From Switching Tools to Rewriting the Way We Work: 10 Principles for Multi-Agent Software Development in Practice

Many developers working with AI coding assistants find themselves caught in a familiar pattern:

Type a prompt into the IDE, hold your breath for several tens of seconds, watch the code stream in, and habitually click accept; run it locally, only to see the console flare with red errors; copy the error trace back into the chat window, wait another several tens of seconds... and repeat.

You have indeed upgraded your tools, and your typing and generation speeds have increased. Yet stepping back to look at the overall delivery cycle—from requirement definition and system design to code authoring, repeated debugging, and production release—overall delivery rarely experiences the dramatic acceleration teams anticipated. Developers still end up exhausted, largely because many still position themselves squarely between the AI and the terminal, acting as real-time human routers, exception dispatchers, and confirmation clickers.

In September 2025, the Kiro team published an engineering feature authored by Clare Liguori titled Frontier Engineering, systematically outlining 10 exploratory principles for multi-agent software development practices.

The author’s core thesis is that software engineering practices are diverging. While some teams merely swapped coding tools within existing workflows, frontier practitioners are attempting to reconstruct how work gets done—moving from handcrafting every line of code to building the engineering infrastructure that enables agents to advance work autonomously in closed loops, pursuing substantial and even step-function gains in delivery speed.

If you are already familiar with AI-assisted coding but find that end-to-end delivery is still repeatedly bottlenecked by human intervention points, this article draws on Kiro's 10 principles to analyze the underlying operational mechanics, dependencies, and engineering boundaries of this workflow.

Reading Map for the 10 Principles

1. Architect, not typist → Role reset
2. Maximize agent time → Eliminating human bottlenecks
3. Build for agents → Refactoring codebases
4. Build a fast feedback loop → Rapid closed-loop feedback
5. Direction over execution → Direction- and spec-driven focus within role reset
6. Treat code as disposable → Disposable implementation, boundary tests as contract
7. Hold the line on human standards → Human standards and division of review labor
8. Trust the boundaries → Guardrail engineering
9. Use agents for everything → Lifecycle-wide collaboration
10. Constantly tune your setup → The continuous tuning flywheel

Role Reset: From Code Typist to Intent-Defining Architect

In frontier engineering practice, Kiro observed that for developers on the cutting edge, hand-written production code has fallen below 1%. Crucially, this is an observation made by the author within a specific exploratory context, rather than a universal target KPI for all teams to copy blindly. It does not mean engineering responsibilities have lightened; rather, the center of gravity in software engineering has shifted dramatically.

Figure: Kiro’s "Architect, not typist" principle illustration, depicting engineers shifting focus toward system direction and verification.

Historically, most engineering hours were consumed by hammering keyboards, wrestling with syntax minutiae, and debugging low-level API invocations. But when agents assume responsibility for concrete implementation, the primary costs of software development shift to two things: first, clearly defining what "Done" means (requirements boundaries, constraints, and acceptance criteria); second, verifying whether the output genuinely conforms to system intent.

Many developers struggle to get good results from agents because their very first step falls into the trap of "vague intent" (Note: The authentication comparison below is an illustrative example added by this article to explain intent expression, not an example from Kiro's original text):

• Ineffective intent: "Add user authentication to this API."
  Given this prompt, an agent typically invents technical choices on its own, arbitrarily chooses interceptor scopes, and invents default error response structures. Once its assumptions clash with actual business requirements, developers must expend extra effort tearing everything down and starting over.
  
• Well-specified intent: "Add role-based access control (RBAC) to the following endpoints: /admin/* restricted strictly to the Admin role; /api/v1/user/* accessible to both User and Admin roles. When a token expires, return an HTTP 401 status code with a TOKEN_EXPIRED error payload in accordance with the specification. Provide comprehensive test cases covering unauthorized access, token expiration, and forged signatures, ensuring all tests pass."

Here, the marginal cost of concrete code execution has plummeted, while the weight of defining system direction has magnified significantly.

If system architecture, API contracts, external dependency selections, or core trade-offs drift off course, the cost of undoing and correcting them remains high. Therefore, developers must focus their energies on the critical skeleton of the system. During the design phase, agents can also serve as assistants for exploring solutions: for instance, asking an agent to research multiple feasible technical approaches and write comparable prototypes, using prototype execution results and empirical evidence to support team decisions.

Once direction is established, work should transition into spec-driven development: co-authoring specifications and requirements alongside agents first to eliminate ambiguity prior to code generation. Throughout implementation, continuously evaluate whether the architecture can sustain real-world loads, whether established trade-offs warrant revisiting, and whether the product has reached a state ready for end users.

Figure: Kiro’s "Direction over execution" principle illustration, depicting establishing direction and specifications before scaling execution.

Eliminating Human Bottlenecks: Extending the "60-Second Wait Loop" into a "30-Minute Self-Healing Loop"

Achieving a breakthrough in development throughput requires breaking the tight coupling of "human-in-the-loop."

If you sit in front of your screen, staring at a blinking cursor after every prompt, waiting 60 seconds only to manually test for the agent and spoon-feed it error logs, you become the single largest concurrency bottleneck across the entire pipeline.

Frontier developers assign agents longer-horizon tasks equipped with explicit verification criteria. For example, a representative task prompt highlighted by Kiro in their principles states:

"Implement the feature, write the tests, run the tests and verify they pass, and ensure new code achieves 90% test coverage." (Note: This is Kiro's official task example, illustrating a closed loop of packaging implementation and verification together, rather than a hard KPI for all projects)

Throughout this process, it is entirely normal for an agent's initial code draft to contain defects. The key is: do not debug syntax errors or environment faults on its behalf. Let the agent run inside a controlled environment, capture error outputs, and self-correct autonomously until it converges on the expected outcome.

The difference between the two working modes:

• Inefficient human polling: Human sends prompt → waits ~60 seconds → agent generates code → human manually tests and inspects logs → human pastes errors back → waits again. Human attention spans and context-switching overhead dictate the upper ceiling of throughput.
• Long-horizon self-healing loop: Human first defines goals, verification scripts, and acceptance metrics; the agent then runs autonomously for 30 minutes or longer:
  1. Writes implementation and tests;
  2. Executes local verification;
  3. Captures failures when tests fail, repairs them, and loops back to the previous step;
  4. Submits a diff once all checks pass, awaiting asynchronous human review.

When an individual agent can operate autonomously in a closed loop for 30 minutes or longer, organizational engineering models level up accordingly: developers can concurrently orchestrate multiple agents assigned to independent tasks, or dispatch long tasks to run in the background, conducting asynchronous reviews (Async Review) at designated intervals.

However, Kiro placed special emphasis on attention management: this does not mean blindly maximizing the number of concurrent agents. The core discipline lies in running only tasks that possess unambiguous objectives and dependable verification loops, while upholding strict quality standards throughout; simultaneously, developers must establish explicit attention budgets and personal life boundaries, resisting the urge to repeatedly check progress over dinner or late into the night.

Figure: Kiro’s "Maximize agent time" principle illustration, depicting the shift from short polling to verified long-horizon tasks.

Refactoring Codebases: Preparing Environments as if Onboarding a "Perpetual Day-One Colleague"

When a human engineer joins a team, reading documentation once and configuring the local development environment is usually sufficient; relevant business context and implicit engineering consensus remain stored in their memory over the long haul.

Agents are fundamentally different: every brand-new session (Session) is like a new collaborator onboarding on their "first day," with zero prior familiarity with your business.

If a codebase relies entirely on word-of-mouth tacit knowledge, agents will repeatedly stall whenever context is missing. To enable agents to work efficiently, a repository must construct agent-facing infrastructure:

Figure: Kiro’s "Build for agents" principle illustration, highlighting support for agents through documentation, boundaries, testing, and tooling.

1. Repository-Level Foundations and Engineering Hygiene

• Comprehensive README and Architecture Documentation: Provide a clear overview of the system, technology stack choices, and directory layout, allowing new sessions to quickly build system-level understanding.
• Test Suites Describing Expected Behavior: Write tests that clearly reflect expected business behaviors, providing agents with immediate grounds for self-verification.
• Explicit Module Boundaries and Strong Typing: Decouple modules cleanly and use strong typing to minimize implicit dependencies; ambiguous typing significantly amplifies agent reasoning divergence.
• Fast Builds and High-Signal Error Messages: Ensure local builds and test feedback are sufficiently rapid, with compilers and test runners yielding specific, actionable diagnostics.
• Strategies for Massive Legacy Codebases: For legacy codebases burdened with substantial technical debt, do not expect overnight transformation. Instead, adopt an incremental module-by-module refactoring strategy, tightening the agent’s context and operational scope (Scope) for each task.

2. Explicit Engineering Rules and Tooling Integration

• Steering Files: Distill team coding conventions, directory standards, and common rules into dedicated steering files, providing enduring engineering agreements and coding standards.
• On-Demand Skills (Skills / Procedures): Encapsulate complex procedures (such as database migrations or API releases) into modular steps, loaded dynamically only when triggered by specific tasks to avoid crowding context with irrelevant information.
• Environment Scripts and CLI/MCP Tools: Supply scriptable local environment setups, and equip agents with CLI or MCP (Model Context Protocol) tools so they can autonomously query logs, pull schemas, or invoke supporting services.

3. Persisting Key Decisions and Contextual Constraints

Throughout task execution, require agents to record architectural decisions (e.g., via ADR) and supplement critical pathways with context and constraint comments. This does not mean dumping verbose model thought processes raw into the codebase; rather, it means persisting essential design decisions, background assumptions, and boundaries to provide continuous engineering memory for future sessions and human collaborators.

Rapid Closed-Loop Feedback: From Local Verification Tools to Property-Based Testing

An agent’s ability to locate and fix issues autonomously rests upon an agile, local, and automated feedback toolchain.

Figure: Kiro’s "Build a fast feedback loop" principle illustration, depicting enabling agents to rapidly observe runtime and test results.

If an agent must rely on a human to manually launch a browser to verify UI changes, or if API modifications can only be validated after deployment to a remote staging cluster, the self-healing loop breaks down, dragging humans right back into tedious real-time confirmation.

In frontier practices, fast feedback typically relies on the following local capabilities:

1. Static Analyzers (Linters) and Unit Tests: Swiftly surface syntax errors, code style violations, and basic logical deviations.
2. Browsers Capable of Visual Rendering and Inspection (Browser): Allow agents to independently load front-end interfaces and perform visual and structural DOM comparisons.
3. Lightweight Local Dependencies and Mocks (Local Mocks): Leverage local mocks or containerization to run full-stack end-to-end tests (E2E) on the local machine, decoupled from shared external environments.

Among various testing methodologies, property-based testing (Property-based Testing) serves as a particularly valuable complement, even though it is not a mandatory barrier to entry nor a direct replacement for foundational unit tests.

Traditional example-based unit tests typically assert fixed outputs for specific predetermined inputs. When an agent writes tests to cover its own code, it easily falls into the same cognitive biases as its implementation logic. Property-based testing, by contrast, requires asserting system invariants (Invariants) that must hold true across a wide spectrum of generated inputs (Note: The examples below are illustrative additions by this article to demonstrate the mechanism, not examples from Kiro's original text):

• Serialization invariant: "For any valid object satisfying schema constraints, deserializing after serializing must yield an object semantically equivalent to the original."
• Fund transfer invariant: "Excluding transaction fees, currency exchange conversions, and rounding errors, the net sum of balance changes across the two accounts must always equal zero."

By subjecting boundaries to randomly generated, diverse input samples, property-based tests help agents expose subtle edge-case anomalies lurking outside standard test suites, enabling them to iteratively adjust code against failing test cases.

Code Is Disposable, Boundary Tests Are the Contract

In conventional development workflows, tearing down code to rewrite it carries immense time costs and psychological resistance.

However, as the cost of code generation and rewriting drops substantially, when an existing implementation or architectural direction proves substandard, decisively discarding the flawed approach and regenerating the implementation becomes far more viable. This does not mean engineering costs evaporate to zero; it means teams no longer need to incur compounding technical debt just to salvage an awkward local implementation.

Figure: Kiro’s "Code is disposable" principle illustration; what is replaceable is the implementation, while rewrites still require the protection of boundary tests.

Here, two distinct layers must be separated:

• Disposable Layer: Concrete internal implementation logic and local private helper functions. When direction proves suboptimal, agents can draft them anew from scratch.
• Contract Layer: End-to-end integration tests, property-based tests, and load/performance baseline tests. These define external behaviors and system boundaries, serving as acceptance criteria that should be preserved across rewrites.

In such rewrites, what must be preserved as the foundation of refactoring are boundary tests (Boundary Tests):

• End-to-end tests (E2E Tests) covering expected external behaviors;
• Property-based tests (Property-based Tests) validating core rules and invariants;
• Load tests (Load Tests) verifying behavior under high concurrency and extreme load conditions.

These three classes of outer-ring tests constitute the system’s formal rewrite contract (Contract). Internal private functions or tightly coupled unit tests can be discarded alongside legacy code; as long as high-level boundary contracts remain clear and effective, agents can explore alternative implementation pathways within well-defined constraints, steadily converging on code that fulfills system expectations. Architectural design and API trade-offs remain expensive, high-leverage directional decisions that require careful judgment, but when facts demonstrate an initial direction was mistaken, they too must be revisited.

Guardrail Engineering: Establishing Least-Privilege Boundaries and Layered Defenses

Affording agents ample room for autonomous execution does not mean abandoning security controls.

Figure: Kiro’s "Trust the boundaries" principle illustration, depicting constraining autonomous execution through least privilege and guardrails.

Many teams stumble into one of two extremes when introducing agents: one is over-defensiveness, gating virtually every read-only or local command behind interactive confirmation popups, which rapidly induces severe "approval fatigue" and dulls human scrutiny; the other is a complete lack of guardrails, granting unrestricted read-write access or sensitive credentials and creating irreversible operational risks.

Kiro’s central security principle is: restrict file, tool, network, and credential access to the minimum necessary scope for the current task, and under those constraints, let the agent run unattended.

Implementation generally follows a "start narrow, expand incrementally" trajectory backed by layered defenses:

• Permissions and Tool Boundaries
  Anti-pattern: Granting full system or global tool read-write access by default.
  Guardrail: Begin with a restricted set of essential tools, expanding access incrementally based on task requirements, mounting capabilities only when strictly necessary.
• Action Approval Gates
  Anti-pattern: Prompting popups indiscriminately for trivial actions, or enforcing no approvals whatsoever.
  Guardrail: Allow read-only operations and sandboxed local tests to execute autonomously; gate approvals exclusively on high-risk actions carrying irreversible consequences, such as destructive data mutations or external production deployments.
• Credentials and Production Access
  Anti-pattern: Exposing high-privilege credentials directly within global environment variables.
  Guardrail: Production permissions and credentials are strictly withheld by default; rely on mock data or restricted sandbox credentials for daily work, granting specific elevated privileges only under explicit, deliberated authorization.
• Security and Code Defenses
  Anti-pattern: Relying solely on human visual skimming prior to merge.
  Guardrail: Integrate automated static analysis (SAST), automated reasoning or formal analysis tools, and secret scanners to construct a multi-layered security net.

The objective of this boundary architecture is to protect systems and data while allowing agents to make uninterrupted headway within safe perimeters, minimizing pipeline stalls caused by frequent interruptions.

Upholding Human Standards and the Division of Review Labor

Regardless of whether code is hand-typed by a human or generated by an agent, once merged into main and deployed to production, engineering accountability rests squarely on human engineers.

Figure: Kiro’s "Hold the line on human standards" principle illustration, emphasizing that generated code must meet the exact same quality bar.

As the volume of generated code swells, teams cannot afford to dilute quality standards in the pursuit of raw throughput. Yet confronted with high-frequency output, relying entirely on humans to perform initial mechanical line-by-line reviews becomes unsustainable. The review evolution path outlined by Kiro introduces explicit prerequisites and division of responsibilities:

1. Initial Manual Line-by-Line Calibration: When first introducing agents, engineers must diligently review generated code line by line to accurately identify model strengths, coding habits, and recurring failure modes, establishing foundational calibration benchmarks.
2. AI Reviewers Assuming Upstream Checks: Once model characteristics are well understood, dedicated AI Reviewers can be integrated locally before PR submission and inside CI pipelines. These handle automated audits for correctness, security vulnerabilities, maintainability, test rigor, and typical bug patterns, progressively absorbing preliminary review rounds.
3. Humans Focusing on Core Architecture and System Impact: Human engineers concentrate their attention on high-leverage strategic judgments:
   • Are overall architecture and modular responsibilities divided rationally?
   • What ripple effects will these changes trigger across upstream and downstream dependencies?
   • Are security perimeters and business authorization boundaries airtight?
   • Does the modification genuinely align with the long-term intent of the system?
4. Post-Deployment Verification and Regression Monitoring: An agent's closed loop does not terminate at PR submission. It can extend into deployment phases—involving agents in monitoring rollouts, verifying runtime behaviors in production environments, and assisting with triage and remediation workflows whenever metric regressions or anomalies surface.

Lifecycle-Wide Collaboration: Agents Are Far More than Code-Writing Tools

Another prevalent misconception in multi-agent practice is pigeonholing agents as mere "code typists." Kiro’s 9th principle explicitly notes: agent capabilities should permeate the entire software development and operations lifecycle.

Figure: Kiro’s "Use agents for everything" principle illustration, depicting the applicability of agents far beyond code generation.

Beyond authoring and refactoring business code, agents can be deployed across a wide spectrum of responsibilities:

• Architecture and Design Documentation: Drafting design proposals, API specifications, and technical evaluation reports.
• Operations and Incident Investigation: Aggregating error logs, tracing distributed call path anomalies, and aiding root-cause analysis during triage and incident response.
• Project and Operational Coordination: Generating status updates, Sprint summary reports, On-call handover logs, and maintaining routine engineering documentation.

Such workflows follow a standardized collaboration model: Provide Context → Define Desired Outcome → Agent Drafts Initial Version → Human Reviews and Revises before External Sharing.

Furthermore, across planning, development, testing, deployment, and daily operations, agents assigned to diverse duties should share engineering context, Steering rules, and underlying tooling (CLI/MCP) whenever possible, forging coherent collaborative synergy across the entire development lifecycle.

Building a Continuous Tuning Flywheel

Frontier engineering is not a one-and-done configuration; it is an evolutionary engineering discipline.

Figure: Kiro’s "Constantly tune your setup" principle illustration, depicting iterative improvements to rules and tools via root-cause analysis.

In daily development, whenever an agent hits a roadblock, strays off course, or triggers an unnecessary interruption, teams should neither simply blame model intelligence nor indiscriminately dismiss the issue as an environmental flaw. Frontier practice dictates: conduct rigorous root-cause analysis on recurring errors or interruptions to determine whether the breakdown stems from ambiguous business constraints, missing tooling, or over-restrictive permissions, and codify the remedy directly into the Agent Setup:

• Consistently confusing the usage of two similar tools? → Add explicit usage scenarios along with positive and negative examples in Steering files.
• Repeatedly blundering across a complex multi-step workflow? → Distill and solidify that workflow into a standalone Skill script.
• Lacking necessary environmental context data? → Write a lightweight CLI utility or expose an information retrieval channel via an MCP Server.
• Frequently stalling for manual approval during safe local operations? → Prudently recalibrate execution environment permissions based on root-cause findings.

This flywheel condenses into four steps:

1. Agent executes a long-horizon task;
2. System logs recurring errors, unnecessary interruptions, and other bottlenecks;
3. Humans perform root-cause analysis, categorizing issues into business constraints, procedural gaps, tooling deficits, or permission misconfigurations;
4. Update corresponding Steering files, Skills, CLI/MCP tools, or permission boundaries, then validate improvements in subsequent task iterations.

As root-cause analyses and tuning accumulate, the engineering environment becomes increasingly resilient in supporting agents. Crucially: underlying foundation models evolve continuously. When a new model is released, re-evaluate workarounds previously introduced to patch older model shortcomings; retire rules or prompts only after verifying they are no longer needed. Meanwhile, the clear contracts, automated test suites, controlled permission boundaries, and MCP toolchains anchored in your codebase remain reusable assets that empower newer models to perform with even greater stability.

Developer Self-Assessment Checklist

If you plan to begin overhauling your development workflow today, evaluate your practice across the following dimensions:

• Hand-Coding Ratio
  Warning sign: Most routine and boilerplate code is still written by hand line by line.
  Practice Direction: Focus on defining system intent, architectural contracts, and acceptance boundaries. Kiro observed that frontier developers can reduce handcrafted production code to under 1%.
• Interaction & Attention
  Warning sign: Trapped in constant human micromanagement and 60-second polling loops, vulnerable to perpetual interruptions.
  Practice Direction: Dispatch long-horizon tasks equipped with self-verifying closed loops, review asynchronously, and maintain strict attention budgets and non-working hour boundaries.
• Verification & Testing
  Warning sign: Relying on visual human inspections or unit tests tightly bound to local implementation details.
  Practice Direction: Rely on local automated verification loops; establish end-to-end tests and property-based tests as contracts protecting future refactorings.
• Codebase Context
  Warning sign: Relying on tribal knowledge and tacit understandings, with documentation and explicit standards largely absent.
  Practice Direction: Maintain comprehensive READMEs and architecture docs; codify Steering rules, on-demand Skills, and lightweight CLI/MCP tools.
• Mindset on Rewrites
  Warning sign: Reluctant to discard legacy code, held hostage by historical sunk costs.
  Practice Direction: Shielded by boundary tests, leverage substantially lower rewriting costs to decisively abandon misaligned local implementations.
• Permissions & Security
  Warning sign: Approval fatigue from incessant popups, or unguarded wide-open access.
  Practice Direction: Adhere to least privilege, expanding access incrementally; gate approvals strictly on irreversible actions, withholding production access by default.
• Error Attribution
  Warning sign: Emotionally venting at the model, or reflexively blaming all errors on the environment.
  Practice Direction: Perform root-cause analysis on recurring errors or unnecessary interruptions first, verifying whether they stem from rules, tools, or permission defects before codifying improvements into your setup.

It must be acknowledged objectively: this agent-oriented engineering paradigm remains in an early-adopter stage of practice. Kiro notes that optimal code review workflows are still being actively explored, toolchains and testing frameworks purpose-built for agents are not yet mature, and delegating tasks effectively, decomposing complex long-horizon objectives, and knowing when to intervene still depend heavily on individual engineer experience.

Transitioning from simple conversational autocompletion to building agent-driven engineering infrastructure is not an overnight flip of a switch. Kiro cautions that velocity will initially be slower, requiring several weeks of dedicated investment to refine the environment—clarifying module boundaries, filling gaps in tests and steering rules, and standing up robust automated verification environments.

If your team wishes to explore this approach starting today, the following phased sequence derived from these 10 principles provides a practical starting roadmap:

1. Solidify Codebase Foundations: Complete READMEs and architecture documentation for core modules, establish clear modular decoupling and strong static typing, and ensure local builds and test feedback are fast and reliable;
2. Establish the First Closed Verification Loop: Select an isolated module with sharp boundaries, write test scripts detailing expected behavior, and pilot delivering 30-minute-class tasks equipped with self-healing verification;
3. Progressively Codify Rules and Tooling: Maintain manual line-by-line code review initially to calibrate model performance, conduct root-cause analysis on recurring bottlenecks, and crystallize team Steering files, operational Skills, and necessary CLI/MCP interfaces;
4. Expand to Lifecycle-Wide Collaboration and Manage Attention: Incrementally extend collaboration into design drafting, incident investigations, and documentation maintenance, while enforcing strict attention budgets to safeguard system quality and personal working rhythms.