The IDE Became the Exception: How I Shifted to Building Loops Instead of Code
Listen to article
Fernando's voiceFernando · 10:58
Powered by Amazon Polly + OmniVoice
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.
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
/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.
- EventBridge · Scheduled Rule
- S3 / API GW · Event Trigger
- Lambda · Loop Orchestrator
- Bedrock · Reason / Plan
- AgentCore · Web Search / Tools
- Tool Output · Observe / Parse
- Verifier Lambda · Quality Gate
- Budget Guard · Token + Time Limit
- Human Gate · (async approval)
- S3 Cache · Chapter / Audio Ptr
- S3 / DynamoDB · Final Output
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.
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.
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.
References
Architecture, AWS, AI and market deep dives — straight to your inbox. Free.
No spam · unsubscribe anytime
Ask Fernando about this
Get a focused answer about this article from my AI assistant, grounded in my work.
Join the conversation
Sign in to comment
Verify your email to join in — you'll also get the newsletter. No password.
Keep reading
Architecture intelligence, in your inbox
Curated signals and original analysis on AWS, AI, distributed systems and the market — the way a solutions architect reads them.
- Curated AWS · AI · architecture · market signals
- New architecture studies & deep-dives when they ship
- Sharp summaries — depth without the noise
- No spam · double opt-in · unsubscribe anytime