Convert the
People
Part I began building the environment for AI-native work. Part II asks the harder question: have the people actually changed how they work?
Do not wait for Part I to be finished. The engineers who begin working agentically are the ones who discover what infrastructure is still missing and can tell AI Ops what to build next. Conversion advances the infrastructure just as the infrastructure advances conversion.
But the direction must come from the top. Bottom-up adoption produces isolated demos; an AI-pilled leader sets the standard, funds the missing infrastructure, and holds the line. Then map the population, apply the right conversion play, and move engineers toward a new job built around orchestrating and verifying agents.
“Wake up, Neo.” – The Matrix (1999)
It Starts at the Top.
One precondition governs all of Part II: conversion only works top-down, and a mandate alone isn’t enough. The decisive variable in this study was whether the top of the house was itself AI-pilled: a CEO, CTO, or VP Eng who had personally run a fleet of agents, not merely sponsored the idea. Such a leader calls the bluffs a sponsor can’t – “I’m 90% AI” doesn’t survive someone who knows what 90% looks like, and holds the line when the org pushes back. Bottom-up enthusiasm without that reverts within a quarter; every transformation that stuck was led from a keyboard, not a strategy deck.
One trait runs through both ends of it: high agency. The leaders who make it happen don’t wait for consensus – they set the mandate and move first; and the people who convert fastest are the high-agency ones who treat that mandate as license to experiment, not an instruction to comply. And it is mostly pre-existing: the best-prepared organizations didn’t build this culture for AI, they already prized speed, ownership, efficiency, and automation, and had invested in systems that could scale, so they met the moment rather than scrambling to manufacture a culture for it. Handing these tools to a team without those bones, as one engineering leader put it, is “an AK-47 to a monkey” – the foundation is far easier to amplify than to create.
You cannot hire your way through the conversion.
That shortage determines the talent strategy. AI-native companies grew engineers with genuine product instincts and agentic fluency internally; converters cannot wait for the market to produce them. The practical answer is hybrid: hire from the small available pool, then pair every external hire with an intensive internal program that retrains the strongest existing engineers into the new mode.
The companies that have moved fastest treat hiring and training as the same workflow: every new hire’s first month is also a learning curriculum for two or three existing engineers paired with them. One profile travels especially well into the new mode: people with a machine-learning or data background, who already think in datasets and evaluation – the same muscles that benchmarks and golden datasets now demand of everyone.
Map: Locate the Population
With that in place, the work begins – and conversion is a distribution, not a number. Organizations convert in pockets, not evenly, and there is no “typical” shape. The four-cluster model below is the diagnostic for locating yourself: Believers and Tool Users separate cleanly on metrics, while Guardians and Resistant share the same low signals – what distinguishes them is whether the resistance has ground.
Defined by behavior. 50K+ accepted LOC/month, 10×+ velocity, and 3+ parallel agents.
Low tens of thousands of accepted LOC/month, 1–2× velocity, and almost no parallel agents.
Low activity with grounded resistance: real architectural constraints or identity tied to the legacy system.
Low activity with no convincing ground: fear, performance theater, or moral opposition.
Two forces sit beneath the clusters: People readiness (willing and able to work AI-natively) and Environment readiness (does the system allow it – Part I infrastructure plus code architecture). A converted engineer in an unconverted environment is paralyzed; the reverse just gets ignored. The Guardian sub-types that follow surface this directly. One caution carried over from Part I: the activity signals above help locate people on the distribution; they are not measures of productivity. Judging the work still needs the complexity denominator.
Convert: Move the Population
The map determines the intervention. Protect the Believers, deepen the Tool Users, and give the Resistant a fair path with a firm deadline. The Legacy Guardians require most of the conversion effort.
Believers don’t need conversion – they need visibility (workflows captured as reusable playbooks), distribution (the strongest made champions inside legacy teams), and pressure (ambitious targets that pull the rest along).
Tool Users already accept AI; the gap is delegation depth. The plays: mandated agentic-workflow training on the team’s own code, a delegation requirement (one ticket-to-PR via AI per sprint), side-by-side bakeoffs, pairing with Believers.
Resistant won’t move regardless – the conversation is fairness of process and acceptance of consequence: equal access, a clear bar, a clear timeline (months, not years), performance-review consequences, then role change or exit.
Legacy Guardians: diagnose, then move
Guardians are the largest cluster, the slowest to move, and the most consequential. Their resistance is partly true – the leader’s job is to diagnose which part.
| Diagnostic question | Architecture-bound | Identity-bound |
|---|---|---|
| Whose concerns are these about? | The system | The code’s character / history |
| What’s missing for AI to work safely? | Tests, sandboxes, observability, decoupled boundaries | Nothing – the system is fine |
| Willing to use AI for adjacent tasks (analysis, tests, review)? | Yes – caution is targeted | Often no – the resistance generalizes |
| What softens the resistance? | A real safety net | A demonstration that their judgment is preserved |
The distinction matters because the same resistance calls for opposite responses. If the environment cannot verify and contain agent work, fix the environment. If the safeguards already exist and the objection still generalizes, the work is human conversion.
Conversion Plays from the Field.
Decisive moves from the study – the bets that reset what a team could do and surfaced who would convert.
The bake-off. An early-stage SaaS built its entire engineering offsite around a single exercise – hands-on time with the agents, capped by a side-by-side, agent-vs-human bake-off on the same tasks. The wager: that watching the productivity delta happen in the room converts the skeptics faster than any presentation can, and the holdouts move themselves.
Write me a CRM. A decade-old software company – not AI-native by birth – shut down all of engineering for a week in October, built a custom internal course, and set every engineer one task: build a CRM end-to-end with Claude Code by the end of the week. They thought it absurd. They built it. Since then, 98% of shipped code is Claude-written.
“I saw what one of them came out with and I was like, this is the future – so we shut down all of engineering for a week.”– CTO, late-stage software company
Mandatory by Sunday. A public consumer company announced its switch to an agentic IDE on a Thursday and made it mandatory by Sunday, expecting 100% agentic code within two months. Engineers are now discouraged from reading code at all – if you’re reading it, the thinking goes, you don’t yet trust the system. The stated culture is unsentimental: “get with the program or get out.”
Rewrite the whole product in Go. An early-stage SaaS decided its legacy .NET stack was the real blocker – too heavy to run many agents in parallel, and not worth patching. Rather than keep fixing an architecture built for a pre-agent world, a small team rebuilt it from scratch in Go using agentic programming, with the old codebase serving as both the spec and the verification layer – the agents read the existing system to recover intent, and the old app ran alongside the new one, dual-read / dual-write, to a clean quarter-end cutover. A from-scratch rewrite that would once have been unthinkable for a team that size.
The whole-company hackathon. A ~1,800-person fintech ran a company-wide AI build-a-thon – and only about a sixth of the company were engineers. Roughly a thousand people entered 600 projects, auto-scored by an ensemble of models because no human could watch them all. The standout came from sales: a real-time AI co-pilot that listens on a live call, scores the customer’s sentiment, and tells the rep what to say next – “like a senior SDR whispering in a junior SDR’s ear.” Conversion isn’t only an engineering problem.
Architecture-Bound: Fix the System First.
Architecture-bound Guardians are often right. Agentic AI does not create a new class of architectural problems; it makes the old ones much more expensive.
Software teams have spent decades wrestling with sparse test coverage, undocumented APIs, service boundaries, dependency sprawl, and code that only a few veterans understand. At human speed, review, coordination, and institutional memory kept many of those weaknesses under control. Connect an agentic engine to the same architecture and you do not remove the debt – you generate changes against it faster. A brittle system becomes more brittle at machine speed.
Dated languages, slow build and test loops, and legacy package dependencies deepen the gap. The organizations that already invested in modular boundaries, documented contracts, observability, modern dependencies, and fast verification arrived better prepared for agents. Others have to catch up before they can capture the same acceleration.
Fortunately, AI can accelerate that preparation too. The first agentic program does not have to be a new feature: point agents at the changes that expand their own safe operating envelope. Let them map, document, test, decouple, and modernize the system first. This is not a detour from adoption; it is the work that makes sustained adoption possible.
Six plays for an agent-ready stack.
Use agents to locate high-fan-in modules, cycles, shared state, and cascading dependencies; then generate dependency maps, context files, service contracts, architectural decisions, and runbooks. One public infrastructure company had to document a multi-million-line, eight-year codebase before agents could traverse it effectively.
Generate characterization tests against existing behavior, contract tests around APIs, and end-to-end traces that connect a code change to its runtime consequence. The goal is a verification function strong enough for agents to check their own work.
Separate the data and domain layer from the UI behind stable APIs and contract tests. Agents can then rewrite either layer independently, and a legacy front end no longer constrains backend velocity.
Break the system into units agents can hold in context. Modularization can split a monolith, while consolidation can pull fragmented services back into a clean monorepo. Direction matters less than clear boundaries and predictable agent behavior.
Put a proxy, facade, or abstraction layer at a stable seam, then route one capability at a time to a new implementation while old and new coexist. Where no clean API exists, intercept events or use an anti-corruption layer. Remove the transitional seam after the migration.
When incremental displacement is slower or riskier than rebuilding, move a bounded component onto modern languages, runtimes, and packages. Treat the existing product as both specification and oracle: run both systems, mirror traffic, compare outputs, and use dual-read or dual-write before a staged cutover.
Identity-Bound: Convert the Person.
The codebase is fine. The resistance is human. What’s at stake: mastery (years of expertise feel devalued), status (visibly slower than AI-native peers), identity (writing code → supervising it), control (can’t audit every line). The phrase to listen for is “I read every line.” It sounds like rigor. Often, it is the last defended position.
Plays: convert expertise into validation criteria (they define “good,” AI does the work) · hero rewrite with old system as oracle · pair with a Believer · name the fear out loud.
The Engineer’s New Job Is Orchestration.
Once engineers own a broader product surface, the job itself changes. It is not the old work sped up. Running a squad of agents is an orchestration role: you hold three to five parallel threads, each an agent mid-task, and the work is the stream of decisions they surface – an architecture call here, a rejected approach there, a “no, do it this way” before a bad path compounds.
The dominant cost is context switching, and it changes how you think. Every thread carries its own mental model, and recovery never fully completes before the next demands attention, so you hold several partly-loaded models and none of them whole – thinner still as the loops lengthen and the threads multiply. It rewards a specific temperament: sustained concentration, fast judgment, and the discipline to run one thread fewer than feels possible. Cognitive bandwidth, unlike the agents, does not parallelize, and the gap shows up as what Addy Osmani calls comprehension debt – supervising more than you can deeply understand. Boris Cherny, who built Claude Code, describes where it ends up: “I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do.”
The closest analogy is a civilization-building strategy game like Age of Empires: you can hold your own for a while on frantic micro, clicking every villager by hand, but you win by building the economy and advancing through the ages. Creating loops is that economy, and the gains compound – get them right and the same person goes from three threads to thirty. It is, not by accident, the same high-stimulation loop from the foreword, which is what makes the work both addictive and draining.
The other half of the job is raising that ceiling: making each thread independent enough to need fewer interruptions. The lever for that is verifiability. A thread runs unattended only as far as you can confirm its output is right. Past a point the constraint is not how fast agents generate code but whether you can prove it correct – quietly, the single largest bottleneck on autonomy. The orchestrator’s real craft is less writing prompts than building the checks (tests, types, evals, shadow runs, the old codebase as a spec) that let a thread prove its own work. Where that proof holds, the loop runs; where it doesn’t, you are back to reading every line.
Were you vibing, or were you engineering?
This is the line between vibe coding and agentic engineering – Andrej Karpathy’s terms. Vibe coding is letting the agent run and accepting what comes back; it’s fine for a throwaway, but it hits a wall the moment the project scales or reaches production, because you can’t operate or maintain what you never reasoned through.
Agentic engineering is the craft of managing agents – leaning on AI just as hard while keeping judgment in the driver’s seat. You hold the design and architecture, and you can step in. Control comes not from inspecting code at human speed but from reviewing the plan with the agent, asking leading questions, and confirming the result is what you intended. Teams that master this scale with agents; teams that default to vibe stall the first time something breaks in production.
The Project Has to Learn You.
The beginning of building this way can be deeply discouraging. I have started projects where working through agents initially felt slower than writing the code myself. Every assumption had to be explained. The agent misunderstood the architecture, chose the wrong dependency, broke something, or produced work that looked finished but was not. You spend hours correcting it, tightening the environment, and wondering whether the promised acceleration is real.
But each correction leaves something behind: a test, a rule, a script, a documented decision, a reusable pattern, or a piece of project memory. The agent is not simply completing the current task; you are gradually constructing the environment in which the next task can complete correctly. This resembles training a new team. Doing the work yourself may be faster today, but it teaches nobody and builds no additional capacity.
The difficulty is that the target keeps moving. As the project grows, dependencies accumulate, the architecture hardens, and earlier decisions sometimes need to be rewritten. The agents are improving at the same time the system is becoming harder to change. Progress comes through repeated cycles of building, breaking, correcting, and encoding what was learned.
Then the experience begins to change. Gradually, the agents anticipate how the project should work. They plan within its architecture, reuse the right components, run the right validations, and repair failed loops. Routine features begin arriving complete enough to move directly into staging or a controlled production path. What once required constant supervision starts to flow.
Reaching that point can take time on a serious project. The early friction is not necessarily evidence that the model has failed; often it is the cost of building the agentic team around the codebase. The first stage feels slow because you are doing two jobs at once: building the product and building the system that will eventually build the product.
When you reach escape velocity.
This is the point at which the experience becomes difficult to explain to someone who has not felt it. You see a feature in another product and send the agent a screenshot. A customer asks for something during a call. An idea occurs to you and you describe it in a few sentences. The agents already understand the architecture, product language, design system, tests, and path to production. They can plan the change, build it, validate it, repair what fails, and even deploy it directly to production, often behind a feature flag or to a trial group. In most cases, it just works.
You are not trusting the model blindly. You are trusting everything you built around it: the accumulated context, rules, tests, scripts, architectural boundaries, and hundreds of previous corrections now encoded in the project. The difficult decisions have already been made and preserved. What once required repeated explanation has become part of how the system works.
That is what defines the escape-velocity moment: when you can one-shot a complex feature. The agentic team carries it through architecture, implementation, validation, and deployment with little intervention. The acceleration is no longer limited to writing code faster. The entire loop from intent to production has changed.
The Transition Cost.
Some people will not make the transition. This is real, and the organization should not pretend otherwise. A data scientist of eight years quit to become a Torah scribe, feeling AI had surpassed his capabilities. An engineer left to help his father’s hardware store. The performance-theater pattern – claiming “I’m 90% AI” while the instrumentation shows near-zero token spend and no parallel agent sessions – is its own quiet form of refusal.
These are not failures of the conversion program. They are the conversion program working honestly – separating who can adapt from who cannot, with fair support but without indefinite tolerance. The companies that struggled most allowed legitimate caution to become permanent shielding, or allowed Resistant clusters to set the pace under cover of “we’re being thoughtful.” The companies that moved hardest named the standard, gave fair support, measured the conversion, and held the line. None of which is costless: a mandate lands hardest on people whose careers were built on the skills it discounts, and the leaders who came through it best said so out loud rather than calling it an opportunity for everyone. Training them is both fair and the only route that scales – the talent to replace an engineering org wholesale does exist, but not in the numbers or at the speed a conversion needs. Say early who has no seat in the new shape. Done badly, the cost is the quiet loss of the people you meant to keep.
AI in the Product: Defense and Dividend.
Converting the engineers you already have is half the work; the other half is building the capability – and the magnet for talent – that makes the conversion stick. The most powerful single move in the study does both at once: an initiative to put AI into the product itself. Almost every company has one, and not as a feature – the alternative is watching their own software become the legacy in real time.
The threat is not that competitors will ship faster. It is more fundamental: the product itself is becoming the legacy. A general-purpose agent with a single domain skill can now do what an entire specialized SaaS used to do – the HR analytics product, the BI tool, the niche CRM, the form builder are each one prompt away from being a 50-line skill on someone’s agent platform, and customers are beginning to choose the agent. This is the Innovator’s Dilemma in its purest form: the specialized software you built the company around is exactly the thing that gets disrupted. The study companies that have absorbed this are racing to cannibalize their own products – to ship the AI-native version of what they sell before a competitor (or a horizontal agent platform with a domain skill bolted on) does it for them.
The response across the study is near-universal.
Almost every company in the study had a named, funded initiative to embed AI into the product layer. The shapes vary:
Agent-as-primary-user. One late-stage SaaS company spun up an “agent experience” team whose job is to make the company’s platform usable by AI agents – text-based interaction, indexing, search, MCP integration, semantic layers, rate limiting tuned for agent traffic. The implicit acknowledgment: agents are now a real share of the platform’s users and need a deliberately designed surface.
AI as the product’s analytical brain. One mid-stage marketplace is building a
“trusted analyst” experience that gives its customers AI-driven insight on their own data –
explicitly framed as a moat against AI-native competitors entering the same market.
Whole product is the agent system. The AI-native companies in the study skip the
integration question because their products are agents already – agentic content generation,
agentic operations, agentic customer support.
AI plus the security wrinkle. One small AI-native company in a security domain
flagged that integrating AI into a security product creates a new attack surface – prompt
injection becomes a real risk. The AI-in-product team and the security team converge.
The compounding dividend.
Investing in AI-in-product pays back across multiple dimensions at once, which is the under-appreciated case for treating it as a top-tier initiative rather than a side project.
The team becomes the org’s AI center of excellence. The people shipping AI features in production are solving the hardest real-world AI problems – model evaluation, failure modes, eval suites, prompt injection, cost-per-inference, what to expose versus what to abstract. That expertise then leads the rest of the company’s adoption: the team that “sells AI” understands AI better than the team that only “uses AI.”
It is usually greenfield. A new product, a fresh codebase, no legacy to defend. The AI-in-product team can move at a speed the rest of the org can’t match – and that speed becomes proof of what’s possible, which is itself a conversion tool for the slower-moving parts of the organization.
It is a talent magnet. The most AI-curious engineers and PMs want to work on AI projects. Having an AI-in-product initiative gives the company a recruiting story for exactly the AI-native talent this transformation runs on – and a place to put the people you most want to hire once you have them.
In short, the same investment defends against the Innovator’s Dilemma and builds the institutional AI literacy that makes converting everyone else far easier. The study companies that moved earliest on AI-in-product are visibly ahead on AI everywhere else too.
The agility dividend: faster delivery changes what you can sell.
There is one more dividend, and it is strategic rather than internal. The classic SaaS posture – “we ship one product, you adapt to it,” and “that’s not on the roadmap” – was a financial position, not a product opinion: engineering capacity was scarce, every customer-specific feature pulled engineers off the roadmap, and the only profitable shape was one-to-many. Once a single engineer with an agent fleet can ship a customer-specific capability in a day, that cost wall is gone, and “that’s not on the roadmap” becomes “that’s a two-day pull – we’ll have it Friday.”
That agility opens business-model moves that were previously uneconomic, each now being tested across the study: a more responsive product (the threshold for accepting customer requests for enhancement drops); a bespoke custom-agent layer on top of the one-to-many core, priced on outcome rather than seats; and the deepest, outcome-as-a-service: selling the resolved ticket, the completed review, the closed conversation, with the customer never logging into a UI. That direction is already visible in the forward-deployed-engineering ventures both frontier labs stood up in 2026 – Anthropic’s Ode, a joint venture with Blackstone and others, and OpenAI’s majority-owned Deployment Company – small teams that embed with a customer and build a bespoke agentic workflow against its data. The risk for the incumbent is blunt: if it doesn’t make the move, a horizontal AI provider delivers the outcome directly, and owns the relationship.
Plot your distribution, and see where the study sits.
With Part II behind you, the deliverable is your own four-axis polygon: the four clusters as axes, percentages summing to 100. The shape that emerges is your conversion picture – and it tells you which playbook to run next.
Aggressive cutover. Believer-heavy after a mandated weekend switch (100% agentic within two months); the Resistant cluster shrank after performance-review consequences and exits.
Broad rollout, uneven depth – half the heavy token consumers show no productivity gain (measurable performance theater). Guardians sat on a coupled monolith; modularization became a 2026 OKR.
Guardian-heavy by structure: small new teams at 100% AI-native; the 200+ engineer team on an eight-year, multi-million-LOC codebase at ~20% (documented with context files first). 280 hires frozen, AI-fluent funnel only.
Plot your own shape honestly. Where your weight sits heaviest is the playbook to run first – Believer-heavy → visibility and pressure; Tool-User-heavy → a ticket-to-PR mandate; Guardian-heavy → diagnose architecture vs. identity. Expect the shape to move; re-plot every quarter.
Once people are converted, the organization itself becomes the bottleneck.
Once engineers can orchestrate agents from intent to implementation in hours, old planning loops, PM handoffs, review processes, and team structures become the constraint. Engineering gets faster, but the company does not – which is the subject of Part III: Assemble the Community.