Most AI coding tools still feel like a faster autocomplete window.
You ask a question. You get an answer back. You copy it, paste it, test it, clean it up, and decide whether any of it belongs in your product.
That is useful, but it is not the big shift.
The big shift is when the agent stops being a chat box next to your work and becomes a worker inside a controlled environment. It can look at a real repo, understand the files, run commands, make a branch, push a commit, and hand you a pull request.
That is why I cared about Vercel Open Agents.
Not because it is another AI demo. Not because it writes code. We already have plenty of tools that write code.
I cared because it points to a different product pattern: background software work with a human review gate.
So I forked it, deployed it, and turned it into a live app you can try: agents.sharonsciammas.com.
The Problem: Chat Does Not Own the Work
When founders and small teams talk about AI coding, the conversation usually gets stuck on output quality.
Can it write the function? Can it improve the page? Can it generate tests?
Those questions matter, but they are not the whole workflow. Real software work has more steps:
- understand the repository
- decide where a change belongs
- edit more than one file
- run checks
- keep the work isolated from
main - create something another human can review
- preserve the history of what happened
Chat alone does not own that workflow. It can suggest what to do, but the human still becomes the orchestration layer. You are copying context back and forth, running commands locally, checking files, and cleaning up the mess.
That is fine for one task. It becomes expensive when the work is continuous.
The real question is not "can AI write code?"
The real question is: can AI take responsibility for a bounded software task while the human stays in control of approval?
That is the product promise I wanted to test.
What Open Agents Actually Does
Open Agents is Vercel's open-source reference app for running autonomous coding agents on Vercel infrastructure.
The user experience is simple:
- Sign in.
- Connect a GitHub repo.
- Start a session.
- Ask the agent to make a change.
- Review the result as a branch or pull request.
Behind that simple flow is the interesting part.
The agent does not need your laptop. It runs as a durable workflow. The code execution happens inside an isolated Vercel Sandbox VM. GitHub is connected through an app installation, so the agent can clone the repo, work on a branch, push commits, and open a PR.
That architecture matters because it changes the role of AI from "answer generator" to "bounded operator."
The human still decides what matters. The human still reviews the pull request. The human still owns judgment. But the tedious middle layer can move into a controlled runtime.
That is the part people should pay attention to.
Why This Is Strategically Interesting
Vercel is not just showing a coding toy here.
Open Agents sits at the intersection of three things Vercel already understands well:
- deployments
- previews
- developer workflows
For years, Vercel made it normal for every branch to become a preview. That changed how teams review frontend work. You did not need to imagine the change. You could click it.
Open Agents extends that logic upstream.
If a branch can become a preview, and an agent can create the branch, then the workflow starts to look different:
- the founder describes the product change
- the agent performs the first implementation pass
- the environment runs the work away from the founder's machine
- the team reviews a concrete PR instead of debating an idea
That is not "AI replaces engineers." That is the lazy headline.
The more interesting version is: small teams get a new execution layer between idea and review.
For the ICP I care about - founders, lean marketing teams, solo builders, and operators trying to ship with too few hands - that is huge. The bottleneck is often not imagination. It is turning scattered ideas into reviewable artifacts.
Open Agents is one way to make the artifact appear faster.
What I Built
I did not build a new coding model. I did not try to make the agent smarter.
I built the path from reference app to usable live surface.
That meant deploying the full stack, connecting auth, wiring GitHub, getting sandbox execution working, and documenting the setup so another builder can reproduce it without spending a day guessing which service owns which credential.
The result is a live coding-agent environment:
You can sign in, connect a test repository, ask the agent to change a file, and review the work in GitHub.
That is the important sentence.
Not "it generated a patch."
"It moved work into a reviewable branch."
That is the product value.
The Real Demo Is the Workflow
The live app is not interesting because it has a chat interface. Every AI product has a chat interface.
It is interesting because the chat is attached to an execution loop:
Intent -> repo context -> sandbox work -> branch -> pull request -> human review
That loop is the product.
It gives a founder a way to delegate small software tasks without handing over production access. It gives a technical operator a way to test agent workflows against real repos. It gives a team a concrete review object instead of another AI-generated suggestion floating in Slack.
The human value is not "less typing."
The human value is less coordination drag.
You can point the agent at a bounded task, let it work elsewhere, and come back to a diff. That is a different relationship with software work. It is closer to assigning a junior teammate a task than prompting a chatbot for an answer.
That also makes the human role clearer. You are not there to type every line. You are there to define the task, constrain the scope, review the result, and decide whether it ships.
That is a higher-leverage job.
Why I Still Wrote the Deploy Guide
The deploy guide exists because useful infrastructure should be reproducible.
If the only way to understand a reference app is to reverse-engineer environment variables, OAuth flows, GitHub App permissions, sandbox behavior, and database setup, most people will never get to the product insight. They will quit at setup.
That is a waste.
The guide is not the story. It is support material.
The story is that Vercel's architecture makes a new kind of agent product feel possible: software work that happens in the background, in a sandbox, with GitHub as the handoff layer.
The guide just helps another builder reach that moment faster.
What This Means for Builders
If you are building AI products, Open Agents is worth studying for the pattern, not the implementation details.
The pattern is:
- give the agent a bounded environment
- give it real tools
- isolate the execution
- preserve the work as a reviewable artifact
- keep the human at the approval point
That pattern applies beyond coding.
A marketing agent should not just write campaign ideas. It should produce a draft campaign brief, audience hypothesis, landing page outline, and creative variants for review.
A sales agent should not just summarize a lead. It should update the CRM, log the activity, draft the follow-up, and surface the next decision.
A support agent should not just answer a ticket. It should cite the source, propose the fix, and escalate the cases where the system should not act alone.
The future is not "chat with everything."
The future is controlled agent workflows that produce reviewable work.
That is what Open Agents makes visible.
My Takeaway
The most useful AI systems do not remove humans from the loop. They move humans to the right part of the loop.
I do not want an agent merging random code into production. I want an agent doing the first pass in a sandbox, giving me a branch, and making the review step faster.
That is the difference between automation theater and useful infrastructure.
Open Agents is early. It is a reference app, not a finished product category. But the direction is clear: the next generation of AI tools will not live only in chat. They will live inside workflows, sandboxes, repos, CRMs, calendars, and approval gates.
That is why I built the live fork.
Not to show that an agent can generate a patch.
To show what happens when an agent can turn intent into reviewable work.
That is the shift.
Links
- Try the live agent: agents.sharonsciammas.com
- My fork: github.com/sharonds/open-agents-1
- Deployment guide: github.com/sharonds/open-agents-deploy-guide
- Original Vercel Labs repo: github.com/vercel-labs/open-agents
