I have spent most of this year on planes. Seven countries, somewhere north of a hundred customer conversations, most of them with teams well past the pilot stage.

The thing I keep coming back to is what changed between the January conversations and the July ones.

In January and February, as agentic coding adoption climbed, people bragged about lines of code being generated. Not sheepishly. Proudly, with slides. By summer, nobody was bragging about that anymore. What replaced it is the interesting part, and it has changed what I think good agentic architecture actually looks like.

The number that didn’t survive contact

Anyone who has written software knows counting lines of code is a terrible proxy for value. Dijkstra wanted lines spent rather than produced. Gates compared measuring programming progress by lines of code to measuring aircraft progress by weight. DORA’s contribution, starting in 2014, was to define delivery performance in terms of throughput and stability instead of output volume, and to keep testing that definition for a decade.

So, the lines-of-code brag didn’t come back because people forgot about its weaknesses. It came back because AI made output volume newly impressive and there was no other number ready to hand.

The industry has since caught up. By spring, DORA was writing about “tokenmaxxing,” the practice of ranking developers on raw token consumption, and filing it in the same drawer as lines of code and commit counts. The question worth asking is which metric the teams who moved past it reached for instead, and what they’re building to move it.

What actually replaced it

Start with the data, because it explains the architecture.

CircleCI’s 2026 State of Software Delivery, drawn from more than 28 million CI/CD workflows, found that for the median team, feature-branch throughput rose 15% while throughput on the main branch, where code actually gets promoted to production, fell 7%. More motion where the writing happens. Less where the shipping happens.

DORA’s survey of nearly 5,000 technology professionals reaches the same place from the human side: higher AI adoption is associated with an increase in both software delivery throughput and software delivery instability. Faster and shakier at once. The mechanism they describe is a verification tax, where effort saved on typing relocates downstream into review and validation, and where AI tempts teams away from small batches into larger, riskier changes. DORA’s ROI report this spring gave the cost a shape: a J-curve, with the dip arriving before the return.

The trick isn’t code volume; it’s how fast an organization can get code into production and how reliable it is once it gets there. How does an organization use AI to achieve this?

The wrong fix to faster, more reliable production releases

The instinct is to build a super agent. One agent that owns the software development lifecycle end to end: reads the ticket, writes the code, opens the pull request, runs the tests, ships it. I have watched it demo beautifully more than once.

It also concentrates every failure mode in one place, needs the entire universe of context to do anything at all, and gives your humans nowhere familiar to look when it goes sideways.

So, if a super agent is the wrong answer, what’s the right one?

What teams are actually building

The pattern I keep finding in the field is the opposite of the super agent. Small agents, each one sitting on top of a system of record that already exists.

Walked out concretely, the chain looks like this:

• Jira ticket to GitHub issue. One agent. It reads the business request and produces a technical issue with enough specificity for engineering to act on. That’s it. That’s the whole job.
• GitHub issues to point poker to sprint organization. A separate agent, independent of the first. It estimates, groups, and sequences.
• Coding. Another agent. This is the one everybody thinks of as “the AI,” and it is one of five.
• Pull request merging. Another. Review, conflict resolution, merge discipline.
• System testing. Another.

The important word is independent. This is not one brain with five subroutines. It is five agents that happen to touch adjacent records, each one narrow enough that you can describe its job in a sentence. If this pattern sounds familiar, it should, because it borrows a lot conceptually from microservices.

Why this way

Keep your systems of record. This is the most underrated idea in the whole pattern. Most agent discourse assumes you are building a new pane of glass, a console where you watch the agents work. The opposite is right. Put the agent behind the pane your people already watch.

Your humans in the loop don’t need training, don’t need a new dashboard, and don’t need to change where they look to see whether things are on track. Jira is already that place. Human-in-the-loop fails less often because people refuse to supervise and more often because supervision got moved somewhere they don’t live.

Limit the blast radius. An agent scoped to sprint organization cannot ship bad code. It can misfile a story, and you will find out at standup. In DORA terms, you are addressing change failure at the stage where the change happens, rather than measuring it at the end of a pipeline where you can no longer tell which step broke it.

Architect and release independently. I watched service-oriented architecture become microservices at HP and again at Cisco, and the thing that made the transition worth its considerable cost was not elegance. It was that you could change one piece without renegotiating the whole system. The same applies here. Swap the coding agent’s model without touching the testing agent. Version them separately. Kill the one that isn’t earning its keep.

There is a fourth benefit that compounds with the others. Each micro agent needs a fraction of the context a super agent needs. Last month I argued that the lever nobody pulls is what a single pass costs, and that the answer is picking the right 200K instead of sending the wrong million. Narrow scope is how you get there structurally rather than through tuning. Cheaper and more accurate, for the same reason as before.

The proof point

One of these customers is a retailer. Over nine months, running this pattern, they took their idea-to-production time down by a factor of five.

Be precise about that metric, because it invites scrutiny. Idea to production is wider than DORA’s change lead time, which starts the clock at commit. Theirs starts when a business stakeholder files the request. I think the wider boundary is the honest one for agentic work, because a meaningful share of what these agents do happens before anyone commits anything. Ticket refinement, estimation, sequencing. Measure from the commit and you miss the part the agents changed most.

They did not move their lines-of-code number. I doubt they know what it is anymore because it’s become irrelevant.

And here is the part that matters more: no layoffs. They are using the capacity to take on projects they could never staff before.

In February I argued that a development team is a productivity multiplier rather than a cost center, and in March I made the bank-teller case that automation which expands what’s economically possible tends to expand employment rather than contract it. Both of those were theory when I wrote them. This is the first field evidence I have been able to publish for either one.

Objections

• “Isn’t five agents more operational overhead than one?” Yes. It is the same trade microservices always were, and the same trade small batches always were. More ceremony per unit, less risk per unit. If you have made that trade before, you know whether you liked the outcome.
• “Won’t agents-per-stage recreate our handoff problems?” Conway’s law applies to agents. Your agent topology will mirror your team topology whether you design for it or not, so design for it. That is a constraint to work with, not a gotcha.
• “Systems of record are legacy. Shouldn’t agents live in a purpose-built layer?” The system of record is not where the data is. It is where the humans already look.

The honest caveat

The microservices analogy cuts both ways, and I would rather say so than have it said to me.

Microservices also brought distributed tracing problems, cascading failures, and orchestration complexity that took the industry years to tame. Micro agents will bring their own version of all of it. Observability across five agents is genuinely harder than across one, and right now the tooling for it is thin. What makes the trade worth it is the same thing that made it worth it for services: you can reason about, test, and replace one piece without holding the entire system in your head. And keeping the existing systems of record in place helps mitigate this distributed tracing problem since there aren’t new locations but the same old ones you’ve had for years.

The scoreboard

The lines of code brag was the sound of an industry measuring the only thing AI had obviously changed.

The teams that moved past it stopped asking how much their agents produce and started asking how small they could make each one. Five times faster from idea to production, no layoffs, and a backlog that finally has room in it.

DORA’s metrics have been revised in 2015, 2018, 2021, 2023 and again in 2024, when the four keys became five. What survived every one of those revisions is the pairing underneath them: throughput and stability, measured together, because either one alone will lie to you.

That is still the scoreboard. It was never going to be the tokens or lines of code.

For many years, Musinsa, South Korea’s premier online fashion platform and marketplace for Korean designer brands, streetwear, and beauty products, has described itself as a company dedicated to AI. They bring in AI-native talent and give employees room to experiment, yet meticulously manage token usage and work performance.

And instead of handing over AI completed by engineers to the field, they have the field restructure their own work using AI. So if external solutions are deemed lacking, they analyze the cause and create their own solutions.

Gil Gi-yong, the company’s director of core AI and CX engineering, began actively utilizing AI shortly after joining Musinsa last year when he saw AI evangelists, from the CTO to new employees, directly create results. He says that Musinsa changes faster than organizations he’s experienced before, so he’s diligent about anything new that comes along to augment its developing internal AI platform.

Director of operations Kim Dae-ho is on the same page, too. Kim, who joined in September 2022, currently leads the operations strategy team that’s responsible for planning and executing tasks to improve customer and partner experiences, and improve operational efficiency across Musinsa’s commerce ecosystem. Recently, most of his work has been closely related to AI, so he’s collaborating with the development team to lead AX projects.

Musinsa is investing so much in AI is because trends change rapidly and fashion consumers can be impulsive. So platforms have to be fast, anticipatory, and intuitive to meet demand. In addition, they should support areas such as sales management for partners, and AI is the means to meet these needs and boost business competitiveness. That’s how Musinsa has started solving unique fashion industry problems.

A prime example is how outfit photos are shot. To showcase products in the past, models were hired, they dress themselves, and it’s all shot in a studio. Now, AI is used as a coordinator to generate images and the goal, according to Gil, is to elevate visual AI tech to a top standard by H1 2027.

Plus, AI is used in the product registration process of partner companies, so when a product is registered, AI automatically infers categories, colors, materials, and more. In the past, these tasks were manually entered. Holistic AI has also been integrated into customer service centers. The AI chat agent operated by 29CM, a South Korean fashion and lifestyle platform operated by Musinsa, currently handles about 25% of all customer inquiries.

From business operations to ROI

Companies typically approach AX in two ways. One is for the engineering team to get the requirements of the field, develop the system, and then say try it, and pass it on. If it’s hard to solve internally, the other way is to leave it to an external vendor. But Gil sees that AX often fails in these two approaches.

“The reason is that engineers do AX, but they don’t fully understand the processes of the field,” he says. “That’s why we focus on creating an environment where field experts can directly improve the actual work processes.”

In fact, Musinsa’s AX-related ideas are directly proposed by each business team. For example, the planning and engineering departments review how to improve on repetitive tasks with LLMs by setting quantitative goals such as reducing tasks from 270 man hours per week to three.

The core of the approach Musinsa choses is next. Engineers don’t write scripts for them. Instead, the core AI team suggests guides until target figures are achieved through repeated testing. Gil says this process ultimately helps the business operator measure how to write prompts and what improvements they use to improve them.

This approach has also changed the process by which AI spreads. Instead of copying systems created by developers, colleagues directly use AI to improve actual work. As small success stories accumulate and are shared, overall AI utilization capabilities also increase.

Gil adds that this approach must align with the direction of leadership. Simply sending tasks down by saying try using AI and costs will be covered isn’t enough to drive adoption. At Musinsa, many leaders, including the C-suite, first experiment with AI and freely share results. This culture encourages voluntary experimentation and accelerates the spread of AI. 29CM’s AI chat agent was reputedly developed using this method.

In fact, this tech was developed in collaboration with outsourced companies, and produced a certain level of output, but the strategy was revised to in-house development. Those results were actually better, according to Gil, and they succeeded in launching quickly while reducing costs to about a third of the outsourcing method. The development period was also about a quarter of similar projects at other companies.

However, this speed isn’t simply due to AI. ROI verification is thorough and Musinsa first fixes timelines and budgets, then prioritizes requirements to implement within that framework.

Even before starting, cost issues are carefully considered. For example, they calculate a five-year TCO and first check when investment costs can be recovered as savings. When using external services, they don’t sign long-term contracts based on simple discount benefits. Kim says that starting a project based solely on rough cost estimates may result in significant investment but doesn’t achieve the expected efficiency.

For AI chat agents, they quantified the estimates generated by the technical team, and simulated how much customer satisfaction would change and inquiry rates decrease. Investment costs were also calculated by year and month.

After implementation, monthly tracking is conducted to see how costs differ from expectations, how the AI processes inquiries, and how close performance is to the original target. If differences from expectations occur, improvements are made, including which variables to add, if the scope of inquiries handled by AI should expand, and if agent workflows should change.

Generous support, but objective evaluation

For this approach to continue, a supportive organizational culture is necessary. First, Musinsa provides a substantial amount of tokens so its members can fully utilize AI. But token usage is actively managed, so each leader regularly checks it using separate monitoring tools. If too many are used for tasks that could be handled with fewer, it’s looked into. Conversely, tasks that could be completed much faster with AI are still subject to inspection even if they’re handled using traditional methods.

Kim says that ultimately, what matters isn’t whether AI was used, but what results were achieved and how many resources were invested in the process. If AI can improve the quality of deliverables and reduce time in the work, it should be actively utilized. But the costs invested and the results achieved should be considered together.

Naturally there are times when using AI when multiple rounds of testing are gone through before desired results are reached. This means more tokens and time are required, and costs increase. But Musinsa focuses more on what trial and error was experienced, what was learned in the process, and what can be done differently next time. Failure is also seen as data that increases the chances of success next time.

AI leader standards for talent

What kind of talent do AI-led companies need? Not so much proficiency in AI itself but the ability to properly define problems. Kim defines planning as a journey of problem-solving, meaning a series of processes to identify them, develop solutions, and execute. It’s become even more important for humans to define what to ask of AI. If the problem definition is ambiguous, no matter how plausible the AI is, it’s difficult to apply it to actual work.

Of course, acquiring these skills isn’t easy. Kim says that training to constantly ask why is helpful. He doesn’t just accept initial causes as they are, but searches until a real solution emerges.

“At first, it’s confusing,” he says, “But through intense discussions and debates, capabilities develop. If the opponent isn’t a human but an LLM, you can repeat the same process much faster.”

Gil’s standards to evaluate development talent are similar. He believes people who can think differently from traditional methods are now needed, and relying solely on experience and technical expertise is no longer a sufficient nor competitive advantage.

In fact, this is reflected in Musinsa’s AI native developer recruitment. The focus isn’t on simple algorithm proficiency, but on how well the applicant defines real-world problems, grasps the essence of the problem, and uses certain indicators to determine whether to solve the problem, even when freely using AI.

The principles of leadership aren’t much different. Kim defines his style as autonomy-based leadership, while Gil prefers to clarify responsibilities and authority. The common goal, however, is to have an organization that doesn’t rely on any single individual.

In terms of next steps in AI transformation. Gil believes that competitiveness depends on who’ll first leverage new technologies, and how quickly that experience will transform into organizational capabilities. But AI led by tech organizations has its limits. Models that worked in commerce don’t work offline as is, and a single model can’t transplant across all areas of the company. So each organization must handle AI based on its own domain of expertise.

This is where Musinsa is headed. It’s not a company that relies on a few AI experts, but a place where anyone can wield AI in their work. “I want to establish a company where every employee solves their own problems with AI, and accumulates that experience as an organizational asset to show we use it well,” says Gil.

AWS is betting that AI agents need a different interface as they move beyond answering prompts and start working autonomously in the background.

The company has open-sourced Pizza Bot, a self-hosted application that gives users an inbox for managing work delegated to AI agents, with separate threads for ongoing tasks and a queue for work that is completed or needs human input, rather than keeping the management of agents restricted inside a conventional chat window.

The rationale, according to AWS, is that background agents do not always need a user’s attention while they work and an inbox model will let users hand off longer-running tasks, return to them later, and see which jobs are complete or require intervention.

Under the hood

That approach is reflected in how the inbox organizes work with the help of an “All” tab that contains the history of each task or conversation, including the agent’s messages and work performed, the “Unread” tab that flags completed work that users have yet to review, and an “Action” tab that surfaces tasks paused while waiting for user input or approval.

The inbox interface also has a panel named Activity that shows users how an agent handled a particular task along with the transcript, AWS wrote in a blog post introducing Pizza Bot.

AWS’ inbox-oriented rationale also extends to Pizza Bot’s architecture.

It uses LangChain’s Deep Agents as the harness and LangGraph as the stateful runtime, with a combination of the two allowing an agent to checkpoint its progress as it works, preserving its messages, tool activity and current state so a task can be paused and resumed rather than being tied to a live chat session, the hyperscaler wrote.

Pizza Bot’s server sits on top of that stack, connecting the agent runtime with the user interface, skills, MCP servers and the model provider, with developers able to choose from Anthropic, OpenAI, Google Gemini and Amazon Bedrock, as well as local models through Ollama, it added.

As for its out-of-the-box capabilities, the application comes with skills for working with files, browsing the web and delegating tasks to specialist agents. Developers can also add existing Agent Skills and MCP servers to give the agents access to other tools and services, the hyperscaler wrote.

Enterprise integration could remain a hurdle

However, analysts were not too convinced that Pizza Bot’s out-of-the-box skills and support for existing tools will make its implementation easier for enterprises.

While the out-of-the-box capabilities and added support for existing skills saves enterprise teams the time to build the application, it leaves out the integration work required to make it work, said Bhupendra Chopra, chief revenue officer at IT consulting firm Kanerika.

“Integration is where most of the money in an enterprise agent deployment goes. A sales or finance team gets value from an agent when it can read and update CRM, email and ERP, and each of those systems needs a connector someone has to build, secure and maintain,” Chopra pointed out.

Pizza Bot’s integration could be further complicated by the application’s lack of support or any SLA, according to Manoj Chandra Jha, principal analyst at Nord-IQ Research. That means the integration and operational burden ultimately falls on enterprises, who would be responsible for running, securing and maintaining the open source software themselves, Jha said.

Rise in enterprise productivity likely

But for enterprises willing to take on that integration work, the inbox-oriented approach could improve productivity.

“It’s a meaningful shift because it changes the economics of delegating work to agents. A chat interface requires a person’s attention throughout the task, while an inbox brings them in only when their judgment is needed, much like how executives delegate work to their teams,” Chopra said.

“Coding agents have already demonstrated this model, where an engineer assigns an issue and reviews the resulting pull request. Pizza Bot extends that approach to tasks such as meeting preparation and follow-ups,” Chopra added.

Further, the analyst pointed out that the inbox-oriented approach could give enterprise teams a clearer window into how scheduled tasks perform.

“For scheduled tasks, having the results delivered as threads gives users a way to track what happened in the background and spot failures that might otherwise go unnoticed,” Chopra said.

Out of sight, out of mind

There are risks with this approach, however: “The inbox model can make bad work less visible. When somebody is watching an agent in a chat window, they can see it going off the rails,” said Phil Fersht, CEO of HFS Research.

In contrast, when hundreds of tasks are running quietly in the background, users may not see an agent making mistakes until the task is complete or an exception requires their attention, potentially making problems harder to catch early, Fersht said.

That reduced visibility can also create approval fatigue, according to Chopra.

“An agent sending back dozens of threads with multiple approval requests can condition users to approve them without reading them closely,” Chopra said.

There is also a risk in the delay between an agent preparing an action and a user approving it: “Information that was current when the agent paused may no longer be valid hours later, potentially resulting in an outdated CRM update or a meeting invite for a slot that is no longer available,” he said. “An assumption that might be caught in a live chat can go unchallenged as the agent continues building on it and consuming model resources. Scheduled runs can also add costs without anyone watching them in real time.”

Those disadvantages can be countered by designing processes with fewer, better-timed approval points, and verifying that the underlying data is still current before allowing an action to execute, he said.

Adoption likely to start with technical teams

Such tradeoffs are likely to shape where Pizza Bot gains traction.

“Adoption will likely be bottom-up, with individual technologists and small platform teams drawn to Pizza Bot’s control and standards-based design,” Jha said. “Risk-averse industries, especially ones in the regulated sectors, and business users with limited technical expertise, however, are likely to approach the application more cautiously,” he added.

That could leave Pizza Bot occupying a more targeted role in the enterprise, as a way for technical teams to experiment with asynchronous agents and new ways of delegating work, rather than an immediate replacement for the governed interfaces and managed services enterprises typically use for business-critical processes, he said.

This article first appeared on InfoWorld.

The first hit is access. I have talked with technology leaders whose teams had a working model but could not secure the capacity to operate it at production scale on the economics they had forecast. The available capacity sat outside the assumptions behind the existing agreement, and market pricing had moved well beyond the budget. As CIO.com has reported, AI is exposing the limits of enterprise cloud strategies created before these workloads became material.

Data movement creates another problem. AI workloads may cross regions or providers in search of an available GPU or a better price on a particular chip. I have seen finance teams confront cloud bills that ran well beyond forecast because data had to leave one cloud to reach compute available in another. The increase had nothing to do with headcount or a wave of new applications. It came from an architecture assembled around capacity rather than cost.

Egress pricing also changes the economics of portability. Consolidating with one hyperscaler may simplify operations, but it can become expensive to change course when the provider cannot supply the right capacity in the right place. By the time the CIO needs alternatives, the cost of moving data may have weakened the negotiating position.

Then the question reaches the board: What will AI cost next year? Some CIOs cannot answer with confidence because the contract and cost model were built around a different workload. That is more than a forecasting problem. It tells the board that the company has committed to an AI roadmap without understanding the infrastructure economics beneath it.

What prepared CIOs are doing differently

The CIOs in the best position separated AI economics from the rest of the cloud estate before returning to a provider. They stopped defending cloud spend as one number and accounted for training and inference by workload, region and chip. That work gave them something far more useful than another high-level forecast: evidence they could negotiate from.

Some have resisted the usual pressure to consolidate everything with one hyperscaler. They have kept selected AI workloads portable across providers or moved GPU-heavy training to specialized infrastructure companies. Portability carries its own engineering and governance costs, so it is not automatically the right answer. But a credible ability to move a workload creates leverage that a cloud strategy built around dependence cannot.

The contract requests have changed as well. CIOs are asking for guarantees tied to named chip types, shorter terms for volatile AI capacity and the ability to rebalance spend categories as the workload mix changes. One structure is a reserved allocation for a specific GPU generation rather than a general compute credit. Another is a shorter AI-specific commitment layered over a longer agreement for the general-purpose estate. The two workloads do not have to be forced into the same planning horizon.

The work should start before the provider puts a proposal on the table. Once the negotiation has been reduced to a renewal number and a discount percentage, the most important assumptions have already escaped scrutiny.

Start with the workload rather than the existing agreement. Which AI use cases are expected to reach production during the next term? Which require training, which rely mostly on inference and which can use a managed model without dedicated GPU infrastructure? Those distinctions determine whether the company needs reserved capacity, flexible consumption or no direct GPU commitment at all.

Then test the location assumptions. Where does the underlying data reside? What residency or sovereignty rules limit where it can move? If the preferred capacity is available only in another region or from another provider, calculate the transfer, egress and operational costs before calling that option cheaper. A lower compute rate can disappear quickly when the data has to travel to reach it.

Capacity and discounts also need to be separated. A favorable price does not guarantee that the required chip will be available when a production workload needs it. Conversely, a capacity reservation can protect access while creating a cost for infrastructure the company does not fully use. The CIO needs both numbers: the economics of consuming the capacity and the economics of holding it.

Finally, decide what must remain portable. Full multi-cloud portability is expensive and often unnecessary. But there may be a small number of high-cost AI workloads where dependence on one provider creates more risk than portability costs. That is where an alternative architecture can become negotiating leverage rather than an abstract cloud principle.

None of this requires treating the original agreement as a mistake. It was often a reasonable decision based on the company’s workload at the time. What has changed is the cost of leaving it unexamined.

A three-year cloud agreement cannot be treated as a three-year suspension of judgment. Before the next renewal, test the commitment against the workload the company is actually running, not the company it was when the agreement was signed.

AI adoption is shaking up the big IT consulting market, with some IT leaders starting to question the need for the multi-year transformation engagements that have been large advisory firms’ bread and butter.

Organizations are increasingly using AI tools to assist with large digital transformation projects such as cloud modernization and mainframe migrations, with the AI cutting the time and effort needed to achieve the goal. At the same time, the speed of evolution in the AI space has led some IT leaders to question the value of two- or three-year engagements.

Some observers have suggested advancements in AI will devastate the large IT consulting model, and McKinsey, Deloitte, Ernst & Young, and KPMG have all announced layoffs in recent months. Others suggest big IT advisory firms are here to stay, although they may need to adjust their business models to change with the times.

Representatives from Deloitte, EY, and Accenture didn’t respond, or declined to respond, to questions about the impact of AI on their businesses. But Edwin Miranda, founder of AI consulting firm konsultora, doesn’t think his larger competitors are going away anytime soon.

“I don’t think the large consulting firms simply disappear,” he says. “They still have enormous advantages in industry expertise, global delivery, complex integration, procurement, regulation, and the ability to operate inside very large organizations. What AI is attacking is the traditional operating model behind the engagement.”

In the past, a large IT consulting project would involve weeks or months of research, analysis, documentation, with large implementation teams doing the work, he notes. The cost of a large IT transformation came from the human labor required to move information from one stage of the engagement to the next.

“AI compresses a lot of that work,” he says. “Research that took weeks can happen in hours. Large document sets can be analyzed before the first meeting. Software can be prototyped while the operating model is still being discussed.”

In addition, AI agents can assist with development, testing, documentation, and coordination, and small senior teams can now produce a level of output that previously required a much larger pyramid, he notes.

“That doesn’t eliminate consulting; it changes what the client should be willing to pay for,” Miranda adds. “The value moves away from the volume of people assigned to an engagement and toward judgment, architecture, implementation, governance, and measurable business outcomes.”

The heart of the value proposition

Some observers see a dimmer outlook for the IT consulting industry. As AI adoption builds, the technology is eroding the core value proposition of big consulting firms, says Paul DeMott, CTO at digital marketing agency Helium SEO.

“Clients are running their own data analysis using off‑the‑shelf AI tools, so it is valid for them to ask why they should pay premium rates for work they can now do internally,” he adds. “AI commoditizes exactly what consultants charge a premium for, which is synthesizing data and translating insights into recommendations.”

With some big firms laying off staff, the traditional model of throwing junior consultants at problems seems to be breaking down, he says.

“Think about it, if AI can do the grunt work faster and cheaper, what exactly are those junior staff doing?” DeMott says.

DeMott sees some potential clients moving toward smaller, more specialized providers and others changing how they use large firms.

“Clients are not necessarily abandoning them outright, but they are pushing back on scope, duration, and cost,” he says. “The large firms still have relationships and brand equity, but those advantages are getting thinner by the quarter.”

Multi-year transformation on the ropes

In addition, big consulting firms are changing the way they hire because of AI, notes Brad Belzak, founder of AI-native advisory firm Acuity Global Partners. Until about two years ago, some generalist IT skills, a data engineering background, decent soft skills, or some trend analysis awareness would be enough to get a job at the large consultancies, he says.

“Frontier models ended that almost overnight,” adds Belzak, a former consulting employee at both Deloitte and EY. “First AI, then agentic AI, then highly trained specialized models absorbed the work that generalists with light coding skills used to do.”

Recruiters at the big consulting firms now want what he calls deployable talent, he says: engineers and analysts with product development histories who know how to read and manipulate data to solve client problems.

“Coding matters less than it did,” he adds. “The premium is on people who can take messy data, structure it, and turn it into an answer. The pyramid of generalists underneath them is gone.”

IT leaders at client companies, meanwhile, are demanding shorter, more modular engagements, Belzak says. Ninety-day sprints are becoming more common.

“The multi-year transformation made sense when the technology underneath it moved slowly,” he adds. “That world is gone. If your roadmap takes three years, the tools you scoped in month one are obsolete by month 18.”

IT leaders hiring consultants should focus on outcomes instead of headcount, he suggests.

“You’re not buying people anymore; you’re buying results,” he says. “That five-year contract might now be a six-month contract, and if the short-term outcomes generate wins, it gets extended.”

Consulting firms can still fill IT staffing needs, but their time on site may be shorter, he says. “Think embedded, on-demand engineers and analysts who come in, solve the problem, and move on, whether you’re a startup or a mature company,” he adds.

Accelerant and expertise

Aelin Golsarry, founder and CIO AAG Technology Consulting, doesn’t believe AI will kill large consulting firms, but it will make some of their services more difficult to justify. Still, AI can’t do all the work involved in large digital transformations, she says.

“AI should make a lot of the work required to get through a transformation faster, but it doesn’t make the transformation itself happen faster,” she adds. “People still have to make decisions, change processes, implement technology, and actually adopt it. AI doesn’t make any of that disappear.”

Golsarry, who as a CIO hired large consulting firms in the past, advises IT leaders to think clearly about what they’re buying when engaging with consultants.

“They should ask, ‘Do I need 30 consultants, or do I need three people who have seen this problem before and know how to fix it?’” she says. “I’d be looking at the expertise of the people actually doing the work, what outcome I’m paying for, and whether the firm’s use of AI is making the engagement faster and more efficient for me or simply making the engagement more profitable for them.”

Consulting isn’t going away, Golsarry adds. “Companies will always need expertise they don’t have internally,” she says. “What I think is going away is the assumption that more people, more hours, and a longer engagement somehow means you’re getting more value.”

IBM will embed OpenAI frontier models and products such as Codex and ChatGPT embedded into IBM’s AI consulting services platform, IBM Consulting Advantage, as well as expanding the companies’ existing collaboration in the cybersecurity realm, they announced Thursday.

Joint initiatives will include the creation of industry-specific products for financial services, government, telecommunications, and retail, as well as serving key enterprise domains such as finance, procurement, customer operations, and HR.

IBM will join the OpenAI Partner Network and engage forward-deployed engineers and consultants trained through the network to help clients accelerate their AI implementations. It will also create a dedicated OpenAI practice, certifying thousands of consultants and engineers via the Partner Network, it said.

There will be three focus areas in the new partnership: helping organizations transform their businesses to integrate AI into their daily work, assisting clients in modernizing legacy applications through a combination of OpenAI products and IBM’s expertise, and an expansion of an existing cybersecurity collaboration combining OpenAI frontier AI capabilities with IBM Autonomous Security.

Everyone, it seems, is engaging forward-deployed engineers to help enterprises build systems around their AI models: OpenAI announced its initiative, OpenAI Deployment Company, on May 11, a week after Anthropic launched its efforts. Microsoft and AWS too have jumped into the ring.

But, said Info-Tech Research Group distinguished analyst Mark Tauschek, “This is becoming table stakes. The consulting firms that have the horsepower and technical talent to partner with a frontier AI lab to do this are all picking their horses. Anthropic has some, Microsoft has some, and of course OpenAI has some. There will be more announcements like this to follow, and while it’s good PR for both IBM and OpenAI, it’s certainly not differentiating.”

Enterprises will choose the consulting firms that work with their AI vendor of choice, he noted, although he does think that Microsoft had the initial advantage because they were able to quickly provide thousands of skilled FDEs.

“But,” he said, “this is a horse race, and it’s going to be a tight one.”