AI gets you to a working solution fast. Everything that makes it right, the architecture, the UX, the NFRs, is where the effort has moved.
I am seeing every client’s expectation shift towards quality and what’s being generated. The value of “we will deliver a working solution” is dropping heavily. A working solution is becoming an assumption. Table stakes.
I am seeing this across many client teams at once.
Clients cared about quality earlier as well. But earlier they were ready to let go of some constraints because of time. Now that they can achieve way more in less time with AI, they want to cover more bases.
Kent Beck gave us three steps: make it work, make it right, make it fast. For years, make it work took most of the effort. Make it right and make it fast were often skipped when time ran out.
That is flipping right now. AI is doing the first 80%. The last 20% is becoming the new 80%.
The last 20% is standardization, UI uniformity, architecture, UX, and NFRs.
AI generates more code than your team can check
AI is not deterministic. So I am seeing more small things slip through the cracks. How a component renders. Whether it is compliant with the design system. Whether it comes from the component library.
Unfortunately, everyone thinks QA should be the first role to be automated. So human judgment is also going, and QA is not scaling with the amount of code being generated.
The developer still owns every line, even the ones AI wrote
Developers need to review their own work. But with so much code being generated, that’s too much to ask. And a developer’s accountability is not changing or becoming more flexible. It remains the same whether 100 lines were generated or 100,000. That puts developers in a tough spot.
We already have many harnesses, like code review and automated browser testing. But the problem still remains: AI is not deterministic. So even a 1% chance of a mistake needs full attention. It’s like having flaky test cases. Because of a few flaky tests, we have a full loss of confidence.
The work is shifting from making it work to making it right
People are shifting their focus from making it work to making it right. And even if the client did not ask for it, making it right is becoming our core responsibility as developers. That’s also the differentiator. Making sure the UX is right.
Good developers mob, pair over specs, focus on architecture and learn more.
Mobbing and shared specs make quality a team decision
One needs to go slow to go fast. If teams can’t pause to reflect, meta-think and create harnesses, they are just accruing more issues.
When working on Anthara, we as a team use skills like grill-me and brainstorming while projecting one of our computers on a large screen. Every decision becomes a joint decision. It’s co-creation and co-ownership.
Our spec-creator agent tries to make architecture decisions early on, and our development loop is collaborative. First the spec is created, then we comment inside the spec until we are happy with the full spec. So when the spec is reviewed and done, it’s not just the functional requirements. NFRs and architectural decisions are made as a team too.
As we work this way, we are getting more and more confidence in the outcomes. It definitely is better than one dev working in a silo with vanilla plan mode.
When every decision is a joint decision, one developer is no longer alone with 100,000 lines.
The practices and tools we use to make it right from the start
These are the practices and tools we are using to make it right from the start.
Practices
- Ensemble (mob) programming. The whole team on one screen, one problem. Every decision becomes a joint decision, so no one developer is alone with what AI generated.
- Spec-driven development. Agree on the spec before any code is generated. Put NFRs and architecture decisions in it, not just functional requirements.
Tools
- Grill Me. A Claude Code skill by Matt Pocock that makes the agent question you about your plan, one question at a time, until you agree on what you are building. It stops AI from making it work before anyone knows what right looks like.
- Superpowers. An open-source skills library for Claude Code by Jesse Vincent. It walks the agent through brainstorming, planning, TDD and code review instead of jumping straight to code.
- Bee. An open-source Claude Code plugin my team at Incubyte built for spec-driven development. It sizes each task by risk, then walks you through spec, architecture, code, test, verify and review. It is aware of your design system for UI work, so components don’t drift from the library.
What I Am Building
- Anthara. Enforces your company’s own engineering standards on AI-written code while the agent is writing it, not only at the PR. Your team’s decisions and standards go into every session, so the agent starts from them and you are not reviewing more code than you can. For regulated industries, it also gives you the governance and audit trail.
Build quality in from the start, before AI writes a line
These are observations from the field, and I don’t have all the answers yet. But one thing is clear to me.
Focus on quality upfront. Don’t make it an “I will do it later” thing.
