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.
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.
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.
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.
Specifics matter. When engineers use a coding agent for several months, three patterns keep showing up.
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.
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.
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.
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.
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.
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.
The right conclusion from a year of using these tools is not that AI replaces engineers. It is that engineering effort moves.
|
Less time on |
More time on |
|---|---|
|
Boilerplate and ceremony |
Validation and review |
|
Searching documentation |
Architectural decisions |
|
Repetitive implementation |
Context management |
|
Initial code generation |
Decomposition and specification |
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.
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.
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:
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.