The Most Important AI Engineering Skill Is Saying No (AI-DLC, bolts, and autonomous agents)

AI can now propose an architecture, break requirements into tasks, write the implementation, generate tests, and prepare a deployment.

And we are increasingly building entire development methodologies around that capability.

AWS introduced the AI-Driven Development Lifecycle (AI-DLC), with concepts such as Units of Work, Bolts, Mob Elaboration, and Mob Construction. Frameworks such as specs.md bring similar ideas into tools like Claude Code.

The promise is compelling: shorter development cycles, persistent context, specialized agents, and fewer manual handoffs.

But after exploring these methodologies, I keep returning to a question that seems more important than how quickly AI can produce software:

Who is actually making the engineering decisions?

Not who approves the final pull request. Not who clicks "continue" when an agent requests permission.

Who decides whether an architectural proposal makes sense in the first place?

We are redesigning software development around AI

For years, the software industry has experimented with methodologies intended to improve how teams deliver software.

Waterfall emphasized sequential phases. Agile introduced iterative development and faster feedback. Scrum provided a framework for organizing complex work, while Kanban emphasized managing flow.

Now we have AI-native development methodologies.

AWS describes AI-DLC as a model in which AI creates plans, asks questions, proposes solutions, and executes work after human validation.

Its lifecycle has three major phases:

The methodology also introduces Bolts, short execution cycles generally measured in hours or days rather than weeks.

The ambition is to reorganize the development lifecycle around AI's ability to generate and execute work rapidly.

AI-Driven Development Life Cycle: Reimagining Software Engineering | AWS DevOps & Developer Productivity Blog

aws.amazon.com

This is a legitimate direction to explore.

But there is a subtle difference between accelerating software development and accelerating the production of software artifacts.

An agent can produce five architectural alternatives in minutes.

It cannot guarantee that any of them is appropriate for the organization, its operational constraints, or the business problem.

That distinction becomes increasingly important as agents gain autonomy.

A Bolt is not a substitute for engineering judgment

Consider a traditional development team implementing a reservation management feature.

A developer might spend time understanding the domain, inspecting existing services, discussing edge cases, and choosing an implementation strategy.

With an AI-driven workflow, an agent may perform much of that investigation and propose an implementation plan.

The team can then approve the plan and let the agent execute it.

This sounds efficient.

But consider what happens when the agent proposes an unnecessarily complicated solution.

For example:

Introduce a Kafka topic to propagate reservation state changes, a Redis cache for availability lookups, and a new microservice responsible for reservation lifecycle management.

It sounds like an architecture.

It even sounds like a reasonably sophisticated one.

But what if the system currently handles a few hundred reservations per day, uses a single PostgreSQL database, and has no demonstrated scaling problem?

The correct engineering decision might be:

No. We do not need any of that.

We might need one additional endpoint, a transaction, a database constraint, and two integration tests.

An AI agent can generate a technically coherent architecture that is nevertheless a poor engineering decision.

The danger is not only incorrect code.

It is unnecessary complexity delivered at extraordinary speed.

Human-in-the-loop is not the same as human-in-control

This distinction deserves more attention.

Many AI workflows include human checkpoints. The agent presents a plan, and a developer approves or rejects it.

That is useful, but insufficient.

Imagine the following interaction:

AI: I recommend introducing an event-driven architecture.

Developer: Approved.

AI: I will implement three services and their supporting infrastructure.

Developer: Approved.

AI: Implementation complete. All generated tests pass.

Developer: Approved.

There were three human checkpoints.

Yet we have no evidence that meaningful engineering judgment occurred at any of them.

Now consider a different interaction.

AI: I recommend introducing an event-driven architecture.

Developer: Why? What problem does it solve that our existing transactional design cannot?

AI: It could improve decoupling and asynchronous processing.

Developer: Show me three alternatives. Compare operational cost, consistency guarantees, failure recovery, and migration effort. Our team maintains this platform with limited infrastructure capacity.

AI: A transactional implementation appears sufficient under those constraints.

Developer: Proceed with that approach. Do not introduce new infrastructure.

The second interaction may produce less code.

It may also produce substantially better software.

The developer was not merely validating output.

The developer was actively shaping the solution.

Human-in-the-loop describes participation. Human-in-control describes authority.

They are not equivalent.

The four powers developers must retain

I believe every serious AI engineering workflow should explicitly preserve four human capabilities.

1. Reject a proposal

Developers must be able to reject a design without having to provide a replacement implementation immediately.

This matters because rejecting a bad abstraction is often easier than constructing a better one.

An AI-generated design may be logically consistent but violate established architectural boundaries, introduce unnecessary dependencies, or optimize for a problem that does not exist.

A useful rejection should identify the concern:

Reject this proposal. It introduces a new service without demonstrating a need for independent scaling, deployment, or domain ownership.

That is an engineering decision.

Not an obstacle to automation.

2. Establish constraints

AI agents need boundaries.

Not just coding conventions, but architectural and operational constraints.

For example:

architecture: new_microservices: prohibited database: postgresql messaging: existing_kafka_topics_only public_api_breaking_changes: prohibited reliability: retries_must_be_bounded: true idempotency_required_for_commands: true backward_compatibility: required delivery: unrelated_refactoring: prohibited integration_tests: required production_deployment: manual_approval 

This is an illustrative policy, not a native specs.md configuration file.

The point is that constraints should be explicit, versioned, and testable wherever possible.

A developer should not need to repeat the same architectural principles every time a new agent session begins.

3. Demand alternatives

One of the most dangerous properties of AI-generated solutions is how persuasive they can appear.

A complete design document with diagrams, tradeoff tables, and confident explanations can create the impression that the design space has already been explored.

It may not have been.

For consequential decisions, developers should ask:

• What is the simplest viable alternative?
• What can we implement using existing components?
• Which assumptions would make this design inappropriate?
• What are the operational and maintenance costs?
• What would make us reverse this decision six months from now?

These questions force the agent to explore the decision rather than simply defend its first proposal.

4. Stop execution

Autonomy should have boundaries.

An agent should stop when it encounters an unresolved architectural decision, a destructive operation, a security-sensitive change, or a conflict between requirements.

Consider a database migration.

The agent discovers that implementing a new feature requires modifying a heavily used table.

It should not automatically choose a destructive migration merely because doing so would complete the task.

It should surface the conflict.

EXECUTION PAUSED Reason: The proposed schema change may break existing consumers. Options: A. Backward-compatible additive migration B. Versioned API and staged migration C. Redesign the feature to avoid the change Decision required: Authorized engineering owner 

Stopping is not failure.

Stopping at the correct moment is a feature of a well-governed autonomous system.

But who should make these decisions?

Not every decision belongs to the same person.

Product owners and business stakeholders should determine which outcomes matter.

Domain experts should validate business rules.

Developers and technical leads should own engineering decisions, including architecture, implementation constraints, reliability, and maintainability.

Authorized operational owners should control production releases.

AI can help each group evaluate alternatives and execute approved work.

It should not silently inherit their authority.

This is also where AI-DLC should be evaluated against established engineering practices.

The Scrum Guide makes developers accountable for creating the Sprint Backlog, adapting their plan, and maintaining quality through the Definition of Done.

AI-DLC changes the mechanics of planning and implementation, but it should not erase that accountability.

There is a difference between delegating execution and delegating responsibility.

What happens when agents start making architecture decisions?

Imagine a team maintaining a mature backend platform.

The system has accumulated years of architectural decisions, operational lessons, domain-specific exceptions, and integration constraints.

An AI agent receives a request:

Implement real-time reporting for active alerts.

The agent examines the existing implementation and proposes a separate Redis-backed endpoint for active alerts, while historical alerts remain in PostgreSQL.

At first glance, the design may appear reasonable.

But the engineering team knows that this introduces two sources of truth for reporting.

Now every consumer needs to understand which endpoint to query, how to reconcile results, and what happens during synchronization failures.

The developer may instead insist on a unified reporting model with explicitly defined state transitions.

That decision requires understanding more than the immediate feature.

It requires understanding the system's history, consistency requirements, and future maintenance burden.

AI can help investigate those concerns.

But it cannot automatically determine which organizational tradeoffs are acceptable.

This is precisely where experienced engineering judgment becomes valuable.

The problem with measuring AI development through speed

AI-DLC introduces shorter execution cycles, and frameworks such as specs.md provide structured workflows for implementing them.

But how should we evaluate whether these methodologies work?

A common demonstration shows an agent producing a working application in a few hours or days.

That is impressive.

It is not sufficient evidence of long-term engineering effectiveness.

I would be more interested in what happens after six months.

Can another developer understand the architecture?

Can the team safely introduce a new feature?

Do the specifications still describe the implementation?

Can a developer challenge an earlier decision without rebuilding half the platform?

How much human effort is required to review and repair generated changes?

And when something fails in production, can the team diagnose it without depending on the original agent's conversation history?

Those questions are harder to demonstrate than a successful prototype.

But they are closer to what professional software engineering actually requires.

A useful evaluation should compare:

Counting completed Bolts is not enough.

Counting generated lines of code is even less useful.

The meaningful unit of progress is not AI activity. It is validated software value.

Are we accidentally reinventing Waterfall?

There is another uncomfortable possibility.

Spec-driven AI development often emphasizes generating requirements, architecture documents, implementation plans, tasks, and tests before or during execution.

These artifacts can improve traceability and preserve context.

But if teams begin treating AI-generated specifications as authoritative simply because they were approved, we risk recreating a familiar problem.

The process becomes:

1. Generate extensive requirements.
2. Approve the requirements.
3. Generate the architecture.
4. Approve the architecture.
5. Generate the implementation.
6. Discover that the original assumptions were wrong.

That is not automatically Agile because the implementation happened in short Bolts.

Agility requires the ability to revise assumptions and respond to new information.

A Bolt can be short while the overall process remains rigid.

Conversely, a team can use AI-generated specifications effectively if those specifications remain open to challenge, revision, and even deletion.

The value of a specification is not that it exists.

It is that it helps the team make and revisit decisions.

A better AI engineering workflow

I would rather see teams organize AI-assisted development around explicit decision boundaries.

Not every small change needs a complete architectural review.

But not every change should run on autopilot either.

Here is a practical model.

The important property is that autonomy is proportional to risk.

An agent should not require permission to rename a local variable.

It should not be allowed to invent a new distributed architecture without engineering approval.

Before implementing this feature: 1. Identify the affected domain boundaries. 2. Propose at least two viable solutions, including one that reuses existing infrastructure. 3. Compare: - Complexity - Reliability - Operational cost - Backward compatibility - Migration effort - Failure recovery 4. Explicitly identify assumptions and unknowns. 5. Recommend the simplest solution satisfying the documented requirements. 6. Do not implement until the architectural decision is approved. 7. If new information invalidates the approved design, stop and request a new decision. 

This is not a replacement for engineering expertise.

It is a way to make that expertise visible in the workflow.

The developer's role is changing, but not disappearing

I do not think the future of software engineering is developers manually writing every line of code.

Nor do I think it is developers approving whatever an autonomous agent produces.

The interesting future lies between those extremes.

Developers may spend less time producing routine implementations and more time defining constraints, exploring tradeoffs, validating behavior, and managing complexity.

But there is a danger in describing this transformation as developers becoming merely supervisors of AI agents.

Supervision without sufficient technical understanding is fragile.

If developers stop exercising implementation and architectural judgment, their ability to challenge increasingly sophisticated AI proposals may deteriorate.

We could end up with systems that are easier to generate than to understand.

And organizations that can produce software faster than they can responsibly maintain it.

That would not be an improvement in software engineering.

It would be an improvement in software production at the expense of engineering control.

The real test of AI-DLC

I am interested in AI-DLC, Bolts, and spec-driven development because they attempt to solve real problems: lost context, slow handoffs, inconsistent implementation, and repetitive work.

I also think they deserve more rigorous evaluation than demonstrations of rapid application generation.

The most convincing evidence would be a substantial production platform developed and maintained through many AI-driven iterations, with its architectural decisions, specification changes, failures, and operational history available for examination.

Not just the first successful release.

The tenth feature.

The unexpected migration.

The production incident.

The architectural decision that turned out to be wrong.

And the developer who recognized the mistake before an autonomous agent made it worse.

Final thought

AI can propose a solution in seconds.

It can generate thousands of lines of code, construct tests, document decisions, and execute an entire development workflow.

But engineering has never been only about producing implementations.

It is also about knowing when an implementation should not exist.

When an abstraction is unnecessary.

When a dependency introduces more risk than value.

When a requirement is incomplete.

When a system should remain simple.

And when execution must stop.

The most important AI engineering skill may not be writing better prompts.

It may be knowing when to say no.

Further reading

• AWS — AI-Driven Development Life Cycle: Reimagining Software Engineering
• AWS — Building with AI-DLC using Amazon Q Developer
• AWS Labs — AI-DLC Workflows
• specs.md — AI-native development workflows
• The Scrum Guide (2020)

What do you think? Are AI-native development methodologies giving engineers more control over software design, or gradually turning them into reviewers of decisions made by agents?