Show HN: Stagewise (YC S25) – Front end coding agent for existing codebases
Hacker News (score: 18)Description
You can spawn the agent into locally running web apps in dev mode with `npx stagewise` from the project root. The agent lets you then click on HTML Elements in your app, enter prompts like 'increase the height here' and will implement the changes in your source code.
Before stagewise, we were building a vertical SaaS for logistics from scratch and loved using prototyping tools like v0 or lovable to get to the first version. But when switching from v0/ lovable to Cursor for local development, we felt like the frontend magic was gone. So, we decided to build stagewise to bring that same magic to local development.
The first version of stagewise just forwarded a prompt with browser context to existing IDEs and agents (Cursor, Cline, ..) and went viral on X after we open sourced it. However, the APIs of existing coding agents were very limiting, so we figured that building our own agent would unlock the full potential of stagewise.
Here's how it works: When you run `npx stagewise`, our cli proxies your running web application in dev mode and injects a toolbar containing the coding agent on top of it. Each prompt you send will be enriched with browser context and sent to our cli, which will call our backend and modify the source code of your local codebase accordingly.
Here's a demo of our agent changing the login UI of Cal.com, a popular open-source meeting scheduling app: https://www.youtube.com/watch?v=BkDcAozK9L4.
So far, we've seen great adoption from non-technical users who wanted to continue building their lovable prototype locally. We personally use the agent almost daily to make changes to our landing page and to build the UI of new features on our console (https://console.stagewise.io).
If you have an app running in dev mode, simply `cd` into the app directory and run `npx stagewise` - the agent should appear, ready to play with.
We're very excited to hear your feedback!
More from Hacker
Show HN: Tusk Drift – Turn production traffic into API tests
Show HN: Tusk Drift – Turn production traffic into API tests Hi HN! In the past few months my team and I have been working on Tusk Drift, a system that records real API traffic from your service, then replays those requests as deterministic tests. Outbound I/O (databases, HTTP calls, etc.) gets automatically mocked using the recorded data.<p>Problem we're trying to solve: Writing API tests is tedious, and hand-written mocks drift from reality. We wanted tests that stay realistic because they come from real traffic.<p>versus mocking libraries: Tools like VCR/Nock intercept HTTP within your tests. Tusk Drift records full request/response traces externally (HTTP, DB, Redis, etc.) and replays them against your running service, no test code or fixtures to write/maintain.<p>How it works:<p>1. Add a lightweight SDK (we currently support Python and Node.js)<p>2. Record traffic in any environment.<p>3. Run `tusk run`, the CLI sandboxes your service and serves mocks via Unix socket<p>We run this in CI on every PR. Also been using it as a test harness for AI coding agents, they can make changes, run `tusk run`, and get immediate feedback without needing live dependencies.<p>Source: <a href="https://github.com/Use-Tusk/tusk-drift-cli" rel="nofollow">https://github.com/Use-Tusk/tusk-drift-cli</a><p>Demo: <a href="https://github.com/Use-Tusk/drift-node-demo" rel="nofollow">https://github.com/Use-Tusk/drift-node-demo</a><p>Happy to answer questions!
Show HN: Yolobox – Run AI coding agents with full sudo without nuking home dir
Show HN: Yolobox – Run AI coding agents with full sudo without nuking home dir
Sandbox: Run untrusted AI code safely, fast
Sandbox: Run untrusted AI code safely, fast
Show HN: Bithoven – A high-level, imperative language for Bitcoin Smart Contract
Show HN: Bithoven – A high-level, imperative language for Bitcoin Smart Contract Hey HN! I’m a researcher working on Bitcoin smart contracts, and today I’m releasing Bithoven—a high-level imperative language that compiles to native Bitcoin Script (Legacy, SegWit, and Taproot).<p>The Goal:<p>Raw Bitcoin Script is notoriously difficult to reason about. Writing raw Bitcoin Script today feels like writing Assembly in the 1970s. You have to mentally juggle the stack (`OP_SWAP`, `OP_ROT`), manually manage distinct execution branches, and pray you didn't leave a stack item unconsumed (which crashes the script). My goal was to bridge the gap between complex contract logic and raw opcodes, allowing developers to write readable, compile-time-safe code.<p>Key Features:<p>- Imperative Syntax: Write logic using familiar if/else and return statements instead of mental stack juggling.<p>- Type Safety: First-class support for bool, signature, string, and number types to prevent runtime errors.<p>- Targeted Compilation: Support for Legacy, SegWit, and Taproot compilation targets.<p>- Native Primitives: Built-in keywords for timelocks (older, after) and cryptography (sha256, checksig).<p>You can try it in the browser here (runs via WASM): <a href="https://bithoven-lang.github.io/bithoven/ide/" rel="nofollow">https://bithoven-lang.github.io/bithoven/ide/</a><p>Here is an example of a Hashed Time-Locked Contract (HTLC):<p><pre><code> (condition: bool, sig_alice: signature) (condition: bool, preimage: string, sig_bob: signature) { if condition { // Relative locktime (Sequence) older 1000; return checksig (sig_alice, alice_pk); } else { // Hashlock verification verify sha256 sha256 preimage == hash; return checksig (sig_bob, bob_pk); } } </code></pre> The project is free open source and the academic paper is currently under review. I’d love to hear any feedback. Thanks for checking it out!
No other tools from this source yet.