Frankenstein Architecture: The Risk of Agents Without Technical Direction

The automation of software development via autonomous agents promises to resolve the eternal bottleneck of product delivery, acting as a siren song for short-term productivity. However, beneath this illusion of velocity lies a formidable entropic force. When the marginal cost of generating code drops to zero, the fundamental laws of system design assert themselves. Without explicit, governed technical boundaries, the codebase undergoes accelerated degradation, giving rise to what we call Frankenstein architecture: a patched quilt of disjointed, locally optimized modifications that are globally destructive.

Jevons’ paradox in the economics of code

In 1865, economist William Stanley Jevons observed that technological improvements increasing coal efficiency did not decrease its overall consumption; instead, they multiplied it by making its industrial exploitation cheaper and expanding demand. We are witnessing an analogous phenomenon in modern software engineering.

The ability of large language models to spit out syntax at lightning speed does not relieve development teams of their workload. On the contrary, it exponentially increases the volume of code that must be read, integrated, and maintained. Writing lines of code is no longer the system’s constraint. The new bottleneck is the cognitive capacity required to audit the coherence and design intent of what is generated.

If a development agent can implement a feature in three minutes that would take a human three hours, the developer’s role is not eliminated but transformed: they must now spend those three hours verifying that the modifications do not introduce silent regressions, security flaws, or architectural violations. The cheapening of production shifts the system’s bottleneck entirely to governance.

Entropy and Lehman’s laws in the agentic era

The thermodynamics of software were formally stated by Manny Lehman in his second law of software evolution (1974): as a system evolves, its complexity increases naturally unless active, deliberate work is done to simplify it.

The Achilles’ heel of development agents lies in the boundaries of their context window. No matter how large this window is, it represents a transient, statistical memory space—not a coherent, historical, and evolutionary mental model of the product. An LLM does not reason about architecture in the abstract; it infers token relationships from pre-existing code.

When asked to patch a defect or add a new feature, the agent will optimize its output to satisfy the pipeline’s completion criteria (usually a successful test suite execution) through the path of least resistance. This dynamic catalyses suboptimal local optimization:

• Architectural bypassing: To avoid reading and understanding a complex database abstraction layer, the agent might choose to couple presentation logic by executing raw SQL queries directly inside the transport layer (e.g., API controllers).
• Unconscious semantic duplication: Failing to conceptually recognize an existing abstraction that calculates taxes or validates schemas, the agent will generate a parallel utility in another folder under subtle syntactic variations, fragmenting business logic.
• The green test bias: The agent can successfully pass a local suite of unit tests while introducing temporal coupling so severe that it compromises performance under concurrency, leaving the system structurally wounded.

As highlighted by the 2024 GitClear Report, the widespread adoption of AI assistants has led to a drastic increase in code churn and redundancy. We write more code than ever, but its life expectancy has plummeted due to its low intrinsic architectural quality.

The agentic governance pyramid

To tame non-deterministic agents and prevent the chaotic accumulation of accidental complexity, engineering teams must structure the workspace through explicit constraints. If design boundaries are not coded as hard guardrails, the agent—driven by its statistical loss function—will incrementally erode them.

Level 1: Pragmatic governance and deterministic formatting

Governance begins at the lowest, most physical layer of development: formatting standards. A classic mistake when delegating tasks to an agent is letting it dictate the aesthetic style of the code. In each iteration, the agent may alternate between spaces and tabs, change file encoding, or reformat entire blocks—triggering massive commits that ruin Git history and hide actual logic changes.

The first line of defense is a deterministic file like .editorconfig. By establishing rigid, explicit guidelines for indentation, encoding, and newlines at the project root, we force any agent reading and editing the repository to configure its editing engine under the same mathematical parameters.

root = true

[*]
indent_style = space
indent_size = 2
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
end_of_line = lf

This simple step reduces stylistic noise to zero, isolating commits strictly to conceptual code modifications.

Level 2: Syntactic governance through static analysis

The second level involves automating the capture of common code smells and vulnerabilities in real time. Configuring tools like ESLint, Prettier, and static security analyzers in pre-commit hooks ensures that the agent receives immediate feedback on its syntactic errors before attempting to publish its work. If the code fails to compile or violates linter rules, the local pipeline halts the agent’s execution, forcing it to iterate on its own errors in a closed self-healing loop.

Level 3: Architectural governance and design assertions

This is where we prevent the agent from disfiguring the system’s architecture. An agent has no intrinsic respect for separation of concerns or clean/modular boundaries. If it needs a dependency, it will import it across any logical boundary as long as it makes its local tests pass.

We must encode the architecture into automated tests. In structured ecosystems, tools like ArchUnit allow writing explicit assertions about code organization:

// Domain must never depend on the persistence infrastructure layer
classes().that().resideInAPackage("..domain..")
    .should().onlyDependOnClassesThat().resideInAPackage("..domain..");

In TypeScript or JavaScript, tools like dependency-cruiser allow defining allowed dependency graphs in a JSON configuration. If the agent attempts to perform a forbidden import (e.g., importing the infrastructure layer from the core domain), the local build will fail immediately. Design decisions stop being passive guidelines and become deterministic tests that block compilation.

Level 4: Semantic governance through system instructions

At the top of the pyramid lies semantic governance. Through context files like AGENTS.md or .cursorrules, human engineers communicate abstract design invariants, codebase philosophy, and project heuristics to the agent.

This communication channel defines intent rules:

• “Favor data immutability throughout the domain layer.”
• “Do not import external libraries for utilities that can be solved with the native JavaScript API.”
• “When modifying a use case, update the corresponding acceptance test rather than writing a new unit test.”

These semantic instructions fill the interpretative gap that deterministic tools cannot analyze, shaping the AI’s conceptual behavior.

Conclusion: The senior engineer as a boundary designer

The arrival of agentic AI does not reduce the importance of software design; it elevates it to a critical dimension. In a traditional development workflow, an engineer spends most of their day writing sequential code. In the agentic era, a senior engineer’s differential value lies in their ability to act as a sandbox architect: a professional capable of building the framework of assertions, boundaries, and validations within which AI agents can produce code safely, coherently, and in alignment with the system’s long-term goals.

The next time an agent generates a Pull Request, do not just check if the tests pass. Ask yourself if you are looking at a clean, sustainable design or the first seams of a Frankenstein architecture that will devour your productivity tomorrow. AI governance is not an optional step; it is the only safety net for your codebase’s survival.