My interest in computers began as a teenager and followed into my career as an attorney. When people ask how I first became interested in software and automation, I usually tell them it began as a way for me to cheat at video games.

What exactly do I mean by that?

The Grind

When I was around 12 years old, all I wanted to do was play RuneScape, the online fantasy MMORPG that, at the time, felt less like a game and more like a second job. At the peak of its popularity, nearly 250,000 players would be logged in at the same moment. We were all fighting monsters, trading goods, and completing quests. We were all trying to build our way toward some version of digital success.

But there was one problem: progress in RuneScape took time. A lot of time.

If you wanted gold, armor, weapons, or status, you had to chop wood, mine ore, fish, cook, smelt, smith, and repeat the same basic actions thousands of times. We had a word for it in game: the grind. RuneScape rewarded patience and persistence.

My patience had a hard limit. My parents and younger brother would only let me use the family computer for so long.

So I did what any impatient, curious kid with access to the internet might do. I asked: is there a way to cheat the game?

The Bots

It turned out there was code that could play the game for me.

Back then, we called them bots. These were small programs that clicked around RuneScape on your behalf. Instead of sitting at the computer for hours chopping virtual trees, you could run a script that did the tedious work automatically. Just set up the bot in the evening and wake up to an inventory full of valuable items in the morning. That meant I could spend my limited computer time on the fun parts of the game: buying armor, trading on the Grand Exchange, completing quests, talking to friends, and exploring.

The scripts were often written in Java, and many were open source. But that did not mean they were easy to use. You had to find them, understand them, modify them, and keep them working. You had to learn the security risks, or you could accidentally download a virus onto the family computer. The botting community was constantly sharing updates, improving scripts, and warning each other when something stopped working. It was not just about downloading a tool. It was about understanding how the tool interacted with the system and staying one step ahead.

RuneScape was always changing so you had to constantly change your code.

The Cat and Mouse

The moderators (the "mods") would ban your account if they caught you botting. And the problem with our early bots was that they were too perfect. They clicked at the same intervals. They moved in the same exact patterns. They repeated actions with a rapid-fire consistency no human player could maintain.

A human finger does not click every 500 milliseconds for three hours straight. A human hesitates. A human gets distracted. A human moves the mouse imperfectly. A human has a little brother who wants the computer too.

The bots did not.

The mods started monitoring accounts for suspiciously consistent activity. If your clicks were too fast, too regular, or too mechanical, you got flagged. If they caught you, your account was banned, and it was back to square one.

That was my first real lesson about automation: automation that ignores human behavior is easy to detect.

The solution was not to make the bot faster or smarter. The insane speed of the bot was part of the problem. The answer was to make the bot more human. Whether it was RSBot or AutoRune, my goal was simple: make the software invisible and unique. I lived by the principle of randomization. I used Java's random utilities to inject jitter into mouse movements, vary the delays between clicks, and shuffle the order of actions so that no two runs were identical. If your bot clicked on a tree at the exact same millisecond, every 4.0 seconds, for three hours straight, that pattern was a massive red flag.

Here is a simplified Java illustration of the idea. Instead of a fixed Thread.sleep(3000), you would calculate a range. So if an action takes roughly three seconds, randomize the delay and even randomize which action comes next:

```java
import java.util.concurrent.ThreadLocalRandom;

public class RandomTimingExample {
    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < 10; i++) {
            int delayMs = ThreadLocalRandom.current().nextInt(800, 1800);
            int actionChoice = ThreadLocalRandom.current().nextInt(1, 4);

            System.out.println("Waiting " + delayMs + "ms before action " + actionChoice);
            Thread.sleep(delayMs);

            switch (actionChoice) {
                case 1 -> System.out.println("Perform action A");
                case 2 -> System.out.println("Perform action B");
                case 3 -> System.out.println("Perform action C");
            }
        }
    }
}
```

I was a kid in a digital mask, and my success depended on that mask looking and acting human.

The cloak worked. I evaded detection. And I became more confident.

Too confident.

The Green Dragons

The bots for the simple tasks like chopping wood and mining ore ran flawlessly. Then one night, browsing the forums, I saw a script that killed Green Dragons, a lucrative but difficult and dangerous in-game task. I downloaded it and watched eagerly as it slayed dragons for me. To my surprise, it worked. I woke up the next morning to hundreds of Green Dragon hides.

The next night I ran the script again. In the morning, there were no hides. My character had been killed by a dragon and I had lost valuable items.

That was my second real lesson about automation: not everything should be automated. Automation had to respect the environment in which it operated: the rules of the game, the monitors, the incentives, and the risk. The grind could be delegated. The judgment could not.

Even as a middle schooler, the bigger realization was already forming: if software could automate a complicated video game, it could automate office work too.

The Grind of the Law

The practice of law has its own version of chopping wood and mining ore.

There are tasks that are necessary but repetitive like organizing documents, extracting facts, comparing versions, preparing first drafts, generating timelines, reviewing standard clauses, summarizing records, checking deadlines, and assembling routine filings. These tasks are important. But they are not where a lawyer's highest value is found. These tasks are rarely what lawyers enjoy most about the job.

The highest value is judgment. The fun part is the strategy: framing, negotiation, advocacy, risk assessment, client counseling, knowing which facts actually matter. Deciding what argument to make, what issue to press, what concession to avoid, and what path gives the client the best chance at a good result.

The lesson from RuneScape was that the repetitive parts of a system should be identified, studied, and automated so the player is freed to play the strategic part of the game.

The goal is not to replace the player. Legal AI should remove the grind so attorneys can focus on the work that actually requires legal judgment. A well-designed system can gather, sort, compare, and prepare. But the lawyer still decides what to build. Which quest to go on. Which monster to slay first.

From Invisibility to Defensibility

Here is the twist: as I develop legal software today, my entire mindset from the botting days has inverted.

Back then, the objective was avoiding detection. In law, the objective is defensibility. In the world of law, invisibility is the enemy of truth and justice.

If a lawyer uses AI and submits a hallucinated case, they are not just breaking terms of service or cheating the other players of a video game. They are failing their ethical duty of competence. I can no longer build or use software that hides its tracks. I have to build systems so well documented that a judge or regulator could audit every single step of the logic.

Defensibility means turning an algorithm into a high-fidelity paper trail. In the botting days, I used randomness to hide the fingerprints of automation such as the repeating millisecond intervals between clicks. Now, I do the opposite. The code needs to be deterministic and transparent, producing an audit trail that shows the data analyzed, the authorities prioritized, and the specific logic path that led to a conclusion. If the system produces a recommendation, it must include the citations and the rationale behind it, so the attorney can challenge or override it. The goal is a human in complete control of the machine's reasoning, verifying every step.

That evolution turned me from a "hacker" into a Legal Quant. Instead of building to bypass the moderators, I am building to survive the scrutiny of a court of law. By prioritizing explainability, we move technology from suspicious, hidden bots to verifiable, trustworthy legal instruments.

The Lesson: Human Oversight

As a kid, I thought I was just trying to get more gold before my parents kicked me off the family computer. In fact, I was learning how software systems work: that repetitive actions can be studied, that rules create patterns, that software can extend human effort, and that automation is most powerful when it is paired with human judgment and oversight. I also learned that some things cannot be automated.

Today, when I think about legal technology, I still think about that old lesson.

Let the software chop the wood. Let it mine the ore. Let it handle the grind. But don't let it fight the green dragons.

Then, focus on the strategy.

In legal software, as in gaming, an automated process is only as good as the human oversight governing it.