Matt's Homepage

I think this is a phase most experienced developers have gone through in the last 6-8 months and I think it’s worth mentioning so that we remember it in a few years.

This article is from the end of 2025 when AI was just starting to turn the corner from toy to tool. I remember many people, including myself, that tried AI solutions out and found them to be very limited for real production purposes. They were excellent for in-house QA or automating small tasks, but writing real production code was still very rough.

Many people, even midway through 2026, are still calling it all ‘AI slop’. Those days are now largely gone. Even expert Linux package owners recognize that AI assisted bug and vulnerability searching has turned the corner from toy to tool.

A reminder that the 5 stages of grief (and realizing AI is now an essential tool in all software development) are:

1. Denial: A defense mechanism that helps pace feelings of grief. It involves numbness or disbelief, protecting you from the immediate shock of reality.
2. Anger: A natural response to feeling powerless or overwhelmed. This anger can be masked, directed at yourself, or aimed at others, serving as a shield against the underlying pain.
3. Bargaining: An attempt to regain control of a situation. It often involves making deals or asking “what if” or “if only” questions to find a way out of the pain.
4. Depression: A deep, sometimes quiet sense of sadness. It is a natural reflection of the magnitude of your loss, where the reality sets in and you may naturally withdraw to process.
5. Acceptance: Coming to terms with the reality of the loss and understanding that your life will be different moving forward. It does not mean you are “okay” with what happened, but rather that you are integrating the loss into your life and learning to live with it.

How bad do the results of using less than full BF16 quantization get? Kaitchup just posted results of his benchmarks for Qwen3.8 27B for quants from different tests – from Q4 to Q1.

Below 95% accuracy recovery, I consider the degradation too large. At that point, you are probably better off using a smaller model at a healthier quantization level rather than forcing a heavily quantized 27B model to fit on your GPU.

Additional discussion here.

Tempest Levels 1-96 played by AI

After Nicholas Carlini’s famous talk at Black Hat conference this year, his predictions have become shockingly real. Critical bugs are being found at an alarming rate. This means patches are also coming at a never before seen rate – and system developers and software engineers must now deal with this historic flood of patches. How many? Most companies would release in the low double digits of bug fixes in a given period. Now we’re seeing hundreds – in mere days.

• Over 600 CVEs were identified in the Security Updates Guide across all of Microsoft’s products for July 2026 alone.
• Oracle dropped 1449 security patches in one week.
• 432 Linux kernel CVE’s were published in just one 24 hour period

None of this appears to be slowing – and we have AI to thank for it. AI is able to find bugs at a rate never before seen. It’s a reminder to the software development world, and especially security specialists, that they have been leaving a LOT of bugs and issues in some of the most secure software (BSD) that was undiscovered for decades.

Now people are talking about how to deal with astronomical numbers of patches coming out every week. It’s definitely something your production pipeline must be prepared for – because this will likely be the new normal for the rest of this year.

Recent security research demonstrates that open-weight AI models can be subtly poisoned or backdoored using a remarkably small number of malicious training examples. Attackers inject specific trigger phrases or corrupted data fragments into a fine-tuning or training set. Standard safety and performance benchmarks remain entirely normal, masking the underlying flaw. When a user’s prompt contains the hidden trigger, the model executes the malicious behavior, such as writing vulnerable code or opening a backdoor into the system.

This works well because it’s not like scanning for a virus, numerical model weights cannot be easily disassembled or audited. Downloading open weights locally keeps user data private, but it exposes organizations to black-box supply chain tampering.

How easy is it to do this? Apparently shockingly easy. Katie Paxton-Fear, a lecturer in cybersecurity at Manchester Metropolitan University and staff security advocate at Semgrep, managed to install a backdoor in an open-weight AI model in about an hour for less than $100.

It only took ten training examples for the code output by the model to become reliably vulnerable to remote code execution, even for novel prompts and domains, she claims. And the larger the model, the easier it was to poison.

This video shows you how to load models in Unsloth Studio – and how to share them locally and across the network. Using Unsloth Studio, you can download and use models directly (much like ollama – but it appears to be much faster since it seems to use llama.cpp under the hood. You can also host these models either locally on the same machine, or set up an external port and connect Claude Code or other cli from another machine.

Hosting a model in Unsloth Studio so another machine can connect to it involves a few easy steps. First, install Unsloth Studio on your host machine (with the big GPU and lots of memory). Then download and start the desired model in Unsloth Studio. After that, go to Settings -> API. Create a new API key. On your client system set up a batch file or environment variables then run claude from the command line:

> set ANTHROPIC_BASE_URL=http://<ip address of your server>:<port number>
> set ANTHROPIC_AUTH_TOKEN=<your unsloth api key - usually: sk-unsloth-d5134......>
> set ANTHROPIC_MODEL=Qwen3.8

> claude --model Qwen3.8 %*

People are trying it evaluate how good AI agents are by giving them a variety of tasks. Ars Technica decided to test different agents by telling them to make Minesweeper.

While now dated, how people are testing AI solutions is an ongoing problem. I do remember these early tests being a clear demonstration that AI was now capable of making working solutions from just vibe-coded slop.

Most keypad additions are largely gimmicks – but the Codex Micro AI keyboard has some interesting features (though I’m not sure it’s worth the $199 price tag).

The lighting portion is probably the most interesting. As you link AI agents to individual keys, each agent key has a multicolor LED that indicates the status as it works on your tasks. Blue is for thinking, green is for a completed task, amber is for items needing additional input or feedback, red is for errors, and solid white is for an idle agent.

There’s even a microphone button for voice prompts. The catch is the macro pad doesn’t actually have a microphone, so it triggers your current system default mic.

The clear polycarbonate border of the macro pad lights up to signal voice/mic status, with a sea-green color to show that the mic is live and recording, a white snaking effect to show that Codex is processing your voice prompt, or a simple solid-white glow to show that the prompt has processed fully.

Read more about it here.

Software development is converging in a way never before seen and Jaymin West gives us some of his observations from the bleeding edge.

AI quickly changed how software that used to take a whole team of software developers into something that could be autonomously generated with a single person using agents. This however, is just the first part.

What’s likely next is what some are calling software factories. Almost all major cutting edge developers such as Anthropic, Cognition, Cursor, Factory, Google, Github, OpenAI, and Ramp all seem to be working towards a factory system that continuously delivers and updates software.

Dark factories that run completely autonomously have been proposed, but experience shows things are not there just yet. West makes some observations from actual working systems people are trying and describes what people are doing – and gives a demo of his own factory.

This emerging software factory system , as supported by the foundation models, is made up of six components:

1. Queue: Work arrives as an issue, not a prompt
2. Control plane: A system that organizes all this information coming in and monitor the system in realtime.
3. Sandbox: One per task. Destroyed after.
4. Pull request: The output unit. Retrieved by a human. This is where dark factories fail – they’re simply not proving to work at scale with mission critical systems.
5. Event stream: Watch every action. Kill it without destroying the run.
6. Durable memory: The sandbox dies every run. Results not written to a file does not survive – so key run data must be stored as results that can be used.