This is a really good framing honestly. Spec-first tools are useful, but milestone-first feels way better for actually learning and not getting lost after step 2.
I like that you keep things verifiable at each step too, thats the part most AI coding tools skip and then people think theyre progressing when theyre just generating code.
how do you decide milestone size so its not too tiny but also not overwhelming?
do you track failed attempts/retries as part of progress, or only completed milestones?
Also are you planning a mode where users can switch between learning path and spec mode in the same project? I think that could be very strong.
Milestone size is basically tuned around one question: "can the user verify this in a short time without ambiguity?" If it is smaller than that, it becomes noise and hurts progress. If it is larger, people get stuck in a blob of work and lose the sense of forward motion. So the target is usually one meaningful capability change with one clear check - not a pile of subtasks and not a full feature.
On progress, I think completed milestones should stay as the primary unit because that keeps the system honest. But retries and failed attempts still matter as signal and we don't track them. I would not count them as progress in the same sense, but I would track them as learning/debugging history, like where people got stuck, how many tries something took and whether a milestone needs to be split or clarified. That is useful both for the user and for improving the recipe indeed. Great point!
And yes, I think mixing learning-path mode and spec mode inside the same project is important. A lot of real work starts milestone-first when you are learning the domain, then becomes spec-first once you know what you are building. So the model I like is one project with two views. Right now, Primer supports learner and builder tracks for the whole project/recipe. I would like to incorporate your feedback and allow switches between tracks.
Love this project. The CD streaming trick is such a smart constraint hack, and honestly the best part is you trained the model for the hardware instead of forcing a desktop recipe onto PS2.
Curious about 2 things if you can share:
whats your per-token latency on real hardware
how much quality loss came from PSNT quantization vs fp16 baseline
Either way this is peak hacker energy, shipping on actual hardware makes it 10x cooler.
It didn't had any quality loss, since the PSNT as quantization it's mainly to convert the model over the console constraints (you can convert any model you want, even when i trained a model for this hw); it's q8 quantization, so quality loss is negligible for these sizes. For the speed, I will fix the Tok/sec count since now drops 0 always for showing measures
PS: Thank you! And forgot to mention PSNT also supports bitnet models, they work like crap tho
Thats super helpful, thanks for the details. Makes sense now that PSNT is more of a transport/runtime format for the PS2 constraints than a quality hack.
Very cool that it supports bitnet too even if results are rough right now, feels like theres a lot of room to tune there over time.
when you do fix tok/sec, are you planning to post per-stage timings too (tokenizer, weight stream, matmul, samppling)? would be awesome to see where the biggest bottleneck is on real hw
Cool tool and great idea. However I find a few UX bugs initially as I'm browsing around.
- The document, when loaded, is not centered in the screen, a little bit annoying.
- The landing page is not SUPER intuitive, I don't really know what to do or how to start doing anything, maybe a SMALL tutorial?
- When I land on the page I get presented with dark mode, as soon as I select a tool and get redirected the theme changes to light mode.
Great tool and most of them work good too!
I will browse a bit more and let you know what I find :)
Wow nice tool! Unfortunately I'm not able to contribute for any of the listed supports. Good luck with finding supporters though, looking forward to follow this.
I built Silent Editor to see if a fully browser-side stack could handle the PDF editing workflow that people currently do by uploading files to cloud services or paying for Adobe. Loading a PDF, editing text in place, adding signatures, merging pages, exporting a clean result. All without the document ever leaving your machine.
All the technology already exists: PDF.js for parsing and rendering (same engine Firefox uses), pdf-lib for assembling output files, Canvas API for pixel-level work, Tesseract.js compiled to WebAssembly for OCR. The problem is making these pieces work together smoothly enough that it actually feels like a real editor and not a hack.
Most of the system is deterministic plumbing. Rendering pages to canvas, extracting text span coordinates, managing overlay state for highlights and signatures, remapping annotations when pages get reordered or deleted. The part where things get tricky is everything visual: matching the original font when you replace text, sampling the actual ink color from rendered pixels so your edits don't look obviously different, and producing an export that's either compact with selectable text (Vector mode) or pixel-perfect faithful to what you see on screen (Visual Perfect mode).
The privacy model is enforced architecturally, not by policy. Production builds ship with a Content Security Policy and a runtime network guard that block outbound requests carrying document data. The only things that touch the network are billing metadata through Stripe and page analytics through Cloudflare. Neither carries any document content. There's a CI suite that fails the build if any of this regresses.
It's already handling real editing workflows: text replacement with font trait detection, electronic signatures with date stamps, page insert/delete/duplicate/reorder/merge, shape annotations, OCR for scanned documents, and both export paths. But font matching is still imperfect for uncommon typefaces, color sampling from the canvas can miss on edge cases, and Visual Perfect export produces larger files than I'd like.
I'd especially welcome criticism on: is the free tier boundary (daily export cap, Visual Perfect gated to premium) reasonable, or does it feel like it cripples the product? And for people who actually handle sensitive documents regularly, does "runs in your browser, no upload" actually change your behavior, or do you just not think about it?
This is a really good idea. Image all the game devs that hate writing actual code but sits on some seriously good ideas. This will help so many to get the initial MVP thats needed to see if a game idea is viable.
I like that you keep things verifiable at each step too, thats the part most AI coding tools skip and then people think theyre progressing when theyre just generating code.
how do you decide milestone size so its not too tiny but also not overwhelming? do you track failed attempts/retries as part of progress, or only completed milestones? Also are you planning a mode where users can switch between learning path and spec mode in the same project? I think that could be very strong.
reply