I used to think getting more out of coding agents meant writing better prompts. Sharper wording, more detail, a cleaner brief.

That’s part of it. But in practice, the prompts I write are often just a file path and an instruction. What does more of the work is the structure around the conversation: a real source of truth, a defined audience, some tone guidance, sensible boundaries, and a concrete job to do.

Getting those five things in place has done more for output quality than any individual prompt improvement.

The myth of the perfect prompt

A lot of advice about AI tools still revolves around the idea that there’s a perfect prompt waiting to be found. If you phrase things just right, the model will become precise and reliable.

Sometimes better phrasing helps. But most weak outputs aren’t weak because the wording was slightly off. They’re weak because the task was underspecified, the source material was unclear, or the model was being asked to invent structure that should have come from me.

The shift that’s helped most: stop treating the prompt as the whole job.

Five things I put in place before I start

1. A source of truth

The model does better when it has something real to work from. That might be a repo, a config file, an existing post, a failing test, or a rough draft that already contains the facts.

My habit is to point at files rather than paste content. Instead of dropping a block of text into a prompt, I give the model a path and let it read. It can see the frontmatter, the surrounding project structure, and the full context without me curating any of it. That shifts the conversation toward interpretation, editing, and implementation. That’s usually where the good work happens.

2. A clear audience

“Write a post about this” is much weaker than “write this for builders following the project” or “write this for potential users who want to understand what improved.”

That audience cue changes what gets emphasised, what gets cut, what level of detail matters, and what tone feels natural. The same facts can produce very different writing depending on who’s reading.

3. Tone guidance

Tone guidance means something specific: a usable writing posture.

For my weekly project dispatches that usually means: specific, reflective, honest about tradeoffs. Explain what changed, why it mattered, and what comes next. Grounded in the product.

That kind of guidance is more useful than asking for something “good” or “engaging.” It gives the model a shape to aim at. For writing I repeat often, I keep that guidance somewhere reusable rather than re-explaining it from scratch each time.

4. Boundaries

A surprisingly large share of prompt quality is really boundary quality.

Say what to preserve. Say what should stay factual. Say whether to edit an existing draft or start fresh. Say what should not be invented.

A lot of agent mistakes aren’t intelligence failures. They’re scope failures. Clear boundaries catch a surprising number of them.

5. A clear job

The model does better when the task is framed as a real job rather than a vague request.

• “Review this post for AI-writing patterns and rewrite it in my voice.”
• “Remove the CV-like phrasing from this page.”
• “Summarise what changed in a way a user would care about.”
• “Review this refactor for regressions and tell me which assumptions look risky.”

Those are better working instructions than “improve this” or “write something about this.” The job description does a lot of the heavy lifting.

Build the structure once

The best ratio I’ve found for my own work: significant setup, minimal invocation.

If a task repeats, I’d rather define the structure around it once than rediscover the whole conversation every time. That might mean a memory file, a skill, an AGENT.md, or a reusable workflow that already carries the tone, constraints, and expectations.

Then the prompt itself can stay short. The useful context is already there.

That works better than trying to write a clever paragraph every time I open a new session.

A good example is the weekly writing workflow for this site. I do not ask the model to invent an article from nothing. I first gather a factual base from the work itself, then decide what matters, then rewrite for voice and emphasis. Splitting those steps has been much more reliable than trying to do all three at once.

Feedback on the problem, not the solution

When a draft isn’t right, I try to describe what’s wrong rather than prescribe what to change.

“The tone is a bit smug” is more useful than “change the third paragraph to say X.” “Tell me which assumption in this refactor looks risky” is more useful than “change function X to Y.”

Describe the problem and you get a collaborator. Specify the solution and you’re doing the thinking yourself, asking the model to execute.

The catch is that this only works if I can read the output well enough to name the issue. That’s its own skill, separate from prompting.

Separate the phases

One thing that works especially well for writing: separate factual generation from editorial judgment. Gather the material first, then decide what matters, then rewrite for voice and emphasis.

Asking the model to discover facts and shape narrative at the same time usually produces something that does both jobs badly. Splitting the phases makes each step more reliable.

Where I’m still improving

I’m not a perfect user of these tools. The places where the process still breaks down are worth naming.

I often discover my constraints late. I see the wrong version first, then realise what I should have said up front. That’s still one of the most common reasons a session takes longer than it should.

I sometimes compress too much into a single instruction. I know what I mean, and the model often gets close enough, but some conversations improve immediately when I split the request into parts: what matters most, what to avoid, and what a good result should look like.

And I rely quite hard on editorial instinct. That helps in revision, but it makes the process less repeatable. If I want consistent quality without close review every time, I probably need to externalise more of that judgment into clearer rubrics.

The honest summary

The prompts I’m proudest of aren’t the cleverest individual messages. They’re the workflows I’ve set up so the useful work happens once and compounds: files that carry context, reusable guidance, clear job descriptions, and enough structure that each new conversation doesn’t begin from zero.

That’s less romantic than prompt wizardry. But it’s what has worked best for me.