Idea #1
The progression from in-loop to near-loop to out-loop is a concrete, actionable framework for measuring agentic engineering skill — and the right measure of skill is now how many agents are working for you at any given moment, not how well you can prompt. In-loop means you are the trigger: you sit at the terminal, write every prompt, watch every run. Near-loop means you are the approver: agents start working before you sit down, present results, and wait for your decision before continuing — you are reactive, not the bottleneck. Out-loop is full cron: no human required, agents fire on events and complete entire workflows autonomously. The argument is that 80%+ of a typical engineer's work can already run without them with the right system in place, and staying in-loop is a self-imposed bottleneck, not a necessity. The concrete workflow sketched: an on-call incident comes in, the agent detects it, investigates, root-causes, prepares a patch, and presents a single 'deploy' button — the engineer's only action is review and click. That one gate is what makes it near-loop rather than out-loop; the point is that all the engineering labor happens autonomously, and the human role compresses to a brief approval checkpoint.
Idea #2
Building a proactive agent (one that works before you show up) requires three architectural pieces acting together: a durable agent, an isolated sandbox, and a clear API/trigger layer. A classic CLI agent running on your laptop dies when you close it, can't survive crashes, and only starts when you type a command — so it is structurally incapable of near-loop behavior. Durability means the agent persists its state across restarts and crashes, can resume mid-task, and can hold an open conversation thread across sessions. The sandbox (dedicated cloud or local compute, not your laptop) means the agent is always-on, isolated, and not constrained by your device's state. The trigger layer replaces you-as-trigger with concrete events: cron schedules, webhooks, log stream events, ticket creation, user interface actions, or another agent's output. Any of these can fire the agent without human intervention. A durable news agent running continuously for a week and a half on an M-core Mac mini, pulling and Jev-classifying information into a signal feed, was shown as a live example — the engineer interacts by upvoting items and giving feedback, but the agent runs and filters constantly without prompting. The formula: durable agent + sandbox + trigger = an agent that works for you then waits, not one that waits for you to work.
Idea #3
Any task with a computable similarity or quality metric can be turned into an autonomous hill-climbing loop — the agent runs, an LLM judge scores the output against the objective, and the loop iterates until the threshold is met, with no human in the middle. This is called an RSI (recursive self-improvement) loop and is a general pattern, not just for UI work. The reason it works is that the judge function replaces human review as the feedback signal: instead of a human deciding 'is this close enough?', an LLM judge (Jev in the examples) scores the result numerically and the loop continues automatically if the score is below threshold. The practical requirement is that the objective must be scoreable — a similarity metric, a pass/fail test suite, a structured rubric, any function that produces a comparable number. The concrete demo: a 'deep Jev UI replicator' that accepts a screenshot of a target UI design, has an agent build the UI, screenshots the result, and uses a judge agent to score visual similarity; this ran in a cloud sandbox, achieved 86.1% similarity for Astra on one test, ran for ~30 minutes of autonomous iterations, and required zero human input after the initial image drop. The broader implication: engineers should actively look for tasks with scoreable outputs and convert them into autonomous loops rather than sitting in the review seat themselves.
Idea #4
The four dimensions of agentic engineering — context, model/tokenomics, prompt/system-prompt, and harness/tools — are all independent leverage axes, and most engineers only pull one or two. Context engineering (what information the agent has access to, how it is structured and compressed) is the first. Tokenomics is model selection: choosing the right performance-cost-speed point for the task, not just the most capable model, because subsidized subscription pricing will not last forever and cost matters at scale. Prompt engineering is not just the user turn — the system prompt sets the law for the agent, and engineers who rely on default system prompts cannot move near-loop because they cannot reliably predict or control agent behavior. Harness and tool engineering is the fourth and highest-leverage axis: what tools the agent can invoke, what guards exist, how the loop is wired. A concrete example: removing the bash tool from a custom agent harness entirely and replacing it with only the specific domain tools the agent actually needs — this eliminates entire classes of unsafe commands without relying on model-level refusals. The out-of-the-box default configuration of any agent harness is now fully saturated as a competitive advantage; every engineer can access the same base. Differentiation requires building custom harnesses with specialized tools, custom judge loops, and architecture decisions that the default configuration does not and cannot provide.
Source: ELITE Agentic Engineers Are LEAVING THE LOOP… Here’s why (IndyDevDan)
Text summarized and optimized using Anthropic’s models and reviewed by a human.