Rethinking Assumptions argued that when agents write most of the code, the assumptions behind our tooling break: tickets, PRs, sprints, and branches were built for a world where humans were the scarce resource. That post focused on tools. This one asks: what does that shift mean for teams? Product and engineering don't just use the tools - they are organized around the same assumptions. If we don't update how we work together, we'll keep forcing agent-era output through human-era structures and blame the wrong thing when it hurts.

There's an upside worth aiming for. When the bottleneck shifts from "can we build it?" to "do we want it? is it right?", product and tech can finally focus on the work that only humans can do: strategy, judgment, coherence, and learning. Less queue management, more craft. The teams that lean into that shift don't just survive the transition - they get to play a better game.

In this post we look at team-level assumptions and tensions, team size (including the "tiny team" angle), what product and tech need to own, the IC and PM in the new loop, the bridge from prototype to production, and a practical stance.

The open source AI assistant space has exploded in the past few weeks. What started with a single breakout project (Clawdbot, later Moltbot, now OpenClaw) has spawned an entire ecosystem: full-featured frameworks, minimal rewrites, Python alternatives, Go and Rust implementations for embedded hardware, and shell-script-as-a-service. The projects share a common promise - an AI agent that runs locally, connects to messaging channels, and can execute real tasks - but differ sharply in implementation and philosophy. If you're evaluating or building on one, the trade-offs matter. This post does a deep comparison of eight major implementations.

Most dev tooling was built on assumptions that no longer hold: humans write code with effort and expertise; changes are scarce and valuable; linear workflows make sense. When agents write 90% of the code, those assumptions break. The tools we rely on - tickets, PRs, sprints, branching - were designed for a different world. It's time to re-examine them from first principles.