# My Opencode Workflow As A Senior Engineer - Channel: [DevOps Toolbox](https://www.youtube.com/channel/UCYeiozh-4QwuC1sjgCmB92w) - Published: 2026-03-13 - Source video: [Watch on YouTube](https://youtube.com/watch?v=UhRGHr7pgnU) - Read on ReadTube: https://www.read.tube/p/videos/UhRGHr7pgnU - Language: Original (source language) ## Summary **Mastering OpenCode: A Senior Engineer's Workflow** This video explores how OpenCode has evolved into a highly customizable and powerful coding agent that integrates across a developer's entire workflow. By utilizing sub-agents, specialized skills, and multi-platform support, the author demonstrates how to build an autonomous team of AI engineers to handle complex tasks while maintaining security through just-in-time tokens. OpenCode has evolved into a comprehensive, highly configurable AI-driven coding system that operates across terminal, web, and GUI environments. Rather than relying on a single AI entity, the workflow leverages primary and sub-agents to break down complex projects, improve accuracy, and reduce hallucinations through task-specific specialization. - Utilize modular sub-agents like plan, build, and code reviewers to handle distinct project responsibilities and improve performance. - Implement just-in-time security tokens instead of static API keys to mitigate risks when agents handle sensitive credentials. - Manage agent logic and prompt instructions through localized markdown files to refine performance over time. - Integrate external tools and plugins via the skills ecosystem to perform specific actions like GitHub PR reviews or complex dev-ops tasks. - Improve the development experience by using integrated GUI or web interfaces for cross-device accessibility and image-based context processing. ## Article 11 months ago, Dario, Anthropic's boss, said that in 3 to 6 months, AI would be writing 90% of the code software developers were in charge of. Are we there yet? Well, when he said that, I was the first to call BS. He speaks out of position. Drama makes news. And to be fair, 11 months, eternity in AI advancement pace. I did not let AI write any of my code. Assist, sure, build small controllable features. Absolutely. But today, not only I've set a team of AI engineers to build complicated tasks, I've built them, including a bunch of skills and other options into Open Code, the best coding agent in existence. There's a video on the channel covering the basics of it. But this was 6 months ago. Since then, Open Code has matured big time. You can now control sub agents, follow their work, install skills, control every bit of the system with motions, integrate it into GitHub, use images, and even do this. Never thought I'd use my iPad to code. And if that's not enough, check out the AJ just casually running Open Code on his site. Don't worry, I'll get to everything in this video covering exactly how I use Open Code in 2026 at work maintaining open source projects and building a side gig. With over 100,000 stars, Open Code is the de facto leader when it comes to coding agents. It's no longer that terminal coding option, but a system that can run as a full-blown GUI, run on the web, your ID, and of course, the terminal. But as with every big project, it starts with a small fuming drama. Open code started as a terminal AI agent built by one developer on his spare time. Dax and Adam, popular devs, joined him, helping advancing the project and even getting the opencode.ai domain. Charm, the known terminal open source projects company, showed interest and offered all three positions, effectively asking to acqui them into the company, while the first dev agreeing and Dax and Adam refusing, saying they want to keep open code what it is, open without VC backed money, which normally leads to some type of monetization and not necessarily having users interest in mind. To make a long story short, this was mainly around the name. Dax tweeted this post about the way he sees things, mentioning he and Adam didn't care about the code and actually rewrote open code from scratch. Anyway, Charm CEO responded with how they see things. And if you want the community's opinions, well, just read the comments. The links are below. Again, to make a long story short, Charm's agent, a beautiful project if I must be honest, is known today as Crush still holding Dax and Adams commits in the history if you look deep enough. Okay, drama aside, Open Code used to be a side project under SSD and is now under a larger umbrella called Anomaly holding SSD, Open Code, Openoth, and other projects backed by Y Combinator, Max Levchin, one of the founders of PayPal and others, which kind of does bring VC money to the table, maybe with more dev control rather than being part of something they aren't in charge of, and that I can appreciate. We're here to get our hands dirty. The open- source agent integrates with any model, can be installed any way you like. With its new features, it's now suggesting one of these, which I highly recommend, either westerm or ghosty. You'll see why it's so nice to see the growing popularity of miz, which is another run option for open code. We'll get into configuration thoroughly, but as expected from the team behind it, it's fully customizable and configurable through `opencode.json`, which can be project specific, global, and even overwritten with envir. I'll skip the install bit. Once open code is ready, you'll see a bunch of interesting options from MCP through create, which is a cool little wizard helping you build an agent step by step. There's also an option to serve a headless Open Code server, run a web instance, show stats of all previous users, and a lot of cool stuff, which we'll soon see. Okay, let's get cracking. Open code fires the TUI with a context of the current path to embed it visually into your terminal. Just align the themes and there we go. The next thing you'd probably want to do is pick a model. I have Claude here both through Zen anthropic along with others but more importantly an interesting model by the name Big Pickle which is a model by open code free to use at the moment and if you're okay with it training on your data I'm using it as my open source bot I'll show you how in a bit other notable free options are Miniax which according to Enthropic is a Chinese LLM basically drinking data off of clothes so you be the judge a minute about Zen for those who haven't watched my first video Zen is Open code router allowing you to put your credit card once and get access to a list of tested and verified models, putting it in the team's words. Not happy with Claude drinking your tokens? Switch to Codeex or Gemini or dozens of others. And if you're adventurous enough, like this guy? Maybe even give Kimmy a go. He actually claims Opus is slower than Kimmy for most stuff he built. Anyway, we're off track. Pick your model or Zen and move on. Oh, important. Open Code aren't looking to profit from Zen. They charge you credit card fees at cost and nothing beyond that. Whenever you have less than $5 in your balance, they'll just recharge another $20, which with clothes can happen every hour. My god, I wish I was joking. Once picked, you can start engaging with your agent. Every session is stored for you, and you can use `/sessions` to find them in the history. A notable change made recently was moving from JSON, holding the sessions to a full-blown DB running on SQLite, making the experience way snappier than it was when searching, filtering, and popping back into sessions. This database, by the way, is available to you by running `opencode db`. Not sure why you'd need that if you're not building on top of Open Code. The DB, unless told otherwise, is stored at `local/share/opencode`. A session holds the entire history, context window, active model, and everything else as if you've never left it. I find myself using it constantly in starting new sessions only when working on a completely new feature unrelated to previous work. Our next top and the first major building block of Open Code is agents. Open code has two kinds primary and sub agents. The two primary you have already noticed are `plan` and `build` basically differing in permissions where `plan` can only read and well plan but not execute even if told so. In previous video and probably in many others you've seen people go nuts with agents. They have a builder, a deep builder, a marketing guy, a salesperson. And if you think I'm joking while I believe this tweet like I trust OpenAI are making the world a better place, people actually are trying to build crazy stuff like that. And to me, this makes zero sense. Not only it's just empty files, and while I've built something small, I do think separation has merit here. It's just beyond me. I have a plan and a build and one more agent that solves my complex work, big features, and stuff that require a more robust system with a structure. Sub agents are the specialized one you can call for specific tasks and will run in the background. Open code has two of them. The general sub agent can execute and explore is mostly for reading. Typing at will allow you to invoke/tag the sub agent you need which can be either done from here from the prompt or from the primary agent instructions. The example from the docs shows the build plan and code review sub agent that cannot write but has instructions to review with focus on security and performance. Your config to set them is at `.config/opencode`. You'll find a bunch of directories here like agent command and skills. But the simplest way is to pop `opencode.json` and set them there. When you restart, you'll see a new code reviewer and you can call it at your disposal. To make this code review sub agent even more interesting, I'm using a tool I've shared before called `gh-` to preview PRs. I have a key binding that sends a new T-Max window, creates a work tree with work trunk, another video on the channel that you'd want to watch, and pops open code with a prompt or we can just run it and tell our code reviewer to do its thing. It's one of those automations that make you feel like you're making yourself obsolete. Similarly to that code reviewer, you can add others like a security engineer which you can start forming communication by telling your code reviewer to delegate security tasks to the other guy. Now, here's where it gets really interesting. And honestly, this is why I think adding a security engineer makes even more sense when you pair it with what I'm about to show you. See, every single one of these agents we're building, at some point, they're going to need credentials, API keys, tokens, database password. You get the point. And here's the thing that keeps me up at night. Most of us, we just dump these keys into environment variables or config files and call it a day. But that is a massive security hole waiting to happen. Think about it. If your machine gets stolen, if someone finds that lit key in a public repo, if someone social engineers their way into your CI pipeline, it's game over. That static key lives forever. and so does the access it grants. This is where Dcope comes in and why I'm integrating it into open code. Instead of static keys, you get what's called JIT, just in time tokens. Your agent requests access. Dope verifies who you are, issues a shortlived token, and that token expires after a few minutes. This changes the entire security conversation around agents, building all these amazing sub agents and skills. But if they're walking around with permanent keys, we're just creating more targets. So when you add that security engineer sub agent, give it to disco. Your future self will thank you. If you do decide to build your own agent, run `opencode agent create`. It'll show a wizard asking description of what the agent is for. You'll be able to set permissions interactively and then define it. A primary, a sub agents or and that's a new one or both available as a primary agent, but also one you can tag later and delegate tasks to. The beauty in the generated result is it lives in a standalone file, a full-blown instruction plan with examples, context of the raw principles, guidelines, edge cases, and how you'd like to see output. Okay, let's not get carried away here. Yeah, this isn't really a full-blown model custom trained to do what they're told. All it is is some prompt injection, and its quality is totally dependent on you. And even if it is high quality with guidelines and all, nothing other than a set of permissions is actually fully stopping the agent from breaking script and going around them happened to me more than once. Use with caution. So why would you even consider something like that? I'll get into more details soon, but basically this separation helps with one less hallucinations. The more specific the task, the less mistakes the model makes and the better it performs. So these sub agents are a great way to break down tasks and instructions. And two, it makes things easier to track. You'll soon see how the main thread we see as users is the parent agent. And this brings me to my last important concept. Something that's relatively new with coding agents and with open code specifically, skills `/skills` will actually come up empty at first. I've added here a couple. The first of which is the more critical skill, giving your agent the power to locate and install skills autonomously. Your other option is finding a list like `skills.sh/sage` and look through tens of thousands of open source options built for different tasks. But be warned, there's a lot of junk here. There's also SkillMP built by Manis, which seems to be a meta company. It's claiming to have almost half a million skills available. And yeah, I know I sound a bit antagonist here, but this level of exponential growth with AI skills does feel like well AI generated skills. If you pick something, a good idea is following a trustworthy home like Versel. Grab the `npx` command and follow the wizard asking whether it's relevant to a specific model or provider, whether it's global or project specific, etc. Once installed, you can call your new skill. In our case, searching and installing. In case it wasn't clear, skills beyond all the complicated fancy explanations are just another form of prompt injection. The idea is that they're not loaded to every context window like a prompt or an agent's MD file. They're there to be used on demand. No need for the AWS skill if I'm not touching the platform. They help guide, connect, and use many other tools and can come with scripts and code examples. Here's a DevOps engineer skill that has a `skill.md` file giving it a name and well text instructions. There are references to other files like GitHub actions or Kubernetes for this engineer, but all of these are just code references and stuff that the agent could have probably found searching online. The cool thing I like most about these is the work other people have done constructing guidelines and specialized instructions for different purposes. So, if you want a Jira skill, it already has the endpoints for authentication methods and scripts to look for your boards and tickets, and that does make things a lot easier. This so-called DevOps engineer did a nice job finding where I'm spending too much on my private account. We'll come back to it when it's done. In the meantime, let's talk about one of my favorite topics as a proud Neovim user, key bindings. Let's start with a familiar concept. You don't get to see all that much beyond Vim and Timmax, a leader key. Changing the bind mode so that it doesn't interfere with other setups you have. I've changed it to `control o` for now. It's not perfect, but it works for me and I don't actually need that all that often. One of my all-time favorite things to do with my key bindings is opening an editor through open code. The prompt box is nice and all, but breaking lines, adding list is not great there. Leader `e`. And wham, my prompt is in neovim. Finally, I can edit my text like a human being with some dignity left before AI takes that, too. Once done, save it and it's sent back to the box. Time to build a team. But before I'm doing that, let me just say this. This is in test mode. This is how I work locally, but I'm improving it constantly. In fact, I think that's the only real way to properly work with agents. Fix them and have them remember what you've just changed by adjusting prompts, skills, and settings. What you'll see next is a very naive implementation of a group of agents I've configured to work on really large features of my application. This is only an initial setup and I've taken it further from what you see here. But let's first check it out and talk about the pros and cons later. So I decided to test an autonomous team of engineers I think any squad needs. So I built a team lead that orchestrates and delegates tasks. Please do not just add them to the long JSON like I did and use the `opencode agent builder`. This is just a showcase of what it can do. So in its prompt, the team lead is told he's here to gather requirements and is constantly delegating things. Here's how. I added a product manager who is there to only read, explore, and understand the user story. A backend dev because, well, I hope that's self-explanatory. A tester or a QA if you will. And lastly, we'll also use our code reviewer to keep that separate. The next time I run open code, the team lead is there to serve. You'll immediately notice a more structured approach to requests. While it's working, it's important to show yet another open- source agents team. This one is built on top of open code called open agents control. It claims to take more serious approach with a plan first pipeline and zero question human gateways. I don't know, I just want to see things first with my own eyes before delegating myself. back to our team. You can dive deep into sub agents with leader and side arrows showing things I really hadn't seen before, like a user flow drawn by my product manager and the backend dev's code changes. It's nice to see the interaction where team lead asks the product manager to clarify requirements for example and in real time how the code reviewer is working and the tester is testing alongside him. It's also common to see question asked by one of the agents. This is an example from another skill I'm trying to adopt, helping me with written content. It seeks to understand what I'm looking for and my preferences to configure itself for future requests. Or this other agent tasked with building a feature that comes back and asks what I want or make sure it's aligned with my preferences before moving to implementation. Right, we've got a team. It's LinkedIn slot ready. But is it worth anything? Well, honestly, the structure makes a lot of sense when I'm building something big. I've been using it for the past couple of weeks and it's been 95% okay. It's not perfect by any means. There are mistakes, but I'll have to push further to say whether this is groundbreaking or not. The secret for me is adjusting those sub agents each in their own markdown files constantly and making sure they are all aligned with my ways. So why would you even bother with sub agents rather than just a thread from the main entry point usually yields better performance per component, which makes a lot of sense. Beyond the prompts and each agent's context, just the fact that it's separated is a lot of the work. Now, keep in mind this isn't always great. First, it means a lot of tokens, a lot more of instructions are big, and I actually let the main builder agent do most of the work that isn't huge new part of my app. Secondly, skimming through sub agents to understand what's up and what went where is not always a pleasure. It's cool and all, but keep in mind you may want to keep it simple most of the times. Another way to keep things simple for some is to run open code where it works for you. `opencode.nvim` is a popular plug-in allowing you to invoke open code from within a running nvim session. And while I used it in the past and this guy I'm sure you're familiar with is having it as part of his setup. I don't find it comfortable anymore. Another way to run open code is through a web interface and that opens a world of new possibilities. It serves on a local port which you can then expose outside with something like engrop and browse through an iPad remotely. There's recent sessions with code changes and everything you can think of. I can browse through the sessions history and even keep working from the comfort of my couch with my iPad on my lap and just well work kind of. Oh, and since I'm on the couch already, instead of sifting through small GitHub technicalities, I can have Open Code manage that for me as well. GitHub's integration is available through the `opencode github install` command, adding an action that's triggered from the platform itself. After a quick auth process, you'll see the new action ready to be triggered with `/oc` or `/opencode` on comments. Once committed, you can just find any discussion and ask Open Code for thoughts or review or anything really. It'll add an emoji indicating it sees the request and is already working on it. And a few moments later, there's a review with thoughts, issues, and the session itself if you want to dive into it, too. Before going away, I cannot ignore the GUI, a fully native application, which I'm not sure if I've seen on the list of available options on the docs, still in beta, but works perfectly. open a session and keep going just like in the web interface with a few nice additions letting you know an agent is waiting with sound and visible OS notifications and a terminal integrated into it like an ID. So I guess that's where we're at. And just before we finish things up, another quite awesome feature and the reason why I initially told you to wait and see why Westerm or Ghosty are essential here is the ability to share images. Yeah, you can now drag an image to Open Code in the terminal and have it process a list of requirements, a theme, a style you want implemented or any visual. And this makes Open Code a fantastic agent that can literally solve anything anywhere. So, it's not a question whether Open Code stays or not. It's deeply integrated into everything I do. I find it better, easier, more flexible to config availability, anything really. I didn't even touch the live ecosystem, projects around it, and so many other great stuff to keep things short. But as you can see, whether on my iPad, GitHub, or laptop, it's everywhere and it's doing a fantastic job. If you like the way I work with it, specifically how Word Trunk pops it open for PRs and issues, I highly recommend checking Word Trunk Next, the project that makes Work Tree feel like branches, perfect for the era of modern engines. Thank you for watching and I'll see you on the next.