Before Writing Code with AI

How we write code has fundamentally changed with AI in the mix … blah blah blah.

We’ve all heard that.

So, I’ll jump straight to the point.

There are lots of ways to code with AI, and a lot of new things to learn, but this article will focus on the one thing I think is the most important foundation.

Sharp or dull

You’ve likely heard a variation of the following story before.

A general goes to war with his army, but all his army’s got are spears.

A salesman approaches the general with a machine gun, but the general is quick to dismiss him.

I don’t have time to talk to a salesman ...

Well, that’s seemingly silly.

The machine gun would have won him the war.

This analogy is apt when it comes to coding with AI. A lot of us (from my experience) plunge into writing code with LLMs without talking to the salesman.

Why not?

The Salesman

I’ve got nothing to sell you in this short write-up.

Analogous to the salesman is spending time to configure your AI agent to output code like YOU.

I didn’t say to get an LLM to work better.

No.

To output code like you.

That’s the point.

You can’t expect a probabilistic machine trained on the code written by millions of developers to magically understand how YOU write code.

There’s a very low probability of that happening, the more opinionated you are about writing quality software.

So, your taste, your idiosyncrasies matter (I like to order module imports by length, for example - weird, I know, but that’s me.)

Otherwise, you spend more time tweaking and editing the output code. A bigger waste of time.

Cursor, Claude Code, Gemini … Doesn’t matter

We won’t get into a battle of what’s best.

I personally don’t care. I have my favourites, but it doesn’t matter right now.

I find myself using different tools at different times.

What matters?

Configuring them to work like you.

Here’s what to do

Every tool’s got its flavour of some document you can pass to the agent to tailor it to you.

The biggest mistake you can make is treat this as optional.

It shouldn’t be an optional requirement.

At least not if you’re serious about your time - LLMs outputting code I spend hours reviewing and could have been faster doing on my own, is the equivalent of “you name it”.

I call it a massive waste of time.

Now, find that document: AGENTS.md, CLAUDE.md, Cursor rules, whatever it is, and spend time working on it.

Remember spears and machine guns?

Don’t squint at the idea of spending time to work on something that’ll drastically improve your productivity.

How to actually write your instructions

First things first, I’ll assume at some point you’ve written code you’re proud of, or that signifies how you want or like to write code/structure programs.

Or perhaps you have strong opinions on how programs should be structured.

Pick an advanced thinking model. Damn the cost at this point.

Use any dictation app if you wanna be faster (you can also write), and tell it to do the following:

Please take a look at the attached file(s). It represents the implementation of a complex [XXX] feature. 

Your task is to codify the principles under which [XXX] has been built into a short document, less than 200 lines, that any AI agent can follow to replicate the method here. 

Now, this is extremely important because not following these principles is a waste of time. I want an AI agent, especially when asked to develop [XXX], to follow these principles to the T. 

So, here are some examples of the rules that have been followed in the attached directory.I'm going to tell you how I approached things, your task is to codify them. You take the information I give you now, you look through the code files, and you codify the principles.


# [Comment: Now I dictate some of the principles. To bias the model into looking at specific things]


The first, and perhaps the most important thing [....]

Now another point is [...]

Now beyond that [...]

Take the principles I've explained, look through the implementation in the file(s) one more time, and codify these principles in a .md file that should live in [XXX]. Please be detailed, but remember to be concise. These are rules that should be codified accurately without vague or unnecessary sentences.

This prompt is not overly optimised. You could come up with something better; this is just what I dictated this morning (about a week ago, before publishing this) to write some new rules.

The most important thing is to codify your way of working.

Keep sharpening

For me [XXX] in the prompt was about frontend engineering. It’s the branch of software engineering where I have the strongest opinions and also where I think AI falls short or is too bland for my taste.

After creating the first document, if you’ve used an advanced thinking model as prescribed, you should have a great starting point.

Treat it as that. A good starting point.

Give it a good read, edit, and be content with it.

It should represent you. Your taste.

Now every time you ask an AI agent to do [XXX], when its done, you review the code (as I hope you do, regardless)

During review, you’ll find things missed.

This is where you correct by updating the doc.

I typically write a prompt like Why did you do YYY instead of as described in the doc JJJ, this gives you insight into what wasn’t clear and a precise pointer for what to update.

It’s common for different models to act in different ways.

The best-case scenario is your doc works perfectly for all models.

However, if it doesn’t, instead of creating different docs, I personally prefer keeping things simple.

One doc, shared across different tools, even if it means adding more info to the doc so it’s clearer to a less capable model I frequently use.

Whatever your guidelines make sure it includes …

When in doubt, ask questions and await my approval before continuing. Do not assume. Simply ask me, and I'll confirm what to do

The above will save you a lot of time and cost in wasted tokens.

Conclusion

Before doing what I wrote here, I’d initially copied some general instructions from other engineers on Twitter… this is a mistake.

You can use those as a starting point, but don’t make the mistake of not making it yours.

There’ll be a lot to learn/unlearn in the next few years as software engineers.

Regardless, the foundation of it will be getting AI to output software like YOU.

Until it all becomes pointless, if we ever get there.