Intent Engineering: The Emerging Skill of Software Development

For most of my career, software development was fundamentally an exercise in implementation.

A requirement would arrive in the form of a user story, a design document, a conversation, or sometimes a vague request from a stakeholder. The job of the developer was to translate that intent into working software. Success was largely determined by an individual’s ability to understand a problem and then express a solution through code.

That model is beginning to change.

After spending the last year working extensively with AI coding agents, I have noticed a shift in where I spend my time. I write less code than I once did. In some cases, significantly less. Yet I don’t feel like I’m doing less software engineering. I’m doing more.

The nature of the work has changed. The challenge is no longer primarily implementation — it is communicating intent. The most productive sessions are no longer the ones where I type the fastest, but the ones where I think the clearest.

Intent as an Engineering Artifact

When developers discuss AI-assisted development, much of the conversation focuses on code generation. The demonstrations are impressive. A prompt is entered and hundreds of lines of code appear moments later. The natural conclusion is that coding itself is becoming less important.

I believe this conclusion misses the larger transformation.

The code generation is the visible part of the change. The more significant shift is happening upstream.

Every generated solution begins with a description. That description may be a prompt, a design document, a set of requirements, a user story, a test suite, or a collection of architectural constraints. Whatever form it takes, the quality of the output is largely determined by the quality of the intent that precedes it.

This observation is not unique. Andrej Karpathy has described large language models as a new kind of computer that is programmed through natural language. His progression from “Software 2.0” to what he later called “Software 3.0” reflects the same underlying trend: the interface between humans and machines is moving to a higher level of abstraction.

The implementation still matters, but the description matters more than it used to.

Deterministic Systems Meet Probabilistic Systems

For decades, software engineers have built deterministic systems. We write code because we want predictable behavior. Given the same inputs, we expect the same outputs. We spend enormous effort eliminating uncertainty from our systems.

Large language models introduce something fundamentally different into the development process.

The software we build remains deterministic, but the tools we use to build it are not. This creates an interesting tension. Developers are now interacting with systems that produce different solutions to the same problem, highlight different tradeoffs, and occasionally interpret requirements in unexpected ways. The implementation may vary, but the desired outcome remains fixed.

As a result, the role of the engineer shifts. Rather than focusing exclusively on implementation details, we increasingly focus on defining boundaries, constraints, and desired outcomes. We spend more time describing what success looks like and less time manually constructing every step required to achieve it.

In many ways, this resembles working with another engineer — one that happens to be a probabilistic system.

Why Architecture Matters More, Not Less

One of the most common misconceptions surrounding AI-assisted development is that software engineering fundamentals will become less important.

My experience has been exactly the opposite.

Good architecture provides clarity. Clear systems have clear boundaries, and clear boundaries are easier for both humans and AI to reason about. When a system has a well-defined domain model, explicit interfaces, clear ownership boundaries, and strong testing practices, AI agents tend to perform remarkably well. The intent is easier to communicate because the structure already exists.

Poorly designed systems amplify ambiguity. When responsibilities are unclear, naming is inconsistent, and architectural decisions are undocumented, AI agents struggle for the same reason human developers struggle: they are forced to make assumptions.

Recent research into AI-generated software systems has highlighted architectural complexity as one of the primary challenges facing large-scale AI-assisted development. While models can generate functional implementations, maintaining coherence across an evolving system remains an engineering problem. The result is not better productivity. It is simply faster production of uncertainty.

The more I use AI coding tools, the more I appreciate the value of solid engineering practices. Design principles that once helped teams collaborate effectively now help humans and AI collaborate effectively. The fundamentals have not become obsolete. They have become leverage.

Code Is Becoming Abundant

Historically, code was expensive. Writing it required time. Reviewing it required time. Refactoring it required time. Large systems accumulated value because they represented significant investment.

AI changes the economics of software creation. Today, generating a new implementation is often cheaper than modifying an existing one. Entire modules can be recreated in minutes. Multiple approaches can be explored simultaneously. Refactoring experiments that once felt expensive can now be performed almost casually.

This abundance changes what we should value. If code can be regenerated, then the enduring assets are no longer the implementation itself. The enduring assets are:

• Requirements
• Specifications
• Architecture
• Tests
• Domain knowledge
• Design decisions

This conclusion is increasingly appearing in both industry discussion and academic research. Recent studies examining AI-assisted development have observed that as the cost of producing code decreases, the importance of specification, architectural understanding, context management, and verification increases.

The bottleneck moves. The work does not disappear. The specification increasingly becomes the source of truth, and the code becomes one possible realization of that truth.

Testing Becomes the New Bottleneck

If code becomes cheaper to create, something else becomes the limiting factor: confidence.

Historically, much of software engineering effort was spent producing code. Increasingly, the effort is shifting toward validating it. This mirrors a point frequently made by Simon Willison, who argues that the job of a software engineer is not to produce code but to deliver software that has been proven to work.

AI can generate ten implementations, but it cannot determine which one belongs in production. That responsibility remains with the engineer.

As code generation accelerates, testing, evaluation, observability, and verification become more important than ever. The teams that succeed with AI are unlikely to be the teams generating the most code. They will be the teams most capable of determining whether the generated code is correct.

The Emergence of Intent Engineering

I have started thinking about this shift as a new discipline: Intent Engineering. It is the practice of creating precise descriptions of desired outcomes. The goal is not merely to tell an AI what code to generate. It is to create a shared understanding of a problem space so complete that multiple implementations could be produced successfully from the same specification.

Interestingly, emerging research is beginning to describe software engineering in similar terms. Some researchers have characterized the shift as a movement from code-centric engineering toward intent-centric engineering, where the role of the developer increasingly involves guiding, validating, and governing systems rather than manually constructing every implementation detail.

This is not entirely new. Experienced architects, technical leads, and staff engineers have always operated in this space. What is changing is that these skills are becoming relevant to a much broader group of developers. The ability to write a clear specification may soon be more valuable than the ability to manually implement every detail of that specification, and the ability to define a system may become more important than the ability to type the code that realizes it.

A Familiar Pattern

This is not the first time software development has undergone a shift of abstraction.

Developers once wrote machine code directly. Then assembly language emerged. Higher-level languages followed. Frameworks abstracted common patterns. Cloud platforms abstracted infrastructure. Containers abstracted deployment concerns. Each transition moved developers further away from implementation details and closer to expressing intent.

AI-assisted development feels like the next step in that progression. We are not eliminating programming; we are raising the level at which programming occurs. The engineer’s job is becoming less about instructing the computer and more about defining the system.

Final Thoughts

The future I see is not one where software engineers disappear. It is one where the most valuable engineers become exceptional communicators. They understand requirements deeply, create clear specifications, design robust architectures, define meaningful tests, and establish constraints that guide implementation. In short, they become experts in intent.

Code remains important. Software still needs to be built. Systems still need to operate reliably in production. None of that changes. What changes is where the scarcity lies.

For decades, the scarce resource was the ability to produce code. Increasingly, the scarce resource is the ability to clearly describe what should be built. The implementation can be generated. The intent cannot.