Code written by agents still gets reviewed

hurukan is largely built by agents. They write code, generate tests, run the suite, integrate, and open the change for release. It compresses the distance between noticing a problem and having it fixed in a running deployment from weeks to hours, and that is a genuine advantage.

It is also the claim in this field most likely to be inflated, so it is worth writing down where the automation stops and why those stops are not temporary.

What is genuinely automated

Implementation from a specification. Given a clear description of the change and the existing codebase, an agent writes a plausible implementation faster than a person and does not get bored by the tedious parts.

Test generation. Including the cases a tired human skips: the empty list, the duplicate, the timezone, the concurrent write.

Integration and the pipeline. Building, running the suite, checking types, resolving the routine conflicts, and doing it continuously rather than in batches.

The boring maintenance. Dependency updates, deprecation migrations, consistency across similar code paths. Real work, historically deferred, and the kind that quietly rots a system.

What is not

The decision about what to build. A specification is a judgement about a business, not a programming task. Agents do not know which of five defects matters to the company running this next Tuesday.

Architecture with long consequences. The choices you live with for years — where a boundary sits, what the data model asserts, what is deliberately made impossible. Cheap to get wrong quickly and expensive to have got wrong.

Review. Every generated change goes through review and the same gates as any other. The speed advantage comes from faster gates, not fewer of them, and anyone offering the second thing is describing a system that will ship something it should not have.

The release decision. A person decides what reaches a company that runs on this. That will not be automated, not because it cannot be, but because the accountability for a bad release has to attach to someone.

The failure mode worth naming

Volume. An agent will produce a large, plausible change quickly, and reviewing it properly takes as long as reviewing anything else. Teams that measure the speed of generation and not the speed of review accumulate under-reviewed code at a rate no human process can absorb, and the debt arrives all at once.

The defence is that generated changes must be small, tests must be genuinely independent of the implementation, and review capacity has to be the constraint the whole thing is sized against. If review is the bottleneck, the system is working correctly.

Why say it this plainly

Because an autonomous software factory sounds like a claim about not needing engineers, and it is not one. It is a claim about the interval between a defect and its fix, which is a thing a customer can measure.

That is the version we would want to be held to, and it is a smaller claim than the words invite. For a company being asked to run its operations on this software, a smaller claim that survives inspection is worth more than a larger one that does not.