You will almost certainly build them
When I first started working in Big Tech, I was surprised at how much of their development tooling was house-made. Version control wasn’t Github, internal messaging wasn’t Slack — except at Salesforce, which notably bought Slack the company — and project tracking wasn’t Jira. Instead the big companies used custom tools they made themselves.
At first I thought this was just because the big guys have so many resources (they do) and so much hubris (and who wouldn’t) that they preferred their own solutions as better than packaged ones. Although using these tools they didn’t necessarily feel like better products than the packaged ones, and they certainly weren’t as polished.
Over time, though, I started to see how the custom tools did exactly what the companies wanted done, in the exact way they wanted to do it. And, at scale, that made a huge difference. More than anything, this allowed the companies to create their own processes and culture, and know that the tools would serve that. Reinforce it, even. And given how unwieldy processes and culture will get across tens of thousands of people, this was worth the investment.
At smaller companies, of course, custom tooling was a luxury that rarely justified the ROI. The tradeoff was that, in return, the company subtly loses a little control of its contours. You use Slack for collaboration and you become a Slack-shaped org. You use Jira for tracking and, sure enough, over time you become a Jira-shaped org. Ultimately everybody thinks in terms that work well for Github, Jira, Slack, whatever the tools are. And it’s fine, it’s better than having your engineers tied up writing and maintaining code for a custom version control system.
Until coding is automated and cheap.
Suddenly the agentic engineering org has made two big shifts: 1) it is producing way more output, so the effects of tools on its culture is more pronounced. And 2) the cost of building custom tooling is way lower.
I believe that this will result in many more small-to-medium size orgs building a lot more tools. For instance, Slack is, at first glance, a convenient place to wire up your agents and collaborate with them. But Slack is probably not the best surface at every engineering org for humans to operate agents, and if your org would do better with something else, it’s a lot easier than it used to be to build and maintain what you want. In fact, it’s probably easier to build and maintain your own system than it is to constantly try to shoehorn what you need through Slack - particularly when engineers are producing many multiples of PRs, reviews, and discussion more than they used to.
I don’t think this shift will be monolithic or universal. Packaged tooling makes sense when a need is both very generalized across an industry, and also very complex. Slack proved to be able to address the specifics of team collaboration across many companies, in a deep and reliable way that made them almost impossible to beat in terms of functionality for many companies.
Similarly, it’s easy to imagine that certain needs of the agentic engineering org — perhaps the knowledge base or the memory/context system — will prove well-suited to complex yet general solutions.
That said, in the meantime I think you should just plan to build a lot of what you want. It’ll be cheaper, and most importantly, more conducive to creating the company you want and the culture you believe in.