[0:00]11 months ago, Dario, Anthropic's 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 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 OpenCode, 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, OpenCode has matured big time. You can now control sub agents, follow their work, install skills, control every bit of the system with motions, integrated 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.
[1:13]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 IDE, and of course, the terminal. But as with every big project, it starts with a small fuming drama. OpenCode started as Term AI, uh, 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 acquire 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 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 OpenCode 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 Adam's commits in the history if you look deep enough. Okay, drama aside, OpenCode used to be a side project under SST and is now under a larger umbrella called Anomaly. Holding SST, OpenCode, OpenAuth, 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 anyway you like. With its new features, it's now suggesting one of these, which I highly recommend, either WezTerm or Ghostty. You'll see why. It's so nice to see the growing popularity of Mise, 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 uses, 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 OpenCode 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 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 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 /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 OpenCode. The DB, unless told otherwise, is stored at dot 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 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.
[6:11]They have a builder, a deep builder, a marketing guy, a sales person, 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. OpenCode 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 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 a 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 dot config slash open code. 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-Dash to preview PRs. I have a key binding that sends a new tmux window, creates a work tree with work trunk, another video on the channel that you'd want to watch and pops OpenCode 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 linked 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 Descope comes in, and why I'm integrating it into OpenCode. Instead of static keys, you get what's called JIT, just in time tokens. Your agent requests access, Descope 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 Descope, 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, 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. Happen to me more than once. Use with caution. So, why would you even consider something like that? I'll get into more detail soon, but basically this operation 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. /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 skill MP 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 sounded 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 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 end points 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 tmux, 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 OpenCode. 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 taking 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 he's constantly delegating things. Here's how. I added a product manager, who's 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 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 OpenAgents Control. It claims to take a more serious approach with a plan first, pipeline and zero question human gateway. 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 OpenCode where it works for you. OpenCode NVIM 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 familiar with is having it as part of his setup. I don't find it comfortable anymore. Another way to run OpenCode 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 Engrock 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 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 oath 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 OpenCode for thoughts or review or anything really. It'll add an emoji indicating it sees the request and is already working on it. In 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 WezTerm or Ghostty 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. It's deeply integrated into everything I do. I find it better, easier, more flexible to configure motions 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 work trunk pops it open for PRs and issues, I highly recommend checking work trunk next, the project that makes work trees feel like branches, perfect for the era of modern agents. Thank you for watching, and I'll see you in the next one.
