Open-source AI code editor. Composer plans a change and stages it as a diff. Before you apply it, every change is checked: it parses, imports resolve, types check, the preview renders, and tests run. Tests run in your browser tab, free.
AI code editors are good at writing edits that look right. Whether the edit parses, whether its imports point anywhere, whether the tests still pass: you usually find that out after you've applied it. I built Aperture so the editor checks before you do.
Composer reads the code, posts a plan, and waits for you to click Build it. Edits arrive as staged diffs you keep or skip file by file. Nothing touches your files until you apply. Each staged change gets five checks: it parses, its imports resolve, the types check, the preview renders, and the project's tests run. A check that couldn't run says why. It never shows as a pass. If a test was already failing before the edit, Aperture says so and doesn't blame the edit.
The tests run in a sandboxed Worker in your browser tab with no network access, so they cost nothing and take about a second. It handles node:test, Vitest and Jest. A new failure goes back to the agent once to fix.
There's also a design mode: click an element in the preview to edit its CSS or the page's theme tokens. The demo plays recorded runs. To use a real model, self-host with your own key for Grok, OpenAI, Anthropic, Gemini, DeepSeek or a custom endpoint.
It's MIT-licensed. The demo asks you to sign in before you can run a plan. It plays back recorded runs, so it costs nothing. You can also run it locally in a minute without an API key; the commands are in the README.
What I'd like to hear: - Do the checks catch the mistakes that actually bite you? What's missing? - Where does the in-browser test runner fall over on your projects? - Anything that confused you in the first five minutes.
You used to wait on one Composer turn. Now hit the clock button (or Ctrl/Cmd+Shift+Enter), keep working, and open the run when it’s ready to review — up to three background runs at once. Checks still run on the result (parse, imports, real tsc, tests) before you keep anything.
Also new since launch:
Checks benchmark: how often the checks stop a bad edit before Apply — https://aperturesais.grok.me/ben... (18/18 visible mistakes stopped; 0/8 false alarms on correct edits)
Editable plans before Build, plus an agent board for every run
Real TypeScript type-check in the strip (not the light check)
Same product idea: plan first, exact lines, then checks — now it doesn’t block you while the agent works.
the "a check that couldn't run says why, never shows as a pass" line is the detail that'd actually make me trust this over other editors - that's exactly the kind of silent-pass failure I worry about with Claude Code when I'm not watching closely. one thing I'm curious about: the new failure goes back to the agent once to fix - what happens on the second miss? does it surface the diff to me with the failing test attached so I can see what it tried, or does it just drop the change and tell me it couldn't do it? that's the moment where I'd want maximum visibility, not a clean failure message
Thanks Gal, that's exactly the failure I was worried about too.
On the second miss it stops. No loop, no silent drop. The change stays staged as a diff with the red checks on it. Click the failing check to jump to the line, and expand the test output to see what broke. Nothing touches your files unless you keep it.
The agent also has to rate its fix. Below 0.8 confidence the fix is thrown away and the turn stops, rather than piling a shaky fix on top.
What I don't show well yet is the first attempt and the fix side by side. That's a good push, I'll look at it.
Replies
Hi Product Hunt, I'm Witchayut.
AI code editors are good at writing edits that look right. Whether the edit parses, whether its imports point anywhere, whether the tests still pass: you usually find that out after you've applied it. I built Aperture so the editor checks before you do.
Composer reads the code, posts a plan, and waits for you to click Build it. Edits arrive as staged diffs you keep or skip file by file. Nothing touches your files until you apply. Each staged change gets five checks: it parses, its imports resolve, the types check, the preview renders, and the project's tests run. A check that couldn't run says why. It never shows as a pass. If a test was already failing before the edit, Aperture says so and doesn't blame the edit.
The tests run in a sandboxed Worker in your browser tab with no network access, so they cost nothing and take about a second. It handles node:test, Vitest and Jest. A new failure goes back to the agent once to fix.
There's also a design mode: click an element in the preview to edit its CSS or the page's theme tokens. The demo plays recorded runs. To use a real model, self-host with your own key for Grok, OpenAI, Anthropic, Gemini, DeepSeek or a custom endpoint.
It's MIT-licensed. The demo asks you to sign in before you can run a plan. It plays back recorded runs, so it costs nothing. You can also run it locally in a minute without an API key; the commands are in the README.
What I'd like to hear:
- Do the checks catch the mistakes that actually bite you? What's missing?
- Where does the in-browser test runner fall over on your projects?
- Anything that confused you in the first five minutes.
Thanks for taking a look.
Since launch we shipped Background Composer.
You used to wait on one Composer turn. Now hit the clock button (or Ctrl/Cmd+Shift+Enter), keep working, and open the run when it’s ready to review — up to three background runs at once. Checks still run on the result (parse, imports, real tsc, tests) before you keep anything.
Also new since launch:
Checks benchmark: how often the checks stop a bad edit before Apply — https://aperturesais.grok.me/ben... (18/18 visible mistakes stopped; 0/8 false alarms on correct edits)
Editable plans before Build, plus an agent board for every run
Real TypeScript type-check in the strip (not the light check)
Same product idea: plan first, exact lines, then checks — now it doesn’t block you while the agent works.
Try it free: https://aperturesais.grok.me
the "a check that couldn't run says why, never shows as a pass" line is the detail that'd actually make me trust this over other editors - that's exactly the kind of silent-pass failure I worry about with Claude Code when I'm not watching closely. one thing I'm curious about: the new failure goes back to the agent once to fix - what happens on the second miss? does it surface the diff to me with the failing test attached so I can see what it tried, or does it just drop the change and tell me it couldn't do it? that's the moment where I'd want maximum visibility, not a clean failure message
Thanks Gal, that's exactly the failure I was worried about too.
On the second miss it stops. No loop, no silent drop. The change stays staged as a diff with the red checks on it. Click the failing check to jump to the line, and expand the test output to see what broke. Nothing touches your files unless you keep it.
The agent also has to rate its fix. Below 0.8 confidence the fix is thrown away and the turn stops, rather than piling a shaky fix on top.
What I don't show well yet is the first attempt and the fix side by side. That's a good push, I'll look at it.