Tag: ai-assisted development

As code becomes cheaper to produce, unowned complexity becomes more expensive. This essay grounds that claim in the decisions that syntax cannot settle by itself: consistency, retries, ordering, failure recovery, scale, team capability, operating cost, and the expected life of the system. A plausible implementation is not yet an engineering answer because the same feature can require a responsible monolith in one organization and a responsible distributed design in another.

The important qualification is that judgment is not a uniquely human property that engineers can claim without evidence. Agents can propose architectures and ask useful questions, while people routinely make shallow decisions or preserve bad conventions. The durable boundary is therefore process, not species: record why a tradeoff was chosen, expose assumptions, work in reviewable increments, test failure modes, and keep a named owner accountable for the result. AI amplifies whatever discipline already exists. Without those controls it accelerates entropy; with them it can widen the set of options a team can examine before committing to complexity.

Giles Edwards-Alexander gives refactoring an unusually concrete AI-era price tag. In a roughly 150,000-line, agent-written Rust application, a representative change initially pulled 159,564 input tokens into context. After breaking a 17,155-line Firestore module into coherent responsibilities, the same task used 27,360 tokens, an 83 percent reduction. The useful mechanism is not small files for their own sake. Better boundaries let an agent find and load less irrelevant code.

The number is evidence, not a universal exchange rate. This was one greenfield codebase, the token counts were estimated from characters, and the agent needed sustained human direction to recognize and execute the refactoring. Correctness, review time, testability, and human comprehension still matter more than a cheap prompt. The durable lesson is that technical debt now charges two readers: people and machines. Good structure can lower both bills, but deciding what belongs together remains design work.

Google's case for Go in agent-assisted development is strongest when it focuses on constraints. A strict compiler, one formatter, integrated tests and fuzzing, a substantial standard library, stable compatibility, and conventional project layouts give both agents and reviewers fewer ambiguous choices. If the scarce resource is human review rather than generated code, readable and mechanically checkable output is a meaningful advantage.

It is also a language advocacy argument, and cleaner generated Go is not the same as better software. Consistency cannot repair a vague requirement, a weak boundary, or a change nobody can validate; verbosity can aid review until it merely expands the surface to inspect. The claim should ultimately be tested in team outcomes: smaller diffs, faster trustworthy reviews, fewer regressions, and lower maintenance cost. Go can provide an excellent feedback loop for agents, but engineering judgment still decides what the loop is optimizing.