🧪 AI Makes Writing Code Cheap. Getting It Right Is Still Expensive.

🧪 Fluent isn’t correct

It’s getting easier to produce code. That doesn’t automatically make it easier to ship good software.

AI can generate a function, draft a test suite, suggest a refactor, or scaffold an entire feature. Sometimes that saves real time. Sometimes the output looks polished enough that it’s tempting to accept it and move on.

That’s where I start to worry.

Code can compile and still be wrong. Tests can pass and still miss the behavior that matters. A security flaw can hide inside an implementation that looks perfectly reasonable. And a quick fix can leave the next developer with a maintenance problem that costs much more than the time we saved.

The danger isn’t that AI always produces bad code. It doesn’t. The danger is that fluent output can make us feel more confident than the evidence justifies.

🏗️ The work around the code

This is why I care about the work around the code: clear requirements, meaningful tests, thoughtful review, security checks, and the ability to explain why a solution is correct enough to ship.

🗣️ What the industry says

Leaders in the AI industry are making ambitious arguments about what increasingly capable systems could do. In Sam Altman’s essay “Three Observations”, he describes the potential for AI agents to act like virtual coworkers, including in software engineering, while also noting that such agents may need significant human supervision and can be surprisingly weak in some areas.

That tension is important. Even a capable assistant needs a way to show what it did, where it struggled, and what still needs checking. The more work we delegate, the more important it becomes to evaluate the result.

I’m not interested in rejecting AI because it makes mistakes. Humans make mistakes, too. I’m interested in building a workflow that catches mistakes before they become incidents.

✅ Earning the confidence

For me, that means treating generated code as a contribution, not as proof. Run the tests. Inspect the diff. Check the assumptions. Think about the failure modes. Ask whether the implementation actually meets the requirement.

And measure the whole process, not just how quickly the first draft appears.

If AI helps us deliver reliable software faster, that’s a genuine win. If it helps us generate more code while quietly expanding the review and maintenance burden, the trade-off may be less attractive than it first appears.

I want the speed. I just want the confidence to be earned.