Having run teams, as much as I love getting into the details of code I care about, in the 30+ years I've been in this business, I've only ever even seen a tiny proportion of the code my teams rely on.

And the non-technical people in these businesses will have seen none of it.

They all take it on a combination of trust and verification of outcomes that the code does what the developers claim it does.

Increasingly we're getting to a point where the output from these machines are more trustworthy than an increasing proportion of human developers, and more importantly: Increasingly often good enough.

Especially as more and more of the code becomes throwaway.

I have a side-project that is profitable, and that is profitable only because I haven't needed to spend time reading the code. If the code turns out to be unmaintainable? Doesn't matter - it's so cheap code that it is reasonable to just throw it away, and start over based on the lessons learned. It enabled me to take an opportunity to profit I wouldn't have been able to profit from if I had to set aside time I didn't have, so even if it was to totally fail in the future as a result of issues with that code it doesn't matter.

As the cost of good enough code falls towards zero, how we think about which code matters and how much we need to understand it will fundamentally change.

Increasingly, a lot of code is even just part of a conversation with an agent to me. It's throwaway, for the duration of a session. Who cares if it lives on?

I don't trust or need to trust most of the code I build any more. I trust the measurable outputs. The verification pipelines we build. The feedback mechanisms we build. Those I need to read and understand.

That's no difference than when working with a team. The only thing that is different is failure rates. And at this point, for some thing the machine failure rates are still higher, for others it is lower.

It ran like a dog. Few nights of running Fable (later Opus 5.5) with a 7 strong team of DeepSeek v4.1 Flash 1017 (don't mistake it with 0731 that is crap) and llama was running 10x faster and vllm was running even faster when before it would not work at all.

I've run similarity and needle tests and the results are exactly the same content wise. But 10x faster. I've relied on this for a month now and I'm pretty happy with how it runs.

Do I now need to learn CUDA Kernel programming to understand how it was done? I don't think so. It's for my personal use. Not for a paying client so no warranty is perfectly fine.

But I also use a lot of AI at work in an I dusty where people may die if the code is buggy. So I absolutely verify and understand everything.

There is a middle ground too. Understanding the architecture.

For example I used a bunch of DeepSeek models supervised by Qwen to build adaptive-acl. A pi coding agent plugin that deterministicly checks if every tool used by an ai during an agentic session matches user intent to give permissions for those actions (reading/writing data, network access etc), as a part of this plugin I run an llm, a classifier that runs over user's prompts and extracts these permission grants then saving them in a format deterministic layer can process.

The design includes massive number of assumptions and compromises. For example, if a user allows writing this implies permission to delete and reading if what was written etc.

The thing also includes over 4 thousand actual instances of tool use preceded by "permissions talk" from my live sessions and that whole collection can be run to test for regression etc.

At some point during one night the AI had a regression and decided the best way to resolve it would be to add regex based language processing elements to the deterministic layer (a huge no no, this has to work regardless of the user speak English or Swahili, also regexing natural language is a disaster waiting to happen).

I knew enough about the architecture to notice that and burn it out with a hot iron.

That is the problem with AI. It sometimes solves problems the easiest possible way causing massive issues for later. So if one uses it for important stuff it is good to understand the architecture and the plan of what it is going to build at the very least.