Make Your Coding Agent Opinionated | by Brooke Jamieson | May, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

Make Your Coding Agent Opinionated

Brooke Jamieson

8 min read·<br>5 days ago

Listen

Share

Brooke Jamieson | Senior Developer Advocate, AWS | Last updated: May 12, 2026<br>I’ve been using coding agents daily for over a year across Kiro, Claude Code, Cursor, and Codex. Over that time, the thing that’s improved my output quality the most has been writing my team’s coding decisions down in a file the agent can read. This post covers how to do that across each of those tools.

Press enter or click to view image in full size

The best engineers I know are also the most opinionated people I know. They have strong views on error handling, on when you should reach for an ORM versus writing raw SQL, on whether the latency win is worth the cost, on what makes a good name for a function. They’ll argue about those views with you respectfully, because those opinions came from years of getting burned by the alternative.<br>So it makes sense that developers aren’t usually happy with what coding agents produce out of the box. These agents don’t really have opinions. They give you whatever was statistically most common in the training data, which I’ve started calling the Stack Overflow median.<br>Better models and cleverer prompts have both helped at the margins over the last year. What’s made a much bigger difference for me is writing down what my team believes about good code, somewhere the agent can read it.<br>Why does my coding agent ignore team conventions?<br>Because your agent doesn’t know your team has any. It only knows what’s statistically common across the code it was trained on, which is a fairly mushy average of every decision anyone has ever made in public.<br>A coding agent knows forty-seven ways to implement auth, but your team already picked NextAuth v5 six months ago and wired up a specific session pattern in src/lib/auth.ts. It will happily use default exports even though your team moved to named exports last year because the refactors were less painful. Route handlers full of business logic look fine to it, even though you long ago decided DB access only ever goes through src/lib/db/ for reasons that made sense at the time and still do.<br>When the agent does any of those things, it isn't failing at a technical task. It's doing the only thing it can do with the context available to it, which is limited to the code in front of it and whatever was in its training data. The reasoning behind "NextAuth v5 with this session pattern in that file" is invisible to the agent, because that reasoning lives in people's heads, in code review comments that got resolved and buried, in a Slack thread from last quarter, and in the instincts of whoever's been working on the project the longest.<br>Being a developer has always been about tradeoffs , and there are usually a lot of them at play at once. Speed against cost is the classic one, but you also have to decide how much flexibility you're willing to trade for consistency, whether resilience is worth the complexity it adds, and so on. There are always a lot of ways you can build something. Choosing how you should build it requires context about what your team cares about and why, and models don't have that context unless you hand it to them.<br>Why do coding agents start from zero every session?<br>Because the context window resets and nothing carries over unless you’ve put it somewhere persistent. An unconfigured coding agent is a bit like the most technically capable junior you’ve ever hired, except they never make it past their first day.<br>When you onboard a brilliant new hire, they write code that works perfectly but uses patterns your team moved away from a couple of years ago. Sometimes they make a decision that’s technically sound but contradicts an architectural choice the team made for reasons that aren’t visible in the codebase. You flag it in code review, they update the PR, and a few weeks later they’ve absorbed enough of the team’s preferences that their code just fits.<br>Your agent goes through the same process, but every session starts over. The comment you left on yesterday’s PR, the design call from last week, the rule someone posted in the engineering Slack channel. Unless it’s somewhere the agent actively loads, the agent hasn’t seen any of it.<br>What should my team agree on before configuring an AI agent?<br>Your team’s actual opinions, before you get anywhere near the file format. Most of them are probably implicit and nobody’s written them down.<br>A few questions that tend to surface the useful stuff:<br>“How do we decide between speed and cost when we’re designing a new service?”<br>“What do we actually mean when we say ‘keep it simple’?”<br>“Why do we reach for X over Y? Can we write down the reasoning?”<br>“What’s our default when there’s no clear winner between two patterns?”<br>Most of the answers exist already, scattered across old...