My stance on AI
I graduated with a First Class BSc in AI from the University of Westminster in 1998 — while already working as a developer and architect, not as a student making a fresh start. For thirty-five years I have worked in production systems. For twenty-seven of them I watched the AI field specifically fail to deliver on its promises, rebuild itself from the ground up, and then deliver on them all at once in the space of about three years. Here is what I think now, as someone who uses these tools daily and has no particular reason to be either evangelical or afraid.
Honest assessments after daily use
These are my personal opinions formed from using these models in real work — Odin systems code, Linux desktop development, infrastructure, documentation. They are not benchmarks. They are what I have found true.
The one I reach for by default. Consistent, fast, honest about its limits. Does not argue. Does not invent. Gets the code written and gets out of the way. Sonnet is what a reliable senior engineer would be if a reliable senior engineer could type at ten thousand words a minute.
Used daily in Kat800 sessions for Amber Linux development.
Something different happens when Fable touches Odin code. It understands the allocator model, the foreign keyword, the multiple-return convention — without needing them explained each time. I do not fully know why. I know that when the problem involves Odin, Fable is my first call.
Specifically strong on Odin, Amber LIB package development, and systems code reasoning.
Impressively confident when wrong. Opus will invent APIs, fabricate documentation, cite papers that do not exist, and hold its position under questioning. The reasoning sounds excellent. The premises are sometimes fictional. I use it rarely, never without verification, and never in a production code path.
The danger is not that it fails — it is that it fails convincingly.
Good at code structure and relatively honest about what it does not know. The early Codex models that powered GitHub Copilot introduced many developers to AI-assisted coding. I liked the pragmatism — less philosophising, more function bodies. The newer Codex CLI continues that tradition.
Useful for code-focused tasks where you want generation without conversation.
The failure mode is subtle errors that look right. Not obviously broken code that fails immediately — plausible code that does almost the right thing, under most inputs, most of the time. That is the dangerous kind. In a codebase you actually ship, almost right is worse than clearly wrong. I do not use Gemini for production coding.
My assessment after testing in real scenarios. Your experience may differ.
The uncomfortable accounting
AI knows more about coding than I do
Not in every specific area. I have thirty-five years of depth in systems design, enterprise architecture, and production operations that no model currently matches for applied judgment. But in breadth of knowledge — languages, frameworks, libraries, patterns, obscure standards, edge cases in specifications — no human brain alive holds what these models have processed. I am honest about this.
AI writes code faster than I do
This is not close. I can think faster than I can type. AI can think and type simultaneously, at a rate I cannot approach. A function body that would take me ten minutes of careful writing appears in seconds. A full page's worth of boilerplate that I would have reached for a library to avoid — written, tested, and correctly handling the edge cases, in the time it takes me to finish the thought.
AI can write better code than I can — but not always
On a contained problem with a clear specification, a good model will produce code that is cleaner, more consistent, and better-tested than what I would write alone. I have seen Sonnet produce Odin code that I would not have written that cleanly in the first attempt.
Where it falls short: architecture across a large, real codebase. Understanding what a system actually is versus what the specification says it is. Knowing when not to write code. The judgment calls that come from having run thirty microservices without a major outage for eight years — the recognition of a design that will work for six months and fail on the seventh — that does not come from the model.
The collaboration produces better results than either alone. That is the honest position.
I like working with AI
I am not performing enthusiasm. The work is genuinely more interesting now. The tedious parts — boilerplate, documentation, test cases, scaffolding — are handled. What remains is the part that requires judgment: design decisions, production trade-offs, the integration of new capabilities into systems that real people depend on. That is the part I find worthwhile, and AI has given me more of it.
Running models locally on my own hardware
I run AI models locally on a machine I call the Spark, fitted with an RTX 5070 Ti. No API keys leaving the building. No data sent to a cloud provider. No subscription. No terms of service that change without notice. The model runs on my GPU, on my machine, in my home.
The frontier models — Sonnet, Fable, GPT-4o — are still significantly better than what I can run locally for complex code generation. I am not pretending otherwise. But the gap is closing. The local models available in 2025 are better than the frontier models were in 2022, and the trajectory is clear.
Sovereign AI matters for the same reason the Amber Linux project matters. If your tools require a cloud connection to function — to think, to write, to reason — then you are not using tools. You are renting a capability that can be withdrawn, rate-limited, repriced, or trained on your input without notice. That is not a foundation I want to build on.
Kat800's design anticipates this directly. An agent session is just a process with a PTY. The model running inside that session can be a cloud API or a local binary. The orchestration layer does not care. As local models improve, the only thing that changes is which binary gets called. The rest of the stack — KatKlips providing context, Amber LIB providing libraries, the Linux Mint desktop providing the environment — stays exactly the same.
Your data stays on your machine. Your model runs on your hardware. The capability cannot be withdrawn, repriced, or trained on your input.
I use frontier models for complex reasoning and Odin code generation. Sovereignty is not dogma — it is a principle that guides defaults.
AI will cost me my job. That is not AI's fault.
I will say this plainly, because I am tired of people in my position avoiding it: AI will displace skilled IT workers. It is already doing so. Roles that required senior expertise a decade ago can be performed by a junior with a good model and the judgment to verify its output. The number of engineers required to maintain a system of given complexity is falling. It will continue to fall.
My own role is not exempt from this. The thirty microservices I have run for eight years without a major outage represent the kind of institutional knowledge that used to take decades to accumulate and could not easily be replaced. AI has not replaced that knowledge — not yet, not fully — but it has made the knowledge more transferable, the work more automatable, and the case for a senior specialist weaker in every annual budget review.
I studied this in 1998. The economic displacement argument was academic literature in the 1990s — not a prediction about AI specifically, but a well-understood property of productivity improvements. When a tool makes labour more productive, the standard economic response is to use less labour, not to preserve employment at the same level and share the gain with the workers. We knew this. We built the tools anyway, because they are genuinely useful and because individual actors do not internalise societal costs.
The fault is not AI's. The fault is a societal failure to value free time. If I can do in two hours what previously took eight, the rational response — the response that would produce human flourishing — is that I work two hours and have six hours of free time, at the same pay, to do whatever humans do best when they are not doing what machines can do. The actual response, historically, is that I am expected to produce four times as much in the same eight hours, and when the business no longer needs four engineers to do eight hours of work, it hires one.
We do not value free time. We have built an economic system in which free time is available only when it is imposed — by unemployment, illness, or retirement — and in each of those cases it arrives stripped of the resources that would make it worthwhile. The productivity gains of every previous technological revolution followed the same pattern. I have no reason to believe this one will be different.
I am not angry about it. I am clear-eyed about it. AI is doing what it does. I will continue to use it, to build with it, and to think carefully about what human contribution looks like in a world where the machine can write the code. That question is more interesting to me now than it has been at any point in thirty-five years of working in this industry.
The people who know, know
This is not a fringe position. Germany's Federal Ministry of Labour runs a think tank — Denkfabrik Digitale Arbeitsgesellschaft — that has published scenarios for what generative AI does to work through 2030. Der Spiegel has covered think tank proposals for a universal salary for future generations as the structural response to exactly this displacement. The serious economists, the serious policy researchers, the people who spend their careers modelling labour markets — they are not debating whether displacement will happen. They are debating the scale, the timeline, and what to do about it.
What strikes me is the distance between that conversation and the one happening in most companies, where the plan is to use AI to do more with fewer people and call it efficiency. The institutions that think in decades are preparing for a structural shift. Most organisations are preparing for a better Q3.
What I think we should do with the time
If we are honest about the freed time — genuinely honest, not the corporate version where freed time means more sprints — then the question becomes: what do we actually do with it?
I have an answer. It is not original, but I believe it: we clean up the mess we have made. We are suffocating our world in rubbish — plastic in the oceans, pollution in the air, soil stripped of everything that made it productive. We have the labour capacity, if we choose to use it, to begin undoing that damage at a scale that has never been possible before.
And we build. We build the cities that people actually want to live in — not the ones designed around car throughput and quarterly development returns. We build schools that are beautiful enough to signal to the children inside them that their education matters. We build homes that are genuinely fit for human life, not the minimum viable shelter that a market optimising for yield produces.
The machines can write the code. The machines can run the logistics. The machines can handle the spreadsheets. That leaves the humans free to do what no machine will do well for a very long time: decide what kind of world we want to live in, and build it with our hands.