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.

In that order, every time.

I make a big deal about working downhill. Get stuff done, slice it smaller, get feedback, go again, remove friction, a little faster this time.

But let me tell you, none of that matters if it doesn’t come together and feel great once it’s all assembled in front of you.

When you feel it, you know. The feature makes you smile when you use it. It fits right in, like it was always meant to be there. You want to use it again. You want to tell people about it.

This is the difference.

— Mitchell Hashimoto, You Have to Feel It

Everyone loves a little faster, even if they say they want more function or nitpick on the form. But not everyone asks for it to feel great. That’s what distinguishes the good from the great and the great from the sublime.

Feel, fast, function, form. In that order. Every time.

It has to feel great, feel quick, have the right functions, and pleasing forms. In that order of importance.

I’ll excuse anyone if they’re not a transcendent genius who can create things exhibiting those qualities in that order and every time they sit down to build. But when you can get all four of those things together, even in small quantities, then you’ve got something special.

Feels great, feels fast, gets the job done, all the right affordances and embellishments. In that order, every time. You gotta try, at least.

The last 10% of any creative act is the hard part. (Previously: Finishing is a skill.) You had an idea, thought it would take X days, only to find X-1 days of all these other things that have to be done. That’s functional scope creep.

Finishing, actually getting the draft or project out of your computer and out into the world, that’s a whole other list of things. Lots of work, and surprises, are lurking here. Call it delivery scope creep. Or a finishing tax. And, it’s a mental challenge, getting over the “they’re all gonna laugh at you” fear. (But not in the Adam Sandler way.)

The more steps you can remove from putting something out there, the more you can put out there. (There’s always money in the shovel stand.) Ergo, the continuous development of new systems and tools to make online publishing easier, despite the market having excited for nearly three decades.

Related, the programmers’ credo: “we do these things not because they are easy, but because we thought they were going to be easy.” So goes software, so goes any other creative endeavor.

Writing words and writing code feel similar, for me. (And, playing a musical instrument, if I go far back enough.) They are equal parts mechanical performance, exercise of taste, and act of creation. For all of them, I want to be in a flow state. I want to go as deep as I can, time permitting. I want to hold a whole world in my head. I want to work among as many details, as deeply as possible.

Finishing, whether it’s releasing software or publishing an essay, reviewing code, or editing and revising words, are a different skillset. Differently creative, but still putting something new into existence. There’s a nice symmetry there. If you can get good at editing and revising words, you can get good at editing and revising code.

Getting over the last 90% of any kind of project, whether code or words or music, is the same skill.

It’s like the last 90% of anything is just a mindset, almost a resilience of mind. If you can get good at one, the skill carries over into anything that requires finishing.

It feels like life pulls a fast one on us, at times. “What got us here, won’t get us there”. Making the software, essay, or music is different from shipping, publishing, or releasing it. But if you can get good at any one of shipping, publishing, or releasing, you are considerably further ahead on getting good at the other two.

The winning scenario for agent-assisted code, design, science, etc. is humans having more time to do creative and impactful thinking because computers/LLMs do the tedious setup, easily verified work, and gather preliminary materials that humans turn into inventions.

FWIW, I don’t think the worst scenarios are likely. The future isn’t atrophying literacy rates or people turning off their brains to tell LLMs what to do. It’s probably not Malthusian job scarcity or Keynesian leisure abundance, either.

The best outcome, IMO, is that producing almost-good-enough software, design, science, etc. is possible for more people, particularly those without specialist degrees.

You won’t have gym owners producing billion dollar SaaS companies, but they might produce software good enough to run their business without needing to contract out to a software developer.

You won’t have software developers producing the same level of design and art direction you see in major films. You might see them producing design good enough and sufficiently distinct that they can wait to bring a designer on until they’ve found their market.

You won’t have writers discovering new axioms of math and science, but you might see them correctly apply statistics and physics so that stories about finance and space battles are slightly more realistic.😉

In short: experts in topic A won’t find themselves held back by having an idea that requires expertise in topic A and topic B, where topic B is too deep for them to “just get good at”. Fewer Wozniaks will have to find their Steve Jobs, fewer Springsteens will have to find their Landaus.

It won’t exactly be you can just do stuff. But, perhaps you can get far enough along that collaborators to fill in the specialties you don’t can find you.