Every engineer shipping working software in 2026 uses these tools. Most consulting sites either avoid saying so or wave it off in a sentence. You are considering handing me systems your business depends on, so here is the real answer.
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 for one person. 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, and I am not going to pretend otherwise. 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. I worked them out years before any of this existed, and the tools have not moved them.
The rest follows from that. 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. When it breaks at three in the morning, it is my name on it and my problem to fix.
The model drafts. I decide.
A faster tool raises the cost of not paying attention. It does not lower it.
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 sell it to you. |
| I can maintain it | The test is not whether it works on delivery day. The test is whether a subtle bug can be found and fixed in it eighteen months later, by me or by your team, 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, nothing I hand you breaks because a model was deprecated, repriced, degraded, or ruled out by your compliance team. That is cheap to design for now and very expensive to retrofit later.
What this means if you hire me
The failure mode people are right to worry about is a contractor who generates a large, plausible codebase, hands it over, and leaves a team holding software nobody understands. That happens now, and unwinding it costs more than the original build did.
You get the opposite arrangement. The design is something I can explain on a call. The code is reviewed and tested by the person who wrote it. The handoff includes documentation your team can follow, and I am reachable afterward when they hit something surprising.
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 your system are deterministic, which parts are not, and why that line is worth defending, we will get along.
Questions about any of this are welcome before you sign anything. Email [email protected].