{"slug": "one-ai-knows-the-errand-one-knows-the-code-i-just-bring-the-phone", "title": "One AI Knows the Errand. One Knows the Code. I Just Bring the Phone.", "summary": "A developer has extended a personal-assistant-to-coding-agent bridge so that a personal assistant (Instinct) handles requests and outside-world context while a separate coding agent (OpenCode) works inside the repository, keeping the coding session on the developer's Mac. The writeup argues the meaningful distinction is who owns the conversation, not which agent has browser tools via MCP, and illustrates the setup with examples such as turning a video into an interactive demo and a vague screenshot complaint into a working preview. The author notes the examples are illustrations of what the team could do, not shipped workflows.", "body_md": "*Part 2: the bridge connects the team. What can the team turn into something useful?*\n\nIn [the first article](https://dev.to/sharkwani/i-texted-instinct-it-tells-my-coding-agent-what-to-build-5h96), I connected my personal assistant, Instinct, to OpenCode on my Mac. Instinct is the PM. OpenCode is the developer. I can text the assistant, it hands over the work, and the result comes back to my phone.\n\nThat solves the handoff. Now for the interesting question: what do you hand the team?\n\nA video you bookmarked. A screenshot captioned \"this looks weird.\" An email asking you to do the same little calculation again.\n\nUsually, you translate each of those into a coding task yourself. Copy the request. Paste the context. Explain the answer. Repeat until the future of computing looks suspiciously like an office job.\n\nThe next step I want is to let the team carry that translation: an everyday thing goes in, something another person can use comes out.\n\nYou can give a coding agent browser tools through MCP or plugins. A coding agent that can look at a page, edit code and check the result is useful.\n\nThat is not the distinction I am making.\n\nThe distinction is who owns the conversation.\n\nWith tools attached to a coding agent, you are still talking directly to the developer. In this setup, I talk to a personal assistant, and it works with a separate coding agent. Instinct handles the request and the outside-world information relevant to it. OpenCode works in the repository and keeps the coding session.\n\nMCP could be part of either side. It does not make the team idea redundant. Tools give an agent capabilities; the handoff gives those capabilities different jobs.\n\nGiving the developer a browser is useful. Giving the developer a colleague is the part I find exciting.\n\nYou watch a video explaining an idea. Normally, the output is a bookmark and the feeling that you have been productive.\n\nWhat if the output were something another person could use?\n\nThe examples below are illustrations of what the team could do with the right tools and access. They are not transcripts or a claim that these workflows all ship in the bridge today.\n\nSay the video teaches a way to compare options. You send it to Instinct:\n\nResearch this method. Work with OpenCode to turn the useful part into a small interactive demo. Bring it back for review before we share it.\n\nInstinct checks the accessible material and supporting sources. It separates the method from the sales pitch, identifies the assumptions, and helps choose a version worth building. OpenCode turns the brief into a demo with adjustable inputs, a worked example and checks for the results.\n\nNow your friend can enter their own options and try the method. They do not need to watch the video, find the useful bit or translate it into a spreadsheet first.\n\nThe interesting transformation is not video to summary. It is video to something you can put in somebody else's hands.\n\nSomeone sends you a screenshot of a mobile page with the message every developer loves:\n\nThis looks weird.\n\nA beautifully precise specification. We should frame it.\n\nInstead of becoming the translator between that message and your coding agent, you could give the team the screenshot and the page to inspect:\n\nWork out what's wrong, fix the clear problem, and give me a working preview I can send back for review. Ask me before changing the design itself.\n\nInstinct turns \"weird\" into something observable: the navigation covers the main action, or the layout clips at a narrow width. OpenCode makes the scoped change. With visual access, Instinct checks the result and sends any remaining problem back to the coding session.\n\nThe useful output is a working preview the other person can open on their own phone. They can try the interaction, rather than approving a screenshot and discovering later that the button is decorative.\n\nA vague complaint has become a corrected experience someone can use and review. The team has carried the translation; you make the decisions it cannot.\n\nThen there is the email that keeps coming back because everybody is doing the same little calculation by hand.\n\n\"Which option fits these requirements?\" followed by a list of constraints. Someone opens a sheet, copies the inputs, checks the rules and writes the answer. Next week, the ritual returns with different inputs. Congratulations: your inbox has a manual API.\n\nYou could ask the team:\n\nLook at this recurring request. Help me turn the agreed rules into a small tool people can use themselves, without exposing the emails or inventing any rules.\n\nInstinct works out which inputs matter, checks the rules with you, and removes the private context from the brief. OpenCode builds a utility around the approved logic, with examples and checks.\n\nThe output could be a simple eligibility checker: someone enters their requirements and sees which options fit, along with the reason. Unresolved cases stay unresolved instead of getting a confident answer made up for them.\n\nNow the next person gets a tool to try, not another explanation to copy. The emails are not being published; the approved process is being turned into something reusable.\n\nThis is the same team dynamic in a different shape. Instinct understands the work around the code. OpenCode builds the thing. You approve the rules and any sharing.\n\nNone of these examples is impossible without two agents. The appeal is that the person no longer has to turn every source, complaint and recurring request into a technical brief by hand, then carry every answer back again.\n\nThe goal is to get interrupted for the right reasons.\n\n\"Which of these designs do you prefer?\" is a useful interruption.\n\n\"Please copy my last message into the other app\" is a cable pretending to be a conversation.\n\nA coding response might say that part of the request is finished, but another part depends on a decision. That should not leave you decoding a terminal transcript on your phone. The PM should bring you the decision in plain words, then take your answer back to the coding session.\n\nA fix might pass a code check but still look wrong in the browser. The PM should be able to return that evidence to the developer rather than declaring victory because the last sentence sounded confident.\n\n\"It works on my machine\" is an old classic. We do not need to replace it with \"it works in my summary.\"\n\nThe roles keep their context. The assistant stays with the request. The developer stays with the code. A follow-up can return to the same coding session, rather than introducing the project to an amnesiac stranger every time you send a message.\n\nThat is what I want from this team: work that keeps moving between my decisions, rather than work that moves only when I paste something.\n\nThe bridge carries tasks to OpenCode on the machine and returns the output, branch and session information. It is the connection between the teammates, not a third genius hired to supervise the other two.\n\nIt also does not magically become a browser, an always-on computer or a quality guarantee. Visual review needs visual tools. The machine needs to be available. The result still needs checking.\n\nThe first version provides the conversational coding handoff. The richer team workflow is what I want to build around it, with clear briefs, useful evidence and questions coming back at the right moment.\n\nPersonal assistants and coding agents will keep improving at different things. I want to benefit from both, rather than wait for one product to become the best at everything.\n\nA better personal assistant could understand the request and the context around it more clearly. A better coding agent could turn that brief into a better implementation. The handoff is what lets those improvements meet.\n\nThat is why I want the pairing to become portable: keep the team, change either teammate when there is a good reason. Instinct and OpenCode are the pair I use today. Other assistants and coding agents would need their own integrations; swapping them is the direction, not a feature every combination supports already.\n\nI am not betting on one platform winning. I want to ride both improvement curves.\n\nThe source is here: [https://github.com/sharkwani/instinct_openCode_bridge](https://github.com/sharkwani/instinct_openCode_bridge)", "url": "https://wpnews.pro/news/one-ai-knows-the-errand-one-knows-the-code-i-just-bring-the-phone", "canonical_source": "https://dev.to/sharkwani/one-ai-knows-the-errand-one-knows-the-code-i-just-bring-the-phone-1g20", "published_at": "2026-10-11 10:08:48+00:00", "updated_at": "2026-10-11 10:21:36.368971+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "agent-protocols"], "entities": ["Instinct", "OpenCode", "MCP", "dev.to"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/one-ai-knows-the-errand-one-knows-the-code-i-just-bring-the-phone", "markdown": "https://wpnews.pro/news/one-ai-knows-the-errand-one-knows-the-code-i-just-bring-the-phone.md", "text": "https://wpnews.pro/news/one-ai-knows-the-errand-one-knows-the-code-i-just-bring-the-phone.txt", "jsonld": "https://wpnews.pro/news/one-ai-knows-the-errand-one-knows-the-code-i-just-bring-the-phone.jsonld"}}