From Programming Applications to Programmable Applications
For most of my career, building software meant turning a decision into code.
You would figure out what the business needed, write a spec, argue through the architecture, build the application, deploy it, monitor it, and then spend years keeping it alive. We called that last part maintenance, but that always made it sound smaller than it was. Maintenance was not some phase after the real work. It was the real work continuing under a different name.
Code matters, but it was never the whole job. Good developers were never valuable because they could type faster. They were valuable because they could understand what the business actually needed, find the edge cases, and build something that still made sense once real people started using it. The expensive part of software has always been keeping the application lined up with the business after the first version goes live. Processes shift, customers behave differently, teams reorganize, and the assumptions baked into the first version start to age out. The app keeps doing what it was built to do, even after the business has outgrown the assumptions behind it.
So I find it strange that so much of the current AI conversation is obsessed with code generation. Can AI write code? Sure. Can it write more code faster? Also yes. But producing more code was never the highest-value part of the job. In a lot of cases, producing more code faster just gives you more places to bury why the system exists.
The more interesting shift is not that AI can help us write applications faster. It is that AI makes it practical to build applications whose behavior can be inspected, discussed, and changed after it is live.
That sounds like a wording difference, but it changes how the software is designed. We are moving from software where intent gets frozen at build time to software where behavior can stay visible and adjustable. The application does not have to be a sealed artifact sitting behind a deployment pipeline that only engineers can reach. It can expose surfaces where behavior can be inspected, discussed, changed, tested, approved, and released.
In other words, the application can become something you work with, not just work on.
The Application in the Room
Picture a dedicated Slack or Teams channel for a business system owned by a small group: an engineer, a product owner, a support lead, and someone from operations. The application is there too, not just posting alerts, but participating in the discussion.
You can ask why something happened, and it can point to the rule or workflow that produced the result. If you ask what changed this week, it can show you. If a new exception needs to be handled differently, it can suggest a rule, show examples, run a simulation, and prepare a change for review.
The point is not to turn every operations request into a ticket, and it is not to let AI rewrite the codebase on its own. The valuable thing is the space in between: a controlled interface where the people closest to the work can interact with the behavior of the system directly, while engineering discipline still governs how changes happen.
Give Intent Somewhere to Live
On real projects, this shows up when teams use AI to turn a business process into software. The default move is to put everything into code. Every behavior becomes implementation. Every new case becomes another branch, another condition, another little knot in the codebase. It can look productive because something appears quickly, but speed is not the same as understanding the shape of the problem.
The better design is usually less flashy and more important. Instead of turning every exception into code, it gives the rules a place the system can inspect and explain.
For an intake and routing system, that might mean putting those rules in a central place. They can be read, explained, versioned, and changed without spelunking through the rest of the application. That structure makes the system more understandable to people, and it makes it much more reasonable for AI to assist. The AI does not need to invent new application logic from scratch. It can operate on a defined surface: review the rules, identify gaps, suggest changes, and stay inside boundaries that make sense.
The win is not getting AI to write more code. The win is designing applications so the operating logic has somewhere better to live than scattered implementation details.
I am talking about applications where what the system is supposed to do, and why, remains accessible. The rules, policies, workflows, prompts, thresholds, mappings, and approval paths are not buried so deeply that changing them requires digging through the codebase. They are part of the system’s architecture. That is the kind of AI application architecture this shift requires.
And that is where I think the next layer of software design is going. Developers are not going away. The work is moving up a level. We used to spend so much time authoring behavior directly. Now more of the work is designing the environment where behavior can safely change.
That means permissions, shared language for describing changes, tests, approvals, audit trails, rollback, observability, a release process, and clear limits on what the system can change, what it can only recommend, and what still requires a human.
A real ticket routing system makes the difference clearer.
Real Example
The tempting version is to let an LLM read the ticket and decide where it should go. The better version still uses the model for that judgment, but treats it as one part of a larger operating loop: a few-shot classifier makes the first pass, deterministic rules check the result, and signals like availability, load, priority, and known routing hints get injected into the prompt before the model makes a recommendation.
The behavior lives in YAML configuration, not scattered across application code. Those configs can change how the system routes work, but they are still reviewed, tested, versioned, and rolled back like production behavior. Every ticket, prompt input, API call, model response, and human override is saved so failures can be replayed later. When the system gets something wrong, that example can become a test artifact instead of disappearing into logs.
The system watches itself. Logs feed back into CI, nightly evaluation jobs compare what the system did against what humans changed or overrode, and the app opens issues when it finds patterns worth fixing. The point is not to make the model perfect on day one. It is to build a system that can keep evaluating itself, turn misses into test cases, and suggest improvements without losing the engineering controls around those changes.
Programmable Does Not Mean Uncontrolled
This is where the engineering fundamentals matter more, not less. If a system can change its behavior after deployment, then that behavior needs to be backed up, versioned, tested, reviewed, released, observed, and reversible. Rules, prompts, configuration, and workflows are production behavior.
Treating those things as softer than code is how you end up with a system nobody understands and nobody can safely recover.
Without restore points, checks, CI/CD, release discipline, and a process for knowing what changed and why, AI does not make the system adaptive. It makes it easier to lose track of how the business actually runs.
This shift does not remove the old problems. You still need the right plan, implementation, setup, and ownership. You still need knowledge of the business, the process, the users, the risks, the incentives, and the reason the software exists in the first place. When those pieces are missing, this becomes another version of the pattern behind why AI projects fail.
AI does not replace that; it exposes whether you have it.
The difference is that we can now start building systems where more of that knowledge stays active inside the application. The application can explain itself better. It can participate in its own operation. It can help maintain the rules that govern it. It can give non-engineers a more natural way to interact with behavior, while still letting engineers protect the integrity of the system.
Working With Our Applications
That is the interesting future to me, not autonomous applications spawning and maintaining themselves with no human judgment. Maybe we get closer to that someday, but that is not where the real work is right now.
Right now, the shift is simpler and more practical: we are learning how to work with our applications instead of only working on or around them.
That means the application is no longer just the thing we built. It becomes part of the operating loop: something you can question, ask to explain itself, and use to find places where current behavior no longer matches what the business needs now. Designed properly, it can help change safely.
So the move from programming applications to programmable applications is not a rejection of software engineering. It is a demand for better software engineering.
The craft is no longer just writing the code that runs. It is designing the surfaces where intent can live, move, and be governed.
That is a different kind of work. I think it is better work. But it is not easier work.
And if we do it well, the result is not software that escapes our control. It is software that gives us a better way to keep old assumptions from getting trapped in the system.
If this matches a problem your team is running into, I would be interested to hear how you are handling it. The hard part is not whether AI can change software. It is deciding which parts should be changeable, who gets to change them, and how those changes stay governed.
For teams working through that architecture, Liquid Intent helps design and build AI systems where business logic is inspectable, testable, and safe to change.