The Work Order Is the New Unit of Software Development

Software Engineering in the Age of AI — Part 3: From Requirements to Implementation

Throughout my career, I’ve worked on software projects where the responsibilities of business analysts, architects, and developers were clearly separated. Business analysts worked with stakeholders to establish requirements, architects designed the systems needed to satisfy those requirements, and developers translated the resulting specifications into working software. Depending on the organization and the project, those responsibilities might have belonged to different teams or been combined among a smaller group of engineers.

Regardless of how the roles were organized, the process required translating a business problem into a technical solution. Someone had to understand what the business needed, decide how the software should behave, determine where that behavior belonged in the architecture, and establish how the resulting implementation would be verified.

Over time, development tools became increasingly sophisticated, reducing the amount of effort required to produce working code. Modern programming languages, application frameworks, libraries, and integrated development environments eliminated much of the mechanical work that earlier generations of developers performed manually. Despite these improvements, implementing software remained a substantial part of the overall engineering effort.

Artificial intelligence is changing that balance.

Today, an AI coding agent can receive a natural-language assignment, examine an existing application, modify source files, create automated tests, and execute development tools. Depending on the assignment and the capabilities of the model, work that once occupied a developer for several days may be completed much more quickly.

What AI does not eliminate is the responsibility for deciding what should be built, how it should fit into the existing system, and what evidence demonstrates that the implementation is correct. Those responsibilities become more important when implementation can proceed faster than a human can comfortably inspect every line of generated code.

This is why I believe the software engineer of the AI era increasingly needs the combined skills of a business analyst and a software architect. The engineer must understand the business problem, translate it into precise requirements, establish architectural boundaries, and define an assignment that an AI agent can execute and verify.

The mechanism for doing that is something software organizations have used for decades: the Work Order.

From Writing Code to Engineering Solutions

In the first article of this series, Before the First Prompt, we established a development environment with Git, automated testing, CI/CD, and separation between development and production. In the second, How We Got Here, we examined the evolution of software development methodologies and used their lessons to establish an application architecture and persistent engineering instructions for AI agents.

At this point, we have an environment in which software can be developed and an engineering framework describing how development should occur. What we haven’t established is how an individual implementation assignment moves from a business requirement to a verified software component.

Traditionally, that translation required considerable interaction between business analysts, architects, and developers. Requirements documents described desired functionality, design documents established how the system would implement it, and developers were responsible for turning those descriptions into working code.

The process was not always as orderly as it sounds. Requirements could be ambiguous, architectural decisions were sometimes made during implementation, and developers frequently discovered missing information after work had begun. The resulting questions, assumptions, and corrections became part of the normal development process.

With AI coding agents, the same problems remain, but the consequences of ambiguity can arrive much faster. An agent given a broad assignment may produce a substantial implementation before anyone discovers that it misunderstood the requirement or selected an inappropriate architectural approach.

An agent instructed to “build task management functionality” might create a database schema, API controllers, user interfaces, business logic, and supporting utilities in one operation. The result could appear functional while duplicating existing capabilities, violating architectural boundaries, or introducing behaviors that nobody requested.

The solution is not necessarily a more sophisticated model or a longer prompt. It is to apply a familiar engineering discipline: decompose the problem into smaller units whose expected behavior, boundaries, and dependencies can be clearly established.

Functional Decomposition: The Other Side of TDD

Functional decomposition is one of the oldest and most useful principles in software engineering. A large business requirement is divided into progressively smaller functions until the individual components are sufficiently well understood to be implemented and tested independently.

The process isn’t simply a method for distributing work among developers. It forces us to examine the responsibilities and relationships within a system. When we decompose a requirement, we identify the behavior the system must provide, the information it requires, the rules governing that behavior, and the dependencies needed to implement it.

Consider our Task Management application. A broad requirement might state that users must be able to assign tasks to other users.

That statement appears straightforward, but it conceals several questions. Can a task be assigned to anyone, or only to members of a particular team? Can completed tasks be reassigned? What happens when the assigned user no longer exists? Does changing an assignment produce an audit record or notification? Who is authorized to make the change?

These are business questions, not programming questions. We need to answer them before asking an agent to implement the functionality, because the answers determine both the expected behavior and the architectural responsibilities involved.

Once those rules are established, we can decompose the feature into individual capabilities. The assignment operation may require validating the target user, checking the task’s current state, enforcing authorization, changing the assigned user, persisting the modification, and reporting the result.

Not all of these capabilities need to be implemented in the same component. Some may already exist as reusable services, while others may require new domain behavior or infrastructure integration. The architect must identify those boundaries before implementation proceeds.

This is where functional decomposition and Test-Driven Development become complementary.

TDD establishes how an individual behavior will be verified. Functional decomposition makes the behavior small and coherent enough that its expected results can be defined and tested.

An agent receiving a narrowly scoped assignment doesn’t need to design the entire Task Management application. It needs to implement one specified behavior within the established architecture and demonstrate that the relevant tests pass.

The smaller and more precise the assignment, the easier it becomes to evaluate the result and recognize when the agent has exceeded its authority.

There is a practical limit to this decomposition. Dividing work into arbitrary fragments can create unnecessary coordination overhead and obscure the behavior we’re trying to implement. Our objective is not to make every Work Order correspond literally to one test or one function. It is to make each assignment represent a single coherent, independently verifiable unit of work.

The Work Order as an Engineering Contract

The term Work Order is deliberately familiar. Engineering, manufacturing, maintenance, and IT organizations have used Work Orders for decades to authorize and track specific tasks. A Work Order identifies what needs to be accomplished, establishes relevant constraints, and provides a basis for determining whether the work is complete.

We’re applying the same concept to software implementation by an AI coding agent.

A Work Order is more than a conversational prompt. It is a bounded engineering assignment that defines the business objective, required behavior, architectural context, permitted changes, verification requirements, and evidence necessary for acceptance.

This distinction is important because a prompt often describes an intended result without adequately constraining how the result should be achieved. A Work Order establishes both the objective and the boundaries within which implementation must occur.

The agent doesn’t receive unrestricted responsibility for deciding how the application should work. It receives a specific assignment within a system whose architecture and engineering practices have already been established.

That doesn’t mean the agent is reduced to mechanically following instructions. It can still make implementation decisions, examine code, identify defects, suggest improvements, and report missing requirements. The difference is that significant changes to the assigned scope or established architecture must be brought back for review rather than incorporated without authorization.

A useful Work Order should therefore be detailed enough to remove unnecessary ambiguity without attempting to prescribe every line of implementation code.

Anatomy of a Work Order

For our development methodology, I would establish ten core components of a Work Order. These create a consistent contract between the engineer defining the assignment and the agent responsible for executing it.

1. Identifier and Title

Every Work Order needs a unique identifier and a descriptive title. The identifier provides traceability between the original requirement, implementation changes, automated tests, and integration records.

For our Task Management application, we might use an identifier such as TM-ASSIGN-001, with the title “Implement Task Assignment Validation.”

This identifier should accompany the work through implementation and review. Where practical, it can also appear in branch names, commit messages, and related documentation, making it easier to identify which changes satisfied a particular requirement.

2. Business Objective

The business objective explains why the functionality exists and what problem it is intended to solve.

It should describe the desired outcome in terms the business understands rather than immediately prescribing a technical implementation. This gives the agent context while helping the engineer verify that the technical requirement actually supports the intended business behavior.

For example, the objective might be to prevent invalid task assignments while allowing authorized users to assign active tasks to eligible team members.

3. Functional Requirements

Functional requirements describe the specific behavior the implementation must provide. They identify the conditions under which a function operates, the rules it must enforce, and the results it must produce.

Ambiguous language should be avoided wherever possible. A requirement stating that the system must “handle invalid assignments appropriately” provides little useful direction. A requirement stating that assignments to inactive users must be rejected with a defined error result is substantially more useful.

This is where the business analyst’s understanding of the domain becomes essential. The engineer must identify missing rules and resolve uncertainty before authorizing implementation.

4. Scope and Exclusions

Every Work Order should explicitly state which functionality is included and which changes are outside the assignment.

This may be the most important behavioral constraint we place on an AI coding agent. Agents are often capable of proposing and implementing changes well beyond the immediate problem, particularly when they encounter incomplete code or opportunities for improvement.

Some of those changes may be beneficial, but they can also introduce unreviewed dependencies, architectural inconsistencies, and regressions in unrelated functionality.

A narrowly defined scope allows the agent to concentrate on the assigned behavior. Exclusions make clear which areas are not to be modified without additional authorization.

5. Architectural Context

The architectural context identifies where the functionality belongs within the system and which existing components, interfaces, and dependencies should be used.

This connects the individual Work Order to the engineering standards established in the second article.

For example, business validation belongs in the appropriate application or domain layer rather than being duplicated inside an ASP.NET Core controller. Persistence operations should use the established repository interfaces, and the new implementation should not introduce direct database dependencies into domain logic.

Without this context, an agent may satisfy the functional requirement while creating an implementation that undermines the architecture.

6. Inputs and Outputs

A Work Order should define the information required by the component and the results it must produce.

This includes relevant data structures, required fields, validation assumptions, return values, and error conditions. Where interfaces already exist, the Work Order should reference them rather than creating competing definitions.

Precise input and output contracts also improve testability. They allow the expected behavior to be expressed independently of implementation details.

7. Acceptance Criteria

Acceptance criteria establish the conditions under which the implementation can be considered complete.

These should be observable, measurable, and directly related to the functional requirements. They should cover successful behavior as well as important failure conditions and boundaries.

Acceptance criteria are not necessarily identical to individual unit tests. A single criterion may require several tests, while some criteria may require integration testing or review of generated artifacts.

Their purpose is to establish an objective basis for accepting or rejecting the completed work.

8. Test Requirements

The test requirements specify how the behavior must be verified.

For functionality suited to TDD, the agent should establish failing tests before implementing the corresponding behavior. Tests should cover successful operations, invalid inputs, relevant boundary conditions, and regression scenarios.

The Work Order should also identify which existing test suites must continue to pass and whether the change requires integration tests.

Tests written by the agent remain subject to review. An agent that generates both the implementation and its tests can misunderstand the same requirement in both places. Independent acceptance criteria, established reference cases, and human review help reduce that risk.

9. Execution Instructions

Execution instructions establish the sequence and constraints under which the agent should perform the assignment.

These may include examining existing interfaces before making changes, writing tests first, avoiding new dependencies, limiting modifications to specified components, and running relevant verification commands.

The agent should also be instructed to report ambiguities or architectural conflicts rather than silently inventing new requirements.

Execution instructions supplement the project’s global engineering methodology. They should not duplicate every organizational standard or contradict the instructions already established for the repository.

10. Completion Evidence

Finally, a Work Order must define what the agent provides when its implementation is complete.

A completion report should identify the files modified, tests added or changed, verification commands executed, results obtained, and any unresolved issues or assumptions.

The report should also identify deviations from the original assignment and explain why they occurred.

This evidence allows the engineer to review the work without relying solely on the agent’s statement that the task was completed successfully. The authoritative integration result will still come from the project’s CI/CD process, but the agent’s report provides the context needed to evaluate the submitted changes.

Applying the Work Order to Our Task Management Application

Let’s return to the Task Management application we’ve been developing throughout this series.

Our next business requirement is to support task assignments. For the initial implementation, we’ll assume that tasks belong to a team, that active users may be assigned tasks within their team, and that completed tasks cannot be reassigned without first being reopened.

These are illustrative business rules for the example application. In a real project, we would establish them through discussions with stakeholders and record the decisions in the project’s requirements documentation.

Rather than asking the agent to implement the entire assignment feature, we’ll begin with a smaller component: validating whether a proposed task assignment is permitted.

This behavior can be implemented within the domain layer, tested independently of the database and user interface, and later used by an application service responsible for completing the assignment operation.

Our functional decomposition might identify several Work Orders:

• TM-ASSIGN-001: Implement task assignment validation.
• TM-ASSIGN-002: Implement the application service for changing task assignments.
• TM-ASSIGN-003: Implement assignment persistence through existing repository interfaces.
• TM-ASSIGN-004: Expose the assignment operation through the application API.
• TM-ASSIGN-005: Add the task assignment interface and integration tests.

Each assignment has a defined responsibility and can be evaluated against its own acceptance criteria. The sequence also follows the architecture rather than encouraging the agent to implement the feature as a single monolithic operation.

We’ll use the first Work Order to demonstrate the complete specification.

Example Work Order: Task Assignment Validation

The following is a realistic example of the kind of assignment I would give an AI coding agent. It assumes that the application architecture and global engineering instructions established in Article 2 are already available in the repository.

The purpose is not to teach a particular agent’s prompting syntax. The Work Order should be usable with any sufficiently capable coding agent that can access the repository, modify source files, and execute the project’s testing tools.

WORK ORDER: TM-ASSIGN-001

Title: Implement Task Assignment Validation

Project: Task Manager

Component: TaskManager.Domain

Type: Domain Logic Implementation

Status: Ready for Implementation

Business Objective

Prevent invalid task assignments by enforcing established task lifecycle and team-membership rules. The validation component must determine whether a specified user is eligible to receive a task without modifying the task or requiring access to persistence infrastructure.

Functional Requirements

Implement task assignment validation using the existing domain models and established interfaces.

The validator must evaluate the following rules:

1. A task may be assigned only when its status is Open or In Progress.
2. The target user must be active.
3. The target user must belong to the same team as the task.
4. A null or missing target user must be rejected.
5. Validation must not modify the task or user objects.
6. Validation must return a structured result indicating success or the reason for rejection.

For this assignment, task and user identifiers are assumed to have already been resolved into valid domain objects by the calling application service. Missing or inactive user references are handled as specified above.

Scope

Implement only the domain-level validation behavior.

The agent may create a validator component and its associated unit tests within the existing domain and domain test projects.

The agent may introduce a small domain validation result type if no suitable existing type is available.

The implementation must use existing domain models and conventions wherever possible.

Explicit Exclusions

Do not modify the database schema, repository implementations, API controllers, user interfaces, authentication logic, or deployment configuration.

Do not implement persistence or change the assigned user on a task.

Do not introduce a new third-party dependency.

Do not redesign the task lifecycle or user membership model.

If existing domain models cannot represent the required behavior, report the limitation rather than independently expanding the scope.

Architectural Context

The validator belongs in TaskManager.Domain.

It must not depend on ASP.NET Core, Entity Framework Core, SQL Server, or other infrastructure components.

The implementation should use existing task and user domain types.

If the project already contains a reusable validation result abstraction, prefer that abstraction over introducing a duplicate.

Inputs

The validation operation accepts:

• A task domain object.
• A target user domain object or null.

The task provides its current status and owning team identifier.

The user provides its active status and team membership information.

Outputs

Return a structured validation result containing:

• A success indicator.
• A machine-readable failure code when validation fails.

Required failure codes:

• TASK_NOT_ASSIGNABLE
• USER_REQUIRED
• USER_INACTIVE
• USER_NOT_IN_TEAM

For deterministic behavior when multiple conditions are invalid, evaluate rules in the order listed: task status, user presence, user active status, and team membership. Return the first applicable failure.

Acceptance Criteria

The implementation is acceptable when:

• Open tasks can be assigned to active members of the owning team.
• In Progress tasks can be assigned to active members of the owning team.
• Completed tasks are rejected.
• Cancelled tasks are rejected.
• Null users are rejected.
• Inactive users are rejected.
• Users outside the task’s team are rejected.
• Failure results contain the expected codes.
• Validation produces no changes to the supplied domain objects.
• Existing domain tests continue to pass.

Test Requirements

Follow Test-Driven Development.

Create failing unit tests covering all acceptance criteria before implementing the validator.

Include tests verifying that the validator returns the documented failure code for each rejection condition and follows the specified precedence when multiple conditions are invalid.

Tests must not require a database, web server, or network connection.

Execute:

dotnet test tests/TaskManager.Domain.Tests

After implementation, execute the solution’s full automated test suite.

Execution Instructions

1. Review the project’s global engineering instructions.
2. Examine the existing domain models, validation abstractions, and testing conventions.
3. Report any conflicting or missing architectural dependencies that prevent implementation.
4. Implement the required tests and verify they fail for the expected reason.
5. Implement the minimum functionality necessary to satisfy the tests.
6. Refactor while preserving passing tests.
7. Execute the domain and solution test suites.
8. Review the changed files for modifications outside the authorized scope.
9. Prepare the completion report.

Do not modify unrelated functionality to make tests pass.

Completion Evidence

Provide a report containing:

• Files created or modified.
• Tests added.
• Test execution results.
• Any unresolved issues.
• Assumptions made during implementation.
• Confirmation that no changes were made outside the authorized scope.

The Work Order is complete only when the acceptance criteria are satisfied and the required tests pass.

What the Work Order Accomplishes

Notice what the Work Order doesn’t contain. It doesn’t prescribe the exact C# implementation, dictate every method name, or attempt to micromanage the agent’s coding decisions. Those details are implementation concerns, and a capable coding agent should be able to resolve them using the repository’s established conventions.

Instead, the Work Order concentrates on the decisions that matter to the engineer: the business rules, architectural placement, component boundaries, inputs, outputs, acceptance criteria, and verification requirements.

This represents the intersection of business analysis and software architecture.

The business analyst identifies the rules governing assignment eligibility and the conditions under which an operation should be rejected. The architect determines that this behavior belongs in the domain layer, independent of presentation and persistence. The engineer turns those decisions into a bounded assignment with executable acceptance criteria.

The coding agent then performs the implementation work within those constraints.

Because the assignment is small and the expected behavior is explicit, the agent can use TDD effectively. It can establish a test for a completed task, verify the failure, implement the rule, and move to the next condition. As the test suite grows, it provides increasingly useful feedback about the component’s behavior.

The result is not merely code that appears to work. It is an independently testable component with documented responsibilities and a defined place in the application architecture.

The Work Order Is Also a Guardrail

One of the concerns frequently raised about autonomous coding agents is the possibility that they may make unexpected changes or take actions beyond their intended assignment.

There are legitimate reasons for that concern, particularly when agents have access to powerful development tools. However, we should distinguish between controlling the scope of an engineering task and controlling the technical environment in which the agent executes it.

The Work Order addresses the first problem. By decomposing a requirement into a narrow, testable assignment, we reduce the number of decisions the agent must make and make unauthorized changes easier to identify.

The development environment addresses the second problem. The agent operates in a controlled workspace with access to the source code and development tools it requires. It does not need production credentials, unrestricted deployment permissions, or access to unrelated systems.

These mechanisms complement one another. A Work Order prevents the agent from treating a small implementation task as authorization to redesign the application, while environment controls limit the consequences of mistakes or unexpected tool use.

Neither approach is particularly new. Functional decomposition, change control, environment separation, and least-privilege access are established engineering practices.

What has changed is that the implementation resource is now capable of acting autonomously. The same disciplines that made human development teams manageable provide a framework for directing and controlling AI coding agents.

From Work Order to Continuous Integration

Once the agent completes its assignment, the implementation enters the integration process established in the first article.

The agent’s completion report provides an account of the work performed, including the modified files and automated tests. The engineer can then examine the changes, verify that the implementation respects the architecture, and determine whether the Work Order’s acceptance criteria have been satisfied.

A successful local test run is useful evidence, but it isn’t the final authority. The committed implementation should be built and tested again by the CI pipeline, using the repository’s established quality gates.

If a test fails during integration, the change is rejected or returned for correction. The failure becomes a new input to the engineering process rather than a defect discovered after deployment.

The same approach extends to subsequent Work Orders. Once the domain validator is accepted, another assignment can implement the application service that uses it. That service can be verified independently through its own tests, while integration testing confirms that it cooperates correctly with the domain component.

Eventually, the feature will include API endpoints, persistence behavior, and a user interface. Each layer can be implemented and verified through bounded assignments, with the integration pipeline continually evaluating the growing system.

The objective is not to eliminate iteration or prevent the agent from proposing improvements. It is to make development incremental, observable, and controlled.

This is also where the global project instructions introduced in Article 2 become essential. The Work Order tells the agent what to accomplish, while the project methodology tells it how to perform the work. Together, they connect requirements, architecture, implementation, testing, and delivery into one coherent engineering process.

What Happens When the Agent Gets It Wrong?

No engineering methodology can guarantee that every implementation will be correct. Human developers misunderstand requirements, introduce defects, and make poor architectural decisions. AI coding agents will do the same, sometimes in different and less predictable ways.

Our process should therefore assume that mistakes will occur and provide mechanisms for detecting and correcting them.

If the agent misunderstands a business rule, the acceptance tests should identify the discrepancy where the expected behavior has been properly specified. If the agent introduces an architectural violation, the change should be detected through code review or automated architecture checks. If it breaks existing functionality, regression testing should reveal the problem before integration.

When a defect is discovered, the first question should not always be how to correct the implementation. We should also examine whether the Work Order, project instructions, or test coverage allowed the error to occur.

A poorly defined requirement may require refinement. An ambiguous architectural rule may need clarification. A missing regression test may indicate that an important behavior was never formally established.

The process should improve as these weaknesses are discovered.

This is another reason to maintain Work Orders and engineering instructions as version-controlled artifacts. They become part of the project’s accumulated knowledge, allowing subsequent assignments to benefit from the decisions and corrections made during earlier work.

Over time, the repository contains more than source code. It contains the requirements, architectural decisions, testing standards, and implementation history necessary to understand how the system was developed.

That knowledge remains useful even when the coding agent or inference model changes.

The Changing Role of the Software Engineer

The traditional distinction between architect, business analyst, and developer is increasingly difficult to maintain when an AI agent can perform much of the implementation work.

That does not mean every engineer must become an expert in every business domain or assume sole responsibility for enterprise architecture. Larger organizations will continue to require specialists, and complex systems will still benefit from teams with complementary skills.

What changes is the set of competencies required to direct implementation effectively.

A software engineer working with autonomous agents must be able to examine a business requirement and identify its functional components. They must understand enough about the application architecture to determine where those components belong and how they should interact. They must be able to define expected behavior, recognize missing requirements, establish verification criteria, and evaluate the implementation against those criteria.

Programming knowledge remains important because an engineer cannot effectively judge a technical implementation without understanding the technologies and architectural principles involved. But manually producing the implementation becomes a smaller portion of the engineer’s contribution as coding agents become more capable.

This is a significant shift in emphasis, although it is not an entirely new profession. Experienced software engineers have always combined analysis, design, implementation, and verification to varying degrees.

AI makes those broader engineering skills more visible because it reduces the amount of time spent on the mechanical act of writing code.

An engineer who can decompose a complex requirement into clear, independently verifiable assignments can direct an AI agent productively. An engineer who can only describe the desired end result may receive impressive output without having a reliable way to determine whether the result is correct, maintainable, or appropriate for the system.

The difference is not simply better prompting.

It is better engineering.

The Work Order as the Unit of Autonomous Development

For decades, software development teams have organized work around projects, features, stories, tasks, and defects. These remain useful planning concepts, but they don’t always identify the appropriate unit of autonomous implementation.

A feature may require changes across multiple architectural layers. A user story may describe a business outcome without specifying all the technical components necessary to implement it. A task may be so broad that an agent must make architectural and business decisions that properly belong to the engineer.

The Work Order provides a more precise implementation boundary.

It represents a coherent assignment with an established objective, defined scope, known architectural context, and verifiable completion conditions. It can be executed by a human developer or an AI agent, and its success can be evaluated independently of the implementation method.

This makes the Work Order a useful unit for organizing autonomous software engineering, particularly when multiple agents or models contribute to the same project.

It also supports the reuse and maintainability goals established in the second article. Instead of directing an agent to build an entire application as an isolated implementation, we can direct it to create or extend well-defined components within a shared architectural framework.

Over time, those components form a system rather than a collection of unrelated applications.

The objective is not to eliminate human judgment from software development. It is to concentrate human judgment where it has the greatest value: understanding the problem, establishing the architecture, defining correct behavior, and deciding whether the result is acceptable.

Bringing the Process Together

We’ve now completed the progression established at the beginning of this series.

We started by building the development foundation. Source control, testing tools, environment separation, and CI/CD established a controlled place for software to be produced, verified, and delivered.

We then examined the history of software engineering methodologies and used their accumulated lessons to establish an architecture and persistent set of project instructions. Those instructions define how software is to be engineered, regardless of which agent or inference provider performs the implementation.

Finally, we’ve introduced the Work Order as the mechanism for translating business requirements into bounded engineering assignments. Through functional decomposition, TDD, architectural constraints, and independent verification, an AI coding agent can contribute implementation work without becoming the authority responsible for the overall system design.

This approach is deliberately independent of any particular AI model or vendor. We can begin with local inference, use commercial services when appropriate, and change agents as their capabilities evolve. The repository, requirements, architecture, tests, and Work Orders remain the enduring assets of the engineering process.

The interesting thing about this progression is how familiar it should be to experienced software engineers. We establish the environment, design the system, decompose requirements, implement functionality, verify results, and promote approved changes through a controlled release process.

AI gives us a powerful new implementation resource, but it doesn’t invalidate the engineering lifecycle we’ve spent decades developing.

I began this series by reflecting on a contract at Bosch where every morning started with an integration report. The team knew what had been implemented, whether it had passed verification, and what needed attention before new work could proceed. We had a development process that made engineering discipline part of the daily routine rather than something we applied only when problems arose.

Today, I can give an AI coding agent a carefully defined assignment, have it implement functionality and run tests, and then review the results through the same kind of controlled integration process. The mechanics of implementation have changed dramatically, but the engineering responsibilities remain recognizable.

The software engineer’s role is evolving, and that evolution deserves serious attention. The future will require less emphasis on manually producing every line of code and more emphasis on the analytical and architectural judgment necessary to direct implementation.

Those are not new disciplines. They are the foundations of software engineering, applied to a new generation of development tools.

The best way to take advantage of AI in software development may be to become better software engineers.

Software Engineering in the Age of AI: Before the First Prompt · How We Got Here · The Work Order Is the New Unit of Software Development