My Opencode Workflow
As A Senior Engineer

​
Everyone's trying to replace themselves. I'm just trying to ship faster.

11 months ago, Dario Amodei said "AI would be writing 90% of developer code within 3 to 6 months".

I was the first to call BS.

And honestly? I still think the framing was wrong. But the tools moved fast enough that I had to change how I work anyway.

I didn't let AI write my code.
I let it assist. Build small, controllable features. That was the line.
Then OpenCode matured and somewhere between sub-agents, GitHub integration, skills, and coding from my iPad on the couch, that line moved.
Not because of hype.
Because (and I hate to be the bearer of bad news here:) the thing actually started working.

This is how I use it now, maintaining open source projects and building a side project.
No fluff.

One thread, one agent, one giant mess

Most people open a session, dump the context, describe what they want, and hope the model holds it together long enough to produce something useful.

For small tasks, this works fine.

For anything bigger, a new feature, a refactor, something that touches multiple files, it tends to either lose touch or just become too much for the human eye (and brain) to handle.
That can go in two ways - you push unreviewed slop and it breaks, or you push unreviewed slop and it breaks in the future (long enough for you to forget where it started).

You end up with code that looks right but doesn't fit the codebase.
Or worse, a half-finished implementation you have to untangle yourself - if you make sure to even review or QA yourself.
Let's not forget you've burned tokens the whole way through.

Then you see the other camp. People building "10-person AI startups" with a CEO agent, a marketing agent, a salesperson. Viral screenshots, empty repos. I've looked at this stuff. It makes zero sense to me, to put lightly.
​You know what? That's absolute crap and I bet no one actually runs production grade software at scale that sells.

The agent files are just empty prompt injections. Nothing actually stops any of them from going off script. It happened to me more than once.
The complexity doesn't add capability, it just adds noise and a bigger bill, unless, you start being the educator, the lead.

Small team, clear lanes, **constant tuning**

OpenCode has two agent types: primary agents that run the session, and sub-agents you (or the agent) call for specific tasks.

I use both, but carefully.

For most work, my main builder agent handles everything.
The builder has a small sibling - the planner which I never ever start a session without. It's the permission-less dude that is there to plan, suggest, ask questions and plan for the builder to take it forward.

And this, is where education starts: instead of using the default, I keep updating it's instructions and context. This doesn't mean it grows (that would be counter productive), but it's adjusted. Constantly.

​
For large features, I bring in a small squad.
⚠️ a small warning though: this is in test mode, I can't actually recommend this wholeheartedly without giving it a good long run, so take with a pinch of salt.

My team: a team lead that orchestrates, a product manager that only reads and maps requirements, a backend dev, a QA tester, and a separate code reviewer.

Each lives in its own markdown file with tight permissions and specific instructions.
Nothing fancy about them, and I would highly recommend creating your own by running:

The wizard will take you through required instructions and will create a structured agent for you.

The team lead delegates. The sub-agents execute.
I stay in the main thread and watch.

The structure isn't magic.
What makes it work is the constant adjustment.
After every session that I wasn't perfectly happy with how things went, I update the relevant agent markdown files, fix what went wrong, sharpen the instructions.
Treat them like living organism (sounds like my nightmares), not a one-time config.

Beyond agents, a few things that changed how I work day to day.

​Skills are loaded on demand, not baked into every context window. No point loading an AWS skill if you're not touching AWS.

You can now drag an image into the terminal (your emulator should be one that supports the feature - I run Wezterm and Ghostty) and have the agent read a design spec or a list of requirements.

​GitHub integration is real.
Drop /oc on any PR comment and it reviews, links the session, and flags issues without you ever leaving the repo.
Bonus tip - I'm currently using Opencode's beta model "big pickle" for these reviews as a secondary measure (plus, it's free), and I'm quite happy with it.

Open code also comes with a web interface. Which means I can `ngrok` it and use my ipad or any other device to keep working while AFK.

That's not a demo trick. That's genuinely how I, well 'work' isn't a perfect term, but 'make progress', from time to time on evenings.

Is it 90% of my code? I honestly don't know at this point.

But for large features, PR reviews, and anything I'd otherwise context-switch out of flow to handle, it's embedded in everything.

The bar isn't replacement. The bar is: does it save real time on real work.

For me, it does.

I hope this was valuable! Thank you for reading.

Feel free to reply directly with any question or feedback.

Have a great weekend!