Feedback loops, while extremely important, aren't a new or revolutionary concept.

They simply refer to doing something, seeing what happened, and using that to decide what to do next.

Modern software practice is mostly about tightening those loops so we find out “did this work?” as soon as possible.

Feedback is the actual job

If you look at a normal software project, it’s a pile of feedback loops.

• You talk to users, ship a small change, watch what they do, and that turns into the next backlog item.
• You push a branch, and automation answers back with green or red: build, tests, lint, security checks, deploy checks.
• Once it’s live, metrics and alerts tell you when reality disagrees with your mental model.

Underneath all of this, the job is: make an assumption, compare it with reality, adjust.

Short loops hurt less

Here’s the thing: the sooner you find out something is broken, the cheaper it is to fix

Fixing a bug while the code is still fresh in your head is trivial. However, fixing the same bug when it shows up as a failed deployment or a 3 a.m. production issue is not.

That’s why fast tests, hot reload, linters in the editor, pre‑commit hooks, and throwaway environments feel so good: they pull the loop closer to your keyboard.

CI/CD is just that idea scaled up: an automated “did this really work?” loop from commit to production.

If you’ve ever rebuilt a big app and clicked through the whole UI by hand for every change, you know exactly what a bad loop feels like.

Agents need the same thing

Now add LLMs. The basic rule doesn’t change.

Agentic systems are built as loops: see the state, decide, act, see what changed, decide again.

Some setups split this across roles (sub-agent driven development anyone?) i.e., one agent writes code, another writes tests, a third runs them, and reports back. That way the same model isn’t both writing the exam and grading it.

The pattern that actually works is straightforward: the agent doesn’t just spit out code and stop. It runs the code, reads the errors, and keeps going until there’s some evidence the change did what you asked. That looks a lot like TDD, just with a machine doing more of the typing.

Doing vs. judging

One important line to draw: the agent’s inner loop and the system’s “is this good enough?” loop should not be the same thing.

Inside the model it’s all pattern matching and probability. Validation should be boring and repeatable: static analysis, tests, security scans, quality gates. Tools like linters, SonarQube, SAST, and dependency scanners already do this for human‑written code.

So let the agent propose changes, but let CI and runtime checks be the judge. If your “judge” is just another call to the same model with a different prompt, you don’t really have a guardrail.

Make agents burn their own cycles

Inside those hard boundaries, you actually want agents to argue with themselves a bit.

A common shape is: generate → evaluate → critique → revise.

In practice that can be separate agents: one writes code, one scores it against a rubric, one explains what went wrong so the first can fix it.

Most bad outputs should die in that inner loop. The goal is to avoid making a human act as the feedback loop by dragging logs and screenshots back into the prompt every time.

Keep loops close to where code is written

Last point: where the loop closes matters.

Bugs you can reproduce locally are cheap. Bugs that only show up in CI or production get expensive fast.

That’s why “shift left” testing, decent local tooling, and realistic dev environments are worth the setup cost. Stories from DevOps and the data both say the same thing: teams with short feedback loops and low lead times tend to ship more and suffer less.

For agentic systems, its the same rule. Close the loop on a laptop, in a dev container, or in a cheap sandbox environment when you can. Then let CI and production monitoring enforce the non‑negotiable checks.

That’s really the whole argument: we already know tight feedback loops are what make human engineers effective.

Agentic coding just gives us more loops to design, and more chances to get them right (or wrong).

References

• Feedback Loop Engineering - Daniel Demmel: If you review no other reference, read this one.
• Feedback Loop - Tomorrow Desk
• Feedback Loops in Software Development - BrainHub
• Feedback Loops - PostHog
• Feedback Loops - Complex Systems Frameworks
• Feedback Loops are a Pre-Requisite for Continuous Improvement
• CI/CD Feedback Loops Best Practices - Hokstad Consulting
• CI/CD DevOps Pipeline - Splunk
• Feedback Loops - Splunk
• Feedback Loops What makes ai coding agents actually useful - profiq
• Implementing Feedback Loops - dev
• Feedback Loops Background Coding Agents - Spotify - Honk, Honk