<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Drift on Alex Herrero</title><link>https://alexherrero.dev/tags/drift/</link><description>Recent content in Drift on Alex Herrero</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Wed, 25 Feb 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://alexherrero.dev/tags/drift/index.xml" rel="self" type="application/rss+xml"/><item><title>Don't get too far ahead of the agent</title><link>https://alexherrero.dev/thoughts/too-far-ahead-of-the-agent/</link><pubDate>Wed, 25 Feb 2026 00:00:00 +0000</pubDate><guid>https://alexherrero.dev/thoughts/too-far-ahead-of-the-agent/</guid><description>&lt;p&gt;When I started Sherwood I designed the whole thing up front — including the front-end, before I&amp;rsquo;d built any of the backend. It felt productive. I expected that the agent would just be able to code until it was done, but by the time we got to the front-end, the backend had already drifted from the plan, and I had a pile of drift to reconcile that I should have caught earlier. You hear a lot of the term &amp;lsquo;Human in the Loop&amp;rsquo; posed as a solution for this problem, and it&amp;rsquo;s true that it helps, but this also slows development, and I don&amp;rsquo;t want to be a bottleneck. So today I learned that designing too far ahead is its own kind of drift. A human in the loop catches it, but agents write faster than one person can review, so keeping pace will eventually have to be automated.&lt;/p&gt;</description></item></channel></rss>