Before Your AI Agent Writes Code, Ask These Three Questions

AI can write code faster than ever. But without clear boundaries, faster development can mean faster mistakes.

By Omar Mahmoud

AI coding agents are changing software development. A developer can describe a feature and receive working code, tests, and documentation within minutes.

But faster implementation raises an important question:

How do we know the agent built the right thing?

An AI agent might implement the requested feature while introducing new dependencies, unnecessary abstractions, or functionality nobody asked for.

The code compiles. Tests pass. Everything looks complete.

Yet the solution may still be wrong.

The problem isn't necessarily the AI. It's the lack of clear engineering boundaries.

Before an AI agent writes code, I believe every engineering team should require answers to three questions:

1. What are you building?
2. What are you NOT building?
3. Why are you building it this way?

These questions sound simple, but they address three critical engineering responsibilities: intent, scope, and accountability.

1. What Are You Building?

A feature request is not the same as a clear requirement.

Consider this instruction:

Implement employee attendance using geofencing.

An AI agent could interpret this as automatic check-in, background location monitoring, location history, or a complete attendance management system.

All are technically reasonable interpretations. But which one does the business actually need?

A better requirement would be:

Objective: Allow employees to confirm attendance when entering an approved workplace geofence.

Expected behavior:

• Detect entry into the configured geofence.
• Notify the employee.
• Request attendance confirmation.
• Submit the confirmation to the existing backend.
• Prevent duplicate submissions.

Now the agent has a defined outcome that can be tested.

The principle: Don't tell an AI agent only what feature to build. Define the behavior you expect and how success will be verified.

2. What Are You NOT Building?

This is arguably the most important question.

AI agents can be surprisingly proactive. Ask for a feature, and they may add supporting functionality to make the solution feel more complete.

Sometimes that's helpful. Often, it creates unnecessary complexity.

Returning to our attendance example, the agent might introduce continuous location tracking, historical movement records, Wi-Fi detection, or an administration dashboard.

None of these was requested.

Each addition means more code to maintain, more tests to write, and potentially more security and privacy risks.

That's why explicit non-goals should be part of every meaningful implementation request.

For our example:

Out of scope:

• Continuous employee location tracking.
• Historical movement storage.
• Automatic checkout.
• Wi-Fi-based attendance detection.
• New administration dashboards.

If additional functionality becomes necessary, the agent should explain why and request approval before proceeding.

Good engineering isn't just knowing what to build. It's knowing what not to build.

3. Why Are You Building It This Way?

Working code doesn't automatically mean good architecture.

An AI agent might create a new service when an existing one could be extended, introduce an unnecessary dependency, duplicate business logic, or modify an API contract.

These decisions can work technically while creating long-term maintenance problems.

Before implementation, the agent should explain:

• Approach: How will the solution fit the existing architecture?
• Alternatives: What other options were considered?
• Trade-offs: What are we gaining or sacrificing?
• Risks: What could break?
• Assumptions: What decisions are being made without explicit requirements?

For example, if an agent proposes adding a new geofencing library, it should explain why existing platform integrations aren't sufficient.

Importantly, an AI-generated explanation is not proof. Technical claims should be verified against the actual codebase, documentation, and tests.

The goal isn't to make AI justify every line of code. It's to make important engineering decisions visible before they become permanent.

Turn These Questions Into an Implementation Contract

I recommend introducing a lightweight Implementation Contract before an AI agent starts any significant development task.

It only needs five elements:

The workflow is straightforward:

Understand → Propose → Review → Implement → Verify

First, the agent examines the requirements and existing codebase. It then proposes an implementation and identifies exclusions, assumptions, and risks.

A developer or technical lead reviews the proposal before authorizing significant changes.

After implementation, the agent reports what was built, which tests actually ran, and whether anything deviated from the approved scope.

This isn't about adding bureaucracy. It's about preventing avoidable rework.

For small, low-risk changes, the process can be lightweight. Architectural, security, database, and API changes deserve greater scrutiny.

A Practical Prompt for Your AI Coding Agent

Here's a reusable instruction you can add to your agent's project configuration:

Before implementing a task, analyze the requirements and existing codebase.

Answer these three questions:

1. What are you building?

• Define the objective, expected behavior, and acceptance criteria.
• Identify affected files, modules, and APIs.

2. What are you NOT building?

• List explicit exclusions and deferred features.
• Avoid unnecessary dependencies, abstractions, and unrelated changes.

3. Why are you building it this way?

• Explain the technical approach and how it fits the existing architecture.
• Identify alternatives, trade-offs, assumptions, and risks.

Present a concise implementation plan and verification strategy.

Do not modify code until the proposal is approved.

If implementation requires expanding the approved scope, stop and request approval.

After implementation, report completed work, deviations, test results, and unresolved issues. Never claim a test passed unless it was executed.

This creates a practical boundary between human decisions and agent execution.

Measure Outcomes, Not Just Output

As AI agents become more capable, engineering teams will naturally measure productivity through development speed, completed tasks, and pull requests.

But speed alone tells us very little about engineering quality.

We should also measure whether implementations stay within scope, how much human rework they require, whether important decisions are traceable, and whether acceptance criteria are actually verified.

An agent that generates 5,000 lines of unnecessary code isn't necessarily more productive than one that solves the problem in 500.

Research such as the 2025 DORA report reinforces the importance of the organizational practices surrounding AI-assisted development.

The real productivity gain isn't writing more code. It's delivering the right solution with less rework and complexity.

From Prompt Engineering to Engineering Governance

The conversation around AI coding often focuses on writing better prompts.

But better prompts alone aren't enough.

As agents take on increasingly complex tasks, engineering leadership must define what those agents can decide independently, what requires approval, and how their work is verified.

Specification-driven approaches, including GitHub Spec Kit, reflect this shift toward defining intent before implementation.

My proposed three-question approach builds on the same principle while keeping engineering accountability at the center.

• What are you building? Establishes intent.
• What are you NOT building? Establishes boundaries.
• Why are you building it this way? Establishes accountability.

Conclusion: Approve the Intent, Not Just the Code

AI agents are making software development faster. But they don't automatically understand business priorities, architectural constraints, or the long-term cost of their decisions.

Those remain engineering responsibilities.

Before your next agent starts writing code, ask:

What are you building? What are you NOT building? And why?

Because the goal isn't to generate more code.

It's to solve the right problem without creating new problems nobody agreed to own.

The future of engineering leadership isn't about supervising every line of AI-generated code. It's about defining the boundaries within which AI is allowed to make decisions.