A 5-minute read for anyone who’s ever felt a little dizzy watching AI coding tools eat the headlines
Many people in tech are feeling a bit unbalanced these days. Every week, there’s another headline about AI agents “shipping production code,” “replacing junior devs,” or “ending software engineering as we know it.” If you’re an engineer reading these stories late at night, it’s natural to wonder if the skills you’ve worked so hard to build still matter.
Here’s the short answer: they matter more than ever.
The real challenge isn’t just getting something to work; it’s making sure it lasts.
AI coding agents have reached a new level. For many well-scoped tasks, they can create a script, prototype, or useful first draft quickly. That makes “Can we produce an implementation?” cheaper to answer, but it does not settle whether the implementation is correct or appropriate.
But there’s something you won’t see in demo videos: getting code to run is only one part of the job. The rest includes making sure it can be debugged at 2 am, maintained six months later, secured, observed, and integrated with all the systems around it. There is no honest universal 20/80 split, but there is a real difference in responsibility.
Think of it like buying a high-end camera. You can learn how to point, shoot, and capture an image in an afternoon. But understanding lighting, composition, and how to tell a story through a photo takes years. The tools have become incredibly easy to use, but the craft itself hasn’t.
Why does AI stumble on the hard part
Here’s something important to understand: large language models do not reason exactly as people do. At their core, they generate tokens from patterns learned during training, while modern systems may also use tools, retrieval, planning loops, and additional inference-time computation. Calling that “mere repetition” understates their capabilities; treating it as human understanding overstates them.
That is still powerful, since much good engineering practice is represented in code and writing. But model output remains sensitive to context, instructions, available tools, and evaluation. It can propose a sound abstraction or a costly one with the same confidence. Judgment still belongs to the people accountable for the system.
That gap often appears at the seams: the APIs, interfaces, data contracts, and trust boundaries between parts of a system. Handling them is part analysis and part judgment, shaped by constraints, experience, and a sense of where a system should be strict or flexible. An agent can help explore those choices. It cannot accept accountability for them.
The instruction-following problem is also a safety problem
There’s a flip side to instruction following: current LLM systems do not provide a reliable security boundary between trusted instructions and untrusted content. A malicious repository file, issue, webpage, or tool result may attempt indirect prompt injection. The risk becomes severe when the same agent can read secrets and take privileged actions. The UK National Cyber Security Centre recommends deterministic safeguards, least privilege, monitoring, and impact reduction, rather than assuming prompt injection can be completely filtered away.
Model training, sandboxing, allowlisted tools, approval gates, and data controls all help. None makes unrestricted agency safe by default. Being skeptical is not anti-technology; it is ordinary threat modeling.
So what should you actually be doing?
If you’re using an AI coding agent day to day, a few practices often separate useful sessions from messy ones:
- Feed it the minimum sufficient context: the relevant slice of the codebase, its constraints, and no secrets it does not need. Too little context causes guesses; too much increases noise and exposure.
- Give it deterministic feedback: tests, linters, type checkers, and build output can expose errors, even though passing checks do not prove the implementation is correct.
- Ask for tests around behavior and failure modes: Red, green, and refactor still work when test-first development fits the task, but tests generated from the same misunderstanding are not independent evidence.
- Review the seams and security boundaries yourself: Let the agent draft local implementation; keep accountable humans on contracts, data handling, dependencies, migrations, and privileged operations.
- Treat “it works” as a first draft, not a finish line.
The real skill nobody’s automating away
There’s no single, perfect answer here, because one doesn’t exist. Good engineering has always been about making trade-offs, choosing abstractions carefully, managing how much complexity someone can handle at once, and knowing when a system should be strict or flexible.
That’s the craft. It was true before coding agents existed, and it’s still true now, maybe even more so. As many implementations become cheaper to produce, more of the value moves to choosing and validating the right thing.
The engineers who’ll matter most over the following years won’t merely be the ones who can prompt an agent to produce a working feature. They’ll be the ones who know, with hard-won judgment, what “working” needs to mean and how to produce evidence for it. The 2025 Stack Overflow survey found that respondents distrusted AI-tool accuracy more often than they trusted it, a useful reminder that adoption is not assurance.
If you’re an engineer right now and you feel a bit of imposter syndrome about what your job means these days, that feeling doesn’t mean you’re falling behind. It might just mean you’re paying attention.