The tool-rollout trap
The decision usually looks responsible. Someone builds a business case, procurement signs off on seats for every engineer, a vendor runs a slick demo, and a message goes out that the company now uses AI. Six weeks later the delivery numbers look exactly like they did before. Nobody is quite sure what went wrong, so the reflex is to measure adoption: what percentage of engineers touched the assistant this month, how many suggestions were accepted, how many lines it generated.
That number is comforting and close to meaningless. Acceptance rate tells you people are pressing Tab. It says nothing about whether the work reaching production is better, safer, or cheaper to change six months from now. I have watched teams post high “AI usage” while their cycle time barely moved, because the time an assistant saves at the keyboard is not where the time actually goes. Writing the first draft of a function was never the expensive part of building software. Understanding the problem, agreeing on the shape of the solution, reviewing it, and living with it were.
Treating AI as a tool rollout assumes the constraint on your organization is typing speed. It almost never is. When you hand a fast code generator to a system whose real bottlenecks are review, context, and decision-making, you get more code pushing into the same narrow pipes. The pipes don’t widen because a tool arrived. Often they get more congested, and flat velocity is the polite version of that outcome. That is the trap: you changed the input and left the organization untouched.
What actually changes when AI writes code
Once a meaningful share of code is generated rather than typed, the center of gravity moves. Review stops being a step near the end and becomes the main event. When a competent engineer produces two or three times more diff, every one of those diffs still needs a human who understands the system to decide whether it belongs there. Reading code critically is slower and more draining than writing it, and it does not parallelize the way generation does. The queue that used to form at “who has time to build this” now forms at “who has time to review it properly,” and if you don’t move deliberately, your most experienced people become a bottleneck by accident.
The scarce skill shifts too. The engineers who get the most from these tools are not the fastest typists; they are the ones who can specify precisely — state the constraint, the edge cases, the invariant that must hold, the thing this must not break. A vague prompt yields plausible, confident, subtly wrong code, and back at Certigon I learned long before any of this that the expensive defects are the plausible ones. Context and specification, the parts of the job that were always undervalued, now separate an assistant that accelerates you from one that generates work for someone else to clean up.
The senior and junior dynamic inverts in odd places. A junior with a good assistant can produce senior-looking output and skip the struggle that used to build judgment, which also means they can ship confident mistakes they cannot yet recognize. What sets a senior apart is no longer production — the assistant handles that. It is the ability to tell when the output is wrong, and to explain why. That is a different competency to hire for, coach for, and organize around.
The four redesign surfaces
If the tool changes the work, the organization has to change with it, and I find it useful to name four surfaces where the redesign actually happens.
Roles come first. The question of what seniors are for needs a new answer. Their value moves from output to judgment: from writing the most code to setting the standard the generated code is held to, coaching specification skills, and owning the calls a model cannot own. Titles and ladders that still reward lines shipped quietly push people the wrong way.
Process is second. Specs stop being optional. The definition of done has to account for code no human wrote line by line, which means it leans harder on tests, on explicit acceptance criteria, and on review treated as engineering rather than a rubber stamp. If your process assumed a person carefully authored every line, it is describing a world you no longer live in.
Architecture is third, and it is larger than it looks. Agents work far better in systems that are legible — clear boundaries, honest names, modules you can reason about without holding the whole thing in your head. The properties that make a codebase pleasant for humans make it tractable for AI, which is why the architecture question deserves its own treatment; I make that case in why AI coding agents reward strong architecture.
Decision rights are fourth and the most neglected. Someone has to answer, explicitly, what an engineer may ship with AI assistance and no human review, and who is allowed to move that line. Left unstated, every engineer invents a private answer, and you discover the full range of those answers during an incident.
Redesign in practice
None of this requires a reorg or a steering committee. A director can start inside one quarter with a few concrete moves.
- Run a spec-first pilot on one team. Change the order of work: write the specification and acceptance criteria before the assistant writes code, and review the spec as seriously as the diff. You are teaching the scarce skill on purpose instead of hoping it shows up.
- Rebalance review load explicitly. Treat review as first-class capacity, not an unpaid tax on your seniors’ evenings. Budget the time, spread it deliberately, and make “I reviewed this well” a valued contribution rather than an invisible one.
- Publish an AI usage policy that names accountability. Keep it short and make one line non-negotiable: a human owns every merge. Whoever clicks merge answers for what ships, assistant or not. That single sentence resolves most of the ambiguity people are otherwise quietly improvising.
- Instrument outcomes, not usage. Watch cycle time, change-failure rate, and recovery time — the signals that tell you whether the system got better. Retire the adoption-percentage dashboard; it measured effort, not results.
At TMA these are the moves I care about, because the product carries real weight: a talent-assessment platform informs decisions about people, so “the AI wrote it” is never an acceptable answer for anything that reaches a customer.
What I’d tell another director
If a peer running an engineering organization asked me where to start, I would tell them to stop thinking about the license and start thinking about the operating model. The tool is the easy part; it is bought in an afternoon. The hard, valuable, slow part is redesigning how your people specify, review, decide, and hold the line on quality when a machine can produce plausible code faster than anyone can check it.
I keep returning to one principle: AI as an accelerator of engineering judgment — not a replacement for it. An organization that internalizes that sentence puts its best people where judgment lives — on the specs, the reviews, the architectural calls, the decision about what may ship — and lets the machine handle the typing. An organization that inverts it, treating the model as the judgment and its people as an afterthought, ships faster into a wall.
Responsible adoption is not a compliance exercise or a slide in a strategy deck. It is the actual leadership work of this decade for anyone who runs engineers: deciding, deliberately, how human judgment and machine speed combine in your organization, then rebuilding the roles, processes, architecture and decision rights so the combination holds up under pressure. The directors who treat that as the job, rather than the tooling, are the ones whose teams will still be shipping well when the novelty wears off.