A return to intentional code in the age of artificial intelligence
For decades, software engineering has followed a trajectory that equates progress with layers: more frameworks, more abstractions, more automation hidden behind conventions. This trajectory was not accidental. It was a response to very real problems—growing teams, inconsistent coding practices, fragile systems, and the human cost of maintaining large codebases.
But the context has changed.
With the rise of artificial intelligence as an active participant in software development, many of the original reasons for heavy frameworks and runtime abstractions are no longer dominant. This article proposes a deliberate shift in perspective that I call “Back to Lovelace”: a return to explicit, intentional, and minimal software design—augmented by AI, not obscured by it.
The original problem frameworks tried to solve
In the early days of software, performance and correctness depended far more on how code was written than on the language itself. A well-written program in a low-level or high-level language could be equally efficient. The real problem was never the language—it was inconsistency.
As projects grew and teams expanded, individual styles and interpretations led to fragmentation. Frameworks emerged primarily as a social solution, not a technical one. They imposed:
- conventions,
- folder structures,
- lifecycle rules,
- and architectural patterns.
Frameworks created a shared mental model so teams could collaborate at scale. Performance and clarity were often sacrificed in favor of uniformity and governance.
That tradeoff made sense—then.
AI changes the equation
Artificial intelligence fundamentally alters the development process in a way we rarely acknowledge explicitly.
AI does not improvise architecture. It executes instructions.
Given clear rules, constraints, and intent, AI can generate:
- consistent structure,
- repeatable patterns,
- readable and maintainable code,
- without personal bias or stylistic drift.
In other words, AI eliminates much of the human chaos that frameworks were designed to control.
Today, the most valuable input is not a framework—it is a well-defined prompt that encodes architectural intent.
Back to Lovelace: what the name means
Ada Lovelace understood something fundamental long before modern software existed: machines do not create intent—humans do. Machines execute formalized ideas with precision.
“Back to Lovelace” does not mean returning to primitive tools. It means returning to:
- explicit logic,
- transparent execution,
- and intentional design.
AI becomes the executor of structure, not the source of abstraction.
Minimal standards instead of heavy frameworks
The proposal is not an absence of structure. It is minimal, explicit structure.
Patterns such as MVC, MVVM, or layered architectures have existed for decades. They are not inventions of frameworks. Frameworks merely codified them—often with additional runtime complexity.
A minimal standard is enough:
/controllers
/services
/models
- Controllers handle transport and I/O
- Services encapsulate business logic
- Models represent domain data
No magic. No reflection-heavy lifecycles. No hidden execution paths.
AI-generated scaffolding can apply these conventions consistently without introducing runtime abstractions.
Scalability is an infrastructure problem, not a framework problem
Modern scalability is achieved through:
- container replication,
- load balancers,
- horizontal scaling,
- stateless services,
- observability and monitoring.
Duplicating a well-designed service across containers solves the majority of real-world scaling needs.
Frameworks do not provide scalability. Infrastructure does.
If a system genuinely requires a radically different model—massive throughput, extreme latency constraints, or global distribution—it should be designed that way from the beginning, not retrofitted through abstractions.
SQL as a first-class citizen
One of the clearest casualties of over-abstraction has been the database layer.
Explicit SQL:
- communicates intent clearly,
- exposes real relationships,
- is auditable and optimizable,
- reflects the true domain model.
Even complex SQL tells a story. An experienced engineer can understand where data comes from, how it is transformed, and why it exists.
ORMs, especially general-purpose runtime ORMs, often obscure this narrative. Views, stored procedures, and optimized queries become difficult or unnatural to express. The abstraction replaces the domain instead of serving it.
In complex systems, this is not simplification—it is distortion.
The myth of constant migration
Automatic migrations were designed for a time when changing database engines was common.
That world no longer exists.
Today we:
- choose a database engine deliberately,
- containerize it,
- and evolve schemas incrementally.
Microservices and APIs further reduce the need for large-scale schema migrations. Services own their data. Interfaces, not schemas, define boundaries.
Migration is now an exception—not a foundation.
Typing is not abstraction—it is intent
Strong typing does not hide behavior. It clarifies it.
Types:
- define contracts,
- reduce ambiguity,
- guide both humans and AI,
- prevent entire classes of errors.
In an AI-assisted workflow, typing becomes even more valuable. It anchors generated code to explicit expectations.
Typing aligns perfectly with the Back to Lovelace philosophy.
The decline of runtime ORMs
Runtime ORMs introduce:
- latency,
- hidden queries,
- unpredictable performance,
- cognitive overhead.
They struggle with advanced database features such as:
- views,
- stored procedures,
- fine-grained optimization.
Modern systems benefit more from:
- explicit SQL,
- query builders where appropriate,
- compile-time checks,
- and clear data boundaries.
ORMs are not inherently evil—but as default runtime layers, their relevance is fading.
Small systems, composed into large ones
The future is not monolith versus microservices.
The future is intentional composition:
- small services,
- clear APIs,
- explicit responsibilities,
- minimal abstractions.
Serverless, microservices, and specialized APIs are not about fragmentation—they are about clarity.
Large systems should emerge from the combination of simple, understandable parts.
Conclusion: progress through subtraction
Back to Lovelace is not nostalgia.
It is an acknowledgment that:
- AI reduces the need for human-enforced abstractions,
- clarity beats cleverness,
- infrastructure scales systems—not frameworks,
- and explicit code is easier to reason about than magical behavior.
The future of software is not more layers.
It is fewer assumptions, clearer intent, and machines executing exactly what we mean.
That is not regression.
That is progress.
Top comments (0)