Nobody worries my website was vibe coded. Everyone worries about my writing.

I use AI to build things and AI to write things. One gets treated as leverage. The other gets treated as a shortcut. I don’t think the difference is the tool.

I vibe code.

I use AI to build my website, explore tools, troubleshoot technical problems and make things I would otherwise have needed a developer for, or simply wouldn’t have had time to make. When people hear that, the reaction is almost always positive. Good use of the tools. Smart way to move fast without a team.

I also use AI in writing. It helps me draft, restructure, interrogate arguments, reuse research and produce work faster, which gives me more time for research, strategy, experimentation and increasingly the technical work above. That gets a very different reaction. There’s a tendency to treat it as avoiding the “real” job, as if the drafting were the part that counted and everything upstream of it didn’t.

I’ve been trying to work out why the same person, doing what is structurally the same thing twice, gets read so differently depending on which output it produced.

The workflow is the same workflow

Strip away the domain and both processes run the same shape. I define the problem. AI helps with execution. I evaluate what comes back. I remain responsible for whether it works.

When I fixed a technical publishing problem with AI, the interesting part wasn’t that AI could touch the code. It was that AI had also caused the problem, by ignoring a constraint it hadn’t checked, and fixing it still needed a human to diagnose what had actually broken and decide what “fixed” meant. The execution was fast. The judgement wasn’t optional at any point, and it wasn’t something the model supplied on its own.

Writing runs the identical loop. I notice something worth saying, work out whether there’s actually an argument in it, and use AI to get from that observation to a structured draft far faster than I could alone. Then I edit, sometimes heavily, and decide whether the argument holds up to the evidence I actually have. The model can produce sentences. It can’t decide whether the sentences are true, or whether the piece deserves to exist at all.

Neither workflow is the AI doing the job. Both are a human using AI to get to the point where the human’s actual job — deciding what’s worth building, or worth saying — starts sooner.

Writing carries something code mostly doesn’t

The strongest version of the objection to that parallel isn’t “writing is precious.” It’s that writing sits much closer to voice, identity and authorship than most business code does. Design carries some of that same weight. And once you move into novels, poetry, journalism built on original reporting or other genuinely creative work, the expectations shift again, because the point of those forms is partly that a specific person made the specific choices, sentence by sentence. A ghostwritten novel and a vibe-coded internal tool are not the same category of claim on authorship, and I don’t think they should be judged the same way.

But most of what I’m describing isn’t that. A landing page isn’t a novel. A Python script isn’t a handcrafted sculpture. A B2B article isn’t automatically diminished because AI helped produce some of its sentences, any more than a website is diminished because AI helped write some of its code. The suspicion aimed at AI-assisted writing mostly lands on exactly this kind of work — the explainer, the LinkedIn post, the client article — not on the narrower category where authorship genuinely is the product.

Competent output was always a proxy, in both directions

Part of what’s happening is that competent code and competent prose used to be reasonably reliable signals of the thinking behind them, because producing either one at all took real skill. That proxy has broken for writing: a fluent paragraph no longer implies research, evidence and a resolved argument sit underneath it, because a model can produce the fluent paragraph without any of that.

The same proxy broke for code, earlier and with less argument about it. A working script no longer implies someone understood the underlying system deeply enough to have written it by hand. Nobody mourns that the way people mourn it for prose. We adjusted the standard for code almost immediately: does it work, is it secure, does someone understand what it does well enough to be responsible for it. We’re much slower to apply the equivalent standard to writing, and default instead to interrogating the prose itself for tells — a familiar rhythm, an em dash, a certain cadence — as a substitute for asking the harder question.

That’s the more useful question in both cases: not whether AI touched the output, but whether real judgement sits behind it. Where did the idea come from. What evidence supports it. Would the person defend it if someone pushed back. A script nobody understands is a liability regardless of who typed it. An article with nothing underneath it is empty regardless of how well it reads. The test is the same test. We just don’t apply it evenly yet.

Why code got permission first

Some of the asymmetry is fair. Code has objective checks writing doesn’t: it runs or it doesn’t, the tests pass or they fail, the site loads or it breaks. A bad vibe-coded feature announces itself. A bad AI-assisted paragraph can sit there looking fine indefinitely, sounding fluent while saying nothing, and that’s a real difference in how quickly a lapse in judgement gets caught.

But I don’t think that fully explains the gap, because plenty of code never gets that kind of scrutiny either, and plenty of writing does get checked hard against evidence, argument and fact. I suspect the bigger reason is that writing has spent longer as a status marker for a particular kind of professional identity than most business code has. Developers didn’t need to defend the idea that using better tools was still “real” engineering; the industry had already had that argument, with compilers, frameworks and now AI assistants, and mostly landed on judging the outcome. Writing is still having it, partly because being a good writer has functioned as a professional credential in a way that being a good coder of internal tools mostly hasn’t.

The question that actually sorts it

“Did AI write this” is the wrong question in both directions, because the honest answer is usually “partly, and it doesn’t tell you what you want to know.” The question that actually sorts good use from bad is who supplied the judgement.

Who decided what was worth building, or worth saying. Who checked whether it was true, or whether it worked. Who shaped the argument, or the system. Who rejected the output that was fluent but wrong. Who takes responsibility for the finished thing when someone asks a hard question about it.

That’s where the real line sits, and it runs through both domains rather than between them. A developer who ships whatever the model generates without understanding it has outsourced the job, exactly as much as a writer who publishes whatever the model drafted without checking it against anything real. A developer who uses AI to handle boilerplate so they can spend more time on the system’s actual design is using leverage well, exactly as much as a writer who uses AI to handle drafting so they can spend more time on the research and the argument.

Using AI as leverage and outsourcing the judgement that made the work valuable look identical from a distance, in code and in prose alike. They aren’t identical up close. The distinction isn’t which domain you’re working in. It’s whether you’re still the one deciding what’s worth making, and still the one who’d have to answer for it if it’s wrong.