Everyone is talking about AI-assisted development. After integrating these tools into our engineering workflow for over a year, here is an honest assessment of what moved the needle and what did not.
I want to be honest about something: when AI coding assistants first became capable, I was skeptical. Not of the technology itself, but of the hype. After eighteen months of integrating these tools deeply into how Obsidian Fern builds products — running controlled experiments, measuring velocity, tracking defect rates — I can give you an empirical answer rather than a vibes-based one.
What Genuinely Improved
Boilerplate elimination has been transformative. Code that we would previously spend hours writing — API route handlers, form validation schemas, unit test stubs, TypeScript type definitions from JSON responses — now takes minutes. Our engineers spend more time on the decisions that actually require judgment: architecture, edge cases, performance tradeoffs, and the places where business logic and code intersect in non-obvious ways.
“AI did not replace the judgment calls. It cleared the runway so engineers could spend more time making them.”
What Did Not Change
System design. Architecture decisions. Understanding what the code should do rather than how to write it. These remain deeply human activities, and if anything, they have become more important. As the cost of writing code approaches zero, the value shifts entirely to knowing what to build. The engineers who thrive are not the ones who type fastest — they are the ones who think clearest.
- Velocity on routine implementation tasks increased by roughly 35% on our team
- Code review burden actually increased — AI-generated code requires careful scrutiny
- Junior engineers benefited most in terms of productivity, but also carried the most risk
- Architecture and system design remained entirely human domains
- Testing improved significantly: AI is excellent at generating test cases from specs
The honest takeaway: AI tools are now a standard part of our engineering toolkit, like TypeScript or ESLint. They are not magic, they are not going to replace your senior engineers, and they require discipline to use well. But used well, they make your engineers genuinely more capable. That is not nothing — that is quite a lot.