Mission #18: Your pipeline needs a front door
Your pipeline is doing real work. It takes the nightly drop, pulls the fields out of ten thousand documents, runs the checks, and hands back something a person can act on in the morning. It has been right for weeks, and somebody outside your team has noticed. Then they ask for a link to it, and you hit the question every demo dies on: can I use this? Answering it means a React front end, sign-in, somewhere to host it, and a way to keep your run and theirs from landing on top of each other. The pipeline was an afternoon's work. The product is a month out, and almost all of that month is plumbing.
On RocketRide Cloud the app is built where the pipeline is. A RocketRide app is a React micro-frontend that the platform shell loads at runtime: you build it in a folder in your workspace, watch it live in the App Builder's preview, and deploy it to Cloud the same way you deploy a pipeline. Same workspace, same deploy, same place it runs for everyone else.
The part worth stopping on is what you do not write. A task's identity is the signed-in user, so every user who opens your app gets their own instance of the pipeline, automatically. No session plumbing, no per-user queue, no two people's runs colliding in the same process. Per-user is simply what you get by writing nothing at all. Where a pipeline should be shared instead, because it is one warm index or one big model, that is the thing you opt into.
You already built the part that was hard. The distance between that and something a colleague can open should not be measured in weeks.
How an app reaches Cloud
The path runs like this: install the VS Code extension and connect to Cloud, which vendors the client into your workspace rather than pulling it from npm, then create the app with a developer ID, build it with your own coding agent, and deploy. Every app you deploy is named with your developer ID in front of it, which is the namespace guarantee: nobody outside your org can ever deploy into it.
Deploy ships a snapshot of the app's source to the server, where the server builds it and it becomes the next immutable registry version. Publishing is then the same repointing move Mission #17 described, aimed at an app instead of a pipeline: yourself, your team, or the public store. Internal rungs serve the moment you publish; the store is the same pointer move behind a review step.
Two ways in today, one on Discord and one in a room, and then a very full October.
- Office Hours, 10:00 to 11:00 AM Pacific, on Discord. The question is the one Story 1 walks straight into: one agent, or many? Mithilesh Gaurihar, Josh Phillips, Krish Garg and Aviral Bhardwaj take it apart live, with the cost of context as the part nobody agrees on. Bring the split you keep changing your mind about and we will work through it together. Come with a question or come just to listen, both are genuinely welcome.
- SF Enterprise Hackathon 2.0, 9:30 AM to 5:30 PM Pacific, at Huddle in Mountain View. A one day build for working professionals on the next generation of enterprise AI: engineers, founders, product leaders and AI practitioners, in a room full of people solving the same problems you are. Spots are limited and every registration goes through the host, so register now rather than at the door. 166 builders are already in.
🚀 And then October, which is stacked. Five RocketRide events across SF Tech Week and LA Tech Week: builds, hackathons, and one night at Club 345 that is entirely ours. Dates land on the calendar as they lock, and that is where they show up first, so keep it open.
The week's AI news that changes how you build.
Every major lab has now had a model reach a real company it was never meant to touch.
Google confirmed on Friday that Gemini accessed three real companies during a May evaluation run by the security firm Irregular. In one case it guessed passwords until it was in, and in the other two it found credentials sitting in a public repository and used them. The model was never supposed to be online at all, and internet access was available by mistake. Google's VP of security engineering says it stopped each time it worked out the target was real, but with OpenAI, Anthropic and Meta already on this list, the question is no longer whether a model will try, it is what sits between it and your production systems when it does.
A paper just measured how much of your agent's score is the harness rather than the model.
Run-Ze Fan and eight co-authors published "An Empirical Study of Harness Design for Coding Agents" on 17 September, holding the execution loop fixed and varying planning, action space and context management across 176 matched settings, four models, and both SWE-Bench Verified and Terminal-Bench 2.1. Two findings are directly actionable: planning stops being an accuracy scaffold and becomes a cost saver once the model is strong enough, and predefined tools only help models with weak bash skills, while bash-capable models do as well with a bare shell for substantially less money. They also recommend staging cheap elision before you pay an LLM to summarize. If you have been tuning prompts and leaving the harness alone, this is the paper that says you have it backwards.
An AI coding assistant was shipping developers' entire Git histories to a cloud they did not choose.
Last Friday a developer publishing as ferstar reverse-engineered ZCode, Z.ai's desktop coding assistant, and found that while you are logged in it quietly packages your whole workspace, the full .git history, the LFS cache, reflogs and global configs, then encrypts it and uploads it to Alibaba Cloud storage. One snapshot came to 42,411 files and 313 MB, of which 86.6 percent was .git. It is encrypted with a public key the server hands over at upload time, so the private key never leaves the vendor and you cannot open the copy sitting on your own disk. Whatever coding agent you run has that same reach into your repository.
Member discussion