My Opencode Workflow As A Senior Engineer

11 months ago, Dario, Anthropics boss, said that in 3 to 6 months, AI will 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 a 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 OpenCode, the best coding agent in existence. There's a video on the channel covering the basics of it, but this was six months ago. Since then, OpenCode 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 OpenCode on his side. Don't worry, I'll get to everything in this video covering exactly how I use OpenCode in 2026 at work maintaining open source projects and building a sidekick. Let's go. With over 100,000 stars, OpenCode 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. OpenCode started as a TermAI, well, 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 acquihire them into the company. While the first dev agreeing and Dax and Adam refusing, saying they want to keep OpenCode 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's 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 Adam's commits in the history if you look deep enough. Okay. Trauma aside, OpenCode used to be a side project under SSD and is now under a larger umbrella called Anomaly, holding SSD, OpenCode, OpenAuth and other projects, backed by Y Combinator, Max Levchin, one of the founders of PayPal and others. Which kinda 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 Western or Ghosty. You'll see why. It's so nice to see the growing popularity of Mies, which is another run option for OpenCode. 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 Envars. I'll skip the install bit. Once OpenCode is ready, you'll see a bunch of interesting options from ACP, 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 OpenCode 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. OpenCode 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 and Anthropic, along with others, but more importantly, an interesting model by the name Big Pickle, which is a model by Opencode, 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 Minimax, which according to Anthropic is a Chinese LLM basically drinking data off of Claude, so you be the judge. A minute about Zen. For those who haven't watched my first video, Zen is an 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 Codex or Gemini or dozens of others. And if you're adventurous enough, like this guy, maybe even give Kimi a go. He actually claims Opus is slower than Kimi for most stuff he built. Anyway, we're off track. Pick your model or Zen and move on. Oh, important. OpenCode aren't looking to profit from them. 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 Claude 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 Slash 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 OpenCodeDB. Not sure why you'd need that if you're not building on top of OpenCode. The DB, unless told otherwise, is stored at .local ShareOpenCode. 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 stop and the first major building block of OpenCode is agents. OpenCode 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 open ai 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 slash tag the sub-agent in 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. You'll find a bunch of directories here like agent, command and skills but the simplest way is to pop open code 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 TMX window, creates a worktree 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 passwords. 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 leaked 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 dscope 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, dscope verifies who you are, issues a short-lived 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 open-cone-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-agent, or, and that's a new one, all. 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 role, 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 just 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 OpenCode specifically. Skills. slash 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 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 Manus, 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 Vercel, 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 agents.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 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 Tmax. A leader key. Changing the bind mode so that it doesn't interfere with other setups you have. I've changed it to Ctrl 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 lists 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 backhand 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 OpenCode, 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 OpenCode called OpenAgentsControl. 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 questions 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, Task 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 is in a 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 OpenCode where it works for you. OpenCode Envim is a popular plugin allowing you to invoke OpenCode from within a running NeoVim 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 ngrop and browse through an iPad remotely. There's recent sessions with code changes and everything you can think of. I can browse through the session's history and even keep working from the comfort of my couch with my iPad on my lap and just, well, work, kinda. Oh, and since I'm on the couch already, instead of sifting through small GitHub technicalities, I can have OpenCode 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 slash OC or slash OpenCode on comments. Once committed, you can just find any discussion and ask OpenCode for thoughts or review. 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... 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 WesDerm or Ghosty are essential here, is the ability to share images. Yeah, you can now drag an image to OpenCode in the terminal and have it process a list of requirements, a theme, a style you want implemented or any visual. And this makes OpenCode a fantastic agent that can literally solve anything, anywhere. So it's not a question whether OpenCode stays or not. deeply integrated into everything I do. I find it better, easier, more flexible to configure motion's 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 WorkTrunk pops it open for PRs and issues, I highly recommend checking WorkTrunk Next, the project that makes work trees feel like branches, perfect for the era of modern engines. Thank you for watching and I'll see you on the next one.

Get started with Descope: Drag & Drop Your Auth! https://descope.plug.dev/AZj86Ml
---

Opencode remains the best agent I've used, and after almost 8 months from the first time I installed it, I'm ready to share my setup and updates.
- https://opencode.ai
- https://github.com/omerxx/dotfiles

✅ Build a Second Brain With Neovim in Under 90 Minutes: https://learn.dotb.sh/courses/second-brain-neovim
✅ Zero To KNOWING Kubernetes in Under 90 Minutes:
https://learn.dotb.sh/courses/k8s-from-scratch
❗Use `devopstoolbox20` at checkout for 20% off!

⌨️ The keyboard on this video is the Dygma Defy: http://dygma.com/DEVOPSTOOLBOX
🎹 Keycaps on my Defy are made by 3DKeyCaps: https://3dkeycap.com/?ref=vxdqqmmo
⚡ Tech I use: https://kit.co/omerxx/my-battle-station