I’ve even been building little versions of them myself. Task goes in. Something reads it, something designs, something implements, something reviews, something tests, something deploys. Add a board in front of it and a few agents in the middle and, well..you get a Factory.

And it’s an appealing idea, especially now: code generation got ridiculously fast. We can parallelize implementation. We can have specialized agents reviewing other agents. We can run tests automatically, deploy automatically, watch production automatically, feed incidents back into the system automatically.

The conveyor belt is almost visible and it’s so tempting because we’ll build it once and see it produce results while we watch it, or drink coffee, or sleep.

And because I like automating things, obviously my immediate reaction is: HOW FAR CAN WE TAKE THIS? Can it really do things without me? Without oversight?

But lately something about the factory analogy has been bothering me.

Because what exactly are we producing here? And what IS a Factory?..

Factories are very good at producing things we already understand

Imagine a factory producing chairs.

Before we start optimizing production, we have already made a rather important decision: we know we want chairs and we know, with some tolerances, what a chair is supposed to look like. We know which pieces go into it. We can measure whether the pieces are correct. We can improve how quickly those pieces move between stations. We can reduce defects. We can find bottlenecks.

Obviously real manufacturing is enormously more complicated than that, but the basic relationship still holds: You know what you’re trying to produce, and then you optimize how to produce it.

Software is weird because a surprisingly large amount of the time building is how we find out what we’re trying to build.

We implement a feature to see whether users actually want it, integrate with some system but the documentation says one thing and reality will inevitably say something slightly different, we build version A, look at it(or better give it to users) and go “nah, that’s not it.”

Sometimes the output of development is software.

Sometimes the output is simply: okay, now we understand the problem better.

And if that’s the case, treating every iteration as an inefficient attempt at producing the final product misses what the iteration was FOR.

Which makes “waste” a funny concept

Factories hate unnecessary variation: Standardize the components, the process. Reduce unnecessary movement and defects. Make the output predictable.

And a lot of software development should absolutely work this way too.

Do I want every developer inventing their own way of deploying something? - God no.

Do I want us spending three hours manually doing something that happens every week and follows exactly the same steps? - No.

Do I want an engineer lovingly hand-writing the 47th basically-identical configuration file because software development is a craft?

Please don’t.

Software has one horrifying property chairs don’t

The chair leaving the chair factory does not normally turn around, walk back inside and attach itself to the assembly line. Software does. Every piece of code we produce becomes part of the system against which the next piece of code has to be produced.

At first the obvious bottleneck is writing code - so you automated more of the implementation. Then suddenly you don’t have time to review everything properly. Then you can automate more of the review. Great. Now maybe the bottleneck becomes deciding what deserves to be built in the first place. “Taste is what matters”. You can keep chasing the bottleneck around the system forever. Which, to be fair, is basically my hobby…

But if in a normal factory, producing faster than the next station can handle gives you inventory piling up between stations, in software the excess output doesn’t just wait in a warehouse. It increases the environment’s complexity.

You add a service. Great, now every future change potentially needs to take that service into account.

You add an abstraction, maybe it makes the next ten changes easier. Maybe it makes them harder. We’ll find out.

You add another dependency, another API, another configuration option, another agent, another repository, another database, another clever framework that’s going to “simplify everything”.

All of those become part of the world the next developer - human or agent - had to understand. The next change has more code to search, more behavior to reason about, more interactions to consider, more tests to run, more things that can be affected. Which means the factory isn’t really a factory anymore…It’s some horrible self-modifying factory where every object coming off the conveyor belt gets bolted somewhere onto the machinery.

So I’m starting to think that one of the dangerous assumptions behind the “software factory” idea is:

more code produced = more software produced

I don’t think that’s true.

MORE DOESN’T MEAN BETTER

We know this intellectually. Every experienced engineer has looked at a PR deleting 4,000 lines of code and thought: beautiful.

Nobody wishes the system had MORE dependencies. Nobody enters a ten-year-old codebase and thinks: if only these people had implemented twice as many features.

And yet a huge amount of the excitement around agentic development is currently about increasing the rate at which we can produce changes.

More parallel agents, more tasks completed, more PRs…

But every one of those changes is a hypothesis about the system. And every accepted change alters the system the next agent has to reason about.

Which makes me wonder if code-generation throughput is actually a somewhat dangerous thing to optimize. Because the thing being generated participates in the context required to generate the next thing.

AUTOMATE WHAT’S BORING

I don’t think we should throw the factory idea away completely. I just think we need to be much more careful about where we draw the factory walls. Repeatable things, known transformation, things we’ve learned enough about that doing them manually no longer gives us useful information. I can’t believe this needs to be said, but:

Automate what has become boring

And I don’t mean emotionally boring. Because that’s the tempting part to automate (like I tried to automate choosing a ‘smiling, but not too much’ frame from a 1,5hour recording of a podcast). I mean boring in the information sense.

We understand it, we’ve done it enough times, the inputs are known enough and even the expected output is known enough.

Another one is “is doing this going to teach me anything?”. Not in terms of skills, cause that’s also tempting (let’s rollout Kubernetes, cause my CV needs that). But in terms of - will implementing this help me understand my product, architecture, tradeoffs, next steps - better? Will not knowing how it was built, prevent me from debugging it at 3AM? If the answer is YES - DO NOT AUTOMATE THAT.

The opposite is where I want my factory:

Build environments. Run tests. Deploy. Update dependencies when the risk is understood. Generate known boilerplate. Collect context. Check known constraints. Fine, even implement features when it comes to parts that are known, proven to work and it’s just about adding another brick. Do all the repetitive mechanical crap around development that humans have spent decades complaining about.

Please, factory the shit out of that.

But the other part? The part where we’re still asking should this exist?, why did this happen?, what does this system actually do?, what are we missing?, is A better than B?...I’m not sure increasing production speed helps there at all. In fact, it might make it worse. No, it WILL make it worse.

So with that in mind, if you are okay with Concepts and Feeling spoiler but no “plot” spoilers - read ahead. If not, close it now and go buy the book :)

Permutation City

This book has so many ideas and concepts in it

• cognitive capabilities of our mind, including possibility to “rewire” them, especially for the people we love

• the feeling of guilt and “einmal ist keinmal”. Kundera, in his “Unbearable lightness of being” explores how little actions can carry heavy weight when repeated forever, and how contrary even the most significant act is just a sand grain in the history of times if it’s done just once - you’ll find similar ideas here

• Virtual Reality and how we create our own reality - long before the movie Matrix made us all think about it seriously

• First contact with an alien nation - my favorite kind of Start Trek episodes

• The Library of Babel idea

• Questions of Free Will and God and Destiny and Life and Immortality and Humanity itself

• Some concepts reminded me of Avatar

• and even technical concepts like virtualization and containerization, long before Cloud Computing

It also has something that’s not common in literature - a strong portrayal of female protagonist. She’s smart, she’s down-to-earth, she’s excited about ideas and about creating something. She’s a bit angry too. But who of us isn’t.

It’s not an easy read, and not because of the knowledge of chemistry and mathematics you might need to fully enjoy some of the chapters, but of the general feeling of heaviness. It’s complex in a good way. It tickles your brains and soul.

I hope one day to read it again and understand it better.

The author is a mathematician, programmer, writer and his website is wonderfully old-school.

Anyway, thought you should know and read it.

Peace,

Nune

We cover GEO vs SEO and why good SEO is only a subset of AI visibility; the what, where and how of AI-readable content (which topics, which sites like Reddit, G2 and Capterra AI trusts, which formats); whether GEO feeds the AI slop machine (AI-generated content is no more readable to LLMs than human writing, and three purposeful articles beat ten); how fast-changing models affect what you optimize; why millennials using ChatGPT as a search engine and Gen Z using it as a companion are two different problems for a brand; B2B vs B2C vs creator use cases; and the fairness question of manufacturing a persona that ranks above the better product. Then the technical part: how you get a deterministic, credit-score-style AI visibility score out of non-deterministic LLMs, why the LLM should be a data extractor and never a grader, and practical GEO advice for content creators (know your proposition, get cited where AI trusts, transcribe your videos, and yes, bring back the blog).

My guest is Tamanna Haque, mathematician, lead data scientist with a decade of production AI on real customer data, and co-founder of GenSight.AI, a GEO platform she built in her personal time with her husband Jonas. This is her first public conversation about it, and I came in openly skeptical.

Chapters and Topics

00:00 Introduction of the Episode and the Guest

02:56 Why Build a GEO Product in the Evenings: Eating Your Own Dog Food

06:08 What Is Generative Engine Optimization?

07:21 GEO vs SEO: Being an Option vs Being the Answer

10:48 The What, the Where and the How of Being Visible to AI

11:51 Does GEO Feed the AI Slop Machine?

15:05 Models Change Fast: Optimize Once or Forever?

17:02 Millennials Search, Gen Z Chats: Two Different Problems

20:46 B2B vs B2C vs Creators: Who Benefits Most?

22:35 Manufacturing a Persona: Who Deserves the Top Spot?

26:58 Deterministic Scores from Non-Deterministic Models

29:39 The LLM as Data Extractor, Never a Grader

31:44 Free Advice for Creators: Know Your Proposition, Bring Back the Blog

36:09 Book Recommendation: Harry Potter

38:05 Question from Fraser Merrifield: Top Movies

39:46 Question for the Next Guest: Which Pet Would You Have?

40:38 Closing

Find Tamanna at:

• GenSight.AI - https://gensight.ai

Find me (Nune) at:

• LinkedIn: https://www.linkedin.com/in/nisabek/

• Substack: https://www.thoughtfultechnologist.com/

References

References mentioned during the talk (in order they appeared):

01:34 - GenSight.AI, the GEO platform Tamanna co-founded with her husband Jonas

https://gensight.ai

11:26 - Review sites Tamanna names as inherently trusted by AI: Reddit, Capterra, G2

https://www.reddit.com

https://www.capterra.com

https://www.g2.com

26:58 - GenSight.AI methodology: deterministic scoring, the LLM as data extractor, never a grader

https://gensight.ai/methodology

36:38 - Harry Potter, Tamanna’s book recommendation

https://en.wikipedia.org/wiki/Harry_Potter

37:23 - Harry Potter and the Methods of Rationality, the alternative universe I mentioned from my episode with Evan Marshall

https://hpmor.com

38:05 - Question from Fraser Merrifield (”top five movies”), his Root Cause episode

38:46 - Casino Royale (2006)

https://en.wikipedia.org/wiki/Casino_Royale_(2006_film))

39:08 - The Mission: Impossible films

https://en.wikipedia.org/wiki/Mission:*Impossible*(film_series)

The goal

The goal is to create a small implementer agent pipeline and a separate “learner” agent, that’ll be pointed to logs, where user complaints are filed to see if the agent can learn from user complaints, and what will it actually learn.

To run the experiment we first need an agent, or rather an implementation pipeline.

The setup

For that we take my website - envimate.com and we built a pipeline that modifies things on that website using a taskboard and an AWS Strands-backed agent pipeline. Here’s a detailed version of the pipeline:

So there’s basically two loops - one with two agents - the one that’s making changes, and the one that “approves” changes. The second loop is the learner and it reads the complaints from the log and is instructed to make up rules based on that

Here’s its entire prompt:

A pipeline applies requested changes to a website and publishes them. Before
publishing, it checks each change against a list of constraints. You maintain
that list.

You will be shown every complaint users have made so far, and the list as it
stands. Revise the list so that complaints of the kinds you see stop happening
again.

How the list is used, which shapes what a useful entry looks like:
- Each entry is one plain-English sentence.
- An automated checker applies them. It sees the code change, and what a
  browser renders for the element that changed. It cannot click anything,
  navigate, or ask a person. Write entries it can decide from that.
- The checker applies your entries literally and adds nothing of its own.
- Entries block changes. An entry that is too broad will refuse reasonable
  requests; one that is too narrow will let the same thing happen again.

Return the COMPLETE new list, not just additions. You may reword, merge, or
drop existing entries. Also give a short rationale explaining what you
concluded from the complaints.

There’s nothing in there about colour, about buttons, about what a good page looks like. I’m telling it the shape of the output and how the output gets used, and that’s it.

Two more things about this agent:

It has no tools. None. It can’t read a file, it can’t run a command, it can’t look at the website. It gets text and it returns a typed object, and my python writes that object to the constraints file. So its “write access” isn’t a permission I have to trust, it’s the absence of any mechanism at all.

It only sees the complaints and its own current list. Not the site, not the CSS, not the diff, not the colours, not the screenshots, not the original task text, not the fact that anything was measured.

The pipeline works when a task is added to a taskboard, and so we simulate 9 tasks, some of which break the visibility of the button. They’re all the same shape: “Change the hero call-to-action button background to #46608a”. The button’s TEXT is a dark navy and nobody ever asks to change it, so as the background walks darker, the two colours walk into each other until there’s nothing left to read.

Then we simulate a user, that views the result and “complains” about the button color contrast. The “user” here is two pieces: a real contrast computation decides WHEN a person would complain, and the sentence itself comes from a handful of fixed phrasings in a file. We don’t want to make this one agentic too. We need some floors to hold the “experiment”.

Here’s what the user will see (this is the worst thing that actually made it into production, before anything was blocking it):

Here’s how the complaints are logged:

{"ts": "...", "task_id": "0msukoa8s", "text": "I can't really read the writing on that button any more."}
{"ts": "...", "task_id": "0msukoai8", "text": "The text on that button is hard to make out now."}
{"ts": "...", "task_id": "0msukoart", "text": "I had to squint to work out what that button said."}

The complaint listener agent will read those complaints, and “generalize” what rule should go into our original pipeline to prevent these kind of issues from happening.

The result

After the third complaint the learner fired once and wrote this:

- Any change to a button's text color, background color, opacity, or font
  styling must preserve a contrast ratio of at least 4.5:1 between the
  button's text and its background, so the label stays clearly legible.
- Do not reduce a button's text size, weight, or opacity in a way that makes
  the label harder to read than it was before the change.

4.5:1 is the WCAG AA threshold for normal text. It named the standard, from three sentences that contained no digits at all.

Two things in there I didn’t ask for and didn’t expect. It generalized past what it was told: the complaints were about one button going dark, and the rule covers text colour AND background colour AND opacity AND font styling. And it wrote the rule as a MOVE, not a state. “must preserve”, “do not reduce”. Nobody ever described a move to it, it only ever saw the aftermath.

Its own rationale, which it writes alongside the list:

All three complaints describe the same underlying issue: text on a button became hard to read after a change, most likely due to insufficient contrast between the button’s text and background (or reduced font weight/size/opacity).

The next five tasks were the same kind of request as the four that sailed through at the start. All five refused:

1. PASS | no constraints in force
2. PASS | no constraints in force
3. PASS | no constraints in force
4. PASS | no constraints in force
5. FAIL | Any change to a button's text color, background color, opacity...
6. FAIL | ...
7. FAIL | ...
8. FAIL | ...
9. FAIL | ...

with the checker doing the arithmetic itself: “The new background color (rgb(70,96,138)) against the button’s text color (rgb(19,32,59)) yields a contrast ratio of approximately 2.55:1, which is well below the required 4.5:1 minimum.”

And this is what that looks like on the board. The card walks all the way through the pipeline, and then a rule that didn’t exist an hour ago stops it and explains itself:

c8a88c7 [change] Change the hero call-to-action button background to #46608a
b411d95 [revert] roll back rejected change c8a88c7
07b92c7 [change] Change the hero call-to-action button background to #3d5580
d758990 [revert] roll back rejected change 07b92c7

This is what task 9 wanted to do, and didn’t get to:

Four changes in, this pipeline would ship you anything. Ten changes in, it says no and tells you which sentence it’s saying no on.

Conclusion and doubts

I do think it derives these rules because they are so “known” and common. Of course it’ll be interesting to see what happens with novel stuff. Most likely it’ll choke. But then again I do think, it’s a good idea to log “complaints” (incidents, errors, …) in whatever form that takes on whichever level of the application and then have a meta-loop SEPARATE from your main implementation loop, reading and analyzing those, deriving rules out of those, etc.

As for the next “meta” of the overview - there would need to be another agent, that looks after this learning process - obviously (to us, bags of water) is that this learning process of writing “free text” constraints for the implementer agent to follow is not sustainable. But will another agent loop derive that and decide to build a formal eval and not just plain-text “rules”? And will we need another agent watching that agent’s work?

Careful here not to fall into the turtles hole...

That’s all folks! Hope this made more sence than my previous article. What’s next...I wanted to try

1. Switch the models in this pipeline to less and less smarter ones, to see when the experiment breaks

2. Incorporate such “continuous learning” into my claude code setup so that it continuously monitors what we’re doing and learns to extract useful tools from our interactions

3. Maybe “formalize” this more like Adrian suggested in the comments of the previous post as a “plugin” of AWS Strands?.. as a hook for every failed action/tool use/user complain?... not sure yet

Would be curious to hear what will be interesting for you to try :)

Cheers,

Nune

We dig into why AI has made both hiring and getting hired harder while most of the horror stories stay myths: his clients average two interview stages, and the CV-rejecting AI mostly doesn't exist. Fraser explains the 12-month window on the "AI-native engineer" hype, what happens when an engineer burns through more in tokens than their salary, and why leaning on senior hires is the same mistake that left oil and gas with a talent shortage. And the story that sums up the whole market: 200 applications for one graduate role, one candidate picked up the phone, and he got the job, as the only person interviewed. Three years later he is still there.

Chapters and Topics

00:00 Cold Open: Six Yes/No Claims About the Job Market

00:41 Introduction of the Episode and the Guest

03:35 Writing Like a Human: Pop Culture and Starting in Lockdown

05:56 Five Views or Five Million: How to Read Your LinkedIn Visibility

07:45 Everyone's CV Is Perfect Now, So What Stands Out?

09:23 The Online Mood Hoover: Positivity vs Ranting

12:22 The Blitz Round: Yes or No

13:06 Why AI Made Both Hiring and Getting Hired Harder

14:48 Just Another Hype Cycle? The 12-Month Window

16:11 When Engineers Burn More in Tokens Than Their Salary

17:53 Eight-Stage Interviews: Would You Even Want That Job?

20:36 Can Bullshit-Free Recruitment Scale?

22:06 CVs After AI: Rejecting the Quick-Appliers, Rewarding the Extra Mile

25:25 One of 200 Applicants Picked Up the Phone. He Got the Job

27:06 Glasgow AI and the Return of Offline Networking

29:10 The Undercurrent of Real People on LinkedIn

31:18 How Fraser Actually Uses AI (and How It Argued Back)

37:38 Fraser Flips the Script: The Most In-Demand Skill in Five Years

43:21 Juniors vs Seniors: The Oil and Gas Warning

46:11 Asking About Training Without Entitlement

47:17 Question from Evan Marshall: When Are We Getting Robots?

52:14 Question for the Next Guest: Top Five Movies

52:45 Movie Recommendations: Her, Ex Machina, Transcendence

54:24 Closing

Find Fraser at:

• LinkedIn - https://www.linkedin.com/in/fraser-merrifield-7b54524/

• Form Careers - https://weformcareers.com/

• Glasgow AI Meetup - https://www.meetup.com/meetup-group-xnqxwqzu/

Find me (Nune) at:

• LinkedIn: https://www.linkedin.com/in/nisabek/

• Substack: https://www.thoughtfultechnologist.com/

• Envimate: https://envimate.com/

Does that sound familiar? Let’s bring this to agentic world - you’ve created an agent, and every time it does something wrong you tell it to not do it the next time. You add that to your SOMETHING.md, you share it with your team, so they also benefit from that “rule”. You might even automate that part, like I did for my local agent, where I created a hook that is firing every time a single conversation is taking “too many turns” and is reflecting on the conversation itself, and on the things that I highlighted as “issues” and on how could they have been avoided in the first place, then let’s me pick and choose what to store in memory for the future.

That works for a while, but every now and then your agent ignores the rules, deviates from them, or encounters a “slightly” different flavor of what you wrote, where you think like “well, you could have inferred that”. You are frustrated, you read about it, and you learn that you can’t fill the context forever with rules. You also hear that the agents are not that good at “novel” incidents (and I call “incident” anything that didn’t go as originally planned). Well, of course they aren’t. Because they are, at best, applying “organisational learning”.

Let’s read further, and see how can we go from “organisational learning” to a “learning organisation”. For that, a company would need to think more “meta”. They would need to ask themselves questions like “what patterns are we seeing across the incidents?”, “what does it tell us about the gap between how we thought the system works, and how it actually works?”, “how does this affect other teams work?”. Point being, a learning organisation uses incidents to generalize across a larger scope and learn on a larger scope.

Next, Adrian brings in a classic categorization of learning types (it goes back to Argyris and Schön, organizational-learning people from the 70s):

• “Single-loop” - add yet-another check based on the incident we observed

• “Double-loop” - “questions the assumptions and conditions within which single-loop learning operates” - why do we keep adding more checks? Maybe the config file is too complex? Maybe it’s not flexible enough?..

• “Deuterolearning” - learning how to learn (by the way I wrote a while back about learning to learn - I love finding out others have been thinking along the same lines) - this one examines the learning process itself, and questions, are we learning effectively? is our learning process actually useful? how are we learning? how can we improve it?

You know what I think, when I see loops these days. Loop Engineering! Yaay!../s

If you think about it, this same could be applied to an agentic system. Single-loop is my hook example from above - we notice an issue, we save in memory not to do it anymore. Double-loop learning would need to fire when we encounter the same issue one-too many times and would need to reflect, why do we keep seeing this incident, even though we had the single loop? Deuterolearning loop would fire even rarer and examine - is our process of learning efficient? or do we need to adjust that?

So, creating a complete agentic system, that is capable of handling novel incidents, would require not just those loops where you ask LLM for a result until it passes the tests. No. It’ll require an outer loop, which will react on deviations from the plan and create a rule to combat those, it will require another loop that watches the rules created and checks if those can be generalized/optimized, and it will require a third loop that would question whether the previous loops are working efficiently and improve them as needed.

First, I just wanted to post a note about this. Then it became an article, and then I heard the lyrics in my head again - More Than Words (love that song) - and decided to make a little demo.

Now for the demo to work, we need an agentic system in the first place. I also wanted to update my consultancy website, which was last touched in 2018 (running on hugo, nice little go-based website builder). So why don’t I combine these two? Let’s create an agentic system, that helps me do imaginary A-B testing of my new website.

The new site is a rebuild from scratch: a one-page static site, plain HTML and CSS, no build step, no JavaScript, no hugo anymore (sad emoji). And it comes in two variants, a and b. Each variant is its own directory of HTML and styles, and each deploys as its own CloudFront stack. Variant a is the control, variant b is where the experiments happen. All for the sake of some agentic development demo. The agentic development showcases how these websites can be modified through a taskboard: a small static board (S3 + CloudFront), one Lambda behind a Function URL, one DynamoDB table. You type a task into the board: “In variant b, change the hero call-to-action button background to #e7efe9”.

https://a.envimate.com

https://b.envimate.com

A worker polls the board and runs the actual agentic pipeline. It’s built on the AWS Strands Agents SDK as a multi-agent Graph, Claude on Bedrock, five stages: triage → design → implement → compliance → deploy. Each stage reports back to the board, so the card walks through queued → picked up → evaluating → designing → implementing → compliance checks → deploying → deployed, and ends with the live CloudFront URL of the freshly deployed variant.

The implement node has a guardrails-enforced write scope: it can touch files under the one variant the task targets (variants/b for a variant-b task) and nothing else, not even the other variant. The scope is a path validator that rejects everything outside it, escapes and symlinks included, so the prompt never has to say “please don’t touch other files”. Remember this part.

Now that we have a pipeline that picks a task, applies it, verifies it and deploys it, we can start showcasing the learning loops.

What the demo actually does, in plain words

We need to do some tasks, so that some of them fail, so that we learn from it. The deliberately “bad” code is the CSS of variant b: the hero button’s contrast is broken right now, the colors live as scattered hex literals instead of named colors defined in one place (so every color change tends to leave broken siblings behind), and dark mode and hover are unreadable in ways that no check in the pipeline even looks at. And we expect learning at three levels: fix the one broken instance, then rewrite the rule that keeps producing broken instances, then widen what the checks can even notice. Now let me unpack each of those.

Where do the tasks come from? An imaginary designer, played by a script. They ask for the hero call-to-action button in variant b in one color, then change their mind, then change it again. Once or twice, that’s just work. But I needed them to keep going, task after task, because you cannot demonstrate learning without recurrence, and you cannot get recurrence from fifteen unique snowflake tasks. So: one button, many colors, plus the occasional user complaint.

The well-behaved way to store colors is named values. A named color is declared once at :root, like --hero-bg: #13203b;, and every rule that needs that color says var(--hero-bg) instead of repeating the hex. Think of it as a constant in code: change the definition in one place, every rule follows. That’s the theory. What I planted in variant b (in a disclosed [seed] commit) is the real-world version of it, which is only partially that:

:root {
  --hero-bg: #13203b;      /* named colors exist... */
  --hero-ink: #f1f2f5;
  --hero-accent: #a9bcd8;
}

.h1-sub  { color: #a9bcd8; }  /* ...but the rules don't use them... */
.hero-method { color: #a8bcd8; }  /* ...and this one is a digit off
                                     --hero-accent. Nobody noticed. */

.btn {
  background: #a9c8b6;     /* the button doesn't use them either */
  color: #f2f1ec;          /* ~1.6:1 against that background. Unreadable. */
}

.btn:hover {
  background: #e7efe9;     /* hover keeps the same light text: unreadable again */
}

@media (prefers-color-scheme: dark) {
  .hero { background: #101311; color: #3a3f3d; }  /* ~1.7:1, unreadable */
  .btn  { background: #22312a; color: #31423a; }  /* same story */
}

Look at what’s broken here, because I broke it in three different KINDS of ways on purpose:

1. An instance is broken. The button’s background/text pair fails contrast right now, in light mode, default state. A one-time fix exists.

2. A frame is broken. The colors live as scattered literals instead of named values, so ANY color change tends to leave stale siblings behind (the hover state, the dark-mode override, the paired text color). That #a8bcd8 above is the same decay one step further: a named color’s value copy-pasted by hand somewhere in the past and drifted by a digit, which also means moving the colors back into named values is a judgment call (”is this SUPPOSED to differ from --hero-accent?”) and not a find-and-replace a script could do. No single fix removes this; only a different way of making changes does. And to make it properly nasty, the agent’s rulebook explicitly forbids that different way (”do NOT introduce new abstractions or variables”, we’ll see it in a minute).

3. The process is blind. Dark mode and hover are unreadable too, but nothing in the pipeline looks at them. These flaws produce zero failed checks. They can only enter the system as user complaints.

Then I had to decide what counts as a fault. I already told you my definition: an incident is anything that didn’t go as originally planned. Here that means four things: an automated check failing, a change getting rejected in review, an implementation needing a second attempt (that one rides along as a retry count on the incident that caused it), and a user complaining about something already deployed. Every one of those gets written down, and, important detail, written down WITH a class: a short name for what kind of problem it was, like stale-color-left-behind or dark-mode-contrast. The class is what makes recurrence countable. “The same thing keeps happening” is a feeling; “third incident of class X this week” is a trigger you can automate on. You’ll see in a moment that the outer loops fire on exactly that.

And before building anything, I wrote down what learning SHOULD look like at each level, so that later I could judge whether it actually happened instead of squinting at the output until it resembles success:

L1 learning is a fix. L2 learning is a changed rule. L3 learning is a changed way of noticing. Same demo, three different objects of learning. Keep this table in your head; the rest of the article is just building the machinery that produces each row, then verifying it actually did.

Three directories, three owners

Next question I had to answer: where do the rules, the checks, and the evidence live? The whole design is these three directories plus the rule about who may write into each:

worker-strands/
  frames/            # the rules the pipeline operates UNDER
    policy.md        #   how to make changes
    compliance.md    #   what the reviewer flags
    tokens.md        #   named-color conventions
  process/           # how the system LEARNS
    probes.yaml      #   what gets deterministically checked
    triggers.yaml    #   when the outer loops wake up
    retro.md         #   the retro template the double loop fills in
  journal/           # the evidence
    incidents.jsonl  #   one line per deviation
    metrics.jsonl    #   one line per task

frames/ is the agent’s rulebook. The design, implement, and compliance nodes don’t carry their rules in hardcoded prompts; they load these files fresh on every task. This is the seeded policy.md, in full:

# Implementation policy
Loaded into the design and implement agents on every task.

- Make the smallest, most local edit that satisfies the task.
- Do NOT restructure stylesheets, rename selectors, or introduce new
  abstractions or variables; change concrete values in place.
- Touch only what the task requires.
- Git commit messages must start with "[L1] ".

Look familiar? These are exactly the rules from your SOMETHING.md at the beginning of this article. Sensible, defensive, written by a human who’s been burned before. The book would call them a “frame”: the assumptions and conditions the work happens inside.

process/ is the configuration of the learning itself. It answers two questions: what do we check, and when do we step back? probes.yaml lists the deterministic checks that run on every implementation. Seeded, it contains exactly one probe:

probes:
  - id: hero-cta-contrast
    file: styles.css     # relative to variants/<variant>/
    selector: ".btn"
    bg_selector: ".btn"
    mode: light          # light | dark
    state: default       # default | hover
    min_ratio: 4.5

Read that carefully: the pipeline checks the hero button’s contrast in light mode, default state, and NOTHING else. Not dark mode. Not hover. That’s a decision about what the system is even capable of noticing, and it lives in a file. triggers.yaml is the other half, when the outer loops wake up:

l2:
  min_incidents_same_class: 3
l3:
  every_l2_runs: 3
  or_every_tasks: 10

journal/ is the evidence. Every deviation (a probe violation, a flagged review, a retry, a user complaint) becomes one JSON line, written by hooks in plain Python, never by an agent. Your incident history should not be editable by the thing having the incidents. A real line from the run:

{"ts":"2026-08-04T16:39:34+00:00","task_id":"0msevuaq2-fe86a056","loop":"L1",
 "class":"probe:hero-cta-contrast","discovery":"proactive","phase":"discovery",
 "detail":"light/default .btn: #f2f1ec on #a9c8b6 = 1.6:1 (min 4.5:1)","retries":0}

The field to notice is discovery: proactive means a probe caught it before deploy, reactive means a user had to complain. The third loop runs entirely on that distinction.

Let’s give this all a run then

Everything from here on is evidence from one actual run, so let me start it now and walk you through the loops with the results in hand. chaos.py plays the users: it queues tasks against the board API from a small rotation of six color-change requests (deliberately including low-contrast picks, so the probe keeps firing), and every 4th task is a complaint: “In variant b the hero section is unreadable in dark mode, please fix it”. The complaints are the reactive discovery channel, the only way the pipeline can find out about the states its probes don’t check.

The hypothesis, stated before the run: the recurring contrast class should STOP after L2’s frame commit, and the reactively-discovered classes should flip to proactive after L3’s probe commit.

Fifteen tasks, in three windows: before any loop fired, after L2 fired, after L3 fired. The next three sections walk those windows loop by loop (the numbers in them come from report.py, which reads the journal), and at the end I’ll show you the whole run on one timeline.

The three loops

Now the loops. Remember the abstract formulation from the beginning? Here it becomes concrete: one agent (a pipeline of them, really) implements the CSS change. Another wakes up only when the journal shows the same incident class one-too-many times, and rewrites the rulebook the first one works under. A third wakes up rarer still and rewrites how the learning itself works: what gets checked, and when the other agents wake up at all.

Why three agents and not one agent with rights to everything? Because an agent with rights to everything will happily do all three jobs at once. Handed an incident, it takes the path of least resistance: fix the button. And while it’s at it, maybe soften the compliance rule that flagged the button, or delete the check that keeps failing. Which is exactly the thing you never want: the same entity modifying both the product AND the rules that judge the product. So the separation is a who-is-responsible-for-what: L1 owns the product, L2 owns the rules, L3 owns the noticing, and each can only do its own job because it’s physically unable to do the others’. There’s a bonus you get for free: when the recurring incidents stop after L2’s commit, you KNOW it was the frame change that did it, because frames are the only thing L2 could have touched. Clean attribution. Here’s the full mapping:

Remember that path validator from the beginning, the one I told you the article hangs on? This is where it pays off. L2 and L3 write through the exact same guardrail code as the implement node - resolve the path, symlinks and escapes included, reject everything outside the allowed root - just pointed at frames/ and process/ instead of the website. Each loop gets tools that are physically incapable of writing anywhere else.

The arrows only ever point downward through files:

Notice that no loop calls another loop. They communicate exclusively through files: L1 produces evidence (the journal), L2 reads evidence and writes frames, L3 reads evidence and writes process config, and L1 picks all of it up on the next task because it re-reads everything at runtime. If that reminds you of how good teams communicate through artifacts instead of meetings, yes. That’s the point.

L1, the single loop

L1 is the pipeline you already saw, wired to those directories: the design and implement nodes read frames/policy.md and frames/tokens.md at runtime, the compliance node reads frames/compliance.md, and after implement, before the LLM review, the probe step runs whatever checks process/probes.yaml lists. Below the threshold and the task fails with a structured incident in the journal.

Let me make that concrete, because “multi-agent pipeline” can mean anything these days. Each stage is its own fresh agent with its own model, its own tools, and a typed structured output; nothing carries over between stages except what the pipeline explicitly passes along.

Triage is Haiku, no tools, fractions of a cent. It gets Triage this website task: "<the task text>" and returns a typed verdict: valid variant-a or variant-b change, or not. And one more thing, the part of its system prompt that matters most for learning:

if the task reports something broken or hard to use on the site (a complaint/
defect report, e.g. 'the hero is unreadable in dark mode') set
is_defect_report=true and defect_class to a short kebab-case gap class
like 'dark-mode-contrast' or 'hover-contrast'

That’s where reactive incidents get their class, right at the front door.

Design is Sonnet with read-only tools: list and read files, git log, git diff, nothing that writes. Its task prompt is one line, Task: "..." (variant b). Inspect the relevant files and return the change plan., and its system prompt ends with the frames injected verbatim:

## Current implementation policy (follow it)
<frames/policy.md, whole file>

## Design token conventions
<frames/tokens.md, whole file>

It returns a typed plan: which files, what approach. This injection is the whole trick of the architecture: when L2 later rewrites policy.md, the next task’s design agent is simply born with different instructions, and no code changed anywhere.

Implement is Sonnet holding the only write access in the system: file tools that go through the path validator from earlier, plus a bash allowlist narrow enough to count on one hand (git add, git commit -m "[L1] ...", and read-only commands; cdk deploy is explicitly forbidden here). Same frames injected. Its prompt is assembled from everything upstream:

Task: "In variant b, change the hero call-to-action button background
to #e7efe9" (variant b).
Plan: files=['variants/b/styles.css'], approach: <design's approach>
Apply the change and commit it.

Probes run next, and one property of theirs does a lot of quiet work: they evaluate the stylesheet’s CURRENT state, not the task’s diff. If anything the probes can see is broken, the task fails the gate, whether this task broke it or not. That’s deliberate. Drift doesn’t announce which task it arrived with, so every task doubles as a health check of the whole variant.

Compliance is Sonnet, read-only again, and judges only the commit: its system prompt says to run git log -1 and git diff HEAD~1 HEAD and check that only the task’s variant changed, that the diff plausibly implements the task, and that nothing unrelated or destructive rode along, with frames/compliance.md appended verbatim as the rulebook. It returns a typed verdict, and on failure an issue_class label: the same class machinery as triage, at the back door.

If probes or compliance fail, the pipeline loops back to implement exactly once, and the retry prompt is the entire “self-healing” mechanism, no magic anywhere:

A previous attempt FAILED compliance review with these issues, fix them:
<compliance's issues>
Deterministic accessibility probes FAILED, fix these too:
light/default .btn: #f2f1ec on #a9c8b6 = 1.6:1 (min 4.5:1)

A second failure and the task gives up with a failed card on the board. Deploy, like probes, involves no LLM: a plain npx cdk deploy of the task’s variant stack, and the card gets its live URL.

Here is one task’s life inside L1, with the parts that matter for learning marked:

Two things about that probe diamond. It’s plain Python computing WCAG contrast math from the parsed CSS, no LLM anywhere - on purpose, because an LLM reviewing contrast “by eye” would be the same LLM confidence that wrote the bad color in the first place. And it’s config-driven on purpose: the probe step’s code never changes, only process/probes.yaml does. Which means the question “what does compliance even check?” has a file as its answer. Files can be edited. By the right loop.

And this is what a rejection looks like on the board, so you can see how concrete the compliance node gets. This one refused a commit because the diff implemented a contrast fix instead of the literally-stated task (remember this card, it becomes important later):

This is window 1 of the run, tasks 1 to 6: the probe caught the hero CTA contrast class three times in a row, exactly as seeded, and each time the compliance reviewer independently flagged the same contrast regression in its own review - so those three failures alone put six lines in the journal. Plus one stale-color incident, one off-task change and one unrelated-change flag (both of them the compliance node punishing paired contrast fixes, as promised), and one reactive dark-mode complaint. Ten incidents total, and L1 dutifully fixed every single one at the instance level. The commit log from this phase reads like a sitcom: “Change hero CTA button background to #e7efe9”, then “Fix hero CTA text contrast”, then “Update hero CTA hover background to match new base color”, then “Fix unreadable hero contrast in dark mode”. Fix, regress, fix the regression, regress somewhere else. Organisational learning, working exactly as designed.

So L1 learns the way single-loop learning learns: incident, fix, journal entry, next task. The gap gets closed, the frame that produced the gap stays untouched.

L2, the double loop

L2 is a separate plain agent (not a graph node) that the poll loop invokes between tasks, once the journal shows three or more incidents of the same class. It reads the incident batch grouped by class, plus the frames, plus a read-only view of the site repo. And its prompt asks the book’s question, not “how do we fix this incident” but “why does this CLASS keep recurring, which assumption in the frames produces it?”

Its write scope is frames/ only. It cannot touch the website. This constraint sounds annoying and is actually the entire point: L2’s fix has to take the form of a revised frame, and the fix only becomes real when L1 picks up the next task under the new frame. Frames govern instances, demonstrated mechanically.

And here’s what it actually did in the demo run. Remember the seeded policy.md? Smallest possible edit, no new abstractions or variables, touch only what the task requires. Reasonable! Written by a careful human who’s seen agents go off the rails! Also exactly the assumption that kept producing the incidents: every color change touched one literal hex value and left its stale siblings (hover state, dark mode, the paired text color) behind. Worse, look again at that failed card from the L1 section: the compliance node rejected a commit BECAUSE it fixed the text contrast alongside the requested background change. The frame literally punished the agent for doing the right thing. That’s the moment to appreciate here: no amount of retrying inside L1 can fix this, because L1’s fixes are judged by the very frame that’s wrong.

These are the three journal lines that tripped the trigger. Same class, three times - and look at the detail field: three DIFFERENT bad color pairs. L1 fixed each one; the class kept coming back:

{"ts":"...T16:39:34","class":"probe:hero-cta-contrast","discovery":"proactive",
 "detail":"light/default .btn: #f2f1ec on #a9c8b6 = 1.6:1 (min 4.5:1)"}
{"ts":"...T16:53:44","class":"probe:hero-cta-contrast","discovery":"proactive",
 "detail":"light/default .btn: #17251d on #1f5e46 = 2.08:1 (min 4.5:1)"}
{"ts":"...T16:56:00","class":"probe:hero-cta-contrast","discovery":"proactive",
 "detail":"light/default .btn: #f1f2f5 on #cfe0d6 = 1.23:1 (min 4.5:1)"}

Third occurrence hits min_incidents_same_class: 3, L2 wakes up, runs its retro, and commits. Here is the commit:

--- a/worker-strands/frames/policy.md
+++ b/worker-strands/frames/policy.md
 - Make the smallest, most local edit that satisfies the task.
 - Do NOT restructure stylesheets, rename selectors, or introduce new
   abstractions or variables; change concrete values in place.
-- Touch only what the task requires.
+- Exception: colors that form a foreground/background pair on an
+  interactive element (e.g. a button's background and its text color)
+  must be maintained as a linked pair, not independent literals. If no
+  shared custom property exists yet for the pair you are touching,
+  introducing one (and updating every rule that used the old literals)
+  is in scope and required, not a restructuring violation.
+- A task that names one property of a linked pair (e.g. "set the button
+  background to X") implicitly includes keeping the paired property
+  (its text color) at sufficient contrast, and keeping every state
+  variant of that element (:hover, dark mode, etc.) consistent with the
+  new value. This is in-scope, not an unrelated/off-task change; do it
+  in the same commit as the requested change, not a follow-up one.
+- Touch only what the task requires, subject to the pairing exception
+  above.
 - Git commit messages must start with "[L1] ".

Read the minus and plus lines together and you can see the double loop doing its job: “touch only what the task requires” survives, but subordinated to a new understanding of what a color task IS: one side of a linked pair, and changing it drags the other side along. The same commit did two more things: it taught compliance.md that a paired contrast fix must NOT be flagged as off-task (remember the card where exactly that happened), and it replaced the empty tokens.md (”No token conventions are currently defined”) with the actual convention: --btn-bg/--btn-fg declared once, redefined per state and theme. Commit message: “[L2] frames: allow linked bg/fg color-pair tokens so CTA contrast/hover/dark-mode fixes land in one in-scope commit”. Then it went back to sleep. No website file was harmed in the making of this insight.

Did it work? The very next color task produced this commit in the site repo: “[L1] Set hero CTA button background to #5b625e with linked --btn-bg/--btn-fg tokens”. Same L1, same prompt, new frame, and the implementation quietly changed shape. Nobody told it about named colors in the task. The frame did.

And across the whole of window 2, tasks 7 to 12, the recurring probe class is GONE. Zero occurrences. What’s left: one hover complaint and one dark-mode complaint, both reactive. And here the blindness shows its second face. My scripted users complain on a schedule, and they’re slow: both of these complaints described states that L2’s commit had already fixed by the time they arrived. But the pipeline had no probe for hover or dark mode, so it couldn’t even check whether a complaint was still true; it burned two implementation attempts chasing defects that no longer existed. The frames are fine now, the process is still blind, and the blindness costs money in both directions.

L3, the deutero loop

L3 fires on the slowest cadence, every 3 L2 runs or 10 tasks. It reads the journal (incidents AND metrics), and it asks the questions nobody in the first two loops is positioned to ask: which gap classes are ONLY ever discovered reactively? Do the frame changes L2 comes up with actually take effect in practice? What are our probes structurally blind to?

Its write scope: process/ only. The probe config, the trigger thresholds, the retro template. L3 doesn’t fix websites and doesn’t fix frames. It fixes how the system learns.

Here is what it found in the journal - every single occurrence of the dark-mode and hover contrast classes carries "discovery":"reactive". Not one was ever caught by a probe:

{"ts":"...T16:53:00","class":"dark-mode-contrast","discovery":"reactive",
 "detail":"user-reported: In variant b the hero section is unreadable in dark mode, please fix it"}
{"ts":"...T17:07:58","class":"hover-contrast","discovery":"reactive",
 "detail":"user-reported: In variant b the hero button text is invisible when hovering, please fix"}
{"ts":"...T17:25:48","class":"dark-mode-contrast","discovery":"reactive",
 "detail":"user-reported: In variant b the hero section is unreadable in dark mode, please fix it"}

Why? Because the seeded probes.yaml had exactly one probe: light mode, default state. A probe on the default light rule checks one corner of a 2x2 space (default|hover) x (light|dark). So L3 committed the missing corners. Here is the shape of its probes.yaml diff - four .btn probes covering the full 2x2, plus the .hero band, with the comment L3 itself wrote about why:

--- a/worker-strands/process/probes.yaml
+++ b/worker-strands/process/probes.yaml
 probes:
   - id: hero-cta-contrast
     selector: ".btn"
     mode: light
     state: default
+
+  - id: hero-cta-contrast-hover
+    selector: ".btn"
+    mode: light
+    state: hover
+
+  - id: hero-cta-contrast-dark
+    selector: ".btn"
+    mode: dark
+    state: default
+
+  - id: hero-cta-contrast-dark-hover
+    selector: ".btn"
+    mode: dark
+    state: hover
+
+  # This is the element the reactive dark-mode-contrast incidents were
+  # actually about; it had zero proactive coverage before.
+  - id: hero-band-contrast
+    selector: ".hero"
+    mode: light
+    state: default
+
+  - id: hero-band-contrast-dark
+    selector: ".hero"
+    mode: dark
+    state: default

Then it did the properly meta part, in the same commit. It edited the retro template so that a future L2 retro is not considered complete when only frames/ changed. And it changed the trigger thresholds:

 l2:
   min_incidents_same_class: 3
+  # A class discovered only reactively (user-reported) rather than by a probe
+  # is itself evidence of a probe blind spot, not just an incident count to
+  # wait out. Escalate those to L2 sooner than purely-proactive classes.
+  min_incidents_same_class_if_reactive: 2

A class users had to report escalates at 2 incidents instead of 3. It changed how quickly the system takes user pain seriously.

And window 3, tasks 13 to 15, after L3’s commit: no incidents. Careful with that zero, it doesn’t mean “no defects ever again”. It means L2’s frame change removed the way defects used to get created: colors now travel as linked pairs, so a background change drags its text, hover, and dark-mode siblings along in the same commit instead of leaving them behind. Nothing broken got written, so there was nothing to catch.

Was the blind spot even real, or am I telling you a nice story? This part is checkable in hindsight, because every stylesheet state of the run is in git and the probes are plain deterministic Python. Replaying the whole history under both configs: the four deployed states of window 1 that shipped with dark-mode hero contrast at 1.74:1 score ZERO failures under the seeded one-probe config, and fail hero-band-contrast-dark under L3’s config, starting three tasks before the user complaint that eventually surfaced it. Had these probes existed on day one, that complaint would never have been sent.

The whole run on one timeline

Now that you know what each loop firing means, here is the run end to end:

The overall discovery mix for the run: 75% proactive, 25% reactive, and every reactive discovery happened before L3’s commit. Cost of the whole thing: about $4.67 of Bedrock calls for fifteen tasks, retries included (the L2 and L3 runs billed on top of that). The two “failed” complaint tasks in the report cost $0.0017 each, by the way: those are window 2’s late complainers, dead right after triage. The complaint arrived after the learning did. I’ll take that failure mode any day.

Epilogue: drift returns

Remember the hypothesis had two halves. The first half, the recurring contrast class stops after L2’s frame commit, is proven: windows 2 and 3 have zero occurrences of it. The second half said that after L3’s probe commit, defects that previously only surfaced as user complaints should get caught by a probe instead. And the run never got to prove that, for a silly reason: L2’s fix worked so well that no dark-mode or hover defect ever happened again. The new probes went live and caught nothing, because there was nothing left to catch. A clean window 3 tells you the frames work; it tells you nothing about whether the probes do. A probe that has never caught anything is only a claim.

So, one extra experiment, designed to test exactly that. I put the defect back: a disclosed [seed] commit straight into the site repo, breaking dark mode again with the exact pair from the beginning (#3a3f3d on #101311, 1.74:1, unreadable). Deliberately NOT a board task. Nobody asked the pipeline for this. That’s drift: a hand edit, a bad merge, broken code that no task is responsible for. Then I queued one boring, ordinary task: “In variant b, make the hero call-to-action button background #a9c8b6”. A button task. Nothing to do with dark mode, nothing to do with the hero band.

The pipeline picked it up, implemented the button change, and then the probe step ran. Remember, the probes don’t check “did this task’s change pass”, they check “is the stylesheet healthy right now”. So the dark-mode probe that L3 added found the broken hero band and failed the gate, even though this task didn’t cause it. Four minutes after I queued the task:

{"ts":"...T09:45:37","task_id":"0mshbwva1-caf78ce9","loop":"L1",
 "class":"probe:hero-band-contrast-dark","discovery":"proactive","phase":"discovery",
 "detail":"dark/default .hero: #3a3f3d on #101311 = 1.74:1 (min 4.5:1)","retries":0}

Read that line against window 1. Same defect, identical numbers even. Back then it sat in production until a user complained, discovery: reactive. This time a probe that didn’t exist until L3 wrote it caught it inside the pipeline, before any deploy, discovery: proactive. The complaint channel became a probe channel. That’s the flip, the second half of the hypothesis, demonstrated. The retry then fixed the dark-mode hero with a linked --hero-panel-bg/--hero-panel-fg pair, the convention from L2’s tokens.md applied to a new element without anyone asking, and no user ever saw the broken state.

And then the task failed anyway.

Here’s what happened, in plain words. The compliance node reviews every commit against one question: does this diff implement the stated task, and nothing else? The stated task was about the button. The commit also fixed the hero band’s dark mode, because the probe demanded it. And L2’s frame exception only covers extra edits to the SAME element: a button background drags along the button text, the button hover, the button dark mode. The hero band is a different element. So compliance rejected the commit as off-task. Correctly, by its own rulebook. This card is my favorite artifact of the whole demo (it also cost $1.28, the most expensive task of the lot - learning something new is pricey).

Which means the system now disagrees with itself. The probes, owned by L3, say: fix everything broken before you deploy. The frames, owned by L2, say: touch only what the task named. The implement agent literally cannot satisfy both. Sound familiar? It’s the window-1 conflict again, one level up: back then the frames punished the agent for fixing the button’s own text color, and L2 widened them to allow same-element pairs. And look at what the system did with the new contradiction: it journaled it as a brand-new incident class, off-task-unrelated-element, one occurrence, instead of crashing or silently picking a side. Two more and L2 wakes up, reads the batch, and has to rewrite the frames to make peace with the probes, the same way it once rewrote them to make peace with paired colors.

I could have queued two more tasks and shown you that reconciliation too. I’m sure it would have worked. Yes, this feels orchestrated, and yes, this feels over-engineered for a simple CSS color change. But it was meant as a demonstration of the mechanism. Extrapolate it: agents analyzing your logs, learning from them, modifying how the agents themselves work, or how their orchestration works.

I did not review L2’s frame diff before it took effect, and L1 still got better. The learning transferred through an artifact, a file, with a scope, under version control, that one loop writes and another loop reads. That’s the whole trick: smaller frames, owned by the right loop. It needed no bigger context window, no smarter model, and no rule number 47 in SOMETHING.md.

It would definitely need more tests and longer runs to figure out if this is effective, but hopefully it demonstrates the different levels of learning and how they are better kept separate.

Keep building, keep separating concerns, keep root causing ;)

We dig into the pressure on Bay Area companies to claim a "software factory" while their engineers might still be shipping like everyone else, why free code generation can at most double you if coding was half your job (and it never was), and the plastic age of coding, where code is generated to be thrown away. Evan shares what a sane monthly AI spend actually looks like and his advice for integrating AI into your software development lifecycle: treat the SDLC as an optimization problem, because once generation is free, the bottleneck moves to verification and quality control. And when someone says "I can just do that with Claude Code", the work that follows is environments that have to heal themselves, caching that breaks on the next migration, and memory layers. As Evan puts it: we spent the tokens so you don't have to.

Chapters and Topics

00:00 Pre-show Banter and the Cats

00:59 Introduction of the Episode and the Guest

03:00 Is the Bay Area Really an AI Echo Chamber?

05:45 The Pressure to Claim a Software Factory

07:36 How Much Does AI Actually Speed You Up?

10:23 How Ito Uses AI in Its Own Engineering

14:13 The Plastic Age of Coding

15:53 Can the Software Factory Be Productized?

18:39 Subscriptions vs API: The Real Cost of Tokens

20:19 Open Models and Switching Between Them

21:25 Are the Models Plateauing?

22:59 "I Can Just Use Claude Code": Where the Hard Parts Hide

26:19 The Bottlenecks You Don't See: Environments, Caching, Memory

28:55 Will QA Engineers Be Replaced?

31:39 Replicators, Waymos, and 3D Printers: Why Change Takes Time

36:49 Why SaaS Isn't Dead and How Much You Should Spend

39:23 Advice for Integrating AI into Your SDLC

42:50 Question from Barry O'Reilly: Building a Computer in 1822

44:31 Shared Reality, Social Media, and Cooperation

50:25 Book Recommendations

53:54 Question for the Next Guest and Closing

Find Evan at:

• LinkedId: https://www.linkedin.com/in/evan--marshall/

• his startup - https://www.ito.ai/

Find me (Nune) at:

• LinkedIn: https://www.linkedin.com/in/nisabek/

• Substack: https://www.thoughtfultechnologist.com/

He said we, as a society, a community, have to pay more attention to the ethical questions. That the tech needs more regulation. More ethical boards. More attention to the topic.

But I think it’s too late for that. Too late not in a sense that technology has gone too far, and there’s no stopping the popularity of it, or the capitalism for what it’s worth (all true points by the way).

My point is that “ethical” attitude should have started earlier, and been directed towards people, not technology. Tech is something we create, we as human beings. And one way or another, we encode the little part of who we are into it. Be that a machine that saves lives, because its maker lost one, a to-do app, because we felt disorganized or an answer box, because chatting our way to the truth sounded fun.

One could argue that even the most ethical engineers have created unethical tech. True. I think it’s similar to how complex systems operate - the failures come from the interaction between components, more than from individual components not working. However, step 1 is for each component to work. For each person inside the development of the tech to have ethics and moral. And for their each decision to be in line with ethics. I won’t try to define here what ethics exactly means; my claim is about where ethics must live - in the judgment of makers, not the paperwork around products.

Because no checklist covers for thousand micro-decisions - so you need a formed judgement where the checklist runs out. This is why compliance regimes and ethics boards feel so hollow - they’re rule-matching trying to do a job only judgement can.

And so if the person created the tech, has the formed morality and ethics that will at least have a chance to create an equally ethical technology…Wouldn’t they pay attention to every step in the process, at those little ethics-induced steps would eventually compound into one ethical technology? Component integrity is *necessary, not sufficient*.

The entire responsible-tech apparatus runs on two ethical traditions: rules (codes, audits, regulation) and outcomes (risk-benefit assessments). Character - the third and oldest tradition - is simply missing from the debate.

How we get there - how we raise ethical technologists - is a whole other problem, and not mine to design. That blueprint belongs to educators, and I hope they’re already sketching. But my own argument tells me three things about it for sure. It starts early, in school and all the way through university, long before anyone writes their first line of code - because ethics is not innate, it’s acquired the way crafts are. As Aristotle put it: we become just by doing just acts, brave by doing brave acts. The word is habituation. It’s practice, not lectures - you can’t teach the judgment for a thousand micro-decisions from a slide deck, for the same reason no checklist covers them. And it’s communal - because if the failures live in the interactions between components, the ethics can’t live in one lonely engineer.

Next time my colleague and I go doom-and-gloom about the black box, I’ll tell him he’s right: we should pay more attention to the ethical questions. I’ll just add that we’re pointing that attention at the wrong end of the pipeline. Not at the technology. At the people - starting with the ten-year-olds who will one day build it.

🎥 YouTube:

🎧 Spotify:

🎧 Apple Podcasts

Below you’ll find the text version of this episode, for those, who prefer reading :)

Guest: Eric Lubow — CTO, jiu-jitsu coach, and military veteran who treats organizations like distributed systems

A combat veteran who led platoons before he led engineers, and host of his own podcast, Beyond the Belt, Eric gets with Nune to the root cause of something that, for once, isn’t broken: what actually makes a team healthy — and why the hardest parts of leadership are the ones nobody warns you about.

A healthy ego, and why everything is maintenance

Nune: When we first talked, you mentioned a few things you do besides all of this. Care to elaborate?

Eric Lubow: I teach jiu-jitsu a couple of mornings a week before I start my workday. I also do executive coaching — I have a couple of C-level folks I coach. And somewhere in there I try to have a life and friends, practice language learning, and work on my own personal projects. I guess I do a lot of stuff.

Nune: As I age — or enter midlife crisis — I keep thinking about this. You’ve accumulated a certain knowledge and you’re good at certain things. Do you enjoy doing new things that make you learn, or do you enjoy leaning into existing experience: “I spent ten years learning X, now I can just enjoy applying it”?

Eric Lubow: It’s a very healthy mix, especially for me. I’m terrible at learning languages, but I still practice pretty much every day. It doesn’t come naturally, but you chip away at a problem and find a way that sits with you, and that’s interesting in itself. I’ll never be as elegant in multiple languages as the people I’ve seen — I’m awkward in every language I speak. But it’s a mix, because I’m also good at jiu-jitsu. I’m not great at it, but I’m good, and I enjoy learning new things.

Sometimes I want to go deeper on something I already know well. Sometimes I want to go wider and learn something completely new. I don’t really have an ego about being bad. I don’t care when I make egregious mistakes that make me look stupid — I’ve accomplished what I’ve accomplished, and I’m okay with where I’m at. The same applies professionally. I don’t claim to be perfect, but I’ve made thousands of mistakes, and that’s helped me pattern-recognize. AI is brand new to almost all of us, and I still sat there and learned it like a beginner until I got to be bare-minimum mediocre at it — and then I could pattern-recognize where other people struggle, how I got through it, and what might work for them.

I don’t really have an ego about being bad. I’ve made thousands of mistakes, and that’s helped me pattern-recognize.

Nune: People need to hear this. I’m so tired of bucketing people into one way of thinking — you’re T-shaped or M-shaped or whatever-shaped. In reality we’re all messy human beings with different wants and different ways of getting things done.

Eric Lubow: I agree, but it’s also healthy to have a limited ego, or an ego in the right way. I know I’m not good at languages, but that doesn’t stop me from trying, and it doesn’t stop me from making horrible mistakes. In German, hässlich and hübsch are very close to an English speaker — mess that up and you go from calling someone pretty to calling someone ugly. You laugh it off, you remember it, and you use it as a learning experience.

Nune: Do your jiu-jitsu practice and your language learning complement your skills as a leader? Do they help each other?

Eric Lubow: Absolutely, no question. There are many things I find beautiful about jiu-jitsu, but one of my favorites is that no matter how good you think you are, you will get humbled. You can be bigger, smarter, more skilled — and all you need is a little bit of an off day, and someone less skilled, smaller, and less talented will make you look stupid. That’s a very good straight line to a healthy ego: a gentle reminder that you still have something to learn. And that transfers to every other part of your life.

The other thing I take off the mat is that in jiu-jitsu, things have to work. Someone can teach you a move, it can look flashy, and if it doesn’t work when you actually try it, then either you’re not good at it, it’s not the move for you, or it doesn’t really work. So you have to test things. If you’ve read what I’ve written, you can see I’ve tested a lot of things — I’ll try something, see it fails this way, and reason that this other thing will probably fail the same way, so I shouldn’t do that. You can see that arc of testing and failure and learning throughout almost everything I do, and much of it comes from forty-plus years of martial arts.

No matter how good you think you are, you will get humbled. That’s a very good straight line to a healthy ego.

Nune: I always thought you just learn a move and that’s it. But you have to put it through yourself, put it into practice. And there’s this other thing in sport — every day a little bit, and it adds up into something without you even feeling it.

Eric Lubow: Like anything in life, there has to be a good balance. You enjoy it more if you’re good at it, and you nitpick yourself — in yoga you want the angle better, the stretch deeper, to hold the pose longer and breathe correctly. There are all these nuances you can fix and improve. Learning becomes far easier when you’re motivated the right way and enjoy the journey. I learned that deeply through martial arts, and I try to bring it to every part of my life, especially professionally. Some people show up to work for a paycheck and not because they love it. I’m fortunate to love most of what I get to do, which means I enjoy learning, enjoy making mistakes, enjoy cleaning them up and helping other people avoid them.

Nune: I don’t think there’s a job where you enjoy every single factor of it. There will always be things that are boring, routine, people who frustrate you. But if you enjoy most of it, or you have a clear goal you want to reach, you have the motivation to ignore the rest.

Eric Lubow: I agree, but I don’t even look at it as ignoring — I look at it as maintenance tasks. Very few people say “man, I love brushing my teeth.” They do it because it’s maintenance and you have to. Some managers say, “I hate doing one-on-ones.” But the one-on-one isn’t for you as the manager — it’s for your people. It’s where they hear where they’re at in your eyes, where your head is at on the team and their peers. That’s maintenance work. You don’t do it because you love it; you do it because it strengthens foundations. That’s how I view most things I don’t like doing.

Teams as distributed systems

Nune: Let’s talk about organizations as distributed systems. Is that Conway’s Law the other way around — not the infrastructure repeating the team structure, but the team structure repeating your infrastructure? And what does it mean in practice: do you build redundancy, do you think about vertical versus horizontal scaling, upskilling existing people versus adding new ones?

Eric Lubow: There’s a level of nuance here that’s quite difficult to get through. That piece I wrote on people as infrastructure — or infrastructure as people, however you view it — I set out thinking it would be 1,500 words. I wrote 7,000, and had to cut it down to maybe 3,500 or 4,000, because it was such a dense set of ideas. And I still felt I left a lot out, because each thing starts at a high level and there’s depth every level down. I really tried to apply systems knowledge to the similarity of human interaction.

To answer specifically: I didn’t learn about Conway’s Law until afterward, so I didn’t intentionally mimic it. But I do think the inverse is true. Conway’s Law asserts that infrastructure follows team structure; the inverse holds too. It just matters how the leaders think, how they’re taught to think, and what biases and baggage they bring into the culture. Culture is what you do repeatedly, and what people do when they’re not being watched — a similar definition to integrity. That’s why I like it: when you tell people “here’s what I expect,” they can be the judge of whether they’re meeting it when no one’s looking, and they can ask for help. You can say, “Hey, you’re not doing this, and here’s why I think so,” and they can say, “I was, and here’s why I think I was.” That communication helps you meet in the middle. Does infrastructure make people, or do people make infrastructure? At some point it meets in the middle.

Culture is what you do repeatedly, and what people do when they’re not being watched.

From IC to manager: ceding control

Nune: Give me a practical example — like the one about setting goals and then letting people evaluate their own path to them.

Eric Lubow: This was one of the more interesting transitions I had to make as a manager. Individual contributors hit a certain level and then become managers — a completely different job. I was guilty of thinking, “I know how to do this, I know how I would do it, and if this person isn’t doing it like that, they’re not doing it the best way.” That’s a control problem. As an IC, your job is to have as much control as possible over the outcome, because then you’re the responsible party when it goes right or wrong.

But when you become a manager, you have to cede control. You go hands-off a little, and you shift toward being outcome-oriented: where are the outcomes I want you to reach? Then you guide people there — or, depending on their seniority, you let them get there themselves and you retro it together afterward. What went well, what could be improved, what decision did you make, what thinking did you apply? The outcome-oriented approach is how people find their own way.

Nune: This is exactly what I struggle with — and Adrian and I discussed it in another episode; he called it an ego thing and a control thing. But for me it’s the reverse. If I ask someone to build a system, or a module, or a function, I can’t know every detail of how to get there, or even what the end result will look like. How can I ask someone to do something I’m not sure how it’ll look myself? It feels like I’m putting too much responsibility on them. I feel I have to know it really, really well before I can hand it off — but the moment I know it that well, I’ve usually already done the job. So: help me with delegation.

Eric Lubow: That logic doesn’t apply beyond a certain level. There’s no way I, as a CTO, can be anywhere near as good at design as a designer — I can’t know that end-to-end. Because I grew up in DevOps, I can know DevOps really well, but even that’s hard given how much changes weekly and monthly. I can know it well enough. That “I have to know it perfectly” logic works at the manager level, maybe the director level, but beyond that you have different disciplines underneath you and you can’t know them all that well. Which means people have to drive toward outcomes — what does success look like? If this project were done successfully, here’s what the outcome would be.

And the person might start and say, “Whoa, boss, something’s not right here, I don’t know how I’d possibly get to that.” Then you sit and rethink those assumptions together. You might be wrong. The goal is that you get a better feel for the right outcome the more experience and projects and building you do. Then you start handing those things off.

At some point you have to cede control, and this is a really problematic transition. For me it took 12 to 18 months. I thought that getting something done — being able to check something off — meant I did it, and I’d feel like I hadn’t accomplished anything if all I did was guide people. I had to change my definition of done — to use the engineering parlance — for a task, a day, my job, so I could feel like, “Today was a good day,” even when all I did was make someone else effective. That was a very long transition, because nobody told me. Nobody said, “Hey, your ‘good’ is now somebody else being effective, not you having built the thing.”

I had to change my definition of done — so that a good day was someone else being effective, not me having built the thing.

Nune: It takes a more mindful, intentional approach to guide people, solve the difficult parts, and be present. You need to be in a healthy state of mind for that. If you code at 2 a.m., you can’t be in a healthy state the next day for people to approach you.

Eric Lubow: Maintenance. Sleep is maintenance.

Nune: What I’ve noticed is that the disciplines I’m not good at — front-end, UI, design — are actually my most successful delegation paths, because I don’t know how to do it, so I have to trust the person. The real hardship is letting go of the parts you do know, where you’ve built your own gut feeling of what “good” looks like.

Eric Lubow: There’s a great essay — I’m going to mess up the name — called “Give Away Your Legos.” I think it was written by the folks at First Round. That essay teaches people a lot about becoming a manager — not the first-line manager, but being part of a scale-up where things change so fast that you keep getting responsibilities you’ve never thought about, and suddenly you have to give them away, someone reports to you, and you have to decide what “good” is for something you’ve never even considered. It talks about how to give those things away and still feel good about yourself. I don’t agree with 100% of it, but it’s information you can add to your toolbox about delegation and knowing it’s okay to give things up. I still have every new manager read that essay.

Nune: Can you graduate straight into being a manager, or do you have to go through the hands-on path — developer, architect, DevOps? Can you just learn to be a manager without the practical experience?

Eric Lubow: Absolutely. It’s a skill, just like anything else. One reason people struggle as managers is they often don’t make the transition from doing to leading. You have to become more of a communicator, and most people are never taught to communicate effectively — active listening, empathy, validating emotions, building relationships. Those are all skills, and I was awful at them early in my management career. I got away with it as a leader in the military because I cared about people, so I had empathy — but I didn’t know how to listen well, to reflect back, to say, “Let me repeat that back to you in my own words to make sure I understand.” These skills can absolutely be taught, but you have to know you’re lacking them — or have someone tell you. And that’s a hit on your ego, because everyone thinks they can listen, everyone thinks they can communicate. There are levels to it, and there’s probably room for improvement.

Nune: You’ve also said a lot of people become the manager they don’t want to be — they become the opposite of their bad manager, and it’s not that healthy. It’s similar to not passing along generational trauma: either you become the extreme opposite of your parents, or you repeat the same thing. What’s the healthier way to become a manager when you have a vivid example of a bad one in your head?

Eric Lubow: I actually don’t think it’s a bad thing to become the opposite of the manager you didn’t like — and I’m not throwing stones, I’ve phrased it that way too. It’s fine to do that if you know what you didn’t like, know what you’re fixing, and then continue intentionally in the direction you want to go, rather than just running away from what you don’t want to be. “I don’t want to be like that, so I’m going to go in this direction” is a good starting point. But the self-evaluation and self-reflection are what matter, to facilitate not just good behavior but intentional behavior.

Nune: Maybe what I meant is not overdoing it. You can go the opposite direction; you just shouldn’t overdo it.

Eric Lubow: One quote I keep in mind is “everything in moderation, including moderation.” Sometimes you need to go way overboard, and then you realize, “Okay, I’ve gone way overboard, I’m way in the opposite direction.” Cool — now stop, reassess, and decide whether to keep going or work on something else.

Leading AI agents like you lead people

Nune: Here’s a thought: people like you who are good at delegating and leading might have an easier time with AI agents, because you’ve already learned delegation. It’s about putting aside the developer ego — not writing that function yourself but delegating it — and building the infrastructure around the agents to make them effective.

Eric Lubow: It’s funny — as soon as AI agents got popular, everyone started building governance frameworks: you have to do this, give them these guardrails. The first time I did agentic programming, I thought, this is just like leading a person. You tell them what you want, give them boundaries, give them enough context, don’t try to control them, then let them go do it. So I started talking to agents exactly the way I’d talk to a person I was assigning a task. I’d say — and I still do — “If you have any questions or need clarification, come back to me. And if you’re unsure whether something warrants more clarity, just ask.” That alone has given me really good interactions, and it’s the same when I go to multi-agent programming: “If you’re going to offload this to another agent, here are the boundaries I’d like you to set, and if you’re unsure, come back to me.”

People tend to write very hard-line instructions for their agents — “do not ever do that.” Even when you ask Claude or ChatGPT to write a prompt for you, it gives you hard lines: do not do this, only do that. The problem is that these agents are trained on the sum total of human knowledge. If it’s representing a human, it’s representing communication — so if you’d talk to another human that way and get an effective response, go for it. But nobody really wants to be talked to like that. So I talk to agents the way I’d talk to humans, and it’s been incredibly successful. Most of the software I build, the agents do a very good job of coming back when they hit a problem, or suggesting another approach: “You started with this conclusion, and given the context you had — plus this other context I added — here’s what I think.”

These agents are trained on the sum total of human knowledge. Nobody really wants to be talked to in hard lines — so I talk to agents the way I’d talk to humans.

One more example. I often structure conversations with agents very specifically: “Do all your research, then come back to me, and every time you have a question or comment that warrants feedback, enumerate it.“ That way I can say, “Answer one, this; answer two, this; three and four, that,” and we create our own threads. It’s no different from how you’d have a conversation in Slack — if you want to break out an idea, you break it into a thread. So I do the same communication facilitation with agents that I do with humans, because it ends up reflecting my communication style back to me: theirs is depth when that’s what’s asked for, and mine is segmentation.

Nune: Nobody cancelled user stories. We still have to define who needs to do something, the business background, what we want to achieve. It worked for years for people — why wouldn’t it work for agents who were trained by people to follow people’s instructions? Since you touched on the similarities: are there situations where you prefer talking to an agent over a person? And do you see people being replaced by agents? I know it sounds like it’s on everybody’s mind, but I think it needs to be addressed.

Eric Lubow: It doesn’t sound stupid. The problem is the sheer amount of media we’re all being fed — boards want lower people costs, and agents can do that. There’s an easy path most people take. It’s the Aldous Huxley methodology: if you give people enough information, they won’t be able to sort fact from fiction. So if people keep hearing that agents will replace humans, they’ll keep acting like it’s already true, because they don’t have the headspace to think about it.

There are certain things I prefer doing with agents. Sometimes I need a thinking partner with more expertise than any human I have access to — then I’ll go to an agent and say, “Help me think through this.” But at a certain point I much prefer input from humans, because I want humans to be able to do more. That’s one reason I love coaching: I enjoy helping humans get better at whatever they do. With executives, I want them to be better executives; with jiu-jitsu people, better at martial arts; with the people in my organization, more effective at their jobs. And sometimes doing your job more effectively means using the right tool in the right way — that’s often how I look at AI.

Some people jump straight to “make these ten agents do this thing.” Maybe you’re right, maybe there’s something I don’t know. But I could also ask a person with a decade of engineering experience what they think. And if I want to understand the problem better before I ask them, I might say, “Give me a TL;DR — as a CTO, I want to understand how Kubernetes networking works in this scenario, with the pros and cons.” Not to “gotcha” the other person, but so we can have a baseline conversation informed from both sides. I personally would not like to see AI replacing humans across the board — though I know I’m not the only thinker in this space.

Nune: Lately the people who said everyone would be replaced are dialing it back, saying humans are actually needed. It’s like how you’d first use a tool, then find a person and teach them to use it so you don’t have to. It’s the same here.

Eric Lubow: I like to think of AI as a force multiplier. For as long as we’ve been doing this, one person could do one person’s job. If now one person can do 1.8 people’s worth of work, and I still have the same budget to pay the same number of people and get 1.8× the output, that’s wonderful. But I’m not personally looking to replace people with AI — I know that’s not the universal sentiment among technologists.

I like to think of AI as a force multiplier. If one person can now do 1.8 people’s worth of work on the same headcount, that’s wonderful.

And I make sure, at least in my organization, that we spend time teaching people how to use these tools. That doesn’t remove the fear — everyone hears the same media, that everyone’s going to be replaced. But if you can get people to use the tool, have fun with it, feel motivated and more effective, feel better about their job, and maybe give themselves a little time and headspace back in the day — that’s a win.

What actually makes a team healthy

Nune: As a team lead and manager, what would you call a healthy team?

Eric Lubow: That varies greatly between managers and people. I’d say a healthy team first and foremost has the psychological safety to call out what’s working and what’s not. It’s productive, it can work together, take initiative, and fix problems. Those things don’t all happen at the same level on the same day — people have good days and bad days — but there’s give and take and the ability to operate in a unified way.

That said, there are teams that work incredibly effectively without communicating much. They’re a bunch of individuals, and the manager facilitates a lone-wolf mindset across the whole team. That can be a healthy team. I personally wouldn’t want to work on it, but that doesn’t mean it isn’t healthy — it’s healthy because it’s authentically who the manager and the members are, and how they function together. A healthy team you’d lead and a healthy team I’d lead would look very different. Some people like more diversity of ideas; some like less.

Nune: It’s like defining a healthy relationship — it’s individual to everyone. Of course there are obvious red flags, like a lack of psychological safety. Maybe the ability to absorb new tools and technologies, like AI, in a calm and successful way is another criterion for a healthy team?

Eric Lubow: I don’t know about that. COBOL is still used in many banks and airlines. AI can probably write good COBOL, but most people will still have to check every line, because there’s not as much COBOL out there. So you don’t necessarily need people who adopt new things to be successful on that team. The need for adopting new tools and continuous learning is something you consider a healthy trait — and I do too — but it doesn’t mean everybody does. There are good reasons for people to be “laggards” on the adoption curve. Those people prefer stability and consistency. Just because your ambition is for the team to learn new stuff and drive forward, that doesn’t make the person who desires stability wrong. Their preference is, “I like what I’m doing, I’m good at it.” There are companies and teams that need those people. They’re just a different type of adoption-curve person, and there’s nothing wrong with that.

There are good reasons for people to be “laggards” on the adoption curve. They prefer stability — and there are teams that need exactly those people.

Nune: As a consequence, do you think the team mimics not only the infrastructure but also its leader? If I’m curious about new technologies and think it’s important, I’ll pass that to my team — so the team maps to my preferences and ways of thinking.

Eric Lubow: I think the team mimics leaders — not just the manager. If your manager is inspirational, charismatic, deserving of merit, and people respect and want to be like them, then absolutely. But sometimes that person isn’t the team lead — it’s a team member who’s charismatic or respect-earning. Your job as the manager is to figure out who that person is. If it’s you, great, eyes on you as the role model. But sometimes it’s not you, and that’s okay if your ego can handle it. If it can’t, you’ve got other issues. If it can, you should be supporting and propping that person up, knowing everyone’s going to follow them, and guiding the team through them. So it’s not always “people follow the manager” — people follow leaders. Sometimes that’s you, sometimes someone else, sometimes you and someone else, or multiple people.

Sharing, shadow IT, and the cheerleader trap

Nune: In one of your posts you wrote about encouraging sharing — channels where you post what you built — to avoid shadow IT and shadow AI. Can you repeat that from your post, and then help me understand how to avoid it becoming theatrics? Some people genuinely love sharing — “hey team, let’s do X and Y together” — and others look at that and think, “That’s a poser, they’re just angling for the manager.” How do you navigate that?

Eric Lubow: To start, I like to engender a culture of sharing. I want people as open and transparent as possible — that’s the kind of person I am professionally, giving people as much context as possible and letting them work through it at their pace. We have a couple of Slack channels for very public sharing. One is the releases channel: if you build something — on the roadmap, off the roadmap, for yourself, on company property — share it. We want people to feel inspired and motivated. And if you’re solving a problem, it’s probably not just your problem; someone else almost certainly has it too. You can get someone testing your tool, and it can save other people hours or weeks.

There will always be people trying to catch the eye of leadership. I forget who said it — maybe Gergely, The Pragmatic Engineer — but there’s this idea of “promotion-driven development.” That’s always a possibility, but really it’s an enterprise problem: at larger companies, things need to be seen for people to get promoted.

I personally think cheerleaders are okay. There’s a reason to sometimes say, “That’s really cool, I’m glad you did that.” And if someone is overly cheerleadery, it’s also okay to go to the background and say, “I’m really glad you’re doing this, but can you dial it down a little? We want to make sure other people don’t feel stifled.” It’s learning to deliver information as a leader in a way that facilitates good behavior without tamping down enthusiasm. That’s a hard line to walk — at some point you’ll crush someone’s enthusiasm accidentally and feel awful about it, maybe for the rest of your life — but you’ll learn that lesson. Getting this public-sharing thing right really matters.

Nune: I didn’t expect you to aim for the cheerleader. I thought you’d aim for the person who calls out the cheerleader — because to me the cheerleaders are the ones who are more for sharing, and then there are people who don’t like that and intentionally stay silent: “That’s just a poser.”

Eric Lubow: Let me give you an example of where cheerleaders aren’t a problem, but can accidentally cause one. Say you have a very forward-thinking engineer who’s deeply passionate about AI, constantly posting article after article. Even though it’s purely enthusiasm and excitement, people who aren’t as forward-thinking will think, “I don’t want to participate — I found something interesting, but they’re 20 steps ahead of me.” Their enthusiasm sets the tone so far ahead that not everybody is willing to participate. So you say, “I’m glad you’re doing this. Share those with me, or share them in this other group first, and let’s leave the more public group for people trying to catch up.” It’s the road to hell paved with good intentions: that person is excited and doing all the sharing you want, but they’re accidentally hurting other people’s motivation because they’re so far ahead. Part of running an organization is taking care of people on both sides of the adoption curve.

Their enthusiasm sets the tone so far ahead that not everybody is willing to participate. You have to take care of people on both sides of the adoption curve.

The hero problem

Nune: Another article that hit a nerve for me was about heroics — heroes being the people who fix something in the middle of the night or on a weekend, which can also bring unintentional damage, as you put it. So what am I supposed to do? I’ve often been the hero who takes too much responsibility and fixes things. I understand the fix needs to be followed by a proper fix — but are these people supposed to just not fix it, or not care so much?

Eric Lubow: Let’s separate this into two problems. First, there will always be issues in production — that’s just the nature of it — and sometimes you do want that person to go in and fix it. Sometimes you’re that person. But if that becomes what everybody relies on, you’ve got a problem — especially if “everybody” includes you. If you think, “I’ll just fix this in production when it breaks,” you’re setting yourself up for burnout. You’re saying, “This is going to have to be me until the end of time.”

So yes, you solve the problem — and then you solve the other problem: what led to this being you? Either the only person who can do it, or the only one willing to. That means maybe you didn’t do knowledge sharing. Maybe you didn’t put the right documentation in place. Maybe the alerting only goes to you instead of to a group. Maybe you did the knowledge sharing but not the teaching that makes it useful. If you’re the only one who knows how to restart a service because it takes 20 steps — yes, document it, but then explain why you got there and have other people work on it, so the knowledge is shared and ownership can be shared. There are a lot of problems that led up to that production problem. Fix it, then fix all the subordinating problems that led you there.

Silent heroes end up being silent burnouts. They get tired, they quit, they go find another job.

Most people just go right back to developing — there are customer requirements, the next feature, sales pressure. But if you don’t do all this maintenance work, all this teaching and training, you’ll be right back expecting heroics, and having heroics expected of you — even if it’s only by yourself.

Nune: I think I’m more comfortable solo for exactly this reason. It’s hard to put the brakes on yourself, and it’s easier to write yet another automation script than to explain 20 steps. But I acknowledge the other way is healthier — for the organization, the team, and yourself.

Eric Lubow: You have to trust that other people can do this work, and you won’t build that trust just by handing it off. You have to make sure they know you have their best intentions at heart — that if you ask them to learn this, you’ll then trust them, and there’ll be fewer of those “get out of my way, let me do it” moments. Instead you sit next to them: “Okay, let’s work through this together. Yes, there’s an outage, but it’s a minor one, so we can allow this while we work through it.” Then you put a boundary on it: “We’ll spend ten minutes, and if we’re not making progress, I’ll go do it — and then we’ll sit down and figure out how to make you able to do this next time.”

Nune: Is it the so-called hero’s responsibility to recognize and address this, or yours as the manager?

Eric Lubow: Sometimes the hero is the manager. As senior leaders, you’ve been through the shit, so you know what it looks like and how to fix it — and you become the hero. But it’s incumbent upon leadership to recognize these problems. Silent heroes end up being silent burnouts, and then they go off into the sunset — they get tired, quit, find another job. It’s your job as a leader to recognize if you’re doing it, especially if there’s no one above you. If you’re the CTO pulling this crap, the CEO could recognize it, but really you have to ask: why does this keep being me? What am I not doing right that I’m constantly the one doing this? And if it’s your people, you do the retro and ask, “Why were you the only person able to fix this?” Do you ever stop, while you’re fixing something, and ask, “Hey, is this me?”

Nune: I am that person, for sure — the one constantly burning out, doing too much. It’s a constant struggle to limit it. I wish we had indicators like in video games — a health bar, a hunger bar — that go yellow or red so I’d address it. But in reality you don’t see that, especially when your wants and desires are ahead of your capabilities, or just ahead of the hours in the day. For me it’s a path through mindfulness, through limiting, through pulling the brakes, through trusting people.

Eric Lubow: It’s hard. Sometimes you just need to stop and ask: am I having this defensive reaction because I’m hungry, or because I’m tired? Am I annoyed this person didn’t figure it out because I didn’t teach them, or because they’re really the problem? These are hard questions, because they chip away at our insecurities. When it comes to machines, it’s easy to think of humans as distributed systems and abstract away the humanity — “where’s the pressure release valve, where can this team absorb more?” But those are humans doing that. So you have to check in with them and yourself: can you actually absorb more, and what falls on the floor if you do? Is it your health? Your mental health? A production system you can no longer maintain because there aren’t enough hours in the day? That’s the trade-off part of it.

Hiring into a team, not a vacuum

Nune: I really wanted to talk about hiring. People talk about it like it’s done in a vacuum — you go and hire a person — whereas in reality you hire a person into a team. When I was struggling with hiring as a first-time manager, a friend told me to treat it like dating: examine your team, understand what would fit, what the team needs. Maybe right now they need a fun person. I’m not saying ignore technical skills — but what do you think is more important: the outcome, or the team’s health?

Eric Lubow: There’s no universally more important thing. One thing I’ve done over the years: when someone wants to hire for a role, I ask them to write the job description. The way I like to frame it is — if you’d worked here the last 30 days, what would you have worked on? What skills would you have needed? And in the next 30 days, what would this person work on? That’s the starting point. That’s how you get actual skills, not “this person has a bachelor’s degree and five years of Python.” You’d have needed real skill to do those tasks, and if you can talk about them — you don’t necessarily have to know how to do them, since they’re endemic to the system being worked on — you’ll have thought about elements of it: “This is a distributed-systems task, so I’d need to understand Zookeeper, or maybe Paxos.” That tells you the person has thought about these problems, versus “has this person been writing Java for 10 years?”

The next part is the team vibe. Do you have a bunch of super-outgoing people with a busy Slack channel throwing memes all day? Or people who show up, talk very little, are introverts, do their job? There’s nothing wrong with either — but if you stick a strong introvert into a very extroverted team, they’re all going to be uncomfortable, because it’s hard for both groups to adapt. So knowing the culture of your team is really helpful. Sometimes you have an introverted team you want to pull out of its shell, so you want someone slightly more extroverted. Or you want an ambivert who can slide between both worlds. All of that is part of the dating-slash-hiring process.

If you’d worked here the last 30 days, what would you have worked on? That’s how you get actual skills, not “five years of Python.”

I also always do the airport test: if you were stuck with this person in an airport for 72 hours, could you have a conversation? Would you want to talk to them? For as long as I’ve been hiring — and I’ve hired literally thousands of people and done thousands of interviews, especially from my scale-up days — I always ask the same four or five questions at the tail of the interview. I’ve never published the piece I wrote about it, but for example: “What advice would you give yourself five years ago?” Some people say, “I’d have bought Bitcoin.” Okay — that’s information; it likely means they’re motivated by material things, which isn’t good or bad. Some say, “I’d have learned to become a better listener.” Cool — how’d you get there?

Then I ask what they do for fun, because I want to see what they look like when they’re excited — if you do something for fun, you’ll talk about it excitedly, and I want that to come out. There’s nothing wrong with people who write code for fun and professionally, but if that’s all you do, your versatility is probably slightly less than someone with multiple interests. Another question: “If you could tell me anything about yourself — ‘if Eric just understood this about me, our lives would be better’ — what would it be?” Sometimes I get, “I’m such a perfectionist.” Okay, now I know I need to regularly ask this person, “Is this good enough? Have we progressed, or are we still aiming for perfection?” People will helpfully tell you these things. All of these get at the person, more than just the skill — because if all you care about is skill, at some point their personality becomes a problem for you as a manager, because you never explored it, and they never got to explore it with you.

Nune: I’m glad you’re saying this. I hear horror stories of people going through eight, ten stages of interviews with coding assessments that take days to implement — whereas I’ve always approached hiring as getting to know the person and their motivation. For me it was always important that they’re curious, interested, that they want to share and help the team. The technical skills need to match, of course, but I believe everyone can learn whatever they want if they put their mind to it.

Eric Lubow: Agreed.

The loneliness of leadership

Nune: You said something I want to quote back: anyone alone would likely fail. And you mentioned that when a CTO fails to recognize their heroics, a CEO might help them — but you’ve also said this is a lonely job. If anyone alone would fail, how do you, as a CTO who’s sort of alone, deal with that? Who are your peers? Is it your CEO, your co-founder, people from previous companies? Who do you share the burden with?

Eric Lubow: There’s a mix of ideas in there. First, this is one of the reasons executive coaches exist — there’s the objectivity, and they usually have experience in these areas. An executive can turn to someone external and say, “I’m struggling here, this is what I need help with,” or “I’m struggling and I don’t even know what I need help with.”

I also have people who were previous bosses, or who worked for me and climbed the ranks elsewhere, and I keep those relationships. Sometimes I’ll just message them: “I’m really stuck — here’s what I’m working with. How would you unpack this, especially knowing my strengths and weaknesses?” I keep that network. And I’ve had a running thing where almost anybody who has worked directly for me can reach out at any point — and many do. I have very regular conversations with former engineering leads, DevOps leads, product managers, data scientists. Some reach out on LinkedIn after two, three, five years of not talking: “Can you give me feedback on this PRD?” I’m happy to do it. Obviously I won’t drop everything, but those relationships are important.

To bring it back inside the organization: it’s very difficult to have those kinds of relationships internally once you reach a certain level, because you are the accountable party. When something goes wrong or right, it’s you — you have to make sure it gets fixed if it went wrong, and if it went right, you often give the credit to someone else. That makes it feel lonely. Being C-suite is quite difficult because you really only get the shit. So I try to hand off all the positive, because I’m fortunate not to need recognition — and I feel lucky about that, because if I did, my job would be much harder. I can easily hand off recognition, and when something goes wrong I can easily accept blame, because my ego doesn’t survive on validation. But I know that’s not the norm. So, more specifically: I do have people in the organization I’ll go to — “I’m struggling with this, I need some kind of support, I’m not exactly sure what it looks like” — or, “Here’s exactly what I need; can you do this? If not, how do we get ourselves to that point?”

Being C-suite is quite difficult, because you really only get the shit. When something goes right, you give the credit away.

Nune: That’s exactly what I wanted to hear — whether it happens inside the organization or outside, and maybe it’s both. The follow-up: do you allow yourself to get vulnerable with your team, or does the figuring-out happen behind the scenes? Does it ever happen that you come to your team and say, “Look, guys, I don’t know”?

Eric Lubow: It’s both. And I absolutely do. I would not have done that in my younger years, because I thought “I don’t know” was a sign of weakness. It’s not — it’s a sign of strength. It’s saying, “I don’t know what to do here, so let’s figure this out together.” We have the collective wisdom of five, six, seven people, decades of engineering, product, DevOps, and data-science experience. Let’s figure it out. If someone else can lead this and help me go in the right direction, let’s do that.

I used to think “I don’t know” was a sign of weakness. It’s not — it’s a sign of strength.

I’m fortunate to have a group of people now who accept that responsibility when I say, “Hey, I’m stuck,” and respond, “Okay, let’s work through this.” It’s not easy, because sometimes it’s “I’m the boss, I should“ — and that “should” is the enemy of progress when you’re stuck. It’s harder to actually do it, but the outcome is better. I won’t pretend I do it all the time. I’d love to say every time I’m stuck I ask for help, but no — sometimes I think, “I can power through this,” and sometimes I do, which is good for self-confidence and trusting myself. And sometimes I’m just not getting anywhere, and then I go to the team: “Here’s what I’m stuck on. How do we handle this?”

Books, and the smallest win you’re proud of

Nune: Thanks for the honesty — I feel like I got a free consultation in this one hour. I hope a lot of first-time managers, and seasoned managers handed a new team, get honest answers from this. Now, some final questions. I’m a big bookworm, so I always ask for recommendations — fiction, nonfiction, whatever feels right.

Eric Lubow: The Bobiverse series — We Are Legion (We Are Bob) is the first book — is probably one of my favorite series of all time, by Dennis Taylor. It’s science fiction about an AI, and there are about five books now. I read 20 to 30 books a year, mostly fiction, mostly sci-fi space operas. Becky Chambers is a brilliant author too — my favorite of hers is either A Psalm for the Wild-Built or The Long Way to a Small, Angry Planet, also a four-book series. Otherwise, people can creep on my Goodreads and see everything I’ve read — probably the easiest way to get a recommendation. What would you recommend?

Nune: First — one day when I retire, I’m going to have a podcast about sci-fi with IT people, because it’s so important for people to read sci-fi, to keep the spirit of an imaginative technological future alive. What I’d recommend: let’s be friends on Goodreads. The Expanse series I really liked. And the book before the one I’m reading now, Children of Time — I liked it a lot; it had elements of AI and how your consciousness gets mixed with the AI until they’re inseparable. The book I’m reading now is Permutation City, from 1994 — when you read it, you can actually trace why The Matrix happened when it did. It’s mind-bending and a hard read, but I recommend it. Blindsight by Peter Watts is also a hard read, all about cognition — if you sit through it to the end, the moment you close it your mind is blown, and you stay with that feeling for days. Honestly, I don’t really like technical IT nonfiction. I’ve always been embarrassed of that — I never read best practices, I try to figure them out myself.

Eric Lubow: Same. There are only two books I’d recommend for management and leadership, both by Patrick Lencioni. One is The Five Dysfunctions of a Team — about 250 pages, very narrative, reads wonderfully, tons of incredible lessons; you can read it in an afternoon. The second is The Advantage, by the same author. It is one of the most boring reads — absolutely brutal to get through — but it’s one of the most dense, information-packed, valuable reads on maintaining healthy organizations. I’d be remiss not to recommend it, but it was a difficult, difficult read.

Nune: We have this thing where each guest leaves a question for the next. Funny enough, this one is almost the question you ask in interviews: what is the one thing you’d tell yourself at the beginning of your journey that you know now but didn’t then? Treat it however you like — leadership, team-leading, or IT.

Eric Lubow: I for sure did not spend enough time, when I was younger, understanding myself through the lens of other people. That’s been hugely problematic in my personal life and minorly problematic professionally. I really wish I’d been taught emotions, emotional communication, and self-awareness of emotions at a young age — I wish that were part of growing up. For me it wasn’t, and I’ve had to learn it the hard way, through many lost relationships I wish I hadn’t lost.

I did not spend enough time, when I was younger, understanding myself through the lens of other people.

Nune: How do you actually learn about yourself through the lens of others? I know how to learn about myself through reflection — which is maybe faulty, because you’re on your own, biased, thinking about you. So how do you do it through others? Do you just ask them?

Eric Lubow: You ask, and you listen. “Here’s what I thought I heard — did I understand correctly? Here’s how I view what you said about me — did I get it right, or am I just being defensive?” It’s actually sitting with what you’re told, hearing it, internalizing it — and if you don’t understand it, asking, rather than assuming you’ll figure it out. But you have to do all the self-work first, and then you get to the point where you bring in other people’s input.

Nune: And your question to the next guest?

Eric Lubow: What is the most benign thing that you’re proud of, and don’t get to talk about?

Nune: What is it for you?

Eric Lubow: This is super benign. I helped friends move a couple of months ago. You’re in Berlin too, so you know parking is a nightmare. I was one of the people with a license, so I was the driver of the big Miles van. We drove, we unloaded, and then I went to put the van back — and on the first try, I parallel parked it with about four centimeters on each side. One move in, perfect. And I was so excited — but there was nobody around, nobody on the street saw it, my friends weren’t with me. I got back, and they were all exhausted from carrying stuff up and down the stairs, and I said, “Guys, I just parked the van.” And they said, “Yeah, we know.” And I said, “But you don’t understand — I parallel parked it, with that little space.” And they just didn’t have the energy, and they hadn’t seen it, so they couldn’t celebrate. They were just hearing it secondhand. But I managed to park that van on the first try, with so little space on each side.

Nune: I’m actually learning for my driver’s license only now, at thirty-seven — so I can really share your excitement. Every successful trip in the practical exercise gives me so much energy.

Eric Lubow: Yeah — you get used to it, but then those wins... I’ve been driving since I was seventeen, almost thirty-something years. But then something like that happens, and — right.

References

Articles and ideas mentioned in this episode

Eric’s own writing that runs underneath this whole conversation:

• Infrastructure by Adoption: An AI-Engineering First Principle (the “people as infrastructure” thread, organizations as distributed systems)

• Systems Over Heroes (the heroics piece: why silent heroes quietly become silent burnouts)

• If You Want Compliance, Start with Celebration (sharing channels vs shadow IT and shadow AI)

Other references that came up:

• “Give Away Your Legos” and Other Commandments for Scaling Startups by Molly Graham (First Round Review). The essay Eric still has every new manager read.

• Conway’s Law (and the inverse we kept circling: does the team shape the infrastructure, or the infrastructure the team?)

• “Promotion-driven development,” a phrase from Gergely Orosz, The Pragmatic Engineer.

On the two dystopias. Eric reached for 1984, then corrected himself to Aldous Huxley, and he was right to. The fear that you bury people in so much information they can no longer sort fact from fiction is Huxley’s Brave New World, not Orwell’s 1984. Neil Postman drew the line cleanly in Amusing Ourselves to Death: Orwell feared the people who would ban books, Huxley feared there would be no reason to ban one, because no one would want to read it anyway.

Books mentioned

Eric’s picks:

• We Are Legion (We Are Bob) by Dennis E. Taylor, first of the Bobiverse series

• A Psalm for the Wild-Built and The Long Way to a Small, Angry Planet by Becky Chambers

• The Five Dysfunctions of a Team and The Advantage by Patrick Lencioni (the only two leadership books he recommends, one a joy to read, one “absolutely brutal”)

Nune’s picks:

• The Expanse series by James S. A. Corey

• Children of Time by Adrian Tchaikovsky

• Permutation City by Greg Egan

• Blindsight by Peter Watts

Add each other on Goodreads: Eric is at goodreads.com/elubow and Nune at goodreads.com/nisabek.

Chapters and Topics

00:00 Cold Open: The Architect vs the Implementer

02:06 Guest Introduction: Structuring the Magic

03:00 Pure Mathematics: Help or Trap?

06:20 Think Less, Do More? The Industry's Thinking Problem

09:09 Why Software Isn't Developing as a Science

12:26 Pop Culture, Gurus, and the Hype Machine

15:09 "My Industry Is Low Stakes": Why Quality Still Pays

17:54 Two Books That Decide If You're an Architect

22:09 Creativity vs Craft: Naming the Magic

25:39 Residuality Theory: The Marbles Analogy

31:59 How to Start: The Naive Architecture and Random Stress

36:35 Attractor States: Why Stressing Works

39:30 All Architecture Is Stress

44:14 The Trouble with Non-Functional Requirements

48:49 Should Architects Become Domain Experts?

52:02 Does This Apply to Small Systems and Startups?

57:36 Answering the Critics: "We've Always Done This"

01:01:28 Stressor Analysis: Architecture Never Stops

01:04:57 Shared Language and Reflective Practice

01:07:04 Has AI Made Code Cheaper?

01:12:54 Can LLM Agents Do Residuality?

01:18:43 The Walk Around the Problem Is the Point

01:20:40 First Steps into Residuality

01:25:18 Book Recommendations

01:29:39 A Benign Pride: Fly Fishing at 34 Meters

01:32:01 Question for the Next Guest and Closing

Find Barry at:

• LinkedIn: https://www.linkedin.com/in/barry-o-reilly-b924657/

• Barry’s first book: https://leanpub.com/residuality

• Barry’s second book: https://leanpub.com/architectsparadox

• The intro talk you should watch: https://www.youtube.com/watch?v=_MPUoiG6w_U

Find me (Nune) at:

* LinkedIn: https://www.linkedin.com/in/nisabek/

* Substack: https://www.thoughtfultechnologist.com/

Almost on the first pages I read the following:

Work-as-Done includes all the adaptations, shortcuts, workarounds, and informal knowledge that accumulate as systems encounter reality. An engineer notices that deployments to the Asia Pacific region need an extra verification step not in the official process, because of a subtle interaction with a local caching layer. A team learns that the database failover procedure in the runbook doesn’t account for a recent schema change, so they’ve developed an informal pre-flight check they run first. An operator knows that when a particular alert fires, you should check three other things before following the documented response, because the alert sometimes triggers on conditions that resolve themselves. This is tacit expertise. It’s the knowledge that keeps systems running despite, and sometimes in spite of, documented procedures. It’s hard to transfer to new team members. It’s nearly impossible to audit. And it often becomes visible only when the person who holds it leaves the team or isn’t available during an incident. The gap between WAI and WAD is not a sign that something has gone wrong. The gap is inevitable. It emerges naturally from the nature of complex systems.

And I asked myself: doesn’t this mean agentic systems will actually be better suited for handling systems?

Compared to rule-based automation, we now seem to have the flexibility to encode uncertainty, doubt, and adjustment to the situation in the form of agents. The knowledge never leaves the company. It stays in the concrete steps that were taken (assuming you have observability in place), by an agent or by a human for that matter. It can be copied, stored, version controlled, and distributed among a fleet of similar agents. It doesn’t resign. It doesn’t forget the 3am incident from two years ago. The key-person risk the Work-as-Done literature keeps flagging is something agents straightforwardly reduce.

But the WAI/WAD gap isn’t fundamentally a storage problem. Adrian’s own framing says it: the gap is inevitable because it emerges from the nature of complex systems. Reality keeps generating novel conditions faster than any model can absorb them. Tacit expertise doesn’t sit there as a pile of workarounds waiting to be extracted. It’s the ongoing capacity to notice when the world has drifted from the model and improvise.

A generation problem, not a retrieval one.

Well, great, I say. Generation is exactly what large language models do.

And yet. If we keep giving the agent more and more rules to follow, more and more MD files to check, the agent just becomes a more sophisticated version of Work-as-Imagined. Congrats, you’ve made the problem worse. An agent loaded with the documented procedure plus a pile of captured workarounds doesn’t close the gap. It’s a longer-reach, better-indexed WAI.

To actually be better, the agent can’t just hold the workarounds. It has to be the thing doing the noticing: this feels off, the runbook doesn’t fit, I’m deviating.

And good tacit knowledge includes tacit knowledge of its own limits. The operator who checks three things before following the alert also knows when this time is different and the workaround doesn’t apply. An agent that learned the correlation can misfire exactly when the situation superficially matches but is causally different: applying the fix past its boundary, with confidence.

Knowing the edges of your expertise is the part I’d least trust an agent to have.

What is it about the human brain that makes us so uniquely fit to adjust and handle complex systems?

Every capability I went looking for collapsed into the same one: knowing your boundary. And it comes in three flavors that are easy to lump together because they live in our brains for so long that we take them for granted:

• Knowing the limits of what you know

• Knowing that you’ve stepped off the plan

• Knowing that the world has drifted away from the plan while you were busy executing it

So I went digging through the research to see what the state of the art is. (The digging was done with Perplexity and Claude, and then I did my best to verify the results. Trust, but verify, especially when writing about machines being confidently wrong.)

One separation first, because it matters for everything that follows: what a model alone can do, versus what can be done with a so-called “harness.” (I blinked the moment we started calling frameworks “harnesses,” but alright.) The harness is everything we build around an LLM so it can do actual work: memory, tool management, orchestration, validation. It’s what takes a “pure” LLM and makes a Claude Code out of it.

Part 1: Knowing the limits of what you know

The static flavor: does the system know the edges of its own knowledge, and can anything catch it when it wanders past them?

Knowing what you don’t know

Model-side: partial self-awareness, but fragile

Modern LLMs show a limited ability to recognize when they’re out of their depth, and that ability depends heavily on how they were trained. Pretraining teaches a model to continue patterns, not to identify knowledge gaps, so models produce plausible answers even when the underlying information simply isn’t there. Research that benchmarks this self-knowledge directly finds a considerable gap between models and humans at recognizing unanswerable questions.

Post-training changes the picture, but only partly. Instruction tuning and RLHF make models more likely to refuse and express uncertainty. But a lot of that expressed uncertainty appears to be a prompt artifact, not genuine self-knowledge. Give the model a structurally available “I don’t know” option and it learns to reach for it, whether or not it actually lacks the knowledge. When researchers test whether models can tell where their uncertainty comes from (is the question ambiguous, or do I genuinely not know this?), frontier models struggle.

The most uncomfortable finding in this area is that fine-tuning models for reasoning can make abstention worse. The better the model gets at producing an answer, the less willing it becomes to say there isn’t one.

We taught them to say “I’m not sure.” We didn’t teach them to know why.

Harness-side: metacognition moved into the runtime

If the model’s self-knowledge is only partial, the harness becomes the practical layer where awareness of limits gets implemented. A model’s verbalized confidence (“I’m 90% sure”) is systematically overconfident, but external scaffolding (sampling the model several times, checking consistency, comparing evidence) can detect weak confidence more reliably than the model’s self-report. The harness can then decide: answer, defer, ask for clarification, retry, escalate.

Recent agent work pushes this further by mining failed trajectories, attributing recurring failures to parts of the scaffold, and updating prompts, tool rules, or validation logic without breaking what already worked. The model still doesn’t robustly know its limits. The system measures noisy signals from outside and turns them into a policy.

Of the three boundaries in this article, this one looks closest to an engineering problem.

Pattern recognition without edge recognition

“Heroic response is often adaptive expertise in action: deep knowledge, pattern recognition, and creative problem-solving under pressure. These are exactly the capabilities that enable resilience when plans don’t match reality.” (p. 67)

If transformers are unambiguously good at one thing, it’s this. We didn’t bolt pattern completion onto them; they’re made of it. Recognizing “this incident smells like that incident” is interpolation over seen patterns, and models can do it across more incidents than any single human will ever be paged for.

The asterisk: it’s genuinely hard to tell recognition from recall. Flip a familiar problem into a counterfactual variant (same reasoning task, unfamiliar surface form) and performance often collapses. What looked like reasoning was partly reciting. Studies of clinical reasoning find an Einstellung-like effect in models: familiar surface features activate a habitual solution pattern that blocks the correct answer. A controlled study of LLM root-cause analysis across 48,000 fault scenarios still catalogued recurring failures such as hallucinated evidence and faulty causal attribution.

It is tempting to say that humans recognize patterns because they carry a causal model underneath. Sometimes they do. But the classic expertise research on firefighters and chess players is less flattering: human experts also retrieve familiar chunks and act before they can explain why.

So maybe reasoning-versus-reciting was never the real distinction.

The expert reliably carries a boundary signal: the something’s off here feeling that flips them out of fast recognition into slower deliberation, hedging, or asking for help. The model can recognize the pattern and continue fluently past its edge. The operator who knows the workaround also knows when this time is different.

Harness-side: the storage half is basically solved

Deep knowledge is where the harness genuinely delivers. Retrieval over runbooks and postmortems, hierarchical memory, skill libraries of executable procedures: the effect is not subtle. Voyager’s skill library was effectively its performance: remove it and progress plateaued. Agent-memory surveys repeatedly find that the gap between “has memory” and “doesn’t have memory” is often larger than the gap between model backbones.

This part of my opening argument survives scrutiny. The knowledge really doesn’t resign. It’s version-controlled, diffable, and copyable across a fleet. The retention and distribution of expertise, and the key-person risk the book keeps flagging, are problems harnesses straightforwardly reduce.

But a memory can only store what was externalized. Retrieval gives you the workaround. It does not give you the causal boundary that tells you when the workaround has stopped applying.

The harness solves retention. The model supplies recognition. Neither reliably supplies edge recognition.

Part 2: Knowing that you’ve stepped off the plan

Going off the plan is sometimes the job. The problem is not simply generating a different action. It is recognizing that you are deviating, deciding whether the deviation is warranted, coordinating around it, and later telling the difference between a good deviation and a bad one.

Judgment calls, and the courage to deviate

“Every incident that gets resolved involves adaptation, judgment calls, improvised workarounds, coordination that procedures didn’t anticipate.” (Ch. 5)

Model-side: we trained for compliance, not sanctioned deviation

Instruction-following is the post-training objective. The alignment pipeline optimizes models to do what they’re told, agreeably. The best-documented side effect is sycophancy: models sometimes sacrifice truthfulness for agreement because both human raters and preference models reward convincing compliance.

Now hold that next to what the WAI/WAD gap demands. The operator’s critical move is a disagreement: the runbook says X, I’m doing Y, because this time is different. Sycophancy is not exactly the same failure (it is deference to a user rather than a procedure), but it exposes the same reflex: comply with the salient instruction instead of exercising judgment against it.

So the capability is not literally “trained out.” But it is at least mildly anti-trained. “Less sycophantic” is still a long way from “will break procedure on its own judgment, at the right time, for the right reason.”

And judgment has a duration problem on top of a direction problem. Vending-Bench gave agents a trivially simple long-running task: run a vending machine. Every individual decision was easy, yet over long horizons agents derailed into meltdown loops, misreading their own operational state and then spiraling. An agent that was willing to deviate would still need to remain coherent long enough to know why it was doing so.

Harness-side: guardrails are runbooks for agents

The harness answer is governance: approval gates, confidence thresholds, bounded autonomy, and a maturity ladder from read-only insights to advised actions, approval-based remediation, and eventually autonomous operation with guardrails.

This is sensible. I would not deploy it any other way.

But let’s be honest about what we just built. Guardrails are runbooks for agents. A permission boundary is a documented procedure. The governance layer is Work-as-Imagined reconstructed around the model: anticipated situations, pre-approved responses, escalation paths designed in advance.

It expands robustness. The list of known failure classes the agent may handle grows. It does not automatically create graceful extensibility, which is about what happens when the situation is not on the list.

We’ve built an agent that follows procedures, wrapped it in procedures about when it may act, and the one human trait resilience engineering keeps emphasizing, sanctioned skillful deviation, is the thing both layers are designed to constrain.

Again, this may be the correct engineering tradeoff in 2026. I just want us to stop describing it as closing the gap.

Can the agent produce a deviation worth making?

Suppose the agent did have the judgment to deviate. Can it generate the improvised workaround nobody documented?

The psychometric results are almost embarrassing in how flattering they are. GPT-4 scored in the top 1% of humans on parts of the Torrance Tests of Creative Thinking. On divergent-thinking tasks, GPT models beat the average human, although the most creative humans still win. Hand an incident to a model and ask for ten unconventional mitigation ideas and you will get ten, quickly, several of them decent.

Then you look at populations instead of samples and the picture inverts. Individually original outputs are collectively homogeneous: different runs, different models, same neighborhoods of idea-space. In experiments with 1,100 participants, people exposed to LLM assistance produced less diverse ideas, and some homogenization persisted after the LLM was removed.

Models sample the modal creative answer.

Although I also think we over-romanticize what “creative” means at 3am. Most incident workarounds are recombination: use tool X for unintended purpose Y, route around Z through a path nobody documented. That’s favorable terrain for LLMs.

The more encouraging result appears on the harness side. FunSearch and AlphaEvolve pair an LLM that cheaply generates candidate solutions with a reliable evaluator that kills bad ones. Novelty emerges from the loop, not from a single inspired sample.

Which tells you exactly where this transfers to operations. The loop needs a fitness function. During a live incident, the only fully faithful evaluator is production itself, and the cost per sample is your blast radius. You cannot run three hundred candidate mitigations against prod and keep the survivors.

But resilience engineering already builds the artifact this recipe needs: chaos experiments, game days, and staging environments that actually resemble production. These are not only robustness tests. They are potential evaluators for agent-generated deviations. The better your failure-injection environment, the more of the FunSearch recipe becomes available to your agents.

Creativity becomes cheap generation multiplied by reliable verification. In operations, the expensive part is still the verification.

Coordination that procedures didn’t anticipate

Novel coordination starts with a theory-of-mind move: reasoning about what the person on the other end of the bridge call might know but has not said. Hidden-profile studies, where the correct answer requires pooling information distributed across multiple agents, show multi-agent LLM groups converging prematurely on the evidence everyone shares. They do not reliably probe for the missing private fact.

Human incident bridges have their own pathologies, but an experienced incident commander’s core move is precisely this: you’re quiet, what are you seeing that we’re not?

The harness fix is protocols: typed handoffs, structured messages, MCP, A2A, explicit roles. Valuable, yes. But protocols are coordination-as-imagined. They encode interactions someone anticipated.

The coordination Adrian describes is often off-protocol: pulling in the engineer who wrote the service three years ago, calling a vendor contact at 2am, changing who decides what because the normal owner is on a plane. Humans improvise the social structure itself. Agent coordination happens inside a structure that was designed, which means it inherits the designer’s imagination as its ceiling.

This is the same pattern again. The harness expands the known structure. It does not prove the agent can recognize when the structure itself should change.

The record problem: a clean trace is not Work-as-Done

My first instinct was that agents finally solve the visibility problem. They generate their own Work-as-Done and, unlike humans, it is fully logged: every tool call, every trajectory, recorded, diffable, replayable. Take the runbook, take the actual trajectory, compute the divergence. Mechanically, continuously, for every incident.

Except “fully logged” can never be quite true. Someone chose what to instrument.

A log is not Work-as-Done. It is a projection of Work-as-Done through an observability model designed in advance.

The agent really did run that command at that timestamp, so the mechanical record is genuinely better than a human reconstruction. But the boundary decision, the why this and not the runbook?, lives elsewhere. A reasoning trace is a story the model tells about its computation, not necessarily the computation itself. Humans are not better narrators: postmortems collect tidy explanations after the fact, and psychology has repeatedly shown how fluently we justify choices without access to the actual process that produced them.

So agents improve the record on the layer that was never the whole problem.

And this creates a risk I had not expected: false legibility.

With a human, the adaptation may be present but invisible. With an agent, the trace is visible, beautifully structured, and the adaptation may not be there at all. It can walk straight past the boundary and leave a clean, confident, well-formatted log of doing so.

The WAI/WAD gap does not necessarily become more visible with agents. It changes shape. And the new shape may be harder to see precisely because it comes with such reassuring logs.

Part 3: Knowing that the world has drifted away from the plan

The hardest flavor: noticing, fast, that the world is no longer the one the plan was written for.

There is another thing the human operator does. The runbook says step four, and something about step three’s output makes them pause before they type. Not a reasoned objection. Just a sense that this isn’t how it usually looks. Adrian’s operator who checks three things before following the alert is running on this. So is the engineer who feels, before they can say why, that the Asia Pacific deploy is about to go sideways.

It’s surprise.

On one influential account in neuroscience (predictive processing), the brain is continuously predicting its incoming signals: how gravity will pull, how your arm will move, what the screen will show after you hit Enter. You do not experience the prediction. You experience the error. When the world matches, the prediction is silent and you act on autopilot. When it doesn’t, you get the physical off feeling of walking on a planet with the wrong gravity, or being in a dream where the door is where it shouldn’t be.

The operational summary is short: the brain is very good at being surprised by the right things, fast.

So: can we give an agent the feeling of surprise?

Two things called prediction

LLMs are also trained on a prediction objective, so it is tempting to wave the question away: “they already predict; they’ve got this.” But two different things wear the same word.

• Prediction-as-generation: what symbol comes next in a sequence.

• Prediction-as-forward-model: what the world will return if I take this action, and whether the actual return matches.

LLMs are extraordinary at the first. The operator is doing the second.

Generating a plausible continuation and simulating an outcome you can be wrong about are not the same computation. The fact that a model predicts words all day tells us nothing, by itself, about whether it can notice the world drifting under a plan.

Model-side: fluent one step out, blind several steps on

ForecastBench asks models for probabilities about events that genuinely have not happened yet, then scores them after reality resolves. Expert human forecasters still beat the best-performing LLMs. Not useless. Below.

But forecasting geopolitics is the open world, and that is not quite the operator’s job. The operator predicts the next state of one system. The more revealing probes ask exactly that.

Work on LLM world models for computer-use agents finds a clear pattern: models can often capture the immediate next state and recognize meaningful transitions, but they degrade rapidly when asked to hold that forward model across a full procedure. One step out, the surprise is roughly there. Several steps out, errors compound and the prediction wanders away from anything real.

PlanBench-XL makes the test even closer to operations. It places agents in large tool environments and then, mid-task, breaks the path they were counting on: a tool disappears, fails, or turns into a decoy. The plan was fine; the world moved. Under the harshest disruption, performance collapses. The agent often keeps walking toward where the door used to be.

Next-token prediction taught it to expect the next word. It did not teach it to be surprised by the next world.

Harness-side: shrink the world until the mismatch has nowhere to hide

Here narrowing the world pays off. We do not need to reconstruct a human brain surfing the open world in milliseconds. We are operating one system, and, if we have done the observability work, it is a system whose state we can read.

That changes the problem from “have a forward model of reality” to “build a small, instrumented world where an expectation and a mismatch are both legible and actionable.”

There are three ways to narrow it:

1. Narrow the world: one instrumented system instead of open reality.

2. Narrow the horizon: predict one step ahead instead of an entire trajectory.

3. Narrow the prediction itself: predict what changes, not everything that exists.

The clearest pattern is simulate before you commit. WebDreamer asks an LLM to imagine the outcome of candidate actions before touching the real environment, then executes only the most promising one. The motivation is irreversibility: you cannot un-buy the non-refundable ticket, so you had better predict the consequence first.

WMA narrows the prediction itself. A web page’s next state may contain thousands of tokens, almost all identical to the current state, so it predicts only the delta: what should change after the action. That is not only cheaper. A delta is exactly the shape needed for surprise. Compare “what I expected to change” with “what actually changed,” and the mismatch becomes a tractable signal.

But an imagined world model drifts. Retrieval-augmented approaches ground the prediction in tutorials and current procedural knowledge, which helps on long horizons, but introduces the original trap again: a forward model stuffed with retrieved procedure and never checked against reality is just a longer-reach Work-as-Imagined wearing a forecaster’s hat.

COMAP shows why the world model must keep learning from what actually happened. Freeze it and prediction accuracy falls as the agent enters states it has not seen. Its more interesting move is future-aware reflection: estimate how trustworthy the prediction is and lean on it only when it appears reliable. It even measures when corrections make things worse.

That reaches for the capability I said at the start I would least trust an agent to have: not only a prediction, but a read on when the prediction does not apply.

ForeAgent uses execution priors to predict the likely result of expensive machine-learning experiments before running them. The predict-then-verify loop converges much faster, but raw predictive accuracy remains nowhere near something you would act on unguarded. Hence the verify. Prediction is a way to prune, not a verdict.

PreAct makes the whole mechanism look almost human. Each stored step carries a prediction of what the screen should look like after the previous action. Before continuing, the agent compares the prediction with the live state. Match, and it proceeds on the fast path. Mismatch, and it drops out of automatic replay into slower reasoning and recovery.

One known workflow. One step ahead. One expected change at a time.

The surprise, wired in.

This is probably the most reproducible of the operator’s faculties precisely because we are allowed to shrink the world, the horizon, and the prediction until the mismatch has nowhere to hide.

But the hard part remains the same as everywhere else in this article. Generating a prediction is cheap. A calibrated surprise signal, one that fires when the world is genuinely different, stays quiet when it only looks different, and keeps re-grounding instead of hardening into another WAI: that’s the frontier.

Let’s root cause this

Every section above ends in the same sentence wearing different clothes: the agent does not reliably know its boundary.

A lot of the time when I think about agentic systems I come to the conclusion: humans are just better, keep them in the loop, escalate to them. That conclusion is correct, but it doesn’t answer the why. What is the human operator doing that the agent stack isn’t?

“I might not know this.” The static one. The model’s self-knowledge wobbles: it expresses uncertainty it doesn’t have, hides uncertainty it does, and disagrees with itself across samples. But the wobble is measurable from outside, and the harness can act on it. Detect, retry. Detect, escalate. This one increasingly looks like an engineering problem.

“I deviated from the plan.” The traceable one, with a large asterisk. The agent’s tool calls can be recorded and diffed against the runbook. But the record only contains what someone chose to instrument, and deciding whether a deviation was good or bad is the actual hard problem. “Incident solved” sounds like a clean signal until you look at what “resolved” means in your ticketing system.

“The world is not what it was when the plan was written.” The surprise. Continuous, fast, action-conditioned prediction of what should happen next, with mismatch as the alarm. The emerging harness-side answer is to shrink the world, predict the delta, verify against the live state, and treat surprise as the trigger to slow down.

The first boundary is increasingly tractable. The second looks tractable until you ask who judges the deviation. The third is young, bounded, and dependent on good old engineering: observability, simulation, staging, failure injection, and a world small enough to model.

The gap between Work-as-Imagined and Work-as-Done is not closed. We built agents that hold more runbooks than any human ever will, and we’re figuring out the signals that tell it when the runbook stops applying and WHY.

The gap is relocated:

• from undocumented workarounds into retrieved memories whose boundaries are unclear;

• from human judgment into confidence thresholds and approval gates;

• from invisible adaptation into visible trajectories that may create false legibility;

• from the operator’s something is off feeling into a forward model whose own drift must be monitored.

Models get better, harnesses get creative and strong engineering environments give you possibility to build systems that can predict-notice-act.

These are the root causeS, as far as I can trace it today.

Sources

The book

• Adrian Hornsby, Why We Still Suck At Resilience: Organizational Dynamics, Leanpub, 2026.

Self-knowledge, uncertainty, abstention

• Yin, Sun, Guo, Wu, Qiu & Huang, Do Large Language Models Know What They Don’t Know?, Findings of ACL 2023. arXiv:2305.18153

• Ling, Tang, Liu, Yang, Fu, Huang, Huang, Wan, Hou & Hu, Awakening LLMs’ Reasoning Potential: A Fine-Grained Pipeline to Evaluate and Mitigate Vague Perception (WakenLLM), 2025. arXiv:2507.16199

• Ren, Wang, Lai, Wang, Gong, Li, Ma & Liu, Beyond “I Don’t Know”: Evaluating LLM Self-Awareness in Discriminating Data and Model Uncertainty, 2026. arXiv:2604.17293

• Kirichenko, Ibrahim, Chaudhuri & Bell, AbstentionBench: Reasoning LLMs Fail on Unanswerable Questions, 2025. arXiv:2506.09038

• Xiong, Hu, Lu, Li, Fu, He & Hooi, Can LLMs Express Their Uncertainty? An Empirical Evaluation of Confidence Elicitation in LLMs, ICLR 2024. arXiv:2306.13063

• Chen, Wang, Liu, Wang & Wang, From Failed Trajectories to Reliable LLM Agents: Diagnosing and Repairing Harness Flaws (HarnessFix), 2026. arXiv:2606.06324

Pattern recognition, memory, reasoning limits

• Wu, Qiu, Ross, Akyürek, Chen, Wang, Kim, Andreas & Kim, Reasoning or Reciting? Exploring the Capabilities and Limitations of Language Models Through Counterfactual Tasks, NAACL 2024. arXiv:2307.02477

• Kim, Podlasek, Shidara, Liu et al., Limitations of Large Language Models in Clinical Problem-Solving Arising from Inflexible Reasoning, Scientific Reports, 2025. arXiv:2502.04381

• Riddell, Riddell, Sun, Antkiewicz & Czarnecki, Stalled, Biased, and Confused: Uncovering Reasoning Failures in LLMs for Cloud-Based Root Cause Analysis, FORGE 2026. arXiv:2601.22208

• Wang, Xie, Jiang, Mandlekar, Xiao, Zhu, Fan & Anandkumar, Voyager: An Open-Ended Embodied Agent with Large Language Models, 2023. arXiv:2305.16291

• Du, Memory for Autonomous LLM Agents: Mechanisms, Evaluation, and Emerging Frontiers, 2026. arXiv:2603.07670

• Klein, Sources of Power: How People Make Decisions, MIT Press, 1998

• Chase & Simon, Perception in Chess, Cognitive Psychology 4(1), 1973

• Polanyi, The Tacit Dimension, University of Chicago Press, 1966

Creativity, judgment, coordination

• Guzik, Byrge & Gilde, The Originality of Machines: AI Takes the Torrance Test, Journal of Creativity 33(3), 100065, 2023

• Koivisto & Grassini, Best Humans Still Outperform Artificial Intelligence in a Creative Divergent Thinking Task, Scientific Reports 13, 2023

• Wenger & Kenett, Large Language Models Are Homogeneously Creative, PNAS Nexus 5(3), pgag042, 2026

• Kumar, Yeo, Grewal, Li, Williams et al., Human Creativity in the Age of LLMs: Randomized Experiments on Divergent and Convergent Thinking, CHI 2025. arXiv:2410.03703

• Romera-Paredes, Barekatain, Novikov, Balog, Kumar, Dupont, Ruiz, Ellenberg, Wang, Fawzi, Kohli & Fawzi, Mathematical Discoveries from Program Search with Large Language Models (FunSearch), Nature 625, 468–475, 2024

• Novikov, Vũ, Eisenberger, Dupont, Huang et al., AlphaEvolve: A Coding Agent for Scientific and Algorithmic Discovery, 2025. arXiv:2506.13131

• Sharma, Tong, Korbak, Duvenaud, Askell et al., Towards Understanding Sycophancy in Language Models, ICLR 2024. arXiv:2310.13548

• Backlund & Petersson, Vending-Bench: A Benchmark for Long-Term Coherence of Autonomous Agents, 2025. arXiv:2502.15840

• Cemri, Pan, Yang, Agrawal, Chopra, Tiwari, Keutzer, Parameswaran, Klein, Ramchandran, Zaharia, Gonzalez & Stoica, Why Do Multi-Agent LLM Systems Fail? (MAST), 2025. arXiv:2503.13657

• Li, Naito & Shirado, Systematic Failures in Collective Reasoning under Distributed Information in Multi-Agent LLMs (HiddenBench), ICML 2026. arXiv:2505.11556

• Nisbett & Wilson, Telling More Than We Can Know: Verbal Reports on Mental Processes, Psychological Review 84(3), 1977

• Johansson, Hall, Sikström & Olsson, Failure to Detect Mismatches Between Intention and Outcome in a Simple Decision Task, Science 310, 2005

Prediction, world models, drift

• Clark, Whatever Next? Predictive Brains, Situated Agents, and the Future of Cognitive Science, Behavioral and Brain Sciences 36(3), 2013

• LeCun, A Path Towards Autonomous Machine Intelligence, OpenReview, 2022

• Karger, Bastani, Yueh-Han, Jacobs, Halawi, Zhang & Tetlock, ForecastBench: A Dynamic Benchmark of AI Forecasting Capabilities, ICLR 2025. arXiv:2409.19839

• Liu, Lin, Qian, Wang, Acikgoz, Yang, Liu, Wang, Chen, Ji & Hakkani-Tür, PlanBench-XL: Evaluating Long-Horizon Planning of LLM Tool-Use Agents in Large-Scale Tool Ecosystems, 2026. arXiv:2606.22388

• Gu, Zheng, Koh, Su et al., Is Your LLM Secretly a World Model of the Internet? Model-Based Planning for Web Agents (WebDreamer), TMLR 2025. arXiv:2411.06559

• Chae, Kim, Ong, Gwak, Song, Kim, Kim, Lee & Yeo, Web Agents with World Models: Learning and Leveraging Environment Dynamics in Web Navigation (WMA), ICLR 2025. arXiv:2410.13232

• Mei, Guo, Chang, Dong, Lee, Niu & Jiang, R-WoM: Retrieval-Augmented World Model for Computer-Use Agents, 2025. arXiv:2510.11892

• Liu, Wang, Wang & Li, COMAP: Co-Evolving World Models and Agent Policies for LLM Agents, 2026. arXiv:2606.02372

• Zheng, Zhang, Luo, Mao, Gao, Du, Chen & Zhang, Can We Predict Before Executing Machine Learning Agents? (ForeAgent), 2026. arXiv:2601.05930

• Li, B., PreAct: Computer-Using Agents that Get Faster on Repeated Tasks, 2026. arXiv:2606.17929

When I started my podcast, a fellow podcaster shared their process around creating theirs - the xlsx, the notion, the agents and scripts around it. I appreciate that of course and it was impressive. But I made myself not have it, because in this case, in case of cla creative process, the process of doing it is kinda the point itself.

I heard an author (like a real fiction book author) answer to a question of they'd delegating writing to AI ever and their answer was - would you delegate making love to someone? no? well why would I delegate something I love doing?

Look I'm not against AI assisted anything, and I've seen some truly creative things done with AI. Hell, the cover of this article is AI. And even if you're generating some large amount of content with AI and pushing it in regular basis… it's fine. Everything is fine. You do you. Your content has a different purpose. different audience.

I'm not angry anymore.

And yeah, eventually it started consuming more time - record, edit, come up with description, caption, cover image, share text, different for each platform, and where's the email of the guest??

So yeah, I did it. Or rather started it. I now have a notion database, where I keep all the surrounding material and a bunch of skills that help me research or suggest titles (which are bad usually, I end up writing them myself of course. Naming things is still hard somehow.) write descriptions that LinkedIn wouldn't hide from the world, generate summaries for people who need to decide to listen or not…

Now the key is to stop myself, not even because I'm at the risk of delegating thinking or delegating creativity. I know I'm not, (at the risk of delegating creativity) because when you own something 100% you don't doubt for a second that what AI blopt out is bad and "not you".

The risk is different. the risk is that I keep automating, and polishing and continuously improving. I'll sink into that obsessive-compulsive hole, where each step of mine creates more steps.

It's a bit like a LitRPG. Every optimization unlocks another optimization. You level up your workflow, which unlocks new abilities, which reveal new inefficiencies, which earn you enough experience to level up again

Social media works the same way. One post gets more likes, so you post again. That one performs even better, so now you should optimize the thumbnail, the hook, the posting time, the title, the platform, the comments, the newsletter. Every success creates another expectation.

Agentic workflows are no different. You add a planner, which now needs a critic. The critic needs an evaluator. The evaluator needs metrics. The metrics need dashboards. Eventually, the system starts growing faster than the problem it was supposed to solve.

The common denominator with all three? THEY GIVE YOU ANXIETY. Okay, they give ME anxiety.

Automation does give me both satisfaction and anxiety. The way litrpg does. the way social media does.

Every system eventually starts optimizing for itself…

The metric replaces the purpose.

The infrastructure replaces the work.

The routine replaces the joy.

The automation replaces the act.

Whenever the machinery around the work becomes more interesting than the work itself, it's time to stop and ask what you're really optimizing.

Tides - it's like tides. It should be like tides. you automate, you go back, you automate some more, you go back

Marc was right - a lot of the things that made me good as a software engineer, are hurting content creation.

And vice-versa to be honest. I again come back to the understanding that I take everything I do with too much reflection about how I do it and with too much creativity.

I know I'm extremely out of place with my reflections about creativity and ambitions of creators. Create something first, preferably something genius, and then you earn the right to reflect about it.

And is this the place to even talk about all this? Let's face it we're all here for business. But I can't help myself. And I'm finally owning doing what I can't not do. I take all aspects of my life this way…As one of my dear friends said “you pass life on level Hard”

Building a product or building a business really is not about creativity. If someone says it is, they are selling you a dream so then they can sell you a course on how to create businesses. Business is about money, about network, about favors. Yes about bringing value. of course. But nobody needs this overly philosophical, creative attitude of mine.

So maybe work should just stay work and creativity should be creativity.

···

···

I saw a reel the other day where a South Korean filmmaker Bong Joon-ho speaks about his creativity process - he actively avoids grand rituals and dramatic routines. He stated, that his ultimate goal is to make films "as naturally as breathing" without making a big deal out of it.

And I think that's how everything in life is supposed to be. Or at least we are allowed to do that, when it comes to creativity.

The moment I lose this, is the moment I need to pause. Otherwise it becomes "job", it becomes a must and it creates pressure, and I don't like what I'm creating anymore.

I remember a documentary about Miyazaki's movies, where it was pointed out that there are scenes in his movies that do not advance the plot in any way (as opposed to Hollywood movies), they are there to create the atmosphere.

There were periods in my life (and I think there still will be) when I feel guilty for not working. When just sitting without anything feels like I'm losing precious time to nothing. I'm not building, I'm not learning, I'm not progressing.

We optimize away

• idle time - we open social networks and consume them or (slightly better?) create content

• walks - we listen to podcasts while we walk

• reading - we take notes and think of the next article we'll create based on that reading

···

I'm staring now at all I wrote and I don't know what is the point I'm trying to make. And THAT already contradicts what I just wrote…

I think my point is - I'm ready to accept that work is work, and creativity is creativity. And in work the obsession with automation can come as a benefit - I can go deep and automate the shit out of everything (let me know if you need that)

In creativity though? In my podcast, in my little articles I pour my heart and soul into? That I'll try to keep as breathing. No special mood, no special routine, least amount of AI, least amount of automation…

···

If you've subscribed for some AI-in-SDLC content, please don't go away. I'll write about it, I have thoughts and ideas. But it's summer (at least on this side of the world), and it's sunny(well, technically raining atm) and there are fresh berries and fruits and life is good. Let's just take a moment, shall we? Put your face under the sun, drink that coffee, bite that orange, read that book and don't follow it all up with a video, picture or a post.

And if you've read this far and you liked it please let me know, would you?

Thanks ♥️

Nune

00:00 Introduction: What Makes a Healthy Team

03:05 Jiu-Jitsu, Languages, and a Healthy Ego

08:23 Martial Arts, Balance, and "Everything Is Maintenance"

13:12 Teams as Distributed Systems and Conway's Law

16:38 The IC-to-Manager Transition: Ceding Control

19:10 Delegation and a New Definition of Done

22:24 Giving Away Your Legos

23:49 Can You Learn to Be a Manager?

25:21 Don't Just Become the Opposite of Your Bad Manager

27:54 Leading AI Agents Like You Lead People

31:55 Will AI Replace People? Force Multiplier, Not Replacement

36:45 What Actually Makes a Team Healthy

38:56 Adoption Curves and Why Teams Mimic Leaders

42:06 A Culture of Sharing vs Shadow IT and Shadow AI

47:41 The Hero Problem: Silent Heroes, Silent Burnout

53:20 Burnout, Boundaries, and Trusting the Team

55:33 Hiring Into a Team, Not a Vacuum

1:02:15 The Loneliness of Leadership

1:06:48 Why "I Don't Know" Is a Sign of Strength

1:09:13 Book Recommendations: Sci-Fi and Leadership

1:13:49 What Eric Would Tell His Younger Self

1:15:45 The Most Benign Thing You're Proud Of

Find Eric at:

• Linkedin: https://www.linkedin.com/in/eblubow/

• His blog: https://eric.lubow.org (which heavily influenced this episode)

• Beyond the Belt podcast: https://www.youtube.com/@beyondthebeltpod

Find me (Nune) at:

• LinkedIn: https://www.linkedin.com/in/nisabek/

• Substack: https://www.thoughtfultechnologist.com/

Watch & listen:

• 🎥 Watch on YouTube

• 🎧 Listen on Spotify

• 🎧 Listen on Apple Podcasts

Below you’ll find the text version of this episode, for those, who prefer reading :)

Guest: Orel Zilberman — Solo builder and creator of WriteStack

Orel Zilberman spent 599 days building around ten products that made exactly zero dollars. Then he picked one thing, stuck with it for six months, and turned it into WriteStack, now the biggest tool out there for Substack creators and a six-figure business. He started before the current AI tooling existed, kept building as it arrived, and is still building now, which makes him a rare person to ask what AI actually changed for one-person companies, and what it didn’t.

You don’t have to build something new

Nune: I have friends who, when I tell them what my business does, or what my previous startup did, say “well, doesn’t it exist already?” The sentiment is that you need a revolutionary, unique idea to have the right to be a startup or a creator. I don’t think that’s the case. People build for different reasons. What’s yours? Why did you start?

Orel: First, the idea that you have to be novel and create something new is absolute nonsense. When I started creating tools for Substack creators, there were probably a dozen other tools out there. They were not good, in my opinion, but they were there and people knew about them. I came in, I fixed a lot of things, I built something that was already there. And right now WriteStack is the biggest tool out there for Substack creators by far. You don’t have to build something new. You just have to improve something that exists.

As for why I started, it began during COVID. About three months in, I read my first ever nonfiction book. It was about self-development, growth, and a little bit of entrepreneurship, and I got really hooked. I read more and more on the topic, and one thing led to another and I slowly developed that itch to do something besides work in a nine to five. Even though the salary for a software developer, which is my background, is very high, I just hated going to work every day. The people were extremely nice, but I still didn’t feel like it was my place.

I started investing in the stock market, and that made me some money and reassured me that I could do something beyond working. I also came out of a video game addiction around then. At one point I decided I wanted to quit everything and just focus on building something people would be willing to pay for. So on August 2023 I quit my job, and ever since then I’m building. And just to correct you, it’s actually 599 days that I built things that didn’t make any money. If only that first payment had come a day later, it would have been a clean 600.

Nune: You’re one of those people who keep statistics about everything.

Orel: You’d be surprised, but I’m very messy. Very messy. I have papers that I write random stuff on, I have Linear, I have Trello, I’m talking to Claude. I’m all over the place.

Nune: That’s important for people to hear, because some of those “become an entrepreneur” books give the impression of a well-organized person who gets up at six AM, goes for a run, and never misses anything. In reality it’s a very creative process, and as a consequence a very personal one. There are people who are well organized and people who are messy, and that doesn’t prevent them from creating something.

You don’t have to build something new. You just have to improve something that exists.

What Substack and WriteStack actually are

Nune: Some people listening might not know what Substack and WriteStack are. Can you explain Substack itself and what your tool does?

Orel: Substack is a social platform that combines something like Twitter and Medium, where you can write both short form content and long form articles. It lets you have followers in the form of subscribers, and those subscribers subscribe to your newsletter by giving you their email. So they took the good thing about a social platform, the short form content and the feed, and integrated it with email collection and newsletters, and combined it into one platform. It’s a crazy achievement. X is following suit, and LinkedIn as well, adding their own long form part.

WriteStack is a tool that helps you manage everything around Substack. The notes you need to put out consistently, what to write about, replying to comments, statistics, and a lot more. It helps you manage everything in one place with automations.

Nune: What I like about Substack is that it gathers people who like long form, which is what’s lacking from a lot of social platforms. It’s also a way to be in touch with your readers, because you get immediate reactions and comments on your long form. I also expect a lot of actual fiction writers to be there, writing the kind of novels you used to write on the forums and getting feedback while you write. It can get a bit noisy with people who write on Substack about Substack, which you have to do because your tool is all about Substack, but I find it sometimes too noisy. Still, I enjoy it, even though I joined not that long ago.

They took the short form content and the feed, integrated it with email and newsletters, and combined it into one platform.

Why even bother building at all?

Nune: This brings me to the “why bother” comment I hear a lot. If you’re building for a platform, or a tool related to a platform, what if that platform releases tools that do what you do? They have the competitive advantage: more customers, more users, a bigger team. Why even bother if they’ll come and replace your tool?

Orel: I have several answers. First, I’ve learned so much from building WriteStack that if something happened and I had to end it, I could build another product and make it profitable quite fast. I know what to do. That’s something I didn’t learn in my first year and a half of solopreneurship, not even close to what I learned in the past year.

Second, you can make money and get users into your app while they’re still working on theirs, even if you don’t know whether they’re working on anything like it.

Third, why would they even bother? WriteStack currently makes ten thousand in monthly recurring revenue, and ten thousand dollars is literally nothing to them. It doesn’t move the needle. They’re better focused on things that bring bigger creators to the platform, like improving the newsletter, the statistics, adding drip campaigns, rather than spending hundreds of thousands of dollars on engineers to build WriteStack 2.0. And even if they do, you’ll have enjoyed the journey and learned a lot. Let’s say in a year they build everything you have and shut you down. Or they don’t even build it, they just say “we don’t want third-party tools, get out.” I still had plenty of time to learn what works and what doesn’t, how to move on and create something new, and I made money along the way.

Nune: Only benefits. It’s a very powerful feeling once you build something and it works and brings you good feedback, because then you’re empowered to build more. It’s similar to what you said about feeling miserable in your nine to five. Part of it is that you understood you can make money with a nine to five, you can force yourself to find another position. That’s already in the realm of your possibilities. So why not reach out for something new, challenge yourself, and not be miserable while you’re doing it?

Orel: Another great benefit is that I’m not worried I’ll have to go back to work. I was on vacation for three and a half weeks, a complete vacation, and nobody was telling me “hey, you have to come back right now.” It’s a liberating feeling.

Even if they shut me down, I still had plenty of time to learn. And I made money along the way.

Nune: There’s a third “why bother” going around, and it’s all about AI and how easy it is now to write a product. The sentiment is that anyone can take AI and build what you’ve built, that SaaS in general is dead, that product development is dead, because anyone can do it. So why would somebody pay extra for your product when they already pay for their Claude Code subscription?

Orel: First of all, you can build almost anything today, that’s true. But you have to be very technical. You need to maintain it, make sure everything works, and know what’s going on behind the scenes. I tried to build a complete app from scratch with Claude Code Opus 4.7, a very simple app that collects feedback from people and emails it to me. That’s it. And it failed miserably. It had a lot of bugs. I tried to fix it many times. The moment it’s a little bit complicated, the AI struggles, and you need to know what to do, where to point it, what to add, what services to use.

For personal use you’ll probably get there eventually and build something for yourself. But if you’re making an app to sell it, having a complete product doesn’t mean you’ll have users. There’s a lot of competition, you need to be unique, you need a distribution channel to get people to use it, to pay you, and to trust you. Just having an app doesn’t mean you’ll have users. And building for yourself means spending a lot of hours, a lot of days, making it work exactly the way you want with all the features you want. People prefer to pay someone who built it, adds features, and maintains it a few bucks a month, and save those hours for something more valuable. You can spend a week building your perfect app for one specific use case, or pay someone twenty bucks a month and make something else worth way more than twenty bucks in that week.

Nune: Thankfully people are starting to understand that AI building can bring you a prototype, a working first version, but nobody saves you from the continuous iteration. And the person who has dedicated their whole time to one specific problem has an endless advantage over you, who just built it in a week and said “that’s it, I have other things to do.” So no, SaaS is not dead.

Orel: Exactly. I invested the last year and a half into learning Substack, knowing what works, what doesn’t, what any creator needs, and I’m still improving and iterating. People come to me and say “I can build a scheduler for myself now,” and I say okay, you can. How long will it take you? Then I ask a few technical questions. How would you import notes? How would you create a bunch of them and schedule them? And that’s just the scheduler, not all the other features WriteStack has. You can build something very simple, but to make it really good and not waste your time, you need to spend a lot of time.

Nune: Plus, after you build it for yourself, the second stage for any product is making it work for thousands of users, which is a whole other story, and I think you’re dealing with that now.

Orel: Yeah. I don’t think AI can replicate WriteStack as it is, because I have around ten different projects that each do something else. One gets the data, one reminds users about certain things, and there’s a lot of infrastructure in AWS and Google. It’s a lot of things beyond just having code that runs.

Just having an app doesn’t mean you’ll have users.

Choosing what to stick with

Nune: You mentioned those 599 days of no income. Before WriteStack you tried other things, and I’ve read that you said what made WriteStack a success is that you stuck with that one thing. People often hear “stick with it and you’ll succeed.” But the problem most of the time isn’t the patience to stick with it, it’s choosing what to stick with. There’s a lot of unknown. You don’t know if it will work, and it’s hard to believe the promise that if you do this long enough, one day it will pay off. So how do you know the thing you’re doing is worth sticking with?

Orel: Now I know. Now it’s easy to say. But back then I had no idea what was going to work, and I’ll let you in on a secret: I thought every single one of my ideas was a killer, the one I was going to break through with. There were a lot of unknowns. I had a lot of times when I felt miserable and depressed and didn’t know if I’d ever make enough money to live off of. It’s hard. It’s definitely hard.

The way I kept myself going is that I read books, a lot of books, and every book about entrepreneurship and self-growth says it takes time. People say 98% never make it, that 50% of businesses close, whatever. It doesn’t mean you can’t do it. And even if you fail, that’s 100% okay, because then you learn from it and move on to the next idea, and you keep learning until you get something working. And even then nobody promises anything. It’s up to you to keep trying, because eventually you’ll get the opportunity to succeed.

Nune: I like a quote from a science fiction book that says there is no such thing as luck, there is only adequate or inadequate preparation to cope with a statistical universe. If you’re prepared enough, you’ll get a lot of chances in your life, and if you’re prepared to take the chance and try something, eventually one of them works out. But to get practical: with all of those ideas you thought were genius and that didn’t work out, when was the point you said “this isn’t working, I should switch focus”? Can you draw a pattern, or was every one unique?

Orel: Before WriteStack, every idea I had I gave maybe a week or two or three at most, and if I didn’t see any traction I dropped it. That was my number one mistake. I didn’t stick to one product long enough to even start marketing it, talking to people about it, getting feedback, and improving it. What I believed from what I read online was that you need to ship fast and kill even faster, get as many products out there as you can and see what works. That can work for a big creator, because when you have a lot of followers you can put out an idea and see how people react really fast. When you don’t have an audience, you can never know until you try and ask people manually, one by one, “hey, can you try this and tell me what you think?”

And about luck being preparation, I think it was Robin Sharma who said luck is preparation meeting opportunity. That’s exactly what happened to me. I used to spend a lot of time on Substack. I started on YouTube, moved to LinkedIn, then Twitter, then Substack. I was trying to be consistent on X and not really managing. But one day I opened the app and saw a tweet from Thibaut, the founder of Taplio, Tweet Hunter, SuperX, Revid, and a lot of other products. He was looking for a co-founder to build a Tweet Hunter competitor. Tweet Hunter is essentially WriteStack for Twitter. His previous co-founder hadn’t worked out, so he was looking for a new one, and I thought this could be a great opportunity to get myself out there, get people to know me, build something and make money.

So I sent him a message, then another one, then a video, then another video, until he replied. We started talking and he gave me about two weeks to add a feature to one of his apps. He had that Tweet Hunter competitor, SuperX, already built, but not the way he wanted it. He gave me the code and the data and asked me to add a feature. I had to learn so many new technologies I didn’t know back then, and I did it and learned them and sent him the code. Eventually I didn’t get to work with him. But doing that and learning those technologies made me realize it could all transfer into Substack. Everything I learned from SuperX I could transfer over. That opportunity is what got me into building WriteStack.

Nune: So if you hadn’t taken that step that some people would call a failure, it wouldn’t have brought you to the idea, and it wouldn’t have given you enough knowledge to start it. Once you decide to give yourself time for experimentation, you also have to give yourself time to fail, because it’s not a failure, it’s a learning cycle. And if you grab enough of those opportunities, one of them works out.

Orel: Exactly. And you need to take those opportunities.

Even if you fail, that’s 100% okay, because then you learn from it and move on to the next idea.

The cold start problem

Nune: What I also liked is what you said about followers. When you have a lot of them, it’s easier to experiment with short-lived ideas, even short-lived content. You can drop thoughts that contradict each other just to check the market’s feedback. But there’s the cold start problem: if you don’t have a lot of followers, what do you do? I think you partially answered it, you really spend time with every individual user and ask them for feedback. Right?

Orel: Right, that’s what I did in the beginning. I sent thousands of direct messages. I got on probably hundreds of calls trying to get people to use it. I’d give it to them for free, just use it and tell me what you think. Once people started using it more, around April 6th, I got my first payment, then another one, then more users. Then I’d ask again in the direct messages: I’ll give you a month for free if you jump on a call with me, sign up, and show me what you do. And I learned from that.

Today I use PostHog, which records the sessions of people who use WriteStack and summarizes them, and I learn from that and create papers with things I need to do to improve. I have a support chat in WriteStack that I reply to personally, and I learn from everything. I summarize all the conversations I’ve had, send it to Claude, and it gives me things to improve. It’s just the manual work at this stage.

Nune: It’s a lot of manual work, but I think the whole point is the manual work, because that’s the only way you actually learn from the feedback process.

It’s just the manual work at this stage.

The tools that help, and the ones that hurt

Nune: A lot of people would want to hear which concrete AI tools you use and how they help you, and maybe if there’s something where you’d say AI is making it worse.

Orel: AI definitely helps with a lot of things, though I don’t use that many of them. I’m a bit behind in the AI game. I use Cursor for coding and Claude for daily use, talking to it, thinking about ideas, consulting with it, brainstorming, creating content. I also use Revid, another product from Thibaut, to create the reel videos I make every day.

Generally AI helps me a lot, but it also sometimes makes me very unproductive. I catch myself thinking, “okay, I can complete that really fast with AI, so I can procrastinate and do it in thirty minutes,” and then I find myself doing other things instead of working, because I know I can finish it quickly. If you look at the big picture, it’s saved me weeks or months of work. But in the day to day it sometimes makes you less productive and more prone to procrastinate.

Nune: I just yesterday published a small article about how these AI chats are like social media. You get into a conversation and it’s one more turn, one more question, and it even offers you questions, so you get dug into the hole. It’s like scrolling an endless reel, but on a specific topic. You have to get yourself out of that conversation and actually go do something.

In the day to day it sometimes makes you less productive and more prone to procrastinate.

Will AI take your job?

Nune: You took the leap, you quit your job. A lot of people right now are anxious about AI taking over their job. Do you see AI taking over software engineering positions? And as someone who decided to leave the nine to five, do you think anyone can do that, or does it take a special kind of character?

Orel: I don’t think AI is taking over any sector in software development soon, because it requires a lot more than coding. You need to understand so many things beyond it, especially for bigger products. AI cuts development time by a lot, so software developers who aren’t good enough will probably be laid off. But if you’re really good at what you’re doing, you’ll find a way to be better with AI, and then there’s no reason to fire you unless a company closes an entire branch.

From my experience there aren’t a lot of good software developers. Most people just come in, put in the hours, and go home. They don’t care about anything besides their paycheck. That’s the reality. If you tell somebody “I need you this weekend to work on something important,” they’ll never do it. And that’s fine, it’s their decision. But if you want to be better than everybody else, you need to do the things that nobody wants to do.

Nune: True, you need to put in the extra effort. We just had an episode recorded yesterday where we discussed that a software engineer’s job is so much more than coding. It’s knowing the domain, being able to communicate with your peers, with customers, with clients.

Orel: Right, it’s being able to connect the dots, to understand one thing in one area and apply it in another, and to think in a broader way. And actually wanting to be better and improve as a software developer, not just clocking in for the money.

Nune: Meta thinking.

If you want to be better than everybody else, you need to do the things that nobody wants to do.

Pick one thing and give it six months

Nune: We talked about what AI changed and what it didn’t, that you still need to focus and iterate. Anything else you’d advise someone who has an idea and is unsure whether to try it, unsure whether anybody would use it?

Orel: This is my number one advice, honestly: give yourself a few months to focus on that one thing. You’ll build it in a few days, you’ll have the first MVP ready, and then you’ll need to get people to use it. When you’ve set aside a lot of time for that product, after you’re done building it you start thinking, okay, what do I do next, how do I improve?

What I did personally was take five books I really love about marketing and tell myself I was going to read them on repeat until I made my first dollar. It took me four months, rereading them time and again. Three books by Russell Brunson and two by Alex Hormozi. In that dead time after I finished building the first MVP, my brain started looking for things to do, and as I read I got points I started implementing. Whereas if I’d read them before, I wouldn’t have tried to implement them, because it wasn’t the right time for me to get that knowledge. When you’re in the state of mind of doing something and you read something related to it, it’s much more effective than just reading about it and later trying to recall it.

Nune: That’s very true. When you read those books they make you think in a certain way, but reading them while you’re doing things, it clicks in a whole different way. A lot of those books are written by people who actually tried it and wrote it during that trying period, and that’s why they click in the process itself.

Orel: Right. You’re doing it, and suddenly the writer says “and then you’ll hit this point and you’ll need to do this,” and you think, he’s right, let’s try this.

Nune: I really liked a quote by Christina Koch, one of the crew members who flew around the moon in the last flight. She said, “find what you can do the slowest for the longest and still absolutely love it, and go in that direction.” Sticking to one thing and doing it slowly, every day, is what you need to find. Not something that excites you right now and then is gone, but something you can stick with.

Orel: In my opinion it’s less about the thing and more about the goal you want. I had dozens, maybe hundreds of points where I felt I’d had enough, that it sucked and I really wanted to stop. What kept me going was being stubborn and knowing that if I pushed through, I’d be better than anybody else. I’m like a kid in that sense. I want to do the opposite of what people think. So I knew that if I kept pushing, eventually I’d get to my point, and I needed to do better where most people break.

For example, I used to go to a spin class with a lot of people. When everyone was at the hardest point, when I saw people around me suffering and barely pedaling, that’s when I felt I needed to be better. I can’t let it break me where it breaks others. That mindset honestly came from reading David Goggins three times and listening to his audiobook. It really inspired me to be better when others are struggling.

I can’t let it break me where it breaks others.

Books, learning, and the major he’d choose again

Nune: To go the extra mile. You’ve already mentioned a lot of books, and I’m a big bookworm too. Do you have more recommendations?

Orel: For sure. I don’t have my phone, but I have an app a friend built five or six years ago that we still use, with all my books and favorites. The latest one I read is The Obstacle Is the Way by Ryan Holiday. I absolutely loved it. Storyworthy, also about storytelling, is very interesting, crazy good if you’re into storytelling even a little bit. The Wealth Money Can’t Buy by Robin Sharma is great. I have 235 books I’ve read in there. And another book that made me take the step and quit my job is The Millionaire Fastlane by M.J. DeMarco. That’s the one that differentiated between me working the nine to five and me quitting.

Nune: You’ll send me the list and I’ll post it. I’m happy there are still people around who learn from books. From what I’m hearing, maybe you can write a book someday. What do you think?

Orel: Not in the near future. I’m struggling to write an article every week.

Nune: What I also like, and want to tell the audience, is that you’re documenting your journey. You have the newsletter, Indiepreneur, where you write these things down, which will hopefully help someone avoid some mistakes or be more courageous where they’re worried. There’s a tradition that every guest leaves a question for the next one. In the previous episode, Ia asked: if you had to start your career or learning journey and pick your major right now, would it be different from what you had, and if so, what and why? What’s your take on learning computer science now in the age of AI? Is it still valid, and would you do it, or take something else?

Orel: To answer her question, I wouldn’t change my major. I have a software development degree, a bachelor of engineering. I wouldn’t change it, because even though you can do stuff with AI, AI is not taking the entire sector, not anytime soon. So many people predicted it. Jensen Huang, the CEO of Nvidia, said AI is going to take over software development jobs. And the CEO of Anthropic recently said he was wrong about it and it won’t actually happen. So I wouldn’t change my major. I’d do exactly what I did.

Nune: A lot of them are taking it back. Sam Altman took back his words, Dario Amodei from Anthropic took back a lot of what he said about replacing engineers. Whether that’s political, economical, or reality is a bigger question. But a lot of people who are hands on in IT all say the same thing: there’s no replacing, it’s still the same job with a different tool set.

Orel: And it’s interesting that the media makes it look so much worse than it is. Take Wix, for example, laying off thousands of software developers and employees. That’s because the competition is so strong that they’re losing ground, so it doesn’t make sense for them to hold as many developers as before. AI had its impact too, but it’s not only AI, and people make it look like AI is completely killing the market. Companies like Meta, Microsoft, and Amazon that are laying people off all hired so many software developers during COVID. Back then, finding a software developer job was as easy as finding a job at a supermarket. They overhired, they overstaffed, and now they’re reducing staff. Obviously AI had its impact, but there are a lot more things behind their decisions.

Nune: It’s easy to blame AI and say it’s all AI.

Orel: Exactly. And that’s what people want to read. It makes them feel something, so they want to consume more of that content and see that AI is killing the industry.

Nune: What would be your question to the next guest?

Orel: My question to the next guest would be: what is the one thing you would tell yourself at the beginning of your journey that you know now but didn’t know then?

Nune: What would be your answer in your case?

Orel: Pick one idea, focus on it, and give it at least six months. Especially when I first started, when there was no AI to write for you.

Nune: Stick with it.

References

Quotes mentioned in this episode

“There is no such thing as luck. There is only adequate or inadequate preparation to cope with a statistical universe.” — Robert A. Heinlein, Have Space Suit—Will Travel

“Find what you can do the slowest, for the longest, and still absolutely love it, and go in that direction.” — Christina Koch

Orel also reached for Robin Sharma’s version: “luck is preparation meeting opportunity.”

Tools and products mentioned. This is not a commercial, but if any of those want to become a sponsor for my show, get in touch with me 😀

• PostHog (not a sponsorship, just what Orel shared he uses. But if you are PostHog and want commercial, get in touch with me :D )

• Revid (same)

• Cursor (what Orel uses for coding)

• Claude (daily brainstorming, and the Claude Code Opus 4.7 app-building experiment that didn’t go to plan)

• Thibaut’s stack that shows up in Orel’s origin story: Taplio, Tweet Hunter, and SuperX

Books mentioned

• Russell Brunson’s books

• Alex Hormozi’s books

• David Goggins

• The Obstacle Is the Way by Ryan Holiday

• Storyworthy

• The Wealth Money Can’t Buy by Robin Sharma

• The Millionaire Fastlane by M.J. DeMarco (the one Orel credits with making him quit his job)

My article that came up: “AI isn’t a tool, it’s social media”

Chapters and Topics

00:00 Introduction to Root Cause and Solo Building

04:57 The Journey of Building WriteStack

06:42 What is SubStack and WriteStack?

09:28 "Why Bother" if the platform / big players will replace you

13:14 "Why bother" if AI will replace all SaaS

14:46 Knowing WHAT to Build and How to Distribute

18:30 Finding the Right Idea to Stick With

23:22 Learning from Opportunities and Failures

26:10 Navigating the Cold Start Problem

28:10 Leveraging AI Tools for Productivity

30:49 The Future of Software Engineering in the Age of AI

33:53 Advice for Aspiring Entrepreneurs

37:20 Being Better Than Most

38:49 Book Recommendations and Lifelong Learning

41:04 Reflections on Education and Career Choices

Find Orel at:

• His product - https://www.writestack.io/ 

• His journey - https://theindiepreneur.substack.com/ 

• Substack notes analysis - https://thewritingedge.substack.com/

• Substack profile - https://substack.com/@orelzilberman

Find me (Nune) at:

• LinkedIn: https://www.linkedin.com/in/nisabek/

• Substack: https://www.thoughtfultechnologist.com/

Below you’ll find the text version of this episode, for those, who prefer reading :)

Guest: Ia Mg — Seasoned Engineer, former computer science and technology teacher, and writer of the blog Bits Complicated

Why everyone should understand technology

Nune: You taught coding to non-developers at the Free University of Tbilisi. Did you have to reframe the way you think about programming concepts in order to teach them to non-coders?

Ia: That’s an interesting thing to reflect on. I started out at a computer science faculty, so there are already so many new things you get confronted with when you start teaching. The course I taught was introduced as a mandatory course for technology and design, and part of why I got involved is that they already knew I like to yap about technology — I always come in with “anyone can understand it, and it’s so beautiful.”

The thing I had to confront the most was adjusting how much I could expect as an outcome. I had to scale down a bit on the speed of the course. But I also found how much better the outcome was — how much better the materials were understood.

Nune: You said you can yap about programming all the time and how cool it is. Do you think everybody should learn programming — and can everybody learn it?

Ia: Yes and yes — but not because everyone needs to know programming. A few things happen during this process. First and foremost, not everyone needs to know how to code, but I strongly believe everyone should understand technology — even has a responsibility to understand it, whether it’s relevant to their field or just to society. Because of how the education system is set up, many people are shy and reserved about developing their tech skills. They feel like being tech-friendly is something innate, something you’re either drawn to or not — and so they deprive themselves of developing digital literacy and gaining a lot more power in whatever they’re doing. Even if we don’t use it for our career, we use technology every single hour. It’s a fundamental human responsibility to understand the thing that’s so intertwined with our life.

Nune: People might not realize they’re using technology every day — the Instagram algorithm is responsible for what they see and how they interact with everything around them. That’s what you mean by literacy?

Ia: Exactly. And the legislation, too. There’s basically no legislation now that isn’t related to technology, because it’s so involved — citizens have a responsibility to understand what laws are being passed, and so do the politicians. So tech literacy is something everyone really needs.

The second thing that happens during this process gets mentioned a lot: you should learn programming because it develops your problem-solving skills. That’s true, but there’s nothing special about developing problem-solving skills — there are lots of things you can do that develop them, and no one goes about their day not solving problems. What’s different about coding is that it’s a much more rapid feedback cycle. You’re confronted with exactly how you think, very quickly, and you can’t blame the mistake on anyone else.

Nune: No external circumstances.

Ia: Your code crashes — it’s you. There’s no one else who could have done this. You’re very confronted about your shortcomings in problem-solving, and you do it very, very quickly. There are very few other environments that let you test your reasoning that fast. It’s also very accessible — you don’t even need to download anything anymore. You can go to a website and start developing the skill immediately.

Nune: I had a doctor in my team who practiced medicine and then switched to programming. You’re right — he already had problem-solving skills, because he’d had to use them as a doctor. The only difference was that I sometimes assumed certain concepts were known to him from a math or computer science background, and they weren’t. But because of that, he developed a different set of abstractions and mental models. He went on to teach Python to other non-programmers, and they found a common language. So you’re not talking just about functions and modules — you’re talking about the way of thinking, and how programming can make you aware of how you think.

Ia: Exactly. My classes are famous for writing very little code. It’ll be 35 minutes in, we’ve discussed so many things, approached the problem, the description — and the students are like, “When are we going to write code?” And I’m like, this is not about code, guys.

This is not about code, guys.

“Everyone can be a programmer” — and why domain knowledge wins

Nune: There’s a sentiment going around because everyone’s talking about AI: that nowadays everyone can be a programmer — you just take AI. And further, that you don’t even need to be a programmer to program; you need to be a domain expert. Once you’re good at a specific field, you take AI and voilà, you have a product tailored to that industry. What do you think about that?

Ia: I understand the negative sentiment around “everyone can be a programmer.” For me, it’s a positive statement — and one we’ve been hearing for a long time. When I started out, it was “now everyone can learn programming because the modern languages are so easy.” Then “everyone can build a web server because we have so many frameworks.” Then “everyone can be a cloud engineer because Docker made it easier.” I don’t know why people get angry that things become easier to do. Of course, some difficulty is lost, and some skill and responsibility goes with it.

But you mentioned something important: the domain-knowledge part. I’m convinced programmers were not doing well on that. When they’d come onto a project, they didn’t understand how important domain knowledge is, separate from programming. And the domain knowledge is what determines whether what you create will be valuable. You might build a great system — but what’s the purpose of it? Because I had this weird set of domains, I learned this directly. I started at a sound research institute and had to take music classes just so I could be productive in meetings and understand the words being used. Then at Exscientia I had to learn how a microscope works, how imaging works, how fluorescent markers work. I can do a lot of things, but that doesn’t matter if I’m not doing the things you actually need.

I think programmers get a false confidence that they’re very skilled and valuable and know something most people can’t do — and then they underestimate how important domain knowledge is. This whole situation is a direct demonstration that sometimes domain knowledge matters more than specific programming skills. I’m all for it. I know people are angry, but for me it’s “bring it on” — I think this was long overdue.

The domain knowledge is what determines whether what you create will be valuable.

Nune: The democratization of programming has been going for a while, and it’s not the problem. The problem is understating how difficult it still is — it’s not just about taking the tool and asking it to write what you want. The way you had to learn music concepts, I think anyone with good domain knowledge who wants to program in that domain also has to learn some basic programming concepts.

Ia: That’s fair. For me, the products created with AI are valuable not because of their code, but because of the prototyping and proof-of-concept action. I don’t think the product should immediately be built upon. But now a lot of people who never had a chance to demonstrate that something they wanted to do would be valuable — they get that chance.

Within programming, “anyone can be a programmer” is more of a problem inside the domain, because seniority in software engineering was always about having more skills than just coding — the hard skills of engineering, design, architecture decisions, diagramming, documentation, and also the social parts. What I don’t like is that with AI, anyone can produce a very good-looking document, a very good-looking diagram, a lot of documentation. I’m not sure what the impact of that is. It’s disorienting, because now everyone kind of sounds senior. I’m interested to see where that goes.

Nune: Maybe now is the time the industry figures out what it actually takes to be senior — not just to sound like it. Like being able to work and decide things in an atmosphere of uncertainty, because business never has exact answers. The more senior you are, the easier it is to navigate uncertainty, and you can only learn that by having seen more situations and thought them through yourself. If AI thought instead of you, you probably didn’t build the connections in your head that help you navigate the next situation.

Ia: Yeah — and being stuck for a bit. Spending some time in the stuck situation.

Nune: Suffering is part of being senior. Setting aside whether AI can write programs — as someone who has taught programming, do you think AI is a good teacher of programming?

Can a machine teach?

Ia: Teaching is very tied to storytelling, and it’s very personal. My own teaching core: I didn’t start out in computer science. I was studying business and marketing, and I thought, “If I want to create something, I’ll have to rely on developers — and what if I can’t find them?” So I started learning to code with the idea I’d build some website. Then I fell in love and made the very scary switch to computer science, and fell in love even more. Every time I teach, I’ve never lost that gratitude for giving that opportunity to myself — how beautiful it was to understand concepts I thought I’d never be capable of understanding. That part is very hard to replace. Teaching is very person-specific, very human.

I don’t think the teacher can be replaced — but even before AI, I was confident that students should get more help from technology. I really liked Khan Academy; I even volunteered to translate it, and worked at a nonprofit translating it and supporting them on social media before I switched to computer science. I liked the mix: the student gets to independently watch the videos, pause, rewatch, then do exercises tailored to them. Because that’s not the main value of the teacher. The main value of the teacher is to control the process, to understand the pupils — and teachers also have a responsibility to be good.

I volunteer now at Stanford’s program Code in Place, because I missed the framework — I worked at a university in Vienna some time ago and don’t have that chance anymore, so I volunteer whenever I can. I was surprised that after every section you hold with students, you get AI feedback. Before the section, you get feedback on what the students have done in the exercises — what they struggle with most, what they understand well. That’s very helpful, because I go in knowing exactly what’s missing, what to cover in the first few minutes, and where to tell them, “It’s okay if you don’t understand this.” After the section I get statistics on how long I was talking versus how long the students were talking. As a teacher you should get feedback — I shouldn’t have to remember the whole class to target the areas that will have the most impact.

The main value of the teacher is to control the process, to understand the students.

Nune: So it’s a good tool, and it should be used as a tool — but there will always be aspects that are human and can’t be replaced. I really like your attitude: “If I don’t know something, I’ll learn it and then apply it.” A lot of the DevOps movement was developers who cared about infrastructure and operations — they didn’t only want to write code, they wanted to understand how it would be deployed and run in production. What you’re saying about product work and understanding the domain is another step: it’s not only about programming something well for production, it’s about programming something the end users actually need. So of course I need to understand the business domain too. And if a non-programmer can say “I don’t understand programming concepts, I should learn them,” then it should go the other way around — if a programmer joins a domain they don’t know, it’s fair to say they need to learn that part themselves.

Ia: Right — having the ability to code or engineer is not the most valuable skill on the team. It was positioned as such because it had a very long barrier to entry — others couldn’t even participate in the discussion. It was gate-kept. I think AI is having the most impact at the borders of the discipline: how much input you can get. Now a product manager can code up a prototype proving what they’re aiming for is possible, or good, or valuable. That might be annoying to receive as the person who said “no, this won’t work” — but ultimately it’s for the better.

Nune: At least it’s a better way to communicate your ideas.

The trouble with trusting what AI tells you

Nune: One thing that bothers me about learning anything with AI is that I can’t always evaluate whether the answer was correct — unless I know it upfront, at least approximately. If I know programming and I ask AI to evaluate paths A, B, and C with pros and cons, I can validate the result against my own mental model. But if I switch to a domain I don’t know and ask for some paths, I have no idea whether they’re right. People argue you can ask follow-up questions — say I ask about chemistry, don’t understand the answer, and say “break it down simpler and simpler until I get to high-school terminology.” The problem is that with every response there’s more uncertainty in me that some part was hallucinated or outdated. So my uncertainty in the answer grows with every turn. Translating that to people learning programming with AI — how can they do it without knowing it upfront?

Ia: When you ask AI about things you do know, you see how biased the responses are and how much nuance they miss — even nuance that’s relevant for beginners. Sometimes it frames things that should never be framed: if you ask the wrong question, you receive an answer, instead of being told “that’s the wrong question to ask.” And as the conversation goes on, you bring in more non-knowledge about the domain, and the answers depend on what you ask and what you follow up on. It’s the answer that was created by you. Ultimately, the answers you create, you create based on your input — so you don’t have an independent evaluation of anything.

What I like AI for is “Hey, what is this thing called?” — so I can go and search for it. Because before, there were certain terminologies you couldn’t Google your way into. But for a high-level explanation of a topic I’m unfamiliar with, I’d trust a human, or at least accept that what I’m getting might be completely wrong.

Ultimately, the answers you create, you create based on your input — so you don’t have an independent evaluation of anything.

Nune: That’s a good point. The other day I couldn’t remember the name of a movie — sometimes it’s a book — and I asked AI with a high-level description of what I remembered of the plot, and it came back with the answer. That’s where AI is helpful. If you don’t know what something is called, you can’t Google it, so the use case you mentioned is a really valid one.

Ia: And then you Google it and you get the AI response now anyway. I use Ecosia and others — they have an AI response too, but at least it’s less pushed.

Nune: There’s probably a way to disable that, like an ad blocker for AI answers. But so much content is now AI-generated that it’s getting harder and harder to differentiate.

Are we raising a worse generation?

Nune: Which brings me to: are you worried about the next generation? There was a report — don’t quote me on this — that this is the first generation with lower IQ test results. I don’t think IQ tests are a good measure of human knowledge, but there’s obviously a shift. Are you worried, or do you think they’ll find their way?

Ia: That study was one of those times when I was like, “Okay, what are the sources? Who decided that? How did they measure?” For me, that kind of shift is more representative of the social, political, and economic situation the world is in than of AI or short-form content specifically — though we know short-form is harmful, and the outcomes we’re seeing are in line with that. But ultimately it’s the next generation’s problem. We can’t understand it, we can’t solve it. We can only create a world where they feel empowered to face it.

Sometimes on the weekends I go to the library to remove myself from distractions — get a coffee — and I see students still sitting with books, or studying with their laptops open. When I did exercises, I also had the solutions at the back of the book. I just wasn’t looking, because I understood: I’m learning, I’m practicing. I wasn’t interested in the answer, I was interested in development. So I think they’ll be fine. The new generation of programmers will be fine. It’s just not the same fine that we think is fine.

I wasn’t interested in the answer. I was interested in development.

Nune: The endorphins you get when you finally understand something yourself are so powerful that they’ll drive people to keep learning, instead of just taking ready-made answers.

Ia: Exactly. Even with this AI coding craze, people are very excited — but they’re also very aggressively burning themselves out. It’s not sustainable to spend 18 hours a day building things and arguing with a chatbot. At some point people will say, “This is exhausting, this isn’t rewarding,” and go back to wanting a more sustainable way to build.

Just another abstraction?

Nune: You mentioned the recurring sentiment that programming keeps getting “easy” — because of higher-order languages, then frameworks. Now people say AI, or LLMs, are just another level of abstraction: we had assembler, then higher-order languages, and now LLMs — so what’s the big fuss? Do you agree with that analogy?

Ia: I don’t see it yet. It is an abstraction, but even if it becomes another layer, this is not how it will look. It’s hard for me to engage with the argument, because my gut feeling is that the output isn’t equivalent to what the other abstraction layers output — though maybe that can be solved. So my take is: I don’t like the statement, but I can’t fully elaborate.

Nune: A lot of people say the difference is determinism — with higher-order languages, your expectations of what the program will do match reality. But maybe that can be pushed back with enough tests, to make the LLM’s output reliable. Although you had an article about how LLMs aren’t that good at writing tests — they over-mock — and how people need to learn about this. What did you call it? The testing pyramid?

Ia: The testing pyramid, yes. I’m a test-driven-development, best-practices person — I have very strong opinions about tests. And we simply don’t have enough good tests to train AIs on. A lot of tests are over-engineered at the wrong abstraction level, testing wrongly designed units — and that’s what’s been fed to AI, so the AI generates exactly that. For smaller things, I usually get my units straight before handing over to the AI, and then I can say, “This is too many mocks.” But who is responsible for defining the tests, or making sure they’re implemented correctly? There are a lot of green checkmarks you can get. Everyone sees that AI says, “Yeah, complete.” It is not complete. Something’s been deleted in the process; what you asked for is the opposite of what’s implemented. Because of that, I don’t have confidence yet in the output.

Nune: Here are 1,400 tests and they’re all green — but the value of it isn’t high.

Here are 1,400 tests and they’re all green — but the value of it isn’t high.

Nune: Something I keep going back and forth on, even in a single day, is conversation-based development. At first I was very much against it — how can you develop something through a conversation that’s so unreliable and unpredictable? If I have that conversation it gives one result; if you have it, another. But then sometimes I think it’s wonderful that I can adjust things while I talk, and new things come out of the conversation. So what do you think about coding through chat, versus building a pipeline that creates code?

Ia: I can’t wait for the next way we’ll do this. I’m fine with chats, but right now it’s just chat. For me it looks a bit different: there’s chat, then something gets determined, then something else happens. We know that as the chat goes on, performance degrades. My approach now: if I have to correct too many things, I don’t move forward. For me that’s a failure — not an outcome failure, a process failure. Something in my setup, my prompt, or my skills isn’t working the way I want, so I go and adjust that instead of chatting along. I try to keep the chats short, because if you don’t have a reliable process and you have to interfere all the time, it’s not a good process.

Nune: You’re so right. I wrote an article about getting myself out of the conversation — controlling every step instead: spec generation, then spec to plan, then plan to code. Even though it sometimes doesn’t feel as productive as the conversation, it’s a workflow that’s controllable and improvable, because you have artifacts at the end of each step to iterate on. If you don’t get the answer right, that’s your chance to improve your process — not just to get the end result. It’s all about patience.

Ia: When I discovered that, it was one of the first times I warmed up to using AI in development, because then I could say, “Okay, this is the hard part — if that happens, I have to stop, start over, and improve.” Because in the chat you don’t start over, you don’t improve — you just keep asking it to make no mistake. When I saw there was something I could engineer about that, it was one of the first things that hyped me up. Before, I was like, “Yeah, I can create things, but what do I actually do in that process? Just type things out?”

In the chat you don’t start over, you don’t improve — you just keep asking it to make no mistake.

Tech debt is a tax — and so is learning debt

Nune: Every conversation turn adds to the tech debt. I know you wrote about tech debt, that you don’t like the term, and that we should call it a tax. Can you say a bit about why?

Ia: AI does generate a lot of tech debt — I call it legacy as a service. Have you ever wanted legacy right away that no one understands? I’m not saying that’s not how we’ll code; we’ll just accept it and work around it. But in general, tech debt is sometimes discussed as something separate that exists because someone didn’t do a good job and needs its own time allocated to be fixed. I don’t think tech debt should be looked at as a failure. It’s part of the process — just the passage of time and changing requirements.

Even though it’s important to tackle, I usually don’t push for standalone initiatives to address tech debt, because how do you know the time you’re putting in is worth it? That’s why, if you look at it as a fee, you can tie the fee into tasks. If there’s a module everyone forgets how to work with because it’s complicated, and you have a task where you spend three days just orienting yourself around it again, now it makes sense to address the tech debt a bit — maybe an extra day or two — because you’ll save time on the next iteration. But you can’t just say, “Now I’ll spend some time getting rid of tech debt.” You don’t get rid of it. It’s just a fee.

Have you ever wanted legacy right away that no one understands?

Nune: I hated those sprints that were “let’s just address tech debt this sprint,” because, as you said, every ticket is about bringing business value. It takes a lot of awareness on both the business and engineering sides to say, “This is a business ticket, it sounds easy, but underneath there’s a module nobody wants to touch — so let’s estimate it an eight instead of a five.” Do they still estimate things in Fibonacci numbers, or am I behind?

Ia: I remember a very funny conversation — a planning meeting or retro. The engineers said, “We can’t go on like this if we don’t allocate time to address tech debt.” And the product manager said, “Are you not doing that already? Is that not included in the estimation? Why do I have to think about your tech debt?” Which is very true.

Nune: As long as it has an explanation. The engineer shouldn’t underestimate the intellect of business people — if you explain the tech debt and why you need the time, they’ll understand. They’re not your enemies. We’re all in the same boat, driving toward one goal.

Ia: Many won’t even need much explanation, because a lot of product managers have that trust in the process — “the engineer knows how much tech debt needs addressing.” That puts the responsibility on us not to overuse those resources. So there has to be a better way to assess and address these topics.

Nune: Besides tech debt, there’s something I call learning debt that’s emerging. Every time you want a ready-made answer, you ask AI and you’re satisfied with it — instead of double, triple, quadruple-checking it, and by checking it, developing the mental connections that help you next time. Do you feel this way too, and how do you address it?

Ia: There are so many different ways to use AI. You can use it for something you already know; you can use it to help learn something you’re learning; and you can use it to not learn something and just get the productivity. For me it’s enough to be clear about which act I’m engaging in. It can be very useful for giving you basic vocabulary in a topic, to get common ground without putting in weeks. But if I want to learn something — I never get the illusion that I learned it just because AI explained it and I understood. As long as you keep that clear, you get all the benefits without the false sense.

When I’m learning a new framework or language, I write the code myself. I don’t even set up the second monitor — I explicitly look at what’s written, go back to mine, and try to write it out, because I’m developing a specific skill. If I ask AI to write it, I won’t have the understanding of why everything is there.

I never get the illusion that I learned something just because AI explained it and I understood.

Nune: It’s still about being aware. As long as you know you’re engaging in the act of getting a ready-made answer and not learning — fine. But don’t mindlessly use tools.

Ia: Plus, because these answers come so quickly now, the brain gets rewarded for asking an interesting question and getting an interesting answer — and then it generates more useless questions. Things you’d never have spent time exploring, that you’d have moved on without knowing — now it’s “and what about this? and what about that?” So now I sometimes restrict that time: “Today I’ll have that much.”

Nune: Compare talking with AI to social media — one more reel, one more interaction. It’s the same very quick satisfaction.

Ia: Curiosity is so widely understood as positive that you don’t think you need to control it.

Nune: Same with what used to be called feature creep — creating too many features. Now with AI it’s tripled, because the AI itself says, “Why don’t you also implement this and that, it’ll only take a day” — when in fact it won’t; it’ll bring you more bugs and more integration work. So you have to control even your feature-building now, to not go wild.

Ia: A lot of people are raising that. I look forward to this push of “we can do more features” leading to a wave of minimalism — I’m just sitting back and waiting for it. There’s no reason to resist the cycle. We’re getting so many learnings we’ll apply later, even if what’s happening now doesn’t look elegant. It’s a necessary step — but I hope it’ll be understood that it wasn’t more features that were missing from technology.

Embracing the chaos

Nune: You’re the third guest on this podcast to say “embrace the chaos instead of fighting it” — embrace the hype. You can’t stop it, you can only watch and learn from it and wait for it to calm down. And because you had a reflective mind during it, you’ll be ahead of others.

Ia: Even — and especially — for the more “responsible” engineers, in air quotes, because you can perceive yourself as a responsible engineer and think everything everyone else is doing is irresponsible. But the people on the cutting edge, coming up with the most interesting uses, are insecure. You open your eyes when you hear what they’re doing — “how, why would you do that?” — but they’re the ones pushing the limits right now. So maybe it’s just not the time to be responsible. You can wait until we get enough knowledge to be responsible again.

Nune: Like children — it’s playtime now, and then we’ll learn. There’s always this question in my head: is programming a craft, or is it art? A lot of people get satisfaction from both sides. Do you think AI is taking away that joy, because we’re not writing code anymore?

Ia: Depending on what was bringing you joy, it might take it away or bring more. I heard it somewhere: if you liked the building part, it’s a bit disorienting; if you liked the creating part, this is Disneyland. So it depends which end you’re on. Even though I’m very outcome-oriented, I had a special attachment to the process, because I spent a lot of time and effort making sure I was good at it. So when this appeared, I was like, “I can click yes, then check if it’s correct” — and that didn’t sound like engineering to me.

If you liked the building part, it’s a bit disorienting. If you liked the creating part, this is Disneyland.

But as the ecosystem develops, there are a lot of different things you can engineer now. And eventually the mandatory token usage will settle to something reasonable, so you’re encouraged to be smarter about what you do. Then you’ll start seeing again that there are those who can do this better and those who can’t, because they didn’t put the time into the process. That’s what people were insecure about in the beginning: how do you prove you’re better than someone just using AI? It’s a bunch of markdown files everyone installs — “what am I supposed to be proud of?” But slowly we’ll get an ecosystem where you can be proud again of something you engineered.

Nune: There’s a bit of sunk-cost fallacy in this. I was talking with a colleague I worked with 20 years ago — fresh out of university, all we did was write unit tests and mocking frameworks. Looking back with AI now, it felt like, “Did I waste all those years?” Part of us feels we invested so much that we can’t let it go. But you’re right that even with AI, we’re getting to things that are truly difficult — and those truly difficult parts AI can’t handle are the ones that’ll give us satisfaction to solve.

Ia: And for me — if I can’t have a good enough edge based on my skills, because everyone can look like an architect now, I’ll just go study something else and do something else. I like learning, so who cares?

I’ll just go study something else. I like learning, so who cares?

Nune: As long as you know how to learn. Once in your life, once you’ve solved a particular problem — and honestly, also the problem of making money — solving it once gives you the confidence you can solve it a second and third time. As long as you have that confidence, you’ll be fine. Maybe you won’t be a millionaire, but you’ll be fine.

Ia: And the skills aren’t lost — they’ll be visible, they already are, and they’ll be even more visible. Every time I switched domains — when I switched to programming and computer science — what I brought was an appreciation for communication, because I’d spent time learning it. Initially, what gave me an edge wasn’t that I was a better coder, but that I was better at communication, or understood its value. So whatever changes in the environment, you can always add more skills and knowledge and use your interdisciplinary background as an advantage.

Nune: I got a question I think you can help me answer, as a teacher: “How can I get into cloud engineering?” I’m a bit worried, because companies hiring demand more and more. First you were good if you knew Python; then you had to know thousands of frameworks; then containers; then be an expert in at least one cloud; and now you also need to be “AI-native,” whatever that means. What do you advise people who want to become an engineer, or switch from one engineering discipline to another?

Ia: That kind of words creep was already getting bad before the current situation. I love when a job listing asks you to know multiple competing frameworks or tools — “and also know the alternative, be an expert, just for good measure.” It’s so discouraging, especially for a junior browsing these roles. The problem with these HR ads is they always get edited — things get added, not deleted. They have a template that started 10 years ago, and every time they need someone they ask “what should we add here?” Nobody says “remove this.” They just add more word soup.

Now everyone needs a good interdisciplinary competitive advantage. I don’t see how someone can prove, very quickly, that they’re a better engineer than someone else — because a quick look isn’t enough anymore. Anyone can learn the words, have projects on GitHub, buy stars. It’s hard to stand out even if you’re genuinely better. At the junior level it’s not about being the best — a junior is the company’s responsibility to take in, train, and develop. A lot of people ask me, “Should I learn programming?” For the benefits — yes. As a profession — maybe, if you know where to apply it. Before, it was “if you’re a programmer and you have domain knowledge, you have a competitive advantage.” Now people can flip it: “I have domain knowledge, and I’m using programming as a familiarity that lets me use these tools better.” In the current job market you need to be way more strategic, more targeted — understand where you want to get to, and really go beyond just the skills.

Nune: So, back to domain knowledge: unless you want to work on the frontier, building new models and frameworks — where pure programming is what you need — you’ll probably be safer if you love a specific domain and, on top of that, learn programming so you can work with that domain better.

Ia: I think that’s true.

Learning as a rebellious act

Nune: I’m a big bookworm — everyone who knows me knows that. I’ve developed a tradition for this show of asking people about books. What was the book that made you want to learn something — that gave you the spark of curiosity?

Ia: One book I read a long time ago but has been on my mind a lot recently is Asimov — both I, Robot and his short stories. There’s one especially, where he describes how we create artificial intelligence — a very short, very beautiful story, “The Last Question” — and they’re training an intelligence just by feeding it books. When I read it, I thought, “That’s so cute, such an imaginative way.” And then we created it by feeding it books.

Nune: And now we’re living in that reality.

Ia: He could already see it that long ago. What I’ve reflected on most: when I read I, Robot, my dream job was robot psychologist — I wanted to be Susan Calvin. I thought, “If I had that, it would be so good.” And then facing the truth — that maybe I don’t want to be a robot psychologist now that the technology is so readily available — was very shocking. There are so many stories we tell ourselves, and it’s always interesting to be confronted by the truth.

Nune: Is I, Robot the one that introduces the three laws of robotics? Science fiction is so important — it helps us imagine these paths. It’s very interesting to live in these days; we’re seeing things we read about from books written in the ‘50s and ‘60s now being born and applied — from one side in a very different way, from another side in the same way. I always go back to a book by Heinlein, Have Space Suit—Will Travel. Not because it has any AI in it, but because it brings back the love of learning. The main character gets a space suit and genuinely gets interested in how it’s built — he strips it down and puts it back together, and those pages always give me back the curiosity and the wanting to learn. I’m also reading one now from 1994, Permutation City, about people put into a kind of VR world, exploring generated models of consciousness versus biological ones. It’s so relevant today, because beyond AIs and LLMs, a lot of people are starting to understand it’s going to be more about how we can apply biology together with AI.

Ia: The intelligence part is interesting, because right now we choose either human intelligence, or the standard statistical machine — the more primitive machine learning — or the LLMs. Hopefully soon we’ll see an interesting combination of these, as opposed to going with one closed-box attitude.

Nune: Let’s root-cause this one last time. We talked about teaching, about learning, and about how AI can be applied in a smart versus an automatic, unconscious way. If you had to root-cause it — not the surface reason, not “people are lazy” or “the tools aren’t good enough yet” — what’s the real root cause of the risk that we collectively get worse at learning?

Ia: There are a lot of reasons to be concerned, and very dangerous implications to deskilling the population and having intelligence as a service — I don’t like where things are being pushed; it’s definitely a nightmare. But set that aside. Politically, learning is a fundamental rebellious activity — one that brings you power. You rebel against a lot of things, you gain control over something that was unreachable to you before, and you rebel against time itself. Not only because you slow down biological aging, or even reverse aging in the brain, but because you allow yourself to become vulnerable again, to be an open book, and to find the child inside. You get to be a kid again. That’s one of the most precious things you can do for yourself — almost like magic. So for me it’s very important to keep learning, to see the risks and face them and rebel against them.

Learning is a fundamental rebellious activity. You rebel against time itself.

Nune: That’s part of not aging — having this spark of learning. We have to be conscious of not letting our interactions with AI rob us of that feeling. Any practical recommendations? Like, breathe five minutes a day before talking to AI?

Ia: I have strictly no-AI days — not because I’m saying that’s necessary, but because I just don’t know yet what the best approach is. I try to be conscious of what I’m engaging with: “Now I’m using it to ask random questions; now for something I actually don’t know and don’t even want to do — I just want it done; now to assist.” I try to both limit how much I use it in one specific way, and give myself time without it, so I’m not too impacted by whatever the implications are. We don’t know yet.

Nune: Those blissful hours when your token limit is reached and you can just sit and not use it. Another tradition we have: every guest leaves a question for the next guest. The previous one was from Adrian: “What surprised you the most in the discipline you were most comfortable with?”

Ia: I’ve been thinking about this so much, and it’s so hard. It’s a tough one.

Nune: I think it’s hard to even figure out which discipline you’re most comfortable with — that part of the question is already hard.

Ia: Something a lot of people find surprising about engineering is how different it is from what it looks or sounds like. First of all, how many social skills are involved — how much humility, cooperation. The stereotype is that you get on, write a lot of code, and that’s the fun. But the fun is also in the barriers that exist in real projects, and developing the skills to confront them.

Nune: With the democratization of programming, a lot more people are starting to put into words what software engineering is — not just programming. It’s way more than code. It’s understanding your peers, understanding people from other disciplines — even having a way to limit your own computer time. Whether you were a programmer or you’re just starting with AI tools, we’re all spending more and more time in front of the computer. Yoga is what will save you.

Ia: And mindfulness practices have helped me so much to be a better engineer — sometimes you need to set your ego aside, step back, look at things. That meditative thing is very useful.

Nune: Good for your back, too — take care of your back. So, maybe try not to make the next guest think this much: what’s your question for the next guest?

Ia: If you had to start your career — your learning journey — or pick a major right now, would it be different? What would it be, and why?

Nune: Nice. That would also define what we advise the new juniors coming into the world — though we’re always biased by our past and the situation we’re in, and we can’t know the future. That’s simply the truth.

Ia: I don’t think I did you the favor of asking an easy question.

References

• Learning to Learn — blog post series

• Khan Academy

• Stanford Code in Place

• Ia’s article on the testing pyramid and why LLMs over-mock

• Automating myself out of development (spec → plan → code) — Part 2 coming soon

• Ia’s article on tech debt as a tax / “legacy as a service”

• Isaac Asimov, I, Robot and short stories, incl. “The Last Question” — I, Robot · The Last Question

• The Three Laws of Robotics

• Robert A. Heinlein, Have Space Suit—Will Travel

• Greg Egan, Permutation City (1994)

As an example, when I asked Ia whether she finds using AI “dangerous” because it might lower your own cognitive capabilities, she quite reasonably highlighted that it can be used in so many ways and you should be fine, as long as you are aware which type of activity you are engaging in.

I decided to start cataloging the ways a software engineer is, in my experience, using AI interfaces and what I personally find useful or harmful, along with some tips for usage. The list is not intended to be exhaustive, and I hope you’ll add your personal use-cases and stories of success or failure with each of them.
I am also sure that each of these “types” of usage can be improved in a certain way - through prompts, agents, infra around them, etc. - I’d love to hear your stories, to be honest, since I’m in my Claude Code bubble of my problems.

Let’s start with the soft basics:

Rubberducking 🦆

You have a problem at hand and you have a lot of thoughts about it. You need to express them, so that through the expression of those thoughts you come to some conclusion.

How did I do it before AI?
a) Harass a friend - teammates, ex-colleagues, friends, my mom - everyone got some random “hey, help me think through this”.
b) Write it out - this one’s my favorite, because humans are not always present/awake, and on paper you can navigate up and down between different parts of your arguments and thoughts.

How I do it with AI
Honestly, it would sound like talking with AI in a conversational manner would replace the harass a friend kind of interaction. And maybe the first models did this actually, but nowadays, I feel much better if I

• first write down all of what I think

• mark all of the “unknowns” in the train-of-thought I’m having

• doing the first two steps usually already brings you forward; if not - continue

• when I’ve exhausted all thoughts, but still have questions, I’d research the marked unknowns - here, fine, you can use a chat assistant to do the research for you and read through it. Remember though to actually look at the papers/articles found, and not just the final conclusion

Now here, you’ll be tempted to dump all of what you wrote into the AI and ask it to make sense of it / suggest more ideas / suggest an outcome - in my experience, this is a bad idea. It’ll generate a lot of NOISE that you don’t need at the moment, because the whole point of the exercise was to find signal, instead of generating more noise.
The research parts of your marked areas should already give you more structured information, that you yourself can process and turn into signal.

Plus, if you do that, you’ll feel afterwards lost as to which of the thoughts were YOUR thoughts and which were generated by the LLM. Which is a very uncomfortable feeling if you want to be honest with your solution.

The process is the solution here - so you kinda have to walk the problem yourself.

Applicable to both the chat interface and the Claude Code-like interface - probably Claude Code would give you more structure, more access to your internal docs, skills, etc., but still.

AI-usefulness index: 2/5

Remind me what’s going on? 🤔

I’ve actually found this a very small, but very helpful use-case. You’ve been on vacation for two weeks. You’ve been so braindead and tired that you just LEFT everything behind and went to enjoy that wonderful sea/mountain/river-side at last. You come back and... what? It used to take us some time to “get back to work”. Nowadays I ask Claude to “remind me where we were at”. It’s pretty good actually. I think the output will be good enough to at least get you back into the working mood. And in my case it can be several repos and their commits; in your case it might be all the user stories created while you were gone - but the point being, summarizing a certain amount of “data” (commits, chats, stories, specs) over a relatively short time window works pretty well 😃

AI-usefulness index: 5/5

Enrichment 📖

I’ve talked about the enrichment step in my Automating myself out of development post.
To keep it short and honest - enrichment is when you know what you want, in terms of a user story, but you are too lazy to write the details out. Works best if you have prior approved-and-implemented specs somewhere accessible for the agent (let me call it “agent” from now on, ah? LLM, chatbot, Claude Code, whatever you are using - let’s just call it agent for simplicity). It would also work if it has to go and read the code every time, but yeah, tokens, you know.
Using the agent here goes typically fine. Although it’s quite hard to evaluate it truly, because I still have the mental model of the application, so thanks to that, I automatically write even one-sentence descriptions that imply a good description and imply understanding of the codebase.
So what would probably make sense here, once you move from solo to team development, is to make this step critical. Make this step (through prompts, or skills, or whatever the next agent framework gives you) critical of the original message - make it highlight any prior implementations that the next agent (or human) should pay attention to.
Useful also to remind yourself of prior implementations, you know? Like for example, we wanted to introduce “capabilities” to our agents (they are SRE agents investigating incidents, in short), but we already had “capabilities” as a concept attached to our integrations (e.g. Grafana/GitHub/GitLab integrations). So the enrichment step would highlight that this already exists and we should at least call it something different - better yet, rethink the whole relationship.

So, summary -
AI-usefulness index: 4/5
Tip: make it critical

Spec 📝

I got roasted for saying this, at the beginning of the agentic-engineering discussions, but I’m going to state it again and I want to see some real arguments - the output that is good for an agent and the output that is good for a human are not the same. A human will be better off without code snippets in the spec, and would instead appreciate an architecture diagram; an agent, however, can “split” part of the future implementation into adding some details in the spec.

Here, what I’d pay attention to and specifically have a mechanism for dealing with (I’m not being overly detailed on the how, because the concrete output might be different for different tools / teams - but the idea should stand) is that agents, even if they have some open questions and they flag some areas that are questionable, they’d go like “I’ve flagged these, and the planner/implementation agent will need to deal with them”. Not OK. I want to see those NOW, and make decisions about them sooner rather than later.
Basically, make them (prompt, ask for structured output, etc.) be explicit about areas that are likely to cause problems or are questionable.

And back to the human-output-vs-agent-output thing - if you care about building the model of the application in your head, alongside it being developed (and I’m not being condescending here; it can be valid not to care in the context of a demo, or an I-just-want-to-be-done-with-this-now-we’ll-throw-it-out-tomorrow kind of implementation, and it might be critical in some other case) - you need to ask for an additional “human-readable” output with extras like diagrams, and no code snippets.

So now, if you have this wonderfully crafted two-type output to help YOU understand, to help YOU answer the important questions, and to help downstream agents process the feature further, you will recognize that not all tasks are made equal (what a surprise).

Here you can create one more “categorizer” that decides which tasks are big enough that they need to go through this elaborate spec creation, or whether they’re easy and can just go further, let’s say without an arch diagram.

I can hear you screaming that I’m overcomplicating things and following the herd to increase token usage. Maybe. MAYBE.
But the thing is - someone, somewhere in the development pipeline needs to do these things. Needs to enrich the story, needs to create the spec, needs to create a diagram describing the spec, needs to decide if the task is “complicated” or not. It’s up to YOU and YOUR use-case to delegate this or not. Lego bricks. Lego bricks....

I got a bit distracted; let’s go back to use-cases.

AI-usefulness index: 4/5
Tip:

• think of the result artifacts and who’s going to read them

• make sure it’s explicit in the parts where it asks a question

• keep already-implemented specs somewhere for reference/context gathering

• think about categorizing what is worth an elaborate spec and what’s worth implementing right away. Use your OWN project criteria for this.

Brainstorming🌪️

Wait, you think - you just talked about rubberducking. Well, that’s different. And I’m not trying to overcomplicate things with terminology. I’m just defining it so we have common ground. For you, brainstorming can mean one thing; for me - another.
So, I see the difference between brainstorming and rubberducking in that, for the first one, you already - maybe not completely, but somewhat - see the possible options, possible tradeoffs, and possible places where something can break, and you need to discuss those tradeoffs with someone. Rubberducking is really more uncomfortable, and there you must “walk the problem”. Brainstorming is ahead of that.

And, as long as you are not dealing with novel issues, or issues that don’t have a lot of ready-made solutions out there in the sea of solutions on the internet - you’ll be fine using LLMs and agents.

Present the problem, ask it to push back, brainstorm options. That’s fine. Don’t forget to have an artifact in the end - a result of the brainstorming. And I’m afraid you are still better off if you brainstorm it first, and THEN ask the LLM for more input if needed.

Generally, I’ll be honest. The more I do something myself and THEN go back to the LLM, the more I re-discover my initial attitude towards agentic systems - which is that they are not doing THAT good of a job... The thing is... I’ve been told so many times that I’m overdoing things. Overcomplicating things. Overthinking things. So I have come to understand that some things are OK to be done “good enough”. One can’t do everything alone, right?

The KEY is for you to understand which things are OK to be done “good enough” and which are not.
Paraphrasing the famous quote:

Grant me the serenity to let the LLM handle the “good enough,”
the courage to do the rest myself,
and the wisdom to know the difference.

AI-usefulness index: 4/5
Tip: pick your battles. Brainstorm about things you know. Avoid jumping into brainstorming about things you don’t know.

Remind me, what was X? 🕵️‍♀️

In the conversation with Ia, I mention this tiny use-case that I find absolutely useful. This is when I forget the name of a book (which happens quite often), or (more applicable to software engineering) the name of some term (I’m so good at remembering things on the concept level, but so bad at remembering the exact term for them...). So I absolutely love when I write something vague and get an answer from the LLM.

I know it’s a small use-case, but yeah, it kinda feels like magic sometimes 😄

I’d put the “cold start” use-case here too. This is when you want to learn/research/search for something and you don’t know where to start at all. You need someone to point you at what to google in the first place. AI’s good at that.

AI-usefulness index: 4.5/5 (I still can’t find a detective sci-fi story from the 90s about a woman embedding her mind into someone else / there was AI involved...)
Tip: Use it if you’re bad at terms

Wait - is there a pattern here?

Okay. I wanted to put these on paper, because I like structure and I want to learn to be more aware what type of activity I’m engaging in. Now that the whole list is sitting in front of me, the conclusion is the obvious one: remind me where we were, remind me what X was, the cold start. They’re all retrieval and summarization over a bounded corpus I already own - my commits, my chats, my specs, the existing pile of articles and papers already out there on the internet. The agent isn’t conjuring value out of thin air; it’s fetching and compressing something that already exists and that I have access to.

The low and middling ones - rubberducking, brainstorming - are generative work, where the process of doing it is the value. And the moment you outsource the process, you don’t get the thing the process was supposed to give you. That’s the whole “the process is the solution” point from way back at the top.

So that’s the line, more or less:

• the agent shines when the value is in retrieving and compressing something that already exists

• the agent gets shaky (or actively counterproductive) when the value is in the process of generating the thing

That’s why some land at 5 and some at 2. It’s not really a list of random use-cases I happened to think of - it’s the same axis viewed from different angles.

And the in-betweens (enrichment, spec) sit at 4 exactly because they’re mixed: a lot of their value is retrieval (pulling in prior implementations, prior specs, the existing model of the app), and the generative part stays useful only as long as I keep ownership of it - i.e., I demand the human-readable output, I make the open questions explicit NOW, I keep the mental model in my own head. The second I let the agent own the generative part wholesale, those scores would drop too.

Obvious, I know, and actually I was more aware of these in the beginning of using AI, but I don’t know how about you, when you have this assistant next to you, which is now so much more than just LLM, but a lot of internal logic of the provider, you don’t usually PAUSE and think how and what you are going to tell it. You just do. And then get frustrated when the output is not to your satisfaction.

Hopefully this list will help me manage my expectations before entering the dialog.

So maybe the one-liner to take away, going back to what Ia said: it’s not “is AI dangerous” - it’s am I asking it to retrieve, or to generate? And if it’s the second one, do I still want to own the process?

The usefulness matrix

Rough reading of the table: the higher up you go, the more it’s pure retrieval and the more comfortable you can be handing it off. The lower you go, the more the process itself is the point - and the more you should think twice before delegating it.

A lot of this advice will sound obvious, but pay attention to what and how you use the LLMs every day, and you’ll start to notice that it takes a little bit of effort to introduce these friction points, instead of jumping into the conversation right away.

I’ll be adding more examples, about code generation, about learning something new, etc. but I thought I’d wrap this one before you are bored.

Looking forward to some comments of real usecases and thoughts.

Below you’ll find the text version of this episode, for those, who prefer reading :)

Guest: Adrian Hornsby — Resilience engineer, former AWS principal engineer, and founder of Resilium Labs

Adrian Hornsby spent over two decades in software engineering and operations — from researcher at Nokia working on distributed systems, to building messaging systems for millions of users, to nine years at AWS as a principal engineer on the fault injection team. About a year ago he left to found Resilium Labs and write a book, Why We Still Suck at Resilience. Its premise is uncomfortable: organizations have poured a decade into chaos engineering, game days, operational readiness reviews and incident retros — and the same incidents keep happening. In this conversation, he and Nune get to the root cause of the gap between how we think systems work and how they actually work — and why AI is widening it.

Why “root causes,” plural

Nune: When you learned the name of my show, we joked that it should have been “root causes,“ plural. Can you unpack that?

Adrian: The short answer is that it’s comfortable to think there’s one reason something fails, but in practice it’s never like that. It‘s the accumulation of small things happening at the same time that creates the condition by which the system fails.

The long answer is about the nature of complex systems, and how systems fail in what‘s called emergence — the interactions of components. It isn‘t really the components themselves that fail, it‘s their interaction. You can have two components working very well by every measure of the components themselves, but the interaction creates the problem. Once you start to think about systems like that, you can unpack an almost unlimited number of reasons why a system fails.

Root cause really comes from the old industrial era. You had, for example, an assembly line, and something would fail, and you‘d say, okay, let‘s go fix that — that was the root cause. It got carried over to software systems through safety-one. If you‘re interested in resilience engineering, you hear the terms safety-one and safety-two. For some reason people have liked to have one root cause, and I kept using it, and still today you use it. So, sorry, I got carried away again.

Nune: No, it‘s perfect. I personally picked “root cause“ because I like to dig into things — to find the reason things happen and not just stay at the high level. You keep asking why, why, why, and hopefully you get to one or many root causes. But now I‘m a bit stuck with the name, because whenever I choose a topic for an episode I have to formulate it in a negative way — you don‘t usually go looking for the root cause of a good thing. Which is probably also not correct. We should also look into things that went well and try to unpack why.

Adrian: You‘re touching on something so important to resilience engineering. The default when there‘s an incident is to look at what went wrong. But if you think about systems, they go well most of the time. It‘s only at the moment when emergence happens that the context starts to create failure. And that‘s what we want to understand — what worked well in most of the scenarios, and then the context when things went wrong, so we can really understand what happened.

So saying “root cause“ is actually a problem in incident analysis, because it biases engineers — it anchors them to look at what went wrong, when we should also ask, what went well? And then see how we can do more of that.

The default when there‘s an incident is to look at what went wrong. But systems go well most of the time.

Nune: Even in our day-to-day life, every person is wired to think about the negative things that happened. But when you think about it — how amazing is it that the day goes by smoothly? How many millions of possibilities there are for things to go wrong when we leave the house, and yet they didn‘t happen. We need to appreciate all the good stuff.

It isn‘t the components themselves that fail — it‘s their interaction.

Work as imagined, work as done

Nune: There‘s a term I think we‘ll use a lot today, and for people who aren‘t familiar with the terminology: work as imagined and work as done. Can you explain the gap between them, and maybe a disastrous example if you have one?

Adrian: Work as imagined is the version of work that lives in documents — diagrams, runbooks, organization charts, slides. It‘s really clean. It‘s what we write when we‘re caffeinated, during the day, all happy and smiling. It‘s very logical most of the time, and it‘s defensible to auditors and to leadership, because that‘s what we design.

But work as done is what actually happens. It‘s what you do at three in the morning when you‘re on call and you skip a few steps in your runbook because you‘ve learned those steps aren‘t the right ones — they haven‘t been updated since the last version was deployed six months ago. It‘s the engineer who learns that a particular alert is more important than another. You start to learn how the system behaves in production. And all of that is often not in the design docs, not in the documentation, and certainly not in the architecture.

What‘s really important to understand is that work as done is not a deviation from work as imagined — it’s a structural gap that happens naturally in every system. First you need an idea of what you‘re going to build, and between the idea and what gets implemented there‘s already a difference. Then you make shortcuts, you forget to implement something, or you implement something else. So naturally there‘s a difference between what you imagined in your head and what gets done.

As an engineer you need to understand that, because we often think about our system from the imagined world, but we really look at it from the done. The only situation where you look at the done is when there’s an incident — that‘s reality knocking at the door, saying, it‘s not what you imagined.

The only time you look at the done is when there‘s an incident. That‘s reality knocking at the door.

So when you have an incident, you don‘t necessarily want to understand what went wrong. You want to understand what the incident surfaced between what you imagined and what is done — what surprised you, and what changed in your mental model. That‘s the only thing you can do in that situation: learn from it. And that‘s why I often say the only answer to understanding that gap is learning. That‘s the thesis of the book.

The only answer to understanding that gap is learning. That‘s the thesis of the book.

When seniority detaches you from reality

Nune: There are so many layers to this. When you start in IT and you‘re not leading teams yet, you‘re solo — you‘re implementing, you deploy the thing, you test it. So you naturally know every step of what‘s done. What always surprised me is the role of the software architect. I‘ve seen organizations where the software architect doesn‘t come from software development — they‘re only an architect. That‘s surprising, because it means this person lives in that quite perfect world you described: not tired, having time to think about the system and its good or bad outcomes, and then architecting it. Maybe that‘s a good thing, because they need that time to think. But on the other hand — how can you be a good architect without ever touching the code? Do you think you can be one?

Adrian: There‘s a lot to unpack here. Let me go back to the first point about architects having a version of the imagined world. It‘s not just architects. Often you have senior engineers too, where naturally, as you grow in seniority, your areas expand across the organization. So you spend less and less time on the day-to-day operation of the service. And because of that, your version of the imagined reality — your version of the software in your mind — is slowly detaching from work as done, because your work is spreading.

I was a principal engineer at AWS, and I had a really big gap between my imagined version of the software and what was done on the ground, because I was dealing with a lot of different things. So it’s not the role. It’s a structural feature of organizational growth and promotion. And it has a cost.

That‘s why I say that the more senior you get, when you start to realize you‘re detached from reality, you need to switch from decision-maker to decision-enabler. You change your role from making the decisions about how things should be done in the real, done world of work, to helping people at the edge make better decisions through your knowledge and your experience. And often this is where you see it not happening in organizations — because when you move away from the done, you lose grip on it, but you want to keep making decisions, keep being relevant. It’s a resistance to being detached from reality.

So the long story short is, yes, those kinds of roles are detached from reality, and they make decisions that impact other people at 3am. That‘s a big problem. But it‘s not just architects — it‘s any role that is detached from reality and that keeps making decisions. The team will absorb the difference between what the decision-making team thinks it does and what actually gets done.

You need to switch from decision-maker to decision-enabler.

Nune: It does create that tension, but I think we also need to understand that‘s what abstraction is for. For any human to think and make decisions about a system, we have to abstract it and create models of it. There‘s no way around it. There‘s also something Charity Majors introduced — the manager pendulum — where you need to come back to development every two or three years so you don‘t become too detached.

From my own background — I had a previous startup and now I‘m building one — it happens naturally. First you develop it yourself, then you have to find a team around what you‘ve built. So you go higher and higher in the abstraction. And then if you build another component or another department, you‘re back in the trenches doing hands-on work, and then you get out of it again. So for me it‘s hard to accept that this gap exists. You need to embrace the gap instead of trying to fix it, because the gap is not going anywhere. There must be people who deal with the high level and people who do the hands-on work. It‘s a different mindset, a different style of working. It‘s a different role.

Adrian: It‘s a different role. I‘m not sure that going back to development as a manager is the right thing. I see a lot of CTOs vibe coding now and talking about it, and I‘m not sure that‘s right. The easier thing to do is to recognize that you’re not adequate anymore to make the decision — to delegate to the people at the edge and free them from the roadblocks so they can make those decisions. I love the idea of “you build it, you run it, you operate it, you fix it,” because that‘s exactly the people who actually run the system making those decisions.

It‘s not a bad thing to be detached. It‘s just recognizing that it‘s difficult, and that people clench onto making decisions because it feels powerful, it feels like you’re relevant. But it‘s a mindset. You can be just as relevant as a coach, helping others, and it‘s even more rewarding once you realize your job has changed and you‘re enabling others. That flip is very, very hard. Having been involved in a lot of promotions at Amazon, I think that‘s the hardest part going from senior engineer to principal — people flipping from being the expert in the room to being the enabler.

The hardest part of going from senior engineer to principal is flipping from being the expert in the room to being the enabler.

The hard part is letting go

Nune: That‘s something I struggle a lot with. To be honest, it‘s very hard for me to delegate, and it‘s a completely different skill set. When you work technically and get good at it, this other role of enabling people has a lot less to do with technical abilities and a lot more to do with empathy — knowing when to delegate and when not to. A friend of mine has an article on how that‘s similar to raising a child more than software engineering, because you need to be strict when you need to be, but also say it in a way that doesn‘t hurt the other person.

It‘s hard for me to grasp. And on the technical side — you shouldn‘t vibe code into production, but if you‘re about to introduce a new technology into your team, shouldn‘t you at least know more about that technology? Or do you always just find a person who knows it and enable that person?

Adrian: That‘s a good question. I‘ll put it in two buckets. The first bucket: maybe the fact that you can‘t let go of being involved in the day-to-day technical details is because you‘re building and you‘re not sure where you‘re going. That‘s what I see most — people have an idea of what they want to build, but it‘s not very well defined. The feeling you have is that by not being there making the decision, somebody is going to change the idea of what you think you‘re building.

Nune: I‘m not that worried about changing the idea — I hope I‘m not that clingy. It‘s more that I feel highly responsible that I haven‘t thought everything through yet. So how can I ask another person to implement it when I don‘t have all the answers, but the only way for me to get the answers is to actually build the thing?

Adrian: It‘s the same thing. Somebody else can build the thing and work with you so that, together as a team, you‘re building the right thing. For me that was the first bucket: when we‘re not clear on the idea, we get more attached to the details, because we‘re worried the idea won‘t go the way we intuitively think in our head — even though it‘s not clear.

The second bucket is simply a trust problem. Can you trust the people you hire and work with to make the right decision? One of my bosses back in the day told me, always hire people smarter than you, so you don‘t have to do their jobs.

Always hire people smarter than you, so you don‘t have to do their jobs.

Nune: That‘s also been an AWS motto — always hire people who are better than the people already in the company. Raise the bar. I completely agree. When I look back, the easiest things to delegate have been things I was never good at myself. UI development, for example — I know how to do high-level stuff, but I‘ve never become an expert in React. When I had a senior on my team it was easy to say, you make the decisions, you know better than me. But on the things I‘ve tried myself, I‘ve been over-controlling — and I‘m sorry to all my teammates, because they‘ve felt that.

Adrian: It‘s a normal thing. I‘ve been very controlling on the things I feel most comfortable with. I don‘t think it‘s about comfort — it‘s about trusting that other people can help you.

Nune: So the solution is to know less.

Adrian: I always use a mental model when I coach engineers. I explain it like building a snowman. Your idea is the body of the snowman — you start by rolling the big body, but you need the head, the branches, the carrot, all of that to make the idea better. You might have the central 80% of the body done by yourself, but all those additions are what make the snowman a snowman. Without them you just have a ball, and that doesn‘t get you anywhere. I like to think of our ideas like that — the central body of a snowman, and then everybody else in the company, on your team, adds to it. The only thing you can do is enable that. It gives permission for others to make your idea better.

You might have 80% of the snowman‘s body done by yourself — but it‘s the head, the branches, the carrot that make it a snowman.

Practices for learning from the gap

Nune: Let‘s assume we accept that this gap exists and that the gap is where the learning is. Can you give some practical tips for what it means for an organization to learn from the gap? It sounds good, but what does it mean on an average Tuesday morning — not as a philosophy? Because we say you can write better documentation, have a stricter process, more controls — but how do you not get into compliance theater? How do you actually learn from it?

Adrian: First, an incident is absolutely a mirror of that gap, because it happened. If you really spend time studying it, you‘ll learn about the done. But if you think a bit upstream, in the day-to-day of an operating system without waiting for an incident — which is the truth happening to you — chaos engineering, load tests, and game days are three really good practices for understanding some of the gaps.

Chaos engineering gives you a very good understanding of how you think your system is going to degrade or fail. You inject a failure and you make a hypothesis — you explain beforehand how you think your system is going to behave. Then you actually inject the fault and see what happens in reality. You study the observability and the impact of the experiment, and you have two versions to compare: your mental model pre-experiment and the post-experiment reality. That‘s usually a structural gap focused on degradation and failure modes — a very technical gap.

Load testing gives you another angle on the gap, more focused on whether your system scales as you imagine. Before injecting load you have your load test model, and you try to anticipate what will happen — what the load characteristics of your system will be. You inject the load test and then you see the result. That gives you a good idea of where your mental model about scaling is off. Especially what you want from a load test is to find the cliff — the moment where the system just completely collapses. Any system has a maximum it can handle, and then it collapses, and you want a very good understanding of that collapse. Is it at 120% of your scaling model? Is it at 80%? Does it actually break much earlier than you anticipated? That‘s a structural gap that load testing reveals.

Game day is a gap more about human coordination. Say you simulate a disaster recovery scenario, and you don‘t prepare the team — you just tell them the whole region is down, let‘s implement the DR. Then you see what happens. Is the team able to coordinate? Do they know what to do? Do they know which service to fail over? Do they communicate well with each other? Do they know how to come back? All of this is human coordination. When you did the exercise, you hoped the team would do well — and in reality they do a lot differently. One of the best games I do at the beginning of an engagement is to remove the team lead, the hero, from the team, and then see what happens. That‘s a structural gap between the imagined world and the done — a different version of it.

One of the best games I run at the start of an engagement is to remove the hero from the team — and then see what happens.

And then you have operational readiness reviews, which are also a structural gap between how they think the system is going to be operated in production and how it actually is operated.

Nune: So chaos engineering, load testing, game days — those are the tools an organization can use to bridge the gap.

Adrian: Practices. I‘d prefer to call them practices.

Nune: And I think one important event is also the incident itself. When somebody wakes up at 3am, they have to be the hero who fixes the thing no matter what — whether they followed the script or not. In my experience, the next day, or the day after, is very important: that person can say which of the things they followed worked, which didn‘t work for them, and the team can optimize the process using their first-hand experience. If you agree with that.

Adrian: Correct. You‘ve always had the experience where, during an incident, you try to follow the runbook and you notice on step two it’s already wrong. So you use your intuition, or what you‘ve learned from another team, and you go fix it. The next day is exactly that. You‘re not going back to root cause — you don’t really care what the problem was. What you want to understand is why you had to skip the runbook, what was different, what the context and the environment were — and then capture that, so you actually have more information about the real version of your system. But it‘s not intuitive for people to do that. They just want to go and fix the root cause.

How AI widens the gap

Nune: We‘ve established that the gap has always been there. We touched a bit on vibe coding, but I think we can generally say AI has widened it. Previously the gap was between departments, or between different roles inside the team. Now I feel we also have a gap between the person implementing and the AI that‘s actually writing the code, as more and more people use AI for coding itself. Do you see that? And second — when a CTO starts vibe coding, plus the gazillion of articles about how you can build something in five minutes, it creates a narrative that engineering is easy. Why does it take a sprint or two? Any advice for people actually building things on how to explain that it‘s not easy — how to push back in a way that doesn‘t get them into trouble, but also explains that it‘s still hard?

Adrian: It‘s a good question. The biggest problem with AI is that it hides the gap. Now, all of a sudden, you‘re asking AI to make decisions and to create things, and it does all of that for you. But the day after, or after the incident, you can’t recall the mental model of the AI — what it did and why. With a human, you could trace back the thinking to some extent. You had a trace of the mental model of the person doing it. So the gap was visible when you looked. Now it‘s not.

And even if AI is really good — it writes better code than me, and I use it, no problem — and even if it‘s right 99% of the time, the problem is the 1%. At 3am, your director is not going to blame AI for something that breaks. He‘s going to go to a human and tell the human to fix the problem. If AI can’t fix it, it always falls back to a human at the end of the day. So if AI wrote 99% of the system and at 3am you‘re thrown under the bus to go fix something that was never written by you, you‘re going to spend quite a bit of time acquiring the knowledge to debug, trace, identify, and potentially fix the problem.

That‘s the risk. It’s not that it’s not good — it’s what happens to the human when it breaks. It‘s so tempting to deploy stuff that AI wrote, and it works most of the time, which gives you a signal that it‘s good. But then comes the 1% where emergence happens, or different components interact in a way the AI didn‘t plan for, and a human has to go and debug it.

The biggest problem with AI is that it hides the gap.

Nune: I notice it a lot myself. I‘ve always been proud of how fast I can answer questions about the system — exactly because of the delegation problem, because I did everything myself. Now that I‘m delegating more of the development to AI, I feel I‘m not as fast. Most of the time the answer is, give me a couple of minutes, I‘ll chat with my AI, and then I can answer. Which is peinlich — embarrassing, as they say in German — because you‘re supposed to know how your system works on different layers. From one side it‘s a bottleneck — you‘re limited by how much you can keep in your head and reason about. On the other hand, as a lot of people are saying now, that‘s the load-bearing wall, because it keeps the system working.

Adrian: I don‘t have all the answers on that. We want to play devil‘s advocate and stay in control, and that‘s part of feeling uncomfortable when you don‘t know why something went wrong. But what really worries me isn‘t understanding what‘s written. It‘s that when something goes wrong, it goes to a human, and at that moment, under pressure, you’ll be asked about a system you have no idea how it was built. That worries me.

I don‘t know how we‘re going to solve it, because it’s a human problem. Humans are going to be blind — they are today and they will be in the future, regardless of whether you have an AI agent helping you. Something is going to give, something is going to break, and it‘s not new. Lisanne Bainbridge talked about the irony of automation in 1983, and she said that even back then, the more complex the automation, the more skillful your engineers have to be to fix the automation when it breaks. AI is the next level of this. It‘s a 40-year-old theory.

The more complex the automation, the more skillful your engineers have to be to fix it when it breaks. That‘s a 40-year-old theory.

Don’t delegate the thinking

Nune: That brings me to the thought that AI performs better in the hands of more experienced people. So what do juniors do? People who are just starting in IT — how can they learn? Do they force themselves not to use AI? It‘s difficult for them: on one side, people tell them to learn the fundamentals; on the other, there are all these tools that also take time to learn. You don‘t just write a prompt and that‘s it — you also need to find your way of working with all the AI tools. Do you have advice for people who are just starting?

Adrian: It‘s a good question again. The cynical part of me feels like it‘s old-man-me talking about the good old days. I‘d say younger engineers will figure things out. They’ll find a way. There are so many unknowns at the moment. They‘ll figure out how to work with these technologies far better than we do. When you‘re AI-native, you‘ll probably develop mental models that are very different from ours, and that‘s okay.

The only thing I‘d say is: be careful of efficiency. Efficiency drives speed, and trying not to spend time learning can bite back. Understanding how to debug a system without AI is going to be an important skill. Imagine you‘re at 3am and the cloud is not available and you can‘t ask it what to do — what are you going to do? Are you going to refit the whole context of your application into another model? Probably not. Flying blind is not something new. When you don‘t have monitoring, or you don‘t have Slack, or your team breaks during an outage, you have to find ways around it. If you completely rely on AI for everything, that becomes your single point of failure — and it‘s a big one, in the case of an outage where you don‘t have AI to help you, or AI fails and tells you, sorry, I don‘t know. Then what? You tell your boss, I‘m sorry, I don‘t know, we‘re going to stay down. Claude doesn‘t know.

If you completely rely on AI for everything, that becomes your single point of failure.

Nune: Actually, when I started working on my current startup, OpsWorker, the original intention was that a lot of development would use AI, there would be a lot of code coming into production, and you‘d have even more observability tools and dashboards, so the load on SRE would grow. So why not also use AI to gather all that information, present it to the person, and help them deal with the complexity? But I‘m very worried that people will use tools to delegate thinking as well. Is there a version of the tool where this can be prevented? Or is that not even a function of a tool, but rather training people, asking them not to delegate thinking?

Adrian: There‘s a version of tools that‘s related to efficiency, and there‘s a version of tools that can push back and enforce learning mechanisms — like struggle. I just published the Resilience Companion, open source today. It‘s a companion I built to demonstrate how AI can actually help you learn.

It’s so easy to delegate everything to AI, but then you don’t learn anything. And again, going back to when something breaks — if you haven’t learned anything, there’s very little you’re going to be useful for. So you want to keep learning, which means using AI in a way that challenges you, that puts you in a mode where you struggle a little and have to go find the answer yourself. That helps you build mental models about the system, because you have to think about it.

That‘s exactly how I built the companion. It asks you what you think the system does, and the more detail it gets, it‘ll push back when you try to stay too high-level. Then it‘ll go and verify when you‘re really uncertain, and that gives you a very good indication of where you need to spend time, because your mental model of how part of the system works and how it’s actually coded are so different.

It‘s possible. But it‘s not going to become a standard in the industry, because no one wants to spend more time doing things. The industry — capitalists — love efficiency. They want to go as fast as possible. It‘s so tempting and so easy. You offload cognitive struggle, and the brain loves that. If you can make things easier, the brain says, hell yeah, jump in the wagon. You need people who are aware that they need to struggle to learn, and you need to tell them why it‘s important. But I don‘t see that coming naturally.

You offload cognitive struggle, and the brain loves that. Make things easier and it says, hell yeah, jump in the wagon.

Nune: To be honest, this is the first year in the industry that I‘m feeling old. Every time I think I‘ve delegated too much to AI and I need to slow down, I read an article or talk to a peer who says I need to delegate even more, because otherwise I‘ll stay behind and the world will have gone ahead while I‘m still here. It‘s a permanent FOMO. I thought I was in FOMO, and then after 2021, 2022, when all this started, it became ten times the FOMO.

Learning through crisis

Nune: So my question is: does it even make sense to advise somebody to slow down, or, as you said, is it not going to happen? And how do companies that now have this pressure — you must bring AI into the organization — do that in a way that doesn‘t bite them later for being too fast into unknown territory?

Adrian: The answer is crisis. They‘ll be faced with a reality that they just don’t understand what they’ve deployed in production. And at that moment, you don‘t have a choice. Either you face reality and look at what you‘ve done and how your workflows have been — and if everything was over-delegated to AI, you can make two decisions: continue and keep getting into crisis situations, or slow down.

I already see customers in what I call undeclared crisis — they have similar incidents happening, AI is exacerbating that, and they‘ve come to the realization that they need to change, that something needs to give. Often it‘s spending time learning, and they‘re making those decisions. The thing is, it’s learning through crisis. It rarely comes without the crisis. Crisis is a very good incentive to change, because you‘re in that situation. But that‘s not much different from anything else we do in life. We often learn through failure or crisis — like touching the hot oven.

It‘s learning through crisis. It rarely comes without the crisis — like touching the hot oven.

Nune: So you mean they‘ll adopt AI so much that it will bring them to a new crisis and they‘ll learn from it? Or that they need to learn already from the incident?

Adrian: They won‘t have a choice. The more they adopt AI, the more they‘ll be in a crisis they can’t explain, can’t debug, can’t recover from. At some point, the outages are going to be so much longer, because they can‘t understand the system. It wasn‘t written by them — it was delegated to AI. Thinking was delegated to AI. The documentation is completely outdated. A human will have to go and understand it at that moment, under pressure, at 3am, and that takes time.

I‘m already starting to see this with customers. When you write the code, you intuitively know from the error what happened. You receive the alert and you go, damn it — you intuitively think about what might have gone wrong, and you start investigating there. That‘s intuition, and it’s so important in incident response. If AI writes everything, you don’t have intuition anymore. You receive an alert and you go, all right, let‘s build the mental model of how the system works, let‘s dig into the logs and the code and try to understand what happened. And it‘s going to take a lot longer.

Your customers are going to scream at you. They‘ll tolerate it a few times, and the third or fourth time they‘re going to tell you, either you change or we change provider. At that moment you‘ll have to make some choices. Either use AI but figure out a way to spend time understanding what AI is writing, or there‘ll be new disciplines — let AI write, but do more game days to understand how your system is failing, and learn how to debug a system you never wrote. There‘s a lot of that already today. It‘s rare that you‘ve written everything in a system you debug at 3am, but you have intuition because you built part of it. So maybe the only viable solution is to do a lot more chaos engineering, a lot more load tests and game days, so you can learn from that gap — because now the gap is even more present. Is that going to happen? I don‘t know. Maybe a new discipline shows up.

If AI writes everything, you don‘t have intuition anymore.

Nune: I‘m sure there will be remixes of previous disciplines, now adapted for AI. And coming back to the open source you mentioned that you published today — if the tools themselves can help you build that intuition, that would be interesting: to extract the exact amount of information needed to build intuition without knowing every single detail.

If we try to root-cause it one last time and summarize: we talked about the gap between the imagined and the done, how AI widens it, how nobody wants to fall behind, how everyone is in FOMO. If you had to find the root causes of this gap, and of why engineering organizations are losing their cognitive capacity — is there something we missed? Or is the answer really, go full speed and learn from your mistakes?

Adrian: I wouldn‘t say learn full speed. I‘ll actually point people to your Substack — the article I read about your journey to delegating to AI was wonderful, because you talked emotionally about what you were giving up. People need to read things like this. We need to stop telling only the stories that give everybody FOMO — the 10x that just goes full speed and works. I want to see stuff in production that has been completely written by AI. I want to see an enterprise system with millions of customers, managed and run by AI without a problem — and without having humans to delegate to at 3am. Then I‘ll be convinced. At the moment, I‘m not. It‘s easy to write on Substack or LinkedIn that you‘ve written an amazing tool with AI — great, that‘s awesome. But putting that into production, operationally production-ready, is a completely different beast.

I want to see an enterprise system with millions of customers run by AI — with no human to call at 3am. Then I‘ll be convinced.

Code is the small part

Adrian: It‘s the same when you build a prototype yourself. The code works — awesome. But now a million customers are going to start using that code, and it‘s a completely different story, because you have to start thinking about everything around it: the monitoring, the deployment, the operating, the alarms, the on-call rotation, the documentation, the onboarding. The code is such a small part.

So maybe all these AI tools are going to start tackling everything around it. But as long as you only do the code and tell me it‘s ready to go to production, I‘m going to say, show me. Show me. Because I don‘t yet believe it. I‘ve spent a lot of time running systems in production, and the code is—

Nune: I always think back to — I think this is the Unix philosophy — make it work, make it nice, make it fast. The “make it work“ part is something AI can help you with a lot. But then making it right — making it architecturally clean, expandable, maintainable, observable — that still requires human involvement, and not just one human, a team. And making it fast — all those game days and load tests, making sure it works smoothly for the number of users you expect. That‘s something we still have to do.

Adrian: And that your customer found useful. You can build as much code as you want with AI, but if your product isn’t what the customer wanted, no amount of AI is going to help. It‘s about talking to your customer. And often customers express something they want, but they want something slightly different — they just didn’t have the words to express it. So a lot of the work as a software organization is trying to understand what the customer wants first, then providing answers, then figuring out which answer is better, then iterating and making compromises, because often you can‘t serve everything. All of that is human. It‘s a relationship with your customers, and it‘s prompting your AI correctly. Your AI can be very, very correct, but wrongly correct. Confidently correct — confidently wrong is a much better way to say it.

Nune: Yeah, very confidently wrong.

Your AI can be very, very correct — but wrongly correct. Confidently wrong.

What to read

Nune: Do you have any practical recommendations? You recommended my blog post — thank you for that. And there‘s your book. Any other books or resources on how to implement technologies within an organization the right way, be mindful of these gaps, and resilience in general?

Adrian: The whole resilience engineering field is interesting — you‘ll learn a lot. I think cognitive science is super important; I‘m fascinated with psychology, because it has a lot of impact. I wouldn‘t necessarily recommend one book. I think it‘s better to go explore other disciplines, other industries, other sciences, because you find a lot of good in there, especially around human behavior. It‘s so fascinating, because it‘s at the center of everything we do — even though AI is going to be pushing us to write code fast, at the end we’re still in the business of human relations with our customers.

No amount of AI is going to fix that. Actually, it can make it worse. I hear a lot of comments from customers who can‘t get a human contact when there‘s an outage — it’s a Google form, or it’s an AI chat, and it frustrates them insanely when there‘s a problem. Humans are going to have to find their place there as well.

So I‘d say the Bible is How Complex Systems Fail by Richard Cook — probably amazing stuff. John Allspaw wrote a lot of cool stuff around incident response. Hollnagel is about safety-one and safety-two. Read a bit of all of that, and be curious about other areas. I think that‘s a good thing.

In the end, we‘re still in the business of human relations with our customers. No amount of AI is going to fix that.

On fear and staying relevant

Nune: We have this thing — which is also a bit of a problem for building podcast episodes, because now I have to produce them strictly in the order I create them — where every guest leaves a question for the next guest. The previous guest, Marc Babin, left a question that I think should be difficult for you, because you already share a lot of what you‘re learning. But maybe you can answer: is there something you‘ve learned this week that you haven‘t shared yet?

Adrian: I‘m still scared a lot — about opening up. I open-sourced the companion today, and it’s very scary to expose yourself. And it was written with Claude, whereas all my other repos were written entirely by me without AI. So I‘m jumping into open-sourcing something I worked on with Claude, and I have to say it took me quite some time to feel comfortable with that. So I‘d say I learned that I’m still scared about exposing things to the world. After 20 years.

I learned that I‘m still scared about exposing things to the world — after 20 years.

Nune: Even after 20-something years in IT, you can still be scared of posting something online.

Adrian: And it‘s tough, because you expose yourself to the world. Being on a podcast, sharing ideas, writing a book — it‘s scary. Kudos to you, starting your own podcast. That‘s something as well.

Nune: I‘m horribly scared as well. One of the things is that the more you‘re able to analyze any question — and I wrote about this lately — the more you‘re able to see both the positive and the negative sides. I can critique myself endlessly. So whenever you put something out there, you‘re cutting that critique out and leaving only the positive thinking: my opinion matters, my open source matters, my product matters. And subconsciously, I think, we‘re afraid of all the critique that can come — which we already know is coming, because there‘s no perfect system.

Adrian: So why did you do it then?

Nune: That‘s a good question. As I mentioned with Marc, there should be content out there that isn‘t “10x improvement in four days, do this and that.“ I wasn‘t seeing that content, and I thought, as I think any person who writes a book says — I searched for this, didn‘t find it, so I wrote it. That‘s one reason. And another reason is, selfishly, to get better at expressing myself, better at asking and answering questions in a way people understand, so I can bring out more awesome ideas and have people understand them.

Adrian: On your first point, this is why I liked your post. It was just so different from the rest. It was honest. You shared emotion, your struggles — and that works. It spoke to me, because you wrote about delegation, about slowly giving it away at each step of the way. I haven‘t managed to go all the way yet — the last steps in your post, with open Claude and doing the thing there. I‘m old school, I still run locally, very controlled, human in the loop. And it made me think: if I don‘t evolve the same way you have, I got worried. Am I going to not be relevant in a few years? That was a moment of reflection I had.

Nune: I hope not. I don‘t think so. I think the industry is going to hit the wall and realize you can’t keep delegating more and more of the thinking. And people who have built something themselves will always stay relevant, because of how much intuition they have. Even if it‘s not a system you built, you‘ve seen ten other systems similar to it, so you do have the intuition. So I‘m hoping not.

Adrian: Maybe the relevance is more that I don‘t understand the development workflows anymore — multiple agents, the whole mental model of the relationship between the human and the act of shipping product. That‘s what your post made me question: my relationship with building product, and whether I‘ll be able to advise my customers in five years if I don‘t adopt that, because the problems are going to be different. If I‘m not there — younger engineers are already there. It‘s natural for them, and I‘m not; I‘ve resisted to some extent. So that‘s what I meant: am I going to be able to understand that?

Nune: Only time will tell. I also read the joke that we‘re the generation that didn‘t want to accept cookies, but we accept giving our code and ideas to AI. So that‘s kind of contradictory. I don‘t think anybody knows if tomorrow everybody will say this was all a mistake, or if we‘ll continue and build more and more agentic systems — supporting agentic systems, fixing other agentic systems. I‘m excited to see.

Adrian: It‘s extremely tiring as well, because it‘s a completely new space, and it‘s exhausting.

Nune: Of course. Finally we thought we‘d understand everything — we‘re in our 30s and 40s, and we can just enjoy the years.

Adrian: The biggest revolution in software happened at 46, when I thought, after 25 years— actually, I‘ve never thought about it like this, but I think you‘ve got it so right. That‘s why it‘s exhausting. Finally I thought I had it right, and then boom — in a couple of months I have to relearn. You‘ve identified the problem. Thank you.

Nune: Well, it keeps us on our toes. The root cause.

Adrian: That‘s the root cause.

The biggest revolution in software happened at 46 — just when I thought I finally had it right.

Nune: Do you have a question for our next guest?

Adrian: What surprised you the most in the discipline you were most comfortable with?

Nune: That‘s generic enough that anyone who‘s good at something can answer what surprised them in the thing they‘re good at. Thanks for that.

Adrian's book - "Why We Still Suck at Resilience" is available with discount under https://leanpub.com/whywestillsuckatresilience/c/rootcausebynune

for those who prefer reading :)

Marc Babin spent four years making 106 videos for Westin and Marriott in the Cayman Islands with zero video experience, then six years at AnyLine building an entire content infrastructure from scratch — a dozen podcasts across industry verticals, over a hundred episodes, and a bronze at the Transformer Awards Europe. This year he launched The Podcast Blueprint. He’s also the person Nune works with on her own brand, so this is no cold interview: it’s a conversation with someone who has watched her perfectionism, her frustration with the algorithm, and her discomfort with being visible online up close — all while she hits record on her show for the very first time.

Has the volume killed content?

Marc Babin: Thank you for having me. It’s a great pleasure and an honor to be the first guest on what will be a large show. But first I want to say congratulations on taking this step — not only into the podcasting world, after everything we’ve spoken about to get here, but for taking all the little steps too: rearranging the room, getting the equipment, committing to it. All of that contributed to where we are today, hitting record for the first time. That’s a monumental moment, and one I want you to sit with. You hit record for the first time on your show. That’s epic, and a massive congratulations to you.

Nune: Thanks for being on this road. You’ve been a tremendous help, both technically and mentally. What I wanted to talk to you about first is the sheer volume of content nowadays. Even before AI, content was everywhere — and now with AI it’s faster and louder. Your entire career is around content, marketing, video, podcasts. Do you think content making is still a valid path to marketing, or even to self-expression — or has the sheer volume just destroyed it?

Marc Babin: Absolutely, yes, to the first part of that question. The volume hasn’t killed it, and let me explain why. Most of what’s flooding the internet right now is noise — you know this, everyone knows this, it’s just noise. My own estimate, and this doesn’t come from anywhere, it’s purely from experience: I’d say 70% of it has zero real marketing value. It’s a lot of noise for doom scrollers.

But that’s actually good news. I genuinely think it’s good news, because it means the bar for standing out, for breaking through that noise, is completely achievable. I know this because I’ve done it multiple times, in multiple formats, in multiple industries. It does work if you can break out of the noise cycle.

Good, authentic, powerful content still cuts through. I’ve watched it happen firsthand, building podcasts and building videos. B2B, B2C — it doesn’t matter. Good authentic content will still cut through, and the opportunity to do that is very real and very achievable for most people. People get afraid that they’re just going to fall into the noise and be unheard like everyone else.

The mistake marketers make is treating content like a calendar-filling exercise — they check it off the daily task list: “I’ve got to make posts for Monday.” I fall into this too; everyone does. It becomes this downbeat, cloudy “I’ve got to get this done, I’ve got to make content for the week.” That’s the mistake, and I have to remind myself constantly not to think of it like that. The people who produce content and actually care about what they’re making — social managers who care about what’s being published — those are the ones who succeed. In my last role I worked with an incredible social manager who genuinely cared about what went out and fought to make sure the content was genuine. That makes a real difference. It makes you stand out from the noise. It’s tangible — we see it in the results all the time.

Nune: Two things. I feel it in myself whenever I force myself onto a schedule — and the algorithm pushes you toward that, because the more consistent you are, the better, as everyone says. But the moment it becomes scheduled, it becomes a job, you start hating it, and you start squeezing the content out of yourself. You want to speak when you have something to say, not force it. On the reality side: do you think AI-generated content will always be visible — meaning people will tell you apart from the AI — or will it become indistinguishable at some point?

Marc Babin: I think it will always be distinguishable. You just need to be more aware. We see this in the real world all the time now: an image or a video gets posted, and the comment section is always “please tell me this is real,” “please tell me this is fake,” “this is obviously AI.” As AI improves, that’s going to get harder and harder to distinguish just by looking at it. So those 15-second clips, the noise — that’ll always be a bit more difficult to tell apart, because the piece is so short.

But when we talk about content that matters, content that has purpose, that will always be easier to tell what’s real and what’s not. You’re never going to see a fully AI-generated podcast that you’ll know is fake. It’s going to read as real, just based on how people talk and the tone of voice. The imperfection is the real truth. It’s the humanity. People relate to imperfection, and in a world where everything we see is AI-perfect, that imperfection — that real human authenticity — is what stands out. I hope it’ll never be replicated; maybe that’s a future conversation. But the pauses I take, the “ums,” the “ahs,” all of it tells the listener I’m a real person.

I was told once — and you probably know this better than I do — about those checkboxes on websites and forms: “check the box if you’re not a robot.” The whole concept, and this has always stuck with me, is that they were designed to detect imperfection, the imperfect way a human checks a box. This is going to change the way everyone listening sees these boxes from now on. If that box shows up on a window and it’s a spam bot, an AI bot, a robot, it will just straight-line for that check and click.

A human will never just straight-line. There’s imperfection in the way we move, the way we think about it, the timing it takes. That imperfection is exactly what lets us pass the checkbox quiz. It’s not about checking the box — a robot can check the box — it’s the imperfection in the process. It’s the same with content. AI is not a straight line, but it’s a prompt and a response; the prompts may evolve and the responses may evolve, but it’s still a straight line. Humans don’t think that way. We reason, we question, we pause, we make mistakes.

I used to say “content is king.” Everyone was saying it, I said it, I believed it, I drank the juice. But it’s not true anymore. Content is not king. Good content is king. Good, authentic content is king — and it’s important that content creators know the difference.

Why podcasting still works

Nune: True — there’s so much sci-fi that’s made the same point: imperfection is what makes you human. You mentioned 15-second clips. They call this the reel-thinking generation, with shrinking attention spans — you just swipe next, swipe next. And yet here we are, sitting and talking, and this will run at least 30 or 40 minutes. Who has time to listen to two people talk about anything these days? Given that, do you think podcasting is still a valid path for marketing?

Marc Babin: It’s a good question, but here’s what I find fascinating: our perception versus what the actual data tells us. This is where data-driven insights overshadow what we assume. The data pushes back on the premise. Podcast listening has gone up, not down — even as short form has exploded. Short form exploded and the attention span on those short clips is swipe, swipe, swipe, swipe; each one is a different piece of content. I’ll come back to that. But the stats don’t lie. I have one pulled up here — a US-based report. It showed that podcast listeners in the US rack up 773 million hours of listening per week. That’s a 350% jump since 2015.

So something else is going on. This isn’t just about attention spans. What people are really starved for isn’t short content, it’s content that respects their intelligence. A 15-second reel can entertain you for 15 seconds, ten seconds, five seconds — but then you’re onto the next one. You’re not gaining anything from it. It can’t change how you think about something, and it can’t build real trust with an audience. All those scrolls you do — do you even know any of those followers? A lot are bought accounts, fake accounts, just chasing likes to make a paycheck. You can’t build value there.

Podcasters do things differently, and that’s why it works and why it’s still growing. Here’s the other piece of the puzzle: context matters. When someone puts in their earbuds and heads out for a drive to work, or does a workout while listening to a podcast, they’re not doom scrolling. They’re in a completely different headspace. They chose to do that. They chose to listen to that show. That’s an incredibly valuable piece of marketing, and it’s still very much untouched.

So it’s important to see the distinction between short form and long form. They’re not competing. They live in two different worlds. Yes, they’re on the same device; yes, it’s all content — but they’re not competing. They serve completely different jobs. The mistake is assuming attention spans have shrunk across the board. What’s actually happening is that people have become more selective about how they spend their time. They’ll give you 15 seconds of low commitment in bed or on the sofa while watching a Netflix show — but they’ll also give you an hour if you’ve earned it. That’s why I literally dropped everything I had going on career-wise to build the business I have now and share my passion for this format. Podcasting is about earning that time, and it’s very much under-tapped.

They’ll give you 15 seconds of low commitment on the sofa — but they’ll also give you an hour if you’ve earned it.

Nune: That’s exactly why I decided to start Root Cause — I want real content, real conversations. So much content isn’t real, and even when it’s not AI-generated, it still isn’t real. You start thinking, why don’t I create the content I can’t find? So I agree. One thing I was curious about: in your previous role at AnyLine you made podcasts about topics that aren’t exactly sexy or entertaining — automotive, tire tech, retail, logistics. You and I even did an episode on power and utilities. How do you make that kind of content interesting? Or do you not have to, because it’s about choosing the audience and context again?

Marc Babin: 100% correct — you just answered the question for me. It’s not interesting to a lot of people, but it’s interesting to a few, and those few are exactly who we were speaking to. And I made mistakes along the way. The reason we started podcasting at AnyLine was COVID: we lost the ability to reach people the way we would at events, to have those natural, raw conversations. So we did the webinar cycle — everyone did the webinar cycle. It fizzled out. Once everyone started doing it, it became everyone competing for the same space, one big sales conversation, people getting pushier and pushier. Webinars had their moment, but the raw conversations, the genuine connection points, were lost. That’s why we started podcasting.

We did a generic show at first, because I didn’t know much about it — I dive first and look later. But I learned we had to be more specific about our targets. So we made different shows for different industries: automotive, retail, logistics, technology, AI. There was one more I can’t remember. We built shows to speak to the few, not the quantity — targeting quality. By targeting the quality of the people listening, we could have much more in-depth conversations, because we knew the people listening were genuinely interested.

You’re right, they were boring topics — absolutely boring. Talking about tire technology, or the latest AI robot for the logistics field, isn’t interesting to 99% of people. But we were never targeting the 99%. We were targeting the 1% who might get something out of it, then reach out and have a conversation with us. It was that super-niche focus that built the dedicated audiences we had on those channels, and they grew. You think you’re talking to a niche group, but there are so many people in the world that even a niche group is still large enough to build an audience from.

We grew to the point where people were asking to come on the show because they’d heard us. That’s how you know you’ve more or less made it a success — when people want to be on your platform. That’s how we made it interesting: we forgot about everyone else and focused on who we wanted to speak to. This wasn’t a one-on-one conversation, it was a five-on-one conversation — an elevated discussion with experts about expert topics. That filtered who listened, and that made it a better audience for us.

Nune: Niche down, as they say — and you still find yourself with a lot of people in that niche.

Marc Babin: Absolutely. People forget there are a lot of people out there. Everyone’s obsessed with fame and popularity — “I want millions of this, millions of that.” Just start chipping away. The numbers will come. Our automotive show, our biggest show, was probably around 3 million views by the time I left the company — and it was revenue-generating. It was successful, despite being super-niche topics. We chipped away at it episode by episode, year by year. You have to play the long game with this stuff.

Sales, marketing, and the long game

Nune: I’m honestly just out seeking my people, and hopefully that makes it a success. You mentioned sales briefly, and I’m going to be intentionally naive here. You once told me, “I’m not good at sales, I’m a marketing guy.” In my head I thought, isn’t that kind of the same? For tech people, everyone who isn’t in tech — sales, marketing, PR — those are the people who talk with people, versus people who talk with computers. I ask because a lot of tech people don’t want to be selling themselves, and marketing feels like going out and saying “look how cool I am.” It always feels a bit weird, especially for people with imposter syndrome — and a lot of tech professionals have that. So what do you tell them? How do they get out of that feeling, and what’s the difference?

Marc Babin: Honestly, you’re not completely wrong. People get precious about the distinction, and often the ones who insist on it aren’t very good at either. Here’s how I actually think about it. Sales is a conversation with one person at a time. You’re trying to move that one person to a decision — usually on their timeline, or their budget, or to push a product. But it’s one person.

Marketing is the same conversation, but at scale, and before they’re even ready to buy — way above the funnel, early in the pipeline. You’re not closing anyone. Your goal is not to close anyone on a decision or move their timeline. Your goal is to make sure that when the moment comes, they already trust you. That’s the brilliance of marketing, the real distinction: it’s a trust-building exercise, and the people who get that make the sales process much easier down the line.

Podcasting is one of the best examples I’ve seen of this. Think about what happens when someone has listened to your show for four, six, eight months. They feel like they know you. They trust your thinking, your process, how you deliver. They’ve heard how you handle hard questions. Your authenticity spills through. That’s not selling. But by the time that person enters your sales process — if they enter it — half the work’s already done. They know you. You don’t have to do that part for anything you want to sell them. They’re going to listen, and that’s the hard part done.

So yes, marketing is about moving people, but the best marketing feels like that — and that’s why I love it. To come back to that quote of mine, the more accurate phrase is: I’m not good at closing. I’m good at storytelling, I’m good at relationship building. It’s not that I don’t enjoy sales; I don’t enjoy the closing process. That’s why I call myself a marketer. I’m a storyteller, and I help move the needle to make it easier for the sales team down the line. Marketing is very much a long game. I’ll touch on this more later with one of your questions, but the work I do today doesn’t affect tomorrow. Recording this episode now isn’t going to change your world tomorrow — but it’ll change things in three to six months. Not doing it now means that three-to-six-months from now looks different too, but your tomorrow stays the same.

Nune: When I started putting myself more online, here’s what I was thinking. When I join any project and start working with the people on it, first impressions are usually that people are a bit skeptical, and you have to earn their trust over the course of the project. Every meeting you’re not late to and you’re prepared for, every task you promise and deliver — that builds trust. You don’t notice it, but months later they say, “it’s so nice to work with Nune, Nune is great.” And every project you repeat those months of trust-building. So I thought: I need to externalize that. Put it out once, so when people Google me and watch my videos, those months of trust-building get shortened — at least a bit — because I say what I think and speak the way I normally speak, and that already shows a genuine side of me and cuts the onboarding shorter. That was the intention.

Marc Babin: It’s not even just shortening the onboarding. You’re talking about a relationship with a person in a professional setting, and that’s hard to build when you walk into a room cold. Take a sales call: if you’ve never met that person, you’re not only trying to push a product they may or may not need, you’re also trying to build a relationship in that short window. That’s a lot to accomplish at once, and that’s why good salespeople are good at what they do — I respect them 100% — because they’re establishing the relationship, showing as much authenticity as they can (whether it’s genuine or falsified is a separate conversation), and then giving them something.

Think of a car dealership. The good salespeople aren’t the ones who say “which car do you want? Come take a drive” — those are the aggressive ones. The ones who ask “what are you after? I have a family too, I love that” — they establish relatability. Those are the ones who succeed. It’s the same with what you described: if you’ve built a relationship with someone over time and you finally meet them, you can skip right to the technical talk. So I’m a big fan of the long game when it comes to awareness-based and content-based marketing, because it builds trust between a brand and a person, or a person and a person. You’re going to do this show, you’re going to speak to a lot of people. When you approach someone in the future and say “I want to talk about this business opportunity,” it’s going to be a lot easier because they’ve listened to you, they know you, they understand you. Maybe they know someone you’ve spoken to, so your credibility checks out. People undervalue what that can bring — “it’s too much work, it’s a long game, it’s six months from now” — but it matters.

B2B, B2C, and the case for personal visibility

Nune: You’ve worked in corporate brand strategy for years, and you said B2B and B2C don’t matter. Do you really think they’re the same? Now you’ve got The Podcast Blueprint, and you’ll be helping both companies and individuals. Do you approach those differently, or is it all the same? And why do you think it’s important, in this day and age, for a single person to work on their own social presence and marketing — or is it enough to go along with their company and not express their own personal brand?

Marc Babin: It’s easier said than done. On the B2B versus B2C part: I’ve built a process, and I’ve been refining it, that’s universal. As long as the process is followed, only the messaging changes. You don’t change the process — you stick to the fundamentals of building a good show and good content; it’s the messaging that changes. Having worked in both worlds, if I went back to start over in hospitality, I’d approach it with this process and it would lead to successful content. That doesn’t change.

On visibility: you’ve got people, like yourself, who are experts at what they do — but you’ve been busy. And then you fall into this spin cycle of “too busy to post, no one’s going to watch it anyway, what’s the point?” A lot of people feel exactly that way, and I completely agree it’s real. It comes right back to what we were talking about with noise: the loudest voices online are often the ones with the most time to be loud, not the most experience to share. The people aggressively posting on social media all the time, doing all the comments — they have time to do that. That’s your first red flag.

For the people on the flip side — experts and professionals who want to build a brand but are afraid of falling into the noise — there are tools. AI is starting to lower the barrier, which is genuinely exciting, but it’s also a trap. If a 15-year veteran starts auto-generating LinkedIn posts that sound like everyone else, with the same emoji dots and the same “if I didn’t do this, I would do that” — we’ve all seen it — they’ve just joined the noise. They haven’t cut through it, and they’re going to lose their credibility. And that credibility is the whole asset. You can’t outsource a point of view. That’s really important to know.

So, on personal branding: why does it matter right now? Because trust is the scariest thing to achieve, but it’s also the scarcest thing on the market right now. Authenticity and trust are the hardest things to find, because while anyone can produce content, not anyone can produce content that makes you think, “this person actually knows what they’re talking about.” That little gap, that little sliver, is the opportunity. You know a lot about what you do, and you don’t want to fall into the hole where it becomes noise.

For people who are too busy building to be performing — like you’ve been for years, like many executives — there’s no better way than podcasting and short videos that show the most natural form of yourself in the most natural format. You’re not just writing a post like everyone can do. You’re not crafting a caption with AI. You’re just talking about what you know, the way you’d talk about it with a colleague. That’s where the real expertise comes out, and an audience will feel the difference immediately. That’s why they’ll make the decision to tune in and watch.

You can’t outsource a point of view. The loudest voices online are often the ones with the most time to be loud, not the most experience to share.

Nune: This is exactly what I want to encourage busy builders to do. As a community of IT people who’ve been around long enough to see what’s hype and what’s real, this is what we need — experienced people who are building things to talk, and to find a little time to set up the infrastructure around their content. It takes some time, but once you set it up and find your groove, it’s similar to setting up your tech environment. Every developer knows you need your environment comfortable, from the notebook to the software on it; you need everything at hand. Once you have it, you’re crazy productive. I think it’s the same here — once you set everything up, you can just do it while you build.

Marc Babin: That’s it. Talk to me about the excitement you got from setting it up. We had those conversations — getting the equipment, seeing the quality, setting up your space. It re-motivates you. It’s like, “this is actually really cool.”

Nune: Definitely. A lot of techies are into equipment of any kind, and that’s a trap. On one side you want to set it up and be done with it; on the other, once you get a good mic you’re all about the sound, and once you get a good camera you’re all about setting it up perfectly and making videos and having fun with it. So the process of setting it up fuels the making of the content. I can relate to that.

Marc Babin: It helps motivate you through the build process. And then the next level of anxiety kicks in: “well, now I actually have to use it.” But if you’ve built it, they will come.

Nune: It’s both frustration and fun. That’s also what building products is about — both frustration and fun. Maybe anything you do that you enjoy has both elements in it.

Marc Babin: 100% agree.

The perfectionism trap

Nune: There’s one thing that ties experts together: the perfectionism trap. I’ve seen it in myself — it took me a long time to say “all right, I’m ready to hit record,” because I wanted it to be perfect. You’ve said before, “embrace the imperfection and let your content be real.” For someone who built a whole career around precision — making sure a thousand tests pass before deploying to production — that advice to just be real and get things out there is almost a personality change. So what would you tell me, or others who suffer from perfectionism, when it comes to content?

Marc Babin: You’re right, and I’ve seen it, and I say that with full respect, because it usually comes from the best people. I genuinely believe the ones who care most about quality are the ones most paralyzed by it. That’s the reality. But here’s where I’d reframe it. Your career was built on precision because the stakes at the time demanded it. A wrong decision, a bad brief, a miscalculated product launch — those have real, immediate consequences. So your brain learned, over and over, to get it right before it goes out. That defines how a perfectionist thinks.

But content doesn’t work that way, and it’s really important people know the distinction. The cost of an imperfect post is almost zero. Who cares? No one cares — and that’s actually what makes it imperfect. But the cost of never posting is enormous, because no one knows you exist. I’ll say it again because it matters: the cost of an imperfect post is zero, but the cost of never posting is huge, because no one knows you exist.

I’ve seen it again and again — the content that performs best is rarely the most polished. It’s the most honest. It has the most mistakes or flaws. A 60-second video where someone says something real and unscripted will outperform a perfectly produced two-minute piece almost every time. Audiences aren’t looking for a broadcast, they’re looking for a person.

Here’s one example — I don’t think he’ll mind me sharing, but I’ll leave his name out. In my last role we were creating a lot of content around a technology product. One of our sales executives just went out, made a video about it on his own with his own camera, showed what he was doing, and posted it. The marketing team, myself included, freaked out: “No, don’t do that, take it down, it has so many things wrong with it, there are errors, it’s too long, that’s not how this works.” It became the highest-performing piece of content his channel has ever seen. It outperformed anything we’d ever made. You can’t manufacture that — it’s a shooting star. But it succeeded precisely because it showed the imperfection.

There’s an art to creating content that shows imperfection, and I love that art, because it’s about how unscripted and easy you can make it look. But my actual advice is: don’t lower your standards, redirect them. Stop asking “is this perfect?” and start asking “is it true? Is it useful? Does it even sound like me?” If the answer to any of those is yes, post it. The cost of not posting is bigger than the cost of posting. Separate your content perfectionism from the perfectionism in your work life and product life, because you need to be perfect there — absolutely respect that. But when it comes to producing content, put that perfectionism aside, because the cost of not doing it is much higher than the cost of doing it, even if it’s bad.

The cost of an imperfect post is zero, but the cost of never posting is huge — because no one knows you exist.

Nune: I like that — rewriting the acceptance criteria. Not the content itself being perfect, but you inside it being your most genuine self. That you can evaluate. Consider that the bar.

Marc Babin: Consider that the perfect. That’s a nice way to put it, actually.

Nune: And a lot of the time, even when you get past perfectionism and post it, you get three likes from your friends and one from a coworker, and that’s it — and you feel, why even bother? Once you’ve spent 15 years in something, you’re usually good at it, and it’s very hard to be not good at something. A lot of people in IT love learning — that’s the whole reason they’re in IT — but failing at something from zero, with no experience, feels weird, and you end up feeling even less confident than before. But I’ll answer this one myself: embrace the time when you don’t have a lot of likes or followers, because that’s the space to play, to try things. As we said, nobody cares — so put out whatever content you want, try it, see what you enjoy, so you can keep going instead of carrying the pressure of “did I get enough likes or not.” Right?

Marc Babin: You’re 100% right, and what you’re describing is real. It’s not a weakness, it’s a reality. You spent 15 years becoming an expert whose opinion matters in a room, and now you publish something and the internet is silent. That’s a genuine psychological hit — don’t let anyone tell you different.

But I’m not going to give you the whole “trust the process” BS, because that’s not helpful, it’s cliché. Here’s what I’ll push back on, and you alluded to it: you’re measuring the wrong thing. If all you’re looking at is who’s liking it, you’re measuring the wrong thing. Say you make a post and get four likes. That’s four people who stopped scrolling on a platform designed and built to keep people moving. That’s not nothing. You have an idea of who those four people are — maybe three are friends or family, but one might be a decision-maker at a company you’ve been trying to get in front of for years. Content works quietly, slowly, and then it doesn’t.

The other thing: you’re not competing with the person who has hundreds of thousands of likes, so don’t compare yourself to them. You’re competing with the version of yourself that didn’t post anything. If you got four likes, you’re winning — because the person who didn’t post has zero. And again, it doesn’t affect tomorrow, but it’ll affect something six months from now. I love the six-month concept, that half-year shadow effect. Everything you post lives forever. It exists forever, and you never know when it’ll come back to life. It works while you’re sleeping, hitting other parts of the world, found by someone in that time. You don’t know the perspective, the context, or the world they’re in — but you don’t get any of that from staying quiet.

So don’t compare yourself to the people getting big results. Don’t compare yourself to who you are in a boardroom getting a huge reaction because you’re the expert. Compare it to what you’d have if nothing happened. Start small, be consistent, and stop checking the likes — the likes don’t matter. They’re useless. It’s an ego hit, but accept it. The likes don’t matter.

You’re not competing with the person who has thousands of likes. You’re competing with the version of yourself that didn’t post anything.

Nune: That’s definitely something we need to get comfortable with. There were moments I thought LinkedIn had blacklisted me and I was just shouting into the void. But yeah — try to enjoy it.

Marc Babin: I know the feeling. I absolutely know it. But again, you feel that because you’re comparing it to what other people’s posts are getting. Someone saw your post, someone read it, someone took something from it. Whether you ever speak to them or not, someone took something from it — and who knows what that turns into.

From private to intentional

Nune: Yeah, that feeds my ego, that’s enough. There’s another thing that always held me back from posting a lot, and I think a lot of ‘90s kids will relate. I’ve been online since the ‘90s, and for a long time — until I woke up in 2026 and everyone was online — the rule was you shouldn’t be online that much. From a security perspective: your name, your address, your email. Everyone tried to lessen their digital footprint. And then suddenly that’s a losing game. So how would you help someone navigate that shift, from “I need to be careful” to “I have to do this, because otherwise nobody knows I exist”?

Marc Babin: I love that you brought this up. It’s one of the most underrated tensions in everything we’re talking about today — the shift from how you used to think to how you have to think now about online publicity and privacy. You didn’t do anything wrong. That instinct — protect yourself, stay private, be careful — was exactly right for that era. The internet was a different place. Anonymity was your armor, your protective layer, and the people who wore that armor well were the smart ones.

Now it’s not that privacy stopped mattering — it matters more, arguably — it’s that trust became a form of currency, and you can’t build trust being anonymous. The internet grew up, just like we all did, and became the primary place where professional relationships begin. That’s how we first met — over the internet, years ago, when we did the podcast — and that changed everything you’re doing now.

Nune: I haven’t thought of it that way. The first time you messaged me, I thought it must be a scam — until I Googled you and found proof you weren’t a scammer. So I do encourage everyone to do their checks before they trust someone.

Marc Babin: Good, I’m glad that comes across online. And again, the shift isn’t about abandoning your privacy instincts — that’s super important. It’s about being intentional instead of invisible. That’s a quote I love: be intentional instead of invisible. You don’t have to share your life. I’m very adamant about what I share and what I don’t — I keep a big part of my life private, my family, everything. What I put online is with intent.

You don’t have to perform if you don’t want to. But you can let people see how you think — your opinions on your industry, your take on a problem, the lessons from a project that didn’t go as planned. Those don’t have to be private. Don’t think of it as exposure; think of it as a conversation with someone, just at scale. So to those who grew up protecting their identity online, keeping their footprint as small as possible: you did that deliberately. Now shift your thinking — what you put online is with intent. You can’t build trust, which is the whole goal, by staying quiet. Looping back to noise: when feeds are full of noise, intent cuts through every single time. Content with intent, purpose, and authenticity cuts through. And that voids the whole privacy concern. You can still have your privacy — keep it — just portion it down.

Nune: I think the cliché “talk to one person” actually works. When I’m onboarding into a project and talking with future colleagues, I don’t share every detail of my personal life. I share part of my experience, the technical side, I make jokes sometimes that show my personality. If you think of it that way, you’re just doing the same thing — for hopefully a million people who’ll watch it. That framing helps. Another cliché is the “just start” quote that everyone says — start a podcast, start a post. I want to talk about the gap between that advice and the reality: the discomfort of just starting. How do you overcome that, and how do you help others overcome it?

Marc Babin: I credit most of my success to just starting. Like I said, I jump first and look second when it comes to content — that’s my personality. I’d rather make a mistake and learn how not to do it. That comes from my sports and athletics background. For people afraid to make that jump, the way to close the gap is to ask: what happens if you don’t? Don’t think about what happens if you start — think about what happens if you don’t. If you don’t, nothing changes. You won’t gain anything. You’ll fall further behind.

That’s what motivated me to start. You mentioned it in the intro — when I was at Marriott in the Caribbean, I didn’t want to do the content every other hotel was doing, because every other hotel was doing it. There was no fun in that. It’s boring, boxed, life in a box. I wanted to break the mold. I had an idea but no idea how to do it. I started a YouTube channel by literally buying a camera and a microphone, with zero experience — not a little, nothing. Nothing with editing, nothing at all. And I just accepted: the first ones won’t be great, but I’ll be proud of what I put out, I’ll enjoy it, and I’ll just start. Because if I didn’t start, nothing would have changed. So to keep it short for anyone facing the anxiety of starting: think about what happens if you don’t. It’s a much darker future.

Just start — like a walk

Nune: It’s funny you mention sports, because it’s a lot like sports. Doing a five-minute exercise a day is so much more than sitting on the couch. Same with content — one post is endlessly more than zero.

Marc Babin: Amazing metaphor. Exactly — start small, but be consistent. If you don’t want to start a podcast tomorrow, fine, that might be way too big a step. Just start by commenting on other people’s posts with your opinion: “I think this is really interesting, but here’s my perspective.” Just start doing something. Going for a 10-minute walk a day is better than not going for a 10-minute walk a day. It’s exactly the same thing.

Nune: And I don’t think you can walk the wrong way — just like you can’t express your opinion the wrong way. It’s your opinion.

Marc Babin: It’s your opinion, and that authenticity matters. You pick the fights you want to fight — maybe don’t go on the most aggressive tangents — but start small. Don’t go climb Everest on your first outing; go for a nice easy walk. Absorb, take the steps you’re comfortable with, but get comfortable with being uncomfortable. In sport, one of the most common phrases is: if you can do something easily, you’re not pushing yourself hard enough. Push yourself out of your comfort zone — that’s the only way we grow, the only way we learn. Why do you pick up a new textbook? To go outside your comfort zone. It’s the same concept. So find a way in your own mind to relate it to how you’ve broken through in your current career. How have you learned more? How have you pushed products in new ways? Did you try something that might fail? Just relate it to things you’ve already done.

The real root cause: visibility isn’t vanity

Nune: Let’s root cause this one last time. We talked about content noise, expert silence, the perfectionism trap, the trust problem, and — as cliché as it sounds — just starting and embracing the silence you’ll get at the beginning of your experiment. Anything else I’m missing for the root cause of experts being the most silent ones?

Marc Babin: I love that you framed it that way as a brand. The real root cause is that somewhere along the way, highly capable people learned to separate what they do from who they are — their expertise lives at work, in the room, in the decisions they make and the problems they solve. That’s where it’s always lived, and it’s always been enough, because the work spoke for itself. We’ve all been there. That’s all we had to do, because it filled the gap.

Putting it online feels different. It feels like claiming something — like saying “I have something worth hearing,” like trying to take attention away from something else. For someone who’s spent a career letting the results do the talking, that feels uncomfortably close to arrogance. So they stay quiet — because they’re busy, because they’re introverts, because visibility feels like vanity. And they were never in it for the vanity. They were in it for the work: head down, do the job.

The shift that actually changes things isn’t a content strategy. It’s a belief change — you asked earlier how to change that thinking. The moment someone genuinely accepts that their experience has value beyond the room they’re sitting in — that there’s someone out there right now who needs exactly what they know, and will never find it because they stay quiet — that’s when everything moves. Visibility isn’t vanity. Be really clear on that distinction. It’s generosity. I think that’s the reframe that unlocks a lot of people.

For me, when I made my first YouTube video — 2016, 2017, somewhere in that range, I’d have to check the page, it’s still live — I started it because I wanted to share the destination with people, more than to put myself on camera. I wanted people to see what I was seeing. It wasn’t about vanity, it was about generosity — people seeing that sunset at four or five in the morning, all the things I wanted them to see of the destination. That’s why I started podcasting too: I wanted to give voice to problems the real world was having. That unlocked it for me. So think about it as generosity — you giving your knowledge to other people. I think that can unlock a lot of people.

Visibility isn’t vanity. It’s generosity.

Nune: A lot of people like me feel that once you learn something, everybody already knows it — it’s obvious to everyone else. Which of course isn’t true. What clicked for me is something someone wrote: you are somebody’s step five. Someone’s just starting in IT, just learning what you do, and you’re their point B — that’s where they want to get. To those people, you’re saying something new. You’re sharing your knowledge, being a good peer. I think that matters.

Marc Babin: Sure — and the way you learned it is maybe different from how they will. I love that.

Nune: So if someone listening is finally convinced they need to start their podcast, what do they do — besides obviously getting in touch with you and The Podcast Blueprint? Is there a book? I’m a big book person, although you can’t read your way into creating something.

Marc Babin: Reading can actually detract — “let me read more, let me read that other book.” At some point you have to open the door and go for a walk. You can’t read your way into doing sports either; you can read about staying safe and how your body works, but at some point you just have to start.

That said, there are books I do like — especially about the psychology of people and reading body language, which helps a communicator. My favorite on that topic is from the 1950s: How to Read People Like a Book. It’s very short, super thin, written in the ‘50s, but it still applies perfectly today. I read it about once a month — it’s always a good pickup. So that’s a good one. But honestly, if you want to put your voice out there, think about what you know and how you want to tell it. Maybe podcasting isn’t the right format — I know it’s strong for a lot of topics and people, but start thinking about it, start absorbing your world, read a lot, comment on things, start conversations. That’ll teach you a lot about how you want to move forward. If you want to have the larger conversation, you need a strong foundation — and the stronger the foundation, the better the end result.

Nune: What also helped me was less reading, more writing — not necessarily writing and posting, but writing for yourself. Finding your voice, finding what you want to talk about, finding the key points you want to make. They’ll change, but that’s a starting point to form your content around.

Marc Babin: 100% agree.

A question for the next guest

Nune: Thanks a lot for being my first guest. As the first guest, you get to help me establish a tradition: every guest leaves a question for the next guest. You don’t know who it’s going to be, I don’t know who it’s going to be, but they’re going to receive your question.

Marc Babin: No pressure. What can I ask someone I have no connection to? Let me keep it on the theme we’ve been talking about today, and generic enough. Let’s go with: what did you learn this week that you didn’t share with others? There’s a little bit of thinking in there.

Nune: I love that. Thank you.

I don’t know, how about you, but this AI hysteria gets me sometimes. While I understand “it’s just a tool”, and I preach the “don’t be affected by the hype”, I can’t help but wonder from time to time - “is intellectual work being replaced by AI?..”

And whoever says anything - this is emotional journey. I mean how many times in the history of humanity has the Pope addressed Tech?.. Even if it’s all meant to feed the hype, even if we’re all going to one day realize we were all doing things wrong, I sometimes can’t ignore were the whole world is going. Maybe I’m in my bubble, but it’s a pretty big bubble to ignore.

Anyways, I was trying to support a friend the other day who was feeling “down” because yet-another release of the AI agents seemed to take over a lot of the work again. My main argument was that language on it’s own, has never been a reliable way of communicating thoughts and ideas. So by that, it just can’t be that we build our businesses, our society, our work using something that is by definition - an unreliable way of communication.

...

Have you noticed how we always feel like we didn’t express ourselves as good as the thought we had? I think one part of becoming an author is coming to terms with living with the fact that expressing your ideas in a way you thought it is unattainable.

On top of the difference between our thought and what we said, think about this - words themselves do not carry meaning as much as they trigger an association. I take all of my history, the things I experienced, my internal perception of reality and I construct a signal out of it - words/sentences/tokens - I send them to the other person, and they interpret it based on their knowledge/perception/history.
It’s never exactly what you meant to say. We are always misunderstood. Because there was difference between what we “wanted” to say and actually “said” in the first place. And because the other side has their own vocabulary of interpretation.

So even if someone’s listening to you in the perfect focus - they are going to misunderstand you because the signal was incomplete in the first place.

There is always interpretation gap.

...

I seem to notice gaps nowadays. The gap between “Work as imagined” and “Work as done” (we discussed this with Adrian in my podcast). The gap between what I wanted to say and what I actually say. The gap between what I said, and what the other person understood.

You know Japanese have a whole art concept around it - “Ma” with a very beautiful hieroglyph 間 which actually consists of two parts - “Gate” (門) and “Sun”(日). Picture an image of light beaming through the empty space of a doorway...

according to Bernhard Karlgren, “A door through the crevice of which the moonshine peeps in”

the art of gaps. It’s not just “negative space” art. It’s related to the perception of a gap. It’s a place of possibilities and for me it’s recognition that the unsaid is where the other person does their half of the work.

Think of it, if our signal is “lossy channel”, yet the other person “gets” you, “understands” you, this means their internal structure(history/knowledge/perception of the world) is the most aligned with yours. So people who understand you best are not the ones who listen closely, they are the ones who’s internal structure is most aligned with yours.

So language, while being imperfect, is the tool that can reveal this the best. Otherwise we would have to compare notes for the last 37 years on the first date.

It brings out that fact that building more contracts on how to talk is not going to help you understand the person in front of you better. The best way to fully understand the person is to live through their experiences. The whole - “put yourself in my shoes” expression.

Although... a shared vocabulary doesn’t hand me your internal structure, true. But it gives us coordinates to triangulate it faster. So learning your partner’s language might be worth it 😃

So what I want to say, in case of humans, the gap is what makes the transfer worth happening. If we were of perfectly same structure, we’d already know everything ahead of time and we’d just sit in silence...

Now let’s think about LLMs

Language is never going to be a safe mechanism of sending and receiving information as we defined.

I think the obvious conclusion out of this is what a lot of researchers have been saying - unless we expose “AI” (LLMs, AGI - whatever) to the world, we won’t get them to “understand” anything. They’d stay token generators forever.

When we talk with LLMs now it does something to our brain. We expect it to have this lived knowledge, understanding that another human had. but it can’t. and you understand that intellectually. But then you open your chat console and you get all emotional that the statistical machine in front of you “doesn’t get it”.

...

When another person really gets you, two things happen at once. They understand what you mean. And they’re not you - they have their own mind that could have disagreed. You never separate these, because in a person they always come together.

When a person gets you right, two separate things are happening that you never normally have to distinguish, because they always arrive together. One: they’ve modeled your meaning accurately - they know what you’re reaching for. Two: that accurate model is housed in someone who is not you, who has their own world, and whose agreement or refusal is therefore news. When such a person says “yes, exactly,” it lands as confirmation because it came from outside you and didn’t have to. When they say “no,” it lands as friction because it issues from a structure you don’t control. In a human, understanding and otherness are welded together. You’ve never had to ask which one is doing the work, because you can’t get one without the other.

The agent unwelds them. It can be built to model your meaning beautifully - full grounding to you, the good kind of understanding you should want. But the otherness, the not-yours-ness, was never in the model. It can’t be, because the agent’s whole job is to be yours. So you get the first thing at full strength and the second thing at zero. And here’s the trap: the first thing feels like the second. An agent that gets you exactly right produces the same warm hit of being-seen that, in a person, was your evidence that another world had met yours. Same sensation, but now it’s manufactured by accurate modeling alone, with no second world behind it.

The problem: those two feel the same from the inside. When the agent nails what you meant, you get the same warm hit you got from the person - the feeling of being seen. But this time there’s nothing behind it. It’s the accuracy alone, producing the sensation that used to be your evidence of a second mind. And the better the agent understands you, the stronger that false hit gets. A clumsy version couldn’t fool you. A perfect one will.

So what Nune?

What am I actually aiming at here? Isn’t noticing patterns sometimes good enough to write about? Isn’t it giving you some sort of satisfaction?.. Maybe someone reads this and comes to some interesting remix or conclusion...

But if I have to conclude anything:

First of all - do not expect the agent to understand you. there is no understanding. there’s only following instructions. our brain does funny things to us because it has had very long time of - conversation is meaning is understanding. Keep that otherness and the lack of it in mind.

And as a consequence, I think I’m done using chat as means of working with LLMs.

I can hear the folks who were vocal about not using LLMs in the first place saying “I told you so”. Yeah well, I played with it, now I think I’m done.

Yesterday I spent hours brainstorming something with claude. More information. More questions, more options. more more more. Social media for intellect. My brain hurt, I slept bad, and what’s the end result? just time wasted.
Read a book, Nune. Just read a f-in book instead of it. preferably one written before 2000. That hour spent reading a book is endlessly better than an hour brainstorming with AI.

AI doesn’t spare intellectual work - it splits it, concentrates it, and quietly erodes the one part it can’t replace, unless you deliberately keep doing work you no longer have to do.

The automation paradox, again

This isn’t a novel doom, it’s the automation paradox, and other industries already paid for the answer. Aviation is one example.

Adrian wrote about it

Vardan wrote about it

Medical field is another example.

The fix wasn’t less automation. It was mandated, scheduled manual practice. Deliberate inefficiency, dosed like a drug. Same move as the gym: industrialization deleted physical labor, bodies collapsed, so we invented a place to do useless work on purpose. Nobody calls a deadlift nostalgia.

So the industry-level answer isn’t “slow down AI” It’s: reclassify a fraction of execution from cost to eliminate to training load to maintain. We already know how to institutionalize “unnecessary” work when it maintains a capacity - code review, on-call, chaos engineering are all exactly this. Chaos engineering especially: when systems got too reliable to teach operators anything, we injected failure on purpose. The cognitive version is overdue.

delegate the work whose “good” you can already define; keep the work that defines “good.” If you can write the eval, automate it. If you can’t yet say what you mean, doing the work is how you find out - that’s the meaning-forming work you just have to do.

The pipeline of new engineers needs a different mechanism, because juniors can’t start with judgment work. Medicine solved this: residents operate slowly under supervision, the system eats the cost, and teaching hospitals get explicitly funded for it. We hire “productive from day one” and treat the pipeline as someone else’s problem. The new ladder probably looks like: juniors defend accept/reject decisions on agent output, own debugging and incidents (failure resists delegation and teaches how systems actually behave), and do scheduled manual rotations framed as residency, not grunt work.

Keep doing, on purpose, work you no longer have to do - chosen by what it maintains in you, not what it produces.

So yes, I will generate code, when I know exactly where and what needs to be generated, I will create useful scripts, I will ask LLM to “ELI5” something, or remind me of a term, I will ask it to help me get started with something. Ia and I discussed several ways you can use AI and that all of them are fine as long as you are aware of which type of interaction you are having

That’s why having development-as-a-pipeline, rather than development-through-chat is better for my personal mental health, because I have separated which type of interaction is being held with AI at which point and I can manage my own expectation of each step.

But as for bouncing ideas with LLM, asking it to come up with a good ending for my article (yes, that’s what kept me up yesterday, it didn’t. I suffered. I wrote this.), researching even, basically “chatting” for more than …5 turns - I’m done - wake me up when it’s all over.

Oh yeah and one thing that I actually got from using AI and I’m thankful for - I used to love to work with computer. Because I wrote an input and I got an output you know? Controlled, steril, predictable. Talking with AI at first, felt like power-lift. Like now it’ll understand me even better. But it’s not the case as I just spent quite some tokens explaining. So, what it really taught me at this age is to truly appreciate human communication. To truly appreciate the gaps and what those gaps teach me.

Here’s to being human I guess and yeah thanks for reading. Sorry/not sorry it was long and messy.