Engineering · 21 Aug 2026 · 7 min read
How we use AI coding tools without shipping worse software
AI assistants write our boilerplate and draft our tests. They also produce confident code that is wrong in expensive ways. Here are the rules that get us the first without the second.
By Gjoko Tashev, Eterna
Article
We use AI coding assistants every day. They write boilerplate, draft tests, explain unfamiliar code and speed up the parts of the job that were never the hard part. They also produce confident, plausible code that is wrong in ways that are expensive to find later. This is how we get the first without the second.
Where it helps
- First drafts of well-understood code: CRUD endpoints, data mappers, form validation, migrations.
- Tests. An assistant is good at enumerating the cases a tired engineer would skip.
- Reading legacy code. Summarising a two-thousand-line module before we touch it saves hours.
- Reviewing our own work. A second pass by a model catches slips in logic, not just syntax.
Where it does not
Anything that requires knowing your business. A model does not know that an active customer means something different in billing and in support, or that the warehouse closes at four on Fridays. Those facts come from discovery and from people, and they are where most bugs live.
Architecture. Assistants optimise for the next ten lines, not the next two years. Decisions about boundaries, data ownership and what should stay boring remain with us.
Security-sensitive code. Generated authentication, cryptography and permission logic gets the same treatment as a junior engineer's first pull request: assume it is wrong until proven otherwise.
The rules we follow
- Every generated line is reviewed by the engineer who owns the feature, to the same standard as human-written code. The model wrote it is not an explanation in a review.
- Nothing is merged without tests that a human read and understood.
- We do not paste client data, credentials or proprietary code into tools that are not covered by the client's agreement with us. Most clients now have a line about this in the contract, and we welcome it.
- We measure. If a tool does not make a specific task faster in our own tracking, we stop using it for that task.
What this means for clients
You get the speed on the parts that are genuinely mechanical, and you get people on the parts that are not. Expect us to be candid about which is which. If a feature is ninety percent boilerplate, we will say so and price it accordingly. If it is ten lines that encode how your company makes money, we will spend a day on those ten lines and not apologise for it.