AI Programming Is Still Waiting for Its Spring Boot
AI programming has moved beyond “Can models write code?” It has not yet moved beyond “How can teams deliver reliably?”
Prompt, Context, Memory, Tool, MCP, Sandbox, Workflow, and Eval are becoming capable building blocks. What is still missing is a widely accepted default path: how people state a goal, what an Agent may inspect and change, how an interrupted task resumes, and what evidence a result must provide before it can be merged.
This resembles Java Web before Spring Boot. The capabilities existed and applications ran, but every team repeatedly solved startup, assembly, and deployment for itself. The “Spring Boot” of AI programming will not appear automatically with a stronger model either.
A Framework Reduces Repeated Judgment
Tomcat answered where a Web application runs. Spring answered how its objects are organized. Spring Boot then packaged dependency choices, common configuration, and the Runtime into a set of defaults. Rails went further, replacing project-by-project freedom with conventions for directories, naming, and connections.
What these frameworks truly save is not lines of code but the number of decisions people must repeat. They compress accumulated practice into concepts, structures, and defaults while preserving ways to reach the lower layers when necessary. A newcomer can first follow a path with a reasonably high chance of success, then learn about containers, transactions, and networks as problems arise.
AI programming currently lacks this compression. SDKs can call models and Agents can use tools, but teams still invent their own ways to organize Context, define permission boundaries, recover state, and decide what counts as acceptance. We have similar parts without a shared development model.
The tree below shows the capabilities already in place. Its branches are dense; the engineering contracts that connect them remain thin.
What Is Missing Is a Feedback Architecture
If the only question is whether a task can be completed, today’s Agents are already quite useful. Software delivery must answer a different set of questions as well: Why was this change made? Which constraints were checked? What did the tests cover? At what layer did a failure occur? Can the system recover after an incident?
The framework for AI programming therefore cannot be merely an Agent orchestrator. It must look more like a feedback architecture that turns a vague delegation into an inspectable loop: goals become executable Specifications, Context has explicit provenance, tools follow least privilege, the Runtime preserves task state, tests and Eval provide acceptance evidence, and the final change remains traceable to human responsibility.
Let Agents produce software that can be accepted under clear constraints, with failures that can be located and a process that can be traced.
Once this matures, developers may rarely assemble Prompts or maintain Agent Loops by hand, just as Spring Boot users do not assemble a Servlet container every day. Common choices will become conventions, complex state will belong to the Runtime, and only exceptional cases will require people to reach into lower layers.
This feedback architecture also serves an easily overlooked user: the person learning to program.
What Newcomers Lack Is Feedback
Junior developers used to begin with bug fixes, CRUD work, and tests. The tasks were modest, but they continually exposed real consequences: why a test failed, where a transaction broke, how an API was misused, and what a production rollback meant. Engineering judgment grew from these short feedback loops.
Agents are taking over that work. A newcomer can receive a complete feature in minutes without knowing which decisions are sound and which risks simply have not surfaced. Asking them to review Agent-written code does not solve the problem, because review requires the very judgment they have not yet developed.
The new learning path must begin at a higher layer and then deliberately drill downward. Let an Agent complete a real feature, then trace one request, inspect a transaction boundary, and explain a permission choice. When a failure occurs, distinguish a misunderstood goal from missing Context, a restricted tool, or a bug in the code. A framework should expose these boundaries so complete code comes with a traceable process.
Delivery requires observability, verification, and recovery; those same properties provide the feedback learners need, without a separate teaching layer. A good intermediate layer can serve teams and newcomers at once.
We Do Not Yet Know What to Call It
It may resemble Spring Boot, joining the Runtime, dependencies, and default configuration. It may look more like Rails, reducing choices through strong conventions. It may not even be a traditional code framework, because it organizes goals, state, permissions, and acceptance, with code as only one of its outputs.
The analogy has limits. Model output is uncertain, and Agents can call tools and alter the external world. Validation, isolation, and permissions must therefore sit much closer to the front than they do in traditional Web frameworks. We can learn how frameworks condense experience, but we cannot copy their answers.
Models will keep changing, and today’s operating tricks will become obsolete. Specification, Runtime, Eval, permissions, and recovery will continue to recur. Wherever people repeatedly fill a gap by hand, or the same failure repeats across teams, an appropriate abstraction is probably missing.
Once this abstraction exists, teams will no longer reinvent task state, permissions, and acceptance for every project, and newcomers can use the same evidence to understand why a delivery succeeded or failed. Until then, AI programming has ever more capable Agents but still lacks a default development path.