Personal blogs

I trained a small transformer from scratch in 1.5hrs on a 5090
Beats many LLMs, and scores the same as TRM/HRM

The solution is to write tests for features in such a way that they are independent of the code. I like to use the neural network test for this: Can you re-use the test suite if your entire software is replaced with an opaque neural network?

A good test suite is, first and foremost, a risk-mitigation measure.
Automated tests reduce the risk associated with changes to an existing codebase - most regressions and bugs are caught in the continuous integration pipeline and never reach users. The team is therefore empowered to iterate faster and release more often.

Pure test do little-to-no IO, they are independent of timings and environment. Less pure tests do more of the impure things. Purity is correlated with performance, repeatability and stability. Test purity is non-binary, but it is mostly discrete. Threads, time, file-system, network, processes are the notches to think about.

Don’t think about tests in terms of opposition between unit and integration, whatever that means. Instead,
Think in terms of test’s purity and extent.
Purity corresponds to the amount of generalized IO the test is doing and is correlated with desirable metrics, namely performance and resilience.
Extent corresponds to the amount of code the test exercises. Extent somewhat correlates with impurity, but generally does not directly affect performance.

Architecture the software to keep as much as possible sans io. Let the caller do input and output, and let the callee do compute. It doesn’t matter if the callee is large and complex. Even if it is the whole compiler, testing is fast and easy as long as no IO is involved.

Ruthlessly optimize purity, moving one step down on the ladder of impurity gives huge impact.
Generally, just let the tests have their natural extent. Extent isn’t worth optimizing by itself, but it can tell you something about your application’s architecture.

I used to load the full Oh My Zsh framework. Then I profiled my shell and found I was pulling in 150+ files to use maybe 10 features. The chef overcooks 👨‍🍳
So I stripped things back. Now I cherry-pick the OMZ plugins I need via Zinit, and fill the gaps with tools that do one thing well. The terminal is Ghostty with a six-line config, the shell is Zsh, and everything below is what makes it feel like home.

I no longer have a firm mental model of what they can do and how they work, which means each additional feature becomes harder to reason about, eventually leading me to lose the ability to make confident decisions about where to go next.

And so generating code is not necessarily the part that you need to worry about the most. Given enough context, agents can write the implementation and run the tests and inspect failure and revise code for us. We need to get to a place where we feel like there is enough of human taste encoded in the environment that we can trust what is being built, so that our human attention can be focused on the places where it’s needed most.

Global workspace theory,4 or GWT, describes the human brain as a collection of specialized modules sharing data through a central, limited capacity bottleneck. Most machine learning architectures already satisfy the first three indicators5 of this theory. However, they consistently fail to implement GWT-4, the requirement for temporal persistence. To address this, we use the framework of computational self-availability, or CSA. This describes a system where internal processing is available as an input to the system itself.

Delete Cargo Integration Tests

My solution to this problem is making the tests data driven. Instead of every test interacting with the API directly, I like to define a single check function which calls the API.

Comprehension debt is the growing gap between how much code exists in your system and how much of it any human being genuinely understands.

Cognitive debt, a term gaining traction recently, instead communicates the notion that the debt compounded from going fast lives in the brains of the developers and affects their lived experiences and abilities to “go fast” or to make changes. Even if AI agents produce code that could be easy to understand, the humans involved may have simply lost the plot and may not understand what the program is supposed to do, how their intentions were implemented, or how to possibly change it.

Reviewing AI generated code can be tough, especially if the code generated is solving a particularly complex problem. Even if the code is correct, it can be hard to understand how exactly it works. When working with other human programmers, I would generally ask them to walk me through their code, and I would ask questions about why they made certain decisions as we go. I wanted a similar process for reviewing AI generated code. After a lot of exploring, I've found a combination that works well for me.

the Unix / Linux Environment is a natural candidate, and could be turned into an Agentic harness with a few modifications.

An agent optimizing for passing tests will find ways to pass them. If the tests were written after the implementation, they are likely testing what the implementation happens to do rather than what it should do.

You cannot write a spec that survives that environment unless you deeply understand the architecture, the integration boundaries, the edge cases, the failure modes, and the invariants that must never break. The spec is not a prompt anymore. The spec is the product thinking made explicit.

The infrastructure that needs to exist to support this model at scale includes better automated regression detection, artifact-level validation that goes beyond diffing changed lines, reliable and fast environment provisioning, and guardrails that hold up under parallel workloads.

Agents run tools in a loop to achieve a goal

If you cannot articulate what success looks like in a way that can be evaluated, no amount of autonomous execution will produce it. Agents cannot clarify requirements they are never given. They will fill the gaps with assumptions, and those assumptions compound.

handwrite your user level AGENTS.md that holds your preferences, and treat your project level ones like a neural net. Give it a size budget and train it on the sessions that actually ran.

Every SaaS business will become a harness around a model, whether or not they’ve realized it yet.

Harrison’s 4 elements of an agent remain – the system prompt, planning tool, file system, and subgents – describing the core loop. This is the core loop the developer controls with the keyboard. The harness manages everything beyond this, the world the developer sits within.

If this continues, there’s a world where 3rd party harnesses become less valuable when used with frontier lab models because the 1st party harness behavior is already baked in. And there’s no longer a fine tuning escape hatch to generalize this behavior away.

The conclusion I draw is that empathy in these systems is not an inherent state but a manufactured quantity.

The scope of a change (the subject of the change) is the most important part of a commit.

I get pushback that falling inference prices will eventually bring us back to sending everything through the largest models. But I’m not so sure: those same gains will benefit the K3s and Qwens, and as we continue to develop better harnesses it will be easier to provide weaker (but still great) models with sufficient context to perform well.

It’s going to be funny if the network effects the AI labs have been searching for end up looking just like the network effects of the SaaS era. Coding harnesses, managing the environments around the agent, look a whole lot like the SaaS platforms of old.