I “built” a demo system in the background today while getting my other work done. It was fun to dip in every half hour and review the agent’s progress, ask questions to better understand what happened, and then approve the next steps. I could get used to this.

[article] Do you really need another framework? Maybe? This is one for your context and whether you’re giving an agent anything good.

[article] CAFE(S): Your Agent Is Only As Good As Its Context. Learn more about the above framework by reading this paper from us and others.

[blog] EmbeddingGemma 2: an open, lightweight multimodal embedding model. Very unique, and potentially very useful. Work entirely locally on device and across modalities (text, image, video, and audio).

[blog] AI For The Public Interest: What A Quarter Century Of Global Television News Can Teach Us About Our World. What if you ask AI to watch decades of television news across 75 countries? That’s a fascinating pool of data for insights.

[blog] The 4 levels of agentic software development. For most companies, their differentiator won’t be model capabilities; it’ll be how they change the way software is built. These four levels factor that in.

[article] Mistral debuts Large 4 ‘Le Chonk’, a 1-trillion parameter text output model with high benchmarks planned for open weights release. Top tier naming. Le Chonk. The numbers look impressive here, which is only good for buyers.

[article] There’s No Such Thing as an AI-Ready Culture. These are five dimensions to look at, but no exact “right” culture, but there are muscles to build.

[blog] How To Stop Getting Taken Advantage Of: 6 Secrets From Game Theory. Most of us could use this advice. Acting too nice or avoiding conflict? That probably means you’re losing in every situation.

[article] Knowing which vulnerability to fix first. Because you probably can’t get them all, you need to think carefully about which vulnerabilities to focus on.

[blog] The results of the 2026 Developer Survey are here! Still a big deal, even with StackOverflow down from its former glory. Many insights into developer adoption and trends.

[blog] Data is the application. Interesting POV. With agentic coding you can make or remake just about everything in no time. But data? The lack of it, or management of it, requires more care.

[blog] Cloud Run’s invisible 60% scaling dials are now yours to control. With good software, the default configuration values are set where they are for a reason. But you may want to override them based on what you know about your system.

[blog] Beyond synthetic testing: Capturing and replaying real database workloads at Airbnb. I love engineering blog posts like this. Here’s how Airbnb updated their query capture system.

[blog] Two-Way Doors: Don’t Code Yourself into a Corner. Don’t over-engineer everything for ultimate flexibility, but also don’t paint yourself into a corner.

Want to get this update sent to you every day? Subscribe to my RSS feed or subscribe via email below:

We developers know just how fast computers can be, and we want to feel that speed in our tools. Waiting for language support to load, builds to complete and tests to run is time we could better spend in other ways.

As part of .NET 11, C# Dev Kit has been completely rearchitected to deliver huge improvements to performance and memory usage. It also has some great new features.

This is the first in a series of blog posts covering the improvements in C# Dev Kit 11.0. In this post we will cover the improvements at a high level, and future posts will dig into the details for those who are interested.

We are aligning C# Dev Kit’s version with the current release of .NET. The new extension version is 11.0, and the previous was 3.3.

Let’s see what’s new.

Faster loads

We measured load times on two real solutions: Orleans (155 projects) and Aspire (407 projects).

Solution	Projects	What’s ready	C# Dev Kit 3.3	C# Dev Kit 11.0	Faster by
dotnet/orleans	155	Active file	up to 50.3 s	0.53 s	up to 95×
		Whole solution	50.3 s	2.3 s	22×
dotnet/aspire	407	Active file	up to 84.1 s	0.47 s	up to 180×
		Whole solution	84.1 s	3.0 s	28×

The table shows two moments during load. Active file ready is when language support is available in the file you are editing, with completions, diagnostics, go to definition, and quick fixes. This is the point at which you can do real work. Whole solution ready is when every project has finished loading, so language support works in any file, tests across the solution are discovered, and find all references works across all projects.

C# Dev Kit’s new project caches contribute to this faster loading. It no longer rebuilds its understanding of every project on every open, so language services, tests, and launch targets are available almost immediately. It now loads the active file first, so you can start working there while the rest of the workspace loads in the background, with performance that’s constant, regardless of the project count. The previous implementation loaded projects in a fixed order, so load times depended on where the file fell in that order.

A project’s cache is built the first time that project is loaded. Every load after that is served from the cache, and is fast. If you commit your cache files to version control, then fresh clones and new git worktrees will have fast tooling support immediately, which is great when working with agents.

We also shortened load time by consolidating several processes into a single one. The previous version launched six managed processes that each had to pass AV checks, load images from disk, perform JIT (minimised via ReadyToRun), then connect to each other. All of this had to happen before they could answer a single question about your code.

This consolidated CSDevKit process is a native executable, compiled ahead-of-time using .NET’s Native AOT. It begins running immediately, with no runtime to load and no just-in-time compilation on the startup path.

Cached data, fewer processes, and Native AOT mean a more responsive development experience. Future posts in this series will explore those topics in more detail.

Faster builds

C# Dev Kit 11.0 has much faster incremental builds thanks to fast up-to-date checks and Build Acceleration, two features that Visual Studio developers have had for a while.

We’ll use the 407-project Aspire solution again, building the whole solution each time.

Changes to build	C# Dev Kit 3.3	C# Dev Kit 11.0	Faster by
Nothing	34.4 s	0.88 s	39×
Single C# file	36.1 s	2.1 s	17×

In 11.0 we cut the overhead of working out what changed, and of copying output files.

Build times depend on the structure of the solution, so not every build will see such huge gains. However, it is common to build only a few changes at a time, which is the scenario that sees the greatest improvement in 11.0.

The improved responsiveness is noticeable when running unit tests and when launching apps. Both of these operations perform a build before starting, so in 11.0 they complete sooner.

Memory

The previous architecture spread C# Dev Kit’s internal services across six interconnected processes. This release consolidates those processes into a single server, compiled with Native AOT.

Solution	Projects	C# files	C# Dev Kit 3.3	C# Dev Kit 11.0	Reduction
dotnet/orleans	155	4,010	1,307 MB	208 MB	~84%
dotnet/roslyn	398	18,153	2,000 MB	379 MB	~81%
dotnet/aspire	407	4,686	2,072 MB	316 MB	~85%

Memory use tracks the size of the codebase more than the number of projects. Roslyn has around four times the C# of Aspire, so its server uses more memory even with fewer projects, while the compact project model keeps memory growing far more slowly than the code itself.

These figures represent the memory allocated by the C# Dev Kit server’s process(es). The C# language service (Roslyn) runs in its own process as before, and Visual Studio Code has its own footprint. Neither is represented in this comparison; both are largely unchanged in this release.

Version 11.0 has a more compact in-memory representation of the project, which reduces memory use considerably, especially for large solutions. Native AOT also uses less runtime memory.

Editing projects and other MSBuild files

C# Dev Kit 11.0 includes a new editing experience for .csproj, .props and .targets files. You get completions, diagnostics, go to definition, quick fixes, and semantic highlighting: the same kind of language support you expect when editing C# code.

Completions are now offered for package names and versions:

Packages also have a CodeLens entry that offers some convenient actions. It highlights when newer versions are available, and when the version being used has a vulnerability.

MSBuild language support is not limited to packages. Completions cover properties, items, and metadata keys. Go to definition works on several language elements, and can take you into SDK source. Diagnostics flag problems as you type, and quick fixes offer corrections.

Health checks with the C# Doctor

Also new to C# Dev Kit is the C# Doctor.

When a project fails to load or behaves in a way you did not expect, the cause is often environmental. A required SDK is missing, a runtime is not installed, a target framework is not available, package restore failed, or a referenced package has a known vulnerability. The C# Doctor collects those checks in one place and guides you towards a good solution, rather than leaving you to reconstruct the cause from separate error messages. It simplifies getting the tooling and configuration you need to have your projects work with C# Dev Kit.

What’s next

The role of the IDE is changing. As developers adopt new workflows, we keep finding where our tools fall short. When developing with agents, we need to get in and out of our tools much faster, and we need to be able to run multiple instances in parallel. The architectural changes we’ve made in C# Dev Kit 11.0 set the extension up for the years ahead.

These are improvements to the fundamental aspects of the tooling, which are helpful to both human developers and the agents they’re waiting for.

We are making longer-term investments in these components, looking to make them available in even more environments, driving more consistency and performance through the ecosystem. Stay tuned for updates in this space.

The next blog posts in this series will dive into the simpler architecture, the Native AOT server, cached project loading, and faster builds.

Try it out

C# Dev Kit 11.0 is available now in pre-release, so the quickest way to see the difference is to update and open one of your own solutions. We hope you’ll find it faster and easier to use.

After installing, select Switch to Pre-Release Version on the C# Dev Kit page in the Extensions view to opt into the pre-release channel and see these improvements.

We’re working hard to get it ready for release on the stable channel, and your feedback will help shape that effort. You can file bugs and suggestions on GitHub.

The post A faster, lighter C# Dev Kit appeared first on .NET Blog.

Every day on GitHub, millions of developers build the products their customers rely on, contribute to open source, and pursue personal projects. GitHub’s architecture has changed steadily over the years to support that work and the growing demands of the developers and organizations who depend on it.

Agentic software development is driving the next architectural shift. With developers and agents working concurrently in repositories that receive millions of commits a day, these workloads demand a different Git architecture. We’re rebuilding GitHub’s Git infrastructure to support them. This post explores the demands shaping that work and the design principles behind it.

Today’s highest-volume workloads show the scale we’re building for. The gap between a typical repository and the busiest ones is wider than most people expect. Here’s a rough picture of the monthly repository activity distribution on GitHub from August 2026:

Repository activity climbs sharply at the far end of the distribution. The busiest repository on GitHub saw roughly a billion requests in August.

Beyond these highest-volume workloads, total Git activity on GitHub is also growing rapidly: between September 2025 and August 2026, it increased to more than 2x its previous level, from 218.2 billion events per month to 473.3 billion.

In September alone, developers and agents made 7.38 billion commits on GitHub, more than five times as many as a year earlier.

The repositories at the top of this curve show what agentic development looks like at its leading edge: large engineering teams running busy CI pipelines alongside growing fleets of agents. Supporting these teams means building Git infrastructure for sustained, concurrent reads and writes at a scale few repositories reach today. We’re investing deeply in Git infrastructure to meet the demands of agentic software development and give teams a foundation built for their most ambitious workloads.

Building for this scale means addressing several architectural challenges:

• Commit turnaround becomes a bottleneck per agent. An agent in a tight loop commits or checkpoints after nearly every action. Its speed is bounded by how fast a single push completes, so latency that a human would never notice becomes the limiting factor.
• Write throughput demand is increasing by orders of magnitude. Pushes grew 4.9x year over year, from 0.69 billion to 3.35 billion per month. Thousands of agents working on their own branches in one repository produce a sustained write rate that converges on a single point in our architecture.
• Merges contend on one reference. Trunk-based development, release trains, and merge queues funnel all that work onto a single ref that has to absorb every merge. Pull request merges on GitHub grew to nearly 4x their volume a year ago.
• Each push multiplies into thousands of reads. For example, CI and code scanning clone or fetch the same branch tip thousands of times per minute, and that fan-out has to be cheap. GitHub Actions alone ran 3.26 billion times in September, more than 4x as many as a year ago.
• Operations on a repository must continue to be fast. To keep them fast, we continually compact repository data and clean up objects that are no longer needed. Every new write adds to that work, and the cost compounds as volume climbs.

This is why fast clones only solve part of the problem. Reads are relatively easy to scale: add caches, add replicas, and serve the same bytes to more clients. Scaling reads is essential, but these workloads require more than that. Writes are way harder. Every push has to be stored durably and made visible consistently before the next agent or CI job can build on it.

Where today’s architecture meets new demands

The current architecture has served developers well for years. Every repository is stored by Spokes, which keeps a full copy on the local disks of several fileservers, five by default. Those fast local disks let Git operations read native repository data with low latency, and the extra copies provide redundancy while spreading reads across fileservers. When a push updates a reference, a three-phase commit protocol uses a quorum to ensure that CI, the web UI, and API clients see a consistent repository state. That pairing serves a billion repositories today.

However, the mechanism we use for durability is the same one we use for scale. The copies on disk are the source of truth, so adding read capacity means adding another durable replica. Every replica participates in every write, so a push is only as fast as the slowest replica in its set. The net effect: adding replicas to absorb read load makes writes slower.

For most repositories, this tradeoff works well. At the highest activity levels, it becomes a ceiling: adding read replicas adds overhead to writes, losing a replica reduces read capacity, and losing quorum stops writes entirely. To meet agent-first demands, we need to separate durability from scale without losing what teams rely on today.

Built for the busiest, better for everyone

We’re rebuilding the infrastructure while GitHub keeps running. There’s no maintenance window where the world’s code stops moving, and no version of this work where we ask people to change how they build software while we do it.

We’re building for the most demanding workloads on GitHub: an enterprise shipping under strict regulatory requirements, a team landing a change across a repo that builds an operating system, and an organization running thousands of agents against a single codebase. Engineering for that scale raises the floor for everyone. The maintainer reviewing contributions from volunteers across time zones and the student opening their first pull request get the same faster, more resilient foundation.

The new architecture also must preserve the controls teams already operate on. A maintainer needs branch protections and required reviews so an unreviewed change never reaches the default branch. A security team needs audit logs and repository visibility to investigate a suspicious access event. An on-call engineer needs dependable automation and enough observability to understand why a deployment failed.

For the platform to keep serving everyone here while it scales for the busiest workloads, these are our guiding principles:

• Build on the workflows developers already trust. Teams rely on workflows like branching, review, merge, and history to build, ship, and govern software at scale. Our new infrastructure is designed to support those same workflows at much higher volumes of activity.
• Put reliability first. We measure every decision against the reliability that developers and organizations require. Confidence in the platform is what lets an engineering organization build automation, ship on a schedule, meet compliance obligations, and understand the software it produces. This work will meaningfully improve throughput and scale, and those gains extend a foundation of trust that’s already there.
• Keep people in control of their code. If the system isn’t helping the people and organizations who use it, and isn’t under their control, it isn’t worth building. As agents take on more of the work, the people who own the code can still review, understand, and approve it.

The approach

We are building a new GitHub architecture that can scale much more effectively. Our approach centers around core distributed systems design tenets, applied to the concurrency and scale of agentic software development. Our goal is to continue the forward momentum for open-source communities and enterprises around the world who have built their projects with Git and GitHub, while preserving and adapting the features and controls around it to meet the new needs of the agentic era.

Minimize coordination

A repository that receives many pushes must accept and publish updates quickly. Coordination is valuable when it protects correctness, but too much of it limits write throughput and can turn a busy repository into a bottleneck. Our current architecture is tightly coupled in places it doesn’t need to be, which limits our ability to scale across reads and writes without tough trade-offs. We’re redesigning the system to preserve the coordination that Git semantics require and let everything else proceed independently.

• Coordinate only what needs agreement. The part of a push that truly needs agreement is the reference update itself. Storing the underlying objects, validating object connectivity, and secret scanning are much more work, but most of it can happen in parallel to other writes. That shrinks the critical path of a push to the small step that needs coordination, so the rest of the work no longer delays the acknowledgment.
• Move maintenance off the serving path. Compaction and garbage collection are among the heaviest work a repository does, and today they run on the same hosts that answer live Git requests. In the new architecture, separate workers handle maintenance directly against durable storage. A busy repository can be optimized continuously in the background without slowing pushes and fetches.

Decouple storage from compute

Today, complete repository copies on local disks serve both as durable storage and as the layer that answers Git requests. Separating the two lets us scale each one independently.

• Scale reads without adding durable copies. In the new architecture, read capacity comes from lightweight workers that cache data to serve requests. The authoritative copy of the repository lives in a durable storage layer underneath. That way, the platform can absorb large read spikes from CI fan-out, agent fleets, and large clones without adding work to every push.
• Let each layer do one job. Authoritative repository data lives in Azure Blob Storage, which already provides durability and replication at Azure scale. The compute layer is optimized for throughput at the lowest latency.
• Recover faster from failures. When storage and compute are coupled, losing a host reduces both capacity and durability, and recovery means rebuilding a full repository copy. When they’re separate, losing a compute worker is closer to a cache miss: a replacement worker can start serving requests right away and fill its cache from durable storage as traffic arrives.
• Match capacity to demand. Compute workers can be added or removed as traffic changes instead of provisioning for peak load in advance. A repository going through a burst of activity, like a release or a new agent fleet coming online, can get extra capacity for the burst. Once it passes, that capacity goes away.

Together, these tenets allow us to support higher throughput and more concurrent work without abandoning the reliability and controls that our users need.

What comes next

We’re building an architecture designed to provide the highest throughput and reliability available. Reads and writes scale independently, and the system recovers gracefully from failures. In internal benchmarks, it has delivered up to 35 times higher write throughput, with read capacity that scales on its own to meet demand.

As automated development increases the frequency and concurrency of software change, GitHub will evolve its foundations without trading away the governance and control that teams rely on. We’re already putting that foundation in place. In the next post in this series, we’ll dive deeper into our future architecture and the journey that led us there.

The post Building Git infrastructure for agent-scale development appeared first on The GitHub Blog.

In earlier parts of this series on event sourcing, we have seen that we can project bi-temporal events (events with two timestamps: when the system knew about the event and when the event takes effect) into so-called timelines. A timeline shows a value over time. In this post, we look at some exemplary use cases these timelines enable.

What a timeline is

A timeline shows how a value changes over time:

A timeline in our system is a discriminated union with two values. It is either

• Existent with a list of phases, and every phase having a start and either having an associated value or representing a phase without a value; or
• NonExistent.

We can get a NonExistent timeline when we ask the system for some non-existent data. To represent the fact that we don’t have any data, we use NonExistent, not an Existent timeline with no phases. These two states are not equal. A great talk on why this distinction matters is Kevlin Henney’s “Much ado about nothing” (no recording available yet).

Feel free to skip the Deep Dive sections if you are only interested in the conceptual part of this post.

Deep dive

These are the F# types to represent a timeline:

Long-time readers may notice this code looks a bit simpler than in older posts. Yes, I cleaned things up based on insights I had while writing this post series and your comments. Thanks for that.

The value at a point in time

Probably the most-used functionality on timelines is getting the value at a specific point in time.

If you are new to bi-temporal events, you might be surprised that the most-used functionality isn’t getting the current value (what we typically do in normal event sourcing). In our system, many events have an effective date in the future. On the other hand, we often need to query past data. So, at is the normal case.

Keep in mind that there might be no value available.

Deep dive

A Timeline is based on a PhaseList. So we can delegate most functionality provided by a timeline to a PhaseList. tryApply makes this a bit easier. Also a good show case why pipes and partial application is such a blessing.

We look backwards for the first phase with a start smaller than or equal to at.

We often also need to know how long this value was unchanged, so we can use the atWithStart function:

Slicing a timeline

When we need to do further calculations on values in a timeline, it is often useful to slice the timeline to a specific range of interest. This speeds up further calculations by dropping unneeded data.

Deep Dive

Different use cases needed different slicing variants, so we introduced options to specify exactly how the resulting timeline should be sliced.

Again, we delegate to PhaseList for the actual work:

First, we trim the start to the specified range. Then we trim the end if needed. Finally, we adjust the start according to the specified options.

Fold over a timeline

In our systems, expenses have a state, and they pass through different phases:

To find the final state, we can fold (or loop) through all phases and calculate the state by applying the above state machine.

So, for example, if an expense was created, accepted, and then withdrawn, the overall state is withdrawn.

Deep Dive

There is way more

I think this blog post is already too long, so I’ll stop here. There are some interesting other functions in the Timeline module:

• getDistinctValuesIn range (no duplicats), getNonDistinctValuesIn range (faster)
• combine2 combines two timelines into a single timeline. Both timelines need to have the same granularity
• choose to choose only phases that match a predicate
• bind to make a single timeline out of two nested timelines (there is an inner timeline per outer phase)
• unzip to transform a Timeline<'a * 'b, 'granularity> into Timeline<'a,'granularity> * Timeline<'b,'granularity> ( * means tuple in F#)

Let me know if you are interested in a deep dive into one of these.

What happens if you ask an AI model to build a whole game in one go?

That's the question I set out to answer when I started experimenting with Claude Opus 5.5. The result is Survive the Sprint: a pixel-art, survive-the-horde browser game where you play as one of the endjineers, battling bugs, flaky tests and merge conflicts across three delivery sprints covering our core offerings.

You can play it right now in your browser (it works on your phone too), or watch the promo video first:

Here's how it came together.

The experiment: one prompt, Max effort

Every time a new model comes out, I like to throw something a bit silly at it to see where its limits are. With Opus 5.5, I wanted to try something that would need a lot of different skills at once: game design, rendering, animation, audio, game balance and, ideally, some personality.

So I tried to one-shot a game. I asked Claude to build a pixel-art, browser-based game for endjin, with the endjineers as the playable characters. Rather than describing everyone myself, I pointed it at our Who we are page and let it work out who we all are, what we do, and what we're known for. I ran it on Opus 5.5 with effort set to Max, then left it to get on with it.

What came back was, honestly, far more than I expected. Most of what you see in Survive the Sprint today came out of that single prompt: a complete, playable game in a single HTML file, with no build step and no external assets. The pixel art, the chiptune music and the sound effects are all drawn and generated in code.

Meet the endjineers

The bit that impressed me the most was how much it picked up from the Who we are page.

It started with how we look. Claude used the headshots on the page to build a pixel-art sprite for each endjineer, picking out the hair, beards, glasses and clothes that make each of us recognisable. Squeezing someone's face into a handful of pixels and still having them look like them is no small feat. It's easy to spot who's who on the character select screen.

It didn't stop at appearances either. In the original version, each endjineer had their own signature weapon, and many of them were already in-jokes that landed surprisingly well.

Later on, we gave Claude more context about each of us (our quirks, our side projects and the things we're known for in the office), and it used that to add a perk and a special move for everyone too, e.g.:

• Howard van Rooijen calls down an Azure Storm, and his special is the PR Comment Tsunami (anyone who has had a PR reviewed by Howard will understand)
• Ian Griffiths hurls a very thick copy of Programming C# that pierces everything in its path
• Jessica Hill releases pythons that hunt down enemies
• Barry Smart plays the trombone, with regular Slide Blasts
• Ed Freeman lobs exploding bar charts with Dashboard Drop
• Me with Fan-out Functions, and a Getting Things Done perk that fills Focus 30% faster, which is a nice nod to my GTD post

There are eleven endjineers to choose from and the office dogs make an appearance too.

Three sprints, three bosses

Each run takes you through a client engagement that mirrors the kind of work we actually do at endjin:

1. The Legacy Migration: cloud native app dev for a financial services client, ending with a fight against The Legacy Monolith
2. The Lakehouse: data & analytics for a retailer, where you collect bronze, silver and gold data and take on The Data Swamp
3. From Clarity to Production: an AI project for an education client, ending with The Hype Machine

Along the way you level up by collecting Mutual Points (our internal bonus scheme), pick up perks like Mechanical Keyboard, Standing Desk and Off and On Again, pair with colleagues to unlock weapon synergies, and evolve your weapons (In-Memory Cache becomes Multi-Layer Cache, and Neural Network becomes Large Language Model). There are also plenty of achievements to unlock along the way.

From one shot to shipped

I'll admit I was hesitant to share it with the wider team. I had a nagging feeling that the moment it landed in Slack, endjin's productivity would drop like a stone... and I was right.

I sent the original output to Howard first, and he was hooked straight away. From there, we had a fair bit of back and forth with Claude to get it from "impressive demo" to something we were happy to put on endjin.com:

• Tweaks: play-testing the balance, refining the characters and polishing the details
• New features: adding perks and special moves for every endjineer, plus more content and things to discover
• Performance: making sure it stays smooth when the screen is full of enemies, including on mobile
• Bug fixes: the kind of things you only find by actually playing it
• Automated tests: smoke tests, bot playthroughs, layout tests etc.

The important thing for me is that the one-shot gave us a genuinely good foundation to build on. We weren't fighting the code to get changes in; we were just iterating on the fun bits.

Bonus: the promo video

Having previously experimented with getting Claude to create videos, we thought it would be fun to see if it could make a promo video for the game too. It built the whole thing: that's the video at the top of this post.

What I took away from it

A year or two ago, "build me a game" would have got you a bouncing square and a TODO list. With Opus 5.5 on Max effort, a single prompt got us most of a polished, playable game, complete with personality and in-jokes, that we were happy to put our name on.

It still needed people to make it great. Play-testing, taste, and knowing when something isn't quite fun yet are still very much human jobs. But the gap between an idea and a working first version has shrunk dramatically, and that changes what's worth trying.

Go and play it!

Head over to endjin.com/survive-the-sprint, pick your endjineer, and see if you can ship all three sprints. If you manage it with every endjineer, there's an achievement for that too: Bus Factor Eleven.