Build Studio learns to ask first

Last week I promised a fuller Build Studio update. There is now a new walkthrough, covering what has changed in drafting, how a new project begins, and an experiment I am not ready to trust yet.

There is a change to the studio's project list too: Launch Studio has arrived, while Skrivhjälp has reached the end of its life.

Drafting and starting a project

A story draft now lives in Build Studio's dashboard rather than in a separate terminal. I can return to the conversation, including when I use Codex or OpenCode, and ending a draft commits the PRD and the project decisions it changed. That sounds like housekeeping, but it removes a surprisingly common interruption: starting the next run only to discover that the previous draft left the project in an unfinished state.

The more interesting change is at the start of a project. In the relevant kickoff and onboarding flows, Build Studio now interviews me about decisions the agents would otherwise have to infer: who the product is for, what belongs in the first release, and which constraints matter. The agents still do the research and planning, but they ask before turning an assumption into the project's direction.

Several smaller changes make the workflow more honest about its state. A task that only I can complete is shown as waiting for me. A check that could not run is not automatically treated as a defect for a developer to fix. And when a review reaches its round limit, I can see the findings I would be accepting rather than clicking past an unexplained gate. Even archived project learnings now keep their links intact, so tidying old knowledge does not break the next commit.

The Build Studio changelog has the full detail. The video also shows how Launch Studio fits in near the end.

Can a model read the checks more carefully?

Build Studio still makes some small decisions by looking for particular phrases in an agent's report. That works when the wording follows the expected format. It can miss a problem described plainly in a different way.

I am testing Jev, a decision model, as a second reader of verification reports. For now it runs in shadow mode: it records an answer beside Build Studio's existing one, but it cannot change what the workflow does.

On the first day, it examined 63 reports and agreed with the existing rule on 53. One disagreement was a genuine catch: a review said in prose that verification was blocked by a build guard, without using the marker the rule looks for. Other disagreements revealed a flaw in my question to the model. I had mixed up "this check was not part of the review" with "the environment prevented this check from running." I have split those into separate questions.

That is an interesting first result, not evidence that Jev is reliable enough to make decisions. The point of shadow mode is to collect the disagreements — and the mistakes — before giving it any authority.

One project arrives, another leaves

Launch Studio now has its own project page. Build Studio helps me make the product; Launch Studio is for the work of bringing it to people and continuing to show up after release. It is a separate product, still early in development. Its weekly overview and content workflow exist today: planning the week, developing topics and drafts, checking them against a product's voice, and approving a handoff to the product repository. The broader social, SEO, support, and video tools are still plans, not shipped features.

At the same time, I have retired Skrivhjälp. It was my first project and taught me a great deal, but it attracted little traffic and arrived too late for continued maintenance to make sense. The service is gone; its project page keeps the story, screenshots, and lessons.

Elsewhere

Fazon continues toward a beta. I hope to give it the main story next week, ideally alongside its website, so I will leave the details for then.

My Next: List is testing an improved grocery-list ordering flow in an internal beta. There is no public release to announce from that work yet.

For Build Studio, this week's thread is fairly simple: better questions at the beginning, clearer uncertainty in the middle, and fewer places where an unfinished decision can quietly pass as a finished one.