Metaknowledge
You don't need to know how to do it. You just need to know what you're doing.
The platform you're reading this on was built by an AI agent on my instruction. So was the publishing pipeline behind it. This article is about what went wrong during that process, and what that says about where everything is headed.
The Bloat Incident
I built this writing app for myself first — a tool to take notes and compose faster, tailored exactly to how I work. When it came time to publish, I needed a frontend. So I did what any sensible vibe coder does: I prompted an Opus-driven agent to build it.
I don't remember the exact words — I wasn't saving my prompts automatically back then, something I've since fixed — but the gist was: make it discoverable, SEO-friendly, easy to index. Look at how serious publishers build their sites. Do that.
It ran for 45 minutes. Burned through a lot of tokens. Then came back with an approach that didn't look much like what you're seeing now but did, in the way agents often do, inspire it. More importantly, it told me it had integrated something called the Ghost Publishing Platform.
I downloaded Ghost, read about it. Solid tool. Millions of users, serious publishers among them. The problem: it's large. Very full-featured. And I already had a backend. So when I started adding features and noticed every small change was taking forever, I asked the agent: do we actually need this?
We're using almost none of it, it told me. But you said you wanted something really professional, so I used a professional tool.
Right. My fault. I asked it to find something lighter. It suggested Payload CMS — better fit, less overhead. Sure, let's do that. Another big refactor. More tokens, more waiting.
Then came Next.js. Same story. Great library. Wildly oversized for what we were actually doing. Another round of slowdowns, another round of questions, another round of realizing I should have asked all of this from the start. Eventually I had to strip almost everything back and rebuild with proper attention to what was actually needed and in what order things were being layered.
If you're a developer reading this: yes, I know. None of it is subtle. But that's exactly the point I'm getting at.
Clanker Slop
In developer circles, this kind of outcome gets called clanker slop — AI-generated code that's functional but somehow wrong. Too heavy, badly structured, solving a problem adjacent to but not quite the one you had. The agents get the blame.
The blame is misplaced. An agent with incomplete instructions will produce something resembling what it understood you to want. If you asked for something "professional" without specifying scope, it reaches for professional tools. That's not a failure of the agent. It's a failure of specification.
Which leads to the actual problem: if you don't know enough to specify correctly, and don't know enough to spot when the result is wrong, you end up with a bloated mess that works until it doesn't. Now that building software is ostensibly something anyone can do, there are a lot more people in that position.
Feature bloat is the same problem at the product level. The easier it gets to add things, the more tempting it is to add everything. Some of the most successful apps alive right now win precisely because of what they don't have — a razor-focused interface that does a few things well. That takes taste, sure. But it also takes knowing, at some level, how software and users actually interact. Without that, you're just adding features at the speed of ideas.
The Monk and the Typist
This isn't new. It just feels new because code is the thing changing now.
Writing — actual writing, words on a page — was once a specialized craft. Monks sat with candlelight and painstakingly transcribed manuscripts. The effort required to put language into permanent form was itself a filter: if someone went to that trouble, it was probably worth reading. Then the printing press arrived. Then the typewriter. Each step lowered the barrier, expanded who could participate, and triggered the same anxieties about standards slipping. Literacy rates went up. We moved on.
High literacy didn't make everyone a good writer. Knowing how to form letters doesn't mean you can structure an argument. Writing words is not the same as knowing how to communicate. You still have to learn grammar, composition, how to hold a reader's attention across five thousand words without losing the thread. Those skills live above the mechanical act of writing — and they're what actually matter.
Code is passing through the same transition. The mechanical act is becoming accessible to anyone with a prompt. The monks are watching the printing press arrive. What remains, after the mechanics are automated, is understanding at a higher level. That part doesn't go away.
What Atrophies, What Doesn't
We will lose the ability to write code, just as we largely lost the ability to write by hand. I was taught cursive. It was already a little ceremonial by then — something you learned, used briefly, and filed under quaint. Now most people type. Soon most people will dictate, and the AI handles the rest. Each layer of automation erodes the skill it replaces.
This is fine. Typists vastly outperformed people writing by hand. People dictating to AI assistants will outperform people typing. Skills don't disappear — they shift upward, away from execution and toward direction.
What frees up is not irrelevant. When you're not spending mental bandwidth on how to form a sentence, you can spend more of it on what the sentence should say and whether it needs to be said at all. When you're not writing code, you can think harder about what the software should actually do. That's not nothing. It's arguably the part that mattered all along.
But — and this is what keeps getting glossed over — "not writing the words yourself" is not the same as "not needing to understand writing." You still have to decide what to say, in what order, at what length. You still have to know when something's redundant, when the logic doesn't hold. An agent will implement whatever you tell it; it won't tell you that your structure is a mess or that you've made the same point three times.
Same with code. You can't make good software by prompting an agent if you have no idea how software works. You'll get something that looks like it might work — until you try to change something and the whole thing creaks under the weight of decisions you didn't understand well enough to question.
Metaknowledge
The broader trend of the information age has been this: as knowledge becomes more available, what becomes valuable is not the knowledge itself but the ability to navigate it. Specialization still has a place, but the direction of travel is toward higher abstraction. Processes. Structures. How things layer, how they communicate, where bottlenecks form.
You don't need to know how to write well in order to write well. But you need to understand how communication works.
You don't need to know how to write code in order to build software. But you need to understand how software works.
The level at which you need to understand things shifts upward, not away. The details get handled by tools; the architecture remains yours. And if you abdicate the architecture — if you just prompt, accept, and ship — you get Ghost-sized libraries in tiny apps, Next.js where a static folder would do, and features nobody asked for buried three menus deep.
This will have consequences for how we teach. A lot of current curricula point toward specializations that are about to change dramatically or stop existing altogether. What to replace them with, and how — that deserves its own treatment. But the answer will have something to do with understanding at scale: knowing how things work without needing to work them yourself.
That's metaknowledge. And if the last few months of building this platform taught me anything, it's that you can feel exactly when you don't have enough of it.