i came for the code, stayed for the outcomes. i feel in love with seeing people use my stuff and i began to like the software layers underneath. the top layer never gets old and the bottom later... well, it just keeps changing.
if you've done this long enough and you're generally normal, then, you know what it feels like to be absolutely bonkers over such-and-such language only to wake up 10 years later and wonder why you even memorized (some of) the syntax.
for those that are ai-pilled then you probably have been bouncing around models and agent harnesses a lot in the last year. the agents are now the language and they are going to evolve as your interest and enthusiasm will.
Thanks for reading! I love the language churn analogy.
There's a bit of a catch: syntax used to be deterministic. Agents aren't quite. The muscle memory we built learning Perl regex or Java generics was highly portable because it was mechanical - like we could eventually stop thinking about it and lose absolutely nothing. But working with agents is all about building judgment. It's about knowing when the AI in front of you is confidently wrong, and that gut feeling doesn't transfer to the next tool for free.
So yes, we need to embrace the new tools, but hold the tools loosely and your own taste tightly. The top layer of the stack stays interesting because it's the only place where you're still the one making the call (and taking the blame!).
This is awesome to see - thank you so much for putting it together! I'll definitely give it a proper watch this week. Its always fascinating to see how ideas survive the jump into a different format.
How should teams define an evidence threshold for shipping, particularly when the verifier may be incomplete or gameable? Should every loop have an explicit evidence contract tied to its risk level? There is a risk that people just rubber-stamp this whole thing.
How much of engineering taste can realistically be encoded into policies, examples or evaluators before it becomes another imperfect verifier that agents learn to satisfy? What should remain deliberately human and non-automated? Historically, engineers had a lot of intuition and tried and see what happens; now there is a big shift and having to "encode" these rules, or checks up front...
One non-obvious implication is that accountability is not just a control mechanism; it is what allows organizations to safely increase agent autonomy.
The rubber-stamp risk is exactly something I worry about too. I think it happens when "evidence" turns into just checking a box rather than actually updating our beliefs. The real test of an evidence contract isn't "did we collect the required proof?" It's: "If this change were actually terrible, what would the evidence look like, and would we have noticed?" If the answer is "it would look exactly the same" we might have a problem.
On your point about taste: we should definitely automate the falsifiable stuff - the things where you can be mathematically wrong (performance budgets, data contracts, etc.). But we have to leave the preferential, "taste" parts to humans. A verifier only knows the world you described to it yesterday, but the world moves. Taste is that human instinct that realizes your metrics are quietly lying to you.
Also, your last line nails the thesis better than I did. Autonomy isn't granted to a system; it's granted against someone's name. Accountability is what gives you the confidence to take your foot off the brakes. I'll read your post properly soon!
Thanks for the thoughtful reply. You and Paddo(https://paddo.dev/) have some of the best takes on AI engineering.
This line is particularly strong: “If this change were actually terrible, what would the evidence look like, and would we have noticed?”
It suggests that a good verifier must be designed around failure modes, not merely success criteria. Teams should describe both the evidence required to approve a change and the plausible failures that this evidence is expected to reveal. In that sense, an evidence contract is really a dual contract: what must pass, and what must become visible when something is wrong.
I also really like: “Taste is that human instinct that realizes your metrics are quietly lying to you.” That problem becomes harder as companies operate more products, features, agents, and layers of abstraction. Swati Tyagi’s post on AI dashboards makes a related point: averages often conceal the system’s worst behavior, so teams need multidimensional views, distributions, and heat maps rather than a single reassuring number: https://contextandchaos.substack.com/p/your-ai-dashboard-is-hiding-its-worst
This also makes me rethink code review. Reviewers should ask: “What evidence would make me reject this change?” If there is no realistic answer, the approval process may be largely ceremonial. In corporate life, things change, but people often follow the same process; perhaps here is where loop engineering can help rethink what's left...
Curious on your thoughts re: cognitive degradation. In my organization (and in my own experience), increasing delegation to agents is actively making people lose their ability to reason; it’s akin to a baseball pitcher turning into a coach and still expecting to be able to throw a fastball the way they did when they played.
Do you anticipate this is something that’ll be solved via model improvements (i.e. it’s okay if we lose our ability to reason granularity), or is it something every outer loop/software factory needs to build around?
I personally have to seek many levels of intentional friction in my own development process to stay close to the code and stay engaged. Maybe there’s a fixed cap/physical constraint to the velocity that organizations can build while retaining the ability to continue to build increasing complexity.
A few thoughts on it. A coach doesn't need to throw a 95mph fastball, but they do need to be able to see one instantly and know the grip was off.
At an individual level, losing the ability to pitch is fine. The organizational danger is that you can't manufacture coaches who were never pitchers. If an entire generation skips the pitching phase, we (might) get a cohort of leaders who can only evaluate what a model tells them is good.
This is why I don't think better models alone solve the problem - they might actually make it worse. The skill we're losing isn't writing code - it's our BS-detector. Better models make output look more plausible even when it's wrong, meaning the burden of detecting errors goes up exactly as our practice doing it goes down.
i see this a lot and i think it's actually a flawed mental model. more specifically, the conflation with a change of focus (literally and cognitively) and the ability to reason (or pay attention is another thing i hear a lot).
i think what people forget is that the human species in insanely adaptable. micro and macro evolution. we evolve from small, defenseless toads to people who are sitting behind manufactured silicon and typing random things into a prompt.
i think that people are scared of not only how fast things are changing — and we have an accelerated view of that for those in tech — but how fast we, ourselves, are changing.
change is scary. the velocity right now is blinding. when you give into this anxiety then you have very little room to think straight. i think that's what's creating "cognitive decline" — it's not the ability to reason but, when you're scared, you don't have much energy or time to think about anything else.
and this lost time is what needs to be used for building really great software.
Ultimately, this is the same career advice we've been giving juniors for as long as I can remember. The goal never should have been to be "just a really good code monkey" (although that's a great song). 🤓 The challenge of the future will be (the same as the past) obtaining enough skill with code to get to the next level of not coding as much.
agreed. had some interns start this summer and they were worried that there code wasn't good and that they didn't understand all of it. i asked them if it worked. they nodded. then i said great, now go ask Claude what the hell it did.
i came for the code, stayed for the outcomes. i feel in love with seeing people use my stuff and i began to like the software layers underneath. the top layer never gets old and the bottom later... well, it just keeps changing.
if you've done this long enough and you're generally normal, then, you know what it feels like to be absolutely bonkers over such-and-such language only to wake up 10 years later and wonder why you even memorized (some of) the syntax.
for those that are ai-pilled then you probably have been bouncing around models and agent harnesses a lot in the last year. the agents are now the language and they are going to evolve as your interest and enthusiasm will.
that's just the game. love it hard.
Thanks for reading! I love the language churn analogy.
There's a bit of a catch: syntax used to be deterministic. Agents aren't quite. The muscle memory we built learning Perl regex or Java generics was highly portable because it was mechanical - like we could eventually stop thinking about it and lose absolutely nothing. But working with agents is all about building judgment. It's about knowing when the AI in front of you is confidently wrong, and that gut feeling doesn't transfer to the next tool for free.
So yes, we need to embrace the new tools, but hold the tools loosely and your own taste tightly. The top layer of the stack stays interesting because it's the only place where you're still the one making the call (and taking the blame!).
Hi Addy, your great posts about loop engineering inspired me to create this video https://www.youtube.com/watch?v=iygAfBzGJ64
This is awesome to see - thank you so much for putting it together! I'll definitely give it a proper watch this week. Its always fascinating to see how ideas survive the jump into a different format.
Addy, another masterpiece.
How should teams define an evidence threshold for shipping, particularly when the verifier may be incomplete or gameable? Should every loop have an explicit evidence contract tied to its risk level? There is a risk that people just rubber-stamp this whole thing.
How much of engineering taste can realistically be encoded into policies, examples or evaluators before it becomes another imperfect verifier that agents learn to satisfy? What should remain deliberately human and non-automated? Historically, engineers had a lot of intuition and tried and see what happens; now there is a big shift and having to "encode" these rules, or checks up front...
One non-obvious implication is that accountability is not just a control mechanism; it is what allows organizations to safely increase agent autonomy.
I explored the same tension from a more operational angle—verification gaming, comprehension debt, stop conditions, and rollback—in my post: https://diegopachecotech.substack.com/p/loop-engineering
Thanks for the loop governance constructs/vocabulary.
Thanks for the kind words!
The rubber-stamp risk is exactly something I worry about too. I think it happens when "evidence" turns into just checking a box rather than actually updating our beliefs. The real test of an evidence contract isn't "did we collect the required proof?" It's: "If this change were actually terrible, what would the evidence look like, and would we have noticed?" If the answer is "it would look exactly the same" we might have a problem.
On your point about taste: we should definitely automate the falsifiable stuff - the things where you can be mathematically wrong (performance budgets, data contracts, etc.). But we have to leave the preferential, "taste" parts to humans. A verifier only knows the world you described to it yesterday, but the world moves. Taste is that human instinct that realizes your metrics are quietly lying to you.
Also, your last line nails the thesis better than I did. Autonomy isn't granted to a system; it's granted against someone's name. Accountability is what gives you the confidence to take your foot off the brakes. I'll read your post properly soon!
Thanks for the thoughtful reply. You and Paddo(https://paddo.dev/) have some of the best takes on AI engineering.
This line is particularly strong: “If this change were actually terrible, what would the evidence look like, and would we have noticed?”
It suggests that a good verifier must be designed around failure modes, not merely success criteria. Teams should describe both the evidence required to approve a change and the plausible failures that this evidence is expected to reveal. In that sense, an evidence contract is really a dual contract: what must pass, and what must become visible when something is wrong.
I also really like: “Taste is that human instinct that realizes your metrics are quietly lying to you.” That problem becomes harder as companies operate more products, features, agents, and layers of abstraction. Swati Tyagi’s post on AI dashboards makes a related point: averages often conceal the system’s worst behavior, so teams need multidimensional views, distributions, and heat maps rather than a single reassuring number: https://contextandchaos.substack.com/p/your-ai-dashboard-is-hiding-its-worst
This also makes me rethink code review. Reviewers should ask: “What evidence would make me reject this change?” If there is no realistic answer, the approval process may be largely ceremonial. In corporate life, things change, but people often follow the same process; perhaps here is where loop engineering can help rethink what's left...
Curious on your thoughts re: cognitive degradation. In my organization (and in my own experience), increasing delegation to agents is actively making people lose their ability to reason; it’s akin to a baseball pitcher turning into a coach and still expecting to be able to throw a fastball the way they did when they played.
Do you anticipate this is something that’ll be solved via model improvements (i.e. it’s okay if we lose our ability to reason granularity), or is it something every outer loop/software factory needs to build around?
I personally have to seek many levels of intentional friction in my own development process to stay close to the code and stay engaged. Maybe there’s a fixed cap/physical constraint to the velocity that organizations can build while retaining the ability to continue to build increasing complexity.
I really like your pitcher/coach framing.
A few thoughts on it. A coach doesn't need to throw a 95mph fastball, but they do need to be able to see one instantly and know the grip was off.
At an individual level, losing the ability to pitch is fine. The organizational danger is that you can't manufacture coaches who were never pitchers. If an entire generation skips the pitching phase, we (might) get a cohort of leaders who can only evaluate what a model tells them is good.
This is why I don't think better models alone solve the problem - they might actually make it worse. The skill we're losing isn't writing code - it's our BS-detector. Better models make output look more plausible even when it's wrong, meaning the burden of detecting errors goes up exactly as our practice doing it goes down.
On adding friction: totally agree :)
i see this a lot and i think it's actually a flawed mental model. more specifically, the conflation with a change of focus (literally and cognitively) and the ability to reason (or pay attention is another thing i hear a lot).
i think what people forget is that the human species in insanely adaptable. micro and macro evolution. we evolve from small, defenseless toads to people who are sitting behind manufactured silicon and typing random things into a prompt.
i think that people are scared of not only how fast things are changing — and we have an accelerated view of that for those in tech — but how fast we, ourselves, are changing.
change is scary. the velocity right now is blinding. when you give into this anxiety then you have very little room to think straight. i think that's what's creating "cognitive decline" — it's not the ability to reason but, when you're scared, you don't have much energy or time to think about anything else.
and this lost time is what needs to be used for building really great software.
Ultimately, this is the same career advice we've been giving juniors for as long as I can remember. The goal never should have been to be "just a really good code monkey" (although that's a great song). 🤓 The challenge of the future will be (the same as the past) obtaining enough skill with code to get to the next level of not coding as much.
agreed. had some interns start this summer and they were worried that there code wasn't good and that they didn't understand all of it. i asked them if it worked. they nodded. then i said great, now go ask Claude what the hell it did.