Where AI adoption actually shows up in engineering work

Most writing about AI in engineering describes it the way the vendors describe it — a productivity lift on top of existing practice. The framing is convenient and, in the teams I’ve watched adopt these tools in earnest, mostly wrong. Adoption doesn’t give you the same work, done faster. It gives you different work.

The change shows up on three surfaces. If you only look at one, you’ll misread the whole picture.

The sprint board — which rituals still pay rent, and which have quietly gone empty.
The skill mix — which kinds of engineering expertise just appreciated, and which depreciated.
The handoffs — the seams where humans pass work to the tool and take it back, and where those seams break.

None of these surfaces is hype and none is apocalypse. They are observable, and once you look, they are hard to unsee.

1. The sprint board

The sprint board didn’t break. Its center of gravity moved, and the rituals that sit on top of it haven’t tracked the move. Standup, refinement, estimation, retro — each was calibrated for a distribution of work where the costly middle of a ticket was typing, integration, and routine search. AI tools eat that middle. What remains at the front of a ticket (spec, framing, constraints) and at the back (review, evaluation) is unchanged or harder. The board’s instruments were tuned for the part that got cheap; they were never tuned for the part that didn’t.

The signature of the shift, on most boards, is teams reporting that “agile got worse this year” without being able to point at what changed. Meetings feel decorative. Velocity numbers feel theatrical. Retros drift toward talking about the tool instead of the team. None of these is the ritual being wrong; each is the ritual measuring a distribution that no longer matches the work. The fix is not to discard the rituals — coordinated humans still need scaffolding — but to retune them against the new distribution. The surface itself didn’t fail. The calibration did.

2. The skill mix

Some engineering skills appreciated when AI tools arrived. Others depreciated. Pretending this did not happen is the most common mistake I see senior engineers make, usually because saying it out loud feels cruel.

The skills that appreciated are the ones that are hardest to fake and hardest to outsource:

Spec clarity. The ability to describe the work — precisely, at the right altitude, with the right constraints attached — is now upstream of almost everything. Engineers who can write a tight spec in a paragraph have become disproportionately valuable. Engineers who wrote code to figure out what the work was have lost half their toolkit.
Review under uncertainty. Reading code you did not write, in a style you did not choose, to assess whether it does what the spec actually asked for. This skill was always valuable and is now constant overhead.
Judgment about when to trust output. The meta-skill. It takes a long time to develop and cannot be transferred cheaply. The engineers who got here by doing the work themselves for many years have an unfair advantage.
System thinking. Where does this belong? What else does it touch? Which invariant does it assume? AI tools produce locally-correct code that is frequently globally wrong; catching this requires holding the system in your head, which is harder than ever because you are reading more code that you did not write.
Debugging under uncertainty. Reproducing a bug in code you didn’t author, written in a style you didn’t pick, stitched through a system you now understand one layer less well. An old skill under new pressure.

The skills that depreciated are the ones most rewarded by the previous decade of hiring:

Boilerplate fluency. Knowing exactly how to wire up the fourth microservice of the year. Still useful. No longer a differentiator.
Tool memorization. Command flags, library trivia, the obscure syntax of a framework you chose once in the early 2020s. Cheap now. Your senior engineer who was “very fast at React” is less of an asset than they were; it’s not their fault.
Mid-level glue code production. This one is uncomfortable. The middle of the org chart — the engineers who do a lot of the real-world work that ships product — is the layer under the most pressure, because the tool is best at the exact kind of work that layer used to own. This is a career-stage problem, not a technology problem, and it is not solved by telling people to “skill up.” It is solved by restructuring how work gets assigned so that the judgment-heavy parts — spec, review, integration — are the main work, not the scraps.

If your org’s adoption story does not have a sentence about how the mid-level is going to move up the value stack, the story is incomplete.

3. The handoffs

The vendor pitch for AI tooling pictures a closed loop: engineer thinks, tool writes, engineer reviews, repeat. In practice the loop has seams. A person hands the tool a problem. The tool returns work. A person accepts, modifies, or rejects it. Each of those passes is engineering work in its own right, and a team’s effective velocity is determined less by the tool’s raw output rate than by what happens at the seams between the people and the tool.

Adoption looks healthy on this surface in ways that are easy to mistake. Output is produced. Some of it ships. Activity is high. What is not visible from the outside is whether the seams are paying off — whether the work that was handed over was the work that needed doing, whether what came back was checked rather than skimmed, whether the team understands what just got merged. The seams either compound across a quarter or they leak. Which it is, you cannot read off the velocity number; you read it off the team’s relationship to its own codebase six months in.

What this means, and what it doesn’t

None of this tells you whether to adopt. If your read is “AI tools are a fit for how we build,” you were going to adopt regardless; if your read is “not yet for us,” you already have reasons. This is about where to look when you do.

The honest summary is unglamorous. The leverage is real — on the right work, done by teams that adopt honestly, it compounds into multiples, not percentages. It is also not an apocalypse. What sits between those two stories is where this post lives: AI is a reorganization of where the work is. The rituals that used to carry the work don’t fit the new shape. The skills that used to command a premium don’t. The handoffs that used to be seamless aren’t. Teams that notice the reorganization and adapt their practices come out of adoption with something useful. Teams that only measure the speed of output come out of it with faster bad code and fewer people who can catch it.

If your adoption story is only about speed, you aren’t running the experiment carefully enough.