I got into the San Francisco hackathon scene for a dumb reason: my buddy — a marathon runner, perpetually hungry from logging 10+ miles a day — insisted that free food was the best signal for event quality. I wanted prizes and coding. So I built a search across event platforms filtering for all three, and hackathons turned out to be the only type of event that reliably delivered food, prizes, and building. So we went.

This was a period when LLM-assisted coding wasn't banned at hackathons but felt slightly clandestine. You weren't supposed to admit the whole project was made that way. Grad schools were simultaneously giving students rationed ChatGPT access and treating LLM use on homework as cheating. There was no consensus on whether this was a tool or a shortcut. I leaned into it anyway, built a speed-optimized stack, and could reliably ship something demoable in ninety minutes. Not always winning, but always finishing — which put me ahead of most teams, who never made it to a demo at all.

Then the ground shifted. YC startups were openly all-AI-coded. Experienced founders from major companies admitted they'd abandoned their IDEs for Claude Code entirely. At hackathons, the number of people who could actually demo rose sharply — especially after Sonnet 4 shipped. Speed stopped being a differentiator because everyone was fast now.

What I noticed in those rooms: the winning teams weren't the ones with the best engineers. They were the ones who paired a fast builder with someone who understood the customer. My velocity was only valuable when it complemented a designer's eye or a domain expert's judgment. The old sequence — mockup in Figma, then hire a developer — had collapsed. We could have a working prototype in one night. The question was whether it was the right prototype.

When Ninety Minutes Isn't Enough

The hackathon approach — sprint, demo, repeat — works for a night. It doesn't work for a product. I needed something that sustained the speed across weeks without accumulating chaos.

I'd already built a simpler version — a tool that proved agents could claim and complete work autonomously — but it was sequential, and the agents kept confidently building the wrong thing. There was no structured moment to ask "is this the right direction?" before code got written.

Then I saw a webinar demoing a structured coding workflow. Phases. Artifacts. Reviewable checkpoints. I wanted it. It was behind a waitlist. So I asked Claude to build me something similar. That weekend I had a working tool.

I called it Lisa — a Simpsons reference. The AI coding community had popularized "Ralph loops": simple autonomous bash loops that run Claude on a task list until it's done. Ralph loops work, but they're sequential, one task at a time, no dependency awareness. Lisa reads tickets that declare their dependencies, figures out what can run in parallel, and launches concurrent agents through structured phases that leave an auditable trail. Ralph eats paste and gets results through sheer persistence. Lisa does her homework.

Describing Instead of Writing

I used to write code. Now I write descriptions of what I want. Claude decomposes those into structured tickets — epics, stories, individual tasks with declared dependencies. Lisa orchestrates concurrent agents. Each ticket goes through phases that give the agents context and give me a trail I can audit after the fact.

The phases aren't about getting it right on the first pass. LLMs are terrible at shipping something that actually works a hundred percent. They're eager to give the impression it's ready. It never is. The phases exist so that when I open the site and start finding what's broken — the edge cases, the flows that feel wrong — I have leverage to fix things fast. There's a research document showing what the agent thought it was working with. There's a design decision I can check against what I actually wanted. There's a review where the agent flagged its own doubts. I'm not debugging from scratch. I'm iterating from a documented starting point.

You can't figure out what someone actually needs until you get something in their hands. The value isn't first-pass correctness. It's iteration speed.

Five Weeks, Five Problems

In five weeks, I shipped projects I wouldn't have attempted before — not because they were impossible, but because the calendar cost was too high for one person.

The nonprofit grant pipeline was the clearest example. A client needed to find grant-funding foundations but had zero budget for prospecting tools. The data — IRS filings for over 100,000 private foundations — is freely available, but reading it manually would take months. I described the pipeline in plain English. Lisa decomposed it into 99 tickets across 9 dependency waves. Data ingestion ran in parallel. Scoring waited for ingestion, then fanned out. Proposal writing waited for scoring. Work that would have taken weeks of sustained, sequential attention compressed into days because agents could work the dependency graph around the clock. The client got 90 qualified prospects and 20 draft proposals at zero cost.

I wanted to learn Elixir, so I prototyped a booking platform for junk removal operators — my first Phoenix project. Realized the language was viable for the kind of multi-tenant work I was doing, which led directly to building Blanksy, a platform that now has its first paying client.

I wanted to make explainer videos. Built a video engine where AI authors scenes that compile to MP4s with synchronized narration.

A landscaping company kept losing plants to sun exposure they couldn't predict. Built a geospatial tool using satellite and LiDAR data to map microclimates and recommend plants that survive.

Each one started the same way: a real problem or a genuine curiosity, and a workflow that made it cheap enough to follow through.

The Room Where Everyone Could Demo

The thing nobody warned me about is what happens when engineering gets fast and everything else stays the same speed.

I watched it happen in real time at hackathons. One year, having a working demo was rare. The next year, half the room could demo. The differentiator moved — visibly, in rooms I was standing in — from "who can build" to "who knows what to build." The teams that won paired a fast builder with a designer or a domain expert. Adding another coder didn't help. Adding someone who understood the customer did.

That pattern scales beyond hackathons. Organizations built around engineering scarcity — where staffing, planning, and processes all assume that writing code is the hard part — are discovering that the hard part moved. The people who never had to think about implementation details, because engineering was always the bottleneck, are now the ones who matter most. "What should we build, for whom, and how do we know it's right?" used to be downstream of "can we build it?" Now it's the whole game.

Multi-person concurrent AI development — four people, shared codebase, agents running in parallel — is still untrodden territory. The coordination patterns for teams working this way are still being invented. I'm watching for it.

What Comes Next

I don't know if this workflow is right for most developers. It fits my brain — I'd rather describe what I want and do QA than sit in an editor writing implementations. Not everyone works that way.

What I'm confident about is the trajectory. The arc from "AI coding feels like cheating" to "AI coding is table stakes" took about eighteen months. The next shift — from "I can build anything" to "but is this what anyone actually needs?" — is already underway. The technical bottleneck dissolved. The product bottleneck didn't.

Lisa is open source at github.com/johnhkchen/lisa. If this resonates — if you're someone for whom concurrent AI-assisted development could be a difference maker in what you're building — I'd love to hear from you. Drop me a message.