At the end of last year, like many other teams, we felt a significant phase transition in models coding capabilities. Agents shifting from sycophancy vibes to constructive push back.
Across the team, engineers progressively bumped their grid-size (number of independent checkouts one has on their machine to parallelise agent work), but we started experiencing friction due to pre-agent baked assumptions in our dev-setup (port conflicts preventing having multiple dev instances running on the same machine and slow warm-up times form fresh checkouts).
It was clear to us that we had to prioritise engineering work in 2026 to upgrade our dev setup to the user of larger grid-sizes.
@henryfontanier came back from holidays with a present for us and casually dropped on the team `dust-hive` a full repackaging of our dev-env for agentic coding with batteries included: https://t.co/zt9RnkfWIM
Henry wrote a full blog post presenting the technical details behind dust-hive + some thoughts on impac of agents on software engineering at large: https://t.co/0GXmPZl2FR
Each dev env is a bit specific and it's likely that every team will have to build a bit of specific software to adapt their environment to large grid-size with proper containment and rapid branching. Henry's work can serve as a solid starting point to do so in days not weeks.
The interesting questions to me are (most covered in the article):
(i) can this be standardized? the answer seems to be yes but would require a very rich configuration layer that goes beyond a Dockerfile.
(ii) What does it mean for software engineering? We strongly believe at Dust that it means more taste and more technical competency are needed from software engineers not less. Almost like an inverted Jevons paradox.
The world we live in.
Shipfox just backed Testcontainers, an essential tool for better tests and reliable CI. Join us in supporting this game-changing OSS project! https://t.co/ajmpX2DE5A via @opencollect