News

Ishraq Khan is the founder and CEO of Kodezi, a developer tool platform that automates codebase maintenance and acts as an AI CTO.

gettyAI has changed the feeling of building software. A developer can open an AI coding assistant, describe a feature in plain language and get working code much faster than before. Tools like OpenAI Codex and Claude Code are making that workflow feel normal for more developers.

The 2025 Stack Overflow Developer Survey shows how widely AI tools have entered software development, while also showing that many developers still have concerns about trusting their output. That tension matches what I have seen firsthand while building developer tools at Kodezi. AI can help teams move faster, but speed alone does not solve the harder problem of understanding what has actually been built.

In my experience, the first version of code arrives faster, but the responsibility for understanding it does not disappear. It often moves to a later stage. You spend less time writing the first implementation and more time figuring out why it behaves differently once it touches the rest of the system.

The Work Did Not DisappearFor many teams, writing code was never the only hard part of software development. The harder part has often been understanding how systems behave over time. A function rarely fails in isolation. It interacts with databases, APIs, permissions, configuration files, legacy logic, infrastructure and user behavior.

DORA’s 2025 report on AI-assisted software development makes an important point: AI tends to amplify an organization’s existing strengths and weaknesses. If a team already has strong engineering discipline, AI can give that team more leverage. If the team lacks structure, AI can generate more work that still needs to be reviewed and maintained.

At Kodezi, my team and I spend a lot of time thinking about what happens after code is written. We have seen codebases that look productive on the surface while becoming harder to reason about underneath. The better question is not, “Did the AI produce code?” It is, “Can the team explain, maintain and trust the code after it enters the system?”

Why The Loop Feels Like ProgressThe most dangerous part of AI-assisted development is not that the tools are bad. It is that they often produce something close enough to working that you keep going. A developer prompts the system, runs the output, sees an error, asks for a fix, runs it again and repeats the process. Each step feels productive because there is always another action to take.

A paper on vibe coding describes how developers increasingly program through conversation with AI, alternating between prompting, evaluating generated code, testing and manual editing. That workflow can be powerful, but it changes the developer’s job. The work shifts from writing every line to managing context, reviewing output and knowing when to stop relying on the model.

Iteration is part of good engineering. The issue is that iteration without understanding starts to look more like guessing than debugging.

The Hidden Cost Of Almost WorkingEvery developer knows the feeling of a feature that almost works. The UI renders, but the data is slightly wrong. The test passes locally, but fails in staging. The bug disappears once, then returns under a different condition. This is when AI tools become tempting because the next prompt feels easy.

I think this is one reason AI coding can start to feel like a gamble. The tool gives you fast feedback, and when the system gets close to the answer, you feel pulled toward one more attempt. The next patch might finally hold.

The problem is that “almost working” can hide the true cost. A METR study on experienced open-source developers found that AI tools did not automatically translate into faster real-world work. If a developer spends hours prompting without understanding the underlying failure, the team may end up with code that functions temporarily but remains fragile.

The Rise Of AI Debugging And MaintenanceThis matters even more in production systems. A small logic change can affect billing, onboarding, notifications, permissions or data integrity. When AI-generated code enters that environment without enough human understanding, the risk is not only that something breaks. The risk is that the team cannot quickly explain why it broke.

This is why monitoring distributed systems, testing discipline, secure coding practices and technical debt management matter more as AI-generated code becomes common. Teams need to see how software behaves in real conditions, not just whether a generated function works in isolation.

Platforms such as Sentry, Snyk, Datadog and Kodezi approach this problem from different directions. Leaders should not treat any tool as a replacement for engineering judgment.

The Teams That Win Will Understand What They ShipFor teams, the first practical shift is to stop treating generated code as finished code. AI output should be treated as a draft. It still needs review, context and ownership.

The second shift is to measure understanding, not just output. Leaders should ask whether the team knows why a bug happened, whether the fix created reusable knowledge and whether the reasoning was documented. ISO/IEC 25010’s maintainability model is useful because it frames maintainability around whether software can be analyzed, modified and adapted effectively.

The third shift is to break the retry loop earlier. If an issue has survived multiple AI-generated fixes, that is usually a signal to stop prompting and start tracing. Look at the logs. Reproduce the issue. Read the surrounding code. AI can still help, but it should support reasoning instead of replacing it.

AI did not eliminate complexity. It made it easier to create more of it. The winning teams will combine AI speed with human understanding, better debugging workflows and a culture that values maintainability. The question is not how quickly we can generate code. It is how reliably we can understand, maintain and improve that code after it is written.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?