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:

1. 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.
2. 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.
3. 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.