AI Coding Made Us Faster-Then the Real SDLC Problems Started -Thoughts from Our First Claude Code Project

We are close to completing our first real AI-native project using Claude Code and OpenAI Codex. The team will share more details soon, but I thought it may be useful to write down some early reflections first, especially because this journey has become much more interesting than simply saying “AI can write code”.

The biggest realization so far is that AI coding does help resolve the coding velocity issue, sometimes dramatically. Claude Code and Codex can generate, refactor, debug, and explain code much faster than the traditional way of working. But when coding suddenly becomes fast, or sometimes too fast, many other challenges start to pop up.

This makes sense when we think about it more deeply. Coding is only one step in the whole software delivery flow. If one step becomes much faster, all the surrounding steps — requirements, architecture, review, testing, UAT, version control, release management, iteration cadence, and accountability — will feel the pressure.

So the real question is no longer just whether Claude Code or Codex can generate code. They can. The more interesting question is how the whole engineering system should change when coding is no longer the slowest part of the process.

Should We Slow Down AI Coding?

One question I have been thinking about is whether we should deliberately slow down AI coding velocity to reduce risk.

My current view is: probably not for long, but yes for some time…

If AI coding gives us speed, we should not simply give up that speed because the rest of the process is not ready. The better question is how to build a stronger harness around that speed. We should not slow down AI coding blindly, but we do need to make sure the surrounding SDLC can absorb the speed safely.

This may mean clearer requirement discussions, stronger architecture review, better test specifications, automated test generation, AI-assisted validation, and more deliberate release gates. It may also mean changing how we assign work.

In traditional agile delivery, we often assign one user story to one developer. That works reasonably well when the developer is the main implementation engine and coding itself takes time. But in an AI coding workflow, the risky part may no longer be who writes the code. The risky part may be whether the requirement, architecture direction, and test intent are correct before the AI agent starts moving fast.

For important user stories, it may no longer be enough to assign the whole story to one person and let that person work through ambiguity alone with an AI agent. If the requirement is unclear, AI will move fast in the wrong direction. If the architecture direction is weak, AI may produce something that works locally but creates long-term maintainability issues. If the test intent is weak, AI may generate both code and tests that look complete but still miss the real business expectation.

So perhaps pairing becomes more important again, but not only during coding. We may need more pairing at the requirement grilling stage, the architecture thinking stage, and the test-spec stage. Once those are clearer, AI can move fast with much better guardrails.

That is a very different way of thinking about productivity. The bottleneck may move away from typing code and toward clarifying intent.

Human in the Loop Or Not, Or Where?

One common assumption is that AI coding must have human in the loop. At first glance, the answer sounds obvious. If AI writes the code, senior engineers should review it. Otherwise, AI may do something crazy, bugs may go into production, and then who is responsible?

This concern is very valid, especially when the product is not a toy project but something used by real business users. However, I think the assumption still needs to be challenged.

If AI coding becomes very fast, and every AI-generated change still needs detailed line-by-line review by senior engineers, will that be realistic? Or will code review become the new bottleneck? Worse, will it slowly become a rubber-stamping exercise because the amount of code generated is too high for anyone to review meaningfully?

No one wants to become the bottleneck in the chain, but no one wants to take blind accountability either. This is probably one of the open wounds in AI-native SDLC. We have not fully solved it, and I suspect many teams have not either.

My current thinking is that human in the loop is still important, but we should not assume the loop must always sit at the code review stage. Human judgment may create more value if it shifts left into requirement clarification, architecture review, business-rule validation, test intent, and release risk assessment.

For example, a senior engineer may spend less time reviewing every line of AI-generated code and more time reviewing whether the feature boundary is right, whether the architecture direction is sound, whether the test cases actually cover the right business risks, and whether the release impact is acceptable. Another AI model or reviewer agent can perform the first layer of code review, while humans focus on the parts where judgment matters most.

As AI models improve, I am actually quite optimistic that some traditional human review activities may reduce. But that does not mean humans disappear from the SDLC. It means the flow needs to change. Human involvement should move to the highest-leverage points, not necessarily the most familiar checkpoints. If humans stop reading code entirely, the organization’s ability to read code atrophies — and you still need that capability for incident response at 2am when the harness itself has failed. So even in the terminal state, we may keep deliberate code-reading practice alive somewhere (incident drills, periodic deep audits, the security tier)….

The PRD Is Back, But for a Different Purpose

Another interesting realization is around the PRD.

In the old traditional SDLC, PRDs were often thick documents that no one really wanted to write, no one really wanted to read, and no one really wanted to update. They were useful in some ways because they acted like a contract between users and developers, especially when something went wrong. But over time, many teams moved toward agile, user stories, and lighter documentation because heavy documents were too slow and often outdated.

Interestingly, in the AI coding era, the PRD seems to be coming back, just for a different reason.

It is not coming back as a bureaucratic contract. It is coming back as context infrastructure.

When we use AI agents across different sessions, the PRD becomes one of the most important documents for context sharing. It helps preserve business intent, user flows, rules, assumptions, edge cases, and decisions. The writing effort is also much lower now because AI can help draft, refine, and update it. So documentation becomes less painful, but much more valuable.

This is why requirement alignment becomes even more important. We have been trying different practices, including using AI to “grill” the requirement before implementation starts. The goal is not to create documentation for documentation’s sake. The goal is to reduce ambiguity before a very fast coding agent starts moving in the wrong direction.

In this sense, the PRD is no longer just for humans. It is also for the AI. if the spec, tests, and harness are independent and strong, the code stops being the asset. It becomes a build artifact, regenerable, disposable, a compilation target. The org’s real IP becomes the PRD, the test intent, and the harness…

Testing Becomes the Control System

The more we use AI coding, the more I feel testing becomes the single most important part of the AI-native SDLC.

We have seen cases where AI did something earlier and later dropped the constraint as the context shifted. From the user’s point of view, it feels like the AI “forgot”. Technically, it is probably more about context, attention, and what remains active in the working window. But from a delivery perspective, the risk is very real.

We have also seen cases where AI confidently defended an implementation that was actually wrong. That is not stubbornness in the human sense, but the effect is similar. If there is no strong validation loop, the model can anchor on a wrong assumption and continue building on top of it.

So testing becomes the real control system.

This is not only about writing more unit tests. Unit tests, integration tests, end-to-end tests, regression tests, and business-rule tests all matter, but they do not all serve the same purpose. Unit tests help protect local logic. Integration tests help protect system behavior. End-to-end tests help protect user journeys. Business-rule tests help protect the actual meaning of the product.

The harder question is not whether AI can generate tests. It can. The harder question is whether the tests are testing the right things.

I think AI can help generate many tests, but humans still need to spend a lot more effort validating test intent, especially for business rules, calculations, workflow behavior, permissions, and user expectations. Otherwise, there is a risk that AI writes the implementation and then writes tests that simply confirm its own assumptions.

This is where we are exploring what I would call a harness framework around AI coding. The purpose of the harness is not to slow AI down. The purpose is to create a reliable environment around AI coding so that speed does not become uncertainty. The harness should provide context, boundaries, tests, review, validation, and release confidence.

Maybe this becomes one of the most important engineering disciplines in AI-native SDLC: not only writing code with AI, but designing the harness that allows AI to write code safely.

UAT Still Matters, But It May Need to Change

UAT definitely still matters. The purpose of UAT has not disappeared. Firstly, we need to confirm that the product works according to the specification. Secondly, users need to see whether it is actually what they want.

But the way we run UAT may need to change.

If AI coding allows much faster release cycles, we probably cannot rely on traditional manual UAT for everything. We may need to separate two things more clearly. Machines can increasingly verify conformance to spec. Humans still need to validate whether the spec and product outcome are right.

That distinction is important. Automated tests and AI verification can help check whether the system behaves according to the agreed rules. But users still need to confirm whether those rules reflect the real business need, whether the workflow makes sense, and whether the product actually solves the problem.

So UAT may become less about users manually clicking through every possible case, and more about users reviewing the right scenarios, validating the right test cases, and focusing on the flows where human business judgment matters. AI can help generate UAT cases from the PRD and user stories, but business users and BAs may need to review those cases earlier, before the code is even written.

This is not just a testing question. It is also a trust question. Users need to trust the system, but they also need to trust the delivery process. With AI coding, that trust may need to be designed more deliberately.

Does the Scrum Iteration Still Make Sense?

Another question we are starting to think about is whether the traditional Scrum iteration still makes sense in an AI-native development flow.

This is not to say Scrum is no longer useful. But we should probably revisit why the sprint structure existed in the first place. In many teams, the sprint helped manage development bottlenecks. It gave the team a rhythm to clarify requirements, estimate effort, assign stories, build features, test, review, demo, and plan the next cycle.

But when AI coding compresses the coding part dramatically, the sprint starts to feel different. A two-week iteration may no longer be mainly constrained by how long it takes to write the code. Instead, the constraint may move to requirement clarity, architecture alignment, test readiness, UAT availability, release governance, and business validation.

So perhaps the role of Scrum also needs to evolve.

Maybe the iteration should become less about “how much code can we complete in this sprint” and more about “how much validated product learning can we safely move through the system”. The unit of progress may not be code completed, but requirements clarified, assumptions tested, business rules validated, test harnesses created, and production risk reduced.

This also affects how we think about user stories. If AI can implement quickly, the most important work may happen before implementation starts. A story may not be ready for AI implementation just because it has a short description and some acceptance criteria. It may only be ready when the team has enough shared understanding, enough architecture direction, enough test intent, and enough confidence that the AI agent will be moving in the right direction.

In this sense, Scrum may still provide a useful cadence for alignment, review, and learning. But the internal mechanics of the sprint may need to change. The bottleneck is no longer development capacity. The bottleneck becomes the team’s ability to create clear intent, validate quickly, and release safely.

When Coding Becomes Fast, Everything Else Feels Slow

Once code development is expedited, many other parts of the engineering system need to be reconsidered.

For example, our version control and branching practices were designed for consistency, collaboration, and safety, not necessarily for extreme coding speed. Trunk-based development works very well for many technology companies, but in an enterprise environment there are process, governance, and release challenges. Feature toggles can help, but they also introduce complexity. Then we need to ask whether the additional complexity gives back enough ROI.

The same applies to pull requests, release approvals, documentation, deployment controls, production support, and ownership. If AI can generate changes very quickly, the bottleneck may simply move somewhere else. We may move from slow coding to slow review, slow testing, slow UAT, slow release, or slow business validation.

That is why I feel AI coding is not only a developer productivity topic. It is an SDLC topic.

Exploring an AI-Native SDLC

This is also why the team is now drafting an AI-native SDLC for our second project. We do not have all the answers yet. This is still new and transformative.

One area we are actively testing now is the idea of a harness framework. The harness may include requirement grilling, PRD-to-test generation, architecture review checkpoints, AI-generated test specs, human validation of test intent, AI-assisted code review, automated regression checks, and release-risk summaries. The exact shape may still change, but the direction feels right: if AI coding is fast, the surrounding system must become more intentional.

We also recently came across obra/superpowers on GitHub, which looks like a very interesting direction for structuring coding-agent workflows. We may not yet fully understand how it works or whether it fits our environment directly, but the idea of composable skills, stronger planning, test-driven development, code review, and disciplined workflows around AI agents feels very relevant to what we are exploring.

That is exciting because it shows that the community is also moving from “AI can code” to “how do we build a better software engineering process around AI agents”. And maybe that is the real shift. It is not simply about plugging in Claude Code or Codex and expecting magic. The deeper we go, the more we realize that meaningful changes are needed across the whole flow. Requirements need to be clearer. PRDs may become useful again. Testing needs to become stronger. UAT needs to evolve. Code review assumptions need to be challenged. Scrum iterations may need to change. Version control and release practices may need to adapt. As we approach the finish line of our first AI-native project, one thing feels quite clear: Adopting Claude Code was the easier part, and reorganizing the process, team, and operation around it requires real transformation.

When one part of the flow suddenly becomes much faster, the whole system has to change. That is what makes this journey so interesting now. We are not just learning how to code with AI. We are learning how to engineer with AI.

More sharing from the team soon….