Author's note: This article is one of the original fourteen pieces that formed the foundation of Intent-Driven Development. The complete framework - refined, restructured, and expanded - now lives at intentdrivendevelopment.org, where you can also download the free ebook. This article remains here as part of the original record.

The New Practitioner – Skills, Mindset, and the Future of Every Role in the Intent-Driven Age

Across the previous eight articles in this series, a consistent theme has emerged. Intent-Driven Development (IDD) does not introduce yet another development methodology layered on top of existing practice. Instead, it represents a structural shift in how software delivery is governed in an era where AI systems increasingly perform implementation.

For decades, the central professional question for software practitioners has been straightforward: how do we build this correctly? The craft of engineering, architecture, testing and design has revolved around the artefacts produced in response to that question.

As AI systems take on an increasing proportion of implementation work, that central question changes. The practitioner’s task becomes something more demanding: how do we define intent with sufficient clarity that execution can safely be delegated? This is something our industry is inherently bad at and is one of the key reasons for the emergence of agile.

This is not a reduction in professional responsibility. It is an elevation of it. And it affects every role involved in modern software delivery.

Readers coming from different disciplines may wish to jump directly to the section most relevant to them:

• User-Centred Design
• UX Design
• Product Management
• Software Engineering
• Architecture
• QA / Test Engineering
• Security Engineering
• Platform / DevOps
• Engineering Leadership

Each of these roles continues to exist. None disappears. What changes is where their expertise is applied and how their contributions shape the governing intent that AI systems execute against.

From Maker to Designer of Constraint

One of the most significant shifts in an Intent-Driven organisation is the transition from making systems to designing the constraints that govern how systems are built.

In traditional development environments, professional value has been closely associated with implementation output. Engineers write code. Designers produce mock-ups. Architects document systems. QA practitioners validate behaviour.

When AI systems can generate implementation at speeds far beyond human capability, that model begins to change. The production of artefacts becomes less scarce. What becomes scarce instead is the clarity of the intent that governs those artefacts.

In an Intent-Driven environment, practitioners increasingly contribute by defining the boundaries within which autonomous systems operate. Deep expertise remains essential, but its application shifts upstream. Knowledge of architecture, testing strategy, human behaviour or security risk becomes the foundation for specifying constraints that guide AI systems rather than for implementing those constraints directly.

The practitioner does not disappear from the delivery process. They become the author of the intent that governs it.

Skills That Compound in Value

Not all professional capabilities evolve equally in an environment where implementation becomes increasingly automated.

Several skills increase dramatically in importance.

Ambiguity resolution becomes one of the most valuable capabilities a practitioner can develop. The ability to recognise where intent is unclear, and where that ambiguity will cause downstream misalignment, becomes critical when execution happens at machine speed.

Cross-disciplinary translation also becomes more important. Intent specifications increasingly require contributions from product thinking, user insight, architectural reasoning, security constraints and operational considerations. Practitioners who can translate between these perspectives play a critical role in producing coherent governing intent.

Governance literacy becomes part of everyday professional practice. Understanding risk thresholds, accountability boundaries and escalation mechanisms is no longer a leadership-only concern. It becomes a practitioner responsibility.

And finally, intent fidelity judgement, introduced in Article 6, becomes a core signal of quality. The central question shifts from “does the code work?” to “does the implementation faithfully represent the intent that governed it?”

A Profession, Not a Persona

One common narrative emerging around AI development suggests the rise of a new singular role, often described as an “AI Engineer”, who blends product thinking, design, architecture and engineering into one individual.

There is truth in the observation that disciplinary boundaries are becoming more permeable. Practitioners must increasingly understand adjacent fields.

But literacy should not be confused with mastery.

Enterprise-grade software systems have always required coordinated expertise across multiple disciplines. Intent-Driven Development does not eliminate that need. If anything, it increases it.

The governing artefact, the intent specification, becomes the shared coordination point across disciplines. Each role contributes its expertise to the same structure of intent rather than operating sequentially through disconnected artefacts.

The future practitioner is therefore not a universal generalist. They are a specialist who contributes to a system organised around shared intent.

Roles Reimagined

User-Centred Design

In many traditional delivery models, User-Centred Design (UCD) has entered the process late. By the time designers engage with real users, architectural decisions and delivery commitments have often already been made.

In an Intent-Driven organisation, that sequencing reverses.

User-centred design becomes the origin point of delivery. User goals, behavioural patterns, accessibility needs and ethical considerations form the earliest expression of intent that shapes everything that follows.

The discipline therefore expands beyond interface design toward structured articulation of human need. When autonomous systems generate implementation, they do so at scale. Poorly understood user intent therefore propagates rapidly. Clear articulation of user purpose becomes foundational to safe delegation.

UX Design

UX design moves upstream as well, shifting from designing interfaces during delivery to designing the experience constraints that govern them.

User flows, behavioural expectations, accessibility requirements and failure states must increasingly be encoded within intent specifications. In systems where AI generates interface behaviour dynamically, UX governance becomes the discipline that ensures experiences remain coherent and aligned with human needs.

Product Management

Product management evolves from coordinating delivery toward governing business intent.

Instead of translating loosely defined stakeholder demands into backlog items, product practitioners increasingly define outcome boundaries within which implementation occurs. Priorities become expressions of intent rather than queues of work.

This shift gives product management greater leverage but also greater responsibility. Ambiguity that might previously have been resolved during implementation must now be resolved at the level of intent.

Software Engineering

Software engineering undergoes perhaps the most visible identity shift.

The craft of building systems does not disappear, but its centre of gravity moves. Engineers increasingly contribute by translating product, user and architectural goals into technical constraints that AI systems can implement reliably.

Deep engineering knowledge remains essential. It informs the constraints that prevent systems from failing. But instead of applying that knowledge only during implementation, engineers increasingly apply it during specification.

Engineers evolve from implementers to architects of constraint.

Architecture

Architectural thinking becomes embedded directly within intent specifications.

Rather than producing advisory documentation, architects define the structural principles that govern how systems may be built. Architectural patterns, boundaries and non-functional requirements become explicit constraints that guide implementation.

Architecture therefore becomes more tightly coupled to delivery while retaining its strategic role.

QA and Test Engineering

Testing evolves from verifying implementation to verifying intent fidelity.

QA practitioners increasingly measure whether systems behave in ways that reflect the intent governing them. The measurement frameworks discussed in Article 6 become core governance tools for organisations adopting AI-driven delivery.

Security Engineering

Security constraints move from post-implementation review to upstream specification.

As autonomous systems gain the ability to access infrastructure, interact with services and manipulate data, security boundaries must be encoded directly within governing intent. Security practitioners therefore play a foundational role in defining the limits within which AI systems operate.

Platform and DevOps

Platform teams become the operational backbone of intent-driven delivery.

Their systems support not only deployment pipelines but also the measurement, governance and orchestration required for safe autonomous implementation, particularly within the multi-agent architectures described in Article 5.
.

Engineering Leadership

Engineering leaders play a critical role in guiding teams through the mindset shift required by intent-driven practice.

They create the conditions in which practitioners can develop specification capability, maintain governance discipline and adopt AI tools without sacrificing accountability.

The transition from implementation-centred delivery to intent-centred governance is as much cultural as technical.

What the Practitioner Carries Forward

Across every role described above, one principle remains constant.

Delegating execution does not mean delegating responsibility.

The practitioner who defines the intent governing an autonomous system remains accountable for the outcomes it produces.

As AI systems accelerate the pace of implementation, the professional responsibility of practitioners becomes clearer rather than weaker.

Their work shifts toward the design of intent that governs those systems.

The Next Step

If practitioners are to govern execution through intent, one question inevitably follows.

What does a well-formed intent specification actually look like?

The next article explores that question directly, examining how organisations can structure intent specifications that safely guide AI-driven implementation.

Next Article ->

Intent-Driven Development – How do you Specify Your Intent

What does an Intent-Driven Development specification actually contain? This article introduces the six elements that allow autonomous systems to execute reliably while remaining aligned with human intent.