AI Has Left the Building
AI is rapidly becoming part of the everyday development tooling. We use it to write code, explain unfamiliar APIs, generate SQL, troubleshoot errors, create tests, and review existing applications. All of these are perfect use cases for AI. I use these tools daily and have no interest in going back. The problem starts when AI is no longer just a tool but is now a critical dependency.
What happens when ChatGPT, Copilot, Claude, or whatever AI stack you’ve picked is unavailable? Or you’ve exhausted your session tokens or reached your usage limit? Or when the internet connection is down? Heaven forbid, what happens when an outage occurs at 2:00 in the morning and the production system still has to run?
The business is not going to accept “AI is down” as an explanation. As developers, we still need to know how to develop and troubleshoot.
Know How the System Works
If AI generated part of an application, someone on the team still needs to understand it. They should be able to explain how execution starts, what the data sources are, where the data is stored, what services are called and when, what credentials are needed, and what happens when one of those pieces fails. If you can’t explain the code without asking AI, you don’t really own that code, you’re just renting it.
This matters most with line-of-business applications. They rarely fail in the middle of a tidy method. Usually, they fail at the boundaries when connecting to databases, APIs, and networks; when authentication or hardware changes; or during scheduled processes. These failures require an understanding of the entire system, not just the file currently open in Visual Studio.
Keep the Basics Sharp
There are skills you can’t afford to outsource. Besides knowing the basics of the language the application was written in, you need to be able to read an exception and follow a stack trace using the debugger. You need to write basic SQL without having it generated for you and understand key concepts like joins, transactions, indexes, keys, and constraints. You also need to know how to trace events and data through an application and understand how the application is configured and how the settings affect its behavior. You will need to decide whether a problem is in the codebase, the data, new hardware, user permissions, or a misbehaving external system.
None of these skills become obsolete just because AI can help. If anything, they matter more now than ever. The volume of code you didn’t personally write keeps going up as AI is used more, but the responsibility for it is still in your hands.
Troubleshooting Still Belongs to You
Troubleshooting a production issue is rarely a matter of asking the one perfect question. The initial report will likely be incomplete because the user is trying to explain what just broke while figuring out how to possibly work around it.
Before diving in to fix the issue, you need to figure out what actually broke as opposed to what was reported. Who’s affected? When did it start? Is it still happening? Did something change? Can it be reproduced?
Then you start eliminating the possibilities. What do the logs say? Is the database available? Are other systems responding? Did a password, certificate, API key, or service account expire? Did someone deploy new software? Did the data change?
AI can certainly help with the process of elimination. It can suggest hypotheses for root cause, decode an unfamiliar error, and remind you of the config setting you forgot existed. But it can’t replace the person standing in front of the actual system gathering evidence. That part is still yours.
Keep Important Information Local
Your team should have enough local documentation to support its systems without depending entirely on the internet. That means keeping useful documentation, which has always been the bane of a developer’s life. AI is a fantastic tool to generate the first draft of system documentation, especially for old codebases where the original developer is no longer part of the team.
The documents can range from architecture diagrams to build and deployment instructions, from database information and configuration notes to troubleshooting runbooks, recovery procedures, vendor contacts, and an inventory of the scheduled jobs and services nobody thinks about until one of them stops running.
You don’t need to document every line of code or external system call. You do need enough documentation so a developer tasked with supporting the application can figure out what the system is doing when the normal tools are unavailable.
Design Applications for Failure
The same thinking should be applied to the applications themselves. Not every application can run without connectivity, but at least ask what happens when a dependency disappears. If the network drops for thirty seconds, does the application fail? What about ten minutes? What if the database becomes temporarily unavailable? What if a web service stops responding?
Should the application retry automatically, and if so, how many times before it gives up? Should data be queued locally and transmitted later? Can a manufacturing application continue collecting information locally and synchronize when connectivity returns? Failure should be part of the initial design discussion, not something discovered after deployment.
Occasionally Work Without AI
The easiest way to figure out if you have a co-dependent relationship with AI is to stop using it for a while. Debug the next issue yourself or write that easy SQL query. Create a small class without prompting. Trace an action through an unfamiliar application manually.
None of this is because using AI is cheating, but because skills disappear when they aren’t used. Pilots still train for situations that rarely occur because the worst possible time to learn an emergency procedure is during the emergency. We developers should think the same way.
AI Should Make You Faster, Not Weaker
I expect AI development tools to continue getting better. I use them, and I have no interest in returning to development without them. But there is a difference between using a powerful tool and becoming unable to function without it.
A developer should be able to explain the code being delivered, understand how it interacts with the business and its data, determine how it can fail, and support it when something goes wrong. Eventually the network will go down; a service will be unavailable; the AI assistant will stop responding.
And when AI has left the building, you, the developer, will still have to be there.