AI & the Audit Profession

A Lawyer Just Beat 500 Developers at Anthropic’s Hackathon. The Lesson Is Not About Code.

For twenty years, knowing the problem and building the solution were two different jobs done by two different people. That wall just came down — and the people who win are the ones who knew the problem all along.

Earlier this year, Anthropic ran a hackathon and let the result speak for itself. Thirteen thousand people applied. Five hundred got in. Most of them were professional engineers. And when the judging finished, first place did not go to a developer at all. It went to Mike Brown, a California lawyer, for a tool called CrossBeam that walks homeowners through the state’s notoriously brutal permitting process for backyard cottages. The other top finishers included a cardiologist in Brussels who built a tool to guide patients after they leave the consulting room, and a road technician in Uganda who turned dashcam footage into infrastructure investment recommendations. By most accounts, none of them had shipped a line of production software before.

Then Anthropic did it again. A few months later, a second hackathon drew more than twenty thousand applicants. The top three: a doctor-turned-engineer in Istanbul, a microsoldering repair technician in a small town in the French Alps, and a computer science teacher in Chile. Anthropic’s community lead summed it up in a single line — this is what it looks like when the people closest to a problem can finally build the solution themselves.

The internet read this story and reached for the obvious headline: coding is dead, anyone can build now. That misses the real lesson by a wide margin. None of these people won because the tools made building easy. They won because each of them understood a problem so deeply that, the moment building got out of the way, they had something worth building. The tool was never the point. The knowledge was.

The scarce skill just became the cheap one

For two decades, the bottleneck in our profession was simple: the person who understood the process — the regulation, the control, the risk — was almost never the person who could build the system that ran it. So we wrote the requirement, handed it across the wall, and someone who did not understand the requirement wrote the code. Nearly everything we have ever cursed in a half-broken application lives in the gap between those two people.

That gap is closing, because the expensive, gate-kept skill on one side of it — the ability to write code — is no longer scarce. A lawyer expressed permit law as working software in six days without learning to code in the traditional sense. The skill that used to take years to acquire is now something the tools largely handle. The bottleneck has moved.

Domain knowledge was always the hard part — now it is the whole game

Here is what none of the winners could have faked, no matter how good the tools became. You cannot weekend-course your way to understanding what a homeowner actually faces in a permitting process, or what a patient needs in the hour after they leave a doctor’s office, or what a stretch of road is quietly telling you about where the next investment should go. That understanding took years. It was always the expensive ingredient. We simply could not see it clearly, because the cost of coding sat in front of it and hid it.

Now coding has stepped aside, and what is left standing in plain view is exactly what these people spent their careers building: knowing the problem cold. The tools did not make domain experts irrelevant. They did the opposite. They stripped away everything that was standing between a deep understanding and a working system — and left the understanding as the only thing that still matters.

The market never actually needed more developers. It needed people who understood the problem — and could finally build for it themselves.

Why this is your moment, specifically

If you sit inside an audit or finance function, read the hackathon story again, because it is about you more than almost anyone.

You have spent your entire career accumulating the one thing that cannot be shortcut. You know how money moves and how controls fail. You know where a number comes from, who approved it, and what a regulation actually demands once you strip away the summary. You know where the edge cases hide, because you are the one who gets called when they surface at quarter-end. That is dense, hard-won domain knowledge — the kind that took years and cannot be acquired in a sprint.

And there is a second instinct most domain experts do not have, but you do. You know what makes a system trustworthy: where did this come from, who can explain it, what happens when the person who built it moves on, how would you prove it to someone who does not trust you. For most professions that instinct is the missing piece. For an auditor it is reflex. So you do not merely get to build — you get to build the version that holds up, the one a regulator can follow and the next person can inherit. Your domain expertise does not stop at knowing the problem. It includes knowing what a system has to be to be believed.

What to build this week

You do not need a hackathon to start. You need one real problem you understand better than any developer ever will — a control still tested by hand, a reconciliation that eats three days a month, a register that lives in someone’s inbox — and you need to build the smallest honest version of the thing that fixes it. Your domain knowledge is the specification. State plainly what the system must know and what it must never do, and let the tools carry the rest.

A lawyer built a permit app in six days because he had understood permit law for years. You have understood your domain for longer than that. The tools have finally caught up to the people who knew the problem all along. The only question left is what you decide to build with what you already know.

— DAXified · audit, built differently