Just-in-time applications: how software caught up with the moment
Software used to take weeks to build. Then days. Then hours. Now it takes minutes, and increasingly, the application you need exists only for the moment you need it.
That last part matters. We have spent 70 years compressing the loop between idea and running software, and the curve just bent again. The pattern is older than people realize, and it tells you where this is going.
The slow beast era
In 1949, assembly language showed up. A thin layer of human-readable mnemonics sitting on top of machine code. You wrote for the chip. You knew which register held what. You moved bytes around by hand. Fast at runtime, brutally slow to write.
Then, in the early 1970s, Dennis Ritchie gave us C, and not long after came C++. A serious step up. You could write portable, structured code. But the workflow was still a hard cycle. Write code, compile it, link it, run it, watch it crash, repeat. Compiles were measured in minutes, sometimes hours on a real project. The feedback loop punished you for every typo.
This era built the operating systems, the databases, the browsers. Real engineering. But every piece of software was a one-time, heavyweight artifact. You shipped it on a disk. Users installed it. Updates were a separate ordeal.
Java and the just-in-time idea
Then 1995 happened. Sun Microsystems released Java with the slogan "Write Once, Run Anywhere". The trick was bytecode. You compiled your Java source once into a portable intermediate format, and a Java Virtual Machine (JVM) on whatever device you were using would translate that bytecode into native machine code at runtime.
That was the breakthrough. In 1999, Sun shipped the HotSpot performance engine, which brought a proper just-in-time (JIT) compiler to the JVM by default in Java 1.3. JIT meant the runtime watched your code execute, figured out which paths got hit the most and compiled those down to optimized native code on the fly. The compile step did not disappear. It moved to the moment of need.
That shift is the whole story. The slow, upfront, monolithic compile stopped being a wall you hit before users ever saw your software. It became something the machine did invisibly, in the background, while the program ran. Java rode that idea straight into the internet boom. Applets in Netscape. Servlets on the back end. The web turned interactive partly because someone figured out how to defer the hard work until it actually mattered.
Where we are now
Fast forward. The interesting thing is that the same pattern is repeating, but at a level higher than code.
In February 2025, Andrej Karpathy posted about what he called "vibe coding", giving in to the vibes, talking to a model, forgetting the code exists. It became Collins Dictionary's word of the year. By 2026, the industry had grown up a bit and started calling the professional version of this "agentic engineering", where AI agents reason, plan and execute multi-step development work on your behalf.
Sit with what that actually means. The compile step has moved again. It used to live on the developer's machine. Then it moved to the JVM at runtime. Now it lives inside an agent that takes a description in plain English and produces a working application at the moment of need.
This is what I would call just-in-time applications, or JIA. Software that gets assembled when you ask for it, shaped to the specific person asking and often thrown away the moment the need passes.
How the trick actually works
The reason this is real now, and not a demo, is that the agents finally have everything they need to behave like a junior engineer with a long memory and no ego.
They have memory. Reading their .md files the way a new starter reads onboarding docs. It remembers your preferences, your stack, your past decisions, who the team is. That memory persists across sessions, so you do not have to re-explain your world every time you ask for something.
They have skills. Reusable bundles of instructions and code for specific jobs. Building a PowerPoint. Cleaning a spreadsheet. Calling an internal API. The agent picks the right skill for the request, just as an engineer reaches for the right library.
They have tools. The Model Context Protocol gives agents typed access to the systems your business actually runs on. Jira. GitHub. Snowflake. Slack. Your custom internal services. The agent does not just write code that talks to these things. It calls them itself, reads the response, decides what to do next.
And critically, they have somewhere safe to actually run. The agent spins up an isolated sandbox or a fresh virtual machine, writes code into it, executes it, sees the result, fixes its own mistakes and tears the environment down when it is finished. The compile step does not just happen at the moment of need. The whole runtime gets created and destroyed at the moment of need.
The best public example of this in production right now is Google. At I/O 2026 they showed Search running custom generative UI for every query. You ask about astrophysics and Search builds you an interactive simulation. You ask for a wedding planner and Search codes a mini-app on the spot, pulling live data from reviews and maps. AI Mode crossed a billion monthly users in its first year. This is not a research project. It is the front door to the internet generating a bespoke application for every single user every single time, then throwing it away when they leave.
Spotify built an internal tool called Honk that lets engineers ship features by describing what they want in Slack, with Claude Code handling the deployment in real time. Kevin Roose at the New York Times, picking up on what Andrej Karpathy was calling vibe coding, spent a few weeks writing what he called "software for one", tiny personal apps no software company would ever bother to build for him. A lunch tracker. A custom dashboard. A tool to sort his kids' Legos. None of them needed to exist for more than a few weeks.
Why this matters more than it sounds
Three things are happening at once, and the combination is where the leverage is.
First, the friction to create software has effectively gone to zero for a huge category of problems. Anyone who can describe what they want can get it built. That changes who gets to be a software user, because now everyone can also be the customer of one.
Second, applications stop being products. They become outputs. The artifact you used to ship in a box, then host on AWS, is now something an agent can spin up, serve and tear down inside an hour. That is a different economic shape entirely.
Third, the work for engineering teams shifts. The valuable thing is no longer typing the code. It is the system of agents, prompts, guardrails, evaluations and infrastructure that makes all this trustworthy at scale. Build the factory, not the widget.
The engineer moves up the stack
There is a tempting narrative that goes, "If AI writes the code, engineers are done." That is wrong. What is actually happening is the same thing that happened to every previous abstraction. The work moves up.
When C arrived, the assembly programmers did not get fired. The ones who adapted became systems engineers, solving harder problems. When Java and managed runtimes arrived, the C++ crowd did not get fired. The good ones moved into building distributed systems, web platforms, the things that needed the new level of abstraction. Every shift in compiler technology has expanded the surface area of what engineering is responsible for, not shrunk it.
The same thing is happening now, only faster and more visibly.
The engineer's job used to be writing the code. Now their job is designing the agent, choosing its tools, writing its skills, defining its memory, building the evaluations that prove it does the right thing and owning the sandbox it runs in. The artifact they ship is not an application. It is a system that can safely produce thousands of applications on demand for users they will never meet.
That is a bigger job than writing the code. Not smaller. You are now responsible for a runtime that generates production software on the fly. You own its judgment, its blast radius, its security posture, its cost envelope. The blast radius of a single careless prompt is larger than the blast radius of a single careless commit ever was.
This is why the engineering role is arguably more important now, not less. The leverage on each person has gone up by an order of magnitude. The cost of a bad decision has gone up with it. The companies that figure out how to staff and structure for this will out-build everyone else by a lot. The ones that treat agentic engineering as a way to cut headcount will end up shipping a fleet of broken throwaway apps and wondering why their security team is on fire.
Skills, memory, tools, sandboxes. Those are the new primitives. Engineers who think in those primitives are the ones whose value just compounded.
The systems of record are not going anywhere
Before anyone in a CIO's office hears "ephemeral applications" and panics about their SAP being torn down, let me be clear about what is not happening.
Your line of business systems are not being replaced. SAP, Oracle, Salesforce, ServiceNow, Workday, Dynamics, your data warehouse, your custom internal platforms. None of these go away. If anything, they get more valuable, not less.
Here is why. A just-in-time application is only as useful as the data it can access. An agent that spins up a custom dashboard for your sales VP is worthless unless it can read pipeline from your customer relationship management (CRM) system, bookings from your enterprise resource planning (ERP) platform and tickets from your IT service management (ITSM) tooling. Those systems are the source of truth. They hold the transactions, the audit trail, the compliance posture, the master records. Nothing about agentic engineering changes the fact that revenue gets recognized in your ERP and that customers exist in your CRM.
What changes is the role those systems play. They stop being the place users go to do work. They become the place agents go to get data. The user no longer logs into SAP and stares at 12 screens to answer one question. The user asks a question. The agent calls SAP, joins it against three other systems and renders the answer as a one-off application built for that exact question. Tomorrow's question gets a different application.
This is the same pattern we saw with databases. When web apps took off in the 2000s, nobody ripped out their Oracle databases. The database got more important, because suddenly more applications needed to read from it. The user interface (UI) layer got cheap and disposable. The data layer stayed expensive and permanent.
The implication for enterprise architecture is concrete. The investment you have made in clean APIs, well-governed data and a solid integration layer is the investment that pays off in this new world. Systems with bad APIs and locked-down data become bottlenecks. If your CRM cannot be queried programmatically by an agent on behalf of a user, the agent cannot help that user. Your master data, your access controls, your event streams, your MCP servers in front of internal systems. That is the substrate JIA runs on.
So the right way to read this is not "AI replaces enterprise software." It is "enterprise software stops being the front door and becomes the foundation." The thing users touch is generated on demand. The thing it runs on is the boring, expensive, regulated, mission-critical system you already own. Spend money on making those systems easy for an agent to talk to, not on retiring them.
The shape of the next decade
Software has spent 70 years moving the compile step closer to the moment of use. Assembly meant you compiled in your head. C meant you compiled at your desk before shipping. Java meant the runtime compiled while the user used the program. Agentic engineering means the application itself compiles into existence the moment someone needs it, then often vanishes when they are done.
The name we have for the pattern at the code level is just-in-time. The name we should use at the application level is the same. Just-in-time applications. Built on demand. Personalized by default. Ephemeral when the need is gone.
That is the world your engineering organization is now operating in. The question is not whether this is happening. It is whether you are building the factory or still trying to ship the widget.