Software development is being reinvented around AI agents — not only as autocomplete, but as orchestratable workers that can plan, implement, and iterate. That shift opens a new way of working: less typing, more architecting and verifying. It also brings real risks: shallow learning, inflated productivity claims, and tooling that can make agents worse instead of better. This post summarises key ideas from Peter Steinberger’s Essential Reading for Agentic Engineers (August 2025), which curates research and essays on both the promise and the pitfalls.

The promise: role reinvention

Research with developers who have made AI central to their workflow suggests a clear evolution: from AI sceptic (dabbling with completions) to AI strategist (orchestrating multi-agent workflows with planning and coding models). At the advanced end, the job shifts from “writing code” to “architecting and verifying implementation work carried out by AI agents”.

That means:

  • Delegation — Context engineering, prompt design, and clear success criteria so agents can execute without micromanagement.
  • Verification — Validating AI output against objectives: does it do what we agreed, and is it correct?
  • Ambition, not just speed — Many practitioners focus less on “time saved” and more on “increasing ambition”: taking on scope and complexity that would have been out of reach before.

Some see a near-term future where the majority of code is AI-written, with humans as “code enablers” or “Creative Director of Code”. Whether or not the timeline is right, the direction is clear: the profession is evolving toward orchestration and verification, with foundational programming knowledge still essential for knowing what to ask for and whether the answer is right.

The learning crisis

There is a sobering counterpoint. Juniors are increasingly able to ship code by leaning on AI without understanding the underlying principles. That’s the argument in the “Hidden Cost of AI-Assisted Learning” thread in Steinberger’s roundup: we may be trading deep understanding for quick fixes.

  • Pattern matching vs. understanding — AI excels at producing working snippets; developers can miss the “struggle phase” where real understanding forms. The gap is between “knowing how to use a solution” and “understanding why it works”.
  • Shaky foundations — Seniors often use AI to amplify existing knowledge. Juniors risk building on sand: when complex debugging or architecture is needed, the missing fundamentals show up. “We’re going to pay for this later.”
  • Generational divide — Those who learned pre-AI often have the fundamentals to verify and correct AI output. Those learning with AI from day one may lack the base to spot subtle errors or bad design.

The implication isn’t to avoid AI in learning, but to use it intentionally: interrogate AI solutions, build from scratch sometimes, and push code review beyond “does it work?” to “why does it work this way?”. Problem decomposition, algorithmic thinking, and system design remain essential for anyone who wants to lead in an AI-augmented world, not just participate.

Reality check: productivity myths

Claims of 10x or 100x productivity from AI are pervasive — and misleading. Much of engineering time isn’t typing: it’s thinking, debugging, reviewing, and coordinating. AI doesn’t fundamentally accelerate those activities. The maths doesn’t add up.

In practice:

  • AI helps most with specific tasks: one-off scripts, boilerplate, repetitive patterns. Those are a fraction of the job. Realistic gains are often in the 20–30% range for well-scoped use cases.
  • AI-generated code frequently needs significant review and correction — sometimes more than writing from scratch. There is a real “correction overhead”.
  • The constant “10x engineer” messaging creates imposter syndrome and anxiety, when in reality experienced engineers quickly learn AI’s limits through use.

A balanced take: use AI where it genuinely helps (scripts, boilerplate, routine refactors), and keep confidence in human judgement for complex problem-solving, system design, and the parts of the work that remain fundamentally human. The goal is a clearer picture of what’s actually changing, not hype or doom.

Context and tools: less is more

Agentic workflows depend on context: the model needs enough of the right information to reason and act. That makes context window economics critical. Every tool, integration, or MCP server consumes tokens. More tools mean less space for the actual code and task.

Geoffrey Huntley’s analysis (also highlighted in the August 2025 roundup) puts it sharply: the more you allocate into the context window, the worse outcomes can get. Proliferation of MCP servers and overlapping tools leads to non-deterministic behaviour — the model struggles to choose between similar capabilities — and adds cognitive overhead. There are security implications too: third-party servers can introduce supply chain and context-injection risks.

The lesson: restrain tooling. Prefer a small set of essential, trusted tools. Enable servers or integrations only when needed for a given workflow stage, rather than loading everything at once. Treat context as a scarce resource.

Conclusion

The new way of development with agents is real: role reinvention, delegation, verification, and higher ambition are within reach for teams that invest in AI fluency and orchestration. So are the downsides: learning that never goes deep, productivity expectations set by myth, and tool stacks that dilute rather than focus the agent.

Embrace the shift — and protect the fundamentals. Use agents for execution where success criteria are clear; keep humans in the loop for direction, review, and the bits that require judgement. Invest in intentional learning and in context discipline. The reinvention of software development is happening; the question is whether we shape it with our eyes open.

Further reading