I've written recently about the pitch pause we ran across the company and about how giving everyone time to build with agentic AI tools changed the conversations we have. Three months on, in the middle of a normal work week, I noticed something. A handful of the tools I now rely on to do my job didn't exist a year ago. Not vendor tools. Tools we built. A few of them by people who don't write code for a living.
That's the win. It's also the thing that's been quietly keeping me up at night.
How we got here
The pitch pause worked partly because of some unglamorous setup we did in advance. I think this is the part most companies skip in the AI-adoption process, so it's worth describing.
We spun up a new GitHub organization and called it "labs." Anything goes. Experiments, half-baked ideas, weekend prototypes. Putting that code in our product organization would have raised the wrong question every time someone wanted to commit something: is this code we're committing to the product? The new org made the answer trivially "no." That one decision removed a surprising amount of friction.
We created a separate AWS account, isolated from anything related to our product or client-facing work. Apps deployed from the labs org go there. Nothing else.
Then we built a shared deploy pipeline with single sign-on baked in. Anyone in the labs org can ship a web app, and only Validic employees can access it. Nobody had to rebuild authentication. Nobody had to figure out routing or certificates or how to expose a service to the internet without exposing it to the entire internet. That sounds like infrastructure plumbing. It is, and it matters more than it sounds. It meant the moment something started working on someone's laptop, they could have it running on a real URL within an hour, accessible to coworkers, gated by their existing credentials.
The difference between localhost and a real URL is meaningful. Localhost is a science project. A real URL is a thing other people can use. People build differently when they know other humans might actually try the result.
The graduation problem
Some of the things people built started getting used. Then started getting depended on. Then started solving real problems well enough that we don't want to give them up.
We now have a process for what we call "graduation." If something built in labs starts mattering, we move it. A different GitHub org, this one for internal tools, distinct from our product code but explicitly corporate. It gets an internally defined SLA. Someone's name is on it. Security reviews happen. Patches happen. The thing is now a thing we own.
A few of these have offset real SaaS spend. The benefits are not theoretical.
But every graduation is also a new mouth to feed.
The question Drew asked
This is something I'd been spending a lot of time thinking about myself, so it really landed when our CEO Drew Schiller posted something on LinkedIn that put words to what I'd been chewing on for a while.
The short version: the question every company asks is "can we build this?" For an engineer, the answer is always yes. With agentic coders, the answer is yes, and fast. But that's the wrong question. The right question is "should we build this?" Because when you build it, you own it. Forever. Your team, humans and agents, has to monitor it, maintain it, improve it, fix it.
That's the bill that comes due eighteen months after the prototype impressed everyone in the all-hands.
What we won't build
I want to be specific here, because it would be easy to read this as "agentic AI is dangerous, be careful." That's not what I think.
What I think is that you have to stay honest about what you're choosing to own.
We could, in theory, build our own code repository that also deploys our software. The technology is well understood. An agent could draft a credible first version in a week. We are not going to. We are not going to build our own version of GitHub. We are not going to build our own AWS services. We are not going to build replacements for the mission-critical platforms our business depends on, because we are very happy to continue paying experts to run those, patch those, and stay on call for those.
What we will build, and what I think is the actual sweet spot, is the long tail of small, niche, internal tools that no vendor will ever build because the market for them is twelve people inside one company. The tedious cross-system reporting tool. The data reconciliation script that runs every Thursday night. The internal dashboard that pulls from three systems nobody planned to integrate. Those are perfect. The audience is known. The cost of getting them wrong is bounded. If they break, the worst case is that twelve people go back to doing the work the slow way for an afternoon while we fix it.
The trap is the middle. The "we could replace that SaaS tool ourselves" pitch that sounds great in a slide deck and looks very different at the eighteen-month mark, when the people who built it have moved on and nobody really wants to be the one paged at 2am because the homegrown version of X has a TLS certificate problem.
Why I'm not worried about software engineering
This is also why I'm not worried about the future of software engineering as a profession, particularly at companies operating in regulated, high-trust markets.
Some of what we sell at Validic can, at the surface, be cobbled together with agentic AI by a small team. The demo, sure. The prototype, no problem. But the gap between a working prototype and a product that paying customers will actually run their business on is enormous. It's resilience. It's disaster recovery. It's HIPAA. It's HITRUST. It's the SOC report a health system's security team requires before they'll sign anything. It's the on-call rotation that picks up at 3am when a data sync breaks. It's the audit logs and the change management and the postmortems and the patches, and the part where someone has to be accountable, with a name and a phone number, when something goes wrong.
That's not a builder problem. That's a company problem. Agentic AI does not collapse the distance between "I have a working prototype" and "I have a product an enterprise customer will trust with their patients' data." The prototype is the easy part. The company around it is most of the work.
Keeping the energy pointed at the core
And that's exactly why I want to be careful about what else we choose to own internally.
Once we've built a thing, weaned ourselves off whatever vendor-supplied product it replaced, and started depending on it, what happens when it breaks in a way the agent can't quite figure out? The subtle defect. The failed deploy. The certificate that didn't renew correctly. The maintenance work rolls downhill, and downhill is engineering. Every graduated internal tool eventually generates an engineering ask, because agentic AI is great at building things and uneven at debugging the weird specific failure mode that only happens in production on a Sunday night.
The thing I keep coming back to is that creative energy is finite, even when the cost of building drops dramatically. Maybe especially then. When building gets cheap, the temptation is to build everything. Why pay for that when we could build a version? Why integrate with that when we could build a version? Why not build a version of everything?
Because every version is a thing you now own.
If your core business is selling X, the creative energy of your builders, human and agent, should be pointed at making X better, faster, more delightful, more defensible. Not at recreating internal infrastructure that someone else is already willing to operate for you.
Niche peripheral productivity tools? Build them. They make people's lives better and the blast radius is small.
Core mission-critical platforms you'd otherwise pay a vendor to operate? There be dragons.
We can build it. The harder question is whether we should. And the discipline to ask that second question, every single time, is what separates a productive internal building culture from a slow-moving distraction from the work that actually matters.
