Code Got Cheaper. Our Rituals Didn’t Notice.

Much of the modern software development lifecycle was built around code being expensive and hard to change. So we built ceremonies, rituals, and whole philosophies around deciding what to build before anyone built it.

We planned every story long before an engineer started writing any code. Product managers would curate an extensive backlog of work just waiting for engineering resources. Designers would build mockups because doing so was so much quicker than implementation. We'd sit for hours every week debating the right Fibonacci number every change deserved because build time could range from hours to months depending on its complexity.

Much of that made sense. When building software was the slow part it felt rational, almost mandatory, to have meetings with half a dozen people debating which thing to build next and what shape it should take.

When Rituals Become Dogma

Our reality has fundamentally shifted: Writing code is now the fast part, or at least significantly faster than it used to be. The problem is that the rest of our practices around shipping software haven't caught up yet. In every other part of the process we continue to act as though coding is still the slowest part of the machine.

AI hasn’t made software easy. It has changed where the bottlenecks are. The expensive part is less often typing code and more often deciding what should exist, giving the right context, validating the result, and coordinating the humans around it.

To adapt to this new reality we have to question every ceremony, every ritual, every phase of software development. We have to ask ourselves what problem each of these exists to solve, and whether that problem is still worth solving in the same way - or even if it still exists at all.

Most teams won't make this leap for a very long time. Many will find themselves stuck with "zombies" that hang around for years. The teams that adapt the best are going to be the ones that ruthlessly let go and are willing to try new things.

This doesn’t mean planning is dead, design is obsolete, or engineers should ship whatever an agent produces. It means the expensive part of the system has moved. The bottleneck is increasingly judgment: deciding what matters, shaping it well, reviewing it carefully, and learning quickly.

Things to Do More Of

Pair Prototyping

This is a really exciting opportunity that didn't exist just a couple of years ago. Historically we've had processes where a product manager would go off and collect requirements, bring them to a designer who would then try and translate them into a design. Then an engineer would go and build some version of it. And it was only at the end of this process that we discovered what didn't work and what other opportunities existed.

Those same two or three people can hop on a call and pair together on a rough, AI-assisted “vibe-coded” prototype. You can actually see what the feature looks like in practice, its complexities and limitations, and you can try different things in real time.

In an hour, the PM can see the edge cases, the designer can see where the interaction breaks down, and the engineer can see which parts are actually hard.

Then at the end of the session, throw away the code and use your experience to inform what you actually want to build. Writing code is fast, so you don't have to be married to it anymore.

Connection Time

One thing I realized when previously suggesting we ditch standup on a previous team is that having that time together with your teammates every day actually serves an important social purpose. Being able to connect with the people you work with is important for cohesion and morale.

Standup just isn't the right venue for it. Instead, have some time carved out during the week for the team to connect - intentionally. Make it optional, low pressure, and fun. Instead of robotically reciting what's on your Jira board get together for the explicit purpose of hanging out and learning about each other.

Show n' Tell

We're building and prototyping more stuff than ever. Experimentation is low friction now, we can build things just to see if we can. Now's the time to show it off.

Show off things that you've experimented with, including purely vibe-coded prototypes. It's useful for generating new ideas and germinating possibilities across teams.

Retro

Software development is evolving more rapidly than I've ever seen in my career. I’ve been around long enough to have seen the rise of Rails, a million JS frameworks, and more fads than I can remember.

With the ground shifting beneath us, regular team retrospectives are even more important. They've always been a good way to identify what's working and what's not on a given team and to pivot accordingly. The trade-offs of these new tools are not clear yet, and their capabilities are growing every month.

Taking time with your team to reflect on what's working, what's not, and what opportunities we have in front of us is worth doubling down on.

Things to Tweak

Backlog Grooming, Shaping, and Refinement

Whatever you call it, this routine exists for two reasons: 1) teams need a backlog of well-defined work that's ready to pick up, and 2) backlogs are vast so they have to be prioritized to make sure the most valuable things get built first.

The first problem not only still exists, but is more critical than ever. Having actionable work is now one of the biggest bottlenecks in software development. The second problem hasn’t disappeared, but it has changed. Teams still need direction. What matters less is maintaining a perfectly stack-ranked backlog of tiny tickets.

The key change is that the focus shifts from prioritization to shaping tasks so they can be shipped. Prioritization can still happen, but it should be done in very broad strokes, not agonizing over the exact stack-rank of every minute story.

Knowledge Sharing & Documentation

These meetings and artifacts exist to prevent knowledge silos from cropping up and spread knowledge around the team. It's important to make sure that these artifacts exist in some form that's visible to the agents writing the code. Documentation used to be mostly for humans. Now it's also part of the context window for the systems helping us build.

Since meetings are often ephemeral, capture meeting notes and make them available too.

Documentation tends to become outdated over time, and it's one of the easiest corners to cut. One strategy for dealing with this is to create an agent job that runs against your documentation sources and looks for contradictions that it can raise. Humans still make the decisions, but agents do the grunt work.

Code Review

This has always been important, and it's even more important now that we can generate code quickly. The whole point is to make sure that the code we write actually does what the author believes, that it does so in a way that's secure, performant, and doesn't reduce the team's ability to change the software in the future.

Specialized AI sub-agents given concrete subjects to focus on (e.g., security, performance, accessibility, correctness, and so forth) can add valuable deep analysis of the changes.

I've found that frontier models are able to catch things that human reviewers commonly miss. Expert human review is still necessary, but combined with AI we have review superpowers. Not only is our code quality not declining, we're actually able to write better code than before, catching issues that we likely would not have caught previously.

Things to Drop

Estimation and Sprint Planning

These are some of the most expensive ceremonies that Agile-adjacent teams perform. They're all about answering the question, "how much can we build in this unit of time?" where the unit of time is usually a week or two. I've been on teams that dedicated several hours every week to this end.

In the time it takes to estimate and debate some tasks, we could now finish them. These resources are now more effectively deployed on shaping work and making it shovel-ready than debating which Fibonacci number it ought to carry.

There are many alternatives worth exploring (Kanban, Shape Up, etc.) Or perhaps the answer will be something new entirely.

Standup

The daily info dump of what you did yesterday and what you plan on doing today. It's supposed to address team problems like coordination drift, visibility into work, and removing blockers.

This meeting has always been one of the most expensive ways to address these problems. Coordination drift is better handled by practices like pair programming and tech leads. Visibility ought to be handled by whatever task management system your team uses. And nobody should be waiting until the next standup to address their blockers.

Instead of a traditional standup block off some time with an open agenda. Allow team members to add items to the agenda for things they want to discuss. When the time rolls around, the appropriate team members should attend based on the agenda. If there's nothing on the agenda, there's no need for a meeting.

The signal-to-noise ratio suddenly becomes very high at a greatly reduced cost.

This doesn't really have anything to do with AI, it's just an artifact we should have gotten rid of long ago - and I'm sneaking it in here because it's my blog and I'll cry if I want to.

Question Everything

There are many rituals out there, and different orgs with different cultures have countless takes on their own. If you take only one thing away from this let it be this: periodically revisit your team's patterns and ask why. What problem are we trying to solve? Is the problem still worth solving? Is this still the best way to solve the problem?

If the problem is clear and the ceremony handles it better than the alternatives, great. Keep going. But if not, don't keep it hanging around for posterity. Find what's out there that's better and embrace it. Maybe you'll blaze a trail that will become a ritual for others.