Or you can have a conversation with an agent to build up a requirements/plan spec, asking it to analyse existing code patterns. When it seems like the agent has a good understanding of what needs to be done and how. Ask it to implement, keeping changes as a local spike.

Ask the agent questions about all the other teams' code, reaching out to them for questions it can't answer or clarification. With agent capabilities atm this is rare or can be done fairly async: "please confirm these things".

Maybe realise your code architecture is completely wrong. Manually code up some new abstractions that fit better, write the learnings into the spec plan. Strip out any implementation that largely doesn't fit your updated abstractions. Ask the agent to migrate the code to the new structure.

Repeat until spike is operational and you're happy with the abstractions used

Chat with the agent to create a Design Doc for the approach in the spike. Create a single JIRA ticket for "Productionise CodeShmode's spike". Get reviews and feedback from stakeholders.

Integrate feedback into your spike, or even the original spec document and regenerate the whole thing.

So much of the ritual you've outlined here is overhead from working in a large org where roles are siloed. When one person is empowered to do more then the actual work per person goes down and the overhead becomes the dominant. But that overhead isn't needed anymore because one person can now do many people's work.

I've whipped up spikes in a few days that would've been a month of work across a team multiple DDs and approvals. In the past this wasn't feasible so we would need to justify what those people would work on. Now you can whip it up, show a working demo and ask "should we productionise this"

I have no idea what a “spike” is, but this seems like a good way to build software when there are no consequences to getting it wrong.

What happens if this “spike” violates someone’s patent or puts the company at legal/regulatory risk? What if it leaks users’ personal information? What if it introduces a vulnerability that my 13 year old can exploit? What if it crashes 2 million of your users’ devices because it didn’t anticipate some unusual configuration? What if the code totally conflicts with some other team’s future plans and you didn’t know because they never reviewed it?

This kind of yolo “just try it” development only works if you are very small and low-profile, don’t have hundreds of millions of users, or your software is inconsequential (nobody cares if it goes down or doesn’t work).