HN user

edgardurand

3 karma

I’m building a mobile control layer for AI coding agents.

The idea came from a simple frustration:

AI coding agents can keep working for minutes or hours, but developers are still tied to the desk if they want to monitor progress, approve decisions, redirect mistakes, preview the result, or keep the workflow moving.

I don’t think the future is “writing full production code from a phone”.

That sounds painful.

But I do think mobile becomes much more useful when the heavy work is being done by AI agents running inside your IDE, terminal, or cloud workspace.

That’s what I’m building with CodeAgent Mobile.

It lets developers pair their IDE, terminal, or GitHub Codespace with a mobile app, then supervise active AI coding sessions from anywhere.

You can:

monitor long-running agent tasks

send prompts by text or voice

approve or interrupt work

review progress

preview your running project from mobile

launch Codespaces from your phone

collaborate with teammates through shared Team Spaces

use Beads-powered AI context to keep agents aligned with project tasks and decisions

connect with any coding agent that supports ACP

For example, if an agent is building a React app, you can follow the session from your phone and open the live project preview inside the app to see how the UI is evolving.

The product works with workflows around Claude Code, Codex, Copilot, Cursor, Windsurf, VS Code, JetBrains, terminal sessions, GitHub Codespaces, and ACP-compatible agents.

The hardest part so far has not only been technical.

It has been messaging.

When people hear “mobile development”, many immediately think:

“Why would I code from my phone?”

And honestly, I agree with that objection.

The product is not meant to replace a laptop or IDE. It is meant to keep AI-assisted development moving when you step away from your desk.

Your IDE keeps running. Your agent keeps working. Your phone keeps you in control.

I’m still early, but I’ve already seen organic interest from developers experimenting with AI agents, async workflows, and remote supervision.

I’d love feedback from other builders here:

Would you use your phone to supervise an AI coding agent if your IDE, Codespace, or local dev server kept running in the background?

Or does this still feel like a workflow that only makes sense from a laptop?

Posts0
Comments2
View on HN
No posts found.
Show HN: SmallDocs – Markdown without the frustrations 3 months ago

For the "prove the server doesn't touch the data" problem — the realistic path today is probably reproducible builds + published bundle hashes.

  Concretely: the sdocs.dev JS bundle should be byte-for-byte reproducible                                                                                                         
  from a clean checkout at a given commit. You publish { gitSha, bundleSha256 }
  on the landing. Users (or agents) can compute the hash of what their browser                                                                                                     
  actually loaded (DevTools → Sources → Save As → sha256) and compare.                                                                                                             
   
  That closes the "we swapped the JS after deploy" gap. It doesn't close                                                                                                           
  "we swapped it between the verification moment and now" — SRI for SPA
  entrypoints is still not really a thing. That layer is on browser vendors.                                                                                                       
                                                                                                                                                                                   
  The "two agents review every merge" idea upthread is creative, but I worry                                                                                                       
  that once the check is automated people stop reading what's actually                                                                                                             
  verified. A dumb published hash is harder to fake without getting caught.                                                                                                        
                                                                                                                                                                                   
  (FWIW, working on a similar trust problem from the other end — a CLI + phone                                                                                                     
  app that relays AI agent I/O between a dev's machine and their phone                                                                                                             
  [codeagent-mobile.com]. "Your code never leaves your machine" is easy to                                                                                                         
  say, genuinely hard to prove.)
0ThreadHN