# The Generational Shift in Software

> What AI changed, what it takes to run it responsibly in production, and how buying software works now that a system can be shaped to a business in days rather than quarters.

_Topic: Enterprise Software · 35 min read_

## Abstract

Artificial intelligence has led to a generational shift in software. Software can now do more than it has ever done, the people who build it have gotten better at every part of building it, and it has become affordable for software to truly fit a business and evolve with it. This paper describes the shift from the inside. Autessa builds, deploys, operates, and governs AI systems in complex production environments, for large enterprises and for small businesses alike; software of this caliber was rarely within a small organization's reach before. The paper takes on the question leadership teams are asking, who controls the AI, and who answers for it when it gets something wrong, drawing on the mental model we have found most useful: governing AI is closer to managing people than to administering systems. It also introduces Continuous Fit, a pattern we are observing in our deployments: when software improves in days instead of quarters, the people using it start inventing what it should do next, and the ideas compound. The paper closes with the new era of buying software, and all of it is shared in the hope that it helps your organization capture the full benefit of the shift.

## What AI changed

Three changes, arriving together, and each on its own would have been a big year for the industry. Software gained abilities it never had. The people who build software got better at every part of building it. And the distance between an impressive demonstration and a system an operation can bet on became the thing that actually separates vendors.



> [Figure: The three changes that arrived together, with the seven new abilities drawn inside the first one rather than beside it, because they are its contents and not a separate list. The seventh, that AI can build software, is the one that compounds the rest, since the same technology that reads, reasons and acts is also what builds the systems that do. The second and third changes are what turn those abilities into something an operation can actually rely on: the people who build software got better at every stage of it, and capability stopped being what separates one vendor from another once anyone could demonstrate it.]



## Software gained new abilities

Software has always done real work. It runs payroll, executes transactions, schedules jobs, moves data, scores risk. What AI added is seven abilities software never had. Each is listed here with its industry name, since these are the terms vendor briefings and analyst reports are built around. This is not a frontier topic anymore: Stanford's 2026 AI Index reports that 88 percent of organizations now use AI in at least one business function.

**1. It can read almost anything (multimodal understanding).** Older software could only take in what arrived in the format it expected; a new document layout meant a new template, a new field meant a new rule. Current AI models are trained on text and images together, so they take in a page the way a person does, layout, tables, stamps, and handwriting included, and extract what it means rather than match a pattern. The same holds beyond documents: video and audio are now readable inputs. The claim that arrives as a letter, three photos, and a forwarded email thread is a readable input, not an exception. The honest qualifier in "almost": input quality still matters, and AI does not police its own reading.

**2. It can write (generative AI).** Drafts, responses, summaries, and reports at the quality of a competent professional, produced from the facts of the case rather than from a template. The technology underneath is the large language model, trained on enormous volumes of text and then tuned to follow instructions, which is why one system can draft a formal determination letter, a plain-language customer reply, and an internal summary of the same case, each in the right register. The response to that claim gets drafted for a person to review and send, in the organization's voice, with the case's specifics in it.

**3. It can reason through unfamiliar situations (AI reasoning).** Given rules, context, and a messy situation nobody scripted, current systems work through it: what applies, what conflicts, what follows. The newest generation are called reasoning models, built to deliberate before they answer, working step by step through the analysis and able to show that chain of reasoning for review, which matters when the conclusion has to be defended. This is the ability behind triage, classification, and evaluation, deciding whether an exception is routine or needs a person, and frontier models now meet or exceed human baselines on benchmarks ranging from PhD-level science questions to competition mathematics, per Stanford's 2026 AI Index.

**4. It can act (agentic AI).** Given a goal and a defined set of permitted actions in your systems, an AI agent plans the steps and carries the work forward on its own, without a person prompting each move. One clarification up front, because "agent" has meant a person for a century: an AI agent is software. Technically, it is a model connected to tools, specific operations it is permitted to call in your systems, choosing which to use, observing the result, and deciding the next step, in a loop, until the goal is met or its authority runs out. This is the newest of the seven abilities and the one moving fastest: in Gartner's 2026 CIO and Technology Executive Survey, 17 percent of organizations had deployed AI agents, while more than 60 percent expect to within two years, the most aggressive adoption curve of any emerging technology in the survey. Four scenes show the range.

A customer asks where their order is. The AI agent traces it across the order system, the warehouse, and the carrier, sees the tracking went dead four days ago, files the carrier claim, reships with upgraded delivery to hit the original promise date, and tells the customer what happened. The refund the customer also asked for goes to a person, because refunds are not its call.

Nothing triggered the second scene, which is the point. Ninety days before a contract expires, the AI agent pulls it, compares what was purchased against what was actually used, drafts a right-sized renewal, and puts it on the account manager's calendar with its reasoning attached. The nonstandard term from last year's negotiation goes to legal, not to the AI agent.

A regulation the operation runs under is amended. The AI agent catches the change, reads the new language against the rules currently in force, flags the two procedures that now conflict, drafts the updated guidance, and queues the open cases the change affects for re-review. None of it takes effect until a person approves, because changing the rules an operation runs on is above its authority.

A system fails overnight. The AI agent reads the logs, ties the failure to that evening's deployment, rolls the deployment back because rollback is within its permissions, confirms recovery, and writes up the incident with the full timeline. Nobody gets woken up, because the criteria for waking someone were never met.

Notice what repeats across the four: not its call, goes to legal, nothing takes effect without approval, criteria never met. The limits are the point. What an AI agent may decide, what it must escalate, and what record it must keep are choices the organization makes. Who enforces those choices, and how, is where the real work of AI in production lives, and this paper returns to it.

**5. It can absorb and synthesize at scale (large-scale analysis).** Every leadership team sits on more information than any person can absorb: tickets, complaints, call notes, contracts, transactions, the accumulated exhaust of running the business. The old tools could count it and chart it. AI can read it, all of it, and return what a good analyst would: what changed, what is driving it, which handful of items deserve a decision-maker's attention this week, and why.

The legal profession met this problem first and gave it a name: eDiscovery, where a single litigation can require reviewing millions of documents. The old answers were rooms of attorneys reading one document at a time, and then keyword search, which matched words without understanding them. Reading with comprehension at this scale is the new thing. M&A due diligence has the same shape: a data room of thousands of contracts, each of which needs to be read for the clauses that actually matter. And the deepest version of the change is what it does to sampling. Auditors sample transactions, quality teams sample calls, compliance teams sample files, and all of it exists for one reason: reading everything was impossible. Sampling is a concession to human reading speed. When the entire population can be read, the sample stops being the ceiling on what an organization can know about itself.

Two advances make this real. A model's context window, the amount it can consider in a single pass, now holds hundreds of pages at once, and retrieval systems let it pull the relevant records on demand from stores far larger than that. Analysis that used to cost a skilled person a week, when anyone did it at all, becomes something the organization simply has, continuously, about its own operation.

**6. It can be directed in plain language (natural language interfaces).** Every previous generation of software made people learn its language: the command line, the menus, the forms, the training course, the manual, the power user down the hall. This is the first generation that learns yours. The system is operated by telling it what you want, in your own words, and refined the same way: not that, group it by region, flag anything over ninety days.

That changes who can shape a system. The claims supervisor, the records officer, the credit manager could always describe how the work should be handled; now the description is the instruction. Technically, plain language has become a way to configure software: the stated rule is translated into behavior the platform enforces, and it can be tested, corrected, and versioned like any other change. It changes who can question a system, too. An executive can ask the operational question directly, in the meeting, and get the answer from the data, instead of submitting a ticket for a report that arrives next week.

The reach of this ability is easy to underrate because it looks like convenience. It is not. Training costs, adoption curves, shelfware, the standing gap between the people who understand the work and the people who can operate the software: whole categories of organizational friction exist because software demanded fluency in software. This is the ability that closes the distance between the person who knows the work and the system that performs it, and it is why the shift reaches every department, not just IT.

**7. It can build software (AI coding).** The ability that folds back on the industry itself: AI writes, tests, and documents code, and the numbers describe a change still in motion. Measured across the economy, a study published in the journal Science in early 2026 found roughly 29 percent of new Python functions on GitHub in the United States were AI-written. At the large incumbents, Microsoft's CEO put that company's share at 20 to 30 percent as of April 2025. And at the frontier, Anthropic reported that as of May 2026 more than 80 percent of the code merged into its production systems was authored by its own AI, up from low single digits sixteen months earlier, with engineers directing and reviewing rather than typing; the head of its coding product told Fortune in January 2026 that he had not written any code by hand in months. The frontier is not the average, but it shows the direction, and it matches what developers now say plainly: they have stopped writing code and started directing it. Technically this runs a spectrum, from assistants that suggest code as a developer types to coding agents that take a described change, plan it, implement it across the codebase, run the tests, and present the result for human review. It belongs last on this list because it compounds all the others: the same technology that reads, reasons, and acts also builds the systems that read, reason, and act.

The pattern to look for in your own operation, across all seven abilities: work that has always needed a person because it required judgment applied to something messy. Organizations staff entire departments for it, and its cost has always scaled with volume. A large share of it can now be done by systems, with people moving from processing everything to deciding the cases that genuinely need a person.

## The people who build software got better at everything

Skilled software people have always been the scarce resource in this industry. Every project's cost, timeline, and quality ceiling traced back to one constraint: how many good people you could put on it, and for how long. AI loosened that constraint in the most direct way possible. It did not replace those people; it multiplied what each of them can carry, across every role at once. Walk through a delivery from start to finish and every stage has changed.

Start where projects start: understanding the work. This is where the oldest failure in enterprise software lived. The people who actually know the work, the claims supervisor, the records officer, the credit manager, could always describe how it should be handled, but their knowledge had to travel through interviews, a written specification, a handoff, and a release cycle before anyone saw it running, and every step of that trip lost something. Now the trip is short. A business analyst turns interview notes into a working draft the same day and tests it against the cases the conversation raised while the conversation is still fresh. An analyst can also do something never before practical: read a year of tickets, case files, or emails and reconstruct how the process actually runs, as opposed to how the manual says it runs, which is usually the more valuable document. A subject matter expert states a rule in plain language, watches the system apply it, and corrects it on the spot. The distance between the person who understands the work and the system that performs it has never been shorter, and most of what goes wrong in enterprise software lives in exactly that distance.

Steering the project changed just as much. A schedule used to be an artifact you built once and defended against reality; it can now be rebuilt in minutes when reality changes, which means it can actually be current. The risk register becomes a living list instead of a document written for the steering committee. Status reporting draws from the actual work record instead of from chasing people. The contract itself gets watched: deliverables checked against what the statement of work actually says, change orders tracked against scope, invoices reconciled against milestones, the compliance obligations buried in section nine actually monitored. And the administrative record, the minutes, the action items, the decisions and who made them, gets kept complete as the work happens instead of typed up from memory at the end of the day. The hours this returns go where a good project manager always wanted to spend them: on analysis, on risk, and on the client.

Building is the stage everyone knows changed, and the change is bigger than faster typing. A developer's judgment concentrates where it always mattered most. Coming up to speed on an unfamiliar codebase takes hours instead of weeks, because code can be interrogated instead of merely read, including the fifteen-year-old module nobody left at the company can explain. The first drafts, the integration glue, the migrations, the tedious correctness work all move to the AI; the developer designs and reviews. The Science study of GitHub developers found the productivity gains accrue to experienced, senior-level developers, which is the right way to understand all of this: a multiplier on judgment, paying most to the people who have the most. UX and UI designers get the same multiplication. A working prototype goes in front of real users in hours, so interfaces get shaped by reactions to something real instead of arguments about a static mockup, and accessibility and consistency get checked continuously rather than audited at the end.

Data gets its own stage now, because AI raised its stakes. Systems that read, reason, and act are only as good as the data they work from, so clean data stopped being housekeeping and became foundation. The encouraging part is that the cleaning itself became tractable: profiling a legacy database, reconciling records that disagree, standardizing what a decade of free-text entry left behind, all of it is reading and reasoning work at scale, which is exactly what the new abilities do. And migration, the silent budget killer of every implementation, mapping the old system's data to the new one, chasing down what a column actually meant twelve years ago, moves from months of contractor hours to machine work under human supervision.

Then the disciplines that protect everything else, the ones every project used to cut first when time ran short, and the ones that matter most once a system is doing real work at real volume. Quality first: test cases can be generated from the requirements themselves, regression suites that were too expensive to maintain become affordable, and edge cases get exercised at a volume no manual effort ever reached. Performance and load testing, which used to be a specialist engagement scheduled once before launch, gets generated and run continuously, so the system that handled the demonstration is proven against the Monday-morning spike before the Monday morning arrives.

Security and operations complete the picture, and for technology leadership they are the picture. Threat modeling, dependency checks, and configuration analysis run continuously instead of as a gate crossed once before launch, which matters more than ever now that the systems being secured can act. Monitoring and observability, the pipelines, the alert rules, the runbooks, get built and kept current instead of perpetually deferred, so the system is watched in production rather than trusted. Scaling work that used to require rare specialists becomes reviewable, testable engineering. And cost gets managed as a continuous discipline rather than discovered on the invoice, across infrastructure and now across AI model usage itself, which is its own new line item worth watching.

A small team now carries what once took several times the headcount, and the roles between them have blurred in a productive way. These are not efficiency gains in the usual sense. They are skilled people doing more of the work they are actually good at, and less of the work that existed only because the tools were slow.

For a buyer, all of it lands as a single compound result: software that is better analyzed before it is built, better tested before it ships, better documented when it arrives, delivered in days rather than quarters, by people whose attention is on your operation rather than their own overhead. And work that used to sit below every credible provider's cost floor is now economically deliverable, which may be the most consequential part: mid-sized companies and public agencies can now buy a caliber of software work that was previously reserved for whoever could fund the largest programs.

## From demo to production

A demonstration is easy now. Impressive AI can be shown in an afternoon; the abilities are real, and they are available to everyone, including every vendor who will ever present to you. Which is exactly the point. When anyone can demonstrate capability, capability stops being what separates anyone. What separates a system an operation can bet on from a demonstration is everything wrapped around the ability.

Run the checklist any operator would. The system has to be put into production and integrated with the systems your operation runs on. Someone has to define what it is allowed to do, and enforce those limits in production rather than describe them in a document. Its reading has to be checked, because AI does not police its own reading: a well-built system measures confidence on every read and routes the doubtful ones to a person. Its output has to be constrained to the exact form a transaction requires, so "usually right" becomes "always in the required form." Every determination has to be recorded as it happens, in a record that can be produced later for a customer, an auditor, or a court. Someone has to watch it in production, notice when it drifts, stop it when it must be stopped, and keep all of this current as the models, the rules, and the business keep changing. None of that comes with the model. It comes from a platform built for it, and from an organization that operates it as a discipline.



> [Figure: The four requirements that have to be in place before it is responsible to let a system act on an organization's behalf. Proof is drawn as the one that matters most because it is the requirement the other three are ultimately measured against: when an auditor, a regulator, a customer or a court asks why the system did something, the answer has to survive being challenged. The bar underneath is the whole argument for why the control layer is not an optional extra, since the same cycle speed produces an advantage with it and a liability without it.]



Say the quiet part, because every executive is thinking it. Ask leaders what actually worries them about AI and it is rarely capability. It is control: who is in charge of this thing? The news feeds that worry on a regular schedule, with stories of AI systems doing things nobody intended. Read those stories closely, though, and the pattern is consistent. The missing ingredient is almost never a smarter model. Sometimes there was no real governance at all. More often there was some, set up at launch and then left standing still while the system kept moving: models improving, usage spreading, the authority granted to the system quietly growing past the oversight built for its first, narrower job. Governance of AI is not a checkbox crossed at go-live. Because the technology keeps evolving, the management of it has to be active and continuous, as alive as the thing it governs. That is a property of deploying AI well, not a reason to avoid deploying it, and it is exactly what disciplined AI operations exist to provide.

This is also why the choice usually presented to leadership, between moving quickly and staying safe, is the wrong choice. Autessa's CEO, Roshnee Sharma, has argued that [speed and safety are not a trade-off](https://www.linkedin.com/posts/roshnee-sharma_speed-and-safety-arent-a-trade-off-ugcPost-7450983810575376385-9QbS/), and has made the longer version of the case in GeekWire in [Why Moving Fast with AI Shouldn't Mean Sacrificing Safety](https://www.geekwire.com/sponsor-post/why-moving-fast-with-ai-shouldnt-mean-sacrificing-safety/). The two are produced by the same machinery. What lets a team ship a change in days is the automated gates, the tests, the staging environment, and the record of what happened, and those are the same things that make the change safe to ship. An organization that cannot move quickly is usually not being careful. It is usually missing the apparatus that would let it be both.

The mental model I have found most helpful is one I shared in a podcast conversation: governing AI is closer to managing people than to administering systems. Traditional software did exactly what it was configured to do, nothing more, forever; you administered it. An AI system is capable, fast, tireless, and able to handle situations nobody scripted, which means it needs what a capable new employee needs. A defined job. Explicit limits of authority. An escalation path for what exceeds that authority. Someone reviewing the work. A complete record of what it did and why. And trust extended incrementally: narrow authority first, expanded as the track record justifies it, revocable in an instant. Nobody hands a new hire the master keys on day one, and nobody should hand them to an AI agent either. The mechanisms are concrete, permissions scoped to the role, approval gates on consequential actions, continuous monitoring with anomaly alerts, staged environments before production, and a kill switch that actually works. The organizations getting this right are not the ones with the most impressive models. They are the ones running their AI the way a well-managed company runs its workforce.

This discipline has an architecture, and we have published it: "Beyond Chatbots: How Enterprises Should Actually Deploy AI Agents," by Autessa's CEO, Roshnee Sharma, along with its shorter companion, "Why MCP Is Not Enough: The Capability Layer Every Enterprise AI Agent Needs." Two ideas from that work are worth carrying out of this section. The unit of control for an AI agent is not the prompt but the capability: a constraint enforced in code, checked on every invocation, that the agent cannot talk its way around. And an agent should never see the raw systems underneath, only the narrow, approved business actions it has been granted, because any surface an agent can see is a surface it can be induced to call.

For thirty years, the expensive and differentiating thing in software was what it could do. Capability now improves by the quarter and is available to everyone. The scarce thing in software is no longer what it does. It is who answers for it. The rest of this paper follows from that reframing.

## What this looks like in production

We build and run AI systems in production every day, for our clients and for ourselves, and a few of those engagements are worth describing here, because concrete work makes the ideas easier to see.

One is large-scale document review of the kind eDiscovery made familiar: document sets past a million pages, where every page must be read for context and for sensitivity before anything can be released. The material includes Category 4 sensitive data, the most restricted classification under the framework this work is governed by. The system reads each page, evaluates it against the review rules, moves it through review toward release, and keeps a record of every determination it makes along the way. The judgment calls go to a person, with the reasoning attached. Reading, reasoning, and acting composed into one flow, at scale, with the record that makes every decision defensible afterward.

Another is a financial regulatory engagement, deep in the quantitative end of the finance world, where the instruments are specialized, the contracts are complex, the analysis is heavily mathematical, and the methods are the firm's own intellectual property. The work is compliance: staying true to the contracts and to the regulations that govern them, while the regulations, the rules, and the contracts themselves are amended, keep changing, and sometimes conflict. Reading all of it correctly has always depended on the accumulated expertise of a small number of specialists. AI agents now carry the mass reading and the working analysis across that material. The stakes of getting it wrong are high, which is precisely why the authority stays where it belongs: the experienced professionals make the final calls, and they make them better armed than they have ever been. This is the managing-people model in production, defined jobs, limited authority, escalation to humans, a record of everything, doing work that matters.

Both engagements run on the same machinery, and it is worth being concrete about what delivering the governance actually means day to day. What each AI agent may do is defined as specific, approved actions with the constraints enforced in code, so anything outside them is structurally impossible rather than merely discouraged. Which agent holds which action, and under what limits, is a policy decision the organization makes and the platform enforces, and consequential actions can be gated on human approval. Every action a system takes is written, at the moment it happens, to a record that cannot be altered afterward without the alteration being visible. The running system is monitored continuously, usage, failures, attempts against its constraints, escalations to humans, and everything is versioned, so a change that misbehaves can be rolled back the way any disciplined software deployment can. The payoff shows up when it matters most. When a client, an auditor, or a regulator asks what the system did and why, the answer is produced from the record, not reconstructed from memory.

The same pattern runs into territory you might not expect. For one client we built a system around a single sport, played everywhere from high school fields to the professional level. It takes in video at massive scale, tens of thousands of games, down to individual plays, watches it, and analyzes what happened. Out the other side come the things a staff of expert analysts would produce: reports, strategies, and improvement plans for individual athletes. It even helps train new analysts. The inputs are game film and the outputs are better athletes, which is about as far from invoice processing as software gets, and yet the same system discipline runs underneath it as runs underneath the mass volumes of invoices and insurance compliance items we process elsewhere, read, matched, and assigned, with people handling only the cases that need them. Different industries, same composition, same discipline.

These deployments also changed how we ourselves operate, and that has been the most inspiring part of the work. We run more cycles, and shorter ones. We show working software instead of telling people what is planned. And what comes back is more than feedback: ideas and innovation at a level we had never seen a delivery process produce, to the benefit of the buyer, their users, and ultimately the whole organization. It kept happening, engagement after engagement, until we gave it a name.

Anyone who has run software delivery will recognize the shape of it, because our industry has already applied this idea twice. Continuous integration made merging continuous: once verifying a merge became cheap enough to do on every commit, integration stopped being a painful event scheduled at the end of a project. Continuous delivery extended the same logic to shipping, and a release stopped being a quarterly window. Each step took an activity that had been episodic because it was expensive, and made it continuous once the cost fell far enough. What both of them have in common is that they stop at deployment. The pipeline carries a decision to production efficiently, but it never touches the question of what should be built next, because deciding that was gated by scoping studies and steering committees rather than by tooling. Continuous Fit applies the same idea one more time, to the last part of the work that was still episodic, which is making the software match the business. CI and CD automated the path from code to production. Continuous Fit closes the loop from production back to the idea.



> [Figure: The same idea applied three times, each track extending the one above it. Continuous integration made merging continuous, and continuous delivery extended that logic to shipping, but both of them stop at deployment and neither one decides what should be built next. Continuous fit applies it once more, to the part of the work that was still episodic, which is making the software match the business. It is the only one of the three that closes the loop from production back to the idea, so each cycle starts from what the team has actually seen working rather than from what somebody imagined at the outset.]



## Continuous Fit

We call it Continuous Fit, and the best way to understand it is something you have already lived.

Think back to your own first weeks with AI. You asked it something basic. The answer was better than you expected, so you tried something harder, and that worked too. Then came the moment the technology actually arrived for you, the first time you thought, I wonder if it can do this, and it could. From then on you kept going, and each thing you watched it do gave you the idea for the next thing to try. Your sense of what was possible was not fixed. It grew with use.

Continuous Fit is that loop, running at the scale of an organization's software, with the whole team inside it. The team uses a working system in their real work within days, not months. Seeing it working produces ideas no requirements session ever could: this flow, this nuance, this exception we handle differently, and then, wait, it could also do this. Those ideas are built and back in the team's hands in days, so the next round of ideas is sharper than the last, informed by everything now running. And because what they are watching work is AI, a second, deeper thing happens: their sense of what software can even be starts to grow. A team that watches a system read messy correspondence and act on it correctly does not just ask for faster correspondence handling. They start seeing every pile of judgment-heavy work in their operation differently, then it could review these, then it could flag that pattern, then it could draft the response. Those ideas were in nobody's backlog, because until recently nothing like them was conceivable. Every cycle is another exposure to what AI can do, so this source of ideas does not run dry. It widens.

Two feedback paths, reinforcing each other: seeing it working generates the next ideas, and seeing AI working keeps expanding the kind of ideas a team can have. That is the magic, and it is what we watch in real time across our deployments: more ideas surviving, and better ideas arriving, every cycle, to the benefit of the users, and through them the whole organization.

> **Continuous Fit.** The operating model that becomes available once modifying a system costs less than working around it. A working system is shaped to how the business actually works and improved in cycles measured in days, at a pace the client's leadership sets, and each cycle of real use generates the ideas for the next: seeing the system work, and seeing what AI makes possible, keeps producing innovation no planning process could. The client owns the queue of what gets built. The engineering gates, staging, regression testing, security review, and client acceptance, run every cycle without exception. The system evolves with the operation, and the organization becomes the source of its own next capabilities.

None of this could happen before, and the reason is the economics of a single idea. Under the old model, someone on the floor notices the system should handle something differently. The idea joins an IT queue, waits for a scoping study, gets priced as a change order, waits for a steering committee, and ships, if it survives all of that, in a quarterly release window months later. At that price and that speed, only the largest ideas justified the trip, and everyone learned to stop submitting the rest. This is the quiet tragedy of the old model: organizations have always had the ideas for their own software. The cycle from idea to working system was simply too slow and too expensive for most of them to survive, and, just as costly, nobody ever saw enough working software to generate the second-order ideas at all. The system stood still, the business kept moving, and the gap filled with workarounds, spreadsheets, and roles that exist only to bridge it.



> [Figure: The two models placed against each other. The upper track is the change-order cycle, where every step is a gate that is either billable or waiting on somebody else's calendar, and where the four-to-nine-month round trip teaches organizations to stop submitting requests at all. The lower track is continuous fit, which keeps the same discipline of staging, regression testing and client acceptance but automates the gates rather than negotiating them, so the loop turns in under a week and each turn feeds better input into the next.]



Continuous Fit begins at the moment the economics flip, when modifying the system costs less than living with the workaround. The loop itself is simple: the team uses the system in real work, sees what it does and does not do, leadership decides what changes next, the change is built and gated, and the team is using the improved system days later. In our engagements, a working system shaped to the client's operation is typically in front of their team within days, on a staging environment, and two rounds of the loop is typically enough to reach production. From there the system keeps improving at whatever pace the client's leadership chooses.

For anyone who has run software delivery, here is what it feels like from inside: as if we moved from two-week sprints to one-week sprints, and each sprint now carries what used to be two or three months of work. That is a sensation, not a measurement. But the experience underneath it is real, and it is the version the client lives: what arrives at each review is the kind of progress that used to arrive quarterly.

The most consistent pattern, and the one I did not expect, is what happens to the client's leadership team a few rounds in. Their requests stop being about the software and start being about the operation. A team working in a system it can actually change stops asking what the software permits and starts asking what the business should do. The system moves at the speed of the operation, and it becomes the way the organization tries things rather than the reason it cannot.

Clients tell us versions of the same thing, often enough that it has become the pattern rather than the exception: this is not what buying software used to feel like. What they are describing is Continuous Fit experienced from the inside. Software that genuinely works for their business, that keeps working as the business changes, at a fraction of what software used to cost.

The fit can be literal. For one client we built an inventory management and order fulfillment system that preserved the spreadsheet view their team loved and had built the operation around, even though the operation could no longer safely run on the spreadsheet itself. The familiar surface stayed; a real system took over underneath. That is what fit means in practice: the software conforms to how the team actually works, down to the screen they trusted, instead of the team retraining around the software.

We hold ourselves to the same model as customer zero. Our own company runs on systems we built on our platform and improve through the same loop: our CRM, e-signature, an interactive proposal writer, a contract redline and collaboration tool, meeting capture, project management, accounting, event lead capture, a video training recorder, a suite of digital marketing tools, dashboards, AI assistants, and the integrations that tie all of it together. Each began as an item on our own wish list. We feel the model's strengths and its rough edges before any client does, and it is, frankly, the most fun any of us have had building software.

Two conditions separate the real model from imitations, and both are worth checking with any vendor claiming to work this way. If the client's leadership does not own the queue of what gets built, it is the vendor's roadmap with better marketing. If the engineering gates do not run every cycle, it is recklessness with better tooling.

## The new era of buying software

Nearly everything in the conventional software purchase, the pricing, the process, the paperwork, was built for the old economics, when capability was scarce and change was expensive. Neither is true anymore, which makes the purchase itself worth rethinking. Five pieces of it in particular, each with an old-era assumption and a new-era replacement.

**What you are paying for.** Every software price has always contained two things: the capability, what the system does, and the responsibility, a supplier who runs it, secures it, keeps it current, and answers for it. For thirty years capability was the expensive part and the responsibility rode on top as a maintenance line. That ratio has inverted. Capability is now abundant, and responsibility grew at the same moment, because software that decides and acts needs governing, recording, and answering-for in a way software that merely recorded never did. A new-era price reflects the inversion: the premium sits on who answers for the system, not on access to what it can do. One useful lens for reading any quote is to ask how much of it is paying for each half.

**How it is priced.** Per-user pricing was never much of a measurement. The cost to a vendor of one more user was always close to zero; charging by the seat was how the industry scaled revenue with the size of the customer, and buyers accepted it because of the rough story underneath: people did the work, so more people meant more use. Whatever truth that story once held, it is gone. When the software does the work itself, output has nothing to do with how many people log in, and a per-seat bill stops having much to do with value. The market has noticed. Many application software stocks fell 30 to 55 percent in early 2026, against a 24 percent decline for the IGV software index, and in February 2026 Jefferies reset its coverage of the sector over AI disruption risk, downgrading Workday, DocuSign, Monday.com, and Freshworks to Hold. Reasonable people disagreed about whether the selloff overshot; there was far less disagreement about what was being repriced, which was the per-seat model itself. Per-seat pricing also carries a cost that never appears in a budget: a twenty-person team gets twelve licenses, and someone maintains a spreadsheet for the other eight. When access costs nothing extra, the rationing ends, and the duplicated work and lost visibility it created end with it. Our own model is one version of new-era pricing: unlimited users, support included, charges tied to work performed. The structure matters less than the principle, which is that cost should stop scaling with the two things that made well-fitted software unaffordable, how much you tailor it and how many people use it. We priced our own e-signature product this way, no per-user charge, no document caps, free to our customers, because charging by the signer was never a law of nature. It was a consequence of what software used to cost to build and change, and when that cost went, the pricing built on it lost its reason to exist.

**How changes happen.** The old route from problem to fix ran through an IT queue, a billable scoping study, a priced change order, a steering committee, and a quarterly release window: four to nine months in a well-run organization, at a cost that taught everyone to stop asking. Every step existed because analyzing and making a change was genuinely expensive. When a change takes days, a commercial model that prices each one as a separate project is protecting the vendor's margins, not covering the vendor's costs. The revealing question is never the first configuration, which is priced into the deal and always looks reasonable. It is the eleventh change, in month twenty-two, after the implementation team has moved to another account. What that change costs, and how long it takes, tells you which era you are buying.

**How you evaluate.** The requirements matrix is worth reconsidering, because it is built backward. A matrix is assembled from what you have watched software do, which quietly carries the last generation's limits into your next contract, and no one can specify a capability they have never seen working. A stronger starting point is the wish list: what would make the operation genuinely good if nothing were for sale. Not what software does. What the operation needs. That list has always contained items everyone assumed were not software problems because they required judgment applied to something messy, and a meaningful share of those items now has an answer. From there, evidence tells you more than demonstration: one item from that list, running against your own data, measured your own way, before money changes hands. Demonstrating real capability no longer takes a vendor months, so it has become a reasonable thing to ask of anyone. We structure engagements this way ourselves, a measured proof on the client's actual data before payment, delivery gated on their acceptance, because it is what the economics now support. The wish list will likely change once people see things running; that revision is the return on the exercise, and a vendor who treats new ideas as scope creep is describing the next three years of the relationship.

**Who sets direction after go-live.** This is the question most evaluations never ask, and it is where the value now lives. Someone decides what gets built next: either a product committee you will never meet, working a roadmap tuned to the vendor's whole market, or your own leadership, working your operation's actual priorities. It is worth knowing which, in writing, before signing.

## What to ask any vendor

Seven questions, each of which exposes something different.

- How does the drop in the cost of building software reach me?
- If my team doubles, or halves, what happens to my bill?
- How do I keep my AI costs predictable when token and model prices keep changing?
- What did the last few changes clients asked for after go-live take, in time and in cost?
- Who answers for the AI when it gets something wrong?
- Where does my data go when the AI processes it?
- Can I get my data out, in open formats, whenever I ask, not just at termination?

Contract length calls for care rather than a rule. A long term often buys a better price. The risk is locking in five years of old-era architecture and pricing while the ground is still moving, which is a different thing from a long relationship with a supplier whose model has already moved.

## The evidence to require

One distinction carries most of what a buyer needs to know about AI accountability: a log is not a record. A log says the system ran, written for the people who operate it. A record says what was decided, on what basis, created at the moment it happened, and provably unaltered since. The difference matters because the standard that will be applied is not future AI regulation but present evidence law. In the United States, business records carry weight in a dispute when they were made at or near the time of the event, in the ordinary course of business, by someone with knowledge, under Federal Rule of Evidence 803(6); a reconstruction assembled later for the dispute does not qualify, however accurate it is. And the regulatory layer has already arrived: under Article 50 of the EU AI Act, in effect since August 2, 2026, people interacting directly with an AI system must be told so unless it is already obvious, an obligation that reaches any organization whose AI-driven systems face people in the European Union. I am not a lawyer and none of this is legal advice, which is exactly why it is worth putting to your counsel before your next AI deployment rather than after.

There is a test that settles whether your evidence exists, and it takes an afternoon. Call it the Reconstruction Test: take one decision a system of yours made six months ago and try to reconstruct why it was made. If the answer takes more than a few minutes, or depends on anyone's memory, the record does not exist, and no one can create it retroactively.

## What is still genuinely hard

Honesty about the limits belongs in any paper asking to be believed about the gains. A working system in days is a true claim; a hardened production deployment in days is not, which is why our own engagements reach production in gated cycles rather than overnight. Something built quickly still has to be operated, secured, and answered for over years, and that responsibility does not get cheaper just because the building did; it is, again, the half of the purchase the money is now for. And not everything needs to be built. Mature, inexpensive commodity tools are usually better bought than rebuilt, and email marketing is a good example twice over: the product is commodity, and much of its real value lives outside any codebase, in sender reputation and standing relationships with the external systems that decide what reaches an inbox. That is difficult to recreate by building. A rule worth considering: build what is core to how you operate, buy what is commodity, and lean toward buying anything whose value depends on networks and reputation that cannot easily be rebuilt. Having the ability to build makes that judgment more consequential, not less, and an organization that builds reflexively can end up with a sprawl of unowned software rather than an advantage.

## In closing

I have spent my career delivering enterprise systems, and I have never seen anything like the last two years. Systems that read, reason, and act, carrying work that once buried whole departments. Teams shipping in days what used to take quarters. Clients inventing their own next capabilities, because they finally get to see software working before the budget is spent, and each thing they see gives them a better idea. The people using these systems are asking for things nobody in our industry would have dared put on a roadmap, and the systems are keeping up with them.

Behind every sentence of this paper is the team at Autessa. The systems that read a million pages, the cycles that ship in days, the gates that never move, the records that hold up: none of that is a feature that exists on its own. It is the daily work of people who are exceptional at their craft, and what this paper knows, I learned from watching them, and from our customers, who keep taking what we build and imagining something better, and whose ideas run all through this paper.

That is what a generational shift feels like from the inside: not a technology arriving, but possibility compounding. All of it is available now. We wrote this to share what we are seeing and what we have learned along the way, in the hope that it helps your organization capture the full benefit of the shift.

## References

1. Stanford Institute for Human-Centered Artificial Intelligence, *The 2026 AI Index Report*. hai.stanford.edu/ai-index/2026-ai-index-report
2. Gartner, "What the 2026 Hype Cycle for Agentic AI Reveals," Rajesh Kandaswamy, April 15, 2026. gartner.com/en/articles/hype-cycle-for-agentic-ai. GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.
3. CNBC, "Satya Nadella says as much as 30% of Microsoft code is written by AI," April 29, 2025, reporting remarks at LlamaCon.
4. Daniotti, S., et al., "Who is using AI to code? Global diffusion and impact of generative AI," *Science*, January 2026. DOI: 10.1126/science.adz9311
5. Anthropic Institute, "When AI builds itself: Anthropic's experience with recursive self-improvement," 2026. anthropic.com/institute/recursive-self-improvement
6. Nolan, B., "Anthropic's Claude Code lead says he hasn't written code by hand in months," *Fortune*, January 29, 2026.
7. Jefferies, U.S. applications software coverage reset, Brent Thill, February 23, 2026, as reported by Seeking Alpha and Investing.com, February 23, 2026.
8. Federal Rules of Evidence, Rule 803(6), Records of a Regularly Conducted Activity.
9. Regulation (EU) 2024/1689 (EU Artificial Intelligence Act), Article 50; European Commission, Guidelines on transparency obligations for providers and deployers of certain AI systems, July 2026.
10. Sharma, R., "Beyond Chatbots: How Enterprises Should Actually Deploy AI Agents," Autessa, autessa.com/blog/ai-agents-enterprise-architecture
11. Sharma, R., "Why MCP Is Not Enough: The Capability Layer Every Enterprise AI Agent Needs," Autessa, autessa.com/blog/mcp-capability-layer
12. Sharma, R., "Why Moving Fast with AI Shouldn't Mean Sacrificing Safety," *GeekWire*. geekwire.com/sponsor-post/why-moving-fast-with-ai-shouldnt-mean-sacrificing-safety
13. Sharma, R., "Speed and safety aren't a trade-off," LinkedIn. linkedin.com/posts/roshnee-sharma_speed-and-safety-arent-a-trade-off-ugcPost-7450983810575376385-9QbS