For the past two years, most of the conversations about AI and software development have centered on security: How do you ensure AI-generated code is secure? How do you prevent intellectual property from leaving the boundaries of your organization? How do you govern prompts, models, and data access?

These are important questions, but they are not the questions that will determine whether AI initiatives succeed or fail.

Organizations are discovering that AI is not just another developer productivity tool. It is an entirely new architectural layer within software delivery. When AI moves to production, the biggest risks are shifting from model outputs to system design.

“When AI moves to production, the biggest risks are shifting from model outputs to system design.”

In other words, AI won’t break your SDLC, but poor AI architecture very well could. 

We are repeating the early cloud adoption cycle

Anyone who worked through the first decade of cloud adoption has seen this movie before.

Everyone felt the pressure to move to the cloud as quickly as possible…and then the bills came. Costs ballooned, governance became increasingly complex, and workload portability became difficult. Some organizations responded by repatriating workloads or adopting hybrid cloud strategies to regain flexibility and control.

We’re seeing something similar play out with AI as some organizations are finding out the hard way what happens when AI usage expands from a handful of developers experimenting with agents to an enterprise-wide software delivery strategy. Every prompt for code generation, test creation, documentation updates, and validation activities consumes LLM inference and compute resources. As adoption scales, so do the associated costs, governance requirements, and operational complexity.

As more organizations move AI to production environments, there is growing consensus that AI must not simply be consumed as a service, but governed as a system with greater visibility and oversight.

The future isn’t one model; it’s an AI supply chain

Software delivery is not a single activity. It is a collection of specialized activities that span planning, coding, testing, validation, deployment, governance, compliance, and operations. Expecting one model to perform all of those functions efficiently is similar to expecting one service or one platform to manage an entire software stack.

Instead, AI-native software delivery will look like a supply chain.

Imagine a future development workflow where different AI systems are responsible for distinct stages of delivery:

• A planning model helps define requirements and generate user stories.
• A coding model generates implementation logic.
• A testing model creates unit and integration tests.
• A validation agent reviews outputs against requirements.
• Compliance agents ensure policies and regulatory controls are met.
• Governance systems monitor activity, costs, and model performance across the pipeline.

In this world, software delivery becomes an orchestrated network of AI capabilities rather than a dependency on a single model.

This shift is already visible in the broader conversation around agentic systems. However, discussions about agents often focus on what they can do rather than where they fit within software delivery and how organizations should govern them.

Why small models may do more work than frontier models

Large frontier models like Claude, Gemini, and GPT-5 can reason across domains, synthesize complex information, generate detailed plans, and tackle a wide range of tasks. But that doesn’t necessarily mean they are the best tool for every job in the software development lifecycle. In fact, most of the SDLC doesn’t require frontier intelligence. 

Star Wars actually offers a useful analogy here — C-3PO and R2-D2 are both intelligent machines, but they serve very different purposes.

Frontier models are the C-3POs of AI — highly capable generalists that can support a wide variety of tasks, but also resource-intensive and expensive to operate at scale. Most software delivery tasks, however, need an R2-D2: a specialized system optimized for a specific job. Software delivery doesn’t need one brilliant assistant. It needs a team of specialists.

“Software delivery doesn’t need one brilliant assistant. It needs a team of specialists.”

Organizations that rely on a single frontier model for every SDLC task will spend more, scale less efficiently, and have less control than those using specialized AI systems. Alternatively, a collection of specialized “R2-D2” models and agents could be optimized for tasks:

• A model focused solely on generating unit tests.
• A model optimized for code review.
• A model responsible for build validation.
• A model dedicated to compliance checks.
• A model trained to evaluate whether requirements have been met.

Many of these tasks don’t require the broad reasoning capabilities of a frontier model. They require consistency, speed, and specialization.

This doesn’t mean frontier models disappear. A large model might be used at the beginning of a workflow to help define requirements, map business objectives, or create an implementation plan. It might also be used at the end of the pipeline as an “AI judge” to assess outputs, validate quality, or verify compliance against organizational policies.

But much of the work in-between may increasingly be handled by smaller, specialized models that are cheaper to run, easier to fine-tune, and more predictable in their outputs.

AI control plans and orchestration bring governance into the pipeline 

Historically, software teams have often treated governance and compliance as downstream activities. Developers write code. Security teams review it. Auditors validate it. Compliance teams verify requirements after the fact.

However, when software is being generated, modified, tested, and validated by multiple AI systems, governance can no longer be a separate workflow. It must become an integrated capability embedded within the delivery lifecycle itself so organizations can easily track:

• Where AI is being used
• Which models are making decisions
• How outputs are validated
• Whether organizational policies are being followed
• How costs are being tracked and optimized
• How compliance requirements are being enforced

Essentially, as AI becomes part of software delivery infrastructure, governance can no longer be bolted on afterward. It must be designed into the system from the beginning.

“As AI becomes part of software delivery infrastructure, governance can no longer be bolted on afterward. It must be designed into the system from the beginning.”

As AI becomes embedded into every stage of software delivery, development teams will need a way to coordinate models, agents, policies, compliance requirements, testing workflows, and cost controls across an increasingly complex ecosystem. That’s why we’re beginning to see the emergence of AI control planes and orchestration layers that help organizations govern AI interactions, manage token consumption, and maintain trust across the AI-driven development lifecycle.

What’s next

Across the industry, we are seeing growing demand for:

• Reference implementations that show how frontier models, open source models, agents, data platforms, and governance frameworks fit together.
• Training to help DevOps teams understand how software delivery changes in an AI-native world and how to manage new workflows. 
• FinOps tooling to give visibility into AI usage and operational costs so leaders can make informed decisions.

Together, these capabilities provide something many organizations still lack: a practical blueprint for adopting AI in a way that is scalable, governable, and economically sustainable.

This is why the role of experienced technology partners is becoming more important, not less. What organizations really need right now is a strategy for integrating AI into software delivery without creating new forms of technical debt, governance gaps, or runaway costs. 

Ultimately, the competitive advantage will come not from any one AI model, but from having the right-sized architecture—and the right partners—to put all the pieces together.

The post Claude, Gemini, and GPT-5 can handle every SDLC task. Almost none of them should. appeared first on The New Stack.

Think about the last big feature you shipped. Be honest. Did you cram it into one giant pull request, or did you split it into smaller scoped pull requests? For years, you have silently had to decide between watching a pull request grow so large that reviewing it becomes a nightmare or breaking it into a chain of smaller pull requests that you have to babysit, sync by hand, and untangle conflicts every time a change is introduced below.

Both options have trade-offs. One is hard to review, while the other is hard to maintain. Your decision that day leans towards the less painful option.

Now add coding agents. They are incredibly productive and are projected to drive a 50% productivity gain across every SDLC stage by 2028, according to Gartner. But, they can’t take away the choice of how you structure your pull requests. They amplify the need to make it.

In this post, follow along with an example of how you can use stacked pull requests to simplify reviews.

A closer look: Adding product search to a shopping assistant

Let’s say you issue a prompt to add product search to a shopping assistant, walk away and minutes later, literally, you come back to review, steer, and approve. But look closely at what tends to land in that single pull request:

• A new data model and its seed data
• An API route and its validation
• The client wiring and the UI and the empty/fallback/error states

…all of this and more in one ginormous 1,000+ line diff.

For agents largely trained on how code has traditionally been written over the years, this pattern is their default way of shipping. Let’s play this out.

You want to add product search on as existing web application and your starting state is:

• A mock AI Assistant showing responses from a random-line generator
• Inconsistent product data hardcoded and scattered across components
• No catalog module, no API, no data layer—no nothing

An issue is opened to implement the feature, and a typical flow would be to create a feature branch, assign it to a coding agent (or multiple custom agents), get a first draft of the whole implementation code and updated tests…

…you read the code (well, you maybe read the code). Then, you still need to manually verify feature behavior and make any necessary updates, push and open a pull request with its long-yet-shallow AI generated description, ensure CI checks are green, and self-review diff then request reviewers. You get started…

<reviewer's hat>

Reviewer: 1,721 lines changed!! This description isn’t very helpful. I’ll review this later.

</reviewer's hat>

And what follows is familiar:

• The large pull request becomes hard to review—so it just…sits there.
• Reviewers lose context and the feedback quality drops.
• It becomes even slower to merge.

This kicks off a manual, messy, time-consuming process that’s prone to conflicts before the feature lands, and it eventually lands under-reviewed.

GitHub stacked pull requests

Stacked pull requests introduce a different and better structure of delivery. The principle is simple: decomposition. Instead of shooting for a single pull request that addresses the issue in its entirety, you break down the feature into logical layers and identify the dependency chain to arrive at your desired goal. This gives you, and your agents, a native way to decompose work that otherwise lands in a giant pull request into a chain of small, focused and independently reviewable layers.

That large pull request that’s hard to review becomes a stack of smaller, logically ordered pull requests, each scoped to a single concern, small enough to hold in a reviewer’s head and with just enough context naturally flowing from the previously reviewed pull request.

Let’s make it happen.

The stack structure

Let’s look at the steps involved when decomposing the problem and arranging the layered stack.

First, and importantly, set the stack base. This matters because CI checks and merge rules throughout the stack management lifecycle get evaluated against the stack base.

Then, identify the core foundational unit of work and put it closer to the base (lowest in the stack), and layer dependent work above it.

Now the independent concerns are clear: data, API, wiring, UX, making it possible to allocate different reviewer audiences for each. Data is reviewed by a data owner, UX by a UI owner.

GitHub’s native support for stacked pull requests can be launched from the pull request UI and extends seamlessly to the terminal with the gh stack CLI.

Install the stacked pull requests CLI extension

Run the following:

gh extension install github/gh-stack

In ancient times, you’d be set to start working. Not today though. There are agents working alongside you. These agents need to learn how stacks work and how to create and manage them on your behalf. The gh-stack skills teaches them this.

gh skill install github/gh-stack

Or, if you prefer:

npx skills add github/gh-stack

For the specific feature from the above example, your development workflow has custom agents, each with defined work streams and that follow a strict scoping discipline to achieve the goal of small, single-scoped pull requests.

The last piece of the setup is to confirm CI exists. As mentioned earlier, each pull request will be evaluated against the stack base, and these checks will run for every layer.

Now the work begins.

Layer one: Data catalog foundation

Most agent workflows today are automated and execute autonomously in loops, but for the sake of illustration, we’ll cover each step at a time.

At this point, all agents are familiar with how stacked pull requests work, so a typical workflow at this stage would be:

1. Invoking the Data Modeler agent with an appropriate prompt
2. The agent initializes a new stack and sets the first branch—feat/catalog-data with main as its base using gh init stack
3. Checks out, works and runs validation
4. (All checks == green) ? commit the layer : Iterate

Reviewer’s note for the future: Are the types correct? Is the data validated? Is the query helper safe? Period.

Layer two: Product search API

Follow a flow similar to:

1. Invoking the Backend agent with an appropriate prompt
2. The agent adds the next layer feat/search-api on top of layer one, its base: feat/catalog-data, to import the completed data access module with gh stack add
3. Checks out, works and runs validation
4. Developer tests the API manually
5. (API works && All checks == green) ? commit the layer : Iterate

Reviewer’s note for the future: Is input validated? Is the response contract stable? Are error/empty states handled here or pushed downstream? Period.

Layer three: Wire chat to the API

In this next layer, you:

1. Invoke the Frontend agent with an appropriate prompt
2. The agent adds the next layer feat/chat-grounding on top of layer two. Its base: feat/search-api, which will branch off with both the data access module and validated API.
3. Checks out, works and runs browser tests with Playwright
4. (All checks == green) ? commit the layer : Iterate

Reviewer’s note for the future: Is every answer tracing back to a real API response? What happens when the API fails or returns nothing? Period.

Layer four: Grounded UI and citations

You’ll notice that layer three and layer four, despite having the same author, (Frontend agent), are layered distinctively. This is deliberate. The UI owner should not have to check the underlying data flow and vice versa, and this structure allows for that independence.

So, the frontend agent:

1. Adds the next layer feat/grounded-ui on top of layer three, its base: feat/chat-grounding
2. Checks out, works and runs browser tests with Playwright
3. (All checks == green) ? commit the layer : Iterate

Reviewer’s note for the future: Does every citation link back to a real product? Are loading, empty and error states all covered? Period.

Submit the stack

The four local stacked branches are ready. Next is to push them to remote with gh stack push, then create pull requests linking them on GitHub with gh stack submit.

The stack map and CI on each layer

Switching over to GitHub, all four pull requests are open and at the top of each one, you see a stack map, which is a one-click navigation system between pull requests in the stack.

Reviewing and updating the stack

Time to switch hats and look at a reviewer’s journey through stacked pull requests.

<reviewer’s hat on>

The stack map is a reviewer’s compass – a navigation aid between the top of the stack and its bottom, heading towards a successful merge. The movement is directional: read top-down, review bottom-up.

• Read top-down, for context. This gives you the end goal at the very beginning of the review process, so you can set a bearing. “Oh, so we want to display product cards on the chat interface.”
• Review bottom-up to build on the predetermined checkpoints. The implementation on each layer only makes sense once the preceding layer is understood.

You are no longer looking at a single 1,720+ line-sized pull request to be reviewed in one sitting, as we saw in our example, but instead, the review can be distributed in small, self-contained targets in a stack.

As the assigned human in the loop reviewer, you come in and look at layer one, the pull request at the bottom of the stack, and see that the automatic Copilot Code Review (CCR) caught two issues which you agree should be fixed.

<developer's hat back on>

Changes are requested at the bottom of the stack, so you:

• Hand the feedback to the layer one author, data modeler agent that owns the branch
• Suggestions are applied, tested, committed and pushed
• Once the fix lands on feat/catalog-data, the natural next question is: what does this mean for layers two, three, and four?

Since branch feat/catalog-data was pushed out of turn after the review, GitHub flags it plainly: “Some branches in this stack have diverged and must be rebased” paired with “Unable to merge as a stack” flag and that blocks the merge.

Back on the pull request UI on GitHub, a one-click Rebase stack button appears. Before using the button, there is something important worth noting. Triggering a web-based rebase using this button runs it on GitHub’s servers, which means it resets the committer to whoever clicked the button, the resulting commits aren’t signed, and if branch protection expects signed commits, that one click quietly breaks.

The safer, equivalent move from the terminal would be gh stack rebase to perform that same cascading rebase locally as you interactively resolve conflicts, but this time using your own Git configuration, then gh stack push.

Finally, you’ll propagate through the stack. The rest of the stack, both local and on GitHub, now needs to catch up, and it couldn’t be easier than a single sync command gh stack sync.

An all-in-one flow starts with fetching from origin, cascading a rebase of every branch above feat/catalog-data onto the new commit, pushes the rebased branches and syncs pull request state from GitHub. This way, the change ripples upward without anyone touching layers two, three, or four by hand.

Back on GitHub, all checks re-run, pass and the stack map settles back into a clean, mergeable line from main to feat/grounded-ui.

The post Turn one giant AI-generated pull request to a reviewable stack appeared first on The GitHub Blog.

Did you know? Ever wondered why C# uses the semicolon to terminate a statement? Obviously it comes from the C/C++ heritage it shares with other languages like Java, but where did C get it from? That would be Algol, where the semicolon was used to separate statements. 

But why the semicolon? In natural language grammar, the semicolon separates two independent but related clauses; it can also be used to separate items in a list (see what I did there?). And what is a program but a list of independent but related clauses?

(Bonus punctuation trivia: the comma is used to separate items in a list, just like the arguments in a function call. The period is used to end a complete thought, like a sentence or paragraph. How did Algol mark the end of a program unit? Why yes, with a period!)

Welcome to dotInsights by JetBrains! This newsletter is the home for recent .NET and software development related information.

🔗 Links

Here’s the latest from the developer community.

1. Nullable GUID Route Constraints in ASP.NET Core – Sebastian Nilsson
2. Closed class hierarchies: Exploring the .NET 11 preview – Part 4 – Andrew Lock
3. No more regressions with Snapshot Tests in C# using Verify: a practical guide – Davide Bellone
4. HttpClient Streaming in C#: HttpCompletionOption, ReadAsStreamAsync, and Server-Sent Events – Nick Cosentino
5. Building a Windows Tray App by combining Microsoft.UI.Reactor and a Worker Project – Morten Nielsen
6. Windows 11 can now run Linux containers with WSL Containers, no Docker Desktop needed (hands on) – Abhijith M B
7. Add vs AddRange in EF Core: The Performance Myth You Need to Stop Repeating – Chris Woodruff
8. Code review is theater now – John Bristowe
9. The .NET Host Process: What Runs Before Main() and Why It Sometimes Hangs – David McCarter
10. Worse is better: JSON versus XML – Mark Seemann
11. The best code is the one you shift+delete – Oren Eini
12. The Docker CLI Commands I Actually Use Every Day – James Joyner
13. Migrate Your WPF App to the Web, From Your Browser – XAML.io Team
14. How to Build a Dark Mode Toggle Without JavaScript – Jakub T. Jankiewicz
15. The role of ActivitySource in OpenTelemetry for .NET – Bart Wullems
16. Track every EF Core record change with temporal tables – David Grace
17. The Complete Guide to Tool Selection in AI Agents – Shittu Olumide
18. Coffee and Open Source Conversations – Jimmy Bogard – Isaac Levin
19. Available Now in .NET 11 for .NET MAUI – Leomaris Reyes
20. Multi-Tenancy Isn’t About Databases – Derek Comartin
21. Composition Ring Spinner [Avalonia] – Stefan Koell
22. C# Async/Await Made Simple – Lou Creemers
23. How to Log JSON Without Turning Your Terminal Into a Wall of Text – JavaScript Tools
24. What is a webhook? Endpoints, examples, and how they work – Jesse Sumrak
25. C# Tip: Use required members to prevent invalid object initialization (beware of SetsRequiredMembers attribute!) – Davide Bellone
26. You’re Already Using .NET’s ChangeToken (You Just Don’t Know It) – Khalid Abuhakmeh & Al Rodriguez
27. Zero-Code Validations in Your .NET API – Pavel Kalandra
28. A gentle introduction to Git worktrees – Nicholas C. Zakas
29. Stop Using Singletons in Unity | Game Systems Explained – Stacey Haffner
30. Guidelines for URL Storage and Comparison – Eric Lawrence
31. Dijkstra’s Shortest Path Algorithm – Kirupa Chinnathambi
32. TimeProvider and the End of Untestable DateTime.Now – Maarten Balliauw
33. Stop Accepting Breached Passwords: Integrating HaveIBeenPwned with Duende UserManagement – Al Rodriguez & Khalid Abuhakmeh
34. .NET Aspire: The price of forgetting WithReference – Bart Wullems

☕ Coffee Break

Take a break with something a little more fun.

DoomPaint – Doom using MS Paint as a playable display by leveraging clipboard and paste. Includes Doom shareware and plays with music and sound effects – Mark Russinovich. Don’t ask why. There is no why. It just is.

Yes, that’s a trailer for the Java Story in a .NET newsletter, but who doesn’t love a geeky bit of history, right?

200+ Funny Software Developer Puns and Jokes That Only Coders Will Truly Get – brace yourself

🗞️ JetBrains News

What’s going on at JetBrains? Check it out here:

• We’ve released the 2026.2 wave of dotUltimate tools – Rider 2026.2, with lots of goodies, including new skills and quality check hooks for agents, Hot Reload for WPF, TypeScript 7 support, improved game dev features for Unreal Engine and Godot. ReSharper 2026.2 gets Junie support, as part of our move to an open AI platform thanks to ACP. It also gets out of process mode enabled by default, so most of ReSharper runs outside of the Visual Studio process.
• ReSharper for Visual Studio Code 2026.2 was released, and now includes the #1 requested feature – debugging! As everyone knows, debugging is only half the story, so read Isaac’s first blog post detailing how ReSharper can help you write C# inside not just VS Code, but all other compatible editors (Cursor, Google Antigravity IDE, Devin Desktop, Kiro, and others). Check it out on the Marketplace or the OpenVSX Registry.
• We’ve announced our annual gamedev day for September 28. Make sure to save the date, and send us proposals for sessions!
• And finally, continuing our series of evaluating skills that claim to reduce token usage, we take a look at the Ponytail skill. Does it really reduce agent code by 54%? #QTWTAIN (You can also check out our evaluation of the rtk skill – does it really cut agent tokens by 60-90%? You might be able to guess from the hashtag…)

✉️ Comments? Questions? Send us an email.