The Agent in the Terminal — and the Human Behind It

Something decisive happened in the last eighteen months of software development. The terminal became the cockpit.

Not the IDE, not the chat window — the terminal, where a developer types a short description and an AI agent goes away and builds it: reading the codebase, writing files across multiple directories, running tests, fixing failures, and returning with a pull request. The developer's role in that cycle shifted from author to director.

For a generation of engineers who learned to code by writing every line themselves, that's not a small thing. It's an identity question.

This isn't a tool benchmark. There are plenty of those. It's about the strategic and human question that leaders inside technology-intensive organisations need to answer: how do you absorb this wave of capability without crushing the very culture that makes your engineering teams worth having?

The market has already moved — faster than you think

The adoption numbers are not incremental.

~90% of developers use at least one AI coding tool daily _(JetBrains AI Pulse, Jan 2026 — 10,000+ professional developers)_

~41% of all code committed worldwide is now AI-generated _(Anthropic Agentic Coding Trends Report, 2026)_

~34% self-reported productivity jump in the first 60 days of adoption _(Digital Applied AI Coding Survey, Q1 2026)_

~37% of teams report "review fatigue" as a hidden productivity drag _(Digital Applied AI Coding Survey, Q1 2026)_

In the Pragmatic Engineer's February 2026 survey of senior engineers, daily-tool-use reaches 95%. This isn't early adoption — it's infrastructure.

Three tools dominate the conversation, and they've taken radically different architectural bets:

• Claude Code (Anthropic) — a terminal-native agent. No IDE. You describe a task; it reads your codebase, plans, executes, and hands you a result. Context window up to one million tokens. Built for deep, multi-file reasoning on complex codebases.

• Cursor — an AI-native fork of VS Code. AI integrated into the editor itself. For developers who want familiar IDE ergonomics with assistance throughout the flow. Daily-driver territory.

• Codex (OpenAI) — a cloud-native background agent. You assign it a ticket; it spins up a sandbox, runs tests, and opens a pull request while you're doing something else. Three million weekly active users as of April 2026.

> "Cursor makes you faster at what you already know how to do. It's an accelerator. You're still driving. Claude Code does things for you. It's a delegator. You assign tasks; they get done."

>

> — _Developer community consensus, r/cursor + X + Pragmatic Engineer survey threads, 2026_

The velocity here is without historical precedent. Claude Code went from zero to an estimated $2.5 billion annualised run-rate in nine months. Cursor became the fastest-growing SaaS company ever recorded, crossing two billion dollars in annualised revenue by February 2026 — doubling roughly every two months at that scale. GitHub Copilot, with a four-year head start, still leads on total users (26 million+), but its satisfaction scores trail badly. In the Pragmatic Engineer survey, 46% of developers name Claude Code as their "most loved" tool — more than double Cursor and five times Copilot.

The shift this represents is architectural, not cosmetic. These tools have moved from autocomplete to _agentic execution_ — from "suggest the next line" to "build the feature." Only four percent of developers who switched to Claude Code switched back. The stickiness tells the real story.

> SimpleTech perspective — For organisations operating in regulated sectors — public healthcare, public transport, financial services — the tooling question is already decided. The real question is governance: under what conditions does your AI agent touch production-adjacent systems, and who reviews what it produces? That's where the work lives.

What these tools are actually changing

The productivity gains are real, but their shape is surprising. The Digital Applied AI Coding Survey from Q1 2026 found that developers now spend 11.4 hours per week reviewing AI-generated code — compared to 9.8 hours writing new code.

That reversal of the 2024 pattern has implications: an engineer's most important cognitive task is no longer creation, it's _evaluation_. The skill profile required has quietly shifted.

The first 60 days vs. the long run

Self-reported productivity jumps 34% in the first 60 days after adoption, then plateaus. Gains concentrate in specific task types — boilerplate, test generation, documentation, routine refactoring — rather than spreading uniformly across the work. Engineers describe developing intuitions for delegation over time: they tend to hand off tasks that are "easily sniff-checkable" or low-stakes, and keep conceptually difficult or architecturally significant work for themselves, often working through it _collaboratively_ with the AI rather than delegating it entirely.

That pattern is healthy. It suggests experienced engineers are exercising judgment about delegation — which is what good engineering leadership looks like in an agentic world.

Review fatigue: the hidden cost nobody is budgeting for

The same survey that found the productivity jump also found that 37% of teams report "review fatigue" as an underreported drag. When an AI agent produces more code than a developer can meaningfully review, teams face an ugly choice: merge under-reviewed work and accumulate invisible risk, or queue pull requests indefinitely and negate the speed gain. Both failure modes are already appearing in production.

> Risk signal — Cursor adoption studies across GitHub repositories have measured high PR acceptance rates (Claude Code's PRs are accepted and merged 83.8% of the time), but the analyses focus on task types rather than code quality over time. Review fatigue is the silent mechanism by which speed gains can quietly degrade architectural integrity. The seniors-in-the-loop model isn't a rubber stamp; it's the last line of quality and coherence.

The two-tool stack is becoming standard

The most productive engineers in 2026 aren't mono-tool devotees. They run a differentiated stack: Claude Code or Cursor for agentic, multi-file work that needs deep reasoning; Copilot or Codex for inline completion and background task execution. Engineers using this combined approach ship first PRs two to three times faster than single-tool engineers on greenfield work, with a wider margin on refactor-heavy codebases.

The tooling cost for that stack runs $50–$150 per developer per month at productive usage levels — not $20. Any business case built on the $20 headline figure is underestimating reality.

The human question nobody wants to ask aloud

Here's the thing most enterprise AI strategy documents skip past: software engineers aren't interchangeable productivity units. They're people who chose this work partly because of the intellectual satisfaction it provides. Many are intrinsically motivated by the act of building — reasoning through a hard problem, finding an elegant solution, making something work.

When an AI agent does that work for them, the transaction isn't neutral. Something is gained in speed. Something may be lost in meaning.

The Pragmatic Engineer survey from April 2026 caught a signal worth attention: the single most predictive factor for engineer happiness was _not_ which AI tool they used. It was whether they could stop using the tool when they wanted to. Agency — the ability to choose — matters more to satisfaction than any feature set.

> "Agent fatigue is real. Pick the stack that makes you a better engineer, not one that writes so much code you forget how to read it."

>

> — _Pragmatic Engineer / Skila.ai, April 2026_

This isn't a soft concern. It's a retention and talent-quality concern. The engineers most skilled at working with AI agents are also the engineers most capable of leaving for organisations that treat them as professionals rather than prompt-entry interfaces. An AI strategy that consists of "give everyone Cursor and measure ticket velocity" is a fragile stack on top of disengaged talent.

The deskilling risk is real — and manageable

There's a legitimate concern about deskilling: engineers who delegate foundational tasks to agents for years may gradually lose the ability to reason through those problems independently. Not hypothetical. The same pattern showed up when calculators became ubiquitous (arithmetic fluency declined), when GPS became universal (spatial reasoning weakened), and when word processors replaced drafting by hand (many professionals report reduced ability to organise thoughts without typing). The tools extend capability and can atrophy the underlying muscle.

For engineering, the risk concentrates in a few places: debugging intuition (reading traces, reasoning about failure modes), architectural judgment (understanding why a design works or doesn't at a system level), and security reasoning (recognising the shape of a vulnerability in unfamiliar code). These are precisely the capabilities an AI agent cannot reliably provide — and that organisations most need their engineers to retain.

What the role of the engineer actually becomes

The framing that's most useful here comes from CIO's analysis of agentic AI in engineering workflows: the engineer moves from creator to curator. AI agents handle first-pass execution — scaffolding, implementation, testing, documentation. Engineers provide architecture, trade-offs, review, and ownership of outcomes.

Gartner's projection is blunt: by 2025–2026, 90% of software engineers will shift from hands-on coding to AI process orchestration. Whether or not the timeline proves precisely accurate, the direction is clear. The skills that define engineering value are shifting toward:

• Systems thinking — understanding how components interact across a whole architecture, not just within a function

• Orchestration fluency — knowing when to delegate, what to specify, and how to evaluate the result

• Quality judgment — distinguishing correct-looking code from genuinely correct code, especially in edge cases

• Security reasoning — recognising what an agent cannot know: threat models, data classification, compliance constraints

• Prompt architecture — structuring complex tasks so an agent can execute them reliably across a large codebase

None of these are lesser skills than "writes good code." Several are harder. They require deliberate cultivation, not just exposure to tools. Engineers don't become good system architects by watching agents build systems. They become good system architects by building systems — including the ones that fail — and understanding why.

The agentic developer operating model

A practical frame, drawn from what's working:

1. Delegate, don't abdicate. Define what the agent should do. Retain ownership of why and whether it worked.

1. Preserve craft time. Protect space in sprints for work engineers own end-to-end, without AI intermediation.

1. Review as a skill, not a formality. Train and reward the ability to critically evaluate AI-generated code — not just approve it.

1. Audit trail by default. Know what your agents touched, when, and why. Both a governance and a learning requirement.

1. Governance before scale. Define guardrails — security standards, license verification, documentation requirements — before deploying at team level.

1. Agent fatigue is a signal. When engineers disengage from their work, the tool configuration is wrong, not the engineer.

A practical agenda — for organisations adopting at intention rather than at speed

The organisations that extract the most value from agentic coding tools aren't the ones that deploy fastest. They're the ones that deploy with intention.

Start with the right task type, not the right tool

The Anthropic Agentic Coding Trends Report is explicit on this: engineers naturally delegate tasks that are "easily verifiable" and low-stakes first. That's the right instinct. Test generation, documentation, boilerplate scaffolding, dependency audits — high-value, low-risk starting points. Move toward feature implementation and complex refactoring once your team has developed the review intuition to evaluate the output reliably.

Budget for the actual cost — and the actual benefit

Productive use of the leading agentic tools costs $50–$150 per developer per month in tool spend. The ROI calculation is straightforward: a senior engineer at market rate costs many multiples of that per hour. If agentic tools recover even two to four hours per week of high-value work — architecture, security, cross-system design — the return is clear. Build the business case honestly, including the review overhead.

Treat AI agents like new team members

The Senorit analysis puts this precisely: AI agents are most effective when treated like new team members — with code reviews, approval processes, and feedback loops. Not metaphorical. Agents don't merge to main without review. They don't touch production-adjacent systems without a defined approval gate. Their outputs are accountable to the same standards as a junior engineer's PR. That framing also helps preserve the professional dignity of the human engineers around them.

Invest in the skills the agents cannot provide

If engineers spend more time reviewing than writing, the most valuable investment isn't in better prompting (though that matters). It's in the depth of understanding required to review well: architecture review, security reasoning, system design. Internal workshops. Senior–junior pairing on evaluation tasks. Deliberate spaces — internal hackathons, architecture reviews, threat-modelling sessions — where engineers exercise the muscles that agent delegation would otherwise let atrophy.

Give engineers the right to opt out

The data is unambiguous: the single most predictive factor for engineer happiness with AI tools is the ability to stop using them when desired. Mandate is the enemy of adoption quality. Genuine choice — clear guidance rather than directives — turns enthusiastic adopters into the most valuable practitioners. Engineers who find specific use cases where the tools don't serve them are giving useful signal about your processes, not resisting progress.

Build governance before you need it

The OWASP Top 10 for Agentic Applications (2026) catalogues risks including agent goal hijacking, tool misuse, identity abuse, and memory poisoning as critical threats. Gartner projects that 40% of enterprise applications will embed AI agents by the end of 2026. Cisco's State of AI Security 2026 report found that 83% of organisations plan to deploy agentic AI — but only 29% feel ready to do so securely. The gap between deployment velocity and governance maturity is where incidents happen.

> The EU AI Act dimension — For organisations operating in the European Union — including Sweden's public-sector — the EU AI Act introduces compliance obligations that intersect directly with agentic AI in software development. High-risk systems (which may include agents with decision-making authority in critical infrastructure) require conformity assessments, human oversight mechanisms, and transparency provisions. Governance isn't optional here; it's regulatory.

The agent is a colleague, not a replacement

The breathless predictions of engineering teams rendered obsolete haven't materialised, and they won't. What's happening is more nuanced and, in many ways, more interesting: the nature of engineering expertise is shifting. The terminal agent is real, and it's powerful. But the human directing it — the one who knows why this system exists, who it serves, what will break if it fails, what the architecture needs to look like in three years — remains irreplaceable.

The organisations that win in this environment treat the moment as an investment in their engineers, not a substitution for them. They use agentic tools to remove drudgery and expand the scope of what each engineer can accomplish. They build governance that makes that expansion safe. And they actively cultivate the craft — the judgment, the depth, the systems thinking — that no agent can replicate.

The agent in the terminal is a powerful tool. The human behind it is still the point.

> About SimpleTech — SimpleTech is a senior IT consultancy based in Stockholm, Sweden, specialising in development management, project management, and enterprise architecture. We work with organisations in public healthcare and public transport to navigate the complexities of technology with clarity and confidence — including the governance of agentic AI systems. If you're building an agentic AI strategy for your engineering organisation and want to talk it through, we'd be glad to help. simpletech.one

Sources

1. JetBrains AI Pulse, Jan 2026 — 10,000+ developer survey. jetbrains.com

1. Pragmatic Engineer Survey, Feb 2026 — 15,000 developers. pragmaticengineer.com

1. Digital Applied AI Coding Survey, Q1 2026. digitalapplied.com

1. Anthropic 2026 Agentic Coding Trends Report. resources.anthropic.com

1. Uvik Software — Claude Code vs Cursor vs Copilot vs Codex Report. uvik.net

1. Gradually.ai — Claude Code Statistics 2026. gradually.ai

1. CIO.com — How Agentic AI Will Reshape Engineering Workflows in 2026. cio.com

1. Senorit — AI Agents in Software Development 2026. senorit.de

1. DEV Community — The AI Revolution in 2026. dev.to

1. Skila.ai — Cursor vs Claude Code vs Codex. dev.to/skilaai

1. arxiv.org — Speed at the Cost of Quality (Cursor AI tech debt analysis). arxiv.org/pdf/2511.04427

1. GitHub Blog — Hack the AI Agent (agentic security skills). github.blog

1. Strata.io — Agentic AI Risks 2026. strata.io

1. RedMonk — 10 Things Developers Want from Agentic IDEs in 2025. redmonk.com