How to clank hard without knowing how to code. — Howaboua

Howtoclankhardwithoutknowinghowtocode.

Ihaveaconfessiontomake.Ihavebeenclankingforaboutayear.

Lifelong PC nerd, yes. Actual developer, no. Twelve months ago I did not know what NPM was. Since then I have spent roughly 3000 hours and probably a 100B tokens building, breaking, rebuilding, deleting, resurrecting, and swearing at React/TypeScript/database/AI-shaped apps.

Don’t expect high brow engineer takes here, just a practical view on how to approach coding with AI agents if you don’t know how to code, can’t be arsed to read the code, or just want to improve what you’re doing.

Disclaimer: if you don’t understand the lingo of whatever comes next, you are not ready. And that’s fine. Use the fact that you are not ready to learn more.

Was vibecoding ever alive?

When Karpathy coined the term, the internet did what the internet always does. Took it to the levels of hype that mostly inflated some egos, wallets and subscriber counts. But unique vibecoded apps that truly succeeded are yet to be seen.

In the original sense, it’s: prompt, fire, forget, pray. No manual edits, no understanding. “Make no mistakes”.

Then there’s Steipete and “agentic software engineering”. You prompt carefully. You watch. You steer. You inspect. You verify. Maybe you edit by hand, maybe you do not, but you know what’s going on.

And then there’s this whole idea of “AI-native”, that doesn’t really have anything to do with the other two. This mostly describes people who began devving after AI entered the room.

Why the intro? Because I believe the true difficulty lies in crossing the line between vibecoding and agentic software engineering. AKA knowing your shit.

Your agent is blind and so are you

If you start in tools like Lovable, Chef, AI Studio, Bolt, Replit, or whatever the current slot machine is called (it’s great that they exist, don’t get me wrong), you get something you don’t realise is there: a feedback loop. The agent changes something. The app tries to build. Something breaks. Your clanker should get pushed to check it.

Then you move to a CLI or desktop coding agent and suddenly you are flying blind… and so is your agent. Unless you design the loop yourself. This is where vibecoding faceplants. Vibers don’t know that the loop exists in the first place.

LSPs are not the answer you think they are

They were fine when models were dumber and our prompts were more conservative. Not so much anymore. An LSP yelling “this import is broken” while the agent has not created the target file yet is noise.

What works better is boring, old stuff: typechecks, linters, tests, builds, pre-commit hooks.

The Clanker should do the work, run the checks, then fix what the checks reveal. Even if it edits the tests itself, it has some sort of a feedback loop that makes it consider things it’s doing just a little bit more.

Markdown is not training

Your AGENTS.md, CLAUDE.md, cursor rules,or whatever overengineered documentation stack you’re trying to implement is not a fine-tune. It is not a substitute for using a model that actually knows the stack or a stack that is in the training data (neither are skills, BTW).

If your model keeps failing at Tailwind v4, use a more up-to-date model use v3. You do not need to follow the latest and greatest solutions.

(That being said, you need to use the latest and greatest model, whichever it is at the moment, or the best one you can afford)

Writing thousands of lines of docs, make your agent fetch stuff from the internet will burn tokens, half-apply some of the rules that do not matter to the current task, ignore the one rule that does, and then it will say that you were absolutely right to call it out for fucking it up.

Multi-clanking

Subagents are cool. Subagents are useful. Subagents are also where unclear intent goes to reproduce.

People see agent teams or Gastown and think: “Clankers go brrr”.

Nope.

Models try to infer your intent. They take what you write, and add what they think is on average best to do with it. Then the main agent relays bits of that intent to subagents who have their own thoughts and opinions on what it is that the orchestrator meant.

Congratulations. You have re-invented distributed slop at an enterprise scale.

I used to be bullish on subagents. Not so much anymore. Not because they cannot code. They can. The issue is context and recovery. If my main agent finishes a task and implements some crap I didn’t ask it to do, it knows where it was. It has the files in context. I can ask it to iterate, and I waste less time going back and forth to make it understand what I really wanted.

If five subclankers each made “reasonable” guesses in separate branches, the main agent has to become a confused project manager running like a headless chicken trying to decipher code that it didn’t create in the first place. Sounds very human doesn’t it?

This is how you spend two hours resolving work that did not need to exist and burn tokens.

Do not parallelise confusion.

You are not suddenly a senior engineer

The most lukewarm take ever but it needs to be said.

AI did not make you a top-class engineer. If you had decent ideas in the first place, congrats, you might be now be a one-person-startup. That is still more power than a non-dev had at any point in history.

But this is also where a lot of vibers get high on their own AI farts.

Just because you can, it doesn’t mean you should. Don’t get fooled into thinking that if the AI can do all of these amazing things, you are suddenly on the frontier of software development. You are not. You are a builder with ideas.

Be critical of yourself.

What to actually learn

Not syntax first. Sorry, but no.

If you love hand-coding or the idea of it, learn it. If you want to become a professional engineer, learn it. If you enjoy the craft, learn it deeply. Start a business unslopping slop (let’s face it you’ll be using AI to do it anyway). But if your goal is to build products with agents, learning to type React components from memory is not going to get you anywhere.

The highest-leverage move is learning how good builders think.

Read people smarter than you. Listen to technical podcasts. Watch engineers explain tradeoffs. Avoid hypebros who tell you AI can do everything. Avoid doomers who pretend nothing changed. Both are full of shit.

You need vocabulary.

You need to know words like state, schema, migration, idempotency, auth boundary, race condition, cache invalidation, optimistic update, background job, integration test, abstraction, coupling, cohesion, dependency, rollback (and some other words that my Claw suggested to include, because I didn’t care enough to think about them myself).

Not because you need to hand-write all of it.

Because there are only so many times you can ask a Clanker to explain the world in “plain English” before you become the bottleneck… (Where have I heard this before…)

Read the fucking output

Stop complaining that models write long responses. Just read them.

How else are you going to know what happened? How else are you going to catch the moment where the Clanker strayed off your original idea? How else are you going to learn the language?

Same goes for their reasoning, as redacted as it is. You see something weird happening? Stop. Ask why.

The community obsession with making agents speak like cavemen is one of the dumbest things we have done to ourselves.

You are hiding the audit trail because reading makes you tired. You are polluting the reasoning chain with things that the model normally wouldn’t consider.

If the agent’s explanation is too long, ask for a tighter summary after the work. Fine. The output where you learn how the agent interpreted you.

And if you never examine that, your prompts will stay bad forever.

“Am I making sense?”

The key to unlocking coding with agents without reading the code is prompting with pseudocode.

Give an agent a logical instruction of “when X then Y, and if Z, then…”. Give it a few bullet points like that. Write a long prompt. Define success criteria. Always end with “am I making sense?”, so the agent can spit out your BS in a more logical way. Next time you’ll know better how to talk about things.

Do it enough times and something weird happens: you start thinking like a Clanker yourself. You start understanding them. You start speaking their language. You minimise the inferred intent.

Dictation is underrated

Typing and thinking are not the same thing. Don’t quote me on that but they live in different parts of brains. Speaking and thinking are wired much closer.

When I type, I edit myself too early. I skip the weird rambling because I am trying to make things perfect. I try to sound coherent before I have actually figured out what I want.

When I dictate, I just stream my consciousness and suddenly start thinking about possible issues my idea might have.

Then the agent can sort it out. Or I can read it and re-dictate. Or we can both stare at it and realise half of it was utter bollocks and cry a little bit.

Dictate for a week. Force yourself to explain the feature out loud. Then ask the agent to restate it. READ THE THING.

“But AI is crap at large codebases.”

Because they were created by humans. And most of the times by mediocre, lazy devs. No offence to anyone, but as in every profession, not everyone is a prodigy. And on average, people are lazy.

If you are somehow a dev reading this trying to get into coding with AI, you shouldn’t be wasting time on making your current codebase work, no matter what it is. Companies are burning tokens like crazy because they are trying to make their current solutions work with Clankers. This is not the way.

What you should be doing, is burning tokens… to reorganise your codebase into feature folders and micromodules. Small files. Some duplication if needed. Agent goes into one of them, implements something, nothing else breaks.

I’ve seen your codebases, guys. 1000+ lines of code in one file. Hand-coded or one-shotted by AI, doesn’t matter. “Shared”, “utils” folders everywhere. Connections that only someone who’s been digging in the codebase for years understands.

Whether you’re vibing, “agentic software engineering”, or pair programming… Whether you believe AI will replace the devs or not… We are not getting away from it. If your codebase isn’t easy for the agent to work in, your product is screwed. How to identify whether it is or not? Dunno, vibes. Read what agent does while trying to navigate it. Not the code.

Same applies for vibers. If you see agent getting dazed and confused, it’s time to reorganise the codebase.

“Let’s refactor the codebase into feature folders. Small files, around 300 lines each. Every file must do one thing well, if it does more, split it into smaller files.”

Run this periodically, especially when a new model drops. Because your projects will grow. This is the only way to avoid true slop.

Epilogue

Whatever you do and however you approach coding with AI… Stay humble. Stay hungry (and I don’t like Apple). Never claim you are a dev. You’re not. But don’t undervalue yourself like yours truly. I have a few mates on Discord who don’t believe I can’t code. Some say I ship more than devs that get paid to code.

You know what the difference is? They’ve got dev jobs. They’re employable.

While I’m here shouting at the sky about the future of software development, teaching them “the ways”, as if I was some sort of a Vibecoding End Boss.

I am.

But half of the shit I went through to get there will be obsolete in half a year, whether you believe Dario or not.

Originally published on: https://x.com/Howaboua/status/2047710779927924850?s=20