Skip to content

FIELD NOTE

What AI Coding Tools Got Wrong

A running account of where these tools have failed us on real work — not as an argument against using them, since we use them daily.

Written by Daksh BathlaFounder — Technology, Product & Business
18 July 2026

This is a first-hand account, not a lesson. It describes what happened on our own work and makes no claim to be generally true — and where a number would make the story better and we don’t have one, it says what happened instead.

Where we're writing from

We use AI assistance on production code every day, and we'd be slower without it. This note is the other half of that: the failures we've actually hit, kept because we noticed the same ones recurring and wanted them written down rather than re-learned.

The plausible method that doesn't exist

The most frequent one, and the least costly once you've seen it. A method with a sensible name and sensible arguments, on a library that has no such method. Types and a run catch it immediately.

What surprised us was how convincing it is when the invented name is better than the real one. Twice we went to the library's documentation assuming we'd find it and were mildly annoyed that we didn't.

Fixes at the wrong layer

Asked why a value was undefined, we got a null check at the point of the error more than once. The check makes the symptom go away and leaves the cause several layers up, where it will produce a different symptom later.

The habit we adopted: before accepting any fix, ask where the bad value came from. If the answer isn't in the change, the change isn't the fix. This has caught more real bugs than any other single review question we use.

The expensive one is convention drift

No individual instance looks wrong. A new date helper here, a slightly different error shape there — each is reasonable code, and each review passes. The cost only shows up months later, as three ways of doing the same thing and no reason for any of them.

Keeping the conventions in a file the tools read each time helped more than we expected, mostly because it also forced us to write down conventions we'd only ever held informally.

What has worked

  • Reading the deletions in a diff before the additions — quiet regressions live there
  • Smaller tasks with a test that must pass, rather than one long session
  • Committing at each working point, so a later confusion costs one step
  • Asking for the uncertain parts to be listed, which is more useful than it sounds

None of that is clever. It's the same review discipline good teams already had, applied to a collaborator that produces tidy-looking code very quickly and has no stake in it existing next year.