The word "agentic" sounds like hype. It arrives in blog posts alongside promises about 10x productivity and software teams shrinking to one person. Most of that is noise. But the underlying shift is real, and if you wait for the noise to settle before forming an opinion you will arrive late to a working model that other developers have already internalised.
This is an attempt to describe what changes, what does not, and where the risks are.
What does "agentic" mean?
A agentic system is a model that operates in a loop. It reads context, decides what to do, calls a tool, reads the result, and repeats until the task is done. That loop might run for two steps or two hundred.
The crucial word is "tool." An agent without tools is a chat window. Tools are what give it reach: reading and writing files, running tests, querying APIs, spawning other agents, committing to a repository. When those tools connect to your actual codebase and infrastructure, the agent becomes a collaborator that acts rather than one that suggests.
You are not programming the agent the way you program a script. You are briefing it the way you brief a junior developer. The model decides how to get from brief to result.
What changes with agentic development?
The biggest change is where your attention goes during a work session.
Before agentic tools arrived, a developer spent most of the day at the keyboard: searching for the right file, writing boilerplate, looking up library signatures, tracing a call stack to find where a bug entered. The thinking was the valuable part, but the mechanical execution took most of the hours.
With an agent you hand execution to the agent and stay in the loop at decision points. You write the brief. You review what came back. You decide whether the result is correct enough to ship or needs another pass. The mechanical work collapses. The judgment work does not.
| Your day before | Your day with agents |
|---|---|
| Write boilerplate and plumbing | Write clear, specific task briefs |
| Search for the right file to edit | Verify the agent found and edited the right files |
| Run tests manually to see what broke | Review test output the agent ran and interpreted |
| Trace a bug through the call stack | Read the agent's reasoning, then confirm or redirect |
| Context-switch between research and editing | Stay at the review level, redirect when the agent drifts |
| Own the full edit history personally | Own the decisions; agent produces the commits |
The ratio shifts. You spend more time thinking clearly about what you want and less time physically producing it.
What stays the same
The things that do not change are the things that were never mechanical.
Judgment. An agent cannot tell you whether a feature is worth building. It cannot tell you that the architecture you described will cause you pain in a year. It cannot tell you that the bug you asked it to fix is a symptom of a deeper design problem. Those calls still require a developer who understands the system, its history, and the constraints it lives under.
Taste. Code quality, API ergonomics, naming, structure: a model will produce something that works, but "working" and "good" are not the same thing. You still have to know the difference and push back when the gap is wide.
Review. This one surprises people. As agent output volume increases, the quality of your review has to increase with it. An agent can write a hundred lines of plausible-looking code in seconds. It can also introduce a subtle off-by-one error, reach for a deprecated API, or quietly change behaviour in a path you did not mention. You need to read what it produces. Not skim. Read.Common gotchaThe trap is letting your review speed scale with the agent's output speed: a clean diff that compiles and passes tests reads as approved, so you skim a 200-line change in the time a 5-line one used to take.That is exactly when the quiet behaviour change in a path you never mentioned slips through. Cap how much agent output you accept per pass to what you can read line by line, and treat green tests as necessary, never sufficient.
Ownership. The agent produces; you ship. That means you are accountable for everything in the diff. "The agent wrote it" is not a defence when something breaks in production.
Which new skills matter most?
If the mechanical execution is largely handled, what skills become more valuable?
Briefing. The quality of your brief is the primary driver of output quality. A vague prompt produces vague code. A brief that specifies the goal, the constraints, the files involved, the shape of the expected result, and what the agent should NOT touch produces a much tighter result.Common gotchaIf you leave the boundaries unstated, an agent tends to widen scope on its own: it renames variables you never mentioned, "fixes" adjacent code, or refactors a whole module to land a one-line change.Name the files and functions it may edit and the ones it must leave alone, so a small task stays small. This is a learnable craft. You get better at it the same way you got better at writing clear tickets: through feedback and iteration. For the mechanics, see write a prompt Claude can follow.
Context engineering. Agents work within a context window. What goes in that window determines what the agent can reason about. If the relevant file is not in context, the agent works from assumptions. Learning to surface the right files, prune the irrelevant ones, and structure your instructions so the important parts are not buried is a skill that compounds. The context engineering guide goes deeper on this.
Verification. You need a mental model of what correct looks like before you ask the agent to produce it. If you can't describe what "done" means, you can't tell whether the agent achieved it. This is not new, but agents make the gap between fuzzy and precise requirements much more visible, much faster. Turning "correct" into a number you check on every change is what evals for a production AI system is about.
Redirection. Agents drift. They solve the problem they understood rather than the problem you meant. Recognising drift early, stopping the agent, and recalibrating with a tighter brief is cheaper than letting it run for another ten steps in the wrong direction. Good developers learn to intervene at the first sign of divergence.
A useful mental model
Think of yourself as an engineering lead and the agent as a capable but literal developer who just joined the team.
That developer executes well on clear tasks. They follow instructions. They can hold a lot of technical context. But they do not share your understanding of the product, the codebase history, the team's conventions, or the constraints that exist for reasons that were never written down. They will do exactly what you asked, which sometimes is not what you meant.
Your job is to write the brief clearly enough that "exactly what you asked" and "what you meant" are the same thing. That is harder than it sounds.
The loop is tight. You are never out of the picture. You are operating at a higher altitude.
How do AI coding agents fail?
Agents fail in predictable ways. Knowing them ahead of time lets you design around them.
They hallucinate. A model can produce code that looks correct, references a function that does not exist, and pass a surface-level review. Your test suite is your first line of defence. If you do not have tests, the agent's errors are harder to catch.
They lose the thread in long tasks. The longer a task runs, the more likely the agent is to drift, repeat work it already did, or contradict an earlier decision. Breaking tasks into shorter scoped units is more reliable than one long prompt.
They are confidently wrong. An agent does not hedge the way a cautious human does. It produces a result with the same tone whether it is certain or guessing. You need to verify outputs against ground truth, not against the agent's own description of what it did.
They surface hidden assumptions. When an agent misunderstands your brief, it is often because the brief contained an assumption you did not know you were making. This is useful feedback. It forces you to make implicit knowledge explicit.
Cost is real. A long-running agent on a complex codebase with many tool calls can consume significant context and tokens. Understanding roughly what a task will cost before you run it is part of the new discipline, which token usage and cost breaks down.
The risks worth naming
Two risks are underappreciated in the enthusiasm around agentic tools.
The first is skill atrophy. If you stop writing code directly, you stop building the low-level intuitions that let you catch agent errors. A developer who has never debugged a race condition will not recognise one in an agent's output. Use agents to go faster, not to avoid the hard problems entirely.
The second is over-trust. The output looks authoritative. The formatting is clean, the code compiles, the explanation is coherent. None of that means it is correct. The presentation quality of model output is decoupled from its accuracy. Treat every agent output as a draft from a confident intern, not a finished product from an expert.
What to take away
Agentic development is a shift in the developer's role, not a replacement of it. The ratio of thinking to typing changes dramatically. The expectation on clarity of thought goes up, not down.
The developers who do well with these tools are the ones who remain sceptical, who review carefully, who push back when the output is merely plausible rather than good, and who keep building their own understanding of the systems they are responsible for.
The future of software development is agentic. The future of software development still requires good developers.