From code production to outcome ownership

For most of our careers, the code and its effect on users were welded together: the only way to get an outcome was to personally produce the output, and output was slow and expensive. So teams optimized output — lines shipped, tickets closed, PRs merged — and measured themselves by it.

That coupling is breaking. Agents are very good at output and improving quickly. What they are not good at is deciding which output is worth producing. Agents produce output; you own the outcome. That isn't a downgrade — owning the outcome was always the valuable part, just buried under typing.

Context: two problems behind Kody

A concrete case makes the abstract advice cheaper. Kody is a SaaS built after years of mainly producing educational products, and it exists because of two issues that surfaced after going all in on agents.

First, agents are too expensive for recurring work. An agent controlling the shades in a house worked, but paying for inference every time you want to open the blinds is silly — that's a job for a small deterministic program, not a language model reasoning about window coverings. The better pattern is to spend inference once to create durable software and run that software cheaply forever. Kody is where that software lives.

Second, automations get trapped. Every agent platform wants to host your integrations, memories and automations; set everything up in one and you're stuck, or you set it all up again in the next one. With Kody, Kody is the home and the agents are guests. It doesn't compete with Claude, Cursor, Devin or OpenAI — it lets all of them share and reuse the same durable software.

That second point was hard to explain, and the early positioning was all over the place. The version that landed: your agents share and reuse durable software without lock-in. Arriving at it wasn't a coding problem and no agent would have handed it over. It was outcome work.

A shipped feature, no implementation written by hand

Kody packages can declare webhooks, and while building one you want to know it works before real traffic arrives. People were testing webhooks with awkward workarounds — a signal worth listening to. The feature was built live, with no editor session: the agent was treated like a sharp teammate who knows the codebase better than the author does.

Shared understanding, then options

Before asking for anything, both sides agreed on the problem: who hits it, what they're trying to do, what "done" means. Skip this and the agent confidently solves a slightly different problem than the one you have.

The next ask was not an answer but a few options, each with rough effort, trade-offs, and whether it is a one-way door (hard to undo) or a two-way door (easy to change later), plus a recommendation and reasoning. Two-way doors can be walked through quickly and handed to the agent; one-way doors — public API names, data shapes, pricing — are where you slow down.

The decisions

None of these are code decisions:

  • Ship the smallest useful slice: a synthetic dispatch through Kody's MCP and API surface, invoking the webhook's handler directly with a fixture the user provides. That answers "does my handler work?" for agents, where most of this testing happens.
  • Defer the UI test button. Nice to have, not what unblocks people today, easy to add later.
  • Defer a true end-to-end ingress dry run. Valuable but much bigger; the smaller slice answers most of the real question.
  • Don't promise what we can't keep. The first instinct was "dry run," but the handler is real code that can call real services, so no promise of side-effect freedom — and no name implying one.
  • Synthetic runs count against usage. They consume real compute; making them free would quietly break the unit economics.
  • Name it carefully. webhookDispatch sounds like it sends real webhooks; webhookSyntheticDispatch says what it is. Capability names are public API, a one-way door.

The agent wrote the implementation, the tests and the PR. Automated gates and AI reviewers checked the work, and it shipped to production before the Q&A ended: kody#2594. The diff was not read line by line. What was read was the outcome: does it do what was decided, and did the trusted gates pass? That is only reasonable because of what was set up beforehand.

Collaborating with agents

  • Shared understanding first. Context before commands, every time.
  • Ask for options with trade-offs and a recommendation. You want the agent's thinking, not just its typing.
  • Ask questions instead of micromanaging. "What would break if we did X?" gets further than a ten-step instruction list. Dictating every step means doing the agent's job instead of your own.
  • Keep skills small. One focused skill beats an overstuffed one; agents follow small, clear instructions far more reliably.

The human work

Decide what should exist

  • Treat workarounds as product signal. Repeated hacking around something is an unwritten feature request — how the webhook feature began.
  • Don't be a ticket translator. Rewriting a product request into instructions for an implementer is agent work now. The valuable part is deciding whether it should be built at all, and what it should actually be.

Design the playground

  • Build good primitives. Agents are only as good as the building blocks they get. With the right primitives you can hand over a job instead of a massive spec. See the talk Thinking in Primitives.
  • Automate shipping where risk is low or medium. Well-structured PRs, tests and AI reviewers let many changes ship without you in the middle. Save attention for high-risk, one-way-door work.
  • Isolate secrets. Agents should be able to use credentials without seeing them. Non-negotiable once agents act on your behalf.

Watch the outcomes

  • Build self-healing automations. Things break; make failures get noticed and triaged (often by another agent) instead of silently rotting.
  • Know your metrics and unit economics. "It works" isn't the bar; does it work at a cost that makes sense? The usage decision for synthetic dispatch is a small example.

Note what is absent: framework choice matters less than it used to, and frontier versus local models for a given job is a practical trade-off rather than an identity. Those are output-level choices, and agents are increasingly good at navigating them with you.

Where this leaves your career

Invest in judgment and outcomes. Get closer to the people using what you build. Practice making trade-offs out loud and explaining why. Get comfortable being accountable for whether something worked, not only whether it shipped. Agents write code; the most valuable and most human work is deciding what should exist, how it should behave, which trade-offs are worth it, and which primitives will make the next round easier.

The post grew out of a talk at a Distillery Tech Night with the React Buenos Aires community. If you've been on the fence about giving a meetup talk: you learn a lot by explaining what you know to a room, and it's a good way to find out what you actually think.