The Return of Engineering to Software

There is a deeper shift underway particularly in the software industry and software production methods and tools. What is changing is not the superficial process layer (Agile vs. Waterfall—although one could argue that certain aspects resemble a return to waterfall-like thinking), but the epistemology and mechanics of engineering itself: how systems are conceived, modeled, validated, and evolved. The center of gravity is moving from implementation toward system definition, constraint modeling, and formalization.

For the last 20 years, what has been called “software engineering” has been dominated by implementation, which is why it was more accurately described as “software development.” In classical engineering disciplines—especially those regulated due to safety, societal impact, and high consequences—the majority of intellectual effort occurs before construction begins. This is closely tied to the fact that development costs and failure consequences in those fields are substantial.

Software engineering is now likely moving from “engineering by construction” back to classical engineering by specification and constraint definition.

The key artifacts in system design are:

• system models
• architecture definitions
• specifications
• constraint definitions
• behavioral specifications
• interface contracts
• invariants
• failure modes
• system decomposition

Construction itself is comparatively deterministic.

Software historically inverted this structure because writing software, although time-consuming, was reversible and allowed for many iterations. As a result, the focus shifted toward the implementation phase (iterative, Agile), and the engineering phase was often minimized. One could argue that in many Agile practices, analysis and design were reduced (nearly to zero in meny cases), and development effectively began with coding an initial version of the solution and refining it over time.

Design rigor was often replaced with iterative discovery through coding. Systems were “grown” rather than engineered. This was an economic artifact, not a fundamental property of engineering.

Previously, constraints were discovered during implementation. Today, explicit constraint engineering—such as defining capacity, performance, security, and failure isolation requirements—replaces implicit constraint discovery. These constraints must be defined upfront so that AI systems can operate safely and correctly.

Engineering becomes the discipline of defining permissible system behavior—not writing behavior line-by-line.

Consider analogous engineering fields:

• Hardware engineers define circuit behavior rather than manually placing every transistor.
• Civil engineers define load constraints rather than laying every brick.

Engineering ends where formal definition and validation end. Software development begins when implementation is generated—now increasingly automatically.

With AI-powered implementation, the constraint of time-consuming coding is largely removed.

Implementation is no longer scarce.

Although iterations have become even cheaper and easier—as seen in approaches like “vibe coding”—there is increasingly little economic or technical justification for progressive iterative discovery when systems can be rapidly implemented based on well-defined engineering intent. Instead of discovering systems through iteration, we can now engineer them directly.

This shift exposes the missing engineering layer.

It creates the opportunity to focus on proper system engineering, knowing that implementation will be fast and inexpensive. Trial-and-error approaches become less necessary. Testing methods will likely evolve as well, since traditional testing practices are heavily oriented around human implementation error, which may become less dominant in AI-generated systems.

The Return of First-Principles Engineering

As implementation becomes inexpensive, engineering returns to its original core functions.

System modeling becomes primary.

Engineering becomes the act of defining system boundaries, context, interfaces, invariants, state transitions, and failure conditions.

This shifts the primary artifact from code to models and specifications.

Emerging primary artifacts include:

• architecture graphs
• interface contracts
• state machines
• constraint definitions
• formal or semi-formal specifications

Code becomes a derivative artifact—not the source artifact.

Emergence of Specification-Driven Development

This trend is already visible in the growing importance of prompts. The prompt increasingly functions as a form of system specification. However, current prompts still lack the precision, structure, and repeatability required for engineering-grade specifications.

This will likely evolve toward formalized specification-driven system generation.

In this paradigm, the system specification becomes the primary artifact from which implementation and related artifacts are derived—not only code, but also documentation, training materials, operational procedures, and supporting organizational artifacts.

Historically, code became the specification.

Now, the engineering specification generates the code.

This inverts the direction of derivation.

Key practices emerging include:

• contract-first design
• interface-first architecture
• schema-first systems
• model-first system definition

Formal specification languages may regain importance (e.g. TLA+, lloy, statechart, formal interface definition languages etc.)

Alongside these, lighter-weight specification approaches may emerge, expressed in structured natural language or constraint-based systems.

Convergence of Software Engineering and Systems Engineering

Historically, software engineering focused primarily on software-only systems. Today, software increasingly defines physical systems, including robotics, automation, and cyber-physical systems.

This expands software engineering into full systems engineering.

Software becomes the governing layer of physical reality.

Engineering methods must therefore align with classical systems engineering principles.

Engineers Become System Governors Rather Than System Builders

System design becomes the core engineering activity.

AI cannot autonomously define optimal architectures without explicit constraints, intent, and governing structure. This remains a human responsibility.

The role of the engineer evolves toward governing system behavior and evolution.

Key activities include:

• defining system invariants
• supervising AI-generated implementation
• validating architectural integrity
• managing complexity boundaries
• preventing architectural entropy

This role is closer to systems engineering than traditional programming.

Additional shifts include:

• transition from procedural engineering to declarative engineering
• emergence of meta-engineering (designing systems that generate other systems)
• increasing emphasis on complexity reduction and validation

Classical methods - not classical tools, scale and speed

Classical engineering methods—formal specification, model-based design, and constraint-driven development are here to stay as they form the logical chain of engineering reasoning, but they will be amplified . Historically, these methods were limited by the effort required to create and maintain formal artifacts. AI removes much of this constraint.

AI systems can now assist in translating specifications into formal models, generating verification properties, analyzing failures, and refining system definitions through iterative feedback. Research and industry prototypes already demonstrate AI agents capable of generating verification plans, formal assertions, and validation artifacts directly from system specifications, with humans supervising and governing the process.

This makes classical engineering rigor economically viable at scale. Methods that were once reserved for aerospace or semiconductor systems can now be applied to general software engineering. AI does not replace engineering methods—it makes them faster, more accessible, and continuously executable.

Engineering becomes not only possible upfront, but practical.

Return of Engineering Accountability

There is one final but critical aspect of engineering: it has always been fundamentally a profession defined by responsibility for system behavior. When AI generates implementation, this responsibility does not disappear. It cannot be delegated to the tool. The engineer remains accountable for system correctness, system safety, behavior, and integrity.

Our legal, economic, and institutional systems are built around human and organizational accountability, and this will not change in the foreseeable future. AI cannot bear legal responsibility, cannot be held liable, and cannot assume consequences. Responsibility will remain with the humans and institutions that define and deploy systems. And ultimately, this is not only a constraint, but a foundation of engineering itself. Engineers do not merely implement systems—they stand behind them. Even in an era of automated implementation, the role of the engineer remains defined by ownership, judgment, and responsibility.