AI in Practice — Software isn’t finished when it works

AI comes up in almost every conversation we have with clients these days, so we thought we’d share some of what we’ve learned. This is the first issue of a monthly note sharing one real lesson from building software with AI at AnaData. No sales pitch. Just honest lessons from real projects.

Here’s the first of, hopefully, many.

Software isn’t finished when it works. It’s finished when someone owns it.

Over the last ten months, we’ve developed a large part of our product with AI. Features that used to take six or seven weeks shipped in three.

Then a customer asked for a routine enhancement to one of those features.

It wasn’t routine.

The code worked. It passed every test and had been running in production for months. But when we opened it up, nobody on the team felt confident modifying it without first reconstructing the reasoning behind it. The problem wasn’t that the code was wrong. Reviewing code for correctness isn’t the same as understanding why it’s built the way it is. That understanding had never become shared across the team.

So we did something that, in hindsight, was the real warning sign. We asked our AI assistant to explain code we had already shipped. We weren’t debugging it. We were reverse engineering our own thinking.

Here’s the part that took longer to see. The problem wasn’t bad AI code. It was good AI code.

Working, passing code attracts less scrutiny, which is exactly what lets the knowledge gap hide behind the green checkmark. The better these tools get, the deeper that trap gets, not shallower.

Software has always had two costs: writing it and understanding it later when it needs to change. AI made the first dramatically cheaper. It didn’t reduce the second. It simply deferred that cost until the day you have to modify the code.

So we changed our definition of done. Before significant AI-generated code ships, someone on the team must own it: able to explain why it’s built that way, defend the tradeoffs, and confidently change it later without asking the AI to reconstruct its own thinking.

That costs us time. We now see it as an investment in ownership, not a delay in delivery. Some features now take longer to finish than they used to. We’ve accepted the trade-off, because we no longer measure “done” by when the code works. We measure it by whether someone on the team can confidently own it.

Velocity without understanding isn’t speed. It’s debt. The bill always comes due the first time you need to change something.

One question worth asking this week Six months from now, when this feature needs to change, who on your team will understand how it works? If the answer isn’t “someone here,” it isn’t finished. It’s only deployed.