The whole product team can use coding agents
This is an expansion of a talk I did for Portland AI Engineers in October. The gist of which was, coding agents are for the whole product team. Not just coders!
Once upon a time
Over 14 months of job searching, I tinkered and experimented with what has become agent coding or vibe engineering. My hypothesis was that, if the hype is real, nearly zero’ing out the effort required to type in code would drastically change how software teams collaborate.
In particular, anyone with a leadership hat (engineering managers, staff+ engineerings, product managers) would have more tools at their disposal. That could lead to better decisions earlier in projects. Fewer bad decisions right when making the wrong choice can generate costly path dependence and sunk cost problems.
I set out to reproduce how folks use coding agents to reduce the effort required to build software. This started with prompt-and-paste in ChatGPT and then Claude. The real moment of drastically reduced friction was the release of Claude Code. That’s when I jumped all the way in and found that perhaps the hype is not hot air.
Now the question, for prospective software projects, has become: can we go from “this is not a bad idea, on paper, should we put a team of software developers on it?” to “this kinda works, let’s move forward” or “actually, bad idea, never mind” in hours instead of days or weeks?
I think the answer is yes!
Coding agents – not just for coders
The whole product team can, and should, use coding agents. Leadership should consider updating how they work to include doing first-pass collaboration with coding agents to explore, develop, and validate their ideas.
For non-developers in particular, the potential is tremendous. It’s never been easier for those who can sling a little bit of prose to make code. More on how they might do that in a moment.
There are many qualifications to that statement, which I’ll get to forthwith.
You have to bring the right mental model, set expectations based on your own experiences, and try new things as your peers (colleagues and otherwise) demonstrate & validate new approaches.
Am I holding this right?
As they say in memes, You Have To Hold It Right.™️
(Pardon me for engaging in a bit of anthropomorphism here. It is incorrect to think of LLMs, bags of floating points masquerading as a slot machine that impersonates a human, as teammates. But, we gender ships and point at little objects and say “look at that cute guy/gal” all the time, so I think there’s precedent in this way of relating to our inventions and environment.)
Agents are a collaborative partner:
- That is available any time…
- …that you’re not over your token spend/quota
- That is often wrong…
- …but takes no offense at being corrected (in fact it’s already cliché how they respond with “you’re absolutely right”)
- Which recently learned software development…
- …at least, the thought process and basic tooling therein
Learning to collaborate with your enthusiastic partner
You have extremely energetic junior developers:
- Who are wrong half the time
- But, respond to feedback very well
- And, they get lost pretty often
The way you succeed is:
- Give them tasks to build up your confidence. Just like you would with a junior dev.
- Curate an environment that keeps them on the golden path. Just like you would to onboard new developers, help forgetful team members, automate formatting and idiomatic rule compliance, validate behavior, etc.
That is to say, collaborating with a coding agent is not that different from any other kind of collaboration. Set some guidelines, agree on a goal, build trust, iterate, and challenge each other to reach just a little higher every time.
Goals ✖️ guidelines ✖️feedback
The quality of an agent’s output is proportional to the quality of the goal you give them and their ability to stay within guidelines.
Goals are a matter of writing. I see folks succeeding in two ways:
- Give the agent short, specific goals/prompts. But, encourage them to ask questions (Claude recently added a tool for just this, it works pretty great!) and use their planning mode to get their context window in order before starting.
- Or, give the agent an exhaustive spec, often written with assistance from another “reasoning” model. Tell it to carefully implement one step at a time (lest they exceed their context window and go loopy).
What I’m calling guidelines, most folks call context engineering. Agents have a limited “memory” size (context window, 200K tokens for the good coding models) in which they operate with uncanny ability. They need at least half of that as working space to get the job with some degree of autonomy.
Deciding what to put in the remaining context window is a matter of strong preference. Here’s mine:
- Write a solid
CLAUDE.md. This is the “readme for robots”. Include the most important details about what the project is, how to run it, what the team standards are, and how to “learn more” by reading docs or searching the code. - In particular, instruct your coding agent to use tools like your favorite linter, formatter, running your test suite, executing the type checker, etc. to do good work. These feedback loops are crucial to prevent hallucination and let the agent run autonomously.
- Even more important: give instructions for how to “see” the program running. e.g. Playwright MCP, XcodeBuild MCP, Peekaboo, are important tools here. The longer an agent run its goal-seeking loop in its own, the better. The ability to run the program it’s working on and see if it achieved its goal, without human intervention, is where the uncanny magic really happens.
Delegate the work, specialize in thinking
Things are moving quickly in this space, but I feel confident saying humans in the loop will remain a requirement for the next several months, at least.
Agents forget, sometimes during a session. But you can solve this via CLAUDE.md and adding ‘memories’ to it. Or, tools and MCPs help too. There are even tools (like [bd]) to explicitly outboard the agent’s memory to task lists, not unlike a human might.
Helpfully, Claude Code has a /context command that tells you how much of your context window is in use and by what. Claude has a mechanism for compacting (think defragging your Windows 95 hard drive). When you’re running out of the context window, it’s helpful to know that is happening. These are the times you might have to remind the agent about standards and principles that were loaded way back in the beginning of the session. “Hey, don’t forget, lil friend, that we use K&R style function declarations!”
As with any tool, or human for that matter, the first days and weeks of working together are about building a working relationship and trust in each other. For coding agents, I’ve found that asking questions, then throwing speculative or well-defined tasks, is a good path towards developing a sense of when coding agents are useful and when they often miss the mark.
How should coders code with Claude Code 🥁
Quite a bit has been written about this angle, including your truly. I’ll keep this part short and concise.
Junior developers (and, as it turns out, experienced developers onboarding with new teams/stacks/systems) can use coding agents as ever-present peers or coaches. Ask the coding agent to explain how something works in the system or what unfamiliar syntax does. If blockers or confusion arise, try to explain the problem and see if the agent can generate useful avenues for troubleshooting your way out. When faced with a project or task which you’re not quite sure how to get started, ask for a few ideas of how you might implement it in this system and pursue the most promising one.
Senior developers should approach coding agents like a speculative productivity unlock. Burn through that backlog of ideas, bugs, and clean-ups. Sometimes the agent will get them right (or, close enough you can tap it in), others it’s a clean miss and it goes back on the stack. Or, you can use it to give you a first draft on features and fixes you’re not quite sure how to approach. Even better: a few first drafts, of which you pick which one to pursue.
Consider: if the time it took you to implement boilerplate and monotonous tasks went to zero, how would you approach getting more of them done?
For staff+ developers, coding agents are an even bigger agency unlock. They can help you brainstorm or tackle automating reproduction of weird, hard to replicate issues. You can build the control, operational, or runtime analysis tooling you’ve always wanted. Again, think about, if the time to build throw-away tools, of increasing complexity, went to zero, what would you do different?
Consider: your relationship to writing code is going to change. Your experience in what works well, where there are hazards, and intuitions on how to get things done are more important than your memorization of APIs and editor shortcuts now. Sorry. 🤷♂️
How should non-coders experiment with Claude Code?
Explore and prune the decision tree. Over years of working closely with product managers, I feel like a lot of it starts with making the best decisions about which potential solutions to customer problems are worth turning into proposals and projects for the software development team.
Consider: If the cost/effort of generating code went down, how would you approach that differently as a product manager or designer?
Turn ideas into prototypes, click around in them, decide if it’s a good idea or not. Work through the backlog of issues that are too small to prioritize but are an irritant nonetheless.
Show me some options. You’ve got a customer problem or feature you want to build, but you’re not sure how to go about it. Ask your agent to give you a few alternatives. I like to specify one should be conservative and one should come out of left field, the weirder the better. Product managers sharing options of how to solve a problem leaves room open for choosing based on scope and effort, rather than throwing us into another estimate, plan, and de-risk exercise.
Work through tedious/combinatory tasks. Rewording jargon in a spec, updating elements of a design system, sizing up how widely used a design token is? Coding agents are great at writing one-off code and scripts to handle tasks like these. Put ‘em to work handling the needful but tedious work you’re avoiding. 😉
In short
Writing is very important! It’s all prompting is. 🙃 Use your words, not too many.
Coding agents are always-on collaborators. Even if they don’t always generate the code of your dreams, they’re valuable for brainstorming and trying out changes with drastically reduced friction.
Give coding agents good goals (prompts), guidelines (CLAUDE/AGENTS.md), and tell them to use tools that keep them on the golden path.
Most of all: experiment! The worst that can happen, nearly, is you’ll write enough to have a clear idea of what you want to accomplish in your product engineering/design/management work but an agent can’t quite get it done. At best, you’ll have a better tool in your belt.
“So then the changes in progress are just there, ready to go.”
“How are they copied? A network sync, an on-disk copy? What about conflict resolution?”
“The data is available on disk and yeah, there’s a sync. Conflicts happen less often than you might think.”
“That’s not how computers work!”
That’s what excitement colliding with worn-in assumptions sounds like.
“So the developer finishes their branch, opens a PR, and then merges it immediately. Once they get feedback, they’ll address it along with whatever they’re working on next. Or a follow-up PR, if they’re working in a different area.”
“But what about foot-guns and project style and crucial but subtle feedback?”
“Yeah, sometimes we shoot ourselves in the foot. But most people only do it a few times before they start to work through it. The upside of getting code into production within minutes instead of hours or days is worth it.”
“You release un-reviewed code within hours of writing it? Multiple times per day? That can’t possibly work!”
Whenever you hear about another team doing something strange that you can’t even process at first, you’re glimpsing a team’s culture peaking through the white space. The more unfathomable or shocking, the deeper the assumption you’re pulling on. Team culture is repetition, that which is done without even thinking about it.
Assumptions seem like an immovable object, until they’re not.
When you hear about practices that rely on none of those habits and assumptions, it brings the whole thing into question. Of course, your initial emotional reactions are “that can’t possibly work” and “why would you even want to do that?”.
Right after “that can’t even” is probably a pretty big insight. If you’re up for it.
Every so often I find myself a few screens deep in an application’s navigation hierarchy and forget I can just pop out instead of going back to the top. I was reading feeds, decided I should do something else, but felt compelled to go back from the item view to the item list to the feed list to the very top of the hierarchy. Silly! I can simply stop reading feeds.
The same thing happens in writing apps: I’m working on a piece and feel like I need to “leave” the app at the very top, seeing all my well-intended but not0-quite-perfect attempts to organize and corral my writing.
I can quit an application from anywhere, not just the top screen!
Algorithmic feeds don’t exhibit this habit, despite presenting very little hierarchy, are worse for this. They actively try to keep comments, liking, sharing, etc. all in one endless view. There’s no “bouncing to the top”, just continual scrolling. Oof.
My habit is probably related to trying to keep as close to zero tabs open at any given time. Which is a great habit!
If we’re pairing or screen sharing, and you reveal a browser window with hundreds of open tabs, rest assured I’m keeping quiet on the outside but encouraging you to close several dozen of those tabs on the inside.
I’m on-board with exploring LLM and agent tooling to improve upon the whole endeavor of software development. But, I consistently find myself disabling Copilot/Claude/etc. completion and next edit prediction in Markdown files. This is the one way in which I’m “too cool” for the machines, the only area where I feel like I certainly know better than the little robot on my shoulder whispering probable next phrases in my ear.
I don’t want any help from the little slot machine of floating-point numbers embedded in my editor. Don’t tell me what I might wanna do or what I could do when it comes to writing, robot! 👴
Writing words, in a text editor, feels like the most creative and think-y activity of the coding regimen. It is a unique situation where I am doing actual invention, creating wholesale of a new cloth, building up from tabla rasa.
Which isn’t to imply that models and agents aren’t helpful for writing, generating ideas, and doing wholesale invention. I love starting with “bad ideas only” and models are superb at that! 😉
When sizing up a stranger, the advice I’ve heard in the past was to observe how they treat service staff: waitstaff, flight attendendants, concierge, etc. This one seems equally appropriate to the internet age:
To rapidly reveal the true character of a person you just met observe them stuck on an abysmally slow internet connection.
— Kevin Kelly, Excellent Advice for Living
If this ain’t a useful frame of reference for our time, I don’t know what is:
Regard for power implies disregard for those without power as is demonstrated by what happened after Moses shifted the route of the Northern State Parkway away from Otto Kahn’s golf course. The map of the Northern State Parkway in Cold Spring Harbor is a map not only of a road but of power—and of what happens to those who, unwittingly, are caught in the path of power.
— Robert A. Caro, The Power Broker
The self-taught amateurs can be weird, or make unorthodox moves that the formally trained can’t see:
“I don’t think it’s very nice,” Angela complained. “I think it’s ugly, but I don’t know anything about modern art. Sometimes I wish Newt would take some lessons, so he could know for sure if he was doing something or not.” “Self-taught, are you?” Julian Castle asked Newt. “Isn’t everybody?” Newt inquired. “Very good answer.” Castle was respectful.
— Kurt Vonnegut, Cat’s Cradle
Case in point: as I was using the revision mode in Ulysses to check this post, nine problems were identified. One misspelling, three incorrect hyphens (another sign o’ the times), and the rest were quibbles about syntax used in the quotes.
Let the experts cook, as it’s said of late.
A little voice in the recesses of my brain, the one that remembers of compiling Linux kernels and collecting WinAmp themes on university Ethernet LANs in the 1990s, is very happy to report that “obscure bit of syntax dot TLD” is still a very valid and fashionable sort of domain name for your programming blog.
Everyone is losing the thread. Maybe that’s what makes this moment in history so difficult to follow and frustrating to live in. Not just politics, and media, and our government(s).
- BMW lost the thread on their sports cars and classic design language.
- Apple lost the thread on great UI.
- JJ Abrams lost the thread on how to (finish) a Star Wars trilogy.
Maybe, somehow, Saturday Night Live only briefly lost the thread because the thread was, almost from the beginning, “did we ever have the thread?”
Maybe we should build more personal software in the text:
For navigation, the Cat featured leap keys: two rose-colored keys below the spacebar. You could press and hold one while typing a sequence of characters to “teleport” to the nearest instance of that pattern. The left leap key would take you back, the right leap key would take you forward.
User conventions emerged to support life within this system. Users would implement their own navigational systems using special characters, tags, “@keywords”, and consistent date and timestamp formats that would work well with the leap keys.
— Alexander Obenauer, Recreating the Canon Cat Document Interface
At the least, we’re probably over-indexed on scripts gluing files together, spreadsheets, and ideologies that expand into multi-hour courses.
The King Gizzard & the Lizard Wizard Rule: If you provide a text box for people to put things on the internet, you will eventually need some kind of moderation mechanism for people to opt out of the King Gizzard and The Lizard Wizard discourse without bothering the admins.
Many folks seem really excited about autumn’s arrival. (Pending, in more stubborn locales.)
Maybe the world is too much blasting, dismal, infernal summer lately.
p.s. Infernal! The double meaning/etymology makes sense now. 🧠
Taylor Troesh, Compressing Codebase Collocates:
To decompress a codebase, inline its paths of execution. For example, rewrite each endpoint of a webserver with only standard library functions and simple database drivers. One can repeat the decompression process all the way to bedrock machine code, but most programs accrue diminishing returns before that point.
To compress a codebase, recursively replace collocates with equivalent”zero-cost” abstractions. Don’t try to outsmart yourself — prioritize infrastructure for the most egregious repetition frictions of digital desire paths.
Writing code for compression/expansion is sticking around in my head. First, because the result seems concise and punchy, two of my favorite qualities in writing for humans.
Second, because there’s something organic and creative to the cycle of making something, trying to subtract the non-essential, adding to make more something, subtracting to improve the something-ness of it. Repeated cycles reveal more about what something actually is, often unknown to us at the outset or surprising when we discover its essence after many iterations or de-/re-compression cycles.
Dang old intellectual endeavors, sometimes they’re really something.
A blog post can just end.
Informality is an advantage, most days.
And, being an amateur.
We’re all terrified of being revealed as amateurs, but in fact, today it is the amateur—the enthusiast who pursues her work in the spirit of love (in French, the word means “lover”), regardless of the potential for fame, money, or career—who often has the advantage over the professional. Because they have little to lose, amateurs are willing to try anything and share the results. They take chances, experiment, and follow their whims. Sometimes, in the process of doing things in an unprofessional way, they make new discoveries. “In the beginner’s mind, there are many possibilities,” said Zen monk Shunryu Suzuki. “In the expert’s mind, there are few.”
– Austin Kleon, Show Your Work
I am told that you can enter thousands of words in a note attached to a task in Things. This seems like an esoteric and unconventional bit of trivia, Things being a task management app, not one of the likely candidates for a “second brain.” My pal Brian Bailey knows the exact number:
My to-dos in Things are often prompts to think and write, such as a post, short story, or planning for a new year. That’s when I normally switch to iA Writer. But recently, I started to wonder why. The to-do in Things usually has notes, initial bullet points, or maybe a draft intro. I often find myself switching back and forth between them.
— Brain Bailey, Focused Writing in Things
You’ll have to read the exact number in his post. 😉
Things is one of the apps I had in mind when I wrote about humble shopkeepers of software. It is, nearly two decades on, nearly complete software. I love that.
Would I love to see them go all the way and add notes, applying their characteristically well considered, high standards of function, form, and feel? Absolutely. Would it make it even harder for me to stick with a notes app I’m already using? Absolutely.
Am I a little worried they might slip and mess up something nearly perfect as-is? Also, yes.
I’ve found that there is an ebb and flow to how I use different tools. Sometimes, I want to consolidate to as few as possible, other times I love having one that specializes in each piece of the puzzle, like an outliner. For now, I’m enjoying going to Things for what’s next, then staying there to actually work on it.
Current status: trying to consolidate tools, so I waffle between them less often. I so want to be the person who is happy with only a few applications to do all of their things. Yet, I am, repeatedly, not that person.
Maximalism, I love you, your grass is always plentiful, and the greenest! Maybe uncanny in how lushly, deeply green it is. 🤔
Modern applications can’t hope to escape towering chains of complexity. Careful consideration of trade-offs and a bit of gardening are the way through.
If you don’t read, you won’t succeed.
– Tom MacWright, How to keep package.json under control
Possibly the best one-liner advice on managing dependencies out there. You might as well get good at understanding and mitigating the carried complexity.
The CSS rediscovery continues!
Then, a few years ago, I read a blog post by Josh W Comeau called My Custom CSS Reset. I realized that there’s no deep magic; everything a reset does is just normal CSS that you can read and understand.
— Jake Lazaroff, My Modern CSS Reset
I have only copypasta’d other folks’ (thanks, Eric Meyer) reset code, assuming it’s deep CSS tricks that I didn’t want to understand. But Jake’s is an easy read, particularly if you read through his post.
I suppose it kind of blurs the line between “CSS reset” and “classless CSS framework”. My goal isn’t really to adhere to a strict definition of either one; I’ve just found this set of styles to be a good starting point for most websites I build.
I love a good classless CSS framework. I did not have “more excited about CSS than JS” on my 2025 web dev bingo card, but here we are.
It’s no “for sale, baby shoes…” (spoiler redacted), but I like the feel of this short fictional invention:
From decades of reading The New Yorker, he had an extensive recall of the fabric that makes up the world. This recall, however, seemed exclusive to facts and anecdotes that led to an easy, repellent, or vulgar punchline about the minutiae that constitute the world. For this reason, it was most practical that around Thanksgiving, he was seated at the kids table.
If you’re keeping score at home, this is, IIRC, my debut as a writer of fiction. 🤔
Polyglot runtimes have arrived and fizzled throughout my stage whisper 25-year career. Supporting multiple programming languages without reducing them to an uninteresting lowest common denominator has proven wildly difficult.
That is, most multi-language runtimes are one of: “you can use any language, as long as you conform to Java-style OO”, “any language can run in a browser as long as it quacks like a DOM manipulation written in JavaScript”, or “bring your favorite languages, as long as it conforms to conventions invented for C sometime in the 1970s”.
It’s wild, to me, that the solution to “I want to re-use singular code that solves my problem but is not in the language I’m using” may end up being “use an LLM to rewrite it wholesale into your language of choice”. 🤷♂️
See also: LLMs are, themselves, weird little computation architectures.
📚_The Long Way to a Small, Angry Planet_, Becky Chambers
I’ve read three of Chambers’ books now and would characterize them as “comfy sci-fi”. In the best possible way! There’s a spaceship with many sapient species making up its crew. There are stakes and adventures, but they aren’t galactic in scale or epic in drama. It’s a nice reprieve from the cold-eyed intensity of, e.g., Herbert.
This one is a “found family” sort of outing. Our crew has a few adventures, but they are secondary to the relationships and connections formed. Again, it’s an enjoyable change of pace from what I normally read. I love a hero’s journey dotted with encrypted deck-of-cards messaging and “what if computers were exceptionally competent and evil?” plot lines. But I think it’s good to read about relationships and “what if birds and apes were sapient and worked together in deep space?” too. 😆