Over the past six months, I’ve been increasingly using AI to write code at work. My impression is that recent AI tools, e.g. Claude Code w/Opus 4.5+, have reached the point where, with proper prompting, they can write code almost exactly as I would have written it, especially on the backend where our codebase has strong conventions and good abstraction.

AI is increasingly becoming an accelerator for software projects. It’s excellent at writing code — perhaps not quite as good as a human, but much, much faster. Work that would previously take a week can be prototyped in an hour, refined and tested in a day, and reviewed and shipped a day later.

The prototyping speed is particularly exceptional. I find myself thinking, “Why should I write a design document/tech plan/etc. when I can just create a prototype in less time?” Prototyping, when done correctly, achieves the same things design documents are supposed to:

  1. Make architecture/technical decisions.
  2. Surface “unknown unknowns.”
  3. Communicate a shared vision for the project’s desired functionality.

The approach described below works better for some types of projects than others. Important qualifiers:

  • Scope. If a project is too large and ambiguous, then doing some up-front research before prototyping is usually a good idea.
  • Risk. Risky projects with many edge cases (e.g. irreversible data migrations) tend to benefit from more careful, traditional design.

So, this is how my projects tend to go recently:

  1. A Product Manager (PM) sends over a Product Requirements Document (PRD) and we talk about it for a half an hour.
  2. I think up an implementation plan that describes how the PRD should be realized. For example, create X and Y new API routes, a new database table for X, and a form that lives in page Z of the dashboard. (Note: This step is still not optional. You should understand what you want before you start vibing it up with Claude.)
  3. I feed the whole PRD, plus my implementation plan, into Claude Code in Plan Mode.
  4. I review the plan. Usually it’s great. If it’s not, I flesh out missing details my implementation plan and start again.
  5. Claude writes the code (say, about 1,000 lines of code).
  6. I review the code, especially the backend, for security or functional issues.
  7. I launch the app and test out the new feature.

This whole process — including talking with the PM — can often be done in one or two hours.

At this point I have a working prototype. I make a recording of it and share it with the PM and other stakeholders: “Here, how does this look? Any feedback?” This is where the prototype can immediately show its worth, as stakeholders can engage much better with a visible, working feature than with a long design document.

Maybe they suggest changes to the UX. I can take that suggestion, often verbatim, and send it back to Claude Code: “The users for this feature said X. Can we fix that?”

If your company has a security review step, this is the point to kick that off as well.

Once this process is done, the prototype is ready to ship from the stakeholders’ perspective. It matches their vision. Hopefully they’re excited about it.

Of course, as an engineer I’m a bit uncomfortable with it. It’s still feeling pretty vibe-coded. But at least I know what we want. This is important! I didn’t invest a bunch of time writing some artful, modularized, and DRY code just for stakeholders to say, “Actually, can you use the new UI component library instead? Oh, and we want this split into three different pages, too.”

I also didn’t write a long document and take a week to explain it to everyone and get consensus.

Instead, our prototype -> demo -> feedback loop has caught those concerns, perhaps in a matter of hours.

The next step is obvious, and can’t be skipped. I go in there and read all the AI-generated code carefully, line by line, fixing any edge cases, bringing it in line with best practices, and refactoring as needed. Then I test it thoroughly. This usually takes most of a day, or longer depending on the project. The result is code that I’m confident we can ship without issues.

Finally, I split the prototype into multiple PRs (depending on size) and send it off for review.

As a closing thought: working with this model reveals something interesting. The bottlenecks for delivering value in software engineering are shifting. Development and other single-person “deep work” is accelerated so much that we’re finding bottlenecks are showing up everywhere you can’t use AI, like consensus-building and feedback gathering. But this is another big topic and a subject for a future post!