Picture an event center on a Saturday morning. By afternoon it will host a rodeo. Next weekend, a concert. The weekend after that, a corporate conference and then a graduation ceremony. Four completely different events, four completely different audiences, four completely different experiences — all running on the same foundation. The same floor. The same rigging. The same power infrastructure, the same acoustics, the same loading docks.
Nobody rebuilds the venue for each event. The venue was never the point. The event was.
Software engineering has the same problem, and most of us haven't admitted it yet.
The Artifact Became the Job
For decades, building software meant building something durable. A system. An application. A platform. Something that could be deployed, maintained, versioned, and eventually replaced. The artifact was the deliverable, and the engineer's craft was measured by how well they built it — how clean the architecture, how stable the release, how defensible the code.
That made sense when the artifact was the only path to the outcome. If you needed a workflow automated, you built the workflow engine. If you needed data analyzed, you built the analytics platform. The software was the means, but it was also the only means, so we built in permenance.
We got so good at building the means that we confused it for the end.
Every line of code ever written existed to facilitate something — a decision, a transaction, an insight, a request fulfilled. The software was never the outcome. It was always the infrastructure between the intent and the result. We just stopped noticing that distinction because the infrastructure was so hard to build that it consumed all the attention.
That constraint has been lifted.
When the Event Becomes Temporal
AI changes the nature of software at a fundamental level, and most of the industry is narrating that change wrong.
The prevailing story is that AI makes software engineers faster. That's true, but it's the least interesting part of what's happening. The more important shift is this — when AI can assemble software on demand to fulfill a specific intent, the artifact no longer needs to be durable. The software can be generated for the moment, fulfill its purpose, and dissolve. It can be assembled differently tomorrow for a different user, a different context, a different question.
The event is temporal. It always was. We just didn't have a venue that could acknowledge that.
This is not a marginal improvement to the development lifecycle. It is a category shift in what software is. Temporal software — assembled at runtime, fit to the moment, discarded when the moment passes — is a genuinely different thing than the durable artifacts software engineers have been building. And it changes what the underlying engineering work actually needs to be.
Because here is what temporal software requires to work: it needs a venue.
The Venue Is the Hard Problem
The event center doesn't succeed by accident. The reason it can host a rodeo on Saturday and a symphony on Sunday is because someone engineered the floor load capacity, the rigging points, the power distribution, the acoustics, the access routes, the safety systems. None of that work is visible during the event. All of it determines whether the event is even possible.
Temporal software has the same dependency. The reason an AI agent can assemble a fit-to-moment experience — pulling the right data, applying the right logic, fulfilling the right intent — is because someone built and maintained the infrastructure underneath it. The governed data. The knowledge architecture. The contextual layer that tells the system what the organization knows, how it operates, and what constraints it works within.
That infrastructure is durable. It has to be. The events come and go. The venue stays.
This is the engineering work that matters now, and it is a harder problem than building any individual application. Building one software system to solve one specific problem is tractable. Building infrastructure capable of empowering any valid intent, reliably and repeatedly, at the moment it is expressed — that requires a different discipline entirely.
That discipline needs a name.
Intent Engineering
The intent engineer owns the venue, not the event.
More precisely, the intent engineer owns the durable infrastructure, data, and contextual knowledge that empowers temporal software to fulfill intent. They are not responsible for the specific application assembled for a specific moment. They are responsible for ensuring the underlying platform can receive any valid intent and give the assembled software everything it needs to fulfill it.
This is not a job title update. It is a category shift in what the engineering work actually is.
A software engineer asks: what should this system do, and how do I build it?
An intent engineer asks: what does the platform need to know, hold, and govern so that any request made of it can be fulfilled reliably?
The second question is upstream of the first. It has always been upstream of the first. We just never had a reason to separate them because the software engineer had to answer both. Now the temporal software can answer the first question on its own. The second question is what remains — and it is the harder, more consequential one.
What Intent Engineers Actually Build
The work is concrete, even if the discipline is new.
Data architecture that outlasts any single use case. Not a schema built for one application but a governed data foundation that temporal software can query against with confidence. Clean, current, and contextually rich enough to support decisions that haven't been anticipated yet.
Contextual knowledge layers. The organization's operating reality encoded in a form the system can reason against — its processes, its constraints, its terminology, its relationships. This is what allows temporal software to feel native rather than generic. The event center that knows it hosts rodeos needs different rigging than one that only hosts graduations.
Governance that travels with the infrastructure. When software is assembled at runtime, the guardrails can't live in the application layer — they live at the venue level. The intent engineer defines what the platform will and won't do, what data it will and won't surface, what decisions it will and won't make autonomously. Those constraints have to be durable because the software honoring them is not.
Reliability without a fixed system to test. This is the genuinely new challenge. Traditional quality assurance tests a known artifact. Intent engineering has to ensure a platform that generates unknown artifacts behaves predictably. That requires a different approach to testing, monitoring, and trust.
The Implication Nobody Is Talking About
The teams and companies that make this shift will compound. The ones that don't will spend the next decade doing something increasingly strange — maintaining durable software artifacts to solve problems that temporal software could fulfill on demand, cheaper and better, if only the venue existed to support it.
This is not an argument against software engineering. The craft that made great software engineers valuable — the systems thinking, the precision, the instinct for what breaks under load — is exactly what intent engineering requires. It doesn't disappear. It moves upstream.
What gets left behind is the assumption that the artifact is the deliverable. That the application is the answer. That shipping software means you've solved the problem.
The event center didn't become valuable because it hosted one great rodeo. It became valuable because the infrastructure it built could host anything worth hosting.
The Venue Outlasts the Event
There will always be engineers who build events. Specific applications for specific moments, assembled quickly and discarded without ceremony. That work matters and it will be abundant. AI will make it cheaper and faster than anything we've seen.
But the work that compounds — the work that determines whether any of those events can happen at all — is the venue. The infrastructure that receives intent and makes fulfillment possible. The governed foundation that every temporal application inherits without knowing it needs to.
The industry has been calling this work by the wrong name for years. We called it platform engineering, or data engineering, or architecture. Those names aren't wrong, but they describe the materials, not the mission.
The mission is intent. And the engineers who own it deserve a title that says so.