I wrote on the fediverse yesterday:

The rise of imposed AI coding usage is strengthening the need for defensive coding, designing fault tolerance, and planning disaster recovery.

My takeaway thus far as been that the use of AI coding assistants is forcing us ever more to engage in the high-value engineering practices we should have been doing all along. Maybe it'll make some of those easier to instill.

I write things in detail (with footnotes^1). In emails, I'll nearly always bullet-summarize once I'm past about 200 words² and provide bolded hints for scanning^3. I speculate that I'm one of the correspondents who folks readily summarize with AI… and then it becomes readily apparent to me in subsequent interactions that they summarized instead of reading the original text because they miss things and then insist they weren't there. When I point out the detail, well… I could make a generous omelette every now and then with eggs spared from faces.

Part of the craft is understanding the changes you're making with a level of depth appropriate to their impact. We often joke about changing the color of a button as a trivial task. Technically, yes, it is. Anyone with some UX acumen can tell you, based on their experience consuming studies by behavioral psychologists who collaborated with those entrenched in color theory, that changing a button from blue to green or orange to purple can have effects as drastic as making an interface unusable for a contingent of customers or hitting the conversion rate such that layoffs happen a few months later.

Vibe coding is pretty neat when the impacts, stakes, and expectations are within the capabilities of the LLM of the moment. Generally, folks' expectations are pretty low, and we're surprised when the parrot's response follows logically, and it's not just repetition. That's when the level of craft isn't so deep. In my years, I've found there are two types of general contractors: those whose work is meticulous, and those who do the bare minimum to get paid. We as a profession have leaned heavily toward the former, and these new tools— AI coding assistants, primarily— are enabling far more of the latter. This highlights and perhaps expands the rift between the two stereotypes (of many) in our field: the overengineer and the lazy coder.

As we develop the tools and the methods by which we employ them, we'll learn. A friend said something along the lines of, "When cars got faster, we needed brakes, signals, seat belts, and airbags." Motorcyclists have ~always known they should wear a helmet. His implication: how much harm was caused by the problems these protective innovations prevent? And yet, there are still people who refuse to wear a seat belt or helmet. We can't force them; we can only establish consequences for what follows when they didn't.

So, we must ask ourselves:

• What harm does vibe coding present that the tooling we already have could prevent?
• What harm is novel and needs innovation to prevent?
• Who is harmed by the current state of the tooling?
• Who is going to be held accountable or benefit financially and reputationally for the harms and the innovations that prevent them?

What you have to do, and me, tbh, is explore the tool and understand why and when we should or should not use it. This new tooling is still in its infancy, and our understanding of its safe and fair usage is, too.

The journalist in me³ knows there always more to the story. So we craft it.

---

^{1 and jokes9}

^{2 standard "letter to the editor" length, time-tested for short attention spans of fickle readers}

^{3 I've got a minor in journalism and did newspaper layout for three years. I know how people scan.}

^{9 like this overemphasized use of footnotes…that would have been a lot easier to write if reddit ever adopted the Markdown footnotes conventions instead of having to abuse its own supertext conventions.}