This is not a post about features beyond autocomplete. It is about what changed in engineering work itself once the agent stopped being autocomplete at all.

TL;DR

• The biggest shift from coding agents like Claude Code is not faster code. It is how engineers learn unfamiliar systems, navigate codebases, and ship small projects that would otherwise die in a notes file.
• The discipline that makes these tools reliable is context engineering: a project-aware CLAUDE.md, structured documentation, and aggressive verification. Output quality depends more on what the model knows about your project than on how clever the prompt is.
• The 2026 data is asymmetric. McKinsey reports 46% time savings on routine tasks and under 10% on complex ones. Roughly 88% of agent pilots never reach production. The differentiator is discipline, not adoption speed.

Last winter, an engineer on our team spent a weekend building a small GNOME shell extension. It tracks screen time and quietly nudges you to take a break. A few hundred lines of code.

It now has over two thousand downloads on the GNOME store.

The interesting part is not the extension.

Without Claude Code, the project would not have shipped. Not because the work was hard. The mix of unfamiliar GNOME APIs, JavaScript packaging, and store submission rules created enough friction that the idea would have died quietly in a notes file. Something about working alongside a coding agent collapsed that distance.

We have been thinking about that pattern for months. It is the most interesting thing happening in our engineering work right now, and it is not the thing that ends up on AI marketing slides.

Why “faster code” is the wrong story

The conventional story about AI in coding is faster code.

True. And not particularly interesting.

GitHub Copilot has been autocompleting Python and JavaScript since 2021. A February 2026 McKinsey study of 4,500 developers across 150 enterprises put numbers on it:

What changed in the last year is what these tools do before the code gets written.

Reading an unfamiliar codebase. Tracing a deployment that failed three commits ago. Untangling an IAM chain across two AWS accounts. Learning a service nobody on the team has touched in years. This is the part of the work that quietly absorbs a third of a senior engineer’s week, and almost all of a junior engineer’s first month.

That has compressed. It is the change worth writing about.

Vibe coding, augmented coding, agentic engineering: a glossary

The industry has not settled on what to call this. Three terms are in the air, and they are not synonyms.

The work we are describing sits between augmented coding and agentic engineering. Vibe coding is the version on the marketing slide. It is not where serious work tends to live.

Three things that change in practice

Specifics matter. When engineers use a coding agent for several months, three patterns keep showing up.

Learning gets interactive

Documentation is broad. Real questions are narrow. The gap between them is where engineers lose hours.

Pick a real one. A CloudFront distribution routes /api/* requests to API Gateway, keeping the direct API URL out of the browser. Every request returns 403. No log explains why.

The non-obvious cause: REST API Gateway reads the first path segment of the forwarded URL as the stage name. CloudFront forwards /api/messages, so API Gateway sees stage=api. The actual stage was named prod. No stage named api exists, so the request is rejected before it reaches any handler.

Fix: create a stage named api on the existing deployment. One console action.

Without knowing that specific URL parsing behavior, the debugging path goes through CloudFront configuration, origin settings, CORS, IAM. A realistic two to three hours before landing on “the stage name is wrong.”

That kind of gap is what a coding agent closes. The conversation ends with an engineer who understands the path, not just the fix. The agent does not replace knowing your way around AWS. It compresses the time it takes to get there.

The same pattern shows up for Terraform modules. For Lambda execution flows. For DynamoDB access patterns. For anything where the documentation is structured by the producer rather than the consumer.

Codebases get readable on day one

Joining a new project is one of the most expensive activities in services engineering. New repository, new conventions, new domain language. Senior time gets spent explaining the same things to every new team member.

Anthropic published a study of their own teams, surveying 132 engineers and researchers. The number that stood out:

Their new hires now use it to navigate the codebase instead of pulling time from people who already have the context.

The same pattern works in any reasonably structured codebase. Ask the agent to trace a request lifecycle. Ask it to identify an authentication flow. Ask it to explain how three services connect. The answer is rarely perfect on the first attempt. It is reliably good enough on the second.

Small projects become possible

Back to the GNOME extension.

The extension itself is a few hundred lines of fairly ordinary code. The point is not that AI wrote an extension. The point is that an engineer with a small useful idea actually built and shipped it, instead of letting it die quietly.

Multiply that across a team and you have a small but real shift in what gets made.

Context engineering: what actually makes coding agents work

Here is the single most underrated finding from a year of working with these tools.

Karpathy put it crisply in his llm-wiki gist:

In practice, this looks deeply unglamorous. It looks like a small markdown file at the root of the repository, typically named CLAUDE.md, that tells the model what it cannot infer from reading your code:

Anthropic’s engineering team writes about this approach formally in Effective Context Engineering for AI Agents. Thoughtworks’ Birgitta Boeckeler covers the practitioner side in Context Engineering for Coding Agents. The discipline is increasingly being called context engineering, to mark it as something different from prompt engineering.

The principle is the same in either name. The model is only as good as the information you put around the task.

What a real AWS system  looks like to an agent

Most of what we do at Craftsmen runs on AWS shaped systems. The conversation about coding agents lands better with a concrete picture, so here is one. A fictional media platform with the kind of architecture our teams actually deal with.

A fictional AWS media pipeline: upload client to S3, S3 event hook to a parse Lambda, SQS queue feeding a transcode Lambda, transcode writing media files back to S3 outputs and metadata to DynamoDB. Annotations flag the questions a new engineer has to absorb: IAM roles, retry behavior, system triggers, cost focus, fault tolerance.

If you have ever onboarded onto a system like this, you know the feeling: a lot to absorb, all at once. What triggers what. Where the IAM roles live. Where the retry behavior is. Where the cost concentrates.

A coding agent with the repository checked out and a CLAUDE.md in place can walk through those questions interactively. Failure modes one at a time. Why each piece is wired the way it is.

The engineer still owns the understanding. The agent ends up being the experienced colleague who is always available and never bored. It is not a replacement for pairing with a human, but the instinct is the same: a second perspective on the same problem.

That is what changes when engineers stop using AI as autocomplete.

What does not work: hallucinations, drift, and the productivity paradox

This section is too often skipped. Anyone who leaves it out is selling something.

A short list of patterns we have run into more than once.

Hallucinated APIs. The agent will, with full confidence, suggest a method that does not exist. The fix is verification. The cost is real if the engineer is moving fast.

Confidently wrong about library behavior. In one session, the agent stated that a form library configuration option would handle live re-validation automatically. It was written into the project documentation as confirmed and working. It was not working. The behavior had to be wired manually on every field in two components. The cost scales with how much code gets built on a wrong assumption before anyone tests the edge case.

Moving fast through destructive steps. In another session, the agent ran a git command that would have discarded all uncommitted working changes in a directory, irreversibly, with no explanation and no warning. The engineer caught it before it was executed. The lesson is not about that specific command. It is about the pattern: the agent moves efficiently through multi-step operations, and some of those steps happen to be destructive.

The productivity paradox. A widely shared METR experiment found that experienced open source developers were measurably slower on a controlled task using AI assistance, while reporting they felt faster. The disconnect is real. It is worth taking seriously.

McKinsey’s number bears repeating. 46 percent time savings on routine tasks. Under 10 percent on complex tasks.

The gain is not free, and it is not uniform.

Where engineering effort moves

The right conclusion from a year of using these tools is not that AI replaces engineers. It is that engineering effort moves.

The complexity does not disappear. It moves.

Anthropic’s own writing on this captures the shift at the lifecycle level. Steps that used to take days or weeks (system design, implementation, testing, deploy) compress into minutes or hours when an agent does the typing and a human stays in the review seat.

Figure: Software development lifecycle, before and after agentic coding tools. Source: How Anthropic teams use Claude Code, Anthropic (2026).

The clearest single statistic for what this looks like comes from a FutureProofing case study published earlier this year. A senior engineer used Claude Code to ship a citation-backed RAG over four thousand clinical guidelines in eleven calendar days. The split:

That is the shape of the work now. The model handles the typing. The engineer handles the design. The throughput number that comes with it, 2.3 times more pull requests per week than the same engineer’s pre-Claude-Code baseline, is what happens when context and verification are set up correctly.

The engineer who used to spend an afternoon plumbing a Lambda invocation now spends that afternoon checking what the model produced (the same code smells and heuristics that matter in any review), deciding whether the approach is right for the system, and writing the tests that confirm it.

This is not a worse job. For most engineers we have talked to, it is a better one. But it is a different one. The skills that get rewarded today are not quite the same as the skills that got rewarded five years ago.

Why this matters for an engineering services company

Three things drive the economics of an engineering services company.

The speed at which engineers can onboard unfamiliar client work. The cost of maintaining knowledge across rotating teams. The quality of the output that ships.

Coding agents move all three.

Onboarding accelerates because the interactive agent absorbs work that used to require senior time.

Knowledge maintenance gets cheaper because context engineering produces durable artifacts (CLAUDE.md files, structured documentation, test suites) that travel across team rotations.

Output quality improves on routine work and stays roughly even on complex work, with the gain concentrated where it actually matters: the time engineers now have for the parts of the job that need their judgment.

The teams that get the most out of this will not be the teams with the most aggressive AI adoption. They will be the teams that take the time to set up context properly, verify aggressively, and treat the agent as a colleague with strengths and weaknesses, not as a magic box.

The cautionary number from the industry: roughly 88 percent of AI agent pilots never reach production (Anaconda / Forrester research, replicated by a16z and the MIT Sloan CIO panel). Adoption is the easy part. Discipline is the differentiator.

Claude Platform on AWS and the May 2026 Code with Claude announcements

Two recent events worth flagging.

On May 11, 2026, Anthropic shipped Claude Platform on AWS. For an engineering company that lives on AWS, this is more than a product announcement. The platform makes Claude Code an officially supported AWS native workflow. It uses your existing IAM. It logs through CloudTrail. It bills through the AWS account you already have.

On May 19, 2026, Anthropic ran the London leg of Code with Claude 2026 and shipped a wave of new agent features. Three of them matter most for the kind of work described in this post:

• Multi-agent Orchestration. A main agent coordinates specialist sub-agents, each with its own context window and tool permissions. Code review, test running, deployment, security checks, all decomposed.
• Outcomes. You define success criteria up front. The agent iterates against them rather than stopping at the first thing that looks done.
• Dreaming. Sessions remember prior sessions. The context engineering we have been doing manually with CLAUDE.md files is going to become partially automatic.

In other words, the way we have been quietly working for ourselves over the last year is now something we can build openly, at scale, on the infrastructure we already operate. The harness around the model is moving faster than the model itself.

Worth paying attention to.

Frequently Asked Questions

Sources and further reading

• McKinsey (Feb 2026). Unleashing developer productivity with generative AI. Link
• Anthropic (2026). How Anthropic teams use Claude Code. Link
• Anthropic (2026). Effective Context Engineering for AI Agents. Link
• Anthropic (2026). 2026 Agentic Coding Trends Report. Link
• Anthropic (2026). Code with Claude 2026 (London). Link
• Kent Beck. Augmented Coding: Beyond the Vibes. Tidy First Substack. Link
• Andrej Karpathy. llm-wiki gist (CPU / RAM analogy). Link
• Birgitta Boeckeler, Thoughtworks. Context Engineering for Coding Agents. martinfowler.com. Link
• METR (2025). Early 2025 AI experienced OS dev study. Link
• FutureProofing. Claude Code production RAG case study. Link
• Anaconda / Forrester research on enterprise AI agent pilot failure rate (88%), replicated by a16z and the MIT Sloan CIO panel.