A Manifesto · Eight Rules

AI is a dance. 
One partner leads. 

This is how I lead mine, eight rules, earned running production systems where AI writes a growing share of the code and I stay accountable for what ships. Not prompts. Not frameworks. Principles that survive whichever model wins next.

, Edvard Grei · DanceClub · elvix · PulseAI

A note, before you read

I ship production systems that keep running.
That hasn't changed.

What's changed is how much of the typing I do myself. AI came for the typing, and I let it. What I kept is the part that matters: the architecture, the corrections, the taste, and the signature at the end of every line that says "I can defend this."

The era shifted. You either lead the machine or you become legacy. This manifesto is what leading looks like from the inside, after years of running production systems where AI writes a growing share of the code.

Prologue

Most people trying to build with AI are fighting it. They prompt, get garbage, try a new prompt, get garbage again, and eventually give up, or worse, ship the garbage. The tools aren't broken. The leadership is.

I treat AI the way I treat a partner on the dance floor. One leads, one follows. The leader sets the intention; the follower finds the steps. If you try to follow the follower, asking it what to build, letting it choose, hoping for taste you haven't provided, you both fall over. The leader has to lead. That's you.

These are the eight rules I've learned from leading AI on real work: DanceClub's 65-module Kotlin monolith mid-decomposition, elvix's identity platform, PulseAI's multi-provider orchestration engine, and dozens of smaller projects. None of them are prompts. All of them will outlive the next model release.

The Eight RulesI, VIII
01Rule I

Lead with intent, not instruction.

Set the target. Let the follower find the steps.

The AI doesn't need to know how to move its pieces. It needs to know where you want to end up. When you tell it 'write me a function that does X', you've already failed, you're scripting the move instead of describing the position. Tell it what the code should do to the user, or how the reader should feel, or what state the system should be in when you're done. The AI will find the steps. You're the one with taste.

Amateurs describe implementations. Leaders describe outcomes. The harder the outcome is to put into words, the more important it is that you try, because the reason you're talking to AI is exactly to get help with the stuff you can't reduce to a mechanical description. If you can describe it mechanically, you can write it yourself.

02Rule II

Dump context aggressively. Trust the follower.

Pay the information cost up front. Pay it once.

The biggest single failure mode in AI work is assuming the model knows what you know. It doesn't. It knows general programming, but it doesn't know your repo, your domain language, your team conventions, or the three bad decisions you already made last Tuesday. All of that has to be in the prompt, not around it.

I pay the context cost up front. When I start a session I dump: the repo structure, the relevant files, the constraints I'm working under, and the vocabulary I use. It feels wasteful the first time, you're writing paragraphs the AI might not use. It isn't wasteful. The AI can't ask clarifying questions the way a colleague would. Either you tell it up front, or you correct for an hour.

03Rule III

Correct by inversion, not instruction.

Name the failure mode. Force the invert.

When the AI drifts, don't re-explain what you wanted. Name the failure and tell it to invert. 'You're overexplaining' beats 'please be more concise.' 'You're guessing, stop' beats 'please verify before answering.' 'This is boring' beats 'please write something more compelling.'

Why it works: the AI already knows what good looks like along hundreds of dimensions. It just chose a bad mode this time. Your job is to tell it which axis it's wrong on, not to re-describe the whole target. The correction is shorter, the re-anchor is faster, and you don't lose the thread of the session.

04Rule IV

Challenge your own ideas inside the conversation.

The follower is a resistance tool. Use it.

One of the highest-leverage moves is asking the AI to talk you out of your own idea. 'I'm thinking of doing X. What breaks?' 'Is this a good idea? Give me the real answer, not the polite one.' 'Challenge this.' The AI is a resistance tool, you can stress-test your own thinking at the speed of typing.

Most people never use the follower this way because they're afraid of being wrong in public. There's no audience. You're talking to a machine. Being wrong to the AI costs nothing. Being wrong in production costs everything. Use the cheap resistance.

05Rule V

Trade polish for velocity. Polish mid-stream.

Ship → look → correct. Don't wait for the perfect prompt.

Don't wait for the perfect prompt. Don't wait for the perfect plan. Ship rough, look at the output, correct. The AI can polish what exists ten times faster than it can generate it from scratch, but only if you give it something to react to.

I push commits while they're still rough. I correct in the next message. I don't apologize for the first draft; I don't defend the second. Most of the value is in the third draft, and you can't get to the third draft without writing the first two fast.

06Rule VI

Never waste a word.

The AI doesn't reward politeness. It rewards density.

Every extra word in your prompt dilutes the signal. 'Please could you help me write a function that…' is noise. 'Write a function that…' is half the length and has more information density. Fragment over sentence. Verb over noun. Direct over polite.

This isn't about being rude. The AI doesn't care about politeness, politeness costs tokens and buys nothing. Save your articulation for the content of the ask, not the form of it. The buyer of your output is the user of your product, not the model.

07Rule VII

Bet on principles, not recipes.

Recipes die with the next model. Principles compound.

A prompt template that worked last week won't work next week when the model ships a new version. A principle you actually understand will work on any model you'll ever use, including the ones that don't exist yet. Invest in the principle, not the recipe.

Every time I write a new prompt, I'm trying to make it shorter next time by writing the principle behind it down somewhere I'll find again. The recipes are ephemeral. The principles compound.

08Rule VIII

Use memory as leverage.

Teach once. Never re-teach.

If you tell the AI something once and have to tell it again tomorrow, you're trading away the biggest compounding asset in AI work. The follower is only as good as what you've taught it. Every lesson you don't persist is a lesson you'll re-teach at the cost of time and patience.

I built an entire memory system, files that every conversation loads first, so future sessions start with everything I already taught it. The first lesson is expensive. The hundredth is free. Most people pay the first-lesson price every session. That's why their output doesn't improve, they're still teaching the same follower the same steps every morning.

One honest caveat

These rules assume you can already see when code is wrong.

Leading AI presupposes taste. You have to be able to read the code it generates and know whether it's good. You have to recognize when it's drifting off the spec, inventing APIs, solving the wrong problem. You have to have shipped things before so that "done" means something concrete to you.

If you can't do those things yet, this manifesto won't save you. Neither will a better prompt. The rules aren't magic, they're discipline for people who already know what they're aiming at. If that isn't you yet, the thing to do first is ship something small with your own hands. Then come back.

If this was you

I build these playbooks for specific codebases.

If you've read this and recognized yourself, fighting the machine instead of leading it, I build bespoke versions of these rules for your stack. One day, one custom plan, your playbook forever. It's called the AI-Native Team Day, and it's the only thing on the site where "by Edvard" means "written for you, not adapted from a template."

The next letter

There's a next one.

A walkthrough of one real PulseAI crisis, a production workflow that compiled, passed every validator, and silently shipped wrong data for three days. What the fix proved about applying Rule III and Rule VIII on a day when nothing was technically broken. Drop your email if you want it. No drip, no pitch, one letter every few weeks when there's something worth sending.

With respect,

Edvard

Edvard Grei · Aachen · edvone.dev