The dominant narrative aroundAIinsoftware engineeringrevolves aroundcode generation. Autocomplete, test generation, entire functions written from aprompt— the demonstrations are impressive, the claims are ambitious and anyone reading aboutAI-assisted engineeringmight reasonably conclude that AI is good for helping people write code faster.
That has not been my experience. AI has saved me the most time not in generating code, but in understanding systems I did not build. Specifically, it has helped most in the first part of any engineering job: understanding a system well enough to interact with it safely. This isn’t a glamorous use case, but it has consistently saved me real hours. So it’s worth looking at honestly, including where it goes wrong.
What Is the Best Use of AI in Software Engineering?
Beyond code generation, AI provides the most value by helping engineers quickly understand systems they didn’t build. By cross-referencing outdated documentation against actual system behavior and ranking performance debugging hypotheses, AI shortens the tedious initial research pass, allowing engineers to focus on manually verifying specific candidate issues.
The Problem Not Enough People Talk About
There is a problem that happens constantly in software engineering, at companies of every size, that we barely talk about: engineers spend enormous amounts of time working on systems they didn’t build, trying to understand how those systems work well enough to change them safely.
This happens with legacy codebases older than the team maintaining them. It happens when another engineer built something and you’re tasked with modifying it. It happens after acquisitions and team reorganizations, with codebases whose documentation describes what someone intended to build rather than what they actually built. In every case, the first job is not changing the system. It is building an accurate mental model of something that already exists.
Doing this manually — reading through documentation, tracing through code, cross-referencing configuration against behavior, comparing what theREADMEsays against what the logs show — is slow. It’s painstaking work that requires sustained attention across a large volume of material, and it’s easy to do poorly when you’re under a time crunch to actually ship something.
The Real Skill AI Has in Development
The specific approach that I’ve found that works is using AI to do the first pass at cross-referencing documentation against actual system behavior and finding the places where they diverge.
In practice, this means taking the documented architecture alongside actual configuration, logs or code, and asking AI to flag discrepancies. Ask it to spot places where the documentation says one thing and the system clearly does another. For a system with hundreds of configuration entries, interface definitions or integration parameters, doing this manually is the kind of task that eats most of a working day. Using AI to generate a shortlist of likely discrepancies in under an hour and then verifying each one manually is a meaningfully different problem.
The time savings is entirely in generating the candidate list, not in the verification. Every flagged discrepancy still gets checked against the actual system by hand. The AI does not replace that step. Instead, it replaces the tedious first pass of reading through hundreds of items to find the ones worth investigating.
On one system mapping exercise, this approach surfaced discrepancies in configuration that would have taken significantly longer to find through manual review. Some of the AI’s flags were false positives, places where it misread a format or made an incorrect inference. But the real discrepancies it found would have been easy to miss under pressure, and finding them before making changes rather than after is what made the process safe.
Performance Debugging on Unfamiliar Systems
The same principle applies to debugging performance problems in systems you didn’t build. When you know a system well, you have a mental model of which causes are most likely given the symptoms. When you are new to it, you’re working through possibilities in an order that is partly guesswork.
Using AI to generate a ranked list of hypotheses based on the query plan, the architecture and recent changes narrows the search space before manual investigation begins. On one performance debugging engagement, the top-ranked hypothesis was wrong: it pointed to resource contention that turned out not to be the bottleneck. The second hypothesis was correct: a specific processing step had become inefficient as data volume grew. Working through a ranked list starting from the second item is faster than working through an unranked list of 10 from wherever intuition happens to start.
AI didn’t solve the performance problem. It gave me a faster starting point than I would’ve had otherwise, and that starting point was imperfect, which is important to be honest about.
Where AI Goes Wrong
The failure mode that matters most is not the obviously wrong answer. It’s the plausible-sounding wrong answer that is confident enough in tone and specific enough in detail that you would accept it without independent verification.
I’ve seen AI describe a one-off configuration exception as a standard pattern. I’ve seen it miss a discrepancy because it was buried in a format it did not parse cleanly. I’ve seen the top-ranked debugging hypothesis be wrong in a way that would have sent me in the wrong direction if I hadn’t planned to verify it anyway.
The discipline that makes this approach safe is treating every AI-generated output as a hypothesis to verify, not a conclusion to act on. The candidate list is not a set of findings; it’s a starting point for your own investigation. The moment you stop verifying and start trusting, you’ve converted a useful tool into a liability.
There is also a category of work where this approach should not be applied at all, regardless of time pressure: anything where a plausible-but-wrong answer could pass a quick review and cause downstream damage. Migration decisions, security architecture calls, production cutover decisions — these all stay fully human. If being wrong is cheap and visible, an AI-assisted first pass is useful. If being wrong is expensive and subtle, it is not.
Let AI Help You Map
If you’ve thought about AI in engineering primarily in terms of code generation, the documentation-versus-reality cross-referencing use case is worth trying on a system you know well. Find its most recent documentation. Ask an AI to flag discrepancies between the documentation and the actual configuration or code. Then verify every flag manually. You’ll find false positives, you’ll find real gaps and you’ll end up with a calibrated sense of where the tool is reliable and where it is not based on your own codebase rather than a demo.
That calibration is the actual value. Not the tool, but a realistic understanding of where it can be trusted and where it cannot.
