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.
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 five minutes at a stretch, because typing caps the average user at around 60 words a minute and speech runs closer to 180. (Ahem those of us who took a typing class in the 90s are closer to 120+ but the point stands!)
The skillset Mike describes is closer to drafting a memo than to writing code. Lawyers spend years learning to think clearly under pressure, to anticipate counterarguments, to specify exactly what they want and exactly what they don’t. Those skills, plus a working “bullshit detector” and a willingness to experiment, are most of what it takes to build with these tools today.
The bit lawyers usually need to add is the last part - the curiosity and willingness to experiment. Some legal training does lean towards risk averseness in a way that doesn’t serve help with building new things. We may need to unlearn some things here.
On security
As we talk, Will Chen’s MikeOSS project has been making waves. It’s an open source version of Harvey/Legora.
Mike and I observe that the conversation on vibecoding has become a little polarised into those who seem to believe you no longer need to learn software engineering at all (on the one hand) and those who believe it is a waste of time (on the other).
Mike is realistic here, if a little more bullish than I am on AI’s ability to spot and resolve security and compliance issues in production software at the current time. He’s alive to the limitations of vibecoding and shares that he would be open to partnering with software engineers when the project demands it.
(Side note: my recommended framework for Responsible Vibecoding is at Vibecode.law/learn).
His biggest frustration is people writing about the issues with open source software rather than submitting PRs to resolve the issues. This ties into something else I observe about Mike - his extreme bias towards action. He doesn’t have time for essays about software - he wants to build.
Key lessons for vibecoders
If we step back from the specifics of permits and ADUs, I think what you end up with is a template for building effectively with AI.
Find a problem worth solving. Talk to the people who actually have it and spend as much time with them as you can. The closer you can get to the problem, the better the output. No problem, no solution, no value.
Build in short cycles with rigorous testing. Testing is a critical part of software engineering but it’s something that most vibecoders forget. Software can be tested really effectively because it largely either works or it doesn’t. Don’t forget this part.
Treat the context window like a budget. Mike learned through experimentation how performance drops off a cliff as you use up the agent’s context window. He manages this carefully with compaction, Skills and just starting new conversations.
Prompting still matters. I occasionally read that the era of prompt engineering is coming to an and. I don’t agree on this. Sure, some of the old hacks like “You are a world expert in everything” aren’t very useful these days but Mike’s framework for prompting is effectively about giving the agent the exact context it needs. This leads to better outputs and CrossBeam is proof.
Show your work to real users early and let their reactions reshape the product. Don’t be precious about your first design. Most vibecoders spend so long seeking perfection and not enough time getting it in the hands of real users.
Finally, be curious.
This is the common theme across all episodes on the podcast.
People like Mike who are pushing the boundaries of what is possible do so because they are curious about the boundaries.
Most people thought the California permitting crisis couldn’t be solved with AI. Mike wondered what would happen if it could.
I for one can’t wait to see what Mike builds next.
Up next
In the next episode, I’ll be sitting down with the amazing Nishat Ruiter, General Counsel of TED and the founder of TEDLaw.
