If you know the good, you'll be good.
I have said that for years, usually to someone anxious about whether this work will still exist for them. I want to finish this book by explaining what I actually mean by it, because the anxiety is real and most of the reassurance on offer is worthless.
Plausible Is the Failure Mode
Start with a confession about the previous book.
Laravel, shipping fast. went out with thirteen defects of one particular species. Not typos. Confident, well-formed, entirely invented API calls. One taught a rate-limiter method as though it returned a live counter — it returns a closure, and the code as printed would have thrown. Another referenced an enum that exists nowhere in the framework or the codebase.
Every one of them read beautifully. They had the right shape, the right naming, the right idiom. They were exactly what that code should look like, and they were wrong.
They were caught by a person who knew what good Laravel looks like, reading with the specific suspicion that comes from having been burned before. Not by a test — there was nothing to test. Not by a linter. By taste.
That is the thing worth understanding about working with these tools. They do not produce nonsense you can spot. They produce work that looks exactly like the real thing. Wrong is cheap to catch. Plausible is expensive, and plausible is the default output.
The Scarce Skill Is Discrimination, Not Production
If plausible-but-wrong is the failure mode, then the valuable skill is no longer producing the artifact. It is being able to tell.
That is what "knowing the good" means. Not knowing a way — knowing which way is right here, for this system, under these constraints, and being able to feel it when something is subtly off before you can articulate why.
That taste is not downloadable. It comes from having been wrong in public, repeatedly, in a specific domain, and having had to live with the consequences long enough to learn what they cost. Every war story in this book is a receipt: the credential nobody could validate, the paused turn that rendered as finished, the two sites from one request, the clever ranking that measured worse. I did not read any of those. They happened, and they hurt, and now I can smell them coming.
What the Eighteen Chapters Were Actually About
Read back over what this book asked you to decide.
Whether that boundary is in the right place. Whether that cap is right for this tenant. Whether that failure is transient or yours. Whether this tool is safe to run twice. Whether the model is wrong or the pipeline around it is. Whether that hop is worth a week of work.
A model will answer every one of those questions instantly and fluently. It will produce a manager, a driver, a retry policy, a tool schema — and the code will be good. I use these tools every day; they are extraordinary at this.
What it cannot do is tell you which answer is right for a system it has not lived in. And — this is the part that matters — it cannot notice when it is wrong. It has no accumulated sense of what a bad idea feels like at three in the morning, because it has never been paged.
That gap is not a temporary shortcoming to be patched in the next release. It is the difference between generating an answer and being accountable for one.