Open
Are you worried about your job?
If you are not, you should be. If you are, you should be preparing. If you are preparing, you are in the right place — the rest of this essay is dedicated to that pursuit.
This is not a soothing essay. It is not the kind of piece that ends with don't worry, it will all work out. It will not all work out for everyone. The shape of the next two years is already visible in the numbers — the team of fourteen that is now six, the implementation engagement that used to take three months and now takes three weeks, the close rate that has slid four points in the last two quarters even though pipeline is at an all-time high, the new graduate who has interviewed seven times and cannot get a call back. The fear is rational. The honest response to a rational fear is not denial. It is architecture.
This essay is for the technology consultant who runs Blueprint workshops on Tuesdays and Thursdays and lies awake on Wednesdays. It is for the senior engineer whose team was fourteen in 2024 and is six in 2026 and who is the one on call when something her team did not write fails in production at 4:30 on a Friday. It is for the account executive whose champion last week did not send a meeting agenda — she sent a Claude conversation summary in which the AE's company came in second. It is for the pre-sales architect whose carefully built POC is now being out-built in a weekend by the prospect themselves on Replit or Cursor. It is for the partner who has to explain to her board why utilization is up and revenue per consultant is flat. It is for the founder of a mid-market services firm who is twelve years in, profitable, and writing the firm's next-cycle strategy on her kitchen table at midnight because she knows the cost structure that worked through 2024 will not work through 2027.
If any of these descriptions made you flinch — keep reading. The flinch is the signal. What follows is the architecture for what to do next.
The cycle that everything we do is running through, faster than ever
Before the stories, a frame that the rest of the essay returns to.
Every piece of consequential work in modern life — building a product, running a campaign, writing a piece of software, structuring a deal, even raising a child or running a household — moves through a recognizable cycle. Discover what the problem actually is. Design the response. Build the response. Test the response against reality. Deploy the response into the world. The cycle is old. Engineers, consultants, marketers, surgeons, generals, and parents have all run versions of it for as long as people have done deliberate work.
What has changed, in the world we are living in right now, is the cycle's cadence. The five stages have shrunk dramatically, and the boundaries between them have dissolved. A team that would have run one cycle in eighteen months in 2018 is now expected to run a cycle in three weeks, sometimes three days. The discovery happens while the building is already in motion. The testing happens continuously rather than at the end. The deployment is not a moment but a stream. The cycle does not end with deployment, because the deployment generates new discovery — what the world does with the thing you built becomes the input for the next cycle, which is already starting before the current one is finished.
This is the operational pattern that has redefined how successful organizations work. It is also, and this is the part most people have not internalized, the operational pattern that has redefined how successful careers work.
The career model most of us grew up with was a single very long cycle. Discover what you wanted to be — a process that took most of childhood and adolescence. Design a path toward it — university, perhaps graduate school, an apprenticeship of some kind. Build your capability over the first decade of work, gradually accumulating experience and reputation. Test the path through promotions and lateral moves and the occasional job change. Deploy yourself into the senior role you had been preparing for, where you would remain for the second half of your working life. One cycle. Forty years.
That model is almost entirely gone. The careers that succeed in 2026 are not built on one long cycle. They are built on the same compressed, iterative pattern that has redefined how products and software and businesses get built. The successful career of the next two decades runs the discover-design-build-test-deploy cycle continuously, at a cadence that would stagger the people who taught us how to work. New tools emerge — new cycle. Regulations change — new cycle. The labor market shifts — new cycle. Your industry consolidates — new cycle. Your firm's strategy pivots — new cycle. Your own skills depreciate in some places and appreciate in others — new cycle.
The employee of the future is not someone who has discovered and designed once and is now deploying for the rest of their career. The employee of the future is someone who can iterate through the full cycle in a quarter, in a month, sometimes in a week — and who treats that iteration not as a disruption to be endured but as the actual shape of the work.
That is what this essay is trying to teach. Not how to find one safe spot to land. There are fewer of those, and the ones that exist are temporary. What to teach is how to run the cycle. How to compress discovery so that you can detect what has shifted before your peers do. How to compress design so that you can sketch a response in days rather than months. How to build the response with the tools that have made building cheaper than at any point in human history. How to test it against reality quickly enough to learn before your assumptions ossify. How to deploy your new posture before the window of advantage closes. And then, immediately, how to start the next cycle, because the world will have shifted again while you were running the last one.
The fear of losing your job is, at its heart, the fear that you ran one cycle a long time ago and that the deployment phase you have been living in is ending. That fear is not wrong. The deployment phase is ending for most people, sooner than they expected. The response is not to find another long deployment phase. There may not be one. The response is to learn to run the cycle continuously, deliberately, at a pace that compounds.
The rest of this essay, including the seven stories that follow, is held together by that pattern. Each story is a person caught somewhere in the cycle — sometimes mid-deploy with no next cycle planned, sometimes mid-discover with no design ready, sometimes iterating fast but on the wrong axis. The analysis after the stories names the pattern across them. The architecture after the analysis is how to build a career and an organization that runs the cycle as a discipline rather than enduring it as an interruption.
Hold the frame loosely as you read. It will return.
Seven stories from the last twelve months
These are not from interviews conducted for this essay. They are from conversations I have been having continuously, in the work I do every week, across an industry in real-time disorientation. The details have been anonymized far enough that nobody in any of them is identifiable. The shape of each story has been left intact.
Story one: The engineer who shipped the bug
She is a principal engineer at a regional bank, fifteen years in, three of them at this institution. Her team was fourteen people in early 2024. The bank, like many regional banks, made the calculation in mid-2025 that AI coding tools would multiply productivity sufficiently to absorb a 50% reduction in engineering headcount. She was told her team would be six, and the multiplier would close the gap. She believed it, more or less. The tools were genuinely capable. The team that remained was strong. The work could be done.
The bug shipped on a Friday afternoon. It was in code generated by an AI agent — they were using a combination of Cursor for in-IDE work and Claude Code for the larger tasks — and it had been reviewed, by her, in the rush before a release. The tests had passed. The tests had been written by the same agent that had written the implementation. Nobody on the team had read the test cases line by line, because that was the work the agent was supposed to absorb. The bug was a subtle one in the way the system handled a particular kind of customer record that had been in the database since 1997. The production incident hit at 4:30 PM Eastern. The on-call alert hit her phone. The post-mortem went on her record.
The lesson she carries — and the lesson she has been trying, without much success, to articulate to her remaining team — is that she is now accountable for code she did not write, in volumes she cannot fully review, with tests she did not author validating logic she did not author. The accountability did not shrink with the team. The capacity to discharge that accountability did.
She does not know what to call her job anymore. She is something between a senior engineer and a quality auditor. The title on her business card has not changed. The work has.
She is, in the cycle's terms, stuck in a deployment phase that ended without her noticing. The cycle that produced her — discover what kind of engineer to be, design the path through systems work, build the capability over fifteen years, test it through harder and harder assignments, deploy into the principal role — closed years ago. She has been operating in deploy mode for three of those years, with no new cycle initiated. The bug on Friday was the world telling her that the deployment was no longer covering the work.
Story two: The consultant whose apprenticeship closed
He is a senior manager at one of the global consultancies, eleven years in. His track was clean — analyst, consultant, senior consultant, manager, senior manager — and he was on the road to partner. The work he came up doing was document review, summary memo drafting, board-deck construction, and competitive landscape analysis. Those tasks were not glamorous, but they were the apprenticeship. The juniors learned the firm's standards by doing the work badly, then less badly, then well. By the time they were senior consultants, they knew what good looked like at the firm because they had spent four years producing approximations of it.
By the end of 2025, his firm had absorbed those tasks into an internal AI tooling stack — built partly in-house, partly on top of foundation lab partnerships. The output was good. Not as good as a senior consultant's, but better than a first-year analyst's first try, and produced in minutes instead of weeks.
The partners are pleased with the margins. The senior manager is the only person on his floor who still knows how the work is supposed to be taught. He is working sixty-hour weeks, partly running engagements, partly training the AI tools the firm bought. The juniors who were hired — fewer than in any year of his career — come to him uncertain about what their next promotion looks like. Several have asked him whether the senior consultant rung still exists in any meaningful sense. He has not given them a clear answer because he does not have one.
The apprenticeship that produced him does not exist for them. He is the last cohort that came up through it. He is not sure who is going to teach the next set of consultants what the firm's standards are, because the AI tools have flattened the work that used to be the teaching.
In the cycle's terms, his firm has compressed five years of build phase into a tool. The juniors do not have the build phase he had. They are being asked to deploy without having built. The senior manager's instinct — the one he has not articulated yet — is that the firm needs to redesign the build phase entirely. Not bring back the old work. Build a new kind of apprenticeship that produces consultants who can run their own cycles inside the firm. That redesign is the next cycle of his career. He has not started it yet because he is busy running engagements in the old one.
Story three: The account executive whose champion used Claude
She closes enterprise software deals in financial services. The deal in question was a four-million-dollar annual contract with a North American bank. She had been working it for nine months. Her champion was a senior director of platform engineering; she had built the relationship carefully, knew his board, knew his architecture priorities, had walked him through three live demos with her solution architect.
The summary came in by email on a Tuesday morning. Fifteen pages. Champion's review of vendor finalists for [project name]. The summary compared her firm's offering against two competitors against the bank's RFP. It picked up details she had not surfaced — capability gaps in her platform, specific objections from past customers, even a careful read of her vendor's most recent S-1 disclosures about customer concentration risk. Her firm came in second.
She knew immediately that the summary had been generated by the champion's own Claude session. The structure was unmistakable. The level of detail across competitors was beyond what a single human could produce in a workweek. The champion had not lied. He had used a tool, the same way he might have used a market research firm — except this tool had run in an afternoon and had been thorough in a way no contracted research firm would have been thorough for a deal of this size.
She had two weeks to flip the deal. Her instinct was to attack the comparison — find the place where it was wrong. The comparison was largely right. Her actual move, when she made it, was to escalate above the champion to the CIO and reframe the decision: not which platform's feature set scored higher on the RFP, but which platform's architecture would still be defensible to the bank's regulators in 2028. She won the deal. The mechanism that won it was the architecture conversation, not the feature comparison.
She has been thinking about what this means for every other deal in her pipeline. Every champion in every account she works is, by 2026, running the same kind of comparison. The differentiator she now has to bring is not a better demo. It is a conversation the AI cannot have on the customer's behalf — the one about consequences in 2028.
In the cycle's terms, she ran a full discover-design-build-test-deploy iteration in two weeks. The discovery was the summary email. The design was the move to escalate above the champion. The build was the architecture conversation she had to be able to hold credibly. The test was the CIO meeting. The deployment was the close. Two weeks. The cycle her predecessors ran over nine months, she now has to run over fourteen days, and she has to do it every time a champion sends a Claude summary. That cadence is the actual job.
Story four: The pre-sales engineer whose POC got out-built
He is a principal solutions architect at an enterprise software vendor. His specialty is building custom proofs-of-concept for top-25 accounts in regulated industries. A POC, for the reader unfamiliar with the term, is the working demonstration a vendor builds during the sales cycle to show a prospective customer that the platform can actually do what the sales deck claims. POCs used to take him three to four weeks of focused work, often with two or three engineers helping.
In the most recent engagement, the prospect showed up at the second meeting with a working prototype. Built in two evenings over a weekend, by a senior engineer on the prospect's team, using Replit and a Cursor session against the publicly available API documentation for his firm's platform. The prototype did about seventy percent of what the official POC would have demonstrated. It was not as polished. It missed some of the orchestration the platform handled. But it was running, and the prospect had built it with no support from him at all.
He was both proud and shaken. The prospect's engineer was sharp; he had read the documentation carefully; the AI tools had let him compress what would have been a month of part-time learning into a weekend of guided exploration. The shake was that the prospect's engineer now understood the platform at a level that — three years ago — would have required the architect's own help to reach. The architect's differentiator was supposed to be deep platform knowledge. The platform, in part, now teaches itself.
The architect spent the third meeting not demonstrating capability but explaining the limits of the prototype the prospect had built — where it would break at production volume, where the security model was insufficient, where the audit trail would not pass a regulator's review. The conversation he had to be able to hold was no longer here is what the platform can do. It was here is the architecture this prototype is missing and why the missing pieces matter at the scale you actually run.
That conversation is harder, more senior, and less repeatable than the demo he used to give. It is also less staffable — there are fewer people in his firm who can hold it credibly. He has been talking to his manager about whether his job description has effectively changed without anyone changing it.
The prospect, in this story, ran a discover-design-build-test cycle in a weekend. The architect's response was a new discovery — that the value he adds is no longer in the build phase but in the test-against-reality phase. He has to run his own cycle now: redesigning his contribution around the architecture conversation, building the depth he needs to hold it, testing it on the next several deals, deploying a new pre-sales motion before his firm formally redefines the role.
Story five: The architect whose diligence got automated
She is a solutions architect at a global system integrator, eight years in, with a specialty in legacy modernization assessments for financial services. Her career was built on a particular deliverable: the comprehensive technology assessment report, sixty to eighty pages, that her firm produced for enterprise customers at the start of a multi-year modernization engagement. The report was rigorous. It involved interviews, code surveys, architecture diagrams, dependency analyses, and a forward-looking modernization roadmap. It took six to eight weeks. The firm charged in the high six figures for it.
Her firm's internal AI practice released a tool in late 2025 that produces the first draft of the assessment in forty-five minutes. The tool reads the customer's repository, ingests architecture documentation, runs automated dependency analyses, and generates a sixty-page assessment that follows the firm's template. The output is not as good as her assessment. It is better than her assessment from three years ago. It is also better than the assessment most of her firm's mid-level architects would produce on their own.
Her partner has asked her to review and add value to the tool's output. She has spent the last three engagements trying to articulate what value she is supposed to add. The honest answer is that she adds judgment — the moments where the tool's recommendation is technically correct but politically infeasible, the moments where the right modernization path requires a sequencing the tool cannot see because the sequencing depends on the customer's CIO retiring in eighteen months. Those moments are real, but they are also harder to defend on a fee structure that previously was justified by the volume of the report. The customer does not see them in the deliverable. They see them in the engagement.
Her firm has not yet figured out how to price judgment when the report is mostly free. She has not yet figured out how to make her professional contribution visible when the artifact that used to demonstrate it is now generated automatically. The two problems are the same problem.
The firm has compressed its build phase. The deploy phase — the engagement itself, the relationship across eighteen months, the moments where the architect's judgment changes the modernization sequence — has not been compressed. It has, in fact, lengthened in importance. The architect's redesign is to migrate her professional identity from the build phase, where she used to be measured by the report, to the deploy phase, where she is measured by the engagement's outcome. That migration is a career-level cycle, and she has not yet committed to running it.
Story six: The founder rewriting the firm at midnight
She built her services firm over twelve years. Eighty people, mostly engineers and consultants, doing implementation work for mid-market financial institutions. The firm is profitable but not growing as fast as the market. She has comfortable runway and a twelve-to-eighteen-month window to reshape the firm around AI-augmented delivery before larger competitors move into her segment with structurally better cost positions.
She has to decide what the firm looks like at the other end of the window. The decision is the hardest of her career, harder than the founding decisions, because the performance data does not help her. The high performers under the old model — the people who could deliver a thirty-page assessment in five days — are not necessarily the people who will deliver under the new model, where the assessment is forty-five minutes and the differentiator is judgment about edge cases. The seniority charts do not help. The compensation data does not help. She has talked to three consultancies; each has told her a different answer; she has noticed that each answer aligns with the consultancy's own commercial interests.
She has started building her own framework, mostly by writing it down at her kitchen table after her kids go to bed. The framework is not about who has performed well in 2024. It is about who can specify a problem clearly, who can hold the line on the work that should never be delegated to an agent, who can build internal tooling that compounds rather than internal tooling that ages quickly, who can teach the next set of consultants when the apprenticeship has been hollowed out. She has noticed, working through the framework, that several of her most senior people score poorly. She has noticed that some of her most junior people, the ones who joined in 2024 and 2025 and grew up with the tools, score well.
She does not know what to do with the discrepancy. The compensation and title structure of her firm does not match the capability structure that her framework reveals. She has not yet told anyone what she has been writing.
The founder is running a discover-design cycle that the firm's organizational structure was not built to receive. Her discovery is honest. Her design is forming. The hard part will be the build and test phases — restructuring the firm, reassigning compensation, redrawing reporting lines — inside the window before the market reshapes around her. The founders who run this cycle deliberately, and who run it before the window closes, are the founders whose firms emerge intact. The founders who delay are the founders whose firms are absorbed in 2027 at multiples that do not reflect the work the founders thought they had built.
Story seven: The junior who cannot pass the interview
She graduated in 2025 with a computer science degree from a strong state school. She did the things she was told to do — co-op rotations, an internship at a respectable enterprise software vendor, a personal portfolio of projects, contributions to two open-source repositories. She studied the interview prep books. She practiced.
The first technical interview she did after graduating, the interviewer noticed she was using Claude during the live coding portion to help her think through a recursive algorithm. The interviewer marked her down for it; the post-interview feedback was that she did not demonstrate independent problem-solving. She adjusted. The second interview, she did not use AI. The interviewer marked her down for being slower than another candidate who had used Cursor's autocomplete throughout the session and finished fifteen minutes early. The post-interview feedback was that she did not demonstrate adaptive tool use. She kept adjusting. The third interview, she tried to balance — using AI for the parts where it was clearly appropriate, working independently for the parts where she thought the interviewer would expect it. The feedback was that her approach seemed inconsistent.
She is seven interviews in. She has not been offered a job. She is starting to suspect that the interview process itself does not know what it is testing for. The recruiters cannot tell her the rule because the rule has not been established. The bar has moved between 2024 and 2026, and the candidates ahead of her in line are competing against tools, while the candidates judging them are still calibrated to an older standard. She is in the in-between cohort — the one that paid full tuition for a four-year degree that was specified by an industry whose hiring practices have not yet absorbed the implications of the same tools the industry is selling.
Her father is a software engineer. He has been doing this for thirty years. He has had no useful advice for her, because the situation has no precedent in his career.
The cycle that produced her father took thirty years. The cycle she is being asked to run, before she has even landed her first job, is one she has to figure out for herself, in real time, with the rules changing between interviews. Her redesign is to stop optimizing for the next interview and start optimizing for the career model where she runs her own cycles deliberately. The companies that will hire her are the companies that have figured out what they are testing for. There are some. They are rare. The ones that have figured it out are testing for the ability to run the cycle — to specify, build, verify, and adjust — not the ability to perform a 2018-era coding exercise under 2026 conditions.
The pattern across the stories
The seven stories are not the same story. They sit at different points in a career arc, in different industries, with different specific pressures. The pattern across them is what matters.
In every one of them, the work itself has not gone away. The bank's regulator still wants a defensible explanation for the production bug. The consulting firm's clients still need the work the senior manager used to teach his juniors. The bank's CIO still has to choose a vendor. The prospect still needs an architect to explain why their weekend prototype will not pass a 2028 audit. The global integrator's customer still needs a modernization roadmap. The founder's clients still need someone to deliver. The new graduate's potential employers still need engineers.
What has changed is the shape of the work, and the cadence at which the cycle runs through it. The work has migrated upstream and downstream from where it used to live. Upstream, it has migrated toward specification — the work of describing clearly what needs to happen, what success looks like, what failure looks like, what counts as acceptable, what cannot be tolerated. That is, in the cycle's vocabulary, the work of discovery and design, compressed into hours where it used to take weeks. Downstream, it has migrated toward verification — the work of confirming that what was produced is actually what was needed, that it works, that it is safe, that it is defensible, that the consequences of releasing it will not destroy what came before. That is the work of test and the early phase of redeployment-after-learning, also compressed. The middle — the production of the artifact, the build phase in its older sense — has been compressed dramatically, sometimes to seconds, sometimes to minutes, sometimes still to days but with one person doing what used to require five.
This compression is not symmetric across the cycle. The discover-and-design end has gotten harder, not easier, because the cost of a poorly specified task has gone up. Before, a vague brief would produce a vague draft, and the iteration would happen during the work. Now, a vague brief produces a confident draft that is wrong, and the iteration is more expensive because the wrong draft has already consumed the budget and the schedule. The test-and-redeploy end has also gotten harder, because the volume of artifact has gone up and the depth of independent understanding by the verifier has gone down. The person reviewing the artifact often did not produce it and cannot reproduce it. The signature on the review is now more consequential and less informed than it used to be. The build phase has not vanished. It has been pulled out as a separate, increasingly automated capability. The skill of producing the artifact — writing the code, drafting the memo, building the POC, generating the report — is now a tool feature, available to anyone, and therefore not, by itself, a defensible career.
The defensible careers are the ones that operate at the upstream end (discovery and design, specification, problem framing, judgment) or the downstream end (test, verification, governance, accountability, learning into the next cycle) or that hold the seam between them. The defensible careers are also, separately, the ones that have learned to run the entire cycle more times in a year than their predecessors ran it in a decade. Both shapes — operating at the ends, and iterating the whole cycle faster — are real, and they are usually combined in the same person.
The implications follow.
For the engineer, the skill that has appreciated is the ability to read code rigorously — to understand what an agent has produced and why it might be wrong — and to specify acceptance criteria clearly enough that the agent's output can be evaluated. Those are test-phase and discovery-phase skills, respectively, expressed in the engineering vocabulary. The skill that has depreciated is the ability to type code quickly, which was the build-phase skill in its older form. The middle work has been absorbed by tooling. The cycle still runs through the engineer; the engineer's contribution has migrated to the phases the tools do not yet do well.
For the consultant, the skill that has appreciated is the ability to frame a problem clearly before solving it, and to hold the client's intent across multiple sessions and decision points. Those are, again, discovery-phase and integration-across-cycles skills. The skill that has depreciated is the ability to produce polished deliverables on schedule, which was the build-phase skill. The deliverables are produced by tools. The framing and the holding of intent are produced by people, and they are the kind of work that requires running a smaller discover-design-build-test-deploy cycle every week of a long engagement, where the framing gets refined as the engagement learns more about itself.
For the seller, the skill that has appreciated is the ability to have the architecture conversation the customer's AI tools cannot have on the customer's behalf — the conversation about consequences, about regulatory exposure in 2028, about the way the wrong choice now compounds into an architectural problem later. That is a deploy-phase skill in a particular sense: it is the conversation about what happens after deployment, projected forward. The skill that has depreciated is the ability to walk a prospect through a feature comparison, which was the build-phase equivalent in the sales motion. The prospect has run the feature comparison themselves, in a Claude session, before the meeting. The seller who survives is the one running her own continuous cycle alongside the customer's — sensing what has shifted in the prospect's posture, redesigning the deal motion, building the new architecture conversation, testing it in the next meeting, redeploying her own approach with what she learned.
The pattern is the same across the three roles, expressed in different vocabulary. The middle has been compressed. The ends — discovery and design upstream, test and re-learning downstream — have appreciated. The cadence at which the whole cycle runs has accelerated. The careers that survive will be the ones that consciously migrate toward the ends and learn to run the cycle continuously, not the ones that compete for what is left of the middle while running one slow cycle at a time.
The organizations that survive will be the ones that redesign around the new shape and the new cadence, rather than bolting AI onto the old shape and hoping the productivity gains absorb the compression. The redesign is the work of the rest of this essay.
The org of the future, in plain terms
If the middle has been compressed and the ends have appreciated, the organization of the future is the one that explicitly staffs and resources the ends. That sounds tautological. The implications are not.
The org of the future has more specifiers than the org of 2023. A specifier is the person who takes ambiguous business intent — we need to reduce false positives in our fraud detection or we need to onboard middle-market customers faster — and translates it into work that can actually be assigned, verified, and held accountable. This is the org's discovery-and-design function, made primary. It used to be a partial responsibility of senior consultants, product managers, business analysts, and architects. In the new shape, it is a primary discipline, with its own training, its own deliverables, its own measurement. The specifier writes the acceptance criteria the agent works against. The specifier writes the definition of done the verifier checks. The specifier holds the seam between the messy intent and the bounded task. Their work is the most senior and the least visible. Their failures are also the most expensive, because a poorly specified task scaled across an agent fleet produces a large volume of wrong-but-confident artifact.
The org of the future has more verifiers than the org of 2023. A verifier is the person who reads what was produced, runs it against the test cases, audits its lineage, and decides whether it can be released into the world with the firm's name attached. This is the org's test-and-learn function, made primary. It used to be a partial responsibility of code reviewers, QA engineers, compliance officers, and partners signing deliverables. In the new shape, it is also a primary discipline, distinct from the production of the artifact. The verifier did not produce what they are signing. They have to be capable of independently re-deriving why the artifact is right. The skill they need is closer to that of an auditor or a senior reviewer than to that of an author. The mistake organizations make is asking the same person to both produce and verify, on the assumption that production and verification are the same activity. In the AI-augmented org, they are different activities, with different cadences, often best done by different people.
The org of the future has fewer middle-producers than the org of 2023. This is the hard part. The middle-producer — the person whose primary contribution was the production of polished artifact at scale — is the role that has been compressed, and the honest reading is that there will be fewer of them. Not zero. There will always be cases where the artifact is too sensitive, too novel, or too proprietary to delegate to an agent. But the headcount of middle-producers will not return to 2023 levels in most organizations, and the organizations that pretend otherwise are accumulating compensation expense they cannot defend on a productivity basis.
The org of the future has more skill authors than the org of 2023. A skill author is the person who writes down, in a form an agent can use, how this organization does this kind of work. The skill, in the sense established by Anthropic and adopted across the agent ecosystem, is the institutional memory packaged for reuse. The org that has fifty good skills covering its core delivery work has compounding leverage across cycles — every new cycle starts from the accumulated learning of the previous ones, rather than from a blank prompt. The org that has none restarts the build phase every time. Skill authorship is its own discipline; it requires both deep domain understanding and the discipline to articulate the work in a way that survives review. The skill authors in an organization tend to be among its most senior people, because the skills capture not just the what but the why, and the why lives in judgment.
The org of the future has more governors than the org of 2023. A governor is the person who decides what the system is allowed to do unsupervised, what triggers escalation, what falls under regulatory or ethical constraint, what is the firm's standard, what is the firm's red line. This used to be a partial responsibility of legal, compliance, risk, and senior leadership. In the new shape, it is a primary discipline with technical depth — the governor has to understand the architecture well enough to know where the bounded-agent constraints live, where the audit trail is generated, where the saga compensating actions fire, where the human-in-the-loop gates are placed. The governor's work is what makes the agent fleet defensible to a regulator, an auditor, a court, or a customer. It is also what makes the cycle's redeployment phase safe — what makes it possible to ship into production at the accelerated cadence the rest of the firm is running, without producing the regulatory event that would force the firm into a defensive cycle nobody wants to run.
The org of the future has different sellers than the org of 2023. The seller of 2023 was, at her best, a translator — between the customer's stated need and the vendor's product capability. The seller of 2026 has to be a translator at a higher altitude — between the customer's stated need, the customer's own AI tooling that has already done a feature comparison, the vendor's product capability, and the architectural consequence of choosing one path over another in a five-year window. The seller of 2023 closed by reciting a feature set. The seller of 2026 closes by holding the conversation about 2028 — the conversation the customer cannot have with their own Claude session because Claude does not have the customer's specific risk posture, regulatory environment, or political timing in mind. That conversation is more senior, more dependent on judgment, and harder to script. The orgs that have not yet started retraining their sellers for it are already losing deals they do not realize they are losing.
The org of the future has different operators than the org of 2023. The operator is the person who runs the production system on the days nobody wants to think about — the Friday afternoons, the holiday weekends, the audit visits, the unexpected drift events. In the AI-augmented org, the operator has to monitor not just the system but the model providers underneath it. Did Anthropic ship a new model? Did our calibration drift overnight? Did the active golden set need to be updated because our prompt patterns started catching on a new pattern of customer data? The operator's work is now part-time AI ops, part-time site reliability engineering, part-time data quality, part-time vendor management. The skill set is broader than what most ops roles were defined for in 2023, and the organizations that have not yet upgraded their operator function are operating in production with a 2023 monitoring stance on a 2026 system.
Across all of these — specifier, verifier, skill author, governor, seller, operator — the pattern is the same. The work that used to be partial and shared has become primary and distinct. The careers that survive the compression are the ones that consciously claim one or more of these primary disciplines and become genuinely good at them. The orgs that survive the compression are the ones that staff for these primary disciplines explicitly, with titles, with training, with measurement, with promotion paths that reward the work the org actually needs.
That is the org of the future. It is not science fiction. It is not utopian. It is a recognizable adjustment to the new shape of work and the new cadence of the cycle, made by leaders who have done the honest accounting of what is left in the middle and what has appreciated at the ends.
The harder question is how to staff it from where you are.
What kind of engineer the org of the future needs
The engineer the org of the future needs is not the engineer who can type code faster than other engineers. That competition is over. The engineer who types code faster is competing against an agent that types code faster than any human, and the engineer is going to lose that race on every dimension that matters except cost — and the cost differential is moving in the wrong direction every quarter.
The engineer the org of the future needs has four primary skills, each of which has appreciated relative to where it was in 2023. They map cleanly to the cycle.
The first skill is the ability to read code rigorously. By rigorously, I mean the ability to take a pull request — written partly or wholly by an agent — and identify what the code actually does, what assumptions it is making, what failure modes it embeds, what tests would catch which failures, what the system's behavior will be at the edges the test cases do not cover. Reading code rigorously is harder than writing code, has always been harder than writing code, and is the skill that distinguishes senior engineers from junior engineers in every organization I have worked with over the last fifteen years. In the AI-augmented org, the ratio of code-being-read to code-being-written-by-this-engineer has gone up by an order of magnitude or more, which means this skill has appreciated by an order of magnitude. The engineer who can read three thousand lines of agent-generated code on a Monday morning and articulate what is wrong with eleven of them is more valuable than the engineer who can write three thousand lines on the same Monday. This is the test phase of the cycle, made primary.
The second skill is the ability to specify clearly. The engineer who can take a Jira ticket that says the dashboard is slow and turn it into a working specification — here are the queries we are running, here is the volume profile, here are the acceptance criteria for slow versus acceptable, here is the test we will write to verify the fix — is the engineer whose work the agent can actually do. The engineer who hands the same Jira ticket to the agent without doing the specification work first will get back an agent-generated answer that may or may not address the actual problem, and the iteration cost of figuring out which is the case will exceed what it would have cost to specify the problem cleanly in the first place. Specification is the discipline that makes the agent useful instead of expensive. Every engineer needs to develop it, at every level. This is the discover-and-design phase, compressed to hours and made primary.
The third skill is the ability to verify rigorously at the system level. This extends beyond code review into system-level verification — running the production-like test, instrumenting the canary, reading the telemetry, comparing the agent's output against the golden cases, deciding whether confidence in the system has actually been earned by the verification work or whether the team is signing off because the deadline is Friday. Verification, like specification, is a discipline. It can be taught. It is also where the engineering organization can compound — every well-verified pull request strengthens the test suite and the golden set, every poorly-verified one weakens them. This is the cycle's test phase extended through deployment and into the start of the next cycle.
The fourth skill is the ability to compose. By compose, I mean the ability to take agents, tools, APIs, skills, and humans and combine them into a working system that does what was actually needed. The engineer who can wire Claude Code to the team's MCP-compliant tool catalog, hook the agent's output to a structured verification step, route the human-in-the-loop gate to the right reviewer, and ensure the audit trail is captured cleanly — that engineer is doing the work of an architect in the AI-augmented sense, even at a mid-level title. The composition work is where the agent's raw capability becomes the org's deployed system, and the engineers who can compose well are the engineers whose work survives the next architectural review. Composition is what makes the cycle's deploy phase trustworthy at the pace the rest of the firm is running.
Across all four skills, the underlying disposition is the same: the engineer of 2026 is not primarily an author of code. They are an architect of systems that include agents as participants. The author of code is still present, sometimes, when the work is novel or sensitive or proprietary. But the primary identity has shifted. The engineer is the person who decides what the system needs to do, who reads what the agent produced against what was specified, who composes the system from agents and humans and tools, who verifies that it works before it ships. The engineer is also, increasingly, the person who runs this entire cycle continuously — small cycles, daily, against shifting team priorities and shifting tooling — rather than running one long cycle against a single project.
The implications for hiring follow.
The engineer to hire is not the one with the most LeetCode problems solved. It is the one who can walk into a code review and identify the three things that are subtly wrong about an agent-generated PR. The engineer to hire is not the one with the fastest typing speed in the live coding session. It is the one who, when given an ambiguous brief, asks the questions that would have prevented the wrong implementation. The engineer to hire is not the one who can name every framework. It is the one who has built and maintained a skill library — even a small one, even at a personal scale — because that engineer has internalized the discipline of writing down how the work is supposed to be done, which is the discipline of compounding learning across cycles.
The implications for training follow. The teams that are training their engineers on prompt engineering as the primary new skill are training the wrong skill. Prompt engineering is a tactical layer that will be reabsorbed into the tooling within twelve to eighteen months. The strategic layer is specification, reading, verification, and composition. Those skills compound. They survive the next model release. They are what makes an engineer's career durable into 2028.
The implications for the engineer reading this also follow. If you are an engineer who feels that the work has slipped out from under you, the most productive response is not to chase the newest tool. It is to invest deliberately in the four skills above, starting with whichever is weakest. Pick a pull request next week that an agent generated and read it as if you were the auditor. Pick a Jira ticket next week and write the specification before you let the agent see the ticket. Pick a test suite this month and audit whether it actually verifies what it claims to verify. Pick a system in your stack and map how the agents, tools, humans, and audit trails compose into the working whole. None of these requires a new tool. All of them, done deliberately over the next ninety days, will produce a noticeably more durable career. Each of them is a small cycle. The career is what those cycles compound into.
What kind of consultant the org of the future needs
The consultant the org of the future needs is not the one who can produce the deepest deliverable on the tightest deadline. That competition is also over. The deliverable the consultant used to write is now produced by an internal AI tool in forty-five minutes; the deadline that used to be six weeks is now a long weekend. The consultant who built a career on the speed and polish of artifacts is competing against the same tools their clients are also running, and the differential is shrinking.
The consultant the org of the future needs has four primary skills, parallel to but distinct from the engineer's. They also map cleanly to the cycle.
The first skill is the ability to frame a problem before solving it. The senior consultant of 2023 often arrived at a client engagement with a methodology — a five-stage approach, a maturity model, a transformation roadmap. The methodology produced the deliverable, the deliverable produced the engagement, the engagement produced the revenue. In 2026, the methodology is in the tool, the deliverable is the tool's first draft, and the consultant who arrives with a methodology and nothing else has nothing to add. The consultant who frames the problem before applying the methodology — who can spend two days at the client site listening, reading, asking the awkward question, and arriving at a problem statement that is more honest than the one in the RFP — that consultant has work to do that the tool cannot. Problem framing is the consultant's version of the cycle's discovery phase. It is older than consulting. It has appreciated.
The second skill is the ability to hold intent across multiple sessions and stakeholders. An enterprise modernization engagement has a CFO, a CIO, a CRO, a head of operations, a board, and a regulator, each with their own concerns, their own political constraints, their own time horizons. The consultant who can hold the engagement's intent across all of them — the consultant who, in week seventeen, can remember why the choice in week three excluded a particular path because of a comment the CRO made in week two — is doing the work of a senior advisor in the genuine sense. The tools do not hold intent. They produce artifacts against the most recent prompt. The consultant who holds intent is the one who keeps the engagement coherent across the seventeen weeks the tools cannot remember. Holding intent is what makes the engagement a single coherent multi-cycle program rather than a series of disconnected micro-cycles that drift away from the original problem.
The third skill is the ability to translate from organizational ambiguity into bounded problems an agent or a team can actually act on. This is the consultant's version of the specification discipline, sitting at the seam between discover-design and build. Most enterprise problems do not arrive specified. They arrive as we need to be more competitive on cost or the regulator is unhappy with our second-line risk function or we lost a deal to a digital-native competitor and we do not know why. The consultant's first job is to turn that into something a team can act on. The bounded problem is the thing the team — and the team's agents — can actually work against. The bounding is the consultant's contribution. The tooling that follows is faster than it used to be, but the bounding is upstream of the tooling and has gotten more valuable, not less.
The fourth skill is the ability to govern delivery, not just produce deliverables. The consultant of 2023 was often measured on what she wrote. The consultant of 2026 has to be measured on what was delivered into production — whether the system, the policy, the org change, the new operating model actually took root and produced the outcome it was meant to produce. Governance of delivery is harder than writing the deliverable, takes longer, and is less visible in the moment. It is also what the client increasingly buys, because the deliverable alone — the slide deck, the report, the recommendation — is increasingly producible by the client's own tooling. The consultant who can govern delivery is the consultant whose engagement does not get cut short when the firm's procurement team realizes the slide deck could have been generated for less. This is the deploy-phase work the AI tools have not yet absorbed and, structurally, may not.
The disposition the consultant of 2026 needs is the disposition of a senior practitioner, regardless of title. The work that has appreciated is not the work that used to be done by managers; it is the work that used to be done — partially, intermittently, often informally — by partners. The org of the future needs more partners, in the working sense, than the org of 2023, and the consultants who survive will be the ones who develop partner-grade skills earlier in their careers than the firm's promotion structure expects.
The implications for hiring are clearer than for engineers. The consultant to hire is the one who can frame a problem in the first ninety minutes of an engagement that the client's own people had been talking around for six months. The consultant to hire is the one who, when asked about the methodology, talks about the engagement and not the deck. The consultant to hire is the one who has held a piece of work to completion in production, against client and political resistance, not just the one who can describe what should happen in theory.
The implications for training are also clearer. The firms that are training their consultants on AI tooling as the primary new skill are training the wrong skill. The tooling is already absorbed into the firm's offering. The strategic skills are framing, holding intent, bounding, and governing delivery. Those skills are taught at the bedside — by senior consultants who can model them on live engagements — and they take years. The firms that have hollowed out their senior consultant ranks under cost pressure are also the firms that have removed the teaching capacity. The firms that have kept their senior consultants and given them explicit teaching mandates are the ones whose junior consultants will still have a path to partnership.
The implications for the consultant reading this follow. If you are a consultant who feels that the deliverable you used to produce is no longer what you are paid for, the productive response is not to fight the tooling but to migrate, deliberately, toward the work the tooling cannot do. Spend the next ninety days noticing where your engagements miss the framing in the opening week. Spend them noticing where intent gets dropped between sessions, and start carrying it. Spend them noticing the moments where the bounding fails and an agent or a team is sent off to do work that was not actually what the client needed. Spend them following one piece of work all the way into production, regardless of whether your engagement formally covers that. The skills you will develop are the skills that compound across cycles, which is the only kind of skill that compounds in a career running at the cadence the consulting industry now demands.
What kind of seller the org of the future needs
The seller the org of the future needs is the seller who can hold the architecture conversation that the customer's own AI tools cannot have on the customer's behalf. That is the headline. The work behind it is less glamorous than the headline suggests.
The seller of 2023, at her best, was a translator between customer need and vendor capability. The translation was often valuable. It involved understanding the customer's politics, the customer's regulatory environment, the customer's existing stack, the customer's roadmap, and matching all of that against what the vendor's product could actually do. The seller's competitive advantage was knowing both sides — the customer's reality and the vendor's product — better than the customer or the vendor's individual practitioners knew their counterpart.
The seller of 2026 is in a different situation. The customer now has tools that do significant parts of the matching the seller used to do. The customer's champion can spend an afternoon with Claude and produce a comparison report that is more rigorous than what the seller would have produced for the same deal. The customer's solution architect can prototype a working version of the vendor's offering, in part, over a weekend. The customer's CFO can run their own scenario analysis on the licensing model. The information asymmetry that the seller used to operate inside has narrowed dramatically. The customer, in the cycle's vocabulary, has internalized parts of the discover-and-design phase that used to depend on the seller.
The seller who survives this is not the one who refuses to acknowledge the narrowing. It is the one who recognizes that the work has moved to the place the customer's tools cannot reach. That place has three components.
The first component is the consequence conversation. The customer's Claude session can compare features. It cannot, with any depth, model the way a particular vendor choice will compound into an architectural problem in 2028 — because the model does not know the customer's regulatory trajectory, the customer's likely M&A activity, the customer's board's risk appetite, the seller's vendor's actual financial trajectory and partnership trajectory, or the way the choice will interact with the customer's existing stack two cycles forward. The seller who can hold the consequence conversation — here is what choosing this platform does to your architectural optionality in 2028, here is what choosing the competitor does — is selling the thing the AI tools have not yet absorbed. That conversation requires depth on both sides: depth on the vendor's strategic trajectory, depth on the customer's institutional reality, depth on the architectural patterns that connect them. It is the work of a senior seller. It is also the work that distinguishes a senior seller from a representative who walks through a feature deck. The consequence conversation is the seller's version of the cycle's deploy phase, projected forward across several future cycles the customer will run.
The second component is the architecture conversation. The customer's Claude session can describe an architecture pattern. It cannot, with any reliable depth, hold a conversation about why a particular architecture is the right one for this customer given this set of constraints over this time horizon. The seller who can hold the architecture conversation is doing work that overlaps with the solutions architect — and increasingly, the senior seller and the senior solutions architect are the same conversation, executed by a small team rather than handed off across organizational boundaries. The orgs that still treat sales and pre-sales as distinct functions, with a hand-off at the demo stage, are operating with a 2023 model in a 2026 market. The architecture conversation cannot be handed off; it has to be held continuously, with the seller participating credibly across every cycle the deal runs through.
The third component is the trust conversation. The customer's Claude session can read public information about a vendor. It cannot judge whether the vendor's leadership is operating in good faith over a multi-year engagement, whether the vendor's roadmap commitments are credible, whether the seller herself is the kind of person the customer can rely on when something goes wrong in 2027. Trust is built between people, slowly, and the customer's tools have not made trust obsolete. They have made it more important, because the easier and more commoditized parts of the relationship have been absorbed by the tools, and what is left for the seller is the part that requires a person who keeps her word.
The disposition the seller of 2026 needs is the disposition of a senior advisor. The work that has appreciated is the work that used to be done by the customer-facing partner at a major consultancy or by the relationship manager at a private bank — the work of holding the conversation that requires judgment, depth, and trust. The orgs that are still building their sales motions around feature demos and product walkthroughs are losing deals to competitors whose sellers have made this transition. The customers do not always articulate why they chose the competitor; the architecture conversation is rarely written down in the formal procurement record. But it is the conversation that decided the deal.
The implications for hiring are unfamiliar to most sales organizations. The seller to hire is not the one with the strongest quota attainment in 2024. It is the one who, in a customer meeting, can recognize when the customer has done their own comparison and can pivot from the feature pitch to the architecture conversation without losing the room. The seller to hire is not the one with the most polished demo script. It is the one whose customer references describe her as a partner over a multi-year horizon. The seller to hire is not the one who closes the most deals in a quarter. It is the one whose deals survive the customer's first crisis without unwinding.
The implications for training are also unfamiliar. The sales orgs that are training their sellers on AI tooling are, again, training the wrong skill at the wrong altitude. The strategic skills are the consequence conversation, the architecture conversation, and the trust conversation. Those skills are taught by senior sellers who can model them on live deals, and they take years to develop. The orgs that have promoted their sales leadership out of customer-facing work and into management have removed the teaching capacity, just as the consulting firms did. The orgs that keep their senior sellers in front of customers — and explicitly task them with teaching — are the ones whose junior sellers will still have a path forward in 2028.
The implications for the seller reading this are practical. If you are a seller who feels that the deals you used to close are sliding, the productive response is to migrate your selling motion deliberately toward the consequence, architecture, and trust conversations. Spend the next ninety days noticing where the customer has already done a feature comparison. Spend them building one customer relationship to the point where the customer would call you before calling their own architecture team. Spend them on a single deal where you are not the cheapest option and where you win by holding the consequence conversation longer and more credibly than anyone else in the room. The deals you will close are not the same deals you would have closed in 2024. They are bigger deals, with longer sales cycles, against customers who will become more loyal over time because the relationship is built on something the tools cannot replicate. Each deal you work, in the new motion, is itself a cycle — discover what the customer's tools have already concluded, design the architecture conversation, build the relationship that lets you hold it, test it in the room, redeploy your motion against the next deal with what you learned. The seller who runs that cycle weekly, against every deal in her book, compounds faster than the seller who runs it once a quarter against the deals that have stalled.
What the leader of the org of the future actually does
The leader of the org of the future is, in most cases, a leader who is also unsure what their job has become. The pattern at the top is not different from the pattern in the middle. The work has migrated, the middle has compressed, the ends have appreciated. The cycle is running faster than most leaders have organized their teams to run. Most leaders have not yet done the personal accounting of where their own role sits in the new shape.
The leader of the org of the future does six things, recognizably, across industry and function.
The first is to staff for the new disciplines explicitly. Specifier, verifier, skill author, governor, operator, senior seller — these are not titles in most organizations in 2026. They need to become titles, with promotion criteria, with compensation bands, with measurement, with training programs. The leader who is staffing for the new disciplines using 2023 job descriptions is staffing the old shape, paying 2023 prices for 2023 skills, and wondering why the productivity gains the AI tooling promised are not materializing. The productivity gains are real, but they require the org to be staffed for the shape the tools have produced. The org that staffs for the old shape will spend on the tools and not capture the gains.
The second is to build the skill library as a strategic asset. The skill library is the institutional memory of the firm, packaged in a form that agents can use. It is also the artifact that distinguishes the firm whose people compound across cycles from the firm whose people start from scratch every time. The firm that has fifty good skills covering its core delivery work has a competitive advantage that compounds quarterly. The firm that has none is paying full price for the foundation model's general capability without capturing any of the firm's specific learning. The skill library is built by the firm's most senior people, reviewed quarterly, owned by named teams, and treated as version-controlled organizational property. The leader who does not have a named owner for the skill library does not yet have a skill library.
The third is to measure what survives audit. The temptation in the AI-augmented org is to measure productivity by output volume — pull requests created, deliverables produced, demos given, prospects contacted. The honest measurement is harder. Accepted pull requests by category and complexity. Escaped defects to production by severity. Customer satisfaction at month six rather than at deal close. Skill library coverage. Calibration drift. Verification thoroughness. None of these are flattering numbers in the first quarter of an AI rollout, because the metrics that look good — we produced three times as many pull requests — often hide the metrics that matter — thirty percent of our production incidents now trace to agent-generated code. The leader who measures only the flattering numbers is the leader whose board will be surprised by the regulatory event in 2027.
The fourth is to write down the list of work that is never delegated. The list will vary by organization. Common items include production deployments, schema migrations on customer data, secrets rotation, customer-facing communications during a crisis, regulatory filings, legal commitments, security policy changes. The point is not that agents cannot help with these. The point is that the firm has decided, deliberately and in writing, where the line between delegated and accountable lives. The list is itself a governance achievement; it forces the firm to inventory which categories of risk it tolerates and which it does not. The firm that has not yet written down the list is making the decision implicitly, transaction by transaction, and the implicit decisions accumulate in ways the firm cannot defend.
The fifth is to build the proprietary tooling that compounds. This is the place where the OakQuant model — the model I have been building toward in my own work — applies broadly. Foundation models are a commodity. Every firm has access to them. The differentiation comes from the proprietary tooling built on top: the firm-specific skill library, the firm-specific evaluation rubrics, the firm-specific token-usage instrumentation that catches the runaway pattern before the bill arrives, the firm-specific composition layer that wires the firm's bounded agents together into a working delivery system. The presentation.oakquant.ai work is a small example of the pattern at small scale: an instrumented presentation-generation system that identified token usage waste, eliminated it, and dropped the per-presentation cost from a meaningful number to a near-trivial one. The same pattern, applied across an organization's delivery work, produces the cost discipline that lets a firm's AI investment actually clear the financial bar the board will eventually demand. The leader who does not have a proprietary tooling roadmap is paying retail for the commodity and not capturing the proprietary value.
The sixth is to instrument the continuous feedback loop. This is the leader's commitment to the cycle's iteration cadence at the organizational level. The AI-augmented org learns from its own work in ways the 2023 org did not. Every agent decision, every verification, every guardrail trip, every saga rollback, every drift event is a signal. The org that captures these signals and feeds them back — into the skill library, into the evaluation rubrics, into the team's training, into the governance posture — compounds quarterly. The org that does not capture them is operating on the same instinct it had when it deployed the first agent, regardless of what has happened since. The continuous feedback loop is not a feature of the tooling. It is a discipline of the organization, and it is built deliberately or not at all.
These six commitments are what the leader actually owes the org. They are not in most job descriptions in 2026. They will be in most job descriptions in 2028, in the firms that survive the transition, and in retrospect the leaders who built them earliest will look prescient. The leaders who delayed will look like they were managing the old shape while the new shape arrived. The leader who builds them is, in effect, redesigning the organization so that it runs the discover-design-build-test-deploy cycle as its operational pattern rather than enduring the cycle as an interruption to a deploy phase nobody planned to leave.
The tooling strategy in plain terms
Most organizations are over-buying and under-building.
Over-buying takes the form of paying for every coding agent on the market — Copilot for one team, Cursor for another, Claude Code for a third, Devin for the asynchronous work — without a clear architectural picture of what each tool is supposed to do and how the outputs compose. The bill grows quarterly. The integration debt grows faster. The team's average productivity does not move as much as the licensing cost predicted, and nobody is sure which tool is responsible for the gains that do appear.
Under-building takes the form of failing to invest in the proprietary tooling that would have compounded. The firm's skill library does not exist, or exists in one engineer's personal folder. The token-usage instrumentation does not exist, so the firm cannot see where its agent costs are concentrating and which patterns are running away. The evaluation rubrics are ad-hoc. The composition layer is whatever the most recent project's engineer happened to build. The audit trail is whatever the underlying tool happens to generate by default. The proprietary capability the firm could have built — the capability that would have been its capability, not the vendor's — is missing.
The correct tooling strategy is to be modest in buying and aggressive in building proprietary tooling on top of what is bought.
On the buying side: pick one or two coding agents that match how your teams actually work. Cursor for synchronous, IDE-centric engineering. Claude Code for terminal-native, deeper-agentic work. Codex Cloud or Devin or Jules for asynchronous delegation against well-scoped tasks. You do not need all of them. The marginal capability of the third tool against the second is small; the marginal cost of integration is high. Pick the two that match your work. Standardize on them. Train your engineers on both. Move on.
On the building side: invest deliberately in five proprietary capabilities, in roughly this order.
The first is a token usage and cost instrumentation layer. Every agent call, every prompt cycle, every reflection loop, every retry — instrumented, attributed to a team, attributed to a workflow, attributed to a customer engagement. The instrumentation is not exotic. It is plumbing. It is also the difference between a firm whose AI bill is predictable and a firm whose CFO discovers, in the third quarter, that the production agent has been re-prompting the same case 800 times because of a configuration bug. The presentation.oakquant.ai work — instrumented to identify token waste, then optimized to eliminate it — is a small-scale example of what this instrumentation produces. The same discipline, applied across delivery, produces material cost differentials at scale. The firm that has the instrumentation can negotiate with model providers from a position of knowledge. The firm that does not is paying retail with no insight into whether retail is what it should be paying.
The second is the firm's skill library. Not a wiki. Not a folder of prompts. A version-controlled, owned, reviewed, tested set of skills covering the firm's repeatable work — the testing skill, the code review skill, the dependency upgrade skill, the security review skill, the release notes skill, the migration template, the incident summary skill, the post-mortem template, the engagement framing skill, the customer success review skill, the renewal conversation skill. Each skill has an owner, a review cadence, a deprecation policy, and a set of test cases. The skill library is the firm's institutional memory in machine-readable form. It is also the artifact that travels across teams, across engagements, and across new hires. The firm with a strong skill library can onboard a new engineer or consultant onto a project in days rather than months. The firm without one is paying full training cost every time. The skill library is what makes the firm's accumulated learning compound across cycles rather than evaporating between them.
The third is the firm's evaluation infrastructure. Calibration tracking, drift detection, golden sets, active learning loops, regression gates on promotion. This is the architectural substrate I described in Inside Cambium, applied to the firm's own delivery work. The firm that has evaluation infrastructure can promote a new prompt or a new agent configuration with confidence, because the infrastructure tells them whether the new configuration is actually better than the old one on the firm's own work. The firm without evaluation infrastructure promotes based on vibes, and the vibes accumulate into a system whose behavior the firm cannot defend.
The fourth is the firm's composition layer. The agents do not work alone in production. They work together, with humans, against the firm's existing systems, with audit trails generated, with human-in-the-loop gates fired where the architecture requires them. The composition layer is the workflow engine and the surrounding orchestration that wires all of this into a coherent whole. For most firms in 2026, the composition layer should not be built from scratch — it should be built on top of an enterprise workflow platform that has matured under regulatory load. Pega Agentic Process Fabric, ServiceNow's AI Control Tower, Salesforce Agentforce, Camunda's orchestration cluster, or another platform with similar maturity. The firm's proprietary work on top of the composition layer is the specific orchestration the firm needs — the case management for the firm's specific work, the human-in-the-loop routing for the firm's specific decision points, the audit trail format for the firm's specific regulatory environment. The firm that has not invested in the composition layer is operating each agent as a standalone, and standalone agents do not compound.
The fifth is the firm's governance toolkit. Identity, audit, policy enforcement, model risk management, drift response. This is the layer that makes the agent fleet defensible to the regulator, the auditor, the customer, and the court. For most firms it should be built in partnership with a dedicated AI governance vendor — Credo AI, IBM watsonx.governance, or one of the others maturing in 2026 — rather than built entirely in-house. The firm-specific investment is in the policy library, the registry of which agents are allowed to do what, and the evidence aggregation that demonstrates the firm followed its own rules.
These five proprietary investments — instrumentation, skill library, evaluation, composition, governance — are not optional in the firm that intends to be operational in 2028 with AI-augmented delivery. The firm that invests in them now will have compounding advantages by 2027. The firm that delays them will be paying for tools without the proprietary substrate that makes the tools produce a return. The leader who has not yet made these investments has the easiest available competitive move on the table. Make them. Quietly. Before the rest of the market does.
The measurement that survives audit
Productivity claims in the AI era are easy to inflate. The leaders who survive 2026 and 2027 will be the ones whose claims survive audit.
The metrics that survive audit are the conservative ones. They are not flattering in the first quarter of an AI rollout. They are the metrics a successor leader can use, a board can use, a regulator can use, and a careful internal audit function can use without finding that the gains were on paper.
For engineering: accepted pull requests by category and complexity, escaped defects to production by severity, time from request to merge, time from merge to production, test coverage delta, security findings rate, modernization throughput, developer satisfaction tracked quarterly, and the proportion of work fully delegated versus collaboratively produced. The single most important pair of these is accepted PRs and escaped defects. The temptation is to optimize for accepted PRs alone, because that number can be moved aggressively with AI tooling. The honest measurement pairs it with escaped defects. The firm whose accepted PRs went up three hundred percent and whose escaped defects went up four hundred percent has made the system worse, not better.
For consulting: time-to-framing on new engagements, engagement renewal rates at month twelve and twenty-four, post-engagement implementation success measured at month six, client satisfaction tracked by named decision-makers rather than by anonymous survey, consultant retention by tenure cohort, skill library contributions by named consultants, and partner-grade work performed by sub-partner-level staff. The single most important of these is the renewal rate at month twenty-four. Engagements that look successful at close often unravel over the eighteen months that follow. The firm that measures only at close is optimizing for the artifact. The firm that measures at month twenty-four is optimizing for the work the artifact was supposed to enable.
For sales: deal close rate by deal size, deal close rate against competing AI-mediated comparisons, customer retention at year two and year three, seller retention by tenure cohort, expansion revenue from existing accounts, time spent in the consequence conversation versus the feature walkthrough, and named referencability — the proportion of closed deals where the customer would speak on the record about the seller's contribution. The single most important of these is customer retention at year three. The seller who closed the deal in 2026 and whose customer is no longer a customer in 2029 did not actually win. The firm that measures only quarterly close rates is missing the durability question that the AI era has made more important.
Across all three roles, the measurement principle is the same: measure outcomes, not activity. Measure durability, not momentary speed. Measure the artifact at month twenty-four, not at signing. The metrics that flatter in the first quarter are the metrics that mislead by the third year. The metrics that are unflattering in the first quarter are the metrics a regulator, a successor, and an internal audit will eventually use to evaluate what was built. The principle is the same as the cycle's: measure not the speed of one phase but the durability of the deployment, because the deployment is the input for the next discovery.
The continuous feedback loop
The AI-augmented org is supposed to be a learning system. Most are not.
A learning system has four mechanisms, and the four mechanisms are themselves the discover-design-build-test-deploy cycle, expressed at the organizational level. The org captures what happens (discovery against its own behavior). It evaluates what happened against what was supposed to happen (design against a standard, build that standard into a comparable judgment). It adjusts its operating posture in response to the evaluation (test the adjustment, redeploy the new posture). And it updates the institutional memory so the next adjustment is faster than the last (the deployment becomes the input for the next cycle). Each mechanism is buildable. None is glamorous.
Capture: every agent decision, every human review, every guardrail trip, every saga rollback, every drift event, every customer complaint — captured in a structured form that can be queried later. The capture layer is plumbing. It is also the precondition for everything that follows. The firm that does not capture is the firm whose post-mortems are stories told from memory.
Evaluation: every captured event scored against the firm's own standard. Did the agent decision match the firm's expected behavior on this case type? Did the human review catch what it should have caught? Did the guardrail trip on something real or on a false positive that is becoming a pattern? The evaluation runs continuously in the background, not as a quarterly exercise. The firm that evaluates only quarterly is operating on three-month-old evidence in a market that moves monthly.
Adjustment: when the evaluation surfaces a pattern, the firm changes the operating posture. New prompts where the existing prompts are drifting. New skills where the existing skills are missing edge cases. New gates where the agents are taking actions that should have required human review. New training where the human reviewers are missing what they should have caught. Adjustment is the disciplined response to evaluation. The firm that does not adjust has captured and evaluated for nothing.
Institutional memory: every adjustment is recorded as a change to the skill library, the evaluation rubric, the agent registry, the policy library, or the training material. The next person who encounters the same situation does not start from scratch. The firm's behavior, in aggregate, gets better. The institutional memory is not a feature of the tools. It is a discipline of the leadership, maintained quarterly, never delegated entirely to the team that produced the work.
Across all four mechanisms, the leadership signal is whether the loop closes. A firm that captures but does not evaluate is producing data nobody reads. A firm that evaluates but does not adjust is producing reports nobody acts on. A firm that adjusts but does not update institutional memory is repeating the same correction every six months. The loop closes only when the leader makes it close, by naming an owner for each mechanism, by reviewing the loop's output regularly, and by promoting the people who run it well.
The continuous feedback loop is the operational expression of the firm is learning. It is, equivalently, the operational expression of the firm is running the cycle as a discipline rather than enduring it as an interruption. Most firms are not learning, even when they say they are. The ones that are will be visibly more capable by 2028 — capable in a way that compounds, that is hard for competitors to copy, that survives leadership changes and economic cycles. The leaders who build it now are building the operational advantage that will be visible in three years, not three weeks.
A ninety-day plan, for whoever you are
The fear is rational. The architecture is the response. The architecture, however, is built one ninety-day cycle at a time. The ninety-day plan is itself an instance of the discover-design-build-test-deploy cycle, run at the personal scale, repeated. What follows is what to do in the next ninety days, depending on where you sit.
If you are an engineer: pick one pull request next week that an agent generated and read it as if you were the auditor. Do this once a week for ninety days. By the end, you will be the engineer in your team who can identify what is subtly wrong with agent-generated code, and you will be the engineer your team turns to when a deployment goes sideways. Separately, pick one Jira ticket next week and write the specification before you let the agent see the ticket. Do this once a week for ninety days. By the end, you will be the engineer whose work the agent can actually do. Separately again, pick one skill in your team's domain that does not yet exist and write the first version of it. Submit it for review. Iterate. By the end of the ninety days, you will have authored at least three skills. You will be the engineer whose contribution shows up in everyone else's work. Each weekly action is a small cycle: discover what is wrong with an agent-generated PR, design how you would have written it differently, build the review, test it against the team's standards, redeploy your reading practice on the next PR. The career is what those weekly cycles compound into.
If you are a consultant: spend the first thirty days noticing where your engagements drop the framing. Pick the engagement where the framing was weakest and rewrite the problem statement, on your own time, as it should have been written in the opening week. Spend the next thirty days holding intent on one engagement deliberately — keeping a private log of the decisions, the context, the people, the constraints, the political timing. Compare your log to the formal engagement record at the end. Spend the final thirty days following one piece of work all the way into production, whether or not your formal role extends that far. By the end of the ninety days, you will have done three pieces of work that distinguish you from the consultant who is paid to produce the deliverable. You will have done three pieces of work that distinguish you from the tool that produces the first draft. You will be visible to the partner in a way you were not visible before. Each of the three months is a cycle: discover the gap, design the practice, build it against a live engagement, test what you learned, redeploy on the next engagement.
If you are a seller: pick the deal in your pipeline where the customer has most clearly done their own comparison. Schedule a meeting with the customer's champion in which the agenda is the consequence conversation — what choosing one vendor versus another does to the customer's architectural optionality in 2028 — not the feature walkthrough. Run the meeting. Notice what works. Pick one customer in your existing book and build the relationship deliberately, over the next ninety days, to the point where the customer would call you before calling their own internal architecture team. Pick one deal where you are not the cheapest option and where your win condition is the trust conversation rather than the price negotiation. By the end of the ninety days, you will have closed at least one deal that the seller you used to be could not have closed. You will also have lost at least one deal that the seller you used to be might have closed. Both outcomes are part of the migration. The seller who survives 2027 is not the seller who wins every deal in 2026. It is the seller who has migrated her selling motion to where the deals that survive are made.
If you are a leader: in the next thirty days, name an owner for the firm's skill library, the firm's token-usage instrumentation, the firm's evaluation infrastructure, the firm's composition layer, and the firm's governance toolkit. Five names. Write them down. If you do not have five people who can plausibly own each of these, that is the gap your leadership has to address before anything else. In the next thirty days, write down the list of work that is never delegated to an agent in your organization. Share the list with your senior team. Refine it. Publish it internally. In the final thirty days, pick the three metrics by which you will measure the AI rollout, choosing them deliberately for the property that they will survive audit at month twenty-four. Stop measuring the other things, or at least stop reporting them as evidence of progress. By the end of the ninety days, you will have done the architectural work that distinguishes the leaders who are building the org of the future from the leaders who are buying tools and hoping the productivity gains absorb the organizational drift.
The ninety-day plan is not a transformation program. It is a set of small, achievable, compounding moves. Each ninety-day plan is one full cycle. Four cycles is a year. A year of these cycles produces the kind of person, and the kind of org, that is visibly different from the person and the org that began the year unsure of what to do. The cycle's cadence is what compounds. The cycle's discipline is what survives the next disruption — because there will be a next disruption, and the next one, and the one after that, and the career that survives is not the one that picked the right place to land but the one that learned to run the cycle continuously enough that the next disruption is just the start of the next cycle.
Closing
The fear is rational. The work has migrated. The middle has been compressed. The ends have appreciated. The cycle has accelerated. The people whose careers depended on the middle, on the old long single-cycle career model, are right to be uncertain. The people whose careers can migrate to the ends, and who can learn to run the cycle continuously, have an opportunity that was not available to them in 2023.
The org of the future is not science fiction. It is recognizable adjustment to a recognizable shift, made by leaders willing to do honest accounting and by employees willing to redesign their own work deliberately. The skills are nameable. The training is buildable. The measurement is auditable. The tooling is buyable in part and buildable in part, with the buildable part being the part that compounds.
The career of the future is not science fiction either. It is the career that runs the discover-design-build-test-deploy cycle continuously, against shifting tools, shifting regulations, shifting opportunities, shifting politics, shifting markets — and treats the shifting not as a disruption to be endured but as the actual shape of the work. The person who builds that career is not the person who found the safe corner. There are no safe corners now. The person who builds that career is the person who learned to run the cycle deliberately, at a pace that staggers their predecessors, and who treats each cycle's deployment as the input to the next cycle's discovery.
I will be working on this problem for the rest of the decade, in my own work at Pega and Accenture, in the building of OakQuant, and in the writing on press.oakquant.ai. The pieces that follow this one will go deeper on the specific disciplines — the skill library as institutional memory, the proprietary tooling as competitive moat, the verification function as the new center of gravity, the consequence conversation as the surviving sales motion. The architecture, however, is in place. The fear is rational, and the response to a rational fear is not denial.
The response is what you do tomorrow morning. The PR you read as if you were the auditor. The Jira ticket you specify before the agent sees it. The engagement you frame more honestly than the RFP would have allowed. The deal where you pivot from the feature walkthrough to the consequence conversation. The skill you write down. The list of work you will never delegate. The five names you assign to the five proprietary investments. The metric you stop measuring. The metric you start measuring. The ninety-day plan, repeated four times. The cycle, run continuously, until running it is no longer the new thing — until running it is just the shape of your career, the way one long deployment phase was the shape of your father's.
The org of the future is built from the bottom up by people who decided not to wait. Be one of them.
— Pumulo Sikaneta