# The IDE Became the Exception: How I Shifted to Building Loops Instead of Code

After 16 years building financial-grade systems on AWS, I realized my job changed: I no longer design code line by line, I design loops — triggers, topologies, verifiers, and stop-rules. The IDE still exists on my workbench, but less and less. This post is the honest record of that transition.

- URL: https://fernando.moretes.com/blog/ide-virou-excecao-loop-engineering-nos-meus-agentes

- Markdown: https://fernando.moretes.com/blog/ide-virou-excecao-loop-engineering-nos-meus-agentes/article.md?lang=en

- Published: 2026-06-29T21:51:42.967Z

- Category: AI & Agents

- Tags: loop-engineering, ai-agents, aws-bedrock, eventbridge, prompt-engineering, serverless, agentic-ai, developer-productivity

- Reading time: 5 min

- Source: [Loop Engineering (architecture study)](https://fernando.moretes.com/studies/loop-engineering-agentes-de-ia)

---

Six months ago, I opened my IDE every single day. Today I open it a few times a week — and when I do, it's because something genuinely demands my attention: a gnarly concurrency bug, a greenfield design decision, a security review I won't delegate. What changed wasn't the tool. It was the level of abstraction where I operate. I stopped writing code and started designing loops. The agents write and run the code. I design what makes them work: the trigger, the topology, the verifier, the stop-rule. This isn't hype — it's what's running in production right now, generating the articles on this site as you read.

## The Shift: From Prompt Engineering to Loop Engineering

For years, the job of anyone using AI was to write better prompts. More context, more examples, better formatting. The bottleneck was the **right word in the right place**. That still matters, but it stopped being the main work.

In June 2026, Addy Osmani named what many of us already felt: **loop engineering**. Boris Cherny was even more direct: my job now is to write the loops that drive Claude. Not the prompt inside the loop — the loop itself.

What is an agent loop, concretely? It's a cycle with four elements you design explicitly:

- **Trigger**: what starts the cycle (a cron, an event, an HTTP call, another agent)
- **Topology**: how many agents, in what order, with what tools
- **Verifier**: what decides if the output is good enough to advance
- **Stop-rule**: what decides the loop is done — by success, by timeout, by budget

When the bottleneck was the prompt, I lived in the text editor. When the bottleneck is the loop, I live at the whiteboard and in EventBridge YAML. The IDE became the exception — not the default environment.

## The Loops Running in Production Right Now

- **Daily bilingual article generation**: EventBridge fires a Lambda that calls Bedrock AgentCore Web Search for grounding. If the search fails, the agent automatically falls back to source-text grounding — the article ships regardless. The loop has a quality verifier and abort-on-timeout.
- **Books and studies chapter by chapter**: no single call holds the whole book. Each chapter is a sub-loop with its own cache. If the process restarts, already-generated chapters are skipped. Retry-with-attempts + circuit breaker ensure one bad chapter doesn't sink the whole book.
- **02:00 voice-audio cron — idempotent by design**: the voice generation loop runs GPU-first; if no GPU is available, it falls back to Mac. State is an S3 pointer — no in-memory state. A re-run resumes where it left off. Idempotency isn't a feature, it's architecture.
- **Keepalive loop engineered live**: a long render inside a short execution window. I designed a heartbeat that keeps the process alive — a small but real lesson in triggers and stop-rules: without the right stop-rule, the keepalive becomes an infinite loop.
- **The `/loop` pattern**: two modes I use depending on context. Self-paced: the model picks the cadence — good for exploratory tasks where depth matters more than time. Fixed-interval: the loop fires at fixed intervals — good for predictable pipelines where SLA matters.

## The Agent Loop Factory

Every loop I run follows this topology: an external trigger fires the cycle, the agent reasons/acts/observes in sub-loops, a verifier decides whether to advance or iterate, and a stop-rule (budget + timeout + human gate) decides when to stop.

### ⏰ Triggers — Event Sources

- EventBridge Scheduled Rule (messaging)
- S3 / API GW Event Trigger (messaging)

### 🤖 AWS Bedrock — Agent Loop

- Lambda Loop Orchestrator (compute)
- Bedrock Reason / Plan (ai)
- AgentCore Web Search / Tools (ai)
- Tool Output Observe / Parse (compute)

### ✅ Control — Verifier + Stop-Rules

- Verifier Lambda Quality Gate (security)
- Budget Guard Token + Time Limit (security)
- Human Gate (async approval) (user)

### 💾 State + Output — Storage

- S3 Cache Chapter / Audio Ptr (storage)
- S3 / DynamoDB Final Output (storage)

### Flows

- cron -> orchestrator: fires
- event -> orchestrator: fires
- orchestrator -> reason: start cycle
- reason -> act: use tools
- act -> observe: return result
- observe -> reason: iterate (sub-loop)
- observe -> verifier: candidate output
- verifier -> orchestrator: failed → retry
- verifier -> budget: passed → check budget
- budget -> human: optional gate
- budget -> output: done → persist
- orchestrator -> cache: read/write state

## My Playbook: How I Put a Loop into Production

1. **1. Define the trigger before any prompt** — What starts the loop? A cron? An S3 event? A human call? The trigger defines the input contract. Without a clear trigger, the loop has no boundary.

2. **2. Design the topology on the whiteboard** — How many agents? Sequential or parallel? Which tools does each one have access to? I draw this before writing a single line of YAML. The wrong topology is expensive to refactor.

3. **3. Write the verifier before the agent** — The verifier is what decides if the output is good enough. I write it first because it forces clarity on the success criterion — something many loops skip and then pay for with infinite loops or silently wrong outputs.

4. **4. Define stop-rules explicitly: timeout, budget, attempts** — Every loop has three stop-rules: a time timeout (the loop can't last more than X), a token/cost budget (I can't spend more than Y per execution), and a maximum attempts count (retry-with-attempts, not retry-forever). Without all three, the loop is an operational risk.

5. **5. Make state external and idempotent from the start** — In-memory state is the enemy of resilience. I use S3 as a state pointer — what has been generated, what remains. A re-run doesn't start from scratch; it reads the pointer and continues. This matters more than any prompt optimization.

6. **6. Add the human gate as an optional stop-rule, not an afterthought** — For loops that produce consequential outputs (publishing, sending, deploying), I design an async human approval point. It's not bureaucracy — it's the difference between an autonomous loop and an irresponsible one.

## When I Still Open the IDE — Credibility Above All

It would be dishonest to say I never open the IDE. I do. And when I do, it's because the problem demands it.

**Gnarly concurrency debugging**: when an agent loop is producing non-deterministic results I can't reproduce from logs, I need the real debugger. Breakpoints, state inspection, full stack trace. The agent doesn't give me that.

**High-consequence greenfield design**: when I'm designing a new financial system from scratch — where a wrong topology decision costs months — I sit with the IDE, the diagrams, and the documentation. I don't delegate that structural reasoning to an agent without dense supervision.

**Security review on critical code**: authentication, authorization, cryptography, secrets handling. I read agent-generated code line by line. The IDE is where I do that review seriously — with a clear diff, with history, with annotations.

The IDE didn't disappear from my workbench. It changed roles: from default environment to precision instrument. I use it when the task demands surgical precision — not as reflex, but as deliberate choice.

> I stopped asking 'how do I write this code?' and started asking 'what loop reliably produces this result?' That change of question changed everything.
> — Fernando F. Azevedo

## Loops Gone Wrong — Field Lessons

- **Loop without a time stop-rule**: a chapter generator without a timeout ran for 47 minutes on a corrupted chapter, burning tokens and blocking the entire pipeline. The stop-rule is not optional.
- **Verifier that always passes**: a verifier that only checked if the output was non-empty let hallucinated content through for three executions before I noticed. A verifier without a real criterion is worse than no verifier — it gives false confidence.
- **In-memory state in Lambda**: a loop that stored progress in a Lambda instance variable worked perfectly in development and lost all state on the first production cold start. S3 as a state pointer isn't over-engineering — it's the minimum.
- **Single-agent topology for a long task**: I tried generating an entire book in a single agent call. Timeout, unpredictable cost, and inconsistent output. The fix was the per-chapter sub-loop with cache. Loop granularity matters as much as function granularity.
- **Retry without circuit breaker**: a retry loop without an attempt limit against a rate-limited external tool accidentally became a self-inflicted DDoS against my own API. Retry-with-attempts + exponential backoff + abort aren't paranoia — they're basic engineering.

> **My Honest Read of This Moment:** Loop engineering isn't the end of software engineering — it's a layer above it. The fundamentals still matter: idempotency, circuit breakers, observability, security. What changed is where you spend your design time. If you're still optimizing prompts without thinking about the loop that wraps them, you're solving the wrong problem. The bottleneck moved. The question is: did you move with it?

## Verdict: The Work Moved Up a Level

Loop engineering is real, it's in production, and it's changing what it means to be a software architect. It's not about not using the IDE — it's about using it when it's the right instrument, not as a reflex. My job today is designing the systems that make agents work reliably: triggers that fire at the right time, topologies that scale, verifiers that actually verify, stop-rules that protect the system from itself. The agents write the code. I design what makes them work. That division of labor, done well, is the most productive thing I've done in 16 years.

**Rating:** paradigm shift — in production

## References

- [Addy Osmani — Loop Engineering (June 2026)](https://addyosmani.com/blog/loop-engineering/)
- [Boris Cherny — Writing the Loops that Drive Claude](https://boris.sh/loops)
- [AWS Bedrock AgentCore — Web Search Tool](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-tools-web-search.html)
- [Amazon EventBridge Scheduler](https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html)
- [AWS Lambda — Retry behavior and error handling](https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html)
- [Building agentic AI applications — AWS Blog](https://aws.amazon.com/blogs/machine-learning/building-agentic-ai-applications-with-amazon-bedrock/)
- [Idempotency in serverless architectures — AWS Blog](https://aws.amazon.com/blogs/compute/handling-lambda-functions-idempotency-with-aws-lambda-powertools/)
- [AWS Lambda Powertools — Idempotency utility](https://docs.powertools.aws.dev/lambda/python/latest/utilities/idempotency/)