There used to be a fairly natural point where someone asked whether it really made sense to build something internally. If the estimate was three weeks, two months or half a year, the cost was visible enough that the discussion happened almost automatically. Is this really something we should build, does something already exist, and is this where we want to spend engineering time?

Coding agents are removing a lot of that friction. A surprising amount of software can now get to a convincing first version very quickly. Give an agent a reasonably clear task and it can inspect the existing codebase, follow the patterns already in use, wire up an API, add persistence, write tests and give you something that works. Not necessarily something you would blindly run for the next five years, but often more than enough to make building it yourself feel like the obvious choice. I think the result will be that companies end up owning a lot more software than they do today, not because someone made a big decision to build an internal platform, but because nobody really had to.

You need a small scheduler for one workflow, so an agent builds it. Someone else needs an internal admin tool and gets one in an afternoon. Another team creates a wrapper around observability, a small data pipeline or some integration logic because doing it directly is now faster than researching alternatives. Six months later another service needs roughly the same thing, but the existing implementation does not quite fit, so another version appears. Every decision can be perfectly sensible on its own.

Previously, the effort involved in creating these things acted as a filter. If something was going to consume a meaningful amount of engineering time, someone normally had to justify it. When building something took weeks, the cost forced the discussion. When it takes an afternoon, it is much easier to skip it.

The software itself does not disappear after the agent is done. It still has to be understood and changed later. Dependencies move, APIs change, requirements change and the small thing someone built for one use case eventually gets used in three others. The fact that version one took an afternoon does not necessarily make version twelve any easier to own.

I do not think the conclusion is that companies should buy everything instead. Coding agents make it possible to build far more software around the things that are actually specific to the business, and that is probably one of the biggest advantages here. But I do think we need to get a little better at separating “this is easy to build” from “this is something we want to own”.

You can see the same thing in a lot of the plumbing around applications. An internal scheduler, authentication component, delivery system or observability layer may suddenly be quite easy to create. That does not necessarily make it more specific to the business. It just makes recreating it internally cheaper.

That distinction is also relevant to what we are building with Queuey. We know developers can build event delivery themselves, and coding agents make that even easier. Our argument is not that retries, buffering, replay or recovery are impossible to build. The question is whether every application should end up owning all of that simply because the first version was easy to create.

The same question probably applies to a lot more than delivery. We may be entering a period where companies can build internal software faster than they have ever been able to before. Most of that will be useful, and some of it will probably be very good. I suspect we will also look back at quite a few internal systems in a few years and wonder when exactly we decided to own them. The answer may be that we never really did.

Sources

DORA — *Impact of Generative AI in Software Development* https://dora.dev/ai/gen-ai-report/report/

Birgitta Böckeler / Thoughtworks — *Maintainability sensors for coding agents* https://martinfowler.com/articles/sensors-for-coding-agents.html

Gregor Hohpe / AWS — *Buy vs. Build Revisited, Part 4: You Might Be Asking the Wrong Question* https://aws.amazon.com/blogs/enterprise-strategy/buy-vs-build-revisited-part-4-you-might-be-asking-the-wrong-question/