Well the well has gotten weirder 🐸.

Intro to 🐸 view

If you haven’t read the last one, 🐸 View is my opinion from the well I exist in. Take it with a grain of salt or a whole salt mine 🧂. I don’t care.

This time I want to talk about something that has genuinely changed how I work: AI agents and the workflows around them. Not the hype. Not the “AGI is coming” bullshit 🤡. The actual, practical, “I shipped a POC in an afternoon instead of a week” kind of change.

The workflow trilogy

Planner, Coder, Designer

Over the past few months, I’ve settled into three agent roles that mirror what a small team would do:

  • Planner 📋️: Breaks down a feature or POC into steps. Takes the vague idea and turns it into something actionable. No code, just structure.
  • Coder 🛠️: Takes the plan and builds it. Writes the actual code, tests, configuration. The hands.
  • Designer 🎨: Handles the visual side. Layout, styling, component decisions. Makes things not look like shit.

Each agent has its own system prompt, its own context, its own job. They don’t step on each other. When I need a feature, planner goes first, coder follows, designer cleans up. It’s like having a tiny team that works whenever I want and doesn’t complain about meetings 🤡.

Why this works

The big unlock is context isolation 🧠. When I used a single chat window for everything, it became a mess. Too much context, too many tangents, the model would start confusing requirements. Splitting roles means each agent only carries what it needs.

POCs that used to take days now take hours. Feature implementations that would stall on scaffolding or boilerplate just move. I spend my energy on the interesting parts: architecture decisions, edge cases, the stuff that actually needs a human brain.

The fear 👻

Here’s the part nobody talks about enough: when things don’t work, you’re not always sure why. You read the output, it looks plausible, you ship it. But there’s this constant low-grade anxiety 😰. Did the agent hallucinate a config value? Is this error from my code or from something the model invented? When you write every line yourself, you know where the bodies are buried. When an agent writes half of it, you’re walking through a graveyard with no map :tombstone:.

This hits hardest during debugging. Especially CI/CD.

The CI/CD hell loop 🔥

I spent way too many commits recently trying to get a deployment pipeline working on a side project. The commit history tells the story better than I can 😭. Commit after commit, each one a tiny fix that should have worked but didn’t:

  • secret variable not being picked up by the runner
  • whitespace in version strings breaking shell parsing
  • YAML indentation issues because the formatter and the runner disagreed
  • registry authentication failing in unexpected ways
  • a build step that worked locally but exploded in CI because of environment differences

Every single one was me and an agent going back and forth. Agent suggests a fix, I push, CI explodes in a new and exciting way, agent suggests another fix, repeat 🔁. Each iteration is a full commit-push-wait-fail cycle. It’s slow. It’s frustrating. And half the time the agent is confidently suggesting fixes that make no sense for my actual setup.

The agent doesn’t know about my environment quirks. It pattern-matches from docs and examples that don’t quite apply. That gap between what the model assumes and what reality is? That’s where the pain lives 🤯.

The CI/CD debugging tax

When you’re debugging CI/CD with an agent, there’s an extra layer of indirection. You describe the error, the agent reasons about it, you apply the fix, you wait for the pipeline. If you’re lucky, it works 🤷. If not, you describe the new error, and the cycle continues.

This isn’t a “don’t use agents” argument. It’s more: know which battles to fight yourself. For CI/CD, the feedback loop is already slow 🐌. Adding an agent in the middle makes it slower. Sometimes you just need to read the damn logs yourself.

Strategies that actually help

Clean boundaries 🧱

The best thing I did was define what each agent owns and what it doesn’t. Planner never touches code. Coder doesn’t redesign the architecture mid-stream. Designer doesn’t rewrite business logic.

When an agent stays in its lane, the output is predictable. When it doesn’t, you get spaghetti that looks confident.

Right model for the job

Not every task needs a top-tier model. Not every task can survive a lightweight one.

  • Planning and architecture 🏗️: bigger model, more reasoning. Worth the tokens.
  • Boilerplate and scaffolding 📦️: lightweight model. Fast, cheap, good enough.
  • UI polish ✨️: mid-tier or higher. Lightweight models make ugly things 😒.
  • Debugging complex issues 🐛: honestly, sometimes no model. Just you and the code.

The cost difference is real. Running a big model for everything is burning money 💸. Running a small model for architecture is burning time ⌛️. Match the model to the ambiguity of the task.

Opencode: the glue

What it is

Opencode is the tool that makes all of this possible. It’s OSS. It’s simple. It doesn’t try to be everything 🌈.

At its core, it lets you define agents with system prompts and tools, then orchestrate them. You can chain agents, pass context between them, and control what each one can do. No vendor lock-in, no subscription, no “enterprise plan” bullshit.

The web portal 🌐

One thing that surprised me is how useful the web portal turned out to be. I switch contexts a lot. Multiple projects, multiple agents, multiple conversations running in parallel. The portal gives me a clean overview of everything: which agents are active, what they’re working on, the conversation history.

It’s not flashy. It doesn’t need to be. It’s just a browser tab where I can jump between workflows without losing state. When I’m bouncing between planning a feature, reviewing code, and tweaking styles, not having to juggle terminal windows or remember which session had what is genuinely a productivity win 💪.

Some tasks feel better in the terminal 🖥️. Some feel better in the browser. Having both and being able to switch freely is the right call.

Global vs Local agents 🌏️ 🏠️

This is where opencode really shines and something I didn’t appreciate at first.

Global agents live at your user level. They’re available across every project. Things like a generic code reviewer, a commit message writer, a changelog generator. Set them up once, use them everywhere. Saves you from copy-pasting the same agent config into every project like a chump.

Local agents live inside a project’s .opencode directory. They know the project’s specific context, conventions, and quirks. Your planner, coder, designer agents? Those are local. They need to understand the tech stack, the folder structure, the weird legacy decisions nobody wants to talk about 😬.

The combo is what makes it work. Global agents handle the boring universal crap. Local agents handle the project-specific brain work. You don’t want your code reviewer carrying project architecture context. You don’t want your project planner reinventing how to write a commit message. Clean separation, clean agents, clean mind :lotus_position:.

Opencode zen

The thing I respect most is the philosophy. Pick your model. Pick your tools. Pick your workflow. Opencode doesn’t force a way of working, it enables yours.

The model choices are genuinely open. Bring your own API keys. Use what makes sense for your task and your budget. No black box, no “trust us we’re doing magic.”

Skills and orchestration

Building skills in opencode is straightforward. Define what the skill does, give it a prompt, tell it which tools it can use. Orchestrating them is equally simple: one agent’s output becomes another’s input. It feels like Unix pipes but for AI workflows 🔌.

The developer experience is clean. You write markdown files. You configure in YAML or JSON if you want. No GUI. No bloat. Just files in a directory that do exactly what they say.

The future 🔮

Things are moving fast. Not AGI fast, but practical fast.

Agents are getting more capable at staying in their lane. Orchestration tools are getting better at context management. The model quality is improving while costs are dropping.

I think the next big shift is agents that can actually observe their own output. Right now, an agent generates code and hopes it works. The agent that can run the code, see the error, and fix it without you in the loop? That’s where this gets interesting.

But also terrifying. Because the debugging problem I described gets worse, not better, when the agent is fixing its own mistakes without telling you.

The well is getting deeper. Or maybe wider. I can’t tell anymore.

Conclusions

  • Split your agents by role. Planner, coder, designer. Clean boundaries save sanity 🧠.
  • Accept the fear. You won’t always know why things work or don’t. That’s the trade 👻.
  • CI/CD debugging with agents is a special kind of hell. Sometimes close the chat and read the logs 🔥.
  • Match the model to the task. Lightweight for boilerplate, heavy for architecture, your brain for the hard stuff ⚖️.
  • Opencode is the real deal. OSS, simple, no bullshit. The way tools should be built ❤️.
  • The web portal is low-key one of the best features. Context switching without losing your place 🌐.
  • Global agents for universal tasks, local agents for project brains. Don’t mix them 🌏️🏠️.
  • The future looks like agents that can see their own mistakes. Exciting and scary in equal measure 🔮.

Until next time from the well 🐸.