In the latest episode of Without Limitation, I meet Michael T. Brown.

When I sit down with Mike, it has been around three months since he won the Anthropic global hackathon, beating 13,000 applicants, most of them career engineers, with a project built in six days from his home in Orange County.

We’re also chatting on the day before he takes the main stage at Code with Claude in San Francisco, one of the biggest software events in the world this year, where he will be delivering a thirty-minute keynote.

Listen to the full episode on your favourite platform, or keep reading for my take on the conversation.

* Apple Podcasts

* Spotify

Not a software engineer

Mike is, by his own admission, not a software engineer. He has never written a line of code in anger. He is a personal injury attorney by background, with a previous career in Hollywood. Of the top 5 finalists that Anthropic announced, only one was a full-time software engineer. The others included a cardiologist, an electronic musician, an infrastructure worker from Uganda, and Mike, who took the overall crown.

So how did a lawyer win the Super Bowl of hackathons? And what does his story tell the rest of us about what is possible with these tools right now?

Join me on 17-18 June: We are running what promises to be the biggest vibecode hackathon in law, at LegalTechTalk in London. This is a unique event, in partnership with HSF Kramer and Replit. You’ll get free Replit Pro credits just for participating, and there are some great prizes on offer. But to be involved, you must register.

Hollywood to law school to a maxed-out credit card

Mike didn’t set out to be a coder, or a lawyer for that matter. He spent his twenties in Hollywood doing visual effects work. He did what he describes, with a smile, as the rational response to any burnout: he went to law school.

He fell into personal injury practice and genuinely liked it. He spent a few years at California PI firms before hitting the decision point most PI lawyers eventually hit, which is making the decision to go out on his own.

That decision happened to land in late 2023, just as ChatGPT was changing what was possible. Faced with the usual choice between hiring paralegals or burning through savings on back office support, Mike did something different. He started building prompt libraries before anyone was calling them prompt libraries, recording intake calls with client permission, transcribing them through Whisper, and feeding the transcripts into ChatGPT to produce his own version of an intake form.

The system worked well enough that his cousin, a serial entrepreneur, suggested they productise it. They built a company called Onbreeze, a note-taking phone line for lawyers, on the insight that injured clients don’t book a Zoom call with a lawyer - they call.

Vibecoding wasn’t mainstream at this point, and Mike outsourced the entire development process to an external development agency. The product launched in January 2025. Unfortunately for Mike, it crashed the moment a fourth caller hit the line.

When the offshore engineering team explained that fixing it would cost roughly the same as building it had, Mike was already maxed out on credit cards. He downloaded Cursor (an AI coding tool) instead. Ten minutes later, by talking to it about what he needed, he had a working solution. He still couldn’t read the code. But the thing worked.

That was his first prompt.

How Mike learned to build

Onbreeze didn’t take off the way Mike hoped. By May 2025 he was at a crossroads: go back to practising law full time, or lean into the strange new fluency he’d developed with vibecoding tools.

He chose the tools. But what’s interesting is how he chose them. He didn’t go and learn to code in the traditional sense. He took on a series of consulting projects for friends and family, each of which forced him to learn one new thing. A roll-up project for a private equity contact taught him how to handle data across complex databases. A pickup ordering system for his cousin’s butcher shop in Brooklyn taught him Stripe. Mako, a demand letter generator for personal injury lawyers, taught him how to deploy agents to the cloud using Anthropic’s SDK.

He describes it as accidentally building a curriculum. Each project was something he wanted to learn anyway. Each one came with a real user on the other side. And each one added to a stack of skills he could combine later.

By the time the Anthropic hackathon was announced in early 2026, Mike was already far more fluent with the technology than most.

Picking a problem nobody could solve

The hackathon accepted only 500 of the 13,000 applicants, and the brief was specific: they wanted problems that weren’t solvable with previous generation models.

The problem was California’s housing crisis, or more precisely, the permits bottleneck inside it. “Everyone thinks California has a housing crisis,” Mike puts it. “We don’t. We have a permit crisis.” His friend builds ADUs (Accessory Dwelling Units), the small backyard cottages California has incentivised as a partial answer to its housing shortage. The laws are favourable, the demand is there, and yet permits routinely take six to nine months, with endless back and forth between builders and city plan reviewers.

Mike had a hunch AI could help. He asked Cameron to send him a set of blueprints. Claude couldn’t handle them. The pages were physically too big, the size of a table, and the dense annotations meant traditional OCR pulled the text away from the visual context that gave it meaning. A note about wall thickness only mattered if you knew which wall it referred to.

By this point, most people would probably move on, but Mike saw an opportunity. If the most advanced Anthropic model available at the time couldn’t handle this, then it was exactly the kind of problem the hackathon judges were looking for. He submitted, got accepted, and immediately had a small panic about whether he could actually solve it.

The lesson buried in this is that problems are way more important than solutions. Most vibecoders jump straight into building things. Mike spent his time finding a problem worth building for, one that mattered to a real user and that pushed the technology to its current limit.

Building it in six days

Mike decided to call the app CrossBeam. The hackathon ran for a week and by Wednesday night, two days in, Mike was in trouble. He had two disparate approaches, neither of them working, and the hour was getting late. He scrapped the elaborate combination of OCR plus image referencing he’d been wrestling with, and went back to first principles: here are the rules, here are the chunks of blueprint, figure out what’s wrong.

That first end-to-end run hit roughly 40% accuracy against the city’s correction letters. Crucially, it ran. Once a system runs end-to-end, even badly, you can benchmark it and improve it. By Thursday afternoon he was at 60 to 70%.

Two design choices were key here. The first was treating the model’s context window as a precious resource rather than a dumping ground. Mike used Skills, Anthropic’s open standard (think of them like those files that get uploaded to Neo’s brain in the Matrix so he suddenly knows Kung Fu), to keep his prompts lean. He used parallel sub-agents, each with a narrow job and a fresh context, rather than one bloated agent trying to do everything. He used what he calls adversarial prompting: have one agent plan, a second agent execute, and a third agent test, so that no single agent is grading its own homework. For this, he uses an analogy from legal practice: “When an associate brings you a memo, you don’t ask them if they double checked it. Of course they’re going to say yes. You give it to someone else to check.”

The second design choice was testing. He set up command line interfaces on the backend so that one Claude instance could run a new ADU through the system every hour while he worked on something else, tracking accuracy gains in real time. By Friday his accuracy was high enough that he could spend the weekend on the user-facing piece, which itself ended up being shaped by two conversations.

The first was with Cameron, his friend, a builder. Mike sent him fresh outputs and Cameron immediately asked if he could run three more blueprints through. Real users behave like that when something works. The second was with his friend Connor Traut, the mayor of Buena Park. Until that conversation, Mike had only been thinking about the builder side. Connor flipped his perspective: cities also need help, on the review side, processing permits faster. So Mike rebuilt the product to serve both sides. Builders drag and drop blueprints and get back a precise action plan in twenty minutes. Cities batch process submissions and generate draft correction letters. Same product, two different audiences.

Why lawyers might be unusually good at this

Mike’s prompting structure is one most lawyers will recognise immediately. Issue, rule, analysis, conclusion. This is the framework you learn for the bar exam, repurposed as the framework for getting good output from a frontier model.

Mike starts with the issue at the top. Then, the relevant rules and constraints. Next, the analysis: why this matters, who it’s for, what good looks like. Conclusion at the end.

He often prompts by voice, often for f...