AI-assisted engineering: more speed, the same responsibility
AI tools have made writing code fast, but not deciding what to write. A team benefits from them when it already has a precise definition, a clear architecture and automated tests. The human role has changed; it hasn't gone.
AI coding tools have moved from curiosity to daily practice in a short time. Two extreme stories circulate about them: "developers are no longer needed" and "they only produce bad code". Neither matches what I see in practice.
I build products with my engineering team using AI-assisted engineering. This article is about where that works and where it doesn't.
What has changed
Writing code has become cheap. What used to take a day can now take an hour.
But writing code was never the real bottleneck. These were, and still are:
- Knowing what should be built.
- Deciding how it fits into the system.
- Being sure it works correctly.
When writing gets cheaper, those three become more valuable, not less.
Where it really helps
- Repetitive, templated work. Similar code, format conversions, initial scaffolding.
- Exploring unfamiliar code. Understanding what a part does and where it is used.
- Writing tests. Especially the edge cases people forget.
- Refactoring to a clear rule. Changing one pattern across dozens of files.
- Documentation. Explaining existing code.
- Fast prototyping. Trying an idea before committing to it.
Where it is dangerous
- Architectural decisions. A tool gives a solution that works, not necessarily one that fits the rest of the system.
- Security. Code that looks right but skipped validation or access control.
- Subtle business logic. A rule that exists only in the client's head isn't in any code for the tool to learn from.
- Trust without review. The most dangerous case is accepting code nobody read.
What makes the difference
The same tool gives two completely different results in two teams. The difference isn't the tool; it is what exists before it.
A precise definition
An AI tool builds exactly what you asked for. If the request is vague, the result is confidently wrong. A clear requirements document matters more now than before.
Architecture and clear boundaries
When system boundaries are defined, you can ask the tool for one bounded piece behind one contract. Without boundaries, every generated piece ties itself to the rest in its own way.
Automated tests
Tests are the only dependable way to know generated code really works. A team without tests just produces errors faster.
Human review
Every change is read by someone who understands that part. Production speed must not outrun review speed.
My working rules
- Plan first, code second. Before generating anything, it is clear what is being built and where it goes.
- Small steps. A small change can be reviewed; a thousand-line one can't.
- Every line is read.
- Tests ship with the code. Not later.
- An automated quality gate. Type checks, lint rules, tests and a secret scan before every release.
- Confidential data stays in. Keys and user data are never given to a tool.
What it means for the client
- Less time to a first version, provided the definition is clear.
- More test coverage, because writing tests got cheaper.
- Better documentation.
There is a caution too: generation speed can also build technical debt faster. A team using these tools without discipline can, in a few weeks, produce code nobody fully understands.
The human role
An engineer's work has shifted from writing towards defining, deciding and verifying:
- Defining the problem precisely.
- Designing the structure.
- Critiquing the output.
- Taking responsibility for the result.
Those skills haven't become cheaper. They have become scarcer and more valuable.
The takeaway
AI is a multiplier, not a replacement. It makes a good process several times faster and a bad one several times more dangerous. With definition, architecture, tests and review in place, the product arrives sooner and in better shape.
Related: security from day one.