Actually building with AI

My OpenCode workflow for turning messy ideas into working products

Last week I gave a presentation at Vibe Code Fest about my workflow for building products with OpenCode.

As I shared with the audience, this workflow is not only for OpenCode. You can apply the same principles to Claude Code, Codex, or any other coding agent. The tools change, but the principles (and skills) remain.

So this is basically the written version of my talk. I hope it helps you improve your workflow, adapt some of the skills or tips I share, or at least gives you a few ideas that can lead you to improve yours.

There are many tools and many ways to work with them. I don’t think there is a perfect workflow, or a one-size-fits-all workflow either.

So here’s mine.

Context is everything

Context is the most important thing for coding agents.

Trash in, trash out.

And even if Anthropic or OpenAI advertise 1M-token context windows, the reality is that there is a big difference between a fresh context window and one that is already at 80%.

When the context is fresh, there is less noise. There are fewer irrelevant files, fewer assumptions, and fewer attention relationships for the model to deal with.

As the conversation grows, noise starts to appear. Maybe the agent loaded files that are no longer relevant. Maybe it made assumptions that were later changed. Maybe there are old decisions in the chat that no longer matter.

LLMs do not read context like a database. They are probabilistic. And as context grows, the chances of wrong assumptions also grow. The agent starts making decisions I didn’t really want it to make.

So I try to keep my context windows fresh.

After working with GPT and Opus over the last few months, I have noticed quality starts to degrade around 100k to 120k tokens. Because of that, I try to keep my sessions around that limit.

But 100k tokens are not enough

Obviously, 100k tokens are not enough to build a product.

A real product is going to take more than that.

So it’s super important to persist the important stuff outside the session: assumptions, decisions, coding styles, product requirements, and anything else the agent will need later.

Those things should live in markdown files that any agent can reference at any time, in any session.

That is the foundation of the workflow.

Going from 0 to 1

With that in mind, let’s start at the beginning.

How do I go from 0 to 1?

This can mean starting a new product, adding a new feature, fixing a bug, or anything like that.

When I start, I’m usually sure of one thing: I don’t know exactly what I want.

If I want to build something new, I usually have a vague idea of what a good first version looks like. Before, I would just send that vague idea to OpenCode using plan mode, hope it created a good plan, and then execute it to see if the result was actually good.

Most of the time, it wasn’t.

Then I would spend a lot of time iterating with the agent until I finally got something good.

That changed when I started using Matt Pocock‘s /grill-with-docs skill.

This skill helps with the problem of not knowing exactly what I want, or not thinking through important considerations before building. I share my vague idea with the agent, and it literally interviews me with a bunch of questions. It does not stop until the agent and I are aligned.

The end goal is simple: the agent and I should have a shared understanding of what is that we actually want to build.

If it’s a new product, it will ask me about product decisions, stack decisions, assumptions, limitations, and basically everything in the design tree.

For example, if I say I want to “add search” to a database, it might ask whether I want basic search or semantic search. If I answer semantic search, it might ask what model I want to use for embeddings, where I want to store them, how results should be ranked, what data should show in the UI, whether I need pagination, and a lot more.

If I’m working on an existing product, it will read important files, understand the stack, and interview me based on the current state of the codebase and the feature or fix I want to add.

I imagine it like this: building a product is moving from point A to point B.

With regular plan mode, I often started building the road before fully understanding the terrain, or even where A and B really were.

With /grill-with-docs, I first analyze the terrain. I try to understand where A actually is, where B actually is, and what is between them. Then, later, I build the road from A to B.

Turning alignment into a PRD

At this point, I know the terrain. I know where A is. I know where B is.

So how do I build the road?

TLDR: I use the /to-prd skill.

This one is also from Matt, and it reads the grilling session and turns it into a document that highlights the problem statement, the solution, user stories, implementation decisions, and more.

It is like a plan with steroids.

At this point, I will probably be around the 100k to 120k token range. And because I don’t want to implement the feature in the dumb zone, I start a new session and ask the agent to work on the PRD.

Plan mode is an option here. But most of the time, my PRDs already have the important implementation decisions captured, so I go directly into build mode.

And most of the time, it works really well.

The agent has a fresh context window, a clear PRD, and almost no noise. That is when I usually get the best results.

What happens when the context gets full again?

But then I’m back at 100k tokens, and the agent is only on task 4 out of 8.

What do I do?

There are some alternatives. I can use the native compact mode or I can ask the agent to summarize the conversation.

I use another skill for this called /handoff, which is also from Matt haha.

It is basically compact mode with steroids.

It asks me to define the purpose of the handoff. In this case, the purpose is to continue working on the product, following the PRD.

So I usually say something like:

Hey, /handoff the work to a new agent.

Then it analyzes what has been done and generates a compact but meaningful document with everything the new agent needs to continue. That includes the current state, the remaining work, important decisions, and even the skills the next agent should use.

Then I start a new session, give the agent the handoff, and get high-quality output again.

That’s the workflow

And that’s it.

I have found myself one-shotting a lot more with this workflow. I even did live (vibe) coding at Vibe Code Fest in front of a lot of people, and it worked. We even deployed live!

So yeah, attention context is all you need.

If I had to summarize my workflow, it would be this:

Use /grill-with-docs and /to-prd to create a shared understanding of what you want to build. Keep context windows below 100k tokens. Use /handoff when you need a fresh agent to continue the work.

You can find Matt’s skills here: https://github.com/mattpocock/skills

Thanks, Matt!

That’s my workflow for actually building with AI.

What’s yours?