How this was built
LLMs write good code. If you know what to ask for.
I built the whole design in conversation before I touched a line of code. Then I put it in front of a rig of seven models from seven different labs to fill in the gaps, argue with it, and build it, in sprints, editing the design as I went and learned more. This page is that process in full.
Knowing what to ask for is the job.
Point a good model at a vague brief and you get bad software very quickly. That has never been the model's fault.
Hand a model a real specification, with the failure modes already worked out and the constraints written down, and it will build you something solid. Ask it for "a login system" and you get the most common pattern on the internet, which is also the most commonly broken one. The whole gap between those two outcomes sits with the person writing the brief.
That is what actually goes wrong when AI-written software falls over. Nobody in the loop could say what it was supposed to guarantee, so nobody noticed when it didn't.
So the design is mine. I built the whole thing out in conversation before I touched any code: how the pieces talk, what each one is trusted with, and what happens when one of them is lying. Then I kept editing it as I went and learned more. What I did not do is treat the first version as finished, or expect to get all of it right on my own. I used the models to fill in gaps and pick holes in it, because having a lot of experience is not the same thing as being right about everything.
The research went the same way, which is to say I did it by telling a model what to go and find out. That part is Google with the results already read for you, and it only works if you know what to ask and can tell whether the answer coming back is any good. More than twenty years working on hardware and software is long enough for that, and to spot it straight away when what comes back is not what I asked for. It is not long enough to catch everything by myself, which is what the rest of this page is about.
Where the hours went. Not into prompting. Into deciding what the thing had to guarantee before anyone wrote a line of it, then proving each guarantee one at a time. That is the slow part of building software, and on something holding the keys to every machine you own, it is the only part worth being slow about.
Then I built it the way a company would.
Every piece of work starts as a build packet, written to disk before anything runs: the spec, the threat model it has to satisfy, the constraints, the files it is allowed to touch, and the tests it has to pass. Then it is sprints. Build, test, review, fix, repeat. Nothing merges until the tests that matter have been watched failing with the protection pulled out.
It came together fast, and that is the rig rather than shortcuts. This started as a research project and grew into a product, so the design kept moving the whole way through. Every packet taught me something, and when a build turned up something the design had not accounted for, the design changed and everything downstream of it got rewritten. That happened plenty of times, and it is a large part of why the thing is any good.
What the rig buys is that revising a design does not cost a month. A packet that arrives fully specified gets built and attacked while I am writing the next one, so nothing sits in a queue waiting on a person, and changing my mind about something structural costs a rewrite instead of a quarter. None of the six steps below were dropped to keep that pace up. They ran on every packet, including the four line ones.
Seven models, seven labs, each told to break what the last one produced.
Claude Opus orchestrates, three to five loops per packet. It writes the packet, hands the build off to another model, then checks what came back against what the packet asked for. Around it I wrote a skill that calls out to whatever suits the job: Codex, and through opencode anything on OpenRouter. MiniMax M3 does the cheap bulk building and a second read over the design documents. GLM 5.3, Kimi K3, Gemini and Grok all take turns attacking what the others produced, and every one of them has caught something Claude and Codex missed. That is the whole argument for paying more than one lab.
A model reviewing its own work agrees with itself every time. Two models from the same lab agree nearly as often. Seven from seven labs, each pointed at the last one's output and told to break it, do not.
What has to happen before code lands.
Same six steps every time, whether the change is a new subsystem or a four-line fix to one.
The threat model comes first
Before I decide how a feature works, I work out how it fails. Who would abuse it, what they'd get out of it, and what stops them. I drive that and the models do the legwork and the drafting, then get pointed at what they wrote and told to break it. That document is the contract the code is held to rather than a description of it, and the model gets handed it along with the spec. Here is what those documents say, and here are the documents.
The model gets a brief, not a wish
Spec, threat model, the surrounding code, and the constraints the change has to hold. Ask a model for "a login system" and you get whatever pattern is most common on the internet. Ask it for this one, with these failure modes already closed, and you get something you can check.
Models that didn't write it attack it
Every change worth the name gets read by models with no stake in the code, pointed at it and told to find the way in. The author model agreeing with itself is worth nothing. Four others failing to break it is worth a great deal.
A test that has only ever passed proves nothing
So I break the code on purpose. Pull out the guard, run the suite, and watch it go red. If everything stays green with the protection deleted, the test was decoration and it gets rewritten until it fails for the right reason.
I read the diff
All of it. A model that writes four hundred lines will slip a fifth condition into a function that needed four, describe the change correctly in its summary, and never mention it. Reading the summary instead of the code is how that reaches production.
Gates, then merge
Tests, policy checks, linters and type checks all run before anything lands. A suite printing ok is not proof by itself, so the ones that matter get pointed at a change that should have broken them, to confirm they still notice.
All six run inside the loop above, on every packet, not as a review pass bolted on at the end. The design documents get broken on purpose the same way the code does, and the loop does not stop until the models stop finding holes and agree the thing is sound.
Hey, I'm Kev.
I'm building adamance solo.
- Business
- gurutechnology.services
- linkedin.com/in/kev-w-35502359
I like taking things apart to see how they work, and breaking them to see how they don't. adamance is Go for the control plane, host agent and CLI, TypeScript and React for the web console, Rego for the policy engine, SQL for the schema, and shell for the installers. All AGPL-3.0.
Why I'm building it
Real talk: the hardest parts were already solved for me. adamance stands on years of brilliant open-source work, FreeIPA, Keycloak, OPA, step-ca, Wazuh, OpenBao, so I didn't have to reinvent identity or cryptography or policy engines. What I did do was pour months of obsessive, careful work into wiring all of it into one console and API a normal human can run, without the seams showing.
It's yours where it counts, too. It runs on your hardware, answers to you, and costs nothing per seat. Microsoft now ships an OS that screenshots what you're doing and jams Copilot into every corner, OpenAI trains on what you type unless you go find the setting and turn it off, and with Microsoft as its biggest backer, the two are fast becoming one operation that gets cozier with governments by the month. The software that decides who gets into your machines shouldn't be rented from whoever's closest to power this week. It should be yours.
(And yes, I built a lot of this with AI: mostly Anthropic, a bit of OpenAI, a dash of MiniMax. Biting the hand that autocompletes me, I know. But every major model got trained on humanity's collective work whether we agreed to it or not, so I'm aiming all that slightly-stolen brilliance at something that actually gives back to the world.)
The best part of all of this: Linux is free, and it doesn't spy on you. Neither do I. No online account you're forced to make. Signing in stays inside your own network, with no outside server to check in with and nothing phoning home. No ads in your file manager. Your computer just works for you. Getting more people onto Linux means more people who own their machine again.
Mostly though, I build it because it's fun, and every person who gives Linux a shot because of adamance is a win in my book. If that counts as a mission, then that's the mission.
Kev
You won't have to take my word for any of this.
When v1 ships, the whole codebase goes public on GitHub under the AGPL-3.0, every line of it, free for anyone to read and pick apart. A dedicated security proof harness ships with it and runs against your own deployment: it breaks a real dependency, checks that the running system refuses the thing it should refuse, then puts it back and confirms recovery. It writes down what it proved rather than a count of passing tests, and it will not record a pass for anything it could not tell either way. How that works. Every claim on this site is meant to survive being checked against that code. If one of them doesn't, I'd rather you found it and told me.
What I'm not claiming: nobody outside this project has audited it. No external reviewer has been through the code and come back with a verdict. When that changes I'll say so on this page, along with what they found and what I fixed. Until then you have the process above, and before long, the source.
It ships when it's ready rather than on a date. That means the mitigations in the threat model are implemented, an external review has been through it and its findings are closed, and every claim here has been checked against the code that's supposed to back it. The date moves before the bar does.
See the full spec sheet, everything under the hood