This is the first article in a three-part series, Engineering with AI Coding Agents: Practices, Evidence, and Lessons Learned. The guide grew out of my experience using coding agents in real development work and additional techniques I researched and collected over time. I extended those observations with further research into published studies, documented failures, and established software engineering practices.

Modern coding agents and their harnesses are improving rapidly, and many of the techniques discussed in this series are already being incorporated into advanced systems behind the scenes. As these tools become more capable, developers may not need to explicitly apply every technique described here. In many cases, a straightforward prompt is already sufficient to get a good result. However, when a regular prompt doesn't produce the desired outcome, or when a task requires more control, accuracy, or reliability, these techniques offer practical ways to improve the workflow. They are not intended as mandatory steps for every task, but as additional tools developers can use when the situation calls for them.

The three articles follow the development process from beginning to end. Part 1 focuses on understanding requirements and making design decisions, including software architecture and UI design, before code is written. Part 2 covers debugging, testing, and independent review. Part 3 covers maintaining project knowledge and the cross-cutting choices that affect the entire workflow, including context, permissions, and reasoning effort. Each technique includes a concrete action, a practical example, and an explanation of the reasoning or evidence supporting it, along with any important limitations or uncertainties.

IN THIS ARTICLE

1. Requirements and Problem Understanding · SDLC: Requirements

2. Architecture Design · SDLC: Design

3. UI and UX Design · SDLC: Design

4. Implementation and Change Boundaries · SDLC: Implementation

1. Requirements and Problem Understanding

Before an agent writes code, the developer needs confidence that it understands the request. These practices expose assumptions, remove leading diagnoses, and give the work a clear definition of done.

1.1. Ask the agent to explain what it understood

THE PROBLEM

With multi-part requests, an agent can build a coherent solution around an interpretation the developer never intended. That mismatch is often discovered only after the agent has touched several files.

THE TECHNIQUE

For any request with multiple requirements, let the agent explain its interpretation before it edits code. Ask what behavior should change, what must remain untouched, and which details it is assuming rather than deriving from the request. Read the response as a draft specification, not as a demonstration of understanding. Correct misunderstandings before moving on. This is especially useful when the request includes implied compatibility constraints or several interacting features. For a one-line change with no ambiguity, the extra exchange may cost more than it saves.

PRACTICAL EXAMPLE

PROMPT Before changing files, summarize the behavior I am asking for, the constraints you will preserve, any assumptions you are making, and any genuine ambiguities. Wait for my correction if a decision would change product behavior.

WHY IT WORKS

The developer can compare the agent’s summary with the request before a misunderstanding turns into changed files. The summary is not proof of correct understanding; it is a chance to correct the interpretation.

EVIDENCE AND LIMITATIONS

The reason for this step is not that repeating a request makes a model smarter. It exposes an interpretation that would otherwise remain hidden until the implementation is complete. The EMNLP 2026 study How Coding Agents Fail Their Users analyzed 20,574 real sessions and documented misunderstandings of developer intent among several forms of misalignment. It did not test this exact prompt, so the claim here is narrower: a visible misunderstanding can be corrected before it becomes code.

SOURCES How Coding Agents Fail Their Users (EMNLP 2026)

1.2. Describe symptoms without asserting a diagnosis

THE PROBLEM

A bug report that includes a confident diagnosis can narrow the investigation before the cause is known. The resulting patch may address the suggested mechanism rather than the observed failure.

THE TECHNIQUE

When reporting a bug, describe what you can actually observe before offering a theory about why it happens. If two concurrent requests sometimes return inconsistent session state, say that. Do not lead with “the session manager has a race condition” unless a race condition has already been established. You can provide your hypothesis later as one possibility to investigate. Neutral phrasing makes it easier to notice when the evidence points somewhere else, and it is particularly valuable for intermittent bugs that admit several reasonable causes.

PRACTICAL EXAMPLE

PROMPT Here is the observed behavior: [symptom, reproduction steps, expected result]. Investigate the cause using code and runtime evidence. Do not assume my current diagnosis is correct; if you consider it, treat it as an unverified hypothesis.

WHY IT WORKS

Describing observable behavior keeps the evidence separate from the developer’s explanation. It also avoids placing a preferred answer in the question before the investigation begins.

EVIDENCE AND LIMITATIONS

This technique has relevant experimental support from the UK AI Security Institute's Ask, Don't Tell research, which examined agreement bias in language models. Models were more likely to agree with an assertion, especially a confidently stated one, than with a neutrally worded question. That is evidence about framing and sycophancy, not direct proof of better bug fixing. The practical risk it addresses is allowing a suggested answer to shape the investigation before the underlying facts are checked.

SOURCES Ask, Don’t Tell: Reducing Sycophancy in Large Language Models

1.3. Define completion criteria before implementation

THE PROBLEM

When you give a coding agent an open-ended task such as "improve the caching system" or "refactor this module," it may not know when to stop. Even after completing the original request, the agent might continue cleaning up code, introducing unnecessary optimizations, or modifying unrelated components. These additional changes can increase development time and introduce new bugs without providing meaningful benefits. The problem is that the agent has been given an objective without clear conditions for determining whether the work is actually finished.

THE TECHNIQUE

Before implementation begins, define what a successful outcome should look like. Specify the expected behavior, what must remain unchanged, which tests or measurements should demonstrate success, and what falls outside the task's scope. Just as importantly, tell the agent to stop making changes once those conditions are satisfied. If the requested behavior already exists, the agent should be allowed to report that no changes are necessary. If an important requirement cannot be verified, it should report the uncertainty rather than continue making speculative changes.

PRACTICAL EXAMPLE

PROMPT Treat the task as complete when [specific behavior], [acceptance tests], and [scope constraints] are satisfied. If an essential criterion cannot be checked, report the blocker. After completion, suggest optional improvements without implementing them.

For example, when optimizing a caching system, you could require a measurable reduction in response time while preserving existing API behavior and passing regression tests. Once these conditions are met, the agent should report the results rather than continue modifying unrelated code.

WHY IT WORKS

Clear completion criteria provide an explicit standard for evaluating whether the task has been completed. Instead of relying on the agent's subjective judgment about whether the implementation could be improved further, both the developer and the agent can compare the result against specific, observable conditions. This also makes it easier to distinguish required changes from optional improvements and to identify when no further modifications are necessary. The approach follows established software engineering practices for defining requirements and acceptance criteria. However, it depends on those criteria accurately representing the intended outcome. Poorly defined criteria can still lead to an implementation that technically satisfies the instructions while missing the developer's actual expectations.

EVIDENCE AND LIMITATIONS

In the 2026 study Coding Agents Don't Know When to Act, researchers evaluated five models across four agent harnesses using FixedBench, a benchmark containing 200 human-verified tasks where no code modifications were necessary. Despite this, coding agents proposed undesirable changes in 35% to 65% of cases, depending on the configuration. The researchers also found that explicitly asking agents to reproduce problems before making changes could reduce unnecessary modifications, although this sometimes caused agents to stop prematurely when an issue was only partially resolved.

These findings demonstrate that coding agents can struggle to recognize situations where modifying code is unnecessary. They provide a relevant empirical reason to consider explicit stopping conditions, but the study did not directly test whether defining completion criteria before implementation improves task success or prevents unnecessary changes. Therefore, this technique is supported by established requirements engineering principles and indirect empirical evidence rather than direct experimental validation.

SOURCE Coding Agents Don't Know When to Act (2026)

2. Architecture Design

Architecture is the stage where a small misunderstanding can shape an entire system. Rather than asking an agent for the “best pattern,” use requirements, the real codebase, and specific trade-offs to review its proposals.

2.1. Define measurable quality goals before asking for an architecture

THE PROBLEM

An agent can propose a familiar architecture that looks convincing without showing whether it meets the system’s real needs. A design optimized for speed of implementation might be unsuitable when reliability, privacy, or easy deployment matter more.

THE TECHNIQUE

Before requesting a design, give the agent the key requirements and turn important quality goals into concrete scenarios. For example, specify how many concurrent users the system should handle, what happens when a dependency fails, and which data must stay private. Ask the agent to evaluate architectural choices against those scenarios instead of simply naming a popular pattern. Review the scenarios yourself before accepting the design.

PRACTICAL EXAMPLE

PROMPT Before proposing an architecture, list the functional requirements, constraints, and quality goals. Turn the most important quality goals into concrete scenarios with measurable outcomes. Then show how the proposed design would address each scenario and where uncertainty remains.

WHY IT WORKS

Specific scenarios give the agent a defined target for design decisions. A statement such as “the system must be scalable” is hard to judge; a statement about expected traffic, latency, and failure recovery can be checked against a design.

EVIDENCE AND LIMITATIONS

The Software Engineering Institute’s Attribute-Driven Design method begins with functional requirements, quality attributes, and constraints. A 2026 IEEE Transactions on Software Engineering study of LLM-assisted Attribute-Driven Design found promising results on architectural drivers but also emphasized the need for human guidance on important decisions. That study supports the design approach, not this exact prompt.

SOURCES SEI Attribute-Driven Design | Better Together: LLM-Assisted Architecture Design (IEEE TSE 2026)

2.2. Make the agent trace the existing architecture before proposing a new one

THE PROBLEM

An agent may suggest a reasonable-looking service, module, or dependency without noticing that the project already has a related component or a rule about where that responsibility belongs. The resulting design can duplicate work or create incompatible boundaries.

THE TECHNIQUE

Before discussing a redesign, ask the agent for a short map of the relevant code paths, components, and dependencies. Have it identify which parts of the map were confirmed by code and which remain uncertain. Then ask for changes that reuse current boundaries unless there is a clear reason to alter them. Review any proposed new service or abstraction against the actual repository.

PRACTICAL EXAMPLE

PROMPT Read the current repository before designing this change. Map the relevant modules, public interfaces, dependencies, and data flow, with source references. Mark any part you could not verify. Only then propose the smallest architectural changes required by the feature.

WHY IT WORKS

The agent’s proposal can be compared with something tangible instead of with its own general knowledge of architectural patterns. Source references also make it easier to catch missing dependencies before development begins.

EVIDENCE AND LIMITATIONS

An ICSA 2025 empirical study of architecture-view generation over 340 repositories found that LLM-generated views could be syntactically valid while still missing important details or using inconsistent levels of detail. This supports checking generated architecture maps against source code; it does not prove that the proposed two-step prompt improves task success.

SOURCES LLM-Based Automated Architecture View Generation (ICSA 2025)

2.3. Ask for architectural trade-offs tied to the requirements

THE PROBLEM

When asked for the “best architecture,” an agent may offer a polished recommendation without showing what the design sacrifices. The most consequential trade-offs can remain hidden, especially when several approaches seem reasonable.

THE TECHNIQUE

For an important decision, request two credible options rather than a long catalog. Ask the agent to compare them against the same requirements, operating constraints, and risks. Require a recommendation that explains why one option fits the present project better, what conditions would favor the other option, and which claims need validation through a prototype or measurement.

PRACTICAL EXAMPLE

PROMPT Compare two realistic architecture options for this requirement. Evaluate both against the same constraints: performance, failure behavior, maintenance cost, deployment complexity, and compatibility with our current system. Recommend one, explain the trade-offs, and identify any claims that need a prototype or measurement.

WHY IT WORKS

A comparison grounded in shared criteria is easier to challenge than an unqualified recommendation. Requiring conditions under which the rejected choice would be better also makes it harder to present a preference as universally correct.

EVIDENCE AND LIMITATIONS

A 2026 ACM TOSEM study evaluated LLM-generated design rationales for architectural decisions and found that they could surface useful arguments but also produced uncertain or misleading ones. Architecture trade-off analysis is an established engineering practice, but the study does not validate this exact prompt or guarantee that the agent will identify every relevant trade-off.

SOURCES Using LLMs in Generating Design Rationale for Software Architecture Decisions (ACM TOSEM 2026)

2.4. Record hard-to-reverse architecture choices in a short ADR

THE PROBLEM

A project may implement a major architectural choice without recording why it was made. Later, the agent or developer may repeat the same debate or change a design without understanding the constraint it was meant to satisfy.

THE TECHNIQUE

After a consequential decision is approved, ask the agent to draft an Architecture Decision Record (ADR) with the problem, considered options, chosen approach, trade-offs, date, and status. Keep the document short and check it against the actual decision. If the decision changes later, add a superseding record rather than silently rewriting the history.

PRACTICAL EXAMPLE

PROMPT Draft an ADR for the architecture choice we just approved. Include the context, requirements, options considered, decision, expected trade-offs, known risks, and status. Do not invent rejected options or claim that untested properties have been verified.

WHY IT WORKS

The decision and its reasons remain available after the conversation ends. A future developer or agent can see which assumptions supported the choice and what would justify revisiting it.

EVIDENCE AND LIMITATIONS

Microsoft's Azure Well-Architected guidance recommends documenting consequential architectural decisions, including rejected alternatives, the rationale, trade-offs, and later superseding decisions. This established engineering guidance demonstrates that an ADR prompt improves coding-agent performance. However, it applies most clearly to significant, hard-to-reverse choices, not routine edits.

SOURCE Microsoft: Maintain an Architecture Decision Record

3. UI and UX Design

A usable interface needs more than a polished mockup. Before writing UI code, an agent should know the product's shared components, the user's goal, what happens when things go wrong, and the requirements for smaller screens and accessible interaction. These techniques turn those needs into decisions that can be checked before and after implementation.

3.1. Follow the project's design system before creating new UI components

THE PROBLEM

A coding agent may generate a polished screen using new buttons, arbitrary spacing, and custom controls, even though the application already has a component library and design rules. The screen can look acceptable by itself while feeling inconsistent with the product, duplicating existing code, and creating avoidable maintenance or accessibility work.

THE TECHNIQUE

Before asking for a UI implementation, have the agent inspect the existing design system, design tokens, component library, and comparable screens. Ask it to name which components and patterns it will reuse, and to explain any proposed exception. If the project has no formal design system, start by identifying its existing conventions and agree on a small, consistent set of tokens and component choices. Include interactive behavior, not just visual styling, and require the agent to check actual component usage rather than assuming that importing a library guarantees accessibility.

PRACTICAL EXAMPLE

PROMPT Before implementing this interface, inspect our design system, existing screens, component library, and styling conventions. Reuse existing components, tokens, typography, spacing, and interaction patterns whenever appropriate. Identify any required new components or deviations and explain why the existing options are insufficient. Outline the approach before editing files.

WHY IT WORKS

A design system narrows the number of independent choices needed for each new screen. Shared colors, spacing, components, and interaction patterns make consistency easier to maintain and give reviewers a concrete reference for departures from project conventions. Reuse can reduce duplication, but a well-designed component can still be used incorrectly.

EVIDENCE AND LIMITATIONS

The U.S. Web Design System documents shared design tokens for consistent visual decisions and provides a related component library. This establishes a concrete design-system reference for reuse, but it does not test whether directing a coding agent to inspect that system improves outcomes. Existing components can still be misused and require task-specific accessibility and behavior checks.

SOURCE U.S. Web Design System: Design tokens

3.2. Give the agent visual references and reusable components before UI design

THE PROBLEM

A written request such as “make the dashboard modern and clean” leaves the agent free to invent spacing, layout, typography, and controls. Even models that can read images often miss visual elements or place them incorrectly when reproducing an interface.

THE TECHNIQUE

Give the agent a screenshot, wireframe, or representative existing screen that expresses the intended visual direction. Ask it to identify visual hierarchy, page regions, typography, and spacing before building anything. Treat the reference as guidance rather than a pixel-perfect specification, and clarify which parts should follow existing product conventions even when the reference differs. Use real content examples when possible, so the design is not evaluated only with ideal placeholder data.

PRACTICAL EXAMPLE

PROMPT Use the attached reference and our existing components as design inputs. First identify the page regions, visual hierarchy, spacing patterns, typography, and reusable controls. Propose a UI design that follows those constraints and flag anything that the reference does not specify.

WHY IT WORKS

A concrete reference makes the requested visual direction easier to discuss than adjectives such as 'clean' or 'modern.' It helps identify what should be reproduced and what still needs a design decision. This is distinct from following the design system: a reference communicates the particular screen's goals, while the design system supplies shared components and rules.

EVIDENCE AND LIMITATIONS

The Design2Code benchmark evaluated models reconstructing webpages from screenshots and documented persistent errors in reproducing visual details and layouts. It supports the need for explicit references and verification, not a claim that adding a screenshot always improves an agent's output. Human comparison against the actual reference remains necessary.

SOURCES Design2Code (NAACL 2025)

3.3. Map the primary user journey before designing screens

THE PROBLEM

An agent can produce a collection of attractive screens that do not form a convenient path through the product. Important entry points, navigation decisions, and the outcome of a task may be missing, even though each screen looks reasonable in isolation.

THE TECHNIQUE

Before approving the layout, describe the user's goal and ask the agent to map the steps from entry to completion. Check the actions available at each step and the language used for labels, instructions, and feedback. Require the main action to be clear, familiar interaction patterns where practical, and no unnecessary detours. For a complicated journey, review the flow with someone who understands the intended users before committing to components.

PRACTICAL EXAMPLE

PROMPT Before designing the screens, map the main user journey from entry to completion. For each step, list the normal, loading, empty, error, and recovery states that matter. Then propose the page structure and user actions for those states, using our existing UI conventions.

WHY IT WORKS

A journey map gives the screen design a concrete task to support. It reveals missing transitions and makes the designer explain how users move forward, recover, or leave. A good-looking mockup does not answer those questions by itself.

EVIDENCE AND LIMITATIONS

Nielsen Norman Group defines a journey map as a representation of the process a person follows to accomplish a goal, making the user's actions and transitions explicit. This directly supports mapping a journey before choosing screens. It is UX practice guidance, not controlled evidence that this coding-agent prompt improves design quality; the proposed journey must still be validated against real user needs.

SOURCE Nielsen Norman Group: Journey Mapping 101

3.4. Define the UI states and realistic content before implementation

THE PROBLEM

A UI may look complete when all requests succeed and sample data is tidy, yet fail during loading, after a network error, when a list is empty, or when a label is unusually long. Destructive actions and recovery paths may be overlooked because the design only shows the happy path.

THE TECHNIQUE

Ask the agent to identify the meaningful states for each part of the journey before writing components. Cover loading, empty, error, success, disabled, and recovery behavior where applicable, and test representative difficult content such as long names, missing optional fields, or large values. For actions that are difficult to undo, define suitable confirmation or recovery behavior. Do not require every state for every component; select those that can actually occur.

PRACTICAL EXAMPLE

PROMPT Before implementation, create a state checklist for the proposed UI. Include normal operation and the loading, empty, error, success, disabled, and recovery states that actually apply. Use realistic edge-case content, and describe how users recover from failed or destructive actions. Identify the components and tests needed for those states.

WHY IT WORKS

Designing states early makes expected behavior explicit before component interfaces and layouts are fixed. Realistic content exposes assumptions that perfect sample data hides, while defined recovery paths prevent the interface from leaving users without an understandable next step. This is an engineering and UX rationale, not a measured agent-specific improvement.

EVIDENCE AND LIMITATIONS

Nielsen Norman Group's heuristics address status visibility, preventing errors, and helping users recover from mistakes. WCAG 2.2 success criterion 3.3.4 more specifically calls for reversal, error checking, or confirmation in certain consequential submissions involving legal commitments, financial transactions, or user data. These sources support relevant UI states and recovery behavior, not a claim that the exact agent prompt has been experimentally validated. The WCAG criterion is not a blanket confirmation requirement for every action.

SOURCES Nielsen Norman Group: 10 usability heuristics | W3C WCAG 2.2: Error Prevention (Legal, Financial, Data)

3.5. Specify responsive behavior for real layouts and content

THE PROBLEM

A request to 'make the page responsive' may result in a layout that technically shrinks but leaves unusable tables, hidden actions, overlapping dialogs, or navigation that breaks on narrow screens. Text expansion or different locale formats can reveal further problems that are invisible in the original mockup.

THE TECHNIQUE

Instead of requesting responsiveness as a general quality, ask the agent to describe how major regions and controls change at narrow, medium, and wide widths. Include navigation, tables, dialogs, primary actions, and text wrapping. Where localization matters, ask the agent to consider longer translations, date and number formats, and right-to-left layouts. Then verify the implemented interface at the relevant viewports and zoom levels rather than relying on a design description alone.

PRACTICAL EXAMPLE

PROMPT Define the behavior of navigation, content columns, tables, dialogs, and primary actions at narrow, medium, and wide viewports. Avoid inaccessible off-screen actions and unintended two-dimensional scrolling. Test with long or translated text where localization is relevant, and report any known layout trade-offs.

WHY IT WORKS

Responsive behavior becomes easier to assess when the specification identifies what must stay usable at different sizes. This also catches layout failures caused by content that does not fit the assumptions of a single design mockup.

EVIDENCE AND LIMITATIONS

WCAG 2.2 success criterion 1.4.10 addresses content reflow without loss of information or functionality, with limited exceptions. W3C internationalization guidance identifies directionality and locale-specific formatting concerns. These are direct standards for the desired UI behavior, not experimental evidence about agent prompting.

SOURCES W3C WCAG: Reflow|W3C: Internationalization quick tips

3.6. Include accessibility requirements in the UI design brief

THE PROBLEM

If accessibility is checked only after implementation, choices about semantic controls, keyboard navigation, visible focus, labels, and error feedback may be costly to revise. A design can appear visually complete while preventing some users from completing the task.

THE TECHNIQUE

Include the relevant accessibility standard and concrete requirements before implementation. Ask for semantic controls, keyboard-operable interactions, visible focus, accessible names, meaningful labels, and appropriate feedback. Review the design choices against those requirements, then test the actual UI with keyboard use and relevant automated or manual checks. Avoid treating the agent's claim of compliance as evidence of compliance.

PRACTICAL EXAMPLE

PROMPT Design this UI for desktop and mobile while considering WCAG 2.2 AA criteria relevant to the feature. Include keyboard order, visible focus, labels, error messaging, contrast, and target sizes. Explain which requirements the design addresses and which will still need testing.

WHY IT WORKS

Accessibility depends partly on choices made during component and interaction design. Giving those choices a testable standard makes them reviewable before the design hardens, but the implementation must still be tested with actual interaction and, where appropriate, assistive technology.

EVIDENCE AND LIMITATIONS

WCAG 2.2 contains testable success criteria covering keyboard access, visible focus, error identification, contrast, and more. These standards support the requirements in the design brief. They do not establish that instructing a coding agent to consider WCAG produces a conformant UI, and the exact prompt has not been directly validated in a controlled agent study.

SOURCES W3C WCAG 2.2

3.7. Use human judgment to choose between AI-generated UI proposals

THE PROBLEM

An agent can confidently rate its own mockup as usable or polished even when users would disagree. A numerical score from the same model that generated the design may look objective without being reliable.

THE TECHNIQUE

When visual direction matters, ask the agent for a small number of meaningfully different options and their trade-offs. Then review them in two passes: one for consistency with the design system and visual hierarchy, and another for whether a representative user can complete the intended journey. Use a product owner, designer, or representative user to make consequential decisions rather than treating the generating model's score as final.

PRACTICAL EXAMPLE

PROMPT Propose two distinct UI directions for this workflow and explain the difference in hierarchy, navigation, information density, and accessibility trade-offs. Do not declare either one the winner. Present the decisions that need human review before implementation.

WHY IT WORKS

Visual quality and usability answer different questions. A design can match a visual system yet leave the primary task confusing, while a usable flow can still be visually inconsistent. Independent review adds information that the model's own aesthetic explanation cannot establish.

EVIDENCE AND LIMITATIONS

A 2025 study by Sun and Baber reported limited agreement between AI-generated and human usability ratings in its evaluated setting. The sample and task were narrow, so this supports caution rather than a universal claim that all AI UI evaluations are inaccurate. Independent task-focused review remains appropriate, but it is not a guarantee of good design.

SOURCES How Well Can Generative AI Design and Evaluate User Interfaces? (2025)

4. Implementation and Change Boundaries

Once a design is agreed upon, the next goal is to change only what the task requires. Concrete boundaries and checkpoints help keep a local change from turning into an unnecessary project-wide rewrite.

4.1. Prefer explicit constraints over vague quality directives

THE PROBLEM

General requests to produce “clean” or “high-quality” code leave room for unrelated refactors and changes outside the developer’s intent. It can also be hard to tell whether the agent followed such vague advice.

THE TECHNIQUE

Replace broad instructions such as “write excellent, maintainable code” with constraints that define the boundaries of the authorized change. Tell the agent not to refactor unrelated modules, not to alter public behavior without a requirement, and not to introduce a new dependency without justification. These instructions give you a concrete way to check whether the agent stayed within scope. They are especially valuable when a small requested change might tempt an agent to perform a wider cleanup.

PRACTICAL EXAMPLE

PROMPT Implement only the requested behavior. Do not refactor unrelated modules or change public interfaces. If a wider change appears necessary, explain why and ask before proceeding.

WHY IT WORKS

A specific restriction identifies an observable boundary: a file was or was not changed, a public interface was or was not modified. Such boundaries are easier to enforce and review than subjective quality slogans.

EVIDENCE AND LIMITATIONS

The 2026 arXiv preprint Guardrails Beat Guidance reports more than 5,000 coding-agent runs and finds that negative constraints were the only individually beneficial rule type in its tested setting, while positive directives were sometimes harmful. This is experimental but not independently established as a universal rule; the result depends on the benchmark, model, and harness. It favors testing explicit boundaries, not assuming that every prohibition helps.

SOURCES Guardrails Beat Guidance (2026)

4.2. Introduce checkpoints for consequential work

THE PROBLEM

A wrong design choice can spread across many files before the developer sees the result of a large agent-driven refactor. The cost of correction grows as more work depends on that choice.

THE TECHNIQUE

For a large refactor or architectural change, stop after the first independently testable piece rather than allowing the agent to modify many files based on an unchecked plan. A useful checkpoint might be a validated interface, a passing representative migration, or a working end-to-end path. Review the result and assumptions before letting the agent apply the same approach more broadly. Small, low-risk tasks may not justify any intermediate pause.

PRACTICAL EXAMPLE

PROMPT Implement the smallest meaningful slice first. Run its relevant checks, then report the changed files, assumptions, and evidence that the approach works. Do not expand the change across the rest of the codebase until that checkpoint is accepted.

WHY IT WORKS

An intermediate, testable slice limits the amount of work built on an unverified decision. Checkpoints are most useful when the next step is expensive to reverse, not as mandatory interruptions for every small edit.

EVIDENCE AND LIMITATIONS

Microsoft Research's AgentLens study examined passing coding-agent trajectories and identified a subset with repeated regressions, blind retries, or missing verification, despite successful final outcomes. This is a reason to inspect the process before scaling a consequential change, but the study did not test human checkpoints or identify an optimal frequency. Checkpoints remain an engineering safeguard to use when the cost of an unverified decision is high.

SOURCE AgentLens: The Lucky Pass Problem (Microsoft Research, 2026)

Before the next step

The first part of effective agentic development is making the intended work clear. Strong designs begin with explicit requirements, real architectural constraints, and UI decisions a human can review. None of this requires the agent to produce more text than necessary; the aim is to make important assumptions visible before they become implementation decisions. Part 2 turns to debugging, testing, and independent code review. Part 3 follows with persistent documentation, security boundaries, and reasoning-effort choices, so readers who need those topics can move directly to them.