Another title might be something like “Stop Fixing Bugs. Start Fixing Systems: Why Every Engineer Should Teach Their AI Agents to Think in Systems” – Anyway, let’s jump into it.
We’ve spent decades teaching engineers how to write better code, design better architectures, and ship software faster.
Now we’re entering a new era: AI agents can write code, review pull requests, investigate incidents, run tests, and even operate parts of our infrastructure.

But there’s a problem.

If we give our agents the same narrow instructions we give ourselves—fix this bug, implement this ticket, optimize this function—we’re simply automating the way we’ve always worked.
And maybe that’s not good enough.

I recently revisited “Thinking in Systems” by Donella Meadows, and one idea really stuck with me:

Most problems aren’t caused by individual components.
They’re caused by the way the system is structured.

I think this is one of the most important ideas every software engineer should understand today—and, more importantly, teach their AI agents to apply.

1. Stop treating symptoms. Understand the system.

Think about some familiar engineering problems:

• Deployments keep breaking.
• The same production incidents happen repeatedly.
• Pull requests sit in review for days.
• Technical debt keeps growing.
• Estimates are consistently wrong.
• A few senior engineers become bottlenecks for everything.

Our natural reaction is to fix the immediate problem. Another hotfix. Another meeting. Another engineer. Another process. Another dashboard.
But what if we’re fixing the wrong thing?

A flaky deployment might not be a deployment problem. It might be the result of poor test isolation, missing observability, unclear ownership, or delayed feedback from production. A slow engineering team might not need more developers. It might need smaller PRs, faster CI, clearer ownership, or fewer dependencies between teams.

The important shift is this:
Don’t ask only what went wrong. Ask what about the system made this outcome likely?

And this is exactly the kind of question we should start asking our AI agents.
Instead of asking an agent to fix a failing deployment, ask it to investigate the entire deployment lifecycle, identify recurring failure patterns, map dependencies, and recommend structural improvements. Don’t just ask it to write code. Ask it to understand why the code needs to change.

2. Understand stocks, not just flows

One of Meadows’ most useful concepts is the distinction between stocks and flows.
I wrote about a similar concepts in the past: https://greenido.dev/2025/09/25/scaling-engineering-teams-lessons-from-google-facebook-and-netflix/

In software engineering, we tend to measure flows:

• How many tickets did we close?
• How many PRs did we merge?
• How many features did we ship?
• How many deployments did we complete?

These metrics tell us how fast we’re moving. But they don’t necessarily tell us whether we’re getting healthier.

Consider the stocks:

• Accumulated technical debt.
• Open production incidents.
• Age of the PR review queue.
• Number of unresolved security findings.
• Operational burden on the on-call team.
• Backlog of known but unfixed reliability issues.

A team can ship 50 PRs this week while quietly accumulating a much larger maintenance problem.
The flow looks healthy. The stock is deteriorating.

What should we do with our agents?

Ask them to monitor both. For example, an engineering agent could:

1. Track open technical debt items over time.
2. Identify areas where new code consistently increases complexity.
3. Detect PRs that remain in review longer than expected.
4. Correlate recurring incidents with recently introduced changes.
5. Generate a weekly engineering health report.

The goal isn’t another dashboard. The goal is to give agents enough context to identify when today’s productivity is creating tomorrow’s problems.

3. Feedback loops are everything

Systems are driven by feedback loops.
Some loops stabilize a system. Others accelerate problems.
Consider a classic engineering example:

1. Technical debt slows down development.
2. Slower development creates pressure to ship faster.
3. Engineers take shortcuts.
4. More shortcuts create more technical debt.
5. Development gets even slower.

This is a reinforcing loop.
It doesn’t necessarily start with bad engineers or bad decisions. It starts with a system that rewards short-term delivery at the expense of long-term health.
Now consider feedback delays.

A developer commits code. CI takes 40 minutes. The deployment happens hours later. The first meaningful production signal arrives the following day. By then, the context is gone, and the cost of investigating the problem is much higher. The longer the feedback loop, the harder it becomes to learn and correct course.

This is where AI agents can make a meaningful difference.

Imagine agents that:

• Review code immediately after every commit.
• Identify risky changes before they reach production.
• Run targeted tests based on the actual code changes.
• Monitor production signals after deployment.
• Connect incidents to the PRs, commits, and architectural decisions that preceded them.
• Automatically open follow-up tickets when they identify systemic problems.

Instead of waiting for humans to discover that something is broken, we’re building a system that continuously learns from its own behavior. That’s a very different way of engineering.

4. Watch out for the traps

Meadows describes several recurring patterns in systems. Software engineering has plenty of them.

Shifting the burden
A production issue appears. Someone applies a hotfix. The service recovers.
Everyone moves on.
But the underlying architectural problem remains, and the next incident becomes more likely. Teach your agent that every hotfix should trigger a root-cause investigation and a follow-up task. Don’t let it confuse restoring service with solving the problem.

Drift to low performance
A test fails occasionally. Everyone knows about it. Eventually, people stop paying attention. The team gradually accepts a lower standard. Teach your agents to track flaky tests, identify recurring failures, and distinguish genuine regressions from known instability. Don’t let “it’s always been like that” become an acceptable engineering standard.

Wrong goals
A team optimizes for story points, PR count, code coverage, or lines of code. The numbers improve, but the product doesn’t necessarily get better. Teach your agents to evaluate outcomes: reliability, maintainability, security, customer impact, and time to recovery.

Success to the successful
The same senior engineers receive the most important tasks because they’re the most experienced. They become even more experienced, while everyone else gets fewer opportunities to grow. Agents can help distribute knowledge by documenting decisions, explaining unfamiliar code, preparing implementation plans, and helping engineers tackle areas they haven’t worked on before.

The objective isn’t to replace senior engineers. It’s to reduce the organizational dependency on a handful of people.

5. Leverage points: Change the rules, not just the numbers

Perhaps the most important concept in Meadows’ book is leverage.
Not all changes have the same impact.

Changing a sprint from two weeks to one week (or six weeks, like we did) is a relatively small intervention.
Changing how information flows through the engineering organization can have a much bigger impact.
Changing the incentives that determine what engineers optimize for can have an even bigger one.

For example:

• Instead of asking engineers to close more tickets, reward the elimination of recurring problems. Easy to say and a bit harder to do.
• Instead of measuring how many tests exist, measure how quickly the team detects meaningful regressions.
• Instead of relying on senior engineers to review everything, build automated review systems and distribute architectural knowledge.
• Instead of treating incidents as isolated events, connect them to recurring architectural patterns.

And here’s the interesting part:
We can encode many of these principles directly into our AI agents. (e.g. DORA metrics)
We should stop thinking about agents as disposable coding assistants and start treating them as participants in our engineering system.

6. Every engineer should build their own systems-thinking agents

This is where I believe the opportunity gets really interesting. You don’t need to be an engineering manager or an architect to apply systems thinking. Every developer can take these ideas and translate them into agent instructions, tools, and workflows.
Whether you’re using Cursor, Claude Code, Codex, or another AI development environment, consider giving your agents a broader mission.

For example:

Agent #1: The Systems Architect

Don’t just review individual files. Understand the broader architecture.

Ask it to:

• Map dependencies between services and components.
• Identify architectural bottlenecks and single points of failure.
• Detect duplicated logic and unnecessary coupling.
• Identify changes that solve symptoms rather than root causes.
• Recommend improvements based on long-term maintainability.

Agent #2: The Reliability Engineer

Its job isn’t simply to fix failing tests.

Ask it to:

• Analyze incident history.
• Identify recurring failure patterns.
• Monitor flaky tests and unstable deployments.
• Connect production incidents to code changes.
• Propose changes that prevent entire classes of failures.

Agent #3: The Technical Debt Watchdog

Give it a long-term view of the codebase.

Ask it to:

• Track complexity and architectural drift.
• Identify areas where technical debt is accumulating.
• Detect shortcuts that introduce future maintenance costs.
• Prioritize debt based on its actual impact on delivery and reliability.
• Suggest small, continuous improvements instead of massive rewrites.

Agent #4: The Engineering Process Optimizer

This agent looks beyond code.

Ask it to:

• Analyze PR review times and bottlenecks.
• Identify dependencies that repeatedly delay delivery.
• Detect overloaded engineers and knowledge silos.
• Evaluate whether team metrics encourage the right behavior.
• Recommend changes to processes and information flows.

Agent #5: The Continuous Learning Agent

Perhaps the most interesting one.

Every time something goes wrong, this agent asks:

• What happened?
• Why did it happen?
• Which system behavior made it possible?
• Have we seen this pattern before?
• What should change so this doesn’t happen again?

It should turn incidents, code reviews, and production feedback into organizational learning.
These don’t necessarily need to be five separate agents. They can be different roles, skills, or workflows within one agent environment. The important thing is that each agent has a systems-level responsibility, not just a collection of coding tasks.

7. A practical challenge: Start this week

You don’t need a company-wide initiative to get started. Pick one recurring engineering problem that frustrates you. It could be flaky tests, slow builds, recurring bugs, deployment failures, or a component nobody wants to touch.

Then try this:

Step 1: Ask your agent to investigate, not fix.
Give it access to the relevant code, logs, incidents, PR history, and documentation.
Ask it to identify the underlying system structure and explain the feedback loops that produce the problem.

Step 2: Ask it to distinguish symptoms from root causes.
Don’t accept the first obvious explanation. Ask it to identify alternative explanations and support its conclusions with evidence.

Step 3: Ask for structural improvements.
Don’t ask for another patch. Ask what changes to architecture, ownership, automation, information flow, or engineering rules would reduce the likelihood of the problem recurring.

Step 4: Implement one improvement.
Keep it small. Make it measurable.

Step 5: Close the feedback loop.
Have your agent monitor the relevant signals and report whether the change actually improved the system.
Repeat.
That’s systems thinking in practice.

---

The bigger picture

We’re entering a period where the cost of producing code is dropping dramatically. That means the competitive advantage won’t simply belong to the engineers who can write code fastest. It will increasingly belong to engineers who understand the systems they’re building, recognize the feedback loops that shape them, and know how to use AI agents to continuously improve those systems.

Donella Meadows wrote Thinking in Systems long before AI agents existed in its current form.
But the principles are arguably more relevant now than ever.

My takeaway is simple:

Don’t just teach your agents how to write code. Teach them how to understand the system, challenge its assumptions, identify its weaknesses, and make it better.
Be bold and ask for high(er) bar.

The best engineer of the future might not be the one who writes the most code.
It might be the one who builds the best system of humans, software, and agents working together. And you can start building that system today.

— Inspired by Donella Meadows’ “Thinking in Systems”