Grilled and shipped; how Dunc runs his AI agent

Almost every month at Kyan, someone on the team does a mini talk about how they approach their craft or a new piece of tech that has tickled them. This month it was Duncan, talking us through how he runs his Claude Code setup. Here's what stuck.

Your config is a decision, not a default

Most people install a tool and never go near the settings again but Duncan isn't most people. His config file gets tweaked constantly, because the defaults are built for everyone, which means they're built for no one in particular.

Two changes are worth noting immediately. First, turn off the little ‘Built by Claude’ signature it likes to leave in commits and pull request descriptions. Second, opt out of the session URL it quietly tries to bolt on. Both just add noise to a codebase that has enough noise already.

He also strips out anything he doesn't use, workflows, remote control, AI connectors, the lot. Every one of these gets described at the start of every single conversation whether you ever touch them or not. Turn off what you don't need and the model starts each chat with less to guess about.

Watch your context window

Here's the bit that surprised me. A big context window isn't free. Every message you send gets sent again with the whole conversation stapled to the back of it, and the model gets noticeably worse at using the middle of a long chat, favouring what was said at the start and what was said most recently. It's a bit like trying to remember the middle third of a long SXSW conference talk. You've got the intro and the bit right before everyone starts clapping, and not much else.

Duncan's rule of thumb is to reset around 20% of the window. Push much further and you're paying more tokens for a worse answer, which is a rubbish trade by any measure. Two tools help here. /compact shrinks the current conversation. /handoff summarises everything into a fresh session so you're not dragging dead weight forward. His status line even shows the context percentage in colour, green through to a bold, unmissable red, so he knows when it's time to flush.

Trust the tool, but put a fence around it

Anything that can run commands and read files on your machine needs boundaries, and Duncan's are nice and simple. Hooks block dangerous shell commands before they run, and block reads into folders like .ssh that have no business being touched by anyone, human or otherwise. There's a whitelist script checked every single time, standing guard.

On top of that, he runs sessions inside a sandbox, so a conversation about one project folder can't wander off and start nosing through unrelated parts of the filesystem. Access gets granted deliberately, never by default.

From nebulous idea to buildable ticket

This was the part I found genuinely interesting, because it's not really about AI at all. It's about how a rough idea turns into working code without anyone pretending they knew the answer from the start.

It begins with conversation, not a prompt. A ‘grill me’ session is just a chat where the model asks you questions until a raw concept comes into focus. ‘Grill me with docs’ does the same thing but reads your repository first, so it understands what ‘record’ or ‘publish’ actually means inside your specific codebase, rather than just guessing.

Matt Pocock's agent skills, including grill me, are worth a look

For anything bigger than a single concept, there's Wayfinder. Instead of jumping straight to a ticket, it breaks an unclear feature into smaller conversations and, where it helps, working prototypes. On one project, that meant eight separate brainstorming threads before a single line of the real feature was written, ending in a technical spec and a bunch of small, buildable tickets instead of one enormous, scarey one.

Only once a ticket is small and well defined does implement take over, writing a failing test first and building until it passes. That last part has nothing to do with AI whatsoever.

Test and test again

If you're working in a technology you don't fully know, and these days that's most of us most of the time, a passing test is one of the few things you can actually trust. Not a confident tone of voice. Not a tidy explanation. A test that either goes green or doesn't.

Duncan makes sure every project has fast, easy test commands from day one, so both he and the agent can check the work independently rather than taking anyone's word for it, including the AI's. It's a good discipline even without an AI in the house, but it becomes essential the moment there is one.

Keep the docs light

One thing the whole team agreed on, without much debate, is that the deep, evolving conversation about a piece of work shouldn't live inside the codebase itself. Keep it in the issue tracker instead, where it sits as a running commentary a pull request can point back to. The README stays clean and lean and doesn't point at anything too specific, because specific links decay as soon the code changes, and the code always changes.

And if you're tempted to dump a pile of AI generated subtasks into a tool like Linear, don't do it. It generates too much noise.

Why we keep doing this

None of this is fixed, and Duncan would be the first to say so. This is what's worked for the last couple of months, and it'll look a bit different again soon enough. That's why we keep having these sessions. The tools are moving fast enough that comparing notes once a month together in person, beats watching another YouTube video or reading another stack of docs.