I talked with Julius Marminge about building T3 Code right in the middle of the agent-orchestrator wave. That is a fun place to build, but it also creates a real product challenge: when implementation gets cheaper, the hard part becomes deciding what deserves to exist in the core product.
Julius described the shift from working with one coding agent at a time to supervising many agents in parallel. That parallelism changes the bottleneck. You can get ten things built quickly, but that does not mean all ten belong in the product, or that the resulting code will still be maintainable a few months from now.
What stood out to me was the difference Julius drew between personal software and a product other people need to build on. If you fork something and add a feature for your own workflow, that can be great. But when you are responsible for the core product, you have to ask different questions. Is this extensible? Does it scale with other workflows? Are we adding one isolated feature, or should we step back and improve the underlying layout system so multiple needs can fit cleanly later?
That is product engineering.
The Pressure to Ship Everything
Julius is in a category where everyone can see what everyone else is building. Forks and clones show up quickly, and it is easy to feel pressure to match every visible feature. But he kept coming back to the same discipline: slow down enough to make sure the product is still good.
I appreciated that because it is a very practical version of the broader lesson for this season. Agents can help us move faster, but they can also help us make a bigger mess faster. If you want software to last, you still need someone with enough product and engineering judgment to notice when a decision is going to back you into a corner.
That is where experienced engineers still matter. The battle scars from past decisions are useful because they help you see when an implementation choice is really a future product constraint.
Dogfooding and the Whole Picture
Julius is also a daily user of the product he is building, so he has an unusually tight feedback loop. A lot of early T3 Code decisions came from getting enough feature parity with the tools he was already using so he could move his own workflow over and dogfood it seriously.
That is a great advantage, but we also talked about what happens as the product grows beyond your own workflow. Developer tools invite customization, and different users want very different agent workflows. The product challenge is not just to let everyone customize everything. It is to decide what the recommended path should be, where customization belongs, and which requests are important enough to prioritize now.
Julius’s homework for us was simple and useful: take a step back and broaden your view. Look at the whole product, not just the slice you are working on. Ask whether the solution will still make sense over time, whether it fits the real job users need done, and whether it keeps future product decisions open instead of closing them off too early.
