{"slug": "no-plugins-needed-i-built-a-fully-automated-coding-loop-in-opencode", "title": "No Plugins Needed, I Built a Fully Automated Coding Loop in OpenCode", "summary": "A developer built a fully automated coding loop inside OpenCode using DeepSeek-V4 models, implementing a three-loop system inspired by Andrew Ng's breakdown of Loop Engineering. The system enables autonomous code implementation, engineer feedback, and external feedback loops without plugins, achieving high-quality results at low cost.", "body_md": "[Harness Engineering](https://www.dataleadsfuture.com/tag/harness-engineering/)\n\n# No Plugins Needed, I Built a Fully Automated Coding Loop in OpenCode\n\nUsing DeepSeek-V4 for low-cost Loop Engineering\n\nToday I want to talk about how I built an agentic coding loop inside OpenCode. People call this Loop Engineering.\n\nTo show you how well this coding loop holds up, I used `DeepSeek-V4-Pro`\n\nand `DeepSeek-V4-Flash`\n\nfor every example in this article. It turns out that with the right design, DeepSeek models can pull off high-quality coding loops at a very low cost.\n\nAll the source code in this article is available at the end of the post. Let's get into it.\n\n## Introduction\n\nIf you've been following the AI agent space recently, you've probably heard the term Loop Engineering. Claude Code and OpenClaw both mention it.\n\nBut nobody really explains what it means.\n\nUntil Andrew Ng posted [a clear breakdown of what Loop Engineering actually is.](https://www.deeplearning.ai/the-batch/issue-359?ref=dataleadsfuture.com) That post gave me the direction I needed to build it inside OpenCode.\n\n## What Andrew Ng Says About the Coding Loop\n\nAndrew Ng's explanation centers around this diagram:\n\nThree loops, simply put:\n\n- The first loop is the code agent's implementation loop. You give the agent a product spec and a measurable target. The agent starts building features on its own, runs tests, and keeps iterating until every requirement in the spec is met.\n- The second loop is the engineer feedback loop. Here the engineer acts as QA for their own product. They test what the coding agent built, and check if it matches their vision. If something is off, they write a new spec and kick off another round in the first loop.\n- The third loop is the external feedback loop. Once the engineer is happy with the product, it goes to the open-source community or gets handed to a product team. Real user feedback comes in. The engineer collects that feedback regularly, feeds it back into the engineer feedback loop, and from there back into the code implementation loop.\n\nAll three loops keep running. With AI in the mix, they push the product forward until it gets to where it needs to be.\n\n## My Take on the Coding Loop\n\nThe way I see it, these three loops map to two commands in Claude or Codex: `/goal`\n\nand `/loop`\n\n.\n\n`/goal`\n\ncovers the first and second loops. Once a user writes a product requirements doc or a spec, they pass the task to the agent through the `/goal`\n\ncommand. The agent iterates on its own, runs its own tests, and opens a Pull Request.\n\nThen the engineer reviews the code and tests it manually. If everything looks good, they merge the PR and ship.\n\nNext comes the external feedback loop. You can use the `/loop`\n\ncommand to set up scheduled tasks that pull issues from GitHub or Jira on a timer. The agent turns those issues into requirement docs, and `/goal`\n\ntakes it from there.\n\nThere is a gap in the traditional understanding here. When a user calls `/goal`\n\n, they just pass in what they want done. How it gets done, and what the exit condition is, often gets left up to a strong reasoning model like Claude Opus or GPT 5.5 to figure out.\n\nBut in a proper coding loop, you need to give the agent a product spec and a measurable completion target so it knows when to exit. Something like this:\n\n```\n/goal Use the spec I wrote to build this chess game. \nUse Playwright MCP for end-to-end testing. \nVerify the game supports castling, pawn promotion, checkmate, stalemate, and rating calculation. \nFix any bugs found during testing and re-run. Loop no more than 20 times.\n```\n\nThat is a solid starting instruction for a coding loop. It needs a goal, a verification method, and a max iteration count. And you have to write something like that every single time, either right after the `/goal`\n\ncommand or inside the spec itself.\n\nIn my OpenCode version, I am not going that route. I just want to tell `/goal`\n\nwhat I want. The agent handles everything else.\n\nThe rest of this article shows you how I built that enhanced `/goal`\n\nloop. (The `/loop`\n\ncommand is a separate topic I will cover in a future post.)\n\n## See the Final Result First\n\nBefore getting into the implementation, let me show you what the `/goal`\n\ncommand actually does in a few scenarios, from simple to complex.\n\n### 1. Write a Fibonacci script\n\nThis test checks whether the agent picks the best algorithm. The prompt is:\n\n```\n/goal Write a Fibonacci calculation script with the best possible performance.\n```\n\n### 2. Build a Tower of Hanoi web game\n\nEveryone knows this game. You could honestly just prompt an LLM directly and get it built. But that predictability is exactly what makes it useful for testing whether each step of the coding loop is working correctly.\n\nThe prompt is:\n\n```\n/goal Build a playable Tower of Hanoi web game.\n```\n\n### 3. Build a chess web game\n\nMaybe you are not impressed by the Tower of Hanoi example, since a regular prompt to any frontier model can do the same thing without a coding loop. Fair. The chess game experiment is something you should actually try for yourself.\n\nThe prompt is:\n\n```\n/goal Build a playable chess web game. \nInclude easy, medium, and hard difficulty levels. \nNo online multiplayer needed. \nUse a Python backend as the AI engine.\n```\n\nIn this experiment, OpenCode first does a quick requirements check with the user after receiving the task.\n\nIt offers suggestions along the way so you can just click next. Once the full requirements list is confirmed, it enters autonomous mode.\n\nIt handles architecture design, builds each feature module, runs unit tests, edge case tests, and end-to-end tests. It only hands the result back to the user when everything passes.\n\nPretty cool, right? Want to know how it works? Let's go.\n\n## Building the Coding Loop\n\n### Overall design\n\nOpenCode updates very fast. Almost every release breaks something or introduces small bugs. So I am not building yet another OpenCode plugin, since a plugin can easily break after an update.\n\nThe good news is that OpenCode lets you define commands and agents using plain Markdown files. Write a few lines of prompts, save the file as Markdown, and drop it in the right directory. That mechanism is the foundation for building a powerful coding loop on the cheap.\n\nLet me walk you through the interaction flow of the whole loop.\n\nWhen a user runs `/goal <some task>`\n\nto start a new coding task, OpenCode sends that task to an agent I call the orchestrator. In this setup, that agent is `goal-orch`\n\n.\n\nThe orchestrator's job is to talk to the user and review completed work. When it receives a task, it does not start coding right away. It first has a short conversation with the user to clarify the details, then breaks the task down into a list of atomic requirements.\n\nThis is different from OpenCode's built-in `Plan`\n\nagent. The `/goal`\n\norchestrator does not ask open-ended questions. It takes its best guess at what the user wants and asks the user to confirm whether those sub-requirements are correct.\n\nThis works much better when the user is not a software engineer. It is like a capable assistant breaking down tasks for their manager without making the manager feel lost.\n\nOnce the requirements list is confirmed, the orchestrator saves it as a `reqs-manifest.md`\n\nfile. This file tracks requirement status and serves as the acceptance record throughout the loop.\n\nAfter that, the orchestrator enters autonomous mode. It starts an internal loop that calls a worker agent called `goal-worker`\n\nand sends each requirement to it.\n\n`goal-worker`\n\nhandles code implementation. Before writing any code, it does architecture planning first. If there are technology choices involved, it raises questions. It does not ask the user though. It asks `goal-orch`\n\n. Once `goal-orch`\n\nanswers, `goal-worker`\n\ncontinues.\n\nAfter the architecture plan is done, `goal-worker`\n\nenters the loop and starts implementing each requirement.\n\nEach requirement includes feature code, edge case handling, and unit test code. When all of that is done, `goal-worker`\n\nsends an implementation report back to `goal-orch`\n\n.\n\nThe orchestrator checks the report against the requirement description, confirms completion, and updates the status in the requirements list.\n\nInside the loop, `goal-orch`\n\nalso builds a DAG from the full requirements list to map out dependencies. Requirements with no dependencies between them get executed in parallel with multiple `goal-worker`\n\ninstances, which speeds things up significantly.\n\nOnce all requirements are done, `goal-orch`\n\nruns acceptance tests against the list, checks unit test coverage, and for tasks involving frontend work, it launches end-to-end tests using `browser use`\n\nto confirm everything works.\n\nWhen everything passes, the orchestrator writes an implementation report and notifies the user that the task is complete. Then it waits for the next task.\n\nThe execution sequence looks like this:\n\nNow, let me walk through how each piece is built.\n\n### Implementing the** **`/goal`\n\n** **command\n\nSince we want `/goal`\n\nto be the entry point for the coding loop, just like in Claude Code, which is the first thing to build in OpenCode.\n\nThankfully, creating a command in OpenCode is pretty simple. Just drop a Markdown command definition file into the `.opencode/commands/`\n\ndirectory.\n\nTwo things to keep in mind when writing the Markdown command file:\n\n- In the\n`frontmatter`\n\n, configure a separate agent through the`agent`\n\nparameter. Without a dedicated agent, OpenCode sends the command straight to the default agent. The default agent has no Loop Engineering prompts, so the command fails. For`/goal`\n\n, I set up an orchestrator agent named`goal-orch`\n\n, which I will cover next. - In the body of the command, use the\n`$ARGUMENTS`\n\nplaceholder to represent the task the user passes when calling the command. When the command sends the message to the orchestrator, this placeholder gets replaced with whatever the user typed, and the full assembled message goes to the orchestrator.\n\n### Implementing the** **`goal-orch`\n\n** **agent\n\nNow let's build the `goal-orch`\n\nagent, which acts as the orchestrator. It handles user communication, requirements clarification, kicks off the development loop, and calls `goal-worker`\n\n, and verifies that work is complete.\n\nSince we have built OpenCode agents multiple times in previous articles, I will not go into every detail here. Just a few things worth noting:\n\n- Model choice.\n`goal-orch`\n\nhandles workflow orchestration overall, so it needs strong reasoning. I am a fan of the DeepSeek-V4 series, so I went with`deepseek-v4-pro`\n\n. - System prompt. The prompt needs to cover both workflow orchestration and the agent's own tasks, so it is on the longer side. But that is fine. When you use\n`/goal`\n\nto send a task, the`goal-orch`\n\nsystem prompt automatically replaces OpenCode's default prompt, so there is no need to worry about excessive token usage. `goal-orch`\n\nmust be a primary agent. OpenCode has two agent types: primary agents and subagents. The key difference is that primary agents can call subagents to delegate work, but subagents cannot. Since`goal-orch`\n\nneeds to call`goal-worker`\n\ninside the loop, so it has to be a primary agent. The only downside is that it shows up in the agent list at the bottom of the OpenCode interface, but you get used to it.- The interaction mechanism between primary and subagents. During the loop, when\n`goal-worker`\n\nhits a tricky problem or needs to make a technology choice, it does not ask the user. It returns the question to`goal-orch`\n\nthrough a session return. This requires`goal-orch`\n\nto answer the question and then continue the previous sub-session. OpenCode uses a`task`\n\ntool to send messages to subagents. This tool accepts a`task_id`\n\nparameter. The first call to the`task`\n\ntool opens a new subagent session, and the return value includes a`task_id`\n\n. After`goal-orch`\n\nanswers`goal-worker`\n\n's question, it passes the answer and the previous`task_id`\n\nback into the`task`\n\ntool. This resumes the task in the original sub-session and preserves context. - Put simply, it works like a foreman and a worker. The foreman sends the worker off to do a job. The worker gives the foreman a reference number. If the worker hits a problem, they come back and ask the foreman. The foreman solves the problem, takes the reference number and the answer back to the worker, and the worker picks up exactly where they left off. No starting over.\n\n- Parallel task execution. Even though we are building a fully automatic coding loop, the orchestrator can still run multiple\n`goal-worker`\n\ninstances in parallel for requirements that have no dependencies on each other. This speeds up the overall task significantly. After`goal-orch`\n\nconfirms the requirements list with the user, it does not jump straight into the coding loop. It first maps out the dependency relationships between requirements into a DAG. When it finds requirements with no dependencies between them, it kicks off parallel execution to finish the task faster.\n\n- Every completed task gets documented. A coding loop handles a large volume of requirements at once, and this process can run for hours. As the task keeps going, the context grows longer and the agent's ability to follow the prompt gets weaker. At that point, we cannot rely on session messages alone to track the status of each requirement. The orchestrator will start missing key steps in the workflow. So when designing\n`goal-orch`\n\n, I included a requirement in the prompt: subagents must not only update the requirement status in`reqs-manifest.md`\n\nafter each step, they also generate a documentation note for each completed requirement. That way, once the coding loop ends,`goal-orch`\n\ncan review those documents to see which tasks finished cleanly and which ones hit blockers that need human attention. - End-to-end testing with\n`browser use`\n\n. Since we are going fully automatic, why not go all the way? When`goal-orch`\n\ndetects that the task involves a frontend page, it calls the`agent-browser`\n\nskill or`@playwright-mcp`\n\nduring the final review phase to run end-to-end tests, and captures screenshots as proof that the feature works. Since I am using`deepseek-v4`\n\nmodels, I also call the`@observer`\n\nagent for image reading when needed. I covered the`@observer`\n\nagent implementation in a previous article.\n\nThat covers the notable design decisions behind `goal-orch`\n\n. I am not going to paste the full prompt here since prompts are easy to generate with an LLM once you understand the principles. Grab the full source code at the end of the article.\n\nNow let's look at `goal-worker`\n\n.\n\n### Implementing the** **`goal-worker`\n\n** **agent\n\nCompared to `goal-orch`\n\n, `goal-worker`\n\nis much simpler by design. It just does the work. The simpler its instructions, the better it performs. That said, I did set a few expectations for it in this coding loop:\n\n- Model choice. For tasks that do not need deep reasoning,\n`deepseek-v4-flash`\n\nhonestly outperforms`pro`\n\n. From my experience, in situations involving function calling and skill loading,`flash`\n\nis more accurate than`pro`\n\nand costs much less. So for`goal-worker`\n\n, which is all about execution,`deepseek-v4-flash`\n\nis the right call. - Ask before acting. Even though it is a subagent, I gave\n`goal-worker`\n\nthe ability to ask questions. Whether it is before starting or in the middle of a task, whenever it hits a technical question,`goal-worker`\n\nstops and asks`goal-orch`\n\nfor input. This makes full use of the stronger reasoning model higher up in the chain. - Plan first, then act. Just like the outer loop driven by\n`goal-orch`\n\n,`goal-worker`\n\nfollows the same rule: plan before doing. Before implementing any new requirement,`goal-worker`\n\nwrites out a plan that covers the tech stack, what it intends to change, and how it will handle unit tests and edge cases. That plan goes to`goal-orch`\n\nfor review. Only after`goal-orch`\n\nsigns off does`goal-worker`\n\nstart coding. This mechanism maximizes the chance of a successful implementation. - Use modern package managers. This is not strictly required, but in practice I noticed that DeepSeek tends to default to traditional tools like\n`pip`\n\nand`npm`\n\nfor global dependency installs. As a developer, that is something I can not live with. So I explicitly require`goal-worker`\n\nto use modern package managers like`uv`\n\nand`pnpm`\n\n. This also keeps your environment clean when the coding loop is building something for you.\n\nThat is the full implementation plan for my OpenCode coding loop. I did not paste source code into the article body since all of it is at the end. Go grab it there.\n\nI also tried to explain the thinking behind this coding loop and how to build it clearly enough that you could just drop this article into OpenCode and have it reconstruct a working `/goal`\n\ncommand for you. From there, tweak it however you want and build your own version of Loop Engineering. In the age of AI, what is really impossible anymore?\n\nBefore wrapping up, let me quickly cover how to actually use this coding loop.\n\n## How to Use This Coding Loop\n\nFirst, go to the end of this article and open the GitHub link I shared. Then come back here and keep reading.\n\nThe source code for the coding loop lives in its own git repo. The only directory you need to care about is `.opencode/`\n\n. To use this coding loop across all your OpenCode projects, copy the `agents`\n\nand `commands`\n\ndirectories from that folder into `~/.config/opencode/`\n\n, then restart OpenCode.\n\nIf you only want to try it in one specific project, just copy the `.opencode/`\n\ndirectory into your project root and restart OpenCode.\n\nIf you just want to take it for a quick spin, clone the repo locally, create a new branch, and run `opencode`\n\nfrom that branch to start the environment.\n\nAfter that, type the `/goal`\n\ncommand in OpenCode with whatever task you want the coding loop to handle. For example, if you want to build the typing practice game Andrew Ng mentioned in his post, just enter this:\n\n```\n/goal I want to build a typing practice web app for kids. \nAt the bottom of the screen are 9 keys representing the positions of 10 fingers, with the thumbs sharing a wider spacebar key that takes up two slots. \nAbove those 9 keys is a gradient-transparent rectangle. \nLetters fall down from the top toward that rectangle, aligned to their matching key positions. \nPress the right key as the letter enters the zone and it counts as a hit, triggering a hit effect. \nConsecutive correct hits build up increasingly dramatic effects. \nThe falling speed gradually increases. \nAt the top of the screen is a scoreboard that adds 1 point for each hit, with a pop animation. \nThe whole thing should feel exciting and dopamine-triggering, with plenty of visual encouragement.\n```\n\nYou can be as detailed or as vague as you want. Either way, once you hit enter, the coding loop starts running. `goal-orch`\n\nwill open a conversation with you to clarify the requirements.\n\nYou can fill in more details as the conversation develops, or just choose `recommend`\n\nfor everything and go make yourself a coffee while it does the work.\n\n## Conclusion\n\nThat is the story of how I built this coding loop inside OpenCode. Before I wrap up, let me answer a few questions you might have.\n\n**1. Can open-source models support this coding loop?**\n\nYes, I think so. In this article, I used `deepseek-v4-pro`\n\nfor `goal-orch`\n\nand `deepseek-v4-flash`\n\nfor `goal-worker`\n\n, and both worked well. With the strict constraints of the loop workflow in place, they can handle most of your tasks automatically.\n\nAlso, DeepSeek is releasing the official version of DeepSeek-V4 in mid-July. It will almost certainly come with post-training improvements, and I expect even better results from it.\n\n**2. What results should I expect?**\n\nThe coding loop will spend hours working through your task, but do not set your expectations too high for what a single `/goal`\n\nrun can produce. That is true even with the most powerful Claude or GPT models.\n\nAs Andrew Ng said, the code implementation loop is just the first of three loops. You need to step into the second loop, the engineer feedback loop. Try out what `/goal`\n\nproduced, find all the bugs and things that do not match your vision, organize those into a new spec, and kick off another coding loop. Keep iterating. That is how the product gets better over time.\n\n**3. Can the coding loop replace SDD frameworks like OpenSpec?**\n\nNo. They serve different scenarios.\n\nThe coding loop is great for product managers or team leads who want to quickly spin up a minimum viable product from market insights or their own ideas. It prioritizes speed and automation. It is for people who want to hand things off and let the agent run on its own.\n\nBut if your product is going to production, if you have high standards for code quality and implementation details, if you have a detailed product spec, and you are an experienced software engineer who knows exactly what the product should look like, then OpenSpec or another SDD plugin is the right tool. Start from a solid foundation and build your full product step by step.\n\nI will keep updating this article as I use the loop more, and the Q&A section at the end will keep growing. If you have any questions, leave a comment, and I will get back to you as soon as I can.\n\nThanks for reading and subscribing. Next time you are sitting there sipping coffee while OpenCode codes away on its own, if this article comes to mind, please share it with a friend.\n\nMr. Qian's Recommendation:\n\nKnowing a few AI coding tricks won't really set you apart at work. What you actually need is the ability to integrate AI-generated code into real enterprise codebases.\n\nI highly recommend the [Generative AI Software Engineering Specialization](https://imp.i384100.net/qWVbNg?ref=dataleadsfuture.com) by Vanderbilt University. It'll take you from being a casual user to becoming a truly AI-driven software engineer.\n\n*If you choose to enroll, I may earn a small commission at zero extra cost to you. I only recommend high-quality resources that genuinely align with the engineering standards of Data Leads Future.*\n\n[👉 Start Learning for Free Now](https://imp.i384100.net/qWVbNg?ref=dataleadsfuture.com)\n\n## Further Reading\n\nHow I built a coding workflow in OpenCode, Oh-My-OpenCode-Slim, and OpenSpec that rivals Claude Code:\n\nHow I added a reflection agent to the OpenSpec workflow and got DeepSeek-V4 to match or beat Claude Opus:\n\nStill can't get your DeepSeek-V4 or GLM-5.2 to read images? Try my method:\n\nYou can grab the source code for this article right here:", "url": "https://wpnews.pro/news/no-plugins-needed-i-built-a-fully-automated-coding-loop-in-opencode", "canonical_source": "https://www.dataleadsfuture.com/no-plugins-needed-i-built-a-fully-automated-coding-loop-in-opencode/", "published_at": "2026-07-15 02:52:26+00:00", "updated_at": "2026-07-15 02:53:20.355897+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "large-language-models", "generative-ai"], "entities": ["OpenCode", "DeepSeek-V4", "Andrew Ng", "Claude Code", "OpenClaw", "Codex", "GitHub", "Jira"], "alternates": {"html": "https://wpnews.pro/news/no-plugins-needed-i-built-a-fully-automated-coding-loop-in-opencode", "markdown": "https://wpnews.pro/news/no-plugins-needed-i-built-a-fully-automated-coding-loop-in-opencode.md", "text": "https://wpnews.pro/news/no-plugins-needed-i-built-a-fully-automated-coding-loop-in-opencode.txt", "jsonld": "https://wpnews.pro/news/no-plugins-needed-i-built-a-fully-automated-coding-loop-in-opencode.jsonld"}}