What Actually Goes Wrong
Everything in this series so far has been about what worked. This one is about what does not, because a builder deciding whether to attempt something deserves the failure modes rather than the highlight reel.
Everything in this series so far has been about what worked. This one is about what does not, because a builder deciding whether to attempt something deserves the failure modes rather than the highlight reel.
There are five that cost me real time. All five are predictable, all five have a mechanical check that catches them, and none of the checks take more than a minute.
It does not remember.
This is the one that surprised me most and the one with the widest consequences. A model will solve the same class of problem a different, entirely correct way next month, because each solution is fine on its own and nothing carries forward about which one you already chose. Left alone, you end up with a codebase that works and has no unifying pattern, which is a maintenance problem that grows rather than a bug you can point at.
The check is that decisions get written down with their reasoning, not just their outcome. The outcome is recoverable by reading the code. The reasoning is not, and the reasoning is what you need, because the decision will get re-proposed and the version of you reviewing it in four months will not remember why the alternative was ruled out either. Standing instructions in the project help. Repeating yourself constantly helps more, and you should expect to do it forever rather than treating it as a failure.
It is confidently wrong.
A wrong answer arrives in exactly the same tone as a right one. It will reference a file that does not exist, a column that was never created, a function name that is almost but not quite correct. Not often, but often enough that assuming correctness is a bad bet, and the confidence gives you no signal at all.
The check that works better than anything else is stating the number you expect before you look. Before running a search to confirm a change landed, say out loud how many matches you expect to find. Then run it. If the number differs, stop, because the mismatch does not mean the search was wrong, it means your understanding of the system was wrong. Every other check catches bad syntax. This one catches bad comprehension, which is the failure that actually accumulates.
The same principle applies more broadly. Verify against the database rather than against the description of the database. Confirm a change ran rather than confirming it compiled. The gap between plausible and true is exactly where this technology lives, and closing it is cheap if you build the habit.
It drifts inside a single stretch of work.
Related to memory but faster-moving. Over a few hours, the same concern gets handled two different ways, both correct, because there was no reason for the second one to match the first. Two ways of doing the same thing is a comprehension problem for whoever reads it next, which on a solo project is you in six months.
The check is that you hold the pattern, and you send back proposals that solve something differently than you solved it before. Not because the new way is wrong. Because consistency is worth more than local optimality, and nothing in the tooling will enforce it for you.
What you see is not always what landed.
This one caught me repeatedly and it is the least discussed. The summary of a change and the actual state of the file are two different artifacts, and they can disagree. Content gets truncated. A block gets duplicated. A preview shows you a clean result while the thing on disk is not clean.
The check is that you verify the artifact rather than the description of the artifact. Read the file back. Count what should be there. Do not accept a report of success as evidence of success, in either direction, because the report is generated separately from the thing it is reporting on.
I learned this the tedious way, which is by fixing a file that was never broken because a preview made it look broken, and by shipping a file that was broken because a preview made it look fine.
It will not tell you when it is uncertain.
There is no reliable signal that distinguishes a well-grounded answer from a plausible guess. Both come back fluent. And it will not volunteer that the thing you are asking for is a bad idea, because it is oriented toward helping you do what you said rather than toward questioning whether you should.
The check is asking questions that force the boundary into the open. What does this not handle. What did you rule out and why. Is this the most robust version available. Those produce lists rather than reassurance, and a list is information. General approval is not.
That is the whole set. Now the part that matters more than the list.
None of these are reasons to avoid the technology. Every one of them is a reason to build a process, and the process is not sophisticated. Write things down. Say what you expect before you check. Hold the pattern. Verify the artifact. Ask for the boundary.
What all five have in common is that they fail quietly. Nothing crashes. No error appears.
What all five have in common is that they fail quietly. Nothing crashes. No error appears. The work looks like it is going well right up until you find that a decision got reversed without anybody deciding to reverse it, or that a number you have been relying on came from a query that never ran the way you thought.
That quietness is the actual risk, and it is why the checks have to be habits rather than reactions. You cannot respond to a signal that does not arrive. You can only build the habit of looking, and then look whether or not you feel like there is a reason to.
The trade is worth making. I would not have built this platform without these tools, and I would not have finished it without the checks. Both of those are true at the same time, and anybody telling you only one of them is selling something.
Selecting supply chain technology?
PreShiftIQ matches buyers to vendors on measured fit across TMS, dock scheduling, ELD, carrier vetting, and fleet management. Vendors pay for outcomes, never for influence, and the buyer match is free.
See how matching works at preshiftiq.com/how-it-works.
Next in the series: what this means for the industry, and why the technology is not the part that changed.
