By 2026, a single AI subscription can produce five very different outcomes inside the same infrastructure team. One engineer opens 40 pull requests before lunch across repositories they hadn’t touched in a year. Another ships a Terraform change they can’t explain in review. A third hasn’t returned to the tool since the pilot and says they’ll come back “when it’s ready.” A fourth uses AI for two narrow tasks — decoding a SAML trace and writing a regex — and may be the team’s most productive person. The fifth tries the tool when a keynote comes around and then drifts away.
Everett Rogers’s diffusion curve (innovators, early adopters, early majority, late majority, laggards) describes when people adopt technology, but it doesn’t explain how they use it. With AI, the way people use the tool determines outcomes and risks.
What shifted: the bottleneck moved
For decades, writing code was the slow part of software, so development methods focused on managing that work. Waterfall pushed planning to the front because late changes were costly; Winston Royce warned of the risks of a strictly sequential model in his 1970 paper, but the diagram persisted. Agile corrected course: the 2001 Agile Manifesto prioritized "responding to change over following a plan," and short iterations replaced year-long specs. Facebook pushed speed with the slogan "move fast and break things," but at F8 in 2014 it replaced that with "move fast with stable infra" after fixing breakages started to cost more than the speed saved.
AI has accelerated what remained: models now draft code, and since GitHub made Copilot code review generally available in April 2025, models often review it too. The tempting response is to push Agile further — shorter loops, more agents, less ceremony — but when one engineer can open 40 PRs a day, cumulative changes can create a system nobody understands.
A better position sits between the extremes. Not a fixed waterfall spec, but not the absence of structure either. You need a roadmap that explains where the team is going and why; issues that state the problem before anyone generates a solution; and design reviews where trade-offs are argued. That structure may look like it slows you down, but it makes speed safe. Jazz musicians improvise because everyone knows the chord changes; without that framing they’d just make noise. A roadmap provides the same boundaries for people and their agents.
With AI accelerating implementation, planning becomes the deciding factor on whether fast work is worth doing. On the Synthetic Auth blog the author frames this as "conducting" versus "auditing": a Conductor holds the why (requirements, history, users) and directs agents toward a how that fits it. An Auditor hands over a ticket, checks that the code runs and tests pass, and ships it. An AI reviewer sees only the diff, not the intent — structure gives the Conductor something to conduct from.
Five common modes of AI use and how to manage them
The Soloist
The Soloist is often one of the team’s strongest engineers with a backlog of unplanned ideas. With fleets of agents they can chase every idea at once, producing a wall of pull requests across repositories not planned for change. Each PR may be well executed, but they can pull the team in different directions. A team moves when members pull roughly the same way; historically the cost of weeks of effort forced people to align before starting. Agents remove that cost.
Ask three questions of any Soloist PR: How does this fit the bigger picture? Who are the stakeholders and were they consulted? Beyond agent-written unit tests, has the change been tested against the rest of the system it touches? Too often the answers are no. The 1990s end-user computing wave is a useful analogy: Visual Basic and macro-heavy Excel created many department-level apps that couldn’t integrate, producing shadow IT that took years to reconcile.
Don’t take the tool away — the Soloist is often your most capable engineer. Instead, require that each PR ties to a shared roadmap issue, name stakeholders before work begins, require integration or end-to-end tests for cross-service changes, and have a person review every RFC instead of the model that helped write it. The goal is to keep talent working toward shared priorities.
The Copy-Paster
The Copy-Paster benefits most from AI speed. Tasks that used to take a day — a Helm chart, an IAM policy, a log-parsing regex — now finish in minutes. The danger is that the work completes before it’s understood. Like a junior engineer, the Copy-Paster can’t reliably tell an answer that merely appears to work from one that’s correct; AI output almost always looks plausible. The Copy-Paster defaults to auditing behavior without the knowledge to do it well.
Earlier tooling created similar issues. The phrase "cargo cult" (from Richard Feynman’s 1974 Caltech address) described copying form without understanding, and Stack Overflow made that effortless. Fraunhofer AISEC and Technische Universität München measured the result in "Stack Overflow Considered Harmful?" (IEEE S&P 2017): of 1.3 million Android apps, 15.4% contained security-related code copied from Stack Overflow, and 97.9% of those included at least one insecure snippet.
The industry responded with guardrails: linters, static analysis in CI, mandatory code review, and frameworks with safe defaults. The same approach works for AI. Because autonomous agents raise the stakes, give agents scoped, short-lived credentials instead of the user’s full keys. Require plan-then-apply workflows so a human approves the diff before anything runs. In review, ask the Copy-Paster to explain each change in their own words — that’s how they learn and how the team verifies understanding.
The Godot Waiter
The Godot Waiter isn’t opposed to AI; they wait for it to be "ready": more accurate, better governed, cleared by security, or simply further along. Every platform shift has had waiters. Mainframe shops resisted client/server transitions, and many enterprises argued for years they would never put sensitive data in public cloud — a stance that became harder to defend after the CIA signed a $600 million contract with Amazon Web Services in 2013.
Waiting can be rational: letting others pay the early-adopter tax is a legitimate strategy, and waiters often spot problems enthusiasts miss. The danger is that a single, polished, trustworthy release rarely appears as a single event; instead, trustworthy capability accumulates while early users build judgment the waiter can’t acquire instantly.
The irony: the Godot Waiter often has good Conductor instincts — skepticism, attention to context, and a demand to know why — they just haven’t taken the baton. Treat objections as requirements: write down what would have to be true, check again in six months, and give waiters low-risk, read-only tasks (summarizing incidents or explaining codebases) so their skepticism applies to real outputs and teaches something.
The Specialist
The Specialist uses AI for a short list of precise tasks that complement deep expertise. A BGP-savvy network engineer has the model write Python to parse 40 router configs; an identity architect uses it to decode an unfamiliar SAML assertion and then asks why that assertion was constructed that way. They use AI as much to understand as to produce.
A recent parallel is the scientific Python stack. Wes McKinney, while at AQR in 2008, created what became pandas to address the heavy data-cleaning burden in projects; scientists used Jupyter notebooks to make analyses reproducible, for example when LIGO released the data from its first gravitational-wave detection in 2016 accompanied by a notebook.
This pattern produces the most durable gains. Specialists can check output because they know what a right answer looks like. Their prompts are precise because they know what they’re asking. When the tool is used to learn, the knowledge remains, so they need the tool less over time. Specialists are Conductors with short scores: they hold the why and give the tool only the how. They need the least management and are easy to overlook; find them and learn their proven use cases — they’re the best guide for team AI strategy.
The Tourist
The Tourist tries the tool when it’s in the news, sees a good or bad result, and drifts away until the next launch. If others are conducting or auditing, the Tourist is a member of the audience. Every hype cycle produces tourists: GeoCities pages and Second Life corporate spaces were visible but often abandoned.
Tourists can distort metrics: they inflate license counts and "have you used AI this month?" surveys, making adoption look broad when actual usage is concentrated. Leaders who budget against those numbers get surprised at renewal. Measure repeated use of specific workflows, not mere logins, and give each Tourist one concrete task where the tool reliably helps; some will become Specialists.
Modes, not personalities
These are modes, not fixed personality types: the same engineer can be a Soloist on weekend side projects, a Specialist at work, and a Godot Waiter about letting agents touch production. Good structure — issues, roadmap, design review — helps people shift modes. When writing and reviewing code both take minutes, the issue, the roadmap, and the design review are what keep a team’s people conducting rather than auditing.
Rogers’s curve may eventually show near-universal AI adoption in IT, but adoption alone won’t reveal how effectively people use the tools. What will matter is whether the people using AI are still conducting their agents or are being conducted by them.
