AI news ·
AI writes more code, but engineers still own the system decisions
Engineer Armando Picón argues AI coding agents can handle more implementation but not the judgment calls on what to build or how to prove it works. He separates intent, generation, verification and decision.
Software engineer Armando Picón argues that AI coding agents can take on more implementation work without taking over the judgment calls that decide what gets built and what counts as proof it works. In a November 1 essay, he separates four activities that get lumped together in claims about AI transforming development: intent, generation, verification and decision. Automating generation, he writes, does not settle the other three.
Picón is skeptical of framing AI as a replacement for developers who write code. That framing, he argues, reduces developers to typing and turns task automation into a claim about jobs. He keeps his focus on a narrower question: how teams use these tools while keeping their decisions visible and their feedback useful.
Decisions need a place to live
A chat session is a convenient place to explore options and a fragile place to store the only record of an architectural decision. Model context is bounded, and long sessions may be summarized or compacted. Picón warns that a summary can preserve a conclusion while losing the condition that made it reasonable. "Use a local cache" is not the same instruction as "use a local cache because this screen must remain usable without connectivity."
His suggestion is a small, reviewable project guide file. It would hold the product's purpose and current scope, including what's explicitly excluded, the system boundaries and the reasons behind architectural choices, the quality checks the team runs, and links to deeper decisions. The filename itself carries no special power, he notes: an agent won't necessarily load it, so it has to be connected through the tool's project instructions or included in the task. Then the engineer checks how the agent interpreted it.
For each increment, Picón recommends supplying the relevant files and asking the agent for a short account of the intended change, the constraints and the acceptance cases. A paraphrase catches misunderstanding early, though the implementation still has to show compliance.
Spell out the next behavior
Picón works through a hypothetical mobile search screen to show the approach. The first increment covers local search over saved items; remote search and changes to persistence are out of scope. Before any code, he makes the acceptance cases explicit: a matching query shows the expected items, a query with no matches shows an empty state, clearing the query restores the full collection, and an older asynchronous result cannot overwrite a newer query's results.
That last case raises a technical question the agent can help assess: does filtering need asynchronous work at all? Picón says to settle it against expected data size and responsiveness requirements rather than adding concurrency because a template expects it. He might choose unidirectional data flow, explicit UI states and a separation between filtering logic and rendering, but calls that an engineering choice with a purpose, not a universal rule.
After the increment, he inspects the diff, runs the checks and exercises the screen. A passing test suite doesn't excuse an agent that rewrote persistence against the scope restriction. A correct-looking empty state doesn't prove the search matches the right field.
Generation has to answer to verification
Agent output is probabilistic, so acceptance should rest on evidence an engineer can inspect and, where practical, reproduce. Picón separates what each check actually proves. A formatter checks conventions. A compiler checks language and type rules. Tests evaluate selected behavior under selected conditions. None of them establishes that the team chose the right product behavior.
He also flags a subtler failure: a generated test can faithfully encode the same misunderstanding as the generated implementation. A search test might confirm that some result appears without checking which one. He recommends reviewing each assertion against its acceptance case and including a failure case on purpose. Controlled verification needs controlled inputs too, since tool versions, fixtures and execution conditions all affect results.
Hooks and local checks catch mistakes earlier, but their coverage depends on what triggers them and whether they can be bypassed. Where a team needs enforcement, server-side checks and repository protections require their own configuration. A local hook is not a remote policy.
For developers weighing where agents fit in their own workflow, training programs such as AI for Software Developers Courses cover these review and verification practices. The broader catalog of AI for Developers Courses includes related material.
Documentation has to earn its maintenance
Picón pushes back on workflows where a small change triggers a long chain of generated documents before anyone sees working behavior. Each document becomes something to review, reconcile and keep current, and producing text cheaply doesn't make reading it cheap. He cites Birgitta Böckeler's 2025 comparison of Kiro, spec-kit and Tessl, which distinguishes tools that write specifications first, retain them during maintenance, or treat them as the primary source. Those differences matter when weighing costs and control.
He applies a practical test to any document: what decision, implementation or verification does it support, and who will maintain it? A multi-page explanation of a compatibility constraint earns its place. Repeated prose that changes no decision does not. Stronger specifications make sense for safety constraints, regulated work, public interfaces and cross-team coordination, where a concise guide is the entry point to necessary detail rather than a substitute for it.
Keep the acceptance decision explicit
The loop Picón advocates is simple: define the next behavior, supply the context it needs, check the interpretation, inspect the change, collect evidence and decide whether to accept it. When a decision changes, update the durable guidance. If review becomes unmanageable, shrink the increment or improve the checks before asking the agent for more output.
He states the limits of his position plainly. It depends on the engineer's understanding, the quality of the evidence and the cost of keeping guidance current. The essay is a working position, not a controlled study, and he makes no claim of demonstrated productivity gains. Proving a gain would require comparable tasks and accounting for review, rework, defects and maintenance, not just time spent generating code.
"I am comfortable delegating more of the work when I can explain what was requested, what changed, and why the evidence supports accepting it," Picón writes.
Why this matters for product, IT and creative teams
The people most exposed to this shift are the ones reviewing AI output without a clear standard for accepting it. Picón's test applies beyond software: before approving anything an agent produced, you should be able to say what you asked for, what changed and why the evidence supports accepting it. Teams that keep decisions in a short, maintained guide and define acceptance cases up front get earlier chances to catch a bad assumption. Teams that rely on the conversation as their only record lose the reasoning the moment the context window closes.
Picón closes with a question worth putting to any team using these tools: which decisions in your workflow remain visible after the conversation ends, and what evidence tells you the agent respected them?