2 comments

  • TheDong41 minutes ago
    I was curious, so I dug a bit.<p>Under the hood it&#x27;s effectively running:<p><pre><code> docker run --rm -w $PWD:&#x2F;workspace \ python:3.11-slim \ pip install -q patchpal &amp;&amp; \ &lt;command&gt; </code></pre> Which cool, great, I sure love &quot;pip install&quot;ing every time instead of just baking a single container image with it already installed.<p>This isn&#x27;t any sort of fancy or interesting sandboxing, this is shelling out to &quot;docker run&quot;, and not even using docker as well as it could.<p>Quoting from the linked page:<p>&gt; The tradeoff is ~5-10 seconds of container startup overhead<p>Sure, maybe it&#x27;s 5-10 seconds if you use containers wrong. Unpacking a root filesystem and spinning up a clean mount namespace on linux is a few ms, and taking more than a second means something is going wrong, like &quot;pip install&quot;ing at runtime instead of buildtime for some reason.<p>I can spin up a full linux vm and run some code in quicker than 5 seconds.
  • davispeck13 minutes ago
    This feels less like &quot;agents&quot; and more like a controlled generate → execute → fix loop.<p>Works great when you have a clear verification signal (tests passing), but what drives convergence when that signal isn’t well-defined?