Every engineer shipping working software in 2026 uses these tools. Most accounts of how are either a sales pitch or a denial, so here is a real one.
What it changes
Throughput is the honest headline. I write more in a day than I used to, and I take on work I would have talked myself out of five years ago because the surface area looked too large to ever finish. Most of what I can show you exists for that reason.
It also changed how I explore a problem. I can stand up three versions of an approach, find out which one survives contact with real data, and discard two of them without having spent a week on each. That is a genuine change in how much design you can afford to do before committing.
What it does not change
The standard, and who is accountable for meeting it.
I do not type out every test by hand anymore. What I do is decide what has to be tested, what counts as covered, and whether what came back is good enough to ship. Those standards are mine, worked out years before any of this existed, and the tools have not moved them. The rest follows: I read the code instead of accepting it, I steer the work in small pieces I can check rather than asking for a system and hoping, and when it breaks at three in the morning it is my name on it and my problem to fix.
The model drafts. I decide.
Everyone says they review what comes back, so here is what that means when I do it. I built a harness that injects small faults into Go packages and counts how many the test suite catches. Run against spf13/cobra it scored 65.5 percent and gorilla/mux 79.3 percent, and in both the survivors included return err changed to return nil. In cobra, the line matching the argument terminator runs 78 times under that project’s own test suite and still accepts a corrupted comparison without one test failing. A suite that passes and a suite that would have noticed are different things, and telling them apart is the part of this job that did not get cheaper.
Three rules I do not break
Nothing goes out the door unless all three are true of it.
| I can explain it | If I cannot walk you through why a component works the way it does, without notes, it does not ship. Code that was merely accepted is code nobody owns. |
| I could rebuild it | If every one of these tools disappeared tomorrow, I should be able to write it again from the design. It would take me longer, and I could still do it. If that is not true, I did not understand it well enough to put my name on it. |
| I can maintain it | The test is not whether it works on the day it ships. The test is whether a subtle bug can be found and fixed in it eighteen months later, by me or by whoever owns it next, without an archaeology project. |
Where determinism matters
My tools are deterministic wherever determinism is possible. Where a model genuinely helps, it sits behind a flag you can turn off, and the tool still does its job with the flag off.
That is not a stylistic preference. An answer you cannot reproduce is not an answer you can act on, and a system whose behavior changes between runs is a system nobody can debug. The useful skill is not avoiding these tools. It is knowing exactly which parts of a system are allowed to be probabilistic and defending the line around the parts that are not.
How much AI goes into what I build
How much of this ends up inside the software is a design decision I make per project, not a default I apply to everything. My own tools land in three places.
| No model at all | A secrets CLI. A JWT service. A Kubernetes drift detector. These do deterministic work, and a model in the path would make them slower, more expensive, and impossible to reason about. There is no model anywhere in them. I used AI heavily to write them, and none of it ships inside the product. |
| Optional, guarded | Turn the model off and these still do their job. One rewrites text through a rules engine that costs nothing and returns the same answer every time, then offers a model pass for the judgment rules cannot make. Another searches an index that always answers, and reaches for a model only when you ask, on your hardware or someone else’s. The model is an upgrade, never a dependency. |
| Built for agents | Some things exist to be driven by an agent. Those ship an MCP server or an HTTP API beside the human interface, with the same behavior through both, so a person and an agent get identical results. |
Placing a project correctly is most of the work. Too far toward the model and you own something nobody can debug, that costs money per run, and that changes behavior underneath you. Too far away and you have shipped something less capable than it needed to be. Both are real mistakes and I have opinions about where the line sits.
Wherever a project lands, none of it breaks because a model was deprecated, repriced, degraded, or ruled out by somebody’s compliance team. That is cheap to design for now and very expensive to retrofit later.
The failure mode I design against
The thing people are right to worry about is a large, plausible codebase that lands in a repository nobody understands, written faster than anyone could read it. That happens now, and unwinding it costs more than writing it did.
Everything above is what stops it happening in my work. The design is something I can explain out loud. The code is reviewed and tested by the person who wrote it. The documentation was checked by running it rather than by reading it. Nothing load-bearing goes in that I could not write again from the design.
If you want an engineer who refuses to touch any of this, that is not me. If you want one who can tell you which parts of a system are deterministic, which parts are not, and why that line is worth defending, we will get along.
None of this is a claim you have to take on faith. The projects page is what came out of this workflow, and every entry links to the source.