OpenAI is buying Pierre Computer Company in order to incorporate the San Francisco-based software developer’s Code.Storage infrastructure layer for Git into its Codex AI-powered programming tool.

Pierre Computer, whose employees number just barely in the double digits, has got plenty of clout for its small size. It’s well-known for Code.Storage offering, as well as for its open-source software libraries, Trees and Diffs, which OpenAI already uses in Codex.

OpenAI has experienced some of the limitations of Git itself, and its in-house engineering teams are already working to improve its support for human coders and AI agents working in parallel. Earlier this week the company described how it built a new back end for Git repositories, Pando, to enable concurrent working at scale.

The AI developer has been pushing Codex more aggressively this year: offering it to Mac users and expanding it to Windows. It cited Pierre Computer’s ability to help developers review code as one of the reasons for the acquisition. OpenAI highlighted the Diffs’ Edit mode and the recently released Highlights as components that were particularly helpful to development teams.

Announcing the deal on its news page, OpenAI set out how it would integrate the company into its existing offerings. “With the Pierre team, we wish to set the standard for modern software development: from the first branch an agent creates to that magic moment when code is deployed to the world. We want to make Codex the place where developers and agents take on their most ambitious projects.”

Neither company disclosed details of the acquisition price. OpenAI said that Code.Storage customers will be able to continue using the product until it brings the features into Codex, while Pierre Computer’s open-source projects will remain open, and OpenAI will continue to contribute to them.

This article first appeared on InfoWorld.

AI is writing more code than ever. Software specialist Sonar’s 2026 State of Code Developer Survey, based on more than 1,100 professional developers, found that 72% of those who’ve tried AI coding tools now use them every day, and that today, AI now accounts for 42% of committed code, a number that’s expected to reach 65% by next year.

But while developers embrace AI-enabled coding services, many professionals are uncertain about how their businesses will cope with this influx of AI-generated code. Sonar’s research additionally discovered that 96% of developers don’t fully trust it, and only 48% always verify it before committing.

In fact, 38% of developers told the researchers that reviewing AI code requires more effort than analyzing code written by human colleagues. That’s a pattern recognized by Tim Chilton, a managing geospatial consultant at UK mapping agency Ordnance Survey (OS). “There’s truth in the headlines that AI can get carried away, and developers spend more time fixing the code that’s been created than not,” he says.

While that’s not a pattern he sees at the OS, Chilton says his organization is cautious about how developers use AI coding tools, and conversations with other digital leaders suggest a similar approach. AI-enabled coding is indeed almost ubiquitous, and it can allow developers to reach new, higher levels of productivity, but more doesn’t necessarily mean better code.

To ensure that such coding services produce business benefits, CIOs must take control of the development process. They should exploit agents carefully, set professional responsibilities, and establish guidelines, policies, and organization-wide training.

Exploiting the agents

Snowflake co-founder and president Benoît Dageville suggests there are two ways to view AI-powered coding. One is the scary way, where AI takes over your tasks without human input. The second is the efficient way, where AI helps you do the same things as before, but at a fraction of the cost. He’s a big believer in the latter, both for himself and his teams.

“The route depends on the organization; their application of AI coding depends on their priorities,” he says. “However, I hope that overall, AI will have a positive effect on humans. I’m using AI every day to code, and if I compare myself to one or two years ago versus now, I’m more efficient and productive, but I’m also writing five times more code.”

Steve Lucas, CEO of integration technology specialist Boomi, also notes the increase in output. He quotes research that suggests 4% of GitHub public commits are already being authored by Claude Code. That proportion is expected to rise to 20% of all daily commits by the end of this year. Staff at Boomi already use AI tools to produce more code.

“We’re writing 10 times the amount today than we did two years ago,” says Lucas. The increase in AI-enabled coding is so significant that he’s spoken with Boomi chief product and technology officer Ed Macosky about goals for the proportion of self-modifying code.

“I believe AI should recursively modify 80% of a software organization’s code,” Macosky says. “Infinite improvement is demanded. If AI is extraordinarily good at breaking security protocols, the only way to keep up isn’t the kind of accordion model of human code design. AI use must be linear in scale and continuous.”

Crucially, Lucas suggests using AI to check and modify that AI doesn’t mean coders go away. “In fact, I think we’ll need more engineers, not fewer,” he says. “We need these professional experts to ensure the quality of the code that’s written.”

At OS, Chilton uses Coco, Snowflake’s coding agent. The tool does as much as 90% of a development task that he would otherwise complete from scratch. “It’s taken an hour to finish, instead of weeks or never,” he says, reflecting on the power of AI coding services.

However, the tool’s influence is carefully constrained. The agent doesn’t work in isolation, and Chilton checks its output in detail. He says all organizations need a similar process and should value experienced professionals who can use AI coding tools effectively.

“If you’re giving a tool to someone who isn’t capable of checking an agent’s work, as a digital leader, you run the risk of putting too much faith in AI just running with its output,” he says. “I think that’s a big risk, so there’s still a need for experienced developers.” 

Setting clear responsibilities

While placing humans in the loop can help ensure AI-enabled code is safe and effective, developers shouldn’t be weighed down by their new management responsibilities.

Gill Haus, CIO at Chase, the consumer banking arm of JPMorgan Chase & Co, says AI coding benefits can only be realized when agents are introduced with a strong focus on automating supporting technology and processes, which reduces the need for too much human input.

“If you have 12,000 engineers, they can write 12,000 engineers’ worth of code in a day,” he says. “If those 12,000 engineers have agentic technology, they can write much more. But if you don’t have automation left to right with confidence, you create more manual processes. You can’t move as quickly since there are only so many humans you can put in the middle.”

Haus says Chase never releases services in production that don’t pass its high bar for quality and security. Strong engineering practices, pipelines, and architecture, plus a tried-and-tested approach to automation, can help ensure AI coding produces solid outputs without a burdensome amount of human intervention.

“We’re focused on effective automation so we’re able to unleash this technology safely and effectively,” he says. “This is something many other companies should be focused on if they aren’t already, because otherwise you can’t keep up with the pace of change.”

François-Xavier Pierrel, group chief data and ad tech officer at French TV network TF1, is another digital leader who says maintaining control as AI writes more code means keeping the human in the loop in a clearly defined manner. His team documents agentic processes using Atlassian project management and collaboration tools, such as Confluence.

Pierrel says policy management is crucial as the agentic transformation gathers pace.  One key step is ensuring professionals who use agents conform to internal standards. Smart businesses set policies that state clearly when staff can explore an agent, delegate work to it, or release it in production.

“We don’t have hundreds of agents deployed yet,” he says. “But the moment you reach a certain level of volume, if you don’t have compliance and policies in place, AI becomes a critical mess, and then it can be disruptive in a negative way.”

Building strong foundations

Kirsty Roth, chief operating officer at content and technology specialist Thomson Reuters, agrees digital leaders must be proactive. Her firm’s explorations with models and agents suggest that AI can help with time-intensive coding processes, such as writing. This capability means her organization carefully considers the roles people fulfil.

“In the last 12 months, we’ve put lots of thought into where we’re seeing benefits,” she says. “It’s great AI can do some of the coding work, but what does that mean for people’s jobs? We used to have thousands of engineers. Do we now need more architects or product people?”

Roth refers to security. While cyber is always a priority for Thomson Reuters, the firm dedicates significant resources to controlling threats in the AI age. Developing high-level development and security skills requires a concerted effort. Yet Roth says ensuring people have the right skills to manage AI is in many ways a familiar IT trend.

“All this effort is no different than digital, cloud, mobile, social, or other big tech trends,” she says. “They all take several years to have an impact as the initial hype comes, and then you’ve got to work through the reality and think about how you upskill people for the new world.”

Crucially, coding is no longer the sole preserve of the software developer. AI coding tools make it much easier for non-IT professionals to vibe code applications. Tal Carmi, CIO at technology specialist WalkMe, says non-developers can create useful tools. However, effective outputs rely on a careful balance between enablement and guidance.

He adds that most of these employees don’t need in-depth capabilities, such as a database or a content delivery network. Instead, non-IT staff require a dedicated place to upload their products. WalkMe’s engineering specialists ask key questions to ensure their outputs are safe, considering credentials and potentially problematic packages.

“You need to add guardrails,” he says. “A lot of the work for in-house engineers is shifting from building to testing. The people who aren’t coders don’t necessarily have security in mind.”

The key takeaway, suggests Emmanuel Frenehard, chief digital officer at biopharmaceutical giant Sanofi, is that digital leaders must help professionals feel comfortable. Successful digital leaders ensure the business generates value from agents, and his firm is helping its staff, particularly its developers, to embrace these tools.

“I genuinely worry for professionals who don’t use AI to code, because in five years, they may not have jobs,” he says. “So we’re guiding, coaching, and training them, but people must take the journey. The train has left the station. You can decide to be on it, or just look at it.”

AI fluency has long mattered to Sambit Dutta. When he joined global chemical manufacturer Hexion this year as SVP of AI transformation, his strategy included bringing “AI to the masses, where the people can not only just consume AI, but also become what we call builders.”

Dutta has made citizen AI a cornerstone of Hexion’s IT strategy because he believes that when the creativity and domain expertise of employees is centralized and funneled through a business analyst or developer, “there are always things lost in translation.” Further, “there’s a queuing process where that request ultimately gets queued, and then based on dollars and other priorities, never gets executed,” he adds.

Dutta also believes that innovation unleashed at the grassroots level is how enterprises achieve true transformation. And it facilitates change management because people become more receptive to absorbing technology at that level, he says.

“We firmly believe that we are at a stage where citizen development has finally taken off” at Hexion, Dutton says.

Citizen AI — a development strategy that has CIOs making AI tools available to employees outside IT to create their own solutions — is taking hold inside enterprises. It democratizes AI by enabling business users to solve problems and create efficiencies in their roles without the overhead of full IT-led development.

“Historically, turning a good idea into a technology solution required specialist skills, funding, and space on a development roadmap,” says Ankur Anand, group CIO at technology recruiter Harvey Nash. “AI lowers that barrier. People can explore an idea, create an agent or prototype, and establish whether it genuinely solves a business problem before the organization commits significant resources.”

But the objective isn’t to create hundreds of unofficial production systems, Anand adds. “It’s to create hundreds of experiments and make it much easier for good ideas to emerge from anywhere in the organization.”

Freedom first, governance to follow

Travel tech company eSky Group is one such company moving toward an AI-first model, “where using it is as natural as using email or a browser,” says Piotr Mynarski, technology director there.

“Employees creating their own agents is not a fringe behavior,” he says. “It is one of the clearest trends we see inside innovative companies today, and the most visible change in how our engineering works.”

At the end of 2025, eSky made AI a company objective, and by spring 2026, the company had agreements with several AI providers whose tools were opened up to everyone, not just to engineering staff.

eSky expects about 60% of its more than 650 employees worldwide outside the contact center to become fluent with AI. Regular use of AI is climbing toward 80%, Mynarski says, who notes that the company’s approach was a bit unusual: Company officials “barely capped budgets, let people use the tools for personal purposes, too, and gave everyone room to experiment rather than mandating a narrow toolset,” he says.

That approach deliberately gave employees freedom first, with governance to follow once leaders saw what they actually built.

“That order was a conscious bet and so far, the right one,” Mynarski says. “Today, we have over 30 agents across the company, almost every engineering team works with at least one, and several teams have more, with some already running in production.”

The agents were developed from a shared codebase built by eSky engineers, and they specialize in different needs: development of new products and features, maintenance, analytics, and monitoring business metrics.

“The rules are catching up rather than leading,” Mynarski notes. “Every agent has its own identity and credentials, guardrails and observability are standard, and responsibility for an agent sits with the team that runs it, not with a central AI department.”

AI reduces the barrier to entry — but still requires guardrails

Before joining Hexion, Dutta worked at Nestlé, where he implemented “a pretty robust program around digital fluency.” Parts of the program worked, but some didn’t, particularly where sophistication was required “in thinking, and a little bit of a technical depth.”

Some citizen development can be performed with drag-and-drop tools, but often written instructions are required, he notes. “A lot of people get really scared when you introduce those kinds of concepts to them.” That creates a barrier when employees want to leverage citizen development in areas such as data science, real-time automation, and Microsoft Power Apps, Dutta points out.

“Those are one type of automation that requires a little bit more sophistication,” he says. But that has changed. “The biggest unlock is now with prompt. You can avoid going into the developer tool altogether. … You can simply go in the prompt and describe what you want,and accordingly, the backend generates the application for it.”

As a result, Power Apps, which was more challenging for users to master and scale, no longer requires business users “to know the nuances about how to create a Power app.” Dutta says, unlocking a new level of productivity to a broader range of users.

At Hexion, employees use a centralized IT-owned platform to create agents. Business users have several tool options, “but those options are restricted to what we believe are enterprise-grade tools, and we have to secure it,” Dutta says.

For example, whereas everyone in the company can use Power App Vibe, only some employees have access to AI building platform Replit for coding.

Replit is “a little bit of a clamped-down application because we want to control what goes into production and how it connects with enterprise databases,” Dutta explains. “Replit can be dangerous because it if it is connected to SAP and other critical systems in a way that the users are doing something unusual with their app, it may bring down the system altogether.”

Users can, however, immediately connect the Replit applications they create to a data lake or other repositories, he adds. “It’s only when a transactional system gets impacted that we impose some condition.”

Unlocking business-user creativity

Hexion’s citizen AI strategy is unleashing creativity across the company, Dutta says. For example, the leader for environmental health and safety built an app she calls Wingman that can be used in the company’s factories to run health and safety processes. “We did some light editing on the core to make it a little bit enterprise standard,” and then it was deployed, Dutta says.

Given the divide between vibe-coded apps and production systems, governance remains an essential ingredient of any citizen AI development strategy. One of the AI governance tools Hexion uses is Microsoft Agent 365, which Dutta says lets IT see which agent is running and the various statuses of agents that employees deploy.

“We can start and stop anything we want across the enterprise,” he says. “It’s one single-pane governance layer.”

At eSky, employees are automating their daily work and building small applications for reporting and for automating specific business cases, Mynarski says. They also lean heavily on specialized agents that can take over parts of a job for them, he says.

In one instance, a performance marketing specialist built an agent that reads campaign data across eSky’s markets and is starting to generate ad content. The operations team runs a platform of 16 scheduled automations and small apps for controlling, reconciliation, and refunds, built by the people who used to do that work by hand, he says.

However, “this often becomes a problem the moment a personal tool needs to become a production system,” Mynarski says. “We have that covered with practices and guardrails that these teams can plug into, so the initiative stays with them and the hardening comes from us.”

At Harvey Nash, a content manager has created an agent that helps the company’s recruitment consultants find approved posts and assets, personalize it to their role, and post them to their social channels.

“This supports us with brand amplification and helping position them as market experts without requiring them to create new content,” Anand says. “We can measure the number of posts created, adding a gamification element to it to encourage usage.”

Coding isn’t the most important capability needed to become an AI citizen, he notes. “It’s understanding a problem well enough to describe it, knowing the context and data behind it, and having the judgment to recognize whether the result is useful.”

Overall, citizen AI is about dramatically increasing the number of experiments an organization can undertake, Anand says. “Give people the freedom and guardrails to turn ideas into proof points,” he says. “When an idea demonstrates real value, that’s when technology steps in to make it enterprise-ready and scale it. You get grassroots innovation without creating a technology Wild West.”

For CIOs considering launching a citizen AI strategy, Mynarski advises keeping costs in mind. “You have to ask, more than ever before, whether a given use brings value to the organization, because it is very easy to spin up AI that works beautifully and adds nothing,” he says.

Still, Mynarski believes the issue CIOs face is not employees doing too much with AI without permission. “The challenge is teams doing too little,” he says. “My advice to other CIOs: Talk about security in the same breath as innovation. If you let that gap grow, the freedom you gave people will be taken away from them later, and that is the expensive scenario.”

See also:

• How IT leaders can make vibe coding work at enterprise scale
• Your employees are building AI agents. Do you know what they’re doing?
• How to make sense of the agentic AI tools ecosystem
• What world-class IT looks like in the gen AI era
• How AI agents are shaping the future of work
• AI governance is fast becoming an unmanageable chore

When juniors take naive questions to an AI assistant instead of a colleague, dashboards record fewer interruptions and higher velocity. What they miss is the erosion of senior engineers’ architectural fluency, and the single point of failure that hardens until an outage forces someone to explain the system out loud.

Over the past year, I watched engineering teams celebrate a quiet drop in Slack interruptions. A junior used to ask a foundational question in a channel: why does this service retry three times instead of once? Today that junior asks an AI assistant first, messaging a senior only if the answer fails in testing. Already, 51% of developers ask generative AI for help they once asked a colleague, and 62% do so to avoid looking uninformed.

Because AI now absorbs routine implementation and debugging, it strips away the trial-and-error juniors once needed to grow into seniors.

Most writing about this shift worries about what juniors lose: less mentorship, thinner context and a shallower feel for production systems. That worry is real, but it is only half the balance sheet.

The costlier loss belongs to the senior engineer and the organization paying them to hold the architecture together. It rarely gets discussed because from the inside it looks like uninterrupted focus time.

What a naive question actually did

A junior engineer’s question was never just a request for a file path. It did three distinct jobs at once, and all three required a human on the receiving end.

First, it transferred tacit institutional memory that documentation never captured. When a senior explained why a payment service retried three times, they rarely recited the config. They narrated an incident from a year ago involving a partner’s rate limiter that never made it into a wiki. Documentation misses that history because nobody writes a design doc after the fact unless something breaks again.

Second, the question gave the senior a live audit of where the system had become needlessly opaque. A staff engineer who has owned a core service for three years goes blind to its rough edges; everything feels obvious once you know the history behind every compromise. A newcomer’s confusion is a free signal showing where the code no longer speaks for itself.

Third, and most overlooked, answering forced an articulation that kept the senior’s own mental model sharp. Explaining a state machine out loud to a colleague who asks follow-ups is a different mental discipline than silently knowing it. Teachers have known this forever: structuring knowledge for someone else exposes gaps and outdated assumptions in your own head. Seniors used to get that workout dozens of times a quarter for free.

The channel disappears without an alarm

Because those informal questions were never scheduled on a calendar or tracked in Jira, their disappearance triggers no alarm. When an AI assistant intercepts the first tier of naive questions, the senior simply gets interrupted less often. Over a single sprint, that silence feels like focus time. Over several quarters, it quietly erodes a senior engineer’s active command of the architecture they own on paper.

In practice, this decay stays hidden during routine code review because spotting a local bug on screen only requires passive recognition. Failure surfaces in postmortems when an incident demands active cross-system recall: tracing how failures cascade across service boundaries during a 2 a.m. outage. Across 211 million lines of analyzed code, structural refactoring has already collapsed from 25% of changes to under 10%, while duplicated code blocks jumped eightfold. Answering a junior’s “what happens if this service times out?” used to force seniors to trace those paths out loud every week. Without that rehearsal, the first live cross-boundary trace happens during an outage.

Why velocity dashboards hide the risk

For a CIO or VP of Engineering, this creates a treacherous blind spot. Standard engineering health metrics do not merely miss this erosion; they actively misread it as progress.

When juniors turn to AI assistants instead of pinging seniors, short-term output metrics look healthier. Pull request cycle times tighten, ticket velocity ticks upward and seniors report fewer context switches on surveys. On throughput dashboards, the organization appears to scale effortlessly.

Underneath those green indicators, three structural risks accumulate.

• Shared ownership collapses into a single point of failure. When architectural rationale stops circulating verbally, it stays trapped inside the heads of the veterans who wrote the code. If one leaves, what looked like shared ownership turns out to be unshared memory.
• Outage recovery times creep upward on complex incidents. Routine bugs get fixed faster with AI, but cross-boundary outages take longer. Every 25% increase in AI adoption correlates with a 7.2% drop in delivery stability, including mean time to recovery (the time required to restore service during an outage). When AI-generated changes hit production without shared context, seniors on the call spend precious minutes re-deriving how subsystems interact.
• Senior engineers’ verification load rises even as mentoring drops. In a 2026 study on developer skill formation, Anthropic found developers who delegated coding to AI suffered their steepest drop in debugging comprehension, creating a downstream “debugging tax.” In practice, seasoned engineers spend up to 19% more time verifying and fixing AI-generated code. When juniors skip foundational questions upfront, they still need a senior engineer’s help later, shifting the senior’s role from upstream architectural teaching to downstream code forensics.

An organization can coast on accumulated fluency for many months before the deficit shows. By the time it surfaces in postmortems or failed handoffs, the habits keeping senior engineers’ understanding sharp have been dormant for quarters.

Rebuilding the channel on purpose

When leaders notice institutional context slipping, their first instinct is more aggressive documentation or indexing wikis into AI retrieval tools. That solves lost context for readers, but not the senior engineer’s problem. Writing a static wiki page never forces a veteran to defend trade-offs or trace failure cascades under questioning. Documentation captures static answers; only live human friction keeps architectural fluency sharp.

Restoring that friction does not mean restricting juniors from using AI assistants, nor does it mean adding optional team meetings that get cut the moment a deadline tightens. If directors are rewarded solely on ticket velocity, informal coaching will always lose to the sprint board. Instead, leadership must embed live human articulation across the four moments where architecture is built, rehearsed, stress-tested and passed on.

• At code review: require verbal design defense on cross-boundary pull requests. Instead of letting seniors review large AI-generated diffs silently, require a ten-minute live walkthrough whenever a change touches service boundaries, retries or state machines. The junior explains what the code assumes about upstream systems; the senior explains why the boundary exists, replacing downstream code forensics with upstream architectural dialogue.
• Between incidents: run live system walkthroughs without slides. Once a month, a senior engineer walks peers through a critical production workflow on a whiteboard, tracing failure modes and historical trade-offs out loud. Where the explanation stalls or relies on guesswork, institutional memory has decayed before an outage can expose it.
• After an outage: require unscripted architectural narratives in postmortems. Do not let seniors satisfy an incident review by pasting a runbook link or an AI-generated summary. Require the service owner to explain live to adjacent teams how a failure propagated and why the boundary exists. Unscripted explanation under peer questioning is the only reliable test of whether a team still understands the software it runs.
• At the 90-day check-in: test architectural handoff, not just ticket count. AI makes it easy for a new hire to close starter tickets in week two without learning how the system fits together. Use the first structured performance check-in to verify whether the new engineer can modify a core workflow and explain its failure modes without escalating to the senior owner. If early ticket velocity is high but every structural change still routes back to one veteran after a quarter, AI is accelerating surface work while core architecture stays trapped in one head.

Every seasoned engineer knows the feeling of trying to explain a familiar system out loud and finding the words no longer come cleanly. That stumble rarely means they lost their edge. It means the friction that kept their understanding sharp was automated away, and leadership must put it back before the next outage asks for an answer.

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.

Human work has gone through several revolutions over the past few decades, each of them bringing a start to new careers and an end to others. Software careers, which seemed virtually untouchable a short while ago, have been touted as among the most prominent victims of artificial intelligence. On the surface, it’s easy to see why.

In the last few years, most enterprises have massively accelerated the rate at which they can produce code, while CIOs reported that tech industry layoffs hit their highest peak since 2024 earlier in the year. If I wanted to, I could now use AI to build a functioning CRM in a few days rather than weeks. With that in mind, it makes sense that senior executives may reconsider how much engineering headcount they really need to achieve their business goals. But would that CRM be fit for purpose, or secure enough to handle sensitive customer and business data? These are areas requiring skilled human judgment, so I’d encourage them to think twice.

AI has certainly changed the traditional path of software careers, but the value of knowledge, skills and experience in software engineering remains the same. As Faros AI found over its past two developer reports, AI speeds up individual coders, but review and rework swallow the gains before they reach the team. Poorly run projects will still lead to disappointing results, no matter how fast software teams can now churn out code. And at the rate companies need to be deploying to keep up with rivals, they need people with a sophisticated understanding of their organization to steward AI-generated software towards positive outcomes.

The conclusion that software engineers are under threat from AI reflects a confusion about what they do best. Code production is secondary to the ways that truly proficient software engineers think. That’s why I believe that demand for these minds will increase, not decrease, with AI.

The Jevons Paradox

When new resources increase efficiency, it’s instinctive to think that the consumption of that resource will drop; the Jevons paradox observes that the opposite tends to be true. Coal and steam made factories more efficient, prompting more tycoons to open factories and increasing overall consumption. As we’ve become better at generating electricity, we’ve found more uses for it, and consumption now dwarfs what was ever thought possible.

The Jevons paradox is not a promise that demand will always rise after an efficiency gain, but it is a useful lens through which to understand why software engineering will survive the AI boom. According to GitHub’s 2025 Octoverse report, developers pushed nearly one billion commits in 2025, a 25.1% year-on-year rise. Businesses are demanding more features and value as lower development costs make previously unviable levels of output more achievable.

So, it makes sense that software engineers capable of using AI to accelerate business value are going to be asked to create more of that value. Completing that loop, as my own business produces more value with more code, I’m inclined to hire more software engineers to manage more teams of agents, not fewer.

The employment outlook gives CIOs another reason to avoid making knee-jerk workforce decisions on the basis of short-term excitement. In July 2026, the U.S. Bureau of Labor Statistics projected that the number of software developers will grow 15.8% from 2024 to 2034, adding 267,700 jobs, even as it accounted for the spread of AI technologies. The shape of those jobs will change, but the need for people who can turn technical capacity into business value is not disappearing.

Lazy in, lazy out

AI will only be an accelerant for people who are able to apply it without outsourcing their thinking. There’s a big difference between asking an AI to write a strategy document for you, and asking it to challenge a base level of thinking that has already gone into the task. Treating AI as a ‘sparring partner’ to refine work rather than deferring to whatever it produces will naturally lead to far better results.

This is a mindset that those responsible for hiring, including myself, are looking to foster in software teams. AI amplifies the need for thinking that differentiates talented software engineers, who need to grasp why they’re doing the tasks they’re doing and what differentiates their organization in order to make a difference. Early career developer roles typically involve churning through tickets, but that skill falling down the order of priority doesn’t pull the rug out from under their development. It should instead free up more time for them to learn about their organization and grow into better problem-solvers.

I think about agents as virtual teammates. I wouldn’t hire a colleague and expect the first piece of work they return to be perfect. Colleagues need to be effectively onboarded and supported with context about the organization and its goals before they start producing value. A lazy prompt with incomplete context is simply a faster way to create something that looks plausible but does not solve the right problem.

Software engineers as foremen

Software engineers managing AI-assisted teams are becoming almost like ‘foremen’ — setting the direction of work, making sure agents have the right context and intervening when output falls short of requirements. Research from Gearset found that 82% of Salesforce teams trust AI to take on tasks in the build stage, dropping markedly to 58% at release. Routine configuration changes and writing tests used to be manual and time-consuming, but these are jobs teams feel most comfortable delegating to AI now. That leaves more space for engineers to manage the delegation of tasks and strategically build trust in AI.

AI has opened up more workstreams that can move at a faster pace at large organizations, meaning quality control is now the main imperative. This leaves an opportunity for software engineers to set intent, enforce standards and get closer to their business.

This change also has implications for junior engineers, who have traditionally learned a codebase through completing routine work. If AI performs all of this kind of work, leaders must be more deliberate in their approach to hiring early-career engineers: training them to explain the thinking behind projects and get more involved in architectural discussions. The objective is not to create more work for the sake of it, but to preserve and develop the problem-solving skills that help enterprises maintain quality at scale.

These skills aren’t new: the order of priority has simply shifted as the process of coding has become faster.

Deploy safely, or don’t deploy

Quality control is the primary challenge that has arisen from AI coding, and that is where engineers can make the most difference. They define what good looks like, for AI and human work alike, and make sure that all software changes are both safe to reach production and relevant to their business goals.

Software engineers supply the context and experience needed to make sure code is genuinely ready for production. An agent can generate a change that appears correct in isolation, but it does not necessarily reflect the surrounding architecture or the consequences of failure for customers and employees.

This is why demand will continue to improve for engineers who can turn higher output into safe, useful deployments. It’s crucial for AI-generated changes to pass the same version control, testing, security scanning, approval and auditing processes as human-written work. Engineers must set those standards and identify the right places where deterministic checks can replace manual reviews. Engineers will play a huge role in helping CIOs decide what work can sensibly be trusted to AI, while keeping teams accountable where human oversight is necessary.

The role therefore moves beyond writing each line of code and towards governing the whole path from intent to production. AI can accelerate the work between those points, but it cannot assume accountability for the outcome.

AI can be a force for good

I see AI as a positive force for the software industry if organizations give engineers the space to make more use of their critical thinking skills. When automation is used primarily for cost-cutting or headcount reduction, you disregard the critical thinking skills that make engineers so adept at improving the systems and products they build.

In an environment of psychological safety, where safeguards are prioritized over pure productivity, there is high potential for skilled software engineers to steward projects towards success at a much faster rate than was previously possible. Lazy inputs lead to bad outputs, but the best software teams are full of problem solvers with deep knowledge of their organization. You can’t outsource their thinking to AI, and the most successful companies in this era know that.

Eager to incorporate agentic AI into their work, employees are taking matters into their own hands, creating their own AI agents, regardless of organizational approval, and a not insignificant number of those creations could have devastating consequences if IT leaders don’t get ahead of the trend.

According to a recent survey by engineering staffing firm Howdy.com, two-thirds of knowledge workers that use AI also use agents, and 16% have begun to build their own.

About a quarter of agent users have had to deactivate them, however, largely because the agent’s outputs were inconsistent or the agent never worked. But 7% of knowledge workers have had to kill agents that went rogue.

The findings put a point on the potential repercussions of shadow agent creation and even sanctioned citizen AI strategies that encourage business users to roll their own agents.

While the survey didn’t ask whether the employees building their own agents were doing it on their own, Frank Licea, founder of Howdy.com, sees that many aren’t waiting for permission.

“In our internal teams, we’ve had to, not put the brakes on, but ask people to hold on,” he says. “Before they start jumping in and building their own agents, we’ve had to put guardrails and system guides in place so that we can do this safely.”

For what Licea has seen, employees are excited to automate boring manual tasks by building their own agents. “It mostly starts unsanctioned because there are tech-forward folks in any organization who are just naturally curious,” he says. “Or maybe even intelligently lazy. They want to automate their work.”

In recent months, Howdy.com employees began telling each other how they automated manual tasks, without waiting for the company’s IT team to approve the uses, Licea says.

“The way it happened for us is that folks would come up to us like just beaming and excited about something that they automated or fixed a long-standing problem that the engineering team never had on their roadmap,” he says. “Once that started happening, then somebody from the tech side gets in and they start asking questions like, ‘What are the API keys here? Are you accessing encrypted data? What are the SOC2 implications?’”

Cautious embrace

Luis Mesas, VP of product engineering at software engineering provider Sngular, believes it’s inevitable that employees will experiment with building AI agents to automate their work.

“Employees are going to create their own agents whether companies formally sanction it or not, because the barrier to building these tools is getting lower, and engineering teams are already being asked to do more with less,” he says. “The bigger concern for me is not that an employee creates an agent, but what happens when that agent starts connecting to company systems and data without the same controls that would normally exist around a piece of software.”

IT leaders need to understand how employee-created agents are connecting to internal systems and data, he says. If an employee creates an agent that can pull customer information from a CRM, update records, or move information between systems, IT leaders should know it’s happening, he adds.

“I want to know exactly what that agent can access and whether the employee should have that level of access in the first place,” Mesas says. “That is where something that started as an individual productivity tool becomes an enterprise technology issue.”

Andy Sen, CTO at B2B commerce platform provider AppDirect, believes employees should be encouraged to build agents — but within guardrails and established policies.

“Employees are almost certainly creating their own agents, and it would be naive to think otherwise,” he says. “Shadow IT has always existed, and shadow agents are just the latest version of it.”

The answer isn’t to lock things down, however, he says. At AppDirect, Sen gives employees a “proper digital playground,” and in response to employee demand, his team built an AI-powered coding service called Devs.AI.

“We built Devs.AI so our employees can build and innovate freely, but IT has full visibility into usage and costs and the assurance that company data isn’t being leaked to the world,” he adds.

Citizen AI strategies, like the one at AppDirect, are on the rise, but require consistent monitoring. If one in four employee agents are deactivated, for example, IT leaders should pay attention, Sen says.

“Failing and learning is fine,” he adds. “Failing silently is not. You need visibility into what your agents are doing before a small problem becomes a serious one.”

Still, Sen doubted reports of a small percentage of employee-created agents going rogue.

“When an agent goes rogue, that usually means the agent did exactly what it was told, and what it was told wasn’t right,” he says. “That’s on the creator, not the agent.”

Creating a path for good ideas

Andrew Sales, chief methodologist at agile methodology vendor Scaled Agile, also sees widespread agent deactivations as a strong signal for IT leaders to investigate.

“When agents are built quickly and outside a formal model, there often aren’t clear boundaries around what they can do, what data they can reach, or when a human needs to step in,” he says. “So it’s not surprising that some have had to be shut down.”

AI governance is important, but it shouldn’t focus only on preventing bad outcomes, Sales notes.

“It should also create a path for good ideas to move from individual experimentation into enterprise capability,” he explains. “Organizations need a way to identify what’s working, standardize it, make it safe, and scale it responsibly across teams. Done well, that same framework that catches the agents that go wrong is what lets the ones that go right spread.”

What happens once building software stops being expensive? That’s the question at the center of this piece, and I think it’s about to matter for every CIO/CTO managing an enterprise technology budget.

For decades, that expense has quietly shaped how enterprises operate. When custom development takes months and a full team, companies buy SaaS products instead. When engineering capacity is limited, CIOs/CTOs prioritize a backlog. When a business unit wants a new application, it competes with everyone else for budget and developer time. Enterprise IT’s whole structure exists partly because software has always been hard to make.

A recent example from Perplexity convinced me that assumption is starting to break down faster than most of us expected, and it’s worth walking through in some detail before getting to what it means for the rest of us.

The buy versus build math is shifting

Perplexity has disclosed that two engineers, working with hundreds of AI coding agents, built a custom database called CobbleDB in roughly two months. This was not a prototype. CobbleDB is a roughly 40,000-line Rust key-value store that now handles part of Perplexity’s production search traffic, built to replace some DynamoDB reads after the company decided it wanted more control over latency and cost.

The numbers are hard to ignore. According to reporting by The New Stack, Perplexity cut its median read latency by more than 80% and expects to save at least 20% on cost compared with DynamoDB, though the comparison wasn’t a controlled benchmark and the savings estimate leaves out the cost of maintaining a custom database. Even with those caveats, two engineers built a substantial piece of infrastructure in eight weeks, and this isn’t a story about one company’s database.

This is already playing out at a smaller scale. Payhawk CEO Hristo Borisov described replacing a commercial performance-management product costing $70,000 a year with software his company built itself using AI-assisted development. Microsoft is pushing the same idea into the broader workforce with its 365 Copilot App Builder, which lets an employee describe an application in plain language and get a working version in minutes.

The same shift is happening at the opposite end of the size spectrum too. Starbucks is reportedly building AI-developed replacements for a Microsoft system that tracks inventory and an IBM platform that manages maintenance, according to a Bloomberg report cited by Fortune. The coffee chain spends roughly $400 million a year on software, and CTO Anand Varadarajan has told employees there are “clear opportunities to reduce the spend in software.” Some of the internally built systems could launch by the end of 2027, pending testing. A specialized production database, a business user’s lightweight app and a Fortune 500 company’s attempt to displace two enterprise vendors at once look like different stories, but I think they are the same trend at different levels of complexity: creating software is getting cheaper, and that changes what enterprises can justify building themselves instead of buying.

AI does not remove the real costs of custom software. Someone still has to understand the business problem, design the architecture, validate the output, secure it and operate it. Perplexity kept its two engineers in control of CobbleDB’s architecture and production environment throughout, and that distinction matters: agents accelerated the work; they did not replace the judgment behind it.

Abundance creates a different problem than scarcity

Enterprise IT has spent decades managing a shortage of development capacity. There are always more requests than developers and more requirements than teams can deliver on schedule. Now picture that constraint loosening. A finance team builds its own reconciliation tool instead of filing a ticket. Sales generates an app that combines CRM data with account research. A developer asks an agent for a specialized utility instead of writing it by hand. None of these individual choices looks unreasonable, but together they add up to an enterprise software environment that looks nothing like the one most CIO/CTOs are managing for today. The organization may still have 500 applications in its official portfolio, and underneath that could sit thousands of generated tools, scripts and workflows that nobody centrally tracks.

From a risk and compliance standpoint, that gap is more than an untidy IT footprint. Most control environments assume software enters through a small number of known channels such as procurement, a formal development lifecycle or a change advisory board. Every control that matters (segregation of duties, access provisioning, periodic recertification) gets attached to software at one of those checkpoints. A tool generated by an employee in an afternoon skips all of them. It gets built, connected to whatever data it needs and put into use without ever crossing a point where someone was responsible for reviewing it. Control frameworks are built on the assumption that risk gets caught at intake. AI-generated software does not have an intake.

The exposure compounds because nobody owns the exit either. A reconciliation tool built for a six-month initiative does not get decommissioned on a schedule the way a vendor contract does or a system gets retired at end of life. It keeps running quietly, holding whatever access it was given on day one, with no control owner accountable for revisiting that access once the project that justified it has ended. Assigning a control owner and an expiration date at the moment someone decides to build would close that gap, and right now almost nobody does it.

There is a second, quieter shift happening alongside all of this. When creating a new tool is easier than finding out whether one already exists, people will default to creating one. I think that flips one of the oldest assumptions in software: creation is expensive and reuse is cheap. AI is making creation cheap while discovery and reuse stay exactly as hard as they have always been, and for a risk function that means the population of unreviewed software an organization is carrying grows faster than any control process built for the old economics can absorb.

CIO/CTOs should start preparing for abundance, not scarcity

Developers don’t disappear from this picture. If anything, the Perplexity example argues the opposite: when a system genuinely matters, experienced engineers still make the architectural calls, test the assumptions and take responsibility for what reaches production. What changes is how much software those same people can create and oversee at once, and that shifts the question CIO/CTOs need to be asking. It used to be whether a team could build something. Increasingly, it’s whether it should, whether the organization already has something like it, who owns it and what happens when the person who built it moves on. Those aren’t engineering questions. They’re portfolio and governance questions, and most organizations don’t have a clear owner for them yet.

There’s a pattern in how enterprises absorb this kind of shift. When storage got cheap, companies didn’t end up with fewer data problems; they accumulated far more data. When cloud infrastructure became easy to provision, the worry shifted from “can we get the compute” to “how do we control the sprawl and the cost.” Software is headed toward the same transition, and the CIO/CTOs who prepare for abundance now will have a real advantage over the ones still planning around scarcity.

Perplexity’s CobbleDB is interesting because of what the company built. It’s more interesting because of how few people it took to build it. If two engineers augmented by AI agents can produce a production database in eight weeks, it’s worth asking what the rest of the workforce, technical and nontechnical, will be able to create as these tools keep improving. That question belongs on the same agenda as budget, headcount and control ownership planning, not off to the side as a curiosity for the engineering team to sort out on its own.

Enterprise IT has spent decades getting faster at building software. That was never going to be the hard part. Knowing what you own, and when to retire it, is.

For years, one of the practical constraints in software testing was time. Writing test cases takes time, preparing data takes time, regression takes time and analyzing what happened after an incident can take even more time. AI is changing this very quickly. Today, a QA engineer can generate test data, write scripts, analyze logs or create dozens of test cases in seconds. From the outside, this looks like an obvious productivity win: if we can create more tests faster, quality should improve as well.

Our experience shows that it is not that simple.

At Gurtam, we have been experimenting with AI in QA for some time. We tried different models, worked on prompts, used AI for generating test cases from documentation and eventually built our own internal assistant for this purpose. The technology is already genuinely useful, but the more we use it, the clearer one limitation becomes: generating tests is becoming easier much faster than evaluating whether those tests are actually useful.

This distinction matters, because volume and quality are not the same thing.

More test cases do not automatically mean better testing

Test generation seems like one of the most natural applications of generative AI. A task already has requirements; there is documentation and the model can use that context to produce positive scenarios, negative scenarios and boundary cases almost instantly. Recent research into LLM-based test generation reflects the same opportunity, while also showing that the quality and usefulness of generated tests remain highly dependent on context, evaluation methods and human expertise.

In practice, we often see two extremes. If there is a lot of documentation, AI can generate a  large number of cases, many of which add little value. They may look technically reasonable, but they do not necessarily improve coverage in a meaningful way. The QA engineer still has to review them, understand which cases matter and remove the rest.

The opposite happens when documentation is incomplete. In that case, the generated tests are often too superficial. They cover what is explicitly written, but they miss relationships, dependencies and risks that are obvious only if you understand the product and the surrounding system. The output can still look convincing, but that does not mean it gives enough confidence in the quality of the feature.

This is where AI exposes a familiar problem rather than eliminating it. A model can work only with the context available to it. If important product knowledge lives in people’s heads, in previous incidents or in an understanding of architecture that was never documented, the generated test cases will not magically contain that knowledge.

We built our own assistant to see how far automation could go

To make test generation more practical, we built an internal assistant. The workflow is simple: a QA engineer gives it the number of a task from our tracking system, the assistant finds the relevant documentation, combines that information with the task and generates test cases.

We also created an interface where these cases can be reviewed, edited and removed if they are unnecessary. Once the QA engineer is satisfied with the result, the final set can be sent directly to the system where we store our test cases.

This already removes a noticeable amount of repetitive work, which is useful on its own. But naturally, once you automate this much, the next question appears: can we remove the review step as well?

In theory, it sounds reasonable. A product team creates and documents a task, a developer starts working on it and the AI assistant automatically generates the test cases. By the time development is finished, everything required for testing is already prepared.

We considered such a flow. So far, though, our experience has not given us enough confidence to run it without human validation. The issue is not that AI cannot generate tests. It clearly can. The issue is that it can still produce a large number of unnecessary tests and at the same time miss something important.

That means the review stage is not simply cosmetic. It is still part of the actual quality work.

AI is already very useful when the task is clear

This does not mean I am skeptical about using AI in QA. There are many areas where I think it already works very well.

Test-data generation is an obvious example. If we need boundary values, test JSON objects or large amounts of synthetic data with different parameters, AI can prepare this much faster than a person would manually. Log analysis is another strong case. Sometimes we deal with very large volumes of logs that no engineer would realistically read line by line. AI can help identify what happened during a particular incident or at a specific point in time and narrow down the area we need to investigate.

It is also useful for generating small scripts or applications that remove repetitive work. This can include scripts for load testing, data generation, file analysis, one-off automated tests or simple interfaces for test environments.

The common pattern is that the engineer already understands what needs to be done. AI helps execute the task faster. In those scenarios, it works as a very strong assistant.

Where I would be much more careful is when we move from execution to decision-making.

The risky part is not automation itself, but giving AI the final say

I would not currently trust AI with the complete process of writing and maintaining automated tests without supervision. In our own experiments, we have seen how easily it can generate unnecessary tests while still missing important scenarios.

The same applies to complex, non-linear business logic. A model can process requirements, but understanding what is risky for the business or what behavior is acceptable in a particular context often requires more than what is written in documentation.

I would also not rely on AI alone for deciding whether a release is ready. Release quality is not simply the sum of passed test cases. You need to understand what has changed, where the risks are, what dependencies exist, what was not covered and what the possible business impact is if something goes wrong.

Data is another concern. Sensitive information disclosure is already recognized as a specific risk in LLM applications, particularly when systems process personal data, confidential business information or credentials. I would therefore be especially cautious about giving external models access to information that an organization cannot afford to expose.

For now, the simplest principle still works well: trust, but verify.

The role of QA is changing because the routine part is shrinking

If AI takes over more repetitive regression work, basic test generation or routine execution, that does not mean QA becomes less relevant. It creates time for the things teams often postpone because there is never enough capacity.

Testing architecture is one example. Risk modelling is another. There are also non-functional testing, test infrastructure, shift-left practices and involvement in business decisions before they become development problems.

This is one of the reasons I see the profession moving towards Quality Engineering. Traditional QA is often associated with checking whether the finished product behaves according to requirements. Quality Engineering is broader. It means trying to reduce the possibility of defects appearing in the first place by influencing processes, architecture and automation.

This also changes what we expect from experienced QA engineers. A technically strong tester should be able to test almost any task in the project. A strong Senior QA needs to see the project as a whole: its architecture, dependencies, risks and connection to business decisions. In a mature team, such a person becomes a link between business and development, not just the person who verifies a feature at the end.

AI makes this transition more visible because the mechanical part of the work is becoming cheaper. The value moves towards understanding what actually needs attention.

We will also have to test AI itself

There is another side to this shift. AI is not only becoming a tool for QA; it is also becoming something QA engineers will increasingly have to test.

We are already seeing more assistants, decision-making systems and AI-based product features. There are still no universally established practices for testing all of them, but I expect this to become a normal part of QA work. The direction is already visible in emerging AI assurance frameworks: NIST, for example, is developing structured approaches to test, evaluation, verification and validation of AI systems across LLMs, multimodal models and AI agents. Validating hallucinations, checking for toxicity, testing data leakage and resistance to prompt injection may soon become standard requirements in some QA roles.

This makes the idea that AI will simply remove the need for QA difficult to take seriously. The more software relies on AI, the more new quality risks appear.

AI models can make mistakes, hide errors, adjust tests to incorrect behavior or generate code with bugs. Another AI model may then fail to identify those same problems. Giving such a system full responsibility for release acceptance without human control is hard to imagine in any serious production environment today.

The important question is no longer whether AI can generate tests

It can.

The more useful question is what happens after generation. Which cases are actually valuable? Which ones are redundant? What is missing? Which risks are not visible in the documentation? And does the final set of tests give us enough confidence in the product?

AI is making the production of testing artefacts much faster. What it has not removed is the need for judgement.

For QA engineers, that means the profession is not disappearing. It is becoming more analytical, more engineering-oriented and more connected to product and business decisions.

And at least for now, the final responsibility for understanding whether the system is actually good enough still belongs to a person.

Tools such as Anthropic Claude Code or OpenAI Codex have changed the face of software development, and all the signs are that this investment is set to increase further. But is paying a monthly subscription (and perhaps additional usage fees) cost-effective? Will the increasing level of investment in AI-generated software prove to be worthwhile?

That’s a question several economists from the US National Bureau of Economic Research have attempted to answser, at least indirectly. Their paper, snappily entitled The Macroeconomic Effect Of AI: Sizing The Software Engineering Channel, attempts to calculate how much AI has increased the productivity of software engineers in enterprises outside the software and semiconductor industries by looking at their share prices.

“The main idea is that if AI raises the productivity of software engineers, then firms that rely more heavily on them should benefit more. Therefore news about AI generates higher expected profits for these firms. These profits are capitalized into larger stock price responses. Combining these stock price responses with a model, we can pin down the increase in software engineering productivity expected by financial markets,” the researchers wrote.

And the answer? “From November 2022 to December 2025, AI increased the market’s expected present value of software engineering productivity by the equivalent of a permanent 32.6% productivity increase.”

That’s not to say that your software engineers will be that much more productive, but it’s a starting point for allocating budget between AI tool use and payroll.

OpenAI says true agentic AI has finally arrived, pushing beyond the trivial capabilities of early-stage virtual assistants.

This week at OpenAI Dev Day, the company introduced Dots, which CEO Sam Altman described as “remarkably capable, always-on” agents powered by GPT‑6 Astra. Dots have their own cloud computer, can be accessed in ChatGPT, Slack, or Teams, and plug into more than 4,000 apps based on human-set boundaries.

In a keynote, Altman said using it will feel like “a whole new way to work with AI.”

“It can hugely magnify your ability and expand your potential, working 24/7 to take on things that you don’t want to do, so you can focus on higher-level work,” he said.

OpenAI also announced a slew of other new capabilities and tools, including GPT-6.1 Sol, a cheaper and faster sibling of GPT-6.1 Astra, which was shelved earlier this week due to safety concerns. Additionally, Codex is also now in the cloud, Codex CLI has voice control and can help developers inspect, edit, and run code locally, and a new Agents API supports computer use and provides components like harnesses, hosting, memory, and multi-agent controls.

Dots goes beyond ‘trivial’ tasks

Early virtual assistants have been useful for quick handoff tasks like booking reservations, but that is “trivial relative to what the technology can do,” Altman contended in his keynote.

Taking that to the next level, OpenAI’s new Dots can understand what’s happening in a user’s workflows and learns over time without requiring constant human instruction, he explained. Soon, users will be able to access Dots outside ChatGPT by interacting with it through text messages or even by calling the agents on the phone to discuss updates, changes, and weigh in on decision-making.

“You can delegate ambitious pieces of work the way you would to a high agency engineer or a chief of staff,” Altman said. Dots can monitor incoming bug reports and propose fixes, draft pull requests (PRs), or take on tasks like kicking off the next year’s budget planning cycle.

Altman provided the example of migrating an app off a legacy API. This can be difficult, because the API might be used all over a code base, he said, and it could break as developers start making changes. But Dots can trace dependencies and determine what needs to change, run tests, and suggest next steps.

“Think about how you would have done that the old way,” Altman noted. “How many people would have been involved? How much time would it have taken them? What could they have done instead?”

Dots is now available to all ChatGPT Pro, Business Premium, and Enterprise users. OpenAI is also now previewing specialist Dots for enterprises, and is working with Microsoft to integrate Dots into Agent 365. These will serve as virtual teammates to help scale more intensive work in accounting, marketing, or legal, Altman explained.

Carmi Levy, an independent technology analyst, said of everything announced at DevDay 2026, Dots might be the most impactful, as it represents OpenAI’s definitive move into AI agents.

While Meta has been grabbing headlines with its app store-topping Muse, OpenAI’s offering is potentially more relevant to enterprise decision makers who are still trying to figure out how agents can fit into their corporate AI development and deployment roadmap, he noted.

“It allows enterprise customers to build on their pre-existing investments in OpenAI’s stack, and represents a familiar adoption path for developers,” he said.

Cheaper and faster sibling of Astra

OpenAI launched GPT-6 Astra to a limited group of users earlier this month, calling it state-of-the-art in computer use, browsing, software engineering, cybersecurity, science, and professional work. But its generally availability was canceled this week after the model failed critical internal safety and alignment tests.

OpenAI learned from the experiment, Altman said, with early testers demanding: “make it cheaper and make it faster.” The answer to that is GPT 6.1 Sol, which provides near Astra level intelligence at one-fifth of the price. Cached inputs cost $0.10 (US) per million tokens, 95% less than standard input pricing. This makes it cheaper for agents to work through longer tasks, reuse context, and ruminate on solutions. Example uses include multi-step business workflows, code writing and debugging, and document analysis.

GPT 6.1 Sol is “smarter than Astra in some ways, and it will become your daily workhorse,” Altman said. It is now available to all Plus, Pro, Business, Enterprise, and Edu users of ChatGPT Work and Codex, and will soon be offered in an ‘Ultrafast’ plan, with up to 8X faster token generation.

Levy noted that GPT 6.1 Sol reduces the cost curve for enterprises looking to deploy AI agents at scale, all while “avoiding some of the privacy/safety/integrity baggage of the now-stillborn GPT 6.1 Astra.” It effectively shifts the economics of AI agents by dropping the price of resource-intensive development activities like querying repositories, running tests, and iterating code.

“It doesn’t have quite the power of Astra, but that was never what the average developer was looking for, anyway,” Levy noted. “Affordability still drives development decisions, and by leading with Sol, OpenAI removes one more barrier to broad-based adoption.”

New Codex capabilities, assurances around safety

In a much-anticipated move, OpenAI has introduced Codex Cloud, giving developers the ability to move coding tasks between devices without losing threads. “You don’t have to worry about closing your laptop in the middle of a run,” Altman said. “Your agents just keep working, wherever you are.”

Meanwhile, new Codex CLI capabilities allow developers to start, steer, delegate, and track tasks with voice commands, and a new Codex Security Cloud helps defenders identify vulnerabilities and prepare fixes.

Altman addressed the top-of-mind security and governance issue in his keynote. “The best version of AI is not about making people cogs in a giant machine,” he said, noting that there are some things that should not be automated.

“People often talk about AI as a new industrial revolution. I find that quite off-putting,” Altman said. “The future, if we get this right, can be much more like a new renaissance than a new industrial revolution.”

This article originally appeared on InfoWorld.

Microsoft’s Copilot super-app has arrived, two months after CEO Satya Nadella confirmed it was in development. It combines conversational Chat, the autonomous Cowork agent, a redesigned coding environment named Code, and Autopilot, the persistent agent formerly known as Scout, into a single Copilot experience.

The idea is to make those capabilities look less like separate tools and more like different ways of getting work done through a unified experience. The end goal is to enable users to describe what they want to accomplish without choosing a mode themselves, and with Copilot routing the task to Chat, Cowork, Code or another capability, Microsoft said.

The individual pieces of this experience are not entirely new, and build on  launches and consolidation moves that Microsoft has made over the past several months.

Nadella first described the unified Copilot architecture during an earnings call in July. He said it would bring chat, agents and business workflows into a single AI workspace while separating the orchestration layer, context and memory from any one AI model. Microsoft subsequently began unifying its consumer and Microsoft 365 Copilot apps ahead of the broader overhaul.

But Microsoft laid much of the groundwork in the period after its November 2025 Ignite conference, with the launch of Cowork for delegated multistep work, Scout for persistent agentic tasks, and natural-language app-building capabilities that have now evolved into Code.

The broader change goes beyond bringing those Copilot experiences together. With Friday’s updates, Microsoft is also adding components and infrastructure aimed at turning Copilot from an AI assistant embedded across Microsoft 365 into a broader orchestration layer for enterprise work.

These include Fabric IQ and Work IQ for enterprise context, Copilot Managed Runtime for running AI-built applications, a unified plugin registry for connecting capabilities, and usage-based billing and FinOps controls for managing agentic workloads and AI spending.

More enterprise context could boost productivity

The inclusion of Fabric IQ in Chat and Cowork, along with Work IQ’s access to data and workflows in Dynamics 365 and Power Platform, will make Copilot more effective for enterprise tasks by giving it a broader understanding of an organization’s data and workflows, potentially reducing hallucinations and improving productivity, said Abhishek Satapathy, principal analyst at Avasant.

“The practical shift is from AI that knows information to AI that can connect what happened, why it happened and what needs to happen next. For example, a business insight can increasingly become the starting point for analysis and follow-up action rather than requiring the user to manually move that context between reports, documents, conversations and business systems,” said Satapathy. “This is particularly relevant for analysts, managers and operations teams working across functions.”

Fabric IQ’s integration with Chat and Cowork is now generally available. Microsoft plans to integrate it with Code soon through its Frontier program. Work IQ will enter public preview over the next month, it said.

Redesigned Code expands the scope of software creation

Productivity is also the focus of Microsoft’s redesigned Code environment.

It “broadens the audience for software creation” by addressing the middle ground between traditional development and simple automation, bringing more use cases into the scope of what business users can build, including those that may be too narrow for a formal development project but too complex for basic automation, Satapathy said.

That means more internal applications, dashboards and workflow tools can potentially be built without going through a traditional development project, while developers can use the same environment to accelerate application creation and focus on more complex engineering and production requirements, he added.

Alongside Code, Microsoft is introducing Copilot Managed Runtime, a governed hosting environment for applications built with Code, Cowork and Copilot Studio. The runtime allows those applications to run within an organization’s Microsoft 365 environment while giving IT control over security, governance and access to live data, Microsoft said.

For enterprise developers and IT teams, the runtime could provide a common production layer for AI-created applications, helping enterprises move applications from experimentation and prototyping into production without having to create a separate operating model for each one, Satapathy said.

It could also help IT teams and CIOs curb shadow IT and application sprawl, said Manoj Chandra Jha, principal analyst at Nord-IQ Research. In its governed environment, IT departments can managed applications and agents created by employees consistently for security, identity, policies, lifecycle management, observability and deployment.

The new Copilot Managed Runtime is currently in public preview and will also be accessible inside the redesigned Code experience, Microsoft said. That experience will roll out to Microsoft’s Frontier program at the end of the month, with broad availability in the coming weeks, it added.

New FinOps tools could help CIOs judge business value

Beyond productivity, faster scaling of AI applications and curbing application sprawl, Microsoft is also giving enterprises more tools to manage the cost of agentic AI by expanding its cost-management capabilities in Agent 365 to include Code and Copilot Managed Runtime.

These capabilities will allow administrators to manage AI spending policies at scale, control access to model families and route credit requests through existing approval workflows, while giving visibility into the outcomes generated by agentic workloads to decide where to sustain, expand or optimize usage, the company said.

End users will also be able to view their credit usage, remaining balances and usage history directly in Copilot, helping them manage their AI usage, it added.

For Bhupendra Chopra, chief revenue officer at IT consulting firm Kanerika, the expanded FinOps capabilities will be critical for CIOs, particularly for understanding if agentic workloads and automation are delivering sufficient business value and if they need to be reworked.

“These capabilities can reveal correction rates for agents. If employees regularly have to undo an agent’s work, that can indicate stale context, poor business rules or an unreliable data foundation before it shows up as a larger operational problem,” Chopra said.

“These capabilities can reveal another insight: whether the time supposedly saved by automation actually translates into a measurable business outcome. Enterprises can automate 20 minutes of work but simply spend that time elsewhere, meaning the productivity gain only matters when it produces a measurable result,” he added.

Usage-based billing extended

Alongside these FinOps capabilities, Microsoft is also extending usage-based billing to more of the capabilities being brought together under Copilot. The model is not new to the platform, having been introduced for Cowork when the agent became generally available in June.

While Cowork, Code and Autopilot, along with new long-running agentic capabilities and frontier models, will use usage-based billing, Chat and Copilot across Microsoft 365 will remain covered by the user subscription license, the company said.

That distinction could require CIOs to think about AI spending differently from traditional productivity software, Satapathy said.

Instead of budgeting primarily around the number of users with Copilot licenses, CIOs may need to consider what work is being delegated to agents, how much that work consumes and what business value it produces, he added.

“Two employees with the same Copilot license, for instance, could generate very different AI costs depending on whether one uses Copilot for assistance while the other delegates longer-running work to agents,” he further said.

However, that might still be some way off, with several of the key capabilities still in preview or yet to roll out.

Home, the new starting point in Copilot where Chat and Cowork come together, will begin rolling out through Microsoft’s Frontier program in the coming weeks, while Autopilot is expanding to private preview at the end of the month, Microsoft said.

This article first appeared on Computerworld.

Last month I made the case for an ROI exchange rate: the formula you negotiate with finance before deployment that converts KPI movement into dollars. One point of first-call resolution equals this many dollars. One hour of engineering time recovered equals that many.

A common objection was a version of the same question. Fine, we agreed on what the benefit is worth. What did it cost?

That column is empty at most companies. Not “roughly known” or “we’re working on it.” Empty. And an empty denominator makes the numerator useless. You can prove the KPI moved and still lose the argument, because the CFO is not funding improvements; she is funding improvements that cost less than they return.

Which brings me to the most-discussed AI budget story of the year, and why I think almost everyone drew the wrong lesson from it.

What Uber actually ran out of

We owe Uber some thanks for being this transparent. They rolled out Claude Code in December 2025. By February, 32% of engineers were on agentic coding tools; by March, 84%. Somewhere in there, the company burned through its entire 2026 AI budget in four months, a number CTO Praveen Neppalli Naga confirmed to The Information in April. In June, Bloomberg reported the response: a hard cap of $1,500 per employee per month, per tool.

Simon Willison called the cap rational, and he is right. Given a budget set before agentic coding existed, a ceiling was the correct emergency move. I would have done the same thing.

But look at what Uber’s COO said when asked whether the spending was working. Andrew Macdonald, on the Rapid Response podcast: “It’s very hard to draw a line between one of those stats and ‘OK, now we’re actually producing like 25% more useful consumer features.'”

That is not a cost complaint. That is a measurement complaint. Uber did not cap spending because tokens are expensive. It capped spending because it could not price what the tokens were buying, and you cannot defend a number you cannot connect to anything. The cap is what you reach for when the exchange rate column is empty.

Here is the part that should worry you more than the budget overrun. Software development is the best-instrumented workflow in the enterprise. Pull requests, cycle time, deploy frequency, escaped defects. It is the one function that already has the scoreboard I spent last month telling everyone to build. Uber had all of it. And cost per task still was not on the board.

If it is missing there, it is missing everywhere.

Two levers, one of them untouched

Look at how the industry has responded to token maxing: quotas, per-seat caps, model downgrades, approval gates, dashboards. Every one of those controls how many passes you make.

Not one of them touches what a pass costs.

That is the whole argument. There are two levers, and the industry has been yanking on one of them for six months while treating the other as if it does not exist.

The compounding nobody budgets for

In a naive agent loop, the full conversation history gets re-serialized and re-injected at every step. Message history grows linearly. Billed input tokens grow quadratically.

Run a modest 20-step loop that adds 1,000 tokens of history per step. Multiply 20 by 1,000 and you get 20,000, which is the number most people carry in their heads. The actual billed input is 210,000, because step 19 pays for everything steps 1 through 18 said.

Longtime readers will recognize the shape. In June, I argued that AI cloud strategy is a physics problem, because 50 milliseconds of cross-region latency does not cost you 50 milliseconds; it costs you 50 milliseconds times every hop in the loop. Same structure, different axis. Trim 800K of junk off one call and you save 80% of one call. Trim it off every hop and you save 80% of a quadratic.

“But we have prompt caching”

Every major provider now discounts re-sent prefix tokens. Anthropic bills cache reads at 0.1x standard input, with a 1.25x premium on the write. OpenAI’s newer models landed on the same 0.1x multiplier. Google’s implicit caching runs about 75% off.

So, does caching kill the argument? Run it and see. Same loop, reads at 0.1x, writes at 1.25x:

Caching takes 79% off the uncached bill. It is the single largest cost lever available and every team reading this should be using it. It also leaves you at 2.2 times the number you had in your head. Caching flattens the quadratic; it does not remove it entirely and it comes with a caveat.

Caches are keyed on the exact prefix, so any change at the front invalidates everything behind it. If your retrieval pipeline injects freshly selected chunks near the top of the context each turn, you are not just paying for tokens that did not earn their place; you are breaking the cache for every stable token that follows. Model a 25% prefix-break rate on that same loop and 44,000 effective tokens become 90,000.

Order the prompt stable to variable: system prompt, tool definitions, long-lived context, then the current turn. Then measure the hit rate. That is an afternoon of work, and it protects your best cost lever.

The part that makes this more than a FinOps memo

Usually cost reduction costs you quality. You buy the cheaper thing, and you get the cheaper thing.

Not here. The low-relevance context you are paying to send is the same context degrading the answer. This is the load-bearing claim in the piece and there is a lot of vendor handwaving in this space, so here are two peer-reviewed sources, none of them selling retrieval infrastructure.

The canonical result is Liu et al., “Lost in the Middle” (TACL, 2024): accuracy follows a U-shaped curve across the window, strong at the edges and weak in the middle, and it drops as input grows even on models built for long context.

The one that surprised me is Du et al., “Context Length Alone Hurts LLM Performance Despite Perfect Retrieval”(Findings of EMNLP, 2025). The authors held retrieval at perfect and grew the input anyway. Accuracy still fell, 13.9% to 85% depending on model and task, well inside advertised limits. It held when the filler was whitespace. It held when the irrelevant tokens were masked out entirely. Most of the damage landed inside the first 7K.

The tokens you did not need are not free even when they are cached. They are diluting the reasoning you are paying for. Cheaper and more accurate, same move. That is not a trade-off; it is a mispricing.

The question becomes: of the million tokens I could send, which 200K earn their place?

That is not a procurement question or a policy question. It is a retrieval question, answered out of your RAG pipeline or your agentic memory. And unlike a spending cap, it has an engineering answer.

Six ways to pick the right 200K

Cheapest to hardest, with the business consequence next to each, because a CIO who will never touch a chunking strategy still needs to know what skipping it costs.

1. Filter before you search. Metadata and scope narrowing costs nothing and kills most irrelevant candidates before semantic search runs. You are paying a similarity search to rediscover what you already knew.
2. Rerank, don’t just retrieve. Vector search optimizes recall; at the point of injection, you need precision. Without it, precision is whatever your embedding model happened to give you.
3. Chunk on meaning, not character count. Fixed-size chunking splits reasoning that needed to stay together. You pay 3x for one idea and the model sees it in pieces.
4. Compact, don’t accumulate. Summarize prior turns instead of re-sending raw transcript. This is the only item that changes the shape of the curve.
5. Dedupe across turns. Agent loops re-retrieve the same chunks repeatedly and almost nobody measures it. You are paying several times per session for identical text.
6. Know when to stop. At what point does the next chunk stop paying for itself, in dollars and in dilution? No answer means you do not have a retrieval strategy; you have a default.

One, two and five are checkable this week without a budget cycle.

The number you take back to finance

Number six deserves pulling out of the list, because it is the only one that produces a figure rather than an improvement.

Cost per task. Not cost per token, which measures your vendor’s pricing. Not cost per seat, which measures your headcount. Cost per resolved ticket, per merged pull request, per closed claim. The denominator under the exchange rate. The other five are how you improve it; this one is how you report it, and it is what lets you argue the bill up when it is earning. No company under a blanket cap can have that conversation.

Objections, and one honest caveat

“Context windows keep growing and models keep getting better at using them.” Both true, and neither makes paying for irrelevant tokens rational. The Du result suggests length itself carries a cost that capability gains have not erased, and the compounding is structural: it gets worse as agents get more autonomous, not better.

“We already do RAG.” A pipeline with fixed-size chunks, no reranker and no eval is tokenmaxxing with extra steps.

“Caps worked for Uber.” They controlled the budget, which was the immediate problem. Ask what they did to cost per shipped feature, and whether your best engineers are now the ones rationing hardest.

The caveat, because I would rather say it than have it said to me: some workloads genuinely want the whole document in the window. Long-form legal review, whole-codebase refactors, anything where relationships between distant sections are the point.

The ledger

A spending cap controls the bill. It is the right emergency move and a permanent admission that you never built the measurement.

Cost per task is the other column. It tells you the difference between an expensive workload and a wasteful one, and those are not the same thing.

Context length is the lever you do not control. Cost per pass is the one you do.

Every successful enterprise AI deployment begins long before anyone types the first prompt. Teams spend weeks defining business metrics, documenting policies, connecting enterprise systems, and explaining the rules and exceptions that allow an AI application to answer questions correctly.

Then the application launches and the business keeps moving. Finance changes how it recognizes revenue, sales introduces new pricing, legal revises a customer policy, or product launches a new capability. Each decision changes something an AI application needs to know, yet those changes rarely reach every application that depends on them. A definition updated in one system remains six months old in another, while a policy legal replaced last week continues guiding a support agent.

Enterprises already know how to keep data accurate and secure, but the meaning attached to that data often lives across documents, prompts, code, and individual applications. AI depends on both, and enterprises have spent far more time building infrastructure for data than for the business knowledge required to interpret it.

Companies know how to manage data, but they don’t yet know how to manage context

Context captures what data means inside a particular company, including how finance calculates revenue, which customer policy applies to a situation, and when an exception overrides a rule. Data can tell an AI what happened, while context tells it how the business understands what happened.

Revenue offers a simple example. A customer record might show $500,000 in annual revenue, and the number might be completely accurate, but an AI application still needs to know whether the company considers that ARR, recognized revenue, bookings, or contracted value. It needs to know which products count and whether finance recently changed the definition. Those answers come from decisions the business has made about how to interpret the number.

The same problem runs through customer policies, product information, contracts, and support procedures. Retrieval can locate the relevant information, but the application still needs the business rules that govern how to use it.

Today’s AI implementations create tomorrow’s maintenance problems

I’ve seen companies solve this in almost every way imaginable. Business knowledge ends up in GitHub repositories, internal documentation, prompt libraries, and shared folders, while someone copies a policy into ChatGPT, another team builds an MCP server, and the analytics group maintains its own definitions in Looker. RAG pipelines retrieve documents, and each approach can get an individual application working.

Six months later, somebody has to remember everywhere that knowledge went when the business changes it. When finance changes a definition or legal changes a policy, someone has to know which prompts, documents, and systems contain the old version.

One business decision can create work across dozens of AI implementations because the organization copied the knowledge behind that decision into dozens of places. When someone changes a value in an authoritative data system, applications querying it can receive the new value. When someone changes the meaning of that value, companies rarely have an equivalent process for recording the change and distributing the approved definition.

Software engineering solved this problem decades ago

When I look at how companies manage context for AI today, it reminds me of software development before version control, code review, automated testing, and structured release processes became standard.

The Software Development Lifecycle connected those practices into a repeatable process, allowing developers to change software while preserving ownership, history, testing, and release controls. Companies need comparable discipline for context, including a consistent process for deciding who owns a definition, how someone changes it, who reviews the change, how applications test it, and how the new version reaches every system that needs it.

Enterprise AI needs a Context Development Lifecycle

I don’t think this requires inventing an entirely new set of enterprise processes. Much of the work already happens somewhere inside most companies, but today it happens separately. A Context Development Lifecycle can connect six activities: defining context, encoding it, reviewing it, testing it, publishing it, and keeping it current.

Business owners should define meaning within their domains. Finance owns financial definitions, legal owns the interpretation of policies, product owns relationships between products and capabilities, and support owns operating procedures.

Data and engineering organizations can then encode those definitions so applications consume them consistently. The representation will vary, but applications should draw from the same definition instead of translating it independently.

Then you have to decide who gets to change that context and who needs to approve it. Security can control access to sensitive information, legal and compliance can review regulated material, and domain owners can approve changes within their areas.

Application owners should test proposed changes against situations their systems encounter. If legal changes a refund policy, support can run common customer scenarios and known exceptions against the new version. If finance changes its ARR definition, analytics owners can test representative questions and compare the output with finance’s intent.

Once context passes review and testing, the organization can publish a version with an owner, effective date, and change history. If an agent produces an unexpected answer three months later, someone should be able to trace which definition it used instead of digging through prompts and repositories hoping to reconstruct what happened.

Each stage should leave something concrete behind: an owned definition, a machine-readable representation, an approval record, a set of tests, a versioned release, and a record of subsequent changes.

The process starts again whenever the business changes, giving the company a history of its business knowledge alongside the systems that already preserve the history of its data and software.

The next stage of enterprise AI depends on managing context

Enterprises can already choose among several capable models based on cost, performance, or workload. A more capable model cannot resolve two conflicting definitions of ARR, determine which policy legal intended it to follow, or know that a product rule changed yesterday unless the organization gives it that information.

Companies already know how to answer basic questions about data, including where it came from, who can access it, when it changed, and which system owns it. I want us to be able to answer the same kinds of questions about context. Who defined this metric, when did the definition change, which policy did this agent use, who approved that version, and which applications depend on it?

A Context Development Lifecycle gives companies a way to answer those questions and keep AI applications aligned as the business evolves. Software engineering became dramatically more reliable once organizations developed disciplined ways to manage changing code. Enterprise AI needs the same rigor around business context because an AI application can only stay accurate for as long as its understanding of the business stays accurate.

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.

Vibe coding is rapidly changing who can build software and how quickly an idea can become a functioning application. Using natural-language prompts and AI-assisted development tools, people can translate concepts into prototypes without mastering every element of traditional software engineering.

The experience reminds me of Topgolf.

Topgolf creates a carefully curated, technology-enabled environment where almost everyone can feel capable. The tee is automated. Performance is tracked. Wind, water, sand, and other hazards are largely virtual. You can experiment, compete, and receive immediate feedback — all from the comfort of a lounge-like setting.

Vibe coding can create a similar sense of confidence. You describe what you want, AI helps build it, and a working application begins to emerge. The demonstration succeeds, colleagues are impressed, and momentum builds.

Then comes the inevitable question: “How quickly can we put this into production?”

That is when the game moves from Topgolf to Torrey Pines.

On a championship course, the controlled environment disappears. You must account for shifting winds off the Pacific, hidden bunkers, changing pin placements, difficult terrain, spectators, and countless other variables. Success requires more than the ability to strike the ball. It requires course knowledge, preparation, situational awareness, discipline, and the ability to adjust when conditions change.

Production technology environments are no different.

An application that performs well in a controlled setting must now contend with scale, cybersecurity, data quality, privacy, integration, resilience, accessibility, regulatory requirements, technical debt, and unpredictable user behavior. The number of variables expands exponentially — and every variable can affect performance, trust, cost, and organizational reputation.

Across my career as a CIO and CTO, I have seen promising technology initiatives encounter difficulty not because the underlying idea lacked value, but because the organization underestimated what it would take to operate that capability reliably at scale. AI accelerates development, but it does not eliminate operational complexity.

That distinction matters because vibe coding is not simply another developer productivity tool. It changes who can participate in creation. A business leader who previously described a need and waited for a development queue can now sit beside an AI assistant and begin shaping the solution directly. That is a meaningful and welcome shift. It creates faster learning cycles, brings domain expertise closer to the product, and gives the business a more active role in technology delivery.

But democratizing development also democratizes responsibility. The person who can create a compelling application in an afternoon may not yet have the experience to recognize an insecure dependency, an ungoverned data source, a fragile integration, or a design that becomes prohibitively expensive at scale. A successful demonstration answers whether something can work. Production requires answering whether it should operate, how it will operate, who will own it, and what happens when it fails.

This is where experienced technology professionals remain essential.

A skilled enterprise architect is like having Tiger Woods help you read the course: someone with a mental model of the topology, dependencies, and conditions most likely to affect the outcome. The architect can see the dogleg beyond the tee box — the downstream consequences that are invisible during a prototype.

The course ranger resembles the change manager, helping teams navigate competing priorities, shared resources, release schedules, and operational conflicts. Cybersecurity professionals manage the equivalent of those pesky paparazzi trying to get inside the ropes, while also preparing for threats far more consequential than a distracting camera. Data teams act as the performance analysts, measuring behavior, outcomes, crowd reaction, and whether the solution is actually producing value. Platform and operations teams ensure the course remains playable when demand surges or something unexpected happens.

These professionals are not standing in the way of innovation. They are helping the organization play the real course successfully.

Before promoting a vibe-coded application into production, leaders should review a simple production-readiness scorecard:

This review does not need to become a six-month obstacle course. Governance should be proportionate to the application’s risk, reach, and potential impact. A low-risk internal productivity tool should not face the same controls as an application making consequential decisions about customers, employees, or vulnerable populations.

The answer is not to force every vibe-coded experiment through the heaviest enterprise process. That would squander much of the speed and creativity AI makes possible. Instead, organizations need risk-based pathways: a safe practice range for experimentation, a clearly marked route for internal tools, and a more rigorous qualification process for applications that touch sensitive data, critical operations, external users, or consequential decisions.

Technology leaders can make those pathways easier to navigate by providing approved AI tools, reusable components, secure development environments, automated testing, standard integration patterns, and transparent criteria for production readiness. In other words, build guardrails and paved roads rather than relying exclusively on gates. When the safest path is also the easiest path, governance becomes an accelerator.

The goal is disciplined acceleration.

The business also has to accept a different role. Vibe coding should not mean throwing an AI-generated application over the wall to technology once the demonstration is complete. If business teams help create these capabilities, they must remain hands-on collaborators and accountable owners. They understand the domain, intended outcomes, acceptable errors, and human consequences better than anyone. Technology brings the architecture, engineering, security, data, and operational disciplines required to make that capability sustainable. Production readiness is a shared responsibility.

This partnership represents an entirely new organizational muscle. Data and AI literacy provide the foundation, but literacy alone is not transformation. Leaders must learn how to evaluate AI-generated work, challenge confident outputs, understand where automation requires human judgment, and make informed tradeoffs among speed, risk, cost, and value. Technology teams, in turn, must learn to engage earlier and more collaboratively so they are not perceived as impediments arriving at the end of the process.

I am a cautious optimist about AI. Vibe coding can democratize development, accelerate experimentation, and bring business and technology teams closer together. It can also help reposition business professionals from passive recipients of technology to active participants in creating it.

But confidence developed in a controlled environment should not be confused with production readiness. The easier development becomes, the more important it is to strengthen organizational literacy about architecture, data, cybersecurity, scale, and responsible ownership.

The central leadership question is therefore not whether organizations should permit vibe coding. That debate will soon be overtaken by adoption. The better question is how organizations will preserve its creative energy while establishing the discipline necessary to earn trust at scale. Leaders who answer that question well will move faster because their teams will know where experimentation is encouraged, when additional expertise is needed, and what evidence is required before a capability reaches customers, employees, or mission-critical operations.

Perhaps we will eventually reach a world in which AI can immediately transform a vibe-coded idea into a secure, scalable, resilient production capability — making 18 holes at Torrey Pines feel as approachable as an evening at Topgolf.

We are not there yet.

Until we are, organizations must pair AI-enabled speed with sound system hygiene, architectural discipline, testing, governance, and risk management. The objective is not to slow innovation. It is to ensure that what we accelerate can survive — and succeeding on — the real course.

Together, we will get there responsibly.

Some of the most impactful engineering breakthroughs likely make for very boring marketing demos.

Over several decades spent leading development teams, I have seen firsthand how tempting it is to focus engineering efforts on highly visible, flashy new features. I’ve known many developers who get bogged down by the pressure to package every software update with a supremely marketable new element or two that’ll get people talking.

But in my experience, the features that most enhance a user interface are often completely invisible to users.

Performance, reliability and security are not the sexiest features, but they’re crucial elements to a satisfactory user experience. That’s especially true when you’re engineering for users working within complex vertical industries – such as architecture – who count on simple, dependable technology to bring their daily work to life as seamlessly as possible.

My foundational philosophy is that the absolute best software is the kind you can dig into without ever needing to pick up the user manual. Users shouldn’t have to spend valuable time fighting to navigate complex menus, acting as manual data routers who must convert one format to another just to connect the dots. When professionals can focus on using their tool as solely a means to an end rather than a puzzle they have to solve, that is when you know you have done your job well as a developer.

The unsung heroes of successful software: Speed, reliability and security

R&D teams often must fight to justify investing in foundational software improvements because they simply aren’t as visually marketable as shiny new capabilities. But performance is a hidden expectation that great developers cannot afford to ignore.

As a Chief Technology Officer guiding design software development for AEC professionals, I’ve learned modern users have incredibly high standards for speed. This is especially true for younger users just entering the workforce. If they have to wait more than a few seconds for their tool to function as directed, it will come at a cost to their sustained attention and workflow.

Reliability is also paramount for modern tech professionals, particularly as we integrate more automation and artificial intelligence into our workflows. When we implement automation to handle boring, repetitive tasks, our users need to know that the system is worthy of their rock-solid trust and can execute those tasks flawlessly.

To use an example relevant to my market, imagine you’re an architect designing a highly complex, multi-million-dollar project for a new hospital with thousands of rooms. You’re collaborating with dozens of other engineers from multiple disciplines, both structural and electrical, and all of you are working on the same model. If you direct the software to automatically update the wall weights across all the bathrooms in the entire hospital, you’re investing your absolute trust in that software accomplishing the task exactly right without interfering with other modeling being done simultaneously.

If the program is unsuccessful or hinders other parts of the project, the user loses trust in the software and the greater team loses trust in the user. That kind of trust is hard to build back.

And if the mistake is not addressed quickly, it could prove costly – potentially pouring significant additional spend into the project budget and contributing to the $2.1 trillion in project cost overruns that occur globally each year. What starts as a simple glitch in software performance can end with significant damage, the kind that could prevent users from ever going back to that tool.

For a similar reason, security is another pivotal foundational element developers must prioritize. In fact, data protection must be prioritized above all else – especially in fields like architecture where you’re dealing with a lot of precious intellectual property. A software user could not care less if an incredible new, time-saving feature is unveiled if, simultaneously, the software environment isn’t secure and their files are vulnerable to corruption.

Developers must focus primarily on protecting the complex digital assets and sensitive information handled with their software. To bring back our hypothetical architect, imagine a project to upgrade a government intelligence facility, with building floor plans that reveal the locations of secure rooms, surveillance locations, emergency exits and other privileged intel that, if put into the wrong hands, could jeopardize the safety of those working on-site.

Ensuring data is never lost, providing redundant storage and keeping sensitive information safe is our absolute baseline responsibility to users. While we might only briefly mention security enhancements in marketing collateral, it is a continual investment in a secure, reliable environment that keeps good software good.

Learning when what glitters isn’t gold

To measure the true return on investment for our R&D efforts here at Graphisoft, we rely heavily on product telemetry to see what users actually engage with. We recently introduced a brand-new, AI-ready data platform that allows us to analyze anonymized usage logs to see exactly which functions are being used and which are being ignored. This data is essential because if the product team convinces us to build something they believe is vital, we can calculate the development cost and then track if it delivers real value to our users.

A while ago, we unveiled a highly visual, flashy tool for our BIM software platform, Archicad, called the AI Visualizer. We were really proud of this tool. Essentially, users could start with a basic drawing or photo of random objects, such as a stack of boxes on a desk. They could then ask the AI Visualizer to create a skin based on the image or drawing, and the software would generate a high-tech office building or a beautiful wooden structure mimicking those shapes. It was an incredibly enjoying tool for creative work at the very beginning of a conceptual design phase.

Based on our continuous usage data analysis, we determined changes were necessary to retain long-term interest in the AI Visualizer – prioritizing enhancements that advanced open standards and seamless collaboration, rather than focusing too heavily on flashy UI additions. The biggest frustration they face is a lack of multidirectional collaboration capabilities and the tedious manual work required to transfer data between closed systems. So, in response, our team homed in on an open, cloud-agnostic environment where our users never feel trapped or dependent on a single provider.

Openness isn’t a flashy UI button, but allowing users to seamlessly connect their dots, export to any format and integrate with any technology is a massive differentiator for user satisfaction.

As a developer, you want users to choose your software every day because it is excellent – not because you have them locked into a closed ecosystem.

The future of intent-based software

I believe we are currently experiencing a paradigm shift away from traditional, click-heavy interfaces and toward what we call “intent-based design” that allows architects and engineers to specify a destination and letting the software itself figure out how to get there.

Across most vertical industries, R&D teams are building toward an AI-native nervous system that digitalizes common knowledge, allowing software to continuously learn and execute tasks based on a massive internal knowledge graph. This trend will contribute to increased intent-based design – and I believe that even in the near future, the user manual will become obsolete.

Rather than having to manually execute against each step in the engineering process, intent-based workflows allow a user to convey a vision and prompt the software to bring it to life based on the low-level functions and knowledge already built into its system. In architecture, for example, that means prompting your BIM modeling software to design a house within the specific parameters of Frank Lloyd Wright’s architectural style, rather than manually guiding it through each of those individual parameters yourself.

An argument for “boring” R&D

My ultimate goal is for our software to act as a quiet partner to great work. I think about it the same way as working with a great human colleague who you don’t have to over-explain every tiny detail to; instead, they understand where you’re headed as soon as you’re halfway there, understanding you in half the words and getting to work in half the time.

I want our software to behave the same way with, for example, intuitively predicting a user’s next step, seamlessly guiding them through new features without requiring any training. Our goal is to handle boring, repetitive tasks so users can remain fully immersed in their creative flow. With that we can provide immense value while demanding minimal attention, prioritizing what’s functional over what’s flashy.

When it comes to R&D, the sexy new features might get people in the door, but it is the invisible strength, the relentless reliability and the quiet partnership of the software that will keep them loyal.