The problem was never that the code came out wrong, but that the decision got made without anyone knowing.
Asking an AI to "just solve this" sounds simple, until you remember how most tasks actually get described: a title, two lines, a generic acceptance criterion. Enough for someone who already knows the system to fill the gaps with context they already carry in their head. Not enough for an AI, which fills the same gaps, only by guessing, and without announcing it was guessing.
The symptom doesn't show up as malformed code. It shows up as a design decision made in the middle of implementation, unrecorded, with no one aware it was even made. And the problem doesn't disappear; it stays dormant until the day the path it skipped turns out to be exactly the path a real case follows.
This isn't unique to AI-generated code. It's the same logic I apply to any diagnosis: I only move to implementation once the decision is documented, reviewed and approved, never mid-process, never in silence. Propose, approve, execute. No skipping steps.
A concrete example of this, without a single line of AI involved: in Arquimadera's data model, the problem was the system itself deciding on its own. Categories, suppliers, brands and products existed as free text, repeated across different cells. An automation silently assumed that "Supplier X" in one cell was the same "Supplier X" in another, until it wasn't. A minor variation in the name would break a formula without warning, and the error didn't surface the moment it happened; it surfaced weeks later, disguised as a wrong price or a duplicate product.
The fix wasn't patching the automation. It was removing the ambiguity at the source: each entity got a unique, stable ID, and the consolidation was documented across 40 tracked changes. The automation no longer had to "decide" whether two pieces of text were the same thing, because that decision was already recorded upstream (in the ID, not in an assumption made halfway through the process).
Same principle, with or without AI: a decision recorded before it turns into behavior eliminates an entire class of silent error. Documenting before implementing doesn't slow the work down; it only slows down the first step, and it prevents the rework that usually shows up weeks later, disguised as something else.
If someone (or some automation) is deciding on its own in your processes, before anyone notices, write to me: kaluanautomate@gmail.com or on LinkedIn.