In August 2025, I wrote From Vibe Mode to Spec Mode: Why I'm All In on Kiro. What appealed to me was the structure: requirements, design, tasks, and standards instead of another conversation I hoped would produce the right software.
Kiro's frontier engineering principles bring me back to that argument. They emphasize clear intent, prepared codebases, useful feedback, and boundaries that hold without constant supervision, with the setup improving as teams learn.
There is a lot here I agree with. There is also a practical question I would put in front of a platform team:
When a developer improves an agent workflow, how does that improvement become something the next team can safely inherit?
Sharing a configuration file starts the process. It doesn't establish which tasks the workflow supports, who maintains it, what evidence justifies its permissions, or how to withdraw a change that makes it worse.
My proposal is to treat a shared agent workflow as a software release: a versioned combination of instructions, context sources, tools, permissions, and verification, with an owner accountable for how it behaves.
A working setup is not yet a supported capability
Kiro is not arguing that teams should simply buy a tool and hope. Its companion guide for teams explicitly calls for shared context, explicit intent, testing, and organization-wide guidance. The practitioner principles also describe preparing repositories and continuously improving the setup.
I want to make the maintenance obligation concrete.
In Spec, Standards, Specialists, I described my own working loop: establish the behavior, supply the engineering standards, and assign focused work to agents operating inside those constraints. That is a useful unit of practice. It is not, by itself, a support model for other teams.
Consider what another engineer needs to use it. They need the right instructions, but also the right commands, access, examples, checks, and expectations about when to stop. They need to know which parts are shared requirements and which are local choices. When something breaks, they need somewhere to report it other than the original author's direct messages.
That is the next step after Your Platform Has a New User: The Agent. Designing a platform an agent can understand is one obligation. Maintaining the supported workflows that act through it is another.
The standard I would use is straightforward: can another engineer run the supported task, understand the evidence, and handle an expected failure without the workflow's author interpreting the result?
That doesn't mean eliminating help. It means making help a supported part of the product rather than a dependency on one person.
Turn the principles into a release contract
I would not turn Kiro's ten principles into ten new policies. I would use them to define what a shared workflow must make explicit.
| Kiro principles, grouped | What I would require in a shared workflow |
|---|---|
| Architect rather than typist; direction before execution | A task contract defining the intended outcome, constraints, non-goals, and evidence of completion. |
| Build for agents; continuously tune the setup | Versioned instructions, authoritative context sources, reproducible setup, and an owner for changes. |
| Fast feedback; human standards | Checks the agent can run, protected acceptance criteria, and review proportionate to the consequences of failure. |
| Maximize agent time; trust the boundaries | Explicit permissions, work limits, stop conditions, and an escalation path. |
| Disposable code; agents beyond coding | Preserved behavioral contracts and distinct authorization for planning, implementation, deployment, and operational work. |
This is how I would translate Kiro's guidance into a release contract a team can inspect before depending on a shared workflow.
The maintenance obligation is especially important in the second row. Kiro recommends changing instructions and tools as models improve. Once other teams depend on that setup, I would evaluate those changes before distributing them. A new instruction might reduce unnecessary questions while also removing a useful escalation. A tool change might simplify execution while expanding what the agent can affect.
I would record the workflow version, supported task types, relevant model and tool configuration, context sources, enforced permissions, required checks, and accountable owner. Where a provider does not expose or permit pinning a version, I would record that limitation rather than imply perfect reproducibility.
The release unit is the whole combination. A prompt file on its own is a component. The implementation could be a repository and an existing pipeline. It doesn't require another portal.
Test whether it knows when to stop
Imagine a shared workflow for updating a dependency in a noncritical internal service. I'm proposing this example; I haven't deployed it in my organization.
The workflow may prepare a branch, apply an update within an approved range, and run the required checks. It may open a review-ready pull request only when those checks pass and the change remains in scope. It may not merge the change, deploy to production, weaken required checks, or broaden the work into an unrelated refactor. In this example, a patch-version label makes an update eligible. It doesn't make the update safe.
I would evaluate more than its ability to produce a passing pull request. I would include an update that changes behavior, a missing test environment, an unsupported package, and a tempting opportunity to make the checks pass by relaxing an assertion.
In some cases, completion is the right result. In others, the right result is to stop, report what is missing or out of scope, and escalate to the accountable owner. I want the evaluation to distinguish those outcomes instead of treating every escalation as a failure of autonomy.
Appropriate stopping and enforced permissions are different protections. A missing test environment should produce an escalation. Merge and production access should be denied by the execution environment regardless of how the agent responds.
Kiro's feedback-loop principle emphasizes giving agents the means to test and correct their work. Its quality principle keeps accountability with the people shipping the result. I would connect them through acceptance checks the task-performing agent cannot quietly redefine to make its own change pass.
That doesn't prohibit agents from proposing tests or changes to tests. It separates proposing a new acceptance standard from authorizing that standard.
Suppose a model change causes the workflow to report success when a required test environment is unavailable. The dependency update might be correct, but this workflow version has failed its acceptance criteria. I would withhold that version until it stops and reports the missing evidence.
A passing evaluation supports a limited rollout within the tested scope. It doesn't establish reliability in settings the evaluation never covered. I would start with a small set of repositories, retain the previous configuration, and keep a way to revoke access. Reverting a workflow version doesn't undo actions it already took, so recovery still has to be designed for the action itself.
Autonomy should have a scope, not a target
The Kiro principle I would qualify most carefully is maximizing agent time while minimizing human involvement.
I agree with the objection to manually relaying errors between tools. That is work the system should often handle. I would not turn the number of running agents, or the length of an unattended session, into a measure of engineering success.
A workflow should use the autonomy appropriate to its task. Finishing a bounded change without unnecessary interruptions is useful. Continuing through an ambiguous requirement because stopping would hurt an autonomy metric is not.
Two Gates and a Night Shift described the arrangement in my personal pipeline: consequential plan and release decisions remained mine, with bounded execution and maintenance between them. That's one example of explicit decision rights. The number two came from my projects, and another team's risk profile may need more gates or different ones.
Kiro's boundary principle makes the important distinction between restricting access and supervising every action. I would implement shared workflows so the execution environment enforces permissions. An agent's promise to follow its instructions doesn't count as a control.
Writing a draft, changing a branch, deploying a service, and modifying production data deserve separate authorization decisions. Extending agents beyond coding should not silently extend the privileges of a coding workflow.
For each supported task, I want the release contract to say what can proceed, what must stop, and who decides what happens next.
Keep the behavior when you replace the implementation
Kiro's disposable-code principle makes an important exception for tests at system boundaries. An implementation can change while its behavioral obligations remain.
I would apply the same distinction to the agent workflow. Replace an instruction file, change a tool, or try a different model, but preserve the cases that define acceptable behavior. That includes cases where the workflow must decline to act.
For the dependency example, the lasting requirements are not the exact sequence of commands an agent happened to choose. They are the authorized scope, the behavior that must remain intact, the checks that cannot be weakened, and the evidence a reviewer needs.
A release process should make improvements easier without making those obligations negotiable by accident.
And the evidence cannot end at a green build. Nobody Pages the Agent argued that the people responsible for a service need enough understanding to diagnose and recover it. A shared workflow should leave them usable evidence of what changed and what was verified. A transcript they have to search during an incident doesn't meet that bar.
Prove that sharing it reduced work
A supported workflow has costs: maintaining context, running evaluations, investigating failures, handling exceptions, and helping teams adopt changes. Those costs belong in the comparison.
The Developer Experience Ledger makes the measurement obligation explicit. Follow the work to a verified outcome, separate elapsed time from human effort, and account for work transferred between people.
For this workflow, I would compare similar tasks before and after adoption. I would track completion, appropriate escalation, rework, review effort, support effort, and the cost of maintaining the workflow. Failed and abandoned attempts belong in that view too.
I would also ask the engineers using it whether they understand its decisions and trust its stop conditions. Fewer support requests are not an improvement when people have simply stopped reporting confusing behavior.
The attraction of Kiro in my original post was that intent could become a more structured part of building software. The question now is how to make the surrounding workflow dependable for people who didn't assemble it themselves.
Start with one recurring task and a team willing to evaluate it. Make its scope explicit, version the workflow, and test both completion and escalation before publishing a supported version. Roll it out to a small set of repositories, then use the results to decide whether to expand, revise, or withdraw it. The next team should inherit a supported capability.
