If you've shipped software in the last three years, you've probably watched your job description quietly rewrite itself. You went from writing code...
For further actions, you may consider blocking this person and/or reporting abuse
Nice read. An honest takeaway while deep thinking 🤔
The "right" intent should not be to replace deterministic logic, but to figure out how to orchestrate the two.
Use strict, unyielding code for the core engine (state, file management, calculations) and use the pattern-matcher purely as a fluid interface or data translator.
pretty much where I land too. Use AI for interpretation and flexibility, use deterministic code for anything that absolutely must be correct.
The through-line in that history is that every leap automated a layer of mechanism and left the judgment layer exactly where it was. Compilers automated writing assembly, frameworks automated boilerplate, and each time the prediction was that the skill would vanish, while what actually happened is the skill moved up a level to deciding what to build and whether it's right. AI writing software is the same move at a larger scale: it automates the producing, not the deciding. The history is reassuring and a warning at once, because the people who thrived across each leap weren't the fastest typists, they were the ones who owned the judgment the automation couldn't. That part still hasn't been automated, and it's still where the value concentrates.
That's a great way to put it. Every wave of automation seems to move the value up a layer rather than eliminate it entirely.
Both happening at once is what the layer split inside the history actually predicts. Theo Valmis's "producing vs deciding" cut below names half of it. The half worth adding: there is a third layer the history of AI has not automated either, which is auditing whether the decision was right after the fact. Producing automated, mostly. Deciding partly automated, mostly delegated. Auditing is still where consequence locality binds, and it is the part most agentic systems quietly skip because the demo only shows the produce-decide loop, not the layer that catches when the loop got it wrong.
That asymmetry is what makes the winter-or-transformation question read as both-at-once. The producing layer is transforming fast and cheaply. The deciding layer is moving but constrained by who actually pays when the decision is wrong. The auditing layer is mostly winter, because almost nobody is shipping verifier evaluations that test whether the verifier catches deliberate violations. Capability is scaling. Auditability is not, yet. The gap between "interactive capability" and the strong sense of autonomy the post carefully avoids claiming runs straight through that audit layer.
The line that stays with me on a second read: "it's powerful precisely because of how tightly that loop is engineered, not in spite of it." Same shape one floor up. Power lives in the loop discipline, and the missing discipline right now is the audit layer, not the agent layer.
Fascinating perspective, Mike. The asymmetry between scaling capability and lagging "auditability" perfectly explains why it feels like we're in a winter and a golden age at the exact same time. The loop discipline is where the real engineering is.
"Loop discipline is where the real engineering is" is the line I want to keep. It compresses the whole capability-vs-auditability asymmetry into something a reader can actually carry. The piece I keep coming back to is that loop discipline is also the only part of the stack that does not get cheaper when the model gets better. Better models tighten the produce side. The loop still has to be engineered, planted-fault tested, and maintained by somebody who pays attention. Capability inflation leaves loop discipline exactly where it was.
I like how each stage gradually shifted more decision-making from people to machines. Now the bigger question isn't whether AI can do something, but what we should still be responsible for ourselves:)
Agreed. Feels like we're slowly moving from capability questions to responsibility questions.
the "moved but not disappeared" framing for the inference cost bottleneck is the part worth dwelling on. running a model in a loop 100x per task is now affordable — but the same cheapness that lets you ship the agent also lets you ship it before you ship the observability for it. RAG plus structured tool calls running 50 iterations used to cost enough to self select for teams who could justify the infra. now any team ships it, which means more teams find out on iteration 47 that something drifted.
at what point do orchestration frameworks bundle step level replay and drift detection by default, vs. every team building that bespoke?
"Iteration 47 hits way too close to home. 💀 The fact that it’s now cheaper to run a loop 100x than it is to store and analyze the traces is the ultimate irony. Honestly, the first orchestration framework to bundle step-level replay by default is going to win a lot of developer hearts."