Cassidy and GPS are joined by Camilla Moraes, a product manager on GitHub's Maintainer Love (aka Tiny Wins) team, to talk about how the team finds and ships small, high-impact fixes for open source maintainers. Camilla walks through her path from engineering to product, and shares how the team's focus shifted this year from quick two-to-three-week "paper cuts" to a bigger, all-hands problem: the rise of low-quality, AI-generated contributions flooding repos. Camilla gives some insight into a new tool the Tiny Wins team has designed to address that issue: PR limits, which lets maintainers cap how many open PRs a user without write access can have at once. The group also talks through how the team prioritizes an endless stream of feedback from Slack, socials, and surveys, and how Camilla built her own repo-as-a-database system with Copilot to track it all. They close out with three open source picks: iOpenPod, Bento, and Camilla's own vibe-coded project for rating the health of a GitHub repo.

Links mentioned in the episode:

• Maintainer Community
• iOpenPod
• Bento

 

The GitHub Podcast is produced and edited by editaudio.

Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.

Download audio: https://afp-920613-injected.calisto.simplecastaudio.com/98910087-00ff-4e95-acd0-a3da5b27f57f/episodes/7b403926-dbe3-4835-9666-ccfb5f5fbe01/audio/128/default.mp3?aid=rss_feed&awCollectionId=98910087-00ff-4e95-acd0-a3da5b27f57f&awEpisodeId=7b403926-dbe3-4835-9666-ccfb5f5fbe01&feed=ioCY0vfY

---

You're tired of hearing that you need to pick up AI, so today I'm not going to add to that pile. Instead, we'll look back at two moments in history that look a lot like this one: the arrival of Fortran in the 1950s, and the spread of autopilot in commercial aviation. Both show how new abstractions change the shape of our work without being purely good or purely bad.

You've heard plenty of engineering leaders tell you to use more AI and more agents, often in a way that seems out of touch with your day-to-day work. I'm not going to add to that today. Instead, I want to share some history. If it feels like our industry is in a completely unique moment, it helps to look at earlier times that had a similar shape. In this episode, I look at the early skepticism around Fortran and the effects of autopilot on pilot skill. Then I explain why a dualistic "good or bad" view of AI leaves out most of what is actually happening.

• Fortran and the Skeptics: In the 1950s, Fortran became widely known as the first high-level language, generating machine code so programmers didn't have to write it by hand. Skeptics doubted it. John von Neumann reportedly questioned why a serious scientific machine should do "clerical work," and many engineers didn't trust the generated code.
• The Critics Were Partly Right: Early generated code wasn't very good and needed a lot of massaging. The Fortran team didn't go back to the old way. They put their effort into improving the new abstraction. The criticisms of the new tool became the fuel for making it better.
• Autopilot and Cognitive Saturation: Commercial aviation is one of the safest forms of travel, and automation is a big reason why. Taking the manual work of flying off the pilot frees up mental capacity for radio calls, navigation math, and diagnosing problems. That adds a safety margin to every flight.
• Children of the Magenta Line: Automation also brought a new risk. When pilots rely on GPS and autopilot, their manual flying skills can atrophy, and that matters in the rare cases where the automation fails. Something similar can happen to engineers who lean heavily on tools like Claude Code. Some might choose to work in their codebase without AI now and then, or practice LeetCode-style problems, just to keep those skills sharp.
• Beware Dualistic Thinking: New technology rarely pushes things in only one direction. It brings new easier things and new harder things, more quality and new risks to quality, skill atrophy and room to focus on completely new problems. Whenever you catch yourself framing something as a simple good-or-bad duality, ask whether your brain is just trying to make it easier to understand.
• A Warning for Team Leaders: It's a mistake to push agents into your existing workflow as if they were a simple accelerant. These tools change who is attracted to the work. They may draw in new people who were never interested in engineering before, and they may push away engineers who loved the job as it was five years ago.
• Where This Is Probably Headed: If this follows the pattern of past technological revolutions, today's rapid pace will eventually level off. The unreliability we see now is likely to drive future reliability, and wider adoption tends to follow once tools stabilize. In the meantime, the fatigue is real, and it's worth paying attention to what it's doing to your mindset.
• Episode Homework: Pick one opinion you hold about AI in your work. Ask yourself whether you've framed it as all good or all bad, then list the new risks and new opportunities it creates together.

📮 Ask a Question

If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

📮 Join the Discord

If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

🗞️ Subscribe to The Tea Break

We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

🧡 Leave a Review

If you're enjoying the show and want to support the content head over to iTunes and leave a review!

Download audio: https://dts.podtrac.com/redirect.mp3/cdn.simplecast.com/audio/c44db111-b60d-436e-ab63-38c7c3402406/episodes/fe5f9037-67e5-4b46-a964-2089be6242ab/audio/f64410b1-4cc8-4ef5-a1fe-8145fad5d9b2/default_tc.mp3?aid=rss_feed&feed=dLRotFGk

Some of the world’s most critical databases run in places where cloud connectivity cannot be assumed. A remote industrial site, for example, may need production systems to continue operating when external connectivity is unavailable. A regulated organization may need sensitive data and processing to remain within sovereign boundaries.

Today, SQL Server on Azure Local is generally available for connected and disconnected operations. With this release, customers can modernize where their data resides while maintaining control over infrastructure, connectivity, and data placement. They can bring AI closer to their data with Foundry Local on Azure Local, currently in preview, and use eligible existing SQL Server licensing investments.

Explore SQL Server on Azure Local
Run SQL Server where your data needs to stay
SQL Server has a long history of supporting mission-critical workloads on customer infrastructure. Azure Local builds on that flexibility by bringing Azure infrastructure to customer-owned environments, giving organizations a consistent platform for running SQL Server across datacenters and edge locations.

Customers can choose the deployment model that fits each environment:

Connected environments: Run SQL Server locally on Azure Local, while using Azure Arc to manage SQL Server resources through Azure.
Azure Local Disconnected Operations (ALDO): Run SQL Server in environments where external connectivity is restricted, intermittent, or unavailable, with operations continuing locally.
This means organizations can choose the deployment approach that fits the requirements of individual environments rather than making the same connectivity decision across their entire data estate.

SQL Server on Azure Local – connected and disconnected operations.
Bring AI closer to your data
Modernizing infrastructure is only part of the opportunity. Organizations also want to bring generative AI to existing enterprise data, including information that cannot leave their environment.

With Foundry Local, customers can run AI models on Azure Local infrastructure alongside SQL Server, bringing inferencing closer to the data. This enables organizations to explore AI-powered applications while keeping sensitive information and processing within their environment.

This can be particularly valuable in sovereign, regulated, and edge scenarios, where organizations want the benefits of AI but need greater control over where models execute and where their data is processed.

The goal is simple: customers should not have to move sensitive data somewhere else simply to begin building intelligent applications around it.

Build on your existing SQL server investments
Modernization should also make it easier to build on existing investments.

SQL Server is licensed separately from the Azure Local infrastructure platform. For connected deployments, customers can use eligible existing SQL Server licenses, including licenses with Software Assurance or qualifying subscriptions, or use pay-as-you-go licensing through Azure Arc.

For fully disconnected deployments, customers can use eligible existing SQL Server licenses through Azure Hybrid Benefit.

This gives organizations options to modernize their SQL Server environments while taking advantage of eligible licensing investments they already own.

A foundation for sovereign and edge data
Enterprise data estates increasingly span cloud, datacenter, edge, and sovereign environments. The opportunity is not to force every workload into the same deployment model, but to give organizations a consistent path to modernization across them.

SQL Server on Azure Local extends that choice to mission-critical SQL Server workloads, helping customers modernize close to their data, applications, and operations while bringing Azure-consistent infrastructure and local AI capabilities into those environments.

SQL Server on Azure Local FAQ
What is SQL Server on Azure Local?
SQL Server on Azure Local lets organizations run SQL Server on Azure Local infrastructure in their own datacenters and edge locations. It supports SQL Server workloads on virtual machines running Windows Server or Linux.

What is the difference between connected and disconnected deployments?
Connected deployments use Azure connectivity and can use Azure Arc to manage SQL Server resources through Azure. Disconnected operations are designed for environments where external connectivity is restricted, intermittent, or unavailable, with operations continuing locally.

Who should consider SQL Server on Azure Local?
It is designed for organizations that need local control because of sovereignty, regulatory, latency, operational continuity, or edge requirements, including public sector, defense, financial services, healthcare, manufacturing, energy, and other regulated or connectivity-constrained environments.

Can customers use existing SQL Server licenses?
Eligible existing SQL Server licenses can be used according to applicable licensing terms. For connected deployments, customers can also use pay-as-you-go licensing through Azure Arc. Fully disconnected deployments use eligible existing licenses through Azure Hybrid Benefit.

Can organizations run AI close to their SQL Server data?
Foundry Local on Azure Local brings AI inference to Azure Local environments and is designed to keep data processing on-premises. As of September 29, 2026, Foundry Local on Azure Local is currently available in preview, so availability and capabilities may change before general availability.

Where can I find deployment guidance?
Microsoft Learn provides guidance for deploying SQL Server on Azure Local, including hardware selection, SQL Server installation, monitoring, performance tuning, high availability, and related Azure hybrid services.

Get Started with SQL Server on Azure Local
SQL Server on Azure Local is generally available for connected and disconnected deployment scenarios.

SQL Server on Azure Local – Overview
Deploy SQL Server on Azure Local
Deploy SQL Server on Azure Local Disconnected Mode
Learn more about Azure Arc-enabled SQL Server
Additional resources

Manage SQL Server licensing and billing with Azure Arc
Foundry Local on Azure Local overview
Foundry Local deployment overview

The post SQL Server on Azure Local is now generally available appeared first on Microsoft Azure Blog.

The HttpRequestExtensions class in DotNetTips.Spargine.Extensions offers reusable methods to streamline HTTP request handling, enhancing code maintainability and consistency. Key functions include reading request bodies, managing headers, extracting bearer tokens, and validating content types. This utility supports input validation and unit testing, improving code quality in applications.

One inescapable conclusion I’ve had to draw observing our industry over the last couple of years is that the AI thing isn’t about productivity. If it was, teams would be looking for ways to improve outcomes. But that’s not what I’ve been seeing.

I’ve seen dev teams setting out with the specific goal to use AI coding agents as much as possible, with the impact a secondary (or even a thirdary) concern.

I’ve watched developers prompting Claude Code to rename classes or methods when there’s a shortcut in their editor that will do it with a fraction of the keystrokes, using a tiny, tiny fraction of the compute and the energy, and do it more reliably.

I’ve watched them task Copilot with finding unused code when background compilation has already identified it.

I’ve watched them explain the code they want to Codex in more words than the code itself, and the model still gets it wrong.

Arguably these people have lost the plot.

And there are those other teams; the ones who use the best tool for the job. Need a refactoring? IntelliJ or Rider or PyCharm’s got you covered most of the time. Wanna know where the unused code is? Your IDE’s showing you. And if you don’t have that feature, a linter will do it lickety-split without the need for a £20,000 GPU and a terabyte of VRAM. If you know what code you need, maybe just write it. M’kay?

And then they hit a gap in their tooling. They need to move an instance method in Python. PyCharm doesn’t have that refactoring. So they go the agent window:

> Move the method calculateDiscount from the Order class to the Product class

And – 90% of the time – the model will do what they need. (And, annoyingly, sometimes more than they need.)

To perform the refactoring by hand would usually take longer, so they make a rational choice to throw the dice if it will save some time.

These are the teams whose outcomes have improved. Lead times and release cycles have shrunk a little, and it hasn’t been at the price of reliability.

And that’s what this is supposed to be about, right? Better outcomes. Bang for the buck. Or should I say “Bang for the token”?