Kiro can fix its own mistakes. It still cannot be its own judge
Kiro's experiments point to a broader rule. An agent is more than a model. Its prompts, tools, memory, tests, and reviewers shape what it can do. The agent may propose its own fix. It must not judge that fix.
Kiro improved without changing the model
Kiro is an AI coding agent. In How Kiro Fixes Itself , its team describes kiro-trace, a system for studying failed and wasteful runs. Several of its best fixes did not add intelligence. They removed friction around the intelligence already there.
One false tool instruction appeared in 61,742 model messages across 445 samples. It did not lead to useful behavior. Another instruction told Kiro to call a tool that did not exist. The team removed both.
Other failures came from the tools. Two contract changes stopped 205 read-tool rejections and 167 sub-agent rejections across 80 sampled sessions. A separate search defect silently returned no results in about one out of eight searches.
Memory caused another problem. Kiro summarizes long conversations before it continues. The old design placed raw user messages after the summary. This left stale requests near the cue to continue. The best replacement kept less. It kept a short summary and the most recent turns. It dropped the raw message history.
Alongside the tool fixes, Kiro reduced redundant rereads by about 83 percent. The compaction retention score rose from 0.82 to 0.92. In the system's first week, seven of eight pull requests merged. One closed for unrelated reasons.
Three patterns appear in those results. Removing instructions sometimes worked better than adding them. Tool contracts changed the model's observed behavior. Less message history improved retention during compaction.
In a larger experiment, a smaller prompt and tool set scored better. It reached 82.4 percent instead of 77.5 percent. It also used about one-third of the tokens. The team did not ship it because changing the default tools required a product decision.
The model stayed the same in these experiments. Its instructions, tools, memory, and evaluation environment changed. The measured behavior changed with them.
Agent performance is a property of the full system: model, prompt, tools, search, memory, retries, and tests.
These numbers come from internal experiments reported in How Kiro Fixes Itself . They are not production estimates. I use Kiro in my own work, and I see this as a strong engineering story. The team built a process designed to reject attractive but weak results, and it published the failures that made that process better.
A fix is not proof
Evaluating changes to the full agent system presents a measurement problem. Model outputs vary. A candidate change cannot also serve as evidence of its own success.
Each Kiro run leaves a trace. It records what the agent saw, did, and received.
kiro-trace studies that record. It may compare Kiro with other agents on the same task. It then names one likely cause and proposes one small change.The process observes a real failure or wasteful run. It diagnoses one behavior that may have caused the result and changes one prompt or tool rule. It then compares fresh runs of the changed and unchanged systems. An independent code gate rejects weak candidates. A technical person decides whether a surviving change should ship.
The candidate does not grade itself. The system runs Kiro with the change off. It also runs Kiro with the change on. Both runs are fresh. This matters because model behavior changes from run to run.
The change starts with cheap tests. It must fix the known failure. It must not cause too much harm elsewhere. A contamination check rejects a pass if the agent fetched the answer or tests. Only then does the change face the full benchmark.
One candidate seemed faster, cheaper, and more accurate. A host-level analysis found that one run caused almost all the gain. Kiro had escaped a recurring loop in that run. Without it, the change was worse. The team rejected the candidate.
A trace can support a repeatable test when it exposes a specific mechanism. The trace is one account of what happened, not the test itself. The team must state a smaller claim with a clear expected result.
Suppose Kiro sends the string
"true" when a tool expects the Boolean true . The full run may never repeat. The failed mechanism can still become a fixed rule. On retry, the adapter should correct this harmless mistake. The rule can then become a test with a known input, expected output, and clear pass or fail.
Behavior tests are harder. A goal such as "solve this task with less waste" still needs fresh model runs. The gate may use fixed code. Its evidence still varies. Control runs and larger benchmarks reduce luck. They do not remove it.
The real system cannot be proved by assertion. In Closed-Loop Agent Control , I described an agent as a controller. It acts through tools. Those actions enter the plant: the codebase, infrastructure, runtime, and user experience. A sensor observes what the plant did. It returns the gap between intent and reality.
The plant is not beyond all control. The agent can act on it. But the plant is outside the agent's direct knowledge. A good edit does not prove a good build. A good build does not prove a good deployment. A good deployment does not prove that a user can finish the task.
The control loop has five parts. The agent chooses a change from the current error. Its tools edit, build, configure, or deploy. The real system produces a runtime and user result. An independent verifier observes the boundary that matters. The result returns as an error signal for the next change.
Closed-loop evaluation places the test outside the fixer's authority. The fixer cannot weaken or skip the test. It cannot convert a failure into a pass. Those controls keep the measured goal stable while the system changes.
The compaction result can be described in the same terms. The old design preserved more history. Raw messages pulled Kiro toward stale work. The revised design kept the current state and omitted the full transcript. Good memory keeps what the next action needs. It does not keep every sentence.
The scarce part is technical judgment
An independent judge stops the agent from approving its own work. It does not choose the right goal. It does not choose the right metric. It does not decide which trade-off belongs in the product.
The smaller tool-set experiment separates benchmark performance from product choice. It scored higher and cost less, but the team did not ship it. The change could improve the benchmark while making Kiro less useful. The product decision requires evidence beyond the benchmark.
In AI Could Make Technical People More Scarce , I argue that technical work needs technical supervision. Process confirmation and technical validation are different tasks. Reliable review requires knowledge of the domain.
Technical skill is only part of the case. An LLM does not share the human conditions that shape our reasons for caring about the outcome. A response may fit the prompt, but that does not establish a shared underlying objective. This is related to the inner-alignment concern: observed compliance is not proof of aligned goals. A technically qualified human must therefore remain in the governance loop, owning the goal, consequences, and release decision.
The reviewer must know if the metric tracks the real goal. They must spot weak tests and hidden faults. They must see when a tool fix hides a deeper defect. They must know when a benchmark gain harms the product. These are technical judgments.
The system therefore separates three powers. The agent diagnoses a run and proposes a change. An independent gate measures fresh treatment and control evidence. A technical person chooses the goal, examines the measure, understands the trade-off, and makes the final decision.
AI can grow the amount of technical work faster than it grows the supply of people who can judge that work. Better agents may make expert supervision more valuable. They may also make it more scarce.
Two questions remain open for me. The first concerns what happens after a human rejects a pull request. The public account does not describe whether that reason becomes durable input or whether an equivalent idea is recognized when it returns in different code. A weak implementation may deserve another try. A rejected product choice should guide future proposals.
The second question concerns how the gate's rules are chosen. Code does not choose its own metric or expected result. It does not choose the sample size or harm limit. A technical person must define what success means. That person must also approve the permanent test.
Durable rejection memory would help prevent unwanted ideas from returning. Clear ownership of the test helps keep the gate aligned with the intended outcome. Kiro's separation of proposal and acceptance is a strong foundation; these questions concern how that foundation can carry human judgment forward.
The phrase "Kiro fixes itself" refers to this larger process. Kiro does not set its goal, control its gate, or merge its patch. The surrounding system mines traces, proposes changes, runs tests, and presents evidence to a technical reviewer.
Under this definition, self-improvement is a governed system property. Its reliability depends on the limits around the model.
The safe unit is not a self-improving model. It is a governed system. The agent proposes. An independent sensor observes the real plant. A technical person owns the goal and the final decision.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article