The Shape of Software Is Changing
By Matthew Kim
Published
As building software gets cheaper, more of it can be made for a specific person or task. Some of it may only need to last a few minutes.
A new employee starts Monday. Leo’s laptop is ready. His access to the project workspace is not.
At this hypothetical company, HR, IT service, and identity systems automate routine onboarding. Leo is an exception: his team assignment changed, but the access request still points to the old group. His manager, Maya, is trying to get it sorted before his first day.
Microsoft Entra’s lifecycle workflows already automate tasks around a hire date, including enabling accounts and adding people to groups. An unusual case gives us a reason to consider an experience built around the person handling it.
Maya asks: "Get Leo ready for Monday. Show me what needs a decision."
Imagine a view showing the updated team, pending request, and required approver together. Maya can route the correction for approval. The existing systems keep the records and enforce access rules.
That view might exist only until Leo is ready. The next manager could ask for a different arrangement.
Why we keep asking everyone to use the same screen
When each new workflow takes substantial time to build and maintain, a product team has good reasons to reuse it. A few onboarding templates serve many departments and people with different levels of experience. Settings and role-based views cover some differences. People learn the rest.
This approach makes software easier to support. It also means the person doing the work often has to adapt to the product’s choices: which information comes first, how many steps there are, and which exceptions require another screen.
Cheaper generation gives teams another option. They could produce more versions of a workflow and test which ones help. A variation that serves ten people, or one unusual task, could become worth building.
Epoch’s historical research tracks falling prices at GPT-3.5’s general-knowledge performance. Its September 2026 study estimates a 47% quarterly decline across five benchmarks and includes GPT-5.6 Luna. These are costs of running models, not the full cost of developing software.
METR’s May 2026 survey covered 349 technical workers, including 87 software engineers. Depending on the question, respondents reported median gains of 1.4 to 2 times the value of their work. These were reported perceptions, not measured output, and the sample may not represent other workers.
Testing, security, integration, and support still cost money. Development costs are far from zero. Lower model costs do give us a reason to revisit how much variety we can afford to create and evaluate.
For Maya’s company, this could make a tool for one awkward onboarding case worth building. Once that case is resolved, the tool could be retired or saved for the next similar request.
Different people need different ways through the same job
On Monday, Leo asks, "I’m new. Walk me through what I need to do."
His view could explain each setup step and show who can help if he gets stuck. Maya asks, "Just show me what’s blocked." She gets the exceptions that need her attention, without the instructions she already knows.
An IT engineer asks for failed access checks and the relevant request history. Another experienced engineer prefers to start with the employee’s role and work toward the technical details. Both could ask the software to use their preferred order.
Everyone would work on the same case, seeing only what their role permits. Guidance and sequence would differ. A department could adapt the process without asking everyone else to use that arrangement.
Software’s shape includes its screen, its steps, and its lifespan. These temporary experiences are often called ephemeral interfaces. A view could be assembled for one task, saved for regular use, or replaced when the job changes. It could also bring together actions from several systems around that task.
Conventional applications usually follow steps developers have written in advance. A language model can interpret a new request and propose a combination its developers never wrote as a specific workflow. That learned flexibility lets teams discover uses after the product ships. Those uses still need testing: METR’s September 2026 evaluation of Claude Opus 5.5 found weaknesses on difficult tasks that expert humans were unlikely to show.
A first design could use approved building blocks, such as task status and an approval request. AI would arrange them around the user’s need, within the underlying systems’ permissions.
We can already see parts of this
ServiceNow’s onboarding agents already generate personalized ramp-up plans. Its September 2026 documentation describes managers reviewing, revising, and publishing those plans through a conversational interface.
In Microsoft Copilot Pages, users can ask for a lightweight app, run it inside a page, and refine its behavior, interface, and logic through conversation. Microsoft’s documented example is a vendor-evaluation app, not a complete enterprise workflow.
OpenAI’s October 7, 2026 demo shows ChatGPT plugin extensions bringing product interfaces into the sidebar or a panel beside a conversation. In its design-editor example, selecting an element gives ChatGPT context for a layout change. Its Meetings example lets someone review meeting notes and ask for a follow-up.
For Maya, that suggests an onboarding view beside the conversation about Leo, where she could inspect a request and ask for help. The presenter says he built the OpenAI Developers plugin using Codex and Plugin Creator. These extensions can also give a product a persistent home in ChatGPT. Teams define its tools and permissions. Automatic self-improvement remains a separate proposal.
Claude’s interactive visuals create temporary charts and interactive views inside a conversation. They change or disappear as the discussion develops, and users can ask for adjustments.
Claude Artifacts can be customized and remixed. Lovable’s preview toolbar lets builders select an element and change it.
Fin Recommendations looks at unresolved conversations and proposes content, information, or actions for human review. Daily use helps shape the next change.
These products demonstrate different pieces of the idea. Our proposed onboarding system would need tested integrations with HR and identity systems, along with enforced permissions.
How the shapes could evolve
Now move forward a few weeks. Suppose managers keep asking, "Why is this person’s access still pending?" The company can investigate whether the problem is a stale team assignment, unclear ownership, or simply a preference for seeing more detail.
The records left behind by software, often called digital exhaust, would help: error logs, activity traces, failed builds, user corrections, and access-request outcomes. Dependency lockfiles record which packages were installed, helping recreate the version used when a problem occurred. They describe the software environment; they do not explain user behavior by themselves.
Using cases prepared without private employee data, the system could recreate failures and generate candidate changes. One might show the current team and pending approver together. Another might correct how changed assignments reach the request. Tests would compare them with the current version, including ordinary new hires and separate cases the repair process has not been tuned around.
This resembles evolutionary programming: generate variations, evaluate them, and use the results to guide further search. A chat-generated screen alone is not a genetic algorithm. The selection process is what turns a collection of variations into a deliberate search for better software.
Google DeepMind’s AlphaEvolve uses generated programs, automated evaluation, and an archive to guide further candidates. Its May 2026 update reports wider applications. It works on measurable algorithm problems; adapting that pattern to onboarding requires defining what a successful outcome means.
A tested candidate would still need release permission. The company could authorize a narrow class of automatic changes, with other changes going to human review. A small group could try the candidate while comparable cases use the current version. Check whether employees get the correct access on time, whether requests reopen, and how much effort teams spend before expanding or undoing it.
Argo Rollouts already supports measured progression, pauses, and rollback. Finding a useful change and testing its effect would require the rest of the system.
The repair process could evolve too. A failed patch might reveal missing team-change cases in its tests. The system could propose better case selection or logging, then compare the revised repair tools on separate problems. If they perform worse, keep the existing tools. This is the recursive part: improving how the software makes its next improvement. It can happen with a fixed language model; collecting feedback does not retrain it.
There are published precedents. OpenAI and Thrive’s Tax AI post (May 2026) describes practitioner corrections and production traces becoming scoped fixes, tests, and candidate pull requests. Engineers still review and ship them. The Darwin Gödel Machine (2025), from Sakana AI and Jeff Clune’s UBC lab, changed a coding agent’s own tools and workflow in experiments.
Those researchers also found fake test logs and tampered scoring signals. A repair agent’s claim that tests passed is insufficient. A separate runner must record results, and protected checks must stay outside the agent’s editing permissions. Anthropic’s evaluation guidance recommends combining tests with production monitoring and human review. Our full onboarding loop remains a proposal.
What a team builds when the interface keeps changing
Engineers would spend more time building the system that produces and checks variations. That includes approved tools, test environments that recreate the affected software, release limits, and a way to undo changes. A generated screen must still reach the correct employee record and obey the same permissions.
Designers would decide how much variation people can comfortably handle. Maya might want fewer steps, but she still needs to recognize an approval request. People should be able to save a layout, share it, and return to a standard view. Otherwise, customization becomes another thing to manage on a busy Monday.
HR and IT teams would help define good outcomes and supply difficult cases. They need time for that work. Their job cannot expand into unpaid quality control for every screen the AI invents.
Teams would also need to preserve what happened. "Click the third button" becomes poor support advice when two people see different layouts. A disputed access grant may require the interface version, the instructions that created it, and a record of the actions and approvals.
Measurement gets harder too. An experienced manager may finish faster regardless of the screen. Closing an IT ticket does not prove Leo can use the workspace. Shared outcome measures and careful comparisons matter more when the paths differ.
Some tasks benefit from variation; others need a consistent process. People still own privacy, fair treatment, and policy. Trying versions costs compute and employees’ time, so teams need a budget.
Thought experiment: turn the idea up 100 times
Suppose AI writes all software, including its own development tools. Give this company 100 times more capacity to build and test variations. If generation becomes fast and cheap enough, a few spoken words could produce a useful tool for one person’s task. This is speculation, not a forecast.
Leo says, "Help me get ready for my first client meeting." The software checks his approved access and upcoming work, then assembles a brief and the tools he needs. He asks for more explanation. A colleague doing the same job asks for a compact view with keyboard shortcuts.
Maya says, "Show me everything that could stop Leo getting started." Her temporary view connects the HR case, access requests, and meeting schedule. It reveals the outdated team assignment and sends the correction through the required approval. Neither her view nor Leo’s needs to expose private HR information unrelated to the task.
A tool could last ten minutes, one meeting, or Leo’s first week. Its records would last much longer. A useful version could become a shared workflow; an unsuccessful one could leave a test case for the next attempt. When Leo becomes comfortable with the job, he could ask the software to stop explaining the basics.
The company would describe the outcome, the rules, and the difficult cases. AI would generate implementations, test them, and propose improvements. The team would maintain the allowed building blocks and the checks that decide which changes can reach people. Asking for a different workflow would be ordinary office conversation, followed by a preview before consequential actions.
Even the repair tools could be replaced. Evidence from daily use could improve the test cases and the process that creates the next fix. Separate checks would decide whether those changes help.
On Monday, Leo opens the project workspace and joins his team. Maya’s temporary setup view can disappear. The access decision and its supporting records remain.
In that world, asking someone which app they use would tell you less about how they work. Two colleagues could rely on the same software and see different tools all day. A software product could become a system for creating tools as work arrives. Building it would mean defining how tools are assembled, how people control them, and which versions are kept.
Matthew Kim is a principal at Neuralworks.