We live in the age of miracles, when every day feels like Christmas. This year we finally have an incredible hardware like Apple MacBook Pro with M5 Max chip capable of running local language models at the speed and approaching the quality of a frontier model, amazing Qwen 3.8 27B model that works on that hardware and finally Claude Opus 5.5. So I decided to put all that goodness to the test and port GPU-Quicksort algorithm to Swift and Metal using Specification Driven Development with speccheck. I wanted to do that for a while, but my two previous attempts failed: GPU-Quicksort uses a bunch of parallel synchronization primitives, so one little mistake in syntax or semantics and you lock up your GPU for good.
The approach was to take the pdf of the original July 2009 article by Cederman and Tsigas and ask Claude to convert it to markdown first, then use spec-writing skill of speccheck suite to write initial version of the spec with target being Swift for code and Metal for GPU kernels, then use spec-review skill to review the spec twice and apply its findings, and proceed with spec-build (which internally calls spec-plan to plan implementation waves, then builds the spec per waves, and runs speccheck twice: first grep-like and then with LLM-as-a-judge, to check specification conformance). Once that was done, the result was 1359 lines of Swift, 281 lines of Metal, 82 lines of C/C++ (for quicksort and std::sort comparisons) and around 1300 lines of test code, mostly in Swift. The code worked on the first try.
Since this is a miraculous year, another thing landed: Formal Verification is now fully accessible to an average software engineer, and I decided to integrate that into speccheck via spec-model and spec-proof skills: the former is to prove specification, when no code is written, the latter: to prove the actual code that was written. speccheck uses Lean 4, a functional language designed specifically for formal specification. Claude proceeded to write 1767 lines of Lean code to prove the spec (and found two issues there, that two spec reviews didn't) and 4511 lines of Lean code to prove the code.
You can read more here: https://t.co/CpWs65fBbk . The end result was pretty impressive: GPU-Quicksort can sort 1 Billion integers on MacBook Pro with M5 Max in under a 1 second! It is also 9X faster that parallel std::sort on the CPU! Built with speccheck: https://t.co/W1JJzTiWsN
Continuing on my yesterday post about speccheck (https://t.co/W1JJzTiWsN): a spec vibing tool. Here I want to cover one of many use cases for it: you vibed a tool for a while, but now want to make it production quality with a specification, and a test suite and hopefully reengineered for better maintainability and quality.
Let’s take one good example. Thomas Ptacek (@tqbf) writes about this here https://t.co/so2CTKSLyS - he needed a better Markdown viewer and decided to vibe code it himself. The result is at the same time pretty amazing and slightly dissatisfying once you try it: https://t.co/j4yXNJxwRP
The amazing thing is how beautiful and immediately useful the editor is. The disappointing thing is that it lacks the features that I need most for my work: solid LaTeX math support and rock-solid Mermaid diagramming support and for obvious reasons: Thomas vibe coded it for himself and his needs were different. Well, the first obvious thing to do here is to fork his repository, vibe code the missing features, and 17 commits later, submit a pull request, which I promptly did. But want you can do in addition to that is to run it through speccheck.
The process is: you start in original mdv repository and you ask spec-write to write a SPEC.md for you based on what a coding agent sees in the repo. You spec-review the result and iterate on the SPEC.md for a while. Then you create another directory, copy SPEC.md there, copy TYPOGRAPHY.md, which Thomas cordially provides, and a screenshot of the original MDV and you run spec-build (it is better to use a high quality model like Claude Opus, but cheaper models like DeepSeek V4.1 Flash also work well). It will take some time, since the specs-build will create a high-level implementation plan, then implementation plans for all the waves and then proceed to build exactly to your spec with two speccheck quality gates at the end.
What you get in the end is the almost exact clone of MDV, but with a full blown specification and a regression test suite and a much better internal code design, since the original accumulated plenty of technical debt via vibe coding marathons. You can see the end result here: https://t.co/v3X7gqkdN9 . You can then add features to it in a principled way, e.g. via spec-proposal process. For example, GitHub-style line citations and C++, Metal, OpenCL, JSON, Lua, Perl and Markdown (within Markdown :) ) are later additions. I think the result is a production quality code base that your mother will be proud of.
So read speccheck introductory article here: https://t.co/cG67QFB2bB
Try speccheck yourself here: https://t.co/W1JJzTiWsN
Let me know how it goes!
@badlogicgames You don't have to produce slop and you can even remediate it: you can spec vibe instead of vibe coding: https://t.co/9j1ZqbX5N6 and the code for it: https://t.co/lhdXVWfYsv . BTW, big thank you for making Pi a thing - I used it quite a bit for speccheck production
@pidotdev That you can do Specification Engineering by spec vibing: https://t.co/9j1ZqbX5N6 , and the tool is here: https://t.co/lhdXVWfYsv - BTW, comes with Pi installable skills :) Thank you for doing awesome job on Pi!
@milohoffman002 Well, in my experiments with speccheck the model still matters, though it matters less: Claude Opus produces higher quality results from the spec than DeepSeek V4.1 Flash, though the latter still does a very good job!
Over the past four years, I've shipped a lot of vibe-coded software. It feels great in the moment — but keep vibe coding the same project on and off for three to six months, and the technical debt piles up. Things start falling apart at the seams, and you end up playing whack-a-mole with bugs popping up in unexpected places.
So between Andrej Karpathy's vibe coding (@karpathy ) and Professor Andrew Ng's (@AndrewYNg ) more rigorous AI Engineering, there has to be a middle ground. I call it spec vibing.
Enter speccheck — a set of agentic skills that:
* write, review, and revise the spec (the document you hand your coding agent)
* plan the build in waves (small, verifiable increments rather than one big build)
* build against the spec
* then run speccheck as a final gate before you call it done
speccheck answers one question: do you have evidence that what the coding agent built fully satisfies the spec? It can check this two ways — mechanically (grep-like, fast but not very reliable), or using LLM-as-judge (local or remote). The coding agent iterates until your code is speccheck clean.
Read the intro: https://t.co/cG67QFB2bB
Try it: https://t.co/W1JJzTiWsN
It comes with an interactive installer and integrates with Claude Code, Pi, or OMP coding agents.
@aaapinen Thank you, @aaapinen ! The cools thing is that you can vibe code first, then use speccheck to extract the spec from the vibed code and more rigorously reengineer the whole thing from that spec.
@PazarkerShon :) Yep, I think Pareto principle applies here: if it took you X time to create a prototype, you are at least 4X time away from a finished product!
@DollarCars I rented a car on May 17th at Chicago O'Hare airport. Rental Agreement 968995996. The reservation was thru Orbitz package deal, so I assumed that I will be charged very little: I did ask for a toll device. However, I was charged $454.17!!! I feel cheated!