Rewiring the SDLC After Code Became Cheap

In the first post of this series, we laid out the thesis that code is no longer the primary constraint in software development. Advances in AI coding tools and models have dramatically increased the amount of code a single engineer can produce, forcing organizations to rethink how software gets built.

At Podium, that shift changed more than just how engineers write code. It changed our entire software development lifecycle (SDLC). Over the past year, we’ve reduced median cycle time by roughly 5x.

However, as AI made it possible to generate more code faster, we found ourselves running into a different set of constraints. Review, testing, validation, and delivery were suddenly becoming a much larger part of the overall effort required to ship software.

This post focuses on the coding-to-deployment portion of the SDLC and the changes we made to help the rest of the system keep pace with the 10x output gains we described in the first post.

Skillifying How Engineers Work With Agents

As we said in the first blog post, one of our earliest lessons in 2024 was that standardization was key to fully realizing the gains we saw in the most forward-leaning engineers. In 2024 and 2025, that meant cursor.md files for all repos and a focused effort to train and level-set engineers around the idea that AI was part of the job.

In 2026, that led us to build an internal skills marketplace. Instead of documenting best practices in scattered notes or chat threads, we packaged repeatable agent workflows into reusable skills that could be adopted, improved, and shared across teams. These skills covered common engineering tasks such as implementation planning, code generation, testing, debugging, and validation.

This made best practices easier to apply in the workflow. Engineers could start from a shared baseline, customize it when needed, and contribute improvements back to the broader team.

We also made this part of the default development setup. Through our internal CLI, engineers can install a standard set of recommended skills and hooks, giving every team a stronger starting point.

More importantly, it gave us a mechanism for turning individual learnings into shared organizational capability. That mattered because once engineers could generate and iterate on code faster, the bottleneck moved downstream into review, validation, and delivery.

Code Review: Turning Engineering Judgment Into Scalable Checks

As the amount of code moving through the system increased, the next bottleneck quickly became obvious: pull requests were backed up in review. Without changing the review process, engineers would spend an increasing share of their time approving, commenting on, and re-reviewing code rather than designing systems, planning work, and solving complex problems.

To address this, we built an AI-powered review system that evaluates code against Podium’s engineering patterns, coding standards, and de-slopification checks. Instead of relying on tribal knowledge or repeated review comments, we codified what good looks like and embedded those checks directly into the review process.

The system combines feedback from multiple review agents, each focused on areas such as security, architecture, and scalability, data stores, languages and frameworks, testing, and AI slop detection. Teams can customize rules for their own repositories, allowing the system to enforce both organization-wide and repo-specific standards.

At first, these review agents reviewed code, but did not have the power to approve it. Before enabling auto-approval, we validated the system extensively against human review to ensure it was identifying issues consistently and applying standards reliably.

This has had a direct impact on developer experience. Engineers spend less time waiting for reviews and more time shipping code. 

In under four months, we reached:

• 70% of eligible PRs were auto-approved
• 90% of PRs were auto-reviewed

That improved our cycle times dramatically while allowing engineers to spend more of their review time on the changes that most need human judgment. Higher-risk changes continue to receive human review. The goal is not to remove engineering judgment from the process, but to apply that judgment where it creates the most value. A code owner still pushes the merge button and explicitly deploys every change.

WALL-E: An Autonomous Cloud Agent for Bug Fixing and CI Follow-Through

As our agentic development workflows matured, we started seeing adoption move beyond engineers.

Product managers, designers, and technical product specialists had direct exposure to customer problems and bug reports that might otherwise sit in the backlog for days or weeks. But they did not always have local development environments set up or the time to maintain them.

Because we had standardized skills and AI-powered workflows engineers were already using, we saw a bigger opportunity: an autonomous agent that could handle larger parts of the development workflow, not just coding.

That became WALL-E: an autonomous agent built on top of the Claude SDK and designed to take on many tasks traditionally handled by engineers. WALL-E can identify eligible customer-reported bug tickets, triage them, claim actionable ones, and implement fixes. It can also test and validate changes, create previews, and generate PRs. Like any effective teammate, WALL-E also knows when to stop. When additional context, business knowledge, or engineering judgment is required, it escalates to a human.

For engineers, the value goes beyond automation. The goal is not to remove engineers from the process, but to remove repetitive work that distracts them from architecture, product strategy, and customer problems. As WALL-E took on more of that work, the next opportunity became clear: helping changes get through the steps required to be ready to merge.

CI: From Developer Babysitting to Agentic Validation

Although code now moved through review more quickly, engineers still had to wait for CI, interpret failures, retry jobs, fix test issues, and repeat the cycle until everything was green.

That follow-through work is highly repetitive and often interrupts engineers who are already focused on the next problem.

At Podium, WALL-E also helps manage that process. It monitors GitHub pull requests and CI runs, works through failures within its scope, and continues moving changes toward a deployable state. 

WALL-E is not simply reacting to events. It operates against a defined goal: getting a pull request validated, approved, and ready to merge. To do that, it diagnoses failures, reruns jobs when appropriate, applies fixes within its scope, and verifies that changes meet the required standards.

Engineers remain responsible for exceptions, edge cases, and decisions that require broader context.

When additional product, design, or domain judgment is required, WALL-E escalates to a human. It does the same when a ticket lacks sufficient context or acceptance criteria, when blocking reviews or external dependencies prevent progress, or when repeated CI or infrastructure failures fall outside its scope.

This is not fully autonomous software delivery, but rather agentic follow-through with human control points.

The result is less context-switching, faster resolution of routine issues, and a delivery process that scales more effectively as engineering output increases.

Early Results

The early signals are encouraging. PR volume has increased materially, WALL-E is contributing a growing share of pull requests, and AI-powered review is reducing review overhead.

Today, that looks like:

• ~11% of all pull requests are generated by AI.
• 100% of pull requests are reviewed by AI.
• 60% of all pull requests are auto-approved.
• 85% of repositories have auto-approval enabled.
• Median cycle time has dropped from roughly 1,000 minutes to roughly 200 minutes.
• Change failure rate has remained stable at less than 1%.

We are still in the early stages of this transition, but it’s becoming increasingly clear that we can significantly scale our output without sacrificing quality or slowing down the entire system.

What We Learned

A few lessons have emerged as we have started rebuilding this part of the SDLC.

First, AI code generation creates pressure downstream. If review, CI, and validation do not change, faster coding just moves the bottleneck.

Second, planning matters more as agents become more capable. AI does not remove the need for clear intent, constraints, and validation criteria. It makes those inputs more important. The better the plan, the better the agent output.

Third, code review has to become more systematic. As code output increases, engineering judgment needs to scale through codified patterns, automated checks, and review systems that apply standards consistently.

Fourth, the people closest to customer problems can contribute more directly when the system gives them safe ways to do so. Product managers, designers, and technical specialists do not need to become full-time engineers to help move small, well-scoped improvements forward.

Fifth, humans still own judgment. Agents can execute, check, retry, and suggest, but humans remain responsible for intent, product quality, architecture, and high-risk decisions.

The SDLC Is Becoming Agent-Native

The first stage of AI adoption in engineering was focused on helping individual developers write code faster. The next stage is about redesigning the software development system around AI-native workflows.

The future SDLC will not be built around humans, or agents alone. It will be built around effective collaboration between the two. Humans define intent, make decisions, and provide judgment, while agents help execute, validate, and move work forward. The role of the system is to make that collaboration as efficient as possible.