The Problem With Human-Driven Coding Agents
Freeform Code started from a practical question inside JetCalls: what would happen if AI developer tools stopped behaving like a faster terminal and started behaving more like a small delivery team?
Most coding agent workflow experiments still keep the human in the driver’s seat. The person must describe the whole product, break it into tasks, feed commands to a coding CLI, notice when context has drifted, decide when to test, and remember what changed. The agent may write code quickly, but the human is still the project manager, analyst, developer lead, QA coordinator, and release checker.
That can be useful for technical users. It is not enough for the kind of AI-guided software development we wanted to prove. We wanted a workflow where a non-specialist could bring a goal in plain language, have the system turn that goal into a small, testable feature, and then see a live result they could review. The product should not pretend to build fully autonomous software from vague prompts. It should make the human decision points clearer, smaller, and easier to approve.
This is where Freeform Code became different from a normal coding assistant. The central idea is inversion of control: the agent guides the human through one small feature at a time, instead of the human driving a coding CLI through a complete pre-planned product.
That difference sounds subtle until you use it. In a conventional flow, the human must arrive with a plan. In Freeform Code, the Analyst agent helps create the plan for the next feature, asks the questions that matter, records the answers, and waits for approval before implementation starts.
The Inversion Of Control
Freeform Code is built around feature-by-feature development. A topic begins with a short request, not a full specification. The Analyst agent turns that request into a goal, acceptance criteria, and open questions. The human reviews the proposed scope and answers only the questions needed to move the next small feature forward.
Only after approval does the Developer agent begin implementation. The Developer agent is not expected to renegotiate the business goal. Its job is to build against the approved pinned spec. When the work is ready, the Tester agent verifies it with real commands and browser checks where appropriate. When the result has a user-visible surface, the Preview agent starts a running version and returns a live preview URL.
The human remains in control of decisions. Freeform Code does not claim to be a fully autonomous product builder. The important shift is that the system owns the process rhythm. It asks, scopes, builds, tests, previews, and hands control between agents in a visible way.
That rhythm matters because software work fails at boundaries. A developer assumes the requirement is obvious. A tester checks the code but not the intended behavior. A preview exists somewhere, but the stakeholder never sees it. Freeform Code makes those boundaries explicit by giving each role a separate job.
This is also why the product is designed around a chat-style experience rather than just a local terminal session. The conversation is not a side channel. It is the work log. Each handoff is visible. Each feature has a durable scope. Human comments can happen in the same place as agent updates without turning the workflow into noise.
From Daemon To Product Workflow
The first useful version of Freeform Code was infrastructure-oriented. It proved that a daemon could run coding agents, keep their sessions separate, route work to different roles, and manage previews. That foundation mattered, but it was still close to a technical system for technical operators.
The product journey moved from “can agents run code on a machine” to “can agents guide software delivery in a form that humans can actually follow.” That is a different standard. A working daemon is necessary. It is not a product by itself.
The next step was role separation. Developer, Tester, and Preview became distinct responsibilities instead of one blended assistant. That made the workflow easier to reason about. A Developer agent changes the product. A Tester agent checks the result and reports failures. A Preview agent manages the running version that a human can inspect.
Then the front of the workflow changed. The Analyst agent became the default entry point. This was the key product move. Without the Analyst, the user still needs to know exactly what to ask the Developer to do. With the Analyst, the first interaction can be a rough product request. The system can turn it into acceptance criteria and ask for the missing decisions before any code changes happen.
That evolution is connected to how we think about other JetCalls products. In building AI Site Biz, the interesting problem is not just generating pages; it is turning a business goal into a useful web presence. In building Resmart AI, the challenge is not just data extraction; it is making real-estate intelligence usable. Freeform Code follows the same pattern: the product value is in the workflow around the model, not in the model call alone.
Why The Pinned Spec Matters
The pinned spec is the source of truth for each feature. It holds the goal, acceptance criteria, open questions, implementation notes, test plan, and preview status. Every agent can refer to the same current scope instead of relying on memory from a previous turn.
This sounds like documentation, but in practice it is control infrastructure. AI-assisted work often breaks when intent lives only in chat history. A long conversation gets compressed. A different agent enters the task without the same context. A user changes a requirement midstream. The pinned spec gives the workflow a stable object that can be read and updated as the feature moves forward.
It also improves accountability. The Analyst agent owns the goal, acceptance criteria, and open questions. The Developer agent records implementation notes. The Tester agent records the test plan and outcomes. The Preview agent records the live preview state. Each role adds the part of the truth it is responsible for.
The human benefits because the scope stays inspectable. They do not need to read code to understand what was intended. They can check whether the acceptance criteria match what they asked for. If a later review finds that the wrong thing was built, the team can see whether the problem was unclear scope, implementation error, incomplete testing, or preview feedback.
That is a large part of E-E-A-T for a product like this. We are not asking readers to trust a claim that agents magically build products. We are showing the operating pattern: scoped work, explicit approval, role-based execution, verification, and a running result.
Testing And Preview As First-Class Work
One of the early lessons was that “the code changed” is not a useful finish line. For business stakeholders, even “the tests passed” can be too abstract. They need to click, inspect, and react.
That is why Freeform Code treats preview as a first-class stage. The Preview agent is not decoration at the end of the process. It is the point where the work becomes reviewable by someone who did not write the code. A live preview URL turns a technical artifact into a product conversation.
Testing has the same status. The Tester agent is responsible for building and running the result, not just reading the diff. For user interfaces, that means real browser interaction when the project calls for it. For APIs, it means calling the behavior directly. The tester can hand work back to the Developer agent when something fails, or back to the Analyst agent when the failure reveals a missing requirement instead of a code bug.
That distinction is important. In human teams, many bugs are actually specification gaps. The same is true in AI-guided work. If the acceptance criteria never said what should happen in an edge case, the right move is not always to guess and patch. Sometimes the right move is to update the spec and ask the human to decide.
This is where Freeform Code becomes more than a chain of agents. It is a process for keeping decisions, implementation, verification, and review connected. That lesson also informs building AI Dashboard, where governed data products need traceable decisions, and building Hermes Hub, where operational systems need reliable handoffs rather than impressive demos.
What This Proved For JetCalls
Freeform Code proved that AI-guided software development works best when the workflow is narrow, explicit, and reviewable. The product is strongest when it guides one feature at a time. It does not need to promise that a vague idea becomes a complete company-grade product with no human judgment. That promise would be weaker and less honest.
The stronger claim is this: a coding agent workflow can reduce the distance between a business request and a running, testable change when it gives each step a clear owner. Analyst scopes. Developer builds. Tester verifies. Preview publishes a reviewable result. The pinned spec keeps the feature anchored as it moves.
That is the product-development story behind Freeform Code. We began with the mechanics of running agents against software projects. We learned that mechanics were not enough. The product became meaningful when it inverted control and made the agent responsible for guiding the human through the next small decision.
This matters for JetCalls because our work is not limited to isolated demos. We build applied AI systems where models, software, infrastructure, and operations have to meet. Freeform Code is both a product and proof of method: AI developer tools become more useful when they are wrapped in a workflow that respects how real software decisions are made.
The next phase is not to remove the human. It is to make the human’s role sharper. Decide the goal. Approve the spec. Review the live result. Then let the agents handle the disciplined middle: feature-by-feature development, implementation, testing, and preview.