Code with AI

AI is not another library

People say generative AI is a tool. Fair enough. But every tool that ever entered a developer's life came with documentation, and was built around how we already think. Compilers, debuggers, package managers, IDEs: they bent toward us.

AI is different. It asks for a fundamental shift in how we think about software.

It also arrives without a settled handbook of best practices. Accomplished users share their own scrolls about the truths they discovered. Those are fragments of a broader picture we have not mapped yet.

In the future, there will be an Uncle Bob of vibe coding™ who collects the fragments into a bible we can all humbly follow. Until that day, all we can do is experiment.

Much of this applies across tools. The feature set is fairly standardised: agents that read files, edit code, run commands, and pull in context. I use goose, Cursor, Claude Code, and Codex in different situations. The habits below travel between them.

I started with CodeCompanion in Neovim in summer 2024, when GPT-4o was still the default — see the r/neovim thread. I will update this article with new findings. It is fascinating how much work humans put into the goal of working less.

Context

Context is what the agent already has in its head. Smaller, sharper context reduces cost and increases precision.

Context can include:

• business knowledge about the project
• code snippets from existing files
• technical boundaries
• rules for how it may extend its own context when necessary

That last one is where the clusterfuck is waiting. You have to define thoroughly what AI is allowed to look up, and make up.

Never let it invent the specification

Not because it is bad at inventing. Because you will be alienated from the outcome. You do not notice until it is too late.

1. Invent the whole vision of how things should work.
2. Dump your thoughts as they come.
3. Turn them into a structured document. Markdown is ideal.
4. Fine-tune the document by hand until you find no holes in the logic.
5. Do not let AI negotiate itself simpler, easier requirements. When it hits a wall, it will suggest a simpler approach to avoid the problem. Never say OK before you read the whole specification again. We tend to forget why we made certain decisions.

Let it invent the technical details

By contrast, let it invent the technical details. Don't be arrogant about this, and don't be over-parenting. The goal is a maintainable product that serves its specified purpose. The level of maintainability and long-term thinking belongs in the specification. Define those boundaries, then let it work freely inside them. That is why you use AI at all.

When you build that frame, detail things like:

• Fault tolerance: when something unexpected happens, should it sit down and cry (alert a human operator), or try to recover?
• Stability vs bleeding edge: some software is made once and left alone for decades. Other software is updated daily. Which one are you building?
• Network surface: will it be connected to the internet? Will bad actors reach it?
• Sensitive data: any juicy stuff in the database you do not want ending up in a breach? Consider an extra layer of encryption. Define and confirm who holds the key.
• Audits and marketplaces: will the final packaged software face an audit? Android and iPhone app markets are notorious for detailed technical guidelines.
• Performance and compatibility: hard requirements, preferably with hardware and OS information.

Of course, agents also learn bad patterns from the internet. It is fine to define some do's and don'ts — but only when you notice them. Do not mention sins it never committed. You might just give it an idea.

Different models also make different mistakes. Remember: AI is incredibly good at role-playing, and it picks up clues implicitly as well. If you junior-style over-explain things, you will trigger impostor syndrome. I have made incredible performance increases simply by removing lines from prompts written for older models.

Most of the work is reading

Communication is bidirectional. The bulk of the work for us is not writing. It is reading and understanding.

Out of the box, AI is incredibly bad at explaining — especially the GPT family. Their sugar-coated version of reality competes with the one Pyro had in Team Fortress 2.

In contrast, DeepSeek is composed, short, and honest. But it's not about the model.

The goal is to:

• keep the conversation focused
• decrease your cognitive load

Every turn, the model re-reads the whole conversation and mimics its own way of writing and “thinking.” Consequently, keeping its communication style clean is not cosmetic. It is essential.

Some rules I use:

- Short, direct. No adjectives, no marketing.
- Radical honesty — state gaps directly.
- Bullet list input → bullet list output.

I also make it add cynical jokes that outline the absurdity of certain situations. If I spend my whole day reading the output, I might as well enjoy it. Humor keeps attention alive. The contrast it provides sharpens judgment.

Memory

Memory is textual information injected into a conversation before any work starts. That text has higher priority than what comes after, and in Cursor it often sticks even much later in the conversation. There is project-specific memory, and there is global memory.

In other words: memory is context, predefined, so you do not have to rebuild it for every new session. In most tools you can enter something like:

remember globally to communicate in a short, direct manner. No adjectives, no marketing.

And it works. remember locally… works the same way; “local” means the current project.

Build memory gradually, and review it frequently. You will recognise many records that sit there and never seem to have an effect, so you have to reword them. That is also a closed-loop way to practice prompting: after a little time shaping preferences in memory, you get a feel for how to structure sentences so they stick across every decision the model makes.

Read everything

I totally get why people do not read what AI tells them. Often it is rubbish. But after you teach your preferred style of communication, you run out of excuses. Read everything it writes. Be humble. Role-playing goes both ways. Here is a prompt for you:

You are the human operator of an AI agent.
Your role is to make up your mind,
specify your desires about the product clearly,
and read and judge everything the AI agent outputs.

That's it.

Your short-term memory is tiny. Every time you recall something from long-term memory, your brain invents parts of it, then stores the slightly altered version. Logic is also, as far from human nature as it gets.

But our aesthetic senses do more than help us enjoy beautiful things. They signal when something is off. We are great observers. Use those aesthetic senses on AI output. This is what we bring to the table. Our real edge over AI.

Burn the context

We spend a lot of time building context. Paradoxically, the best thing you can do with it is burn it and start a new one. Long conversations are costly as hell, and the reasoning gets dumber as well.

When the context limit is reached, Cursor compresses the conversation so the show can go on. Ideally, do not reach that threshold, and instead, burn the session.

• If the next change has no direct relation to the work you just did, burn it.
• If the context was accidentally polluted with a big, meaningless file, burn it.
• If tool calls fail frequently, burn it.
• If you want Cursor to refactor, review, or test critically, burn it. One session does the coding and happy-path testing. Another does the review and critical testing. Just like humans do.
• If it forgets the initial boundaries and specification you gave, burn it. AI does not forget as much as it ignores. Ignorance comes not from lack of interest, but from lack of capacity to grasp every important detail. Just like with humans.

Important! If you use Cursor in the terminal, do not just close the terminal window. Press Ctrl+C. Otherwise the session can stay in memory indefinitely, eating precious RAM in high volumes.

Examples

The easiest way to explain what you want is to provide examples of things that already exist. Be careful, though: when the agent reads those examples, it will pick up every detail — including potentially harmful or misleading ones.

Consequently, explaining what is intentionally left out — the negative space — matters just as much as explaining what is present.

Git

Handle git yourself. Ideally, do not let AI touch version control except when resolving conflicts. In that case, make sure it understands both sides of every colliding change, then have it ask you about each meaningful decision while it keeps consistency across the files. You keep judgment. It keeps the mechanical merge coherent.

MCP

Load the fewest MCP servers you need for the current session — preferably only what the task requires. They are huge bloat: they add token cost and deteriorate the model's capacity for detail.

MCPs save me from an astonishing amount of manual work, but every MCP server that can communicate with the outside world is a liability. Always enable them consciously, and do not forget about them.

Browser testing works surprisingly well. Use it before manual testing. Let the agent click through the flow, catch the obvious breakage, then verify what still needs human eyes.

Models

Use models for their own purposes. Leaving Cursor in Auto mode works out well for cost and quality most of the time. Auto is no longer a vague “pick something.” It is powered by Cursor Router: a classifier that looks at the query, context, task complexity, and domain, then routes the request to a model that fits. Routine edits go to cheaper, faster models. Hard, long-horizon work goes to frontier ones. You steer the tradeoff with optimization modes — Cost, Balance, or Intelligence — instead of babysitting every model switch by hand.

Token waste is also mechanical. Tools like RTK (Rust Token Killer) compress noisy command output before it hits the context window. Skeletonisers such as rtt give the agent a compact map of signatures and structure instead of whole file bodies. Graph-aware selectors like ContextDiet keep only the code reachable from the task at hand. Use them when the repo is large and the agent keeps drowning in irrelevant text.

Lifestyle

Sit up straight. When was the last stretch of time you were not staring at a screen?

When you get effective at this way of working, you will soon notice that you run multiple agents in parallel. Let's be clear: you do not do it for throughput. You do it so you don't get bored. We can keep only so much in our heads at once, and there is a minimum threshold as well. Vibe coding is a different kind of flow state, but it has its own rhythm. Multitasking is part of that rhythm.

Have a way to write down ideas and tasks quickly. After a while, you will instinctively draft prompts you can copy-paste when you get to a computer. Be careful, though: notice when your mind is still working even though it should not be. Writing ideas and todos down is a good way to prepare for rest. Once you dump the thoughts, the unconscious treats them as dealt with and lets you live in the present.

For me, Google Calendar todos worked best. You can set a reminder for the exact moment the information is needed, and you can add a detailed description. There is a temptation to write these notes as perfect prompts. Sometimes they come out that way naturally. Do not force it. You will sort through the text before you execute it anyway.

Done right, this style of working is actually quite addictive. It also takes a lot out of you, which you have to replenish.

Modulate caffeine. It makes people impulsive, and this work needs you concise, deliberate, and calm. Long coffee or tea is better than spikes. Prep for a reading session, not a sprint.

Taking breaks matters more than ever. Burn the session. Clear the context. Do something else. Space out — preferably without screens.