Follow ZDNET: Add us as a preferred source on Google.
ZDNET’s key takeaways
- You face real maintenance and sustainability issues when ceding coding control to AI.
- Having AI agents write your code is a lot like having human contractors write it.
- These best practices will help you get back from AIs what you asked for.
There are two prevailing narratives about vibe coding. The first is that you can write a single sentence, and the AI will give you back a million-dollar app. The second is that since the AI is writing all the code, humans have no idea what’s inside it. It must, therefore, eventually fail and cause a large-scale apocalypse.
Both of these narratives are caricatures of reality. In previous articles, I’ve talked about my work on a variety of vibe-coded projects. We’ve looked at how they’re both amazing and a lot of work. In this article, I’m going to dive deep into the maintenance and sustainability questions that come from ceding coding control to a machine.
Also: The case against an imminent software developer apocalypse
When I was a young product manager, I was sent down to Los Angeles to support our sales VP. He decided to take me to one of his favorite restaurants. This restaurant specialized in fusion cuisine, which meant the chef would mix a lot of different influences into his food. It had a reputation for its chef’s special, which was whatever the chef decided to create for you that evening.
I remember wondering just what I’d gotten myself into. I knew that I’d get food, but I had no idea what I would be expected to ingest. As it turned out, the food we ate that night was…weird. It was edible. It was not someplace I’d go again voluntarily.
Agentic coding is a lot like going to that restaurant. You know that the reputation of the coding AI you’re using is good, but you really have no idea what’s going to be delivered to you. You have little insight into the actual code coming from the AI. You’re basically going to have to eat it, regardless of what you’ve been served.
Also: I used Gmail’s AI tool to do hours of work for me in 10 minutes
When you have agents writing your code, it’s like having a bunch of contractors or subordinates writing your code. Until you test and evaluate it, you have no idea what you’ll get.
Everything is predicated on your prompt. Garbage-in, garbage-out has a much deeper meaning than the old hackneyed phrase would imply. If you don’t prompt clearly enough, and you don’t maintain the conversation with enough clarity and oversight, the code you’ll get back from the AI will be hard to stomach.
1. The myth of lost control
Engineering managers have faced the challenge of managing contractors under their supervision since the days of the pyramids. Assigning work and evaluating the work product is what engineering managers do. Maintaining quality and control in that process is at the core of software engineering.
Also: Implementing AI into software engineering? Here’s everything you need to know
On the other hand, while much of the vibe-coding doom and gloom is hyperbole, there’s also truth there. Without quality standards and practices, you could end up with problematic code. In this article, we’ll discuss the myths surrounding agentic coding and the best practices that will help you get back from AIs what you asked for.
Many AI coding advocates recommend providing the AI with deep, rich requirements documents. However, my experience is that the AIs can misinterpret one single element of that deep document and go completely off the rails in ways you can’t trace or find.
I prefer to give the AI one simple task. Once that has been successfully completed, I give it another. That way, there’s less of an opportunity for either AI or me to lose track of the overall plan.
As a sole developer, I used to write code line by line. I sweated each and every line. I knew everything about my code. But when I was an engineering manager, I had to rely on my teams and the individual developers on my teams.
Also: I built two apps with just my voice and a mouse – are IDEs already obsolete?
Sure, we had coders (roughly the equivalent of agents). But I still needed to build a discipline of testing and integration into the system, to be sure what was submitted by any one of our coders or contractors worked with everything else.
If you’re going to use agentic coding, you’ll need to do the same. Checkpoints at every stage. Carefully track the integration. Assume you’re taking delivery from outside contractors, and therefore need to check their work before incorporating it into your main project.
2. The myth of real-world readiness
I have a friend whom I dread sharing my software projects with. No matter how carefully I’ve designed and tested my code, the minute I give it to him to run, it breaks.
That’s because he uses the code without my curse of knowledge. I know what my code should do. I know how the program should work. I build the code to do that. My friend, however, does not have that internal map in his head. He just uses it. In the course of using it, he always tries something I never thought anyone would do. The code breaks.
My buddy is a textbook example of the fragility of automated testing systems. Sure, automated tests can help you determine whether a recent fix broke something else. But because you’re pre-planning the tests, you’re bound to miss something that an outsider without the curse of knowledge about your project’s complete spec would inevitably find.
In some ways, AIs help serve the role of the untrained friend. They can be instructed to try various tests to see if the code can survive the encounter. But when AIs are asked to build up their own set of tests, they are also limited by whatever perspective they use or are prompted with going into the project.
Most unit tests examine what are called “happy paths,” the paths developers know and expect the code to take. But those same unit tests often overlook edge cases. When AI builds unit tests, they often inherit the same blind spots as the human-created tests.
Test environments are also not real-world environments. There are more than 20,000 websites running my security software. You would not believe some of the problems users have reported. Problems range from legitimate bugs to spending days on support messages only to find out the software doesn’t work because the user never installed it.
Many coding managers base their assumption of correctness on reports from diagnostic and testing systems. Getting good coverage and performance metrics from tests that suffer from the curse of knowledge can easily mask real-world issues.
Here’s the real cost. When the failures are discovered during integration and deployment rather than in development, debugging complexity and expense can increase considerably.
To overcome this problem, test like an outsider. Incorporate adversarial test practices. When prompting, require edge-case, failure-mode, and misuse scenarios as part of every test plan. Assign people and/or AIs to intentionally misuse and abuse the code without guidance, simulating real users with no internal context. Build in instrumentation for unexpected behavior. Code everything for failure and error correction.
If you’re using agentic coding, remember that your project is never done. It’s just in a state of good enough to test. Expect breakage. Build corrective processes into your management structure and into the code itself.
3. The myth of inherited code
Throughout my years in the software industry, both as an employee and a business owner, one of my core competencies was acquiring rights to software intellectual property.
With the exception of the two Apple apps I’m vibe coding right now, every product I’ve brought to market was originally coded by someone else. There was benefit to this. Most products came with an existing customer base and a pre-built deep understanding of the core application.
But acquired products also come with challenges. There are usually reasons why the software IP is available for acquisition. There can be technical debt inside the software, where something doesn’t work. Market changes can make the software less valuable. There can be (and this was a big driver for my acquisitions) a great deal of weariness on the part of the original developers. They no longer want the responsibility for maintenance and support.
Also: I asked 5 data leaders about how they use AI to automate – and end integration nightmares
I usually inherited black boxes. The code was crafted by other people and teams. In order to improve it, maintain it, and just keep it from exploding in my face, I had to somehow absorb code with all sorts of secrets hidden inside. It’s kind of like buying a house without a home inspection, only to find faulty wiring and broken pipes inside the walls.
This is what every AI coding experience will be like. By definition, the code is not written by human developers. The AIs construct an entire black box. You just hope it will run.
Don’t give up on the process. I’ve made a career shipping code I didn’t fully understand on acquisition. Early on, I had to rely on my programming teams to figure it out. Later, as I dove into a solo developer career, I systematically learned segments of the code, working my way through function after function, often driven by a desire to add a feature or fix a customer-reported problem.
4. The myth of maintenance debt
Since the AI isn’t human, design decisions and code structure aren’t built with humans in mind. If there are problems, debugging consists of a combination of reverse engineering the AI’s work and cajoling the AI to fix something it might not have fully understood to begin with.
Code built by an AI often lacks consistent intent, structure, and architectural coherence. This makes for a shaky foundation, so anything built onto or after becomes a patchwork of disparate elements cobbled together. Likewise, naming conventions and patterns can vary widely across AI-generated components. The result is that changes and updates cascade into unexpected bugs across loosely related areas.
After a few days of working with Claude on a new iPhone app, I decided to take a look at the file structure. It was completely incoherent. The AI had decided to place files wherever it wanted. It named them whatever it seemed to want to name them. As for structure, it didn’t group anything. It was all a giant pile of files in one main directory.
Also: 10 things I wish I knew before trusting Claude Code to build my iPhone app
It doesn’t have to be that way. I instructed the AI to clean up after itself, and it did. It took a few tries to create a file structure pattern that made sense. It took a few other tries to immortalize that practice into startup instructions. Thinking like a manager helped me wrangle my digital subordinate.
Likewise, there are times when careful code reviews will get you quite far. My advice for the agentic coding era we’re entering is to use multiple agentic AIs based on different large language models. Not multiple agents, but multiple AIs. Have one model code-review the other model’s work. Let one model be the maker. Let the other be the evaluator.
This approach won’t solve every problem. I’ve used Claude Code and OpenAI’s Codex to check each other’s work. I’ve been quite pleased about how, with careful coordination on my part, they keep each other fairly honest.
5. The myth of vulnerability-free output
If you think about it, as soon as you combine testing fragility with maintenance debt, you can’t help but get security blind spots. Poorly written code with inherent failure points is a recipe for a perfect storm of security issues.
In some ways, it’s even worse with AI. AI coding models have been trained from information available on the public internet. That includes a tremendous amount of faulty code and bad advice. Programmers have been posting on the internet longer than any other professional group, so the scope and range of that knowledge base might be bigger than just about any other topic area.
Also: 7 AI coding techniques I use to ship real, reliable products – fast
Since most open source code has been posted to GitHub, the underlying software that most of the world runs on has also been available to the models for training. The gotcha? That code doesn’t always work, regularly has bugs and vulnerabilities, sometimes has only been tangentially tested by a lone developer, and often is followed by coding comments from coders who make mistakes. Lots and lots of mistakes.
Models, therefore, may well reproduce insecure coding patterns learned from public data. Input validation and sanitization gaps allow subtle exploit vectors. I was shocked to discover that the AI that I was using to work on my security product did absolutely zero input verification, completely ignoring best practices. Once I adjusted my human assumptions and told the AI to properly check inputs, the validation routines were better than I had written on my own. But I had to diligently instruct the AI to make things secure.
AIs are also likely to incorporate libraries that seem to fit the problem without checking the supply chain for down-chain vulnerabilities or issues. Since AIs generate code far faster than we humans can double-check it, there’s a good chance errors will be introduced that we just can’t catch at meatspace speed.
Also: The new rules for AI-assisted code in the Linux kernel: What every dev needs to know
Add to that the rapidly expanding piles of code made possible by code generation, which takes hours instead of months, and you have a giant time bomb of unverified and potentially unsafe code.
Keep in mind that human-generated code can also be a security nightmare. AIs can sometimes help fix that problem.
My hosting provider recently informed me that the open source anti-registration spam blocker I was using had a severe vulnerability. The author wasn’t available to make fixes. I had my AI examine the code, identify the vulnerabilities, and create a fresh code module that did not contain those vulnerabilities.
Using a separate AI to validate the first AI’s code uncovered a few more things that needed fixing, which I then had the first AI fix. We repeated the cycle until no further errors were found. It’s been months since I installed that new code on my server. In that time, the hosting provider hasn’t red-flagged the new implementation.
Think like a general contractor, not a craftsperson
Perhaps because I spent most of my software career working on code acquired through IP acquisitions or produced by contractors and employees, I’m not freaked out by the fact that AI-written code is a big black box. It’s just that you have to use different skills.
Many cautionary articles on vibe coding contend that although the code writing period of the software lifecycle is wildly compressed, the debugging and maintenance periods have expanded to account for the mess AIs deliver in their code, often after it’s been shipped to users.
Also: How to actually use AI in a small business: 10 lessons from the trenches
There is truth to this worry, but it’s really no different than working with acquired code or code written by contractors. Engineering managers have been dealing with these issues for decades. Good software engineering, planning, and management practices are designed to overcome the problem of contractor opaqueness. It just requires discipline, training, and experience.
This all goes back to the premise that AI isn’t a magic bullet. You’re never going to give a one-line prompt and create a million-dollar product. You have to work it. You can shorten time-to-market. You can use AI to help support maintenance. You can use AI to find and fix security vulnerabilities. You can have fun with AI.
Just remember that the AI is a tool, and you are the professional. You need to manage, delegate intentionally, and test voraciously. If you do, you’re likely to find that you can avoid a vibe coding apocalypse and create solid outcomes.
What’s your take on agentic AI in software development? Let us know in the comments below.
You can follow my day-to-day project updates on social media. Be sure to subscribe to my weekly update newsletter, and follow me on Twitter/X at @DavidGewirtz, on Facebook at Facebook.com/DavidGewirtz, on Instagram at Instagram.com/DavidGewirtz, on Bluesky at @DavidGewirtz.com, and on YouTube at YouTube.com/DavidGewirtzTV.
