I wanted to migrate a content drip system. My intuition said "web app," and instead of Django (comfort zone), I'd learn Axum, a Rust web framework. Two sessions with Claude Code and I had something real: 1,069 lines of Rust.

If only I had asked first: Does this need to be a web app?

The Question AI Doesn't Ask

The existing content drip system was not developer-friendly. Markdown tables didn't render, lack of syntax highlighting for code snippets. Worse, the content was a copy of our source of truth on GitHub. Every curriculum update meant manual copy-paste. Multiple independent copies? A maintenance headache waiting to happen.

AI makes it dangerously easy to skip past the initial analysis phase. The friction of building used to be a natural speed bump: by the time you'd set up a project, configured a database, and wired up auth, you'd had hours to question whether you were solving the right problem. With AI, you go from idea to working prototype so fast that stopping to think becomes a discipline, not a default. That's powerful when your direction is right, but it's equally devastating when it's not.

Once I stopped and listed what I actually needed, the answer was already in front of me. It turned out that GitHub had everything: markdown rendering, syntax highlighting, authentication, and an API to sync content. I could use GitHub itself as the delivery mechanism and write a workflow to automate weekly content releases.

So that's what I did. 1,069 lines became 156: one GitHub Actions workflow instead of a web app. No hosting, no database, no auth layer to maintain.

Tradeoffs > Building

Less code doesn't automatically mean a better solution. By moving to GitHub Actions, I gave up control. I'm locked into GitHub's platform, constrained by what Actions can do, and YAML isn't exactly a joy to maintain either. But for this specific problem, releasing markdown content on a schedule to people who already have GitHub access, the tradeoff made sense. The point isn't that simpler is always better. It's that I almost never evaluated the tradeoff because I rushed into building.

Years ago Jeff Atwood wrote:

"Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported."

That was true in 2007. It's even sharper now that LLMs will happily write all the code you ask for.

The Moment That Mattered

The most productive thing I did that week wasn't the 1,069 lines of Rust. It wasn't the 156-line workflow either. It was the moment between them, when I stopped building and asked what the system actually needed to do. Questioning each requirement. Realizing most of them were already solved.

It's also interesting how both projects' git logs tell the rest of the story. The Rust app: 2 massive commits, the entire thing scaffolded in one shot. The GitHub Actions workflow: 10 small commits over days. simplify flow. fix username. admin only workflow. Config that started with 3 fields and ended with 1. A security check that took three commits to arrive at a single line. Each commit a deliberate choice, each one touching a small surface area.

This matches what I see working with developers, and across the broader industry now. The developers getting the most from AI aren't the ones asking it to do all the work. They build in small, deliberate increments.

As Boris Cherny put it: "Who are the people getting the most out of Claude Code? Experienced engineers." Not because they prompt better, but because they know what to build, and apply disciplined engineering principles to the code they generate.

AI does exactly what you ask. It can't tell you what not to ask. That judgment comes from experience, hard-earned taste, and being intentional in how you use this new powerful toolset.

Next time a session starts to feel like vibe coding, pause and ask: am I building the right thing? Am I building it the right way?