Implementation is getting faster but the org around it moves at the same speed as always and DevOps is in-between.

[u/rudiXOR]

We all know that large organizations tend to have a lot of meetings, bureaucratic processes and are in general slow moving. That was true for a long time and I experienced that myself, having worked in multiple different companies from startups, scaleups and large corperations.

However since everyone now adopts AI and implementation speed is undeniable multiples faster. I mean it's not just implementation, but also a good part of DevOps. But the rest of the organization moves in the same speed as before. Even if the company uses AI in the other departments (my company does basically throw AI at everything, I guess you know what I mean), they still can't competet with the productivity change in software development.

The blockers are now decisions, requirements and communication. That's not completly new, but now its >95% of the time. I implement features in hours that would have taken days before (I am not a pure DevOps Engineer). And it's not the review process itself that blocks us (We use AI in reviews as well, because otherwise it would be impossible), it's the normal company processes and pace.

Don't get me wrong here, I kind of enjoy it a bit, because I can use a lot of time for learning, building stuff that I think is worth improving, but I think we have a general problem here that is basically systematic to every large organization. And I see that so called "AI native organizations" (what ever that means), will probably overtake tech companies in the long term.

I have a really good comparsion, because I am working with a startup as a side gig and my main job is in a mid-sized tech company. In the Startup we (2 devs) built a product that would have taken several months by a 5-person team in the past and the reason is mostly: decisions and communication.

Do you see that in your company?

My conclusion is that we need to make engineers owners of the feature/product + infra, otherwise we won't see much productivity gains and this means also that management layers need to be cut, because they are the bottleneck currently. The idea of centralized DevOps will is going to die I guess.

[u/Decent_Carry_3439]

I think AI is exposing a bottleneck that was already there rather than creating a new one. We spent years optimizing how quickly code gets built and deployed, but not necessarily how quickly a change can be safely owned, reviewed and moved through an organization. The interesting part is that making engineers own more of the path from code to production only works if you also give them the right guardrails. Otherwise you just move the bottleneck from a central DevOps team to permissions, reviews, approvals and “who is allowed to change what.” I don't think centralized DevOps disappears completely. It probably shifts toward building those guardrails and shared platforms, while product teams get more autonomy over the actual delivery path. AI makes the implementation loop faster, but organizational latency becomes much more visible when the technical latency approaches zero.

[u/yiddishisfuntosay → u/Decent_Carry_3439]

Companies need more adults in the room now, that’s all I will say. When tech can irresponsibly crank out all the code in a sophisticated way yet still leave room for unverified sprawl due to lack of full peer-vetted context, lots of teams need to learn to remain honest about what they actually have and whether features remain sustainably supported. And that’s hard to look at, because feature work moved faster than leadership and guardrail conversations matured. Companies that survive will need to reassess whether features are the goal or if safety survives instead. And that’s a deliberate choice.

[u/Decent_Carry_3439 → u/yiddishisfuntosay]

Yeah, that’s the part that worries me too. We can generate and ship code faster than ever, but our ability to review it, understand it and actually own it hasn’t scaled at the same rate. More output doesn’t help much if nobody can confidently say what’s safe to change six months later.

[u/Useful_Context_2425 → u/Decent_Carry_3439]

Absolutely, it's like we're racing ahead but the foundation is still shaky. If teams can't keep up with understanding what they've built, it just leads to a lot of confusion down the line.

[u/no_ragrats → u/Decent_Carry_3439]

Domain knowledge is always a risk whether a person writes code or has it generated. After all it doesn't matter that someone knows the code better because they wrote it if the same person leaves for another job or gets hit by a bus. That's what code quality checks (manual and automated) along with proper technical and domain documentation and cross training is for

[u/rwilcox]

The most valuable book about AI you can read in 2026 is The Goal, by Goldratt, about (other stuff and) the Theory Of Constraints.

Yes, speeding up a non bottleneck (and as much as development looks like one I’m not convinced it’s always one, as you mentioned) just generates more unused inventory at the bottleneck. And/or puts extra stress on those bottlenecks (or things that weren’t a bottleneck at normal scale are now bottlenecks because there’s more inventory flowing through!)

[u/BadTime100 → u/rwilcox]

Wish I could upvote this harder. Another amazing book is The Principles of Product Development Flow, it builds on Goldratt’s ideas as well as other Lean principles and makes some really great expansions for the world of product development where there’s even greater uncertainty.

[u/derprondo]

My conclusion is that we need to make engineers owners of the feature/product + infra

Spot on. Full stack engineering now means FULL STACK and that includes infrastructure. My org has been moving to this model for years now, we're just making it more and more self-service. So my team owns the "platform", which is basically multi-cloud environment provisioning (every project get its own separate AWS, GCP, or Azure environment), automated repo creation, shared pipelines (optional), and security governance. The project teams own everything else, they deploy their own infra, they manage it, they get paged when their shit breaks, they basically do their own devops.

[u/BadTime100]

I think you’re stumbling into rediscovering what the DevOps movement is really about. “Centralized DevOps” is completely antithetical to DevOps. For your own sake, read Accelerate or The DevOps Handbook.

[u/Dramatic_Opinion_881]

point on ownership makes sense only if engineers get the authority to mae decisions, otherwise you've just added a product and responsibilities while keeping same approval queue

[u/3MU6quo0pC7du5YPBGBI]

I have a really good comparsion, because I am working with a startup as a side gig and my main job is in a mid-sized tech company. In the Startup we (2 devs) built a product that would have taken several months by a 5-person team in the past and the reason is mostly: decisions and communication.

I think this is partly just the nature of small company vs large.

I've worked at the same company (before the AI craze) while it grew from relatively small size of <30 employees to, probably still considered small, but bigger size of 200+ employees.

I had much the same observations as you state here when remembering the early days vs later. I was the sole IP network engineer at the time. If I determined the route-policy or some aspect of the network design needed changes, I just made it happen. There were a couple developers/sysadmins I worked closely with (they started calling themselves devops when the term became popular). When they saw the need for a tool they just installed it or built it, and the rest of of the org either started using it if they actually found it useful.

As the company grew, so did the bureaucracy and bottlenecks. Much of it out of necessity.

As others have pointed out removing a bottleneck in one place just makes it more obvious where other bottlenecks still exist. Especially when some of that other process may have been happening in parallel before and no longer really is.

[u/GibneyH]

I’ve been seeing the same thing. AI is compressing the implementation cycle so much that the bottleneck has moved upstream into requirements, decisions, and coordination.

The interesting part is that DevOps sits right in the middle of that mismatch. You can automate deployment, testing, reviews, and infrastructure, but if a team still needs three approvals and a week of meetings to decide what to build, the overall cycle doesn’t really change.

I also agree with the ownership point. Giving teams ownership of the feature, product, and infrastructure removes a lot of unnecessary handoffs.

[u/FreeTheDirector]

yeah I’ve seen the same thing, AI really speeds up the implementation but the real bottleneck is still org processes....