We've been using AI coding assistants — Cursor, Claude, GitHub Copilot — seriously for over a year across client projects and our own tooling. This isn't a review of any specific tool. It's a record of what actually changed in how we work, what we thought would change but didn't, and the failure mode we've watched sink two projects.
What genuinely changed
Boilerplate is free now.CRUD handlers, migration files, test scaffolding, Dockerfile stubs, GitHub Actions workflows — anything with a clear pattern and known shape generates in seconds. We still review every line, but we don't write it from scratch. That's a real productivity gain on mechanical work.
Context-switching is cheaper.When you switch from a Go backend to a React component you haven't touched in three months, an AI that understands the codebase cuts the warm-up time significantly. Less time re-reading your own code before you can write new code.
Documentation pressure dropped. Code that would previously need a comment explaining why now gets explained in the prompt history or the commit message. Not a substitute for clarity, but it removed a category of low-value writing.
Learning adjacent territory is faster. Using a library for the first time, reading an unfamiliar codebase, translating idioms across languages — all of these are meaningfully faster with a good AI assistant in the loop.
What stayed exactly the same
- System design. What should this service do? Where does the boundary go? Should we use a queue here or not? AI is a useful sounding board but not a decision-maker. It will confidently argue for whichever option you seem to lean toward.
- Debugging complex state. A race condition, a subtle ordering issue, a distributed deadlock — the kind of bug that requires understanding the system as a whole. AI tools pattern-match to common bugs. Novel bugs require human thinking.
- Client communication and requirements. Understanding what the client actually needs versus what they said they need is still the hardest and most expensive part of any project.
- Code review for correctness.AI assistants are weak at flagging logical correctness issues in context. They'll tell you your code is stylistically fine when it's semantically wrong.
The failure mode nobody talks about
The failure mode we've watched in other teams — and nearly walked into ourselves — is high-velocity wrong direction. AI tools make it very easy to build a lot of code very quickly. If you don't know exactly what you're building, you can accumulate three weeks of generated code pointed at the wrong problem.
The old failure mode was slow movement in the wrong direction — you'd notice after a week. The new failure mode is fast movement in the wrong direction. You notice after three.
Velocity is a multiplier. If the direction is wrong, going faster makes it worse.
The mitigation is the same as it always was: short feedback loops, working software in front of real users early, and a scoping process that establishes what you're building before you start building it. The MVP scoping post covers how we do this.
How we actually use them now
- Generation with immediate review.We generate, we read every line, we push back when it's wrong. The workflow is generate → read → edit → commit, not generate → commit.
- Agent mode for mechanical multi-file work. Creating a new feature scaffold across handler, service, store, test — agent mode is genuinely useful here. Still reviewed before merge.
- Not for architecture decisions.We write architecture decision records (ADRs) the old way: thinking, discussing, deciding. We don't let AI make calls we can't fully explain.
- Prompt investment.A vague prompt gets a plausible but wrong answer. A precise prompt — with context, constraints, and examples — gets something useful. We've started treating prompt quality as seriously as code quality.
Honest advice for engineering teams
Use AI tools. The productivity gains on boilerplate and context-switching are real. But don't mistake speed for progress. The work that matters — understanding the problem, designing the system, verifying correctness — is still yours, and it's still most of the project.
If your team is shipping features faster than your product understanding is improving, that's not productivity. That's inventory.
End of article · Thanks for reading