Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer. This issue is the entire The Pulse issue from the past week, which paying subscribers received seven days ago. This piece generated quite a few comments across subscribers, and so I’m sharing it more broadly, especially as it raises questions on what is defensible and what is not with open source.

If you’ve been forwarded this email, you can subscribe here to get issues like this in your inbox.

Today’s issue of The Pulse focuses on a single event because it’s a significant one with major potential ripple effects. On Tuesday, Cloudflare shocked the dev world by announcing that they have rewritten Next.js in just one week, with a single developer who used only $1,100 in tokens:

There are several layers to dig into here:

1. The Next.js ecosystem: a recap. Close to half of React devs use Next.js, and the best place to deploy Next.js is on Vercel – partly thanks to its proprietary build output.

2. What Cloudflare did with Next.js. Replacing the build engine in Next.js with the more standard Vite one, allowing Next.js apps to be easily deployed on Cloudflare.

3. AI brings the impossible within reach. What would take years in engineering terms was executed in one week with some tokens.

4. “AI slop” still an issue. Contrary to Cloudflare’s claims, vinext is not production-ready, and will need plenty of cleanup and auditing to make it on par with Next.js.

5. New attack vector on commercial open source? AI makes it trivial to “piggyback” off any commercial open source project. That’s a massive problem for commercial open source startups.

6. Defense or offense? Making test suites private is one defense, and going closed source is another. Code is no longer a moat, but other things like support, community, and infrastructure could become more important.

7. AI-world reality. Tests are an efficient way to use AI agents, vendors will start deploying “migration agents” like Cloudflare, and more.

1. The Next.js ecosystem: a recap

First, some background. Next.js is the most popular fullstack React framework and around half of all React devs use it, as per recent research such as the 2025 Stack Overflow developer survey. Next.js is an open source project, built and mostly maintained by Vercel, which is the preferred deployment target for Next.js applications for many reasons. One of them is that Next.js is ideal to deploy to Vercel because Next.js applications are built with Vercel’s Turbopack build tool. The output of a build is a proprietary format. As Netlify engineer Eduardo Bouças writes:

“The output of a Next.js build has a proprietary and undocumented format that is used in Vercel deployments to provision the infrastructure needed to power the application.

This means that any hosting providers other than Vercel must build on top of undocumented APIs that can introduce unannounced breaking changes in minor or patch releases. (And they have)”.

Next.js is an interestingly built project, where everything is open source, and the best place to deploy a Next.js application is on Vercel, as it’s optimized to run undocumented build artifacts the most efficiently. This is a smart strategy from Vercel which competitors will dislike, as any hosting provider would prefer Next.js to produce a standard build format. To do this, the build engine, Turbopack, would need to be replaced with something more standard.

Let’s talk about build tools for web development. According to the State of JS 2025 survey, the most popular in the web ecosystem are:

1. Vite: the most popular choice for new projects due to its speed and developer experience. Uses projects like esbuild and Rollup under the hood

2. Webpack: a legacy tool that’s not very performant, but still widely deployed in older projects

3. Turbopack: Created by Vercel and optimized for larger Next.js applications. Built in Rust and intended to be more performant

4. Bun: a relatively new, all-in-one runtime and bundler. Anthropic acquired the team in December, and some Bun folks are now focused on improving Claude Code’s performance.

So, most of the web ecosystem uses Vite as a build tool; Next.js uses Turbopack, and the majority of React applications with a full-stack React framework use Next.js. Basically, most devs using Next.js are likely to use Vite as their build tool.

2. What Cloudflare did with Next.js

Here’s a naive idea: what if Next.js used Vite to generate build outputs? In that case, build outputs would be standardized and would run equally well on any cloud provider, as there would be nothing proprietary or undocumented to Vercel.

And this is what Cloudflare did: replace Turbopack with Vite and call the new package ‘vinext’:

Buried midway in the announcement is how this project is experimental and not at all guaranteed to work okay: it’s a ‘use-at-own-risk’ project. Still, the mere fact of this development feels like an earthquake in the tech world because of how it was pulled off.

3. AI brings the impossible within reach

In a blog post announcing the project, Cloudflare claims only one engineer “rebuilt” the whole thing in a way that’s trivial to deploy to Cloudflare’s own infrastructure, and only cost $1,100 in tokens. From Cloudflare’s statement:

“Last week, one engineer and an AI model rebuilt the most popular front-end framework from scratch. The result, vinext (pronounced “vee-next”), is a drop-in replacement for Next.js, built on Vite, that deploys to Cloudflare Workers with a single command. In early benchmarks, it builds production apps up to 4x faster and produces client bundles up to 57% smaller. And we already have customers running it in production.

The whole thing cost about $1,100 in tokens”.

What Cloudflare did:

• Took the Next.js public API

• Reimplemented behaviour using Vite

• Created build output whose behaviour matches the “original” Next.js implementation

After 10 years, the core of Next has around 194,000 lines of code (LOC)**. Meanwhile, vinext is about 67,000 lines of code which suggests a much leaner implementation: for example, vinext does not need to support legacy Next APIs, and vinext currently supports 94% of the Next.js API (and it’s safe to assume they left complex edge cases in the remaining 6%).

** the Next.js repository is closer to 2M lines of code: 1M is bundled dependencies (eg React bundles, CSS build etc), tests are 308,000 LOC, Turbopack 311,000 LOC.

Pre-AI, this reimplementation would have taken years of engineering time to complete. Doing what Cloudflare did was always possible in theory, but never seemed practical. I mean, why have a team of engineers spend potentially years on generating a standardized build output for Next.js apps? Even if they did, the dev community would have doubts about whether Cloudflare would maintain the project.

This is the thing with forking or rewriting open source projects: a major value proposition for commercial open source is to know that they will be maintained. Vercel has proved it’s a reliable custodian of Next.js for the past 10 years. Without AI, it could be assumed that any new reimplementation would eventually run out of steam.

Separately but relatedly, Cloudflare has now proved that the cost of rewriting existing software has become ~100x cheaper, thanks to AI, and this economy is likely to be the case for maintenance, too. Considering how trivial it was to rebuild one of the more complex open source projects, this augers well for it being trivial and much cheaper to maintain in the future. Potentially, Cloudflare no longer needs to budget an engineering team only for maintenance, if a single engineer could maintain the project, part-time!

Cloudflare had a project measured in engineering years, and completed it in one engineering week! It just took a single engineer using OpenCode (open source coding agent), Opus 4.5, and a bunch of tokens, then: ‘boom’, vinext was born.

4. “AI slop” still an issue

There are questions about the quality of vinext, though. Vercel, naturally, is unhappy and hit out at the obvious weakness that vinext is unfit for production usage because it’s insecure. Vercel CEO, Guillermo Rauch, did not miss a beat by tying Cloudflare’s effort to the “vibe coding” stereotype of sloppy work executed with a lack of understanding:

Guillermo has a point: anyone who stopped reading Cloudflare’s launch announcement after the first few sentences would assume it’s production-ready, with the first paragraph of this announcement closing with:

“And we already have customers running it in production.”

However, Cloudflare doesn’t share the rather crucial detail that “running in production” means that vinext has been deployed onto a beta site, until more than 1,000 words (around 2–3 pages) into the announcement:

“We want to be clear: vinext is experimental. It’s not even one week old, and it has not yet been battle-tested with any meaningful traffic at scale. (...)

We’ve been working with National Design Studio, a team that’s aiming to modernize every government interface, on one of their beta sites, CIO.gov.

Oh. So, “customers running it in production” at Cloudflare apparently means “customer running a beta site in production without meaningful traffic.” This is a first from the infrastructure giant, which usually prides itself on accurate statements!

This detail was also absent when Cloudflare’s CEO and CTO were boosting vinext like it was a mature, battle-tested product. In that context, Vercel’s raising of the issue of security vulnerabilities is more than fair game, in my view.

Still, all that doesn’t alter the core learning from this project: that AI has the power to drastically reduce engineering time by up to ~100x and deliver usable-enough output, for relatively negligible financial cost. Just keep in mind that security and reliability issues will probably take plenty of extra time and effort to address.

5. New attack vector on commercial open source?

If arch-rivalries exist in tech, then Cloudflare and Vercel are a prime example. Both are gunning to become the most popular platform for developers to deploy their code, and the CEOs are regularly seen in public taking shots at the other side. One such spat happened in March, as covered at the time:

“Things kicked off on social media, with developers confused about the severity of the incident, and about why Next.js seemed silent, and also why Cloudflare sites were breaking due to its fix for the CVE causing its own issues. It was at that point that Cloudflare’s CEO, Matthew Prince, entered the chat to accuse Vercel of not caring about security:

Given the security incident was ongoing, this felt a bit “below the belt” by the Cloudflare chief. Criticizing rivals is fair game, but why not wait until the incident is over? The punch landed, and Vercel’s CEO Guillermo Rauch is not someone to take it lying down, so he hit back.

Cloudflare’s CEO then responded with a cartoon implying that although Vercel is much larger than its competitor Netlify, Cloudflare is 100x bigger than both, and could stomp them into the ground at will.”

Serving the public interest wasn’t why Cloudflare rewrote Next.js: they did it because they want Next.js sites to be deployed onto Cloudflare, but doing so made little sense until now because Next.js produced bespoke build output optimized for Vercel’s infrastructure. With this change, Cloudflare claims it provides superior performance when hosting Next.js apps, according to their own measurements.

I’d just add that performance is important for developers, but other things matter, too. Cost, reliability, developer experience, and how much devs like a company, are all factors in choosing between vendors. Also, performance measurements from a vendor about its own service must be taken with a large pinch of salt.

Zooming out from this episode, it seems that AI is bringing the value of existing commercial open source moats into question. Vercel carved out a clever open source strategy that helped turn its open source investment into business revenue:

1. Build and maintain Next.js, delivering the best developer experience (DX).

2. Optimize Vercel to serve the specific (and undocumented) build output of Next.js.

3. Most developers onboarding to Next.js will decide to deploy on Vercel to get the most benefit, in terms of DX and performance.

4. … repeat for years while the business becomes worth billions! (Vercel was valued at $9B last October).

Underpinning this success are some assumptions:

1. Next.js will remain the #1 choice for developers to build React applications, thanks to ongoing investment.

2. It is expensive to rewrite Next.js to be deployable and performant on another cloud vendor.

3. Even if someone did #2, developers would be skeptical and not switch over.

Vercel can invest in #1 to keep Next as best-in-class, while knowing that the risk of #2 occurring is minor. However, Cloudflare has now “cloned” Next, and can easily keep up with all changes in the future, and port them back to vinext.

But AI makes it trivial to “piggyback” off any commercial open source project, which is a massive problem for commercial open source startups. It puts all the effort and investment into building and maintaining Next.js, while Cloudflare enjoys the benefit of this hard work (the Next.js public API) which is easily deployable to Cloudflare, and it can now undercut Vercel on price. For all future Next.js changes, Cloudflare will just sync it to vinext, using AI!

WordPress had a similar problem, with WP Engine “piggybacking” off its work and undercutting their pricing in 2024. As I analyzed at the time:

“Free-riding on permissive open source is too tempting to pass on for other vendors. WP Engine uses a common loophole of contributing almost nothing in R&D to WordPress, while selling it as a managed service. This means that they could either easily undercut the pricing of larger players like Automattic which do spend on WordPress’s R&D. Alternatively, a company like WP Engine could charge as much, or more, as Automattic, but be able to spend a lot more on marketing, while being similarly profitable. “Saving” on R&D gives the “free-riders” plenty of options to grow their businesses: options not necessarily open to Automattic while they invest as much into R&D as they do.

Commercial open source vendors pressure to end “freeriding”. Automattic is likely facing lower revenue growth, with customers choosing vendors like WP Engine which offer a similar service — getting these customers either via a cheaper price or thanks to more marketing spend. This legal fight could be an effort to force WP Engine to stop eating Automattic’s lunch, or perhaps get WP Engine to sell to Automattic, which would cement its leading status in managed Wordpress, while also boosting revenue by $400M a year – according to its own figures”.

Vercel managed to avoid the “free-riding” problem with Next.js, but that’s no longer possible now that AI makes it trivial to rewrite.

6. Defense or offense?

How should commercial open source companies respond to the threat that a competitor can easily rewrite the software behind the managed solutions which they sell as services?

One obvious response is to make tests private, so that replication is harder for AI. One thing that made it so easy for Cloudflare to rewrite Next was the project’s comprehensive test suite. From their announcement (emphasis mine):

“We also want to acknowledge the Next.js team. They’ve spent years building a framework that raised the bar for what React development could look like. The fact that their API surface is so well-documented and their test suite so comprehensive is a big part of what made this project possible.”

Database solution SQLite is famous for its incredible test suite. What some people don’t know is that while core SQLite tests are open source, its most comprehensive test suite – TH3 – is closed source. SQLite monetizes its advanced infrastructure as a service for purchase. This is a fair tradeoff: for most contributors, the basic open source tests work well enough. For enterprise users or customers who really care about correctness, it makes sense to purchase advanced testing services from the service’s creator.

Open source canvas project, tldraw, announced it will relocate its test suite to a closed source repository; a move which makes plenty of sense. Here’s commentary from Simon Willison:

“It’s become very apparent over the past few months that a comprehensive test suite is enough to build a completely fresh implementation of any open source library from scratch, potentially in a different language.”

In the event, tldraw’s announcement turned out to be a joke, but who’s laughing now? An open source project with excellent tests is an easy target for an AI agent to execute a full rewrite of it.

Could new licenses be created for the AI era? Existing open source licenses were created on the assumption that humans read open source code, and humans modify it. Agents break that assumption.

Could we see new license types emerge to ban AI agents from modifying projects’ source code? It seems pretty far-fetched and hard to implement, but not beyond the realms of possibility.

AI agents are still very new, and going mainstream in tech. Once they break into other industries, I wouldn’t be surprised if legal frameworks are reworded to also apply to AI agents. If and when this happens, it would open the path for open source licenses to distinguish between agents and humans.

What is a moat, if code can be trivially ported? A team operating a popular open source project can no longer assume it’s expensive to fork or to be completely rewritten, meaning it makes sense to focus on other moats, such as:

• Outstanding (paid) support. AI could make this much easier at a higher quality, if done right.

• Smaller open core, larger closed source part. “Open core” as a business model has been dominant for commercial open source: keep the core of the software open source, while advanced enterprise features are source available or closed source. I would expect more companies to move their additional services to closed source, not source available.

• In-person connection and community. Projects with a real-world community will form a sense of connection that goes beyond code. For example, it’s hard to imagine vinext meetups popping up – whereas there are many Next.js communities.

• Infrastructure and hardware remains a massive moat. In a world where software is trivial to copy, infrastructure remains a moat. Commercial open source might make most sense for players that own and operate superior infrastructure layers than their rivals: and being able to offer lower cost, higher reliability, lower latency, higher performance, or a combination of these.

7. AI-world reality

One of the single best AI use cases is full-on rewrites of well-tested products. I estimate that AI sped up the creation of vinext by at least 100x, which is massive. But we don’t really see efficiency boosts of anything like that with AI tools, in general. As Laura Tacho shared at The Pragmatic Summit in San Francisco, the average self-reported efficiency ‘AI gain’ seems to be circa 10%.

I suspect this vast chasm in efficiency boosts is because AI is many times more efficient at “no-brainer tasks” where correctness can be verified with tests, versus those which are more open ended or involve more creativity.

In general, tests are incredibly important for efficient AI usage. On The Pragmatic Engineer Podcast, Peter Steinberger stressed how important “closing the loop” in his developer flow is by instructing the AI to test itself, and ensuring the AI has tests to run that verify correctness.

Automated tests were always considered a best practice for creating maintainable code. Now, having a codebase with extensive tests is the baseline to make AI agents work productively for refactors, rewrites – or even adding new features and verifying that things did not break!

Vendors will start to deploy “migration AI agents” to move customers over to their own stacks. This got lost in Cloudflare’s announcement, but it’s important:

vinext includes an Agent Skill that handles migration for you. It works with Claude Code, OpenCode, Cursor, Codex, and dozens of other AI coding tools. Install it, open your Next.js project, and tell the AI to migrate:

> npx skills add cloudflare/vinext

Then open your Next.js project in any supported tool and say:

> migrate this project to vinext

The skill handles compatibility checking, dependency installation, config generation, and dev server startup. It knows what vinext supports and will flag anything that needs manual attention.

This is very clever from Cloudflare, and a true “AI-native” move. They have not only used AI to migrate Next.js, but also built an “AI plugin” (a skill) to help customers migrate their existing codebases over to vinext – and deploy on Cloudflare!

This move will surely be copied by other vendors, since migrations which are tedious for humans are much less effort with agents.

AI is making the tech industry more ruthless when it comes to business practices. Laura Tacho said something interesting at The Pragmatic Summit:

“AI is an accelerator, it’s a multiplier, and it is moving organizations in different directions.”

AI seems to be accelerating the ruthlessness of competition for customers and the speed at which this happens. In one week, Cloudflare rebuilt Next.js, and it’s attacking Vercel full-on: claiming their “vibe coded” alternative is more performant and production-ready, and burying at the foot of the launch announcement the crucial information that vinext is very much experimental.

I sense vendors are realizing that there’s a limited amount of time in which to use AI to their advantage, and some will decide to use it like Cloudflare has.

On the other hand, AI could be great news for non-commercial open source. AI presents as a threat to commercial open source because it removes existing moats which make code hard to fully rewrite. However, beyond that, AI could help non-commercial open source to thrive:

• With AI, it’s easy to fork an open source project and keep the fork in-sync with the original.

• It’s trivial to instruct AI to rewrite an open source project to another language or framework.

• …and it’s equally trivial for AI to add features to a fork.

For these reasons, I believe there could be a lot more forks and rewrites to come, and more open source projects and code, in general.

Takeaways

Personally, I could not have imagined things changing this quickly in software. Rewriting Next.js in a single week, even to a version that is not quite there – but mostly works? This was out of the question as recently as a few months ago.

Things changed around last December, when Opus 4.5 and GPT-5.2 came out and proved capable of writing most of the code. What used to be expensive is now cheap – like rewriting complete projects – and we still need to learn what the “new” expensive parts of software engineering are.

All this is new territory for everyone. To succeed in the tech industry, you need to be able to capitalize upon change, as Cloudflare has clearly done in this case by making the most of an opportunity created by new technology. It’s unclear how popular vinext will become, and how much of a moat Vercel has around the broader Next.js ecosystem, but I suspect that it’d take more than a Next rewrite to make Cloudflare into a viable Next.js platform-as-a-service provider.

Stream the latest episode

Listen and watch now on YouTube, Spotify, and Apple. See the episode transcript at the top of this page, and timestamps for the episode at the bottom.

Brought to You by

• Statsig — ⁠ The unified platform for flags, analytics, experiments, and more. Stop switching between different tools, and have them all in one place. Check out Statsig.

• Sonar – The makers of SonarQube, the industry standard for automated code review. Proactively find and fix issues in real-time with SonarQube MCP Server by connecting AI tools like Claude Code, GitHub Copilot, and Cursor directly to Sonar’s systematic code analysis engine. Learn how Sonar provides the essential verification layer for the AI development era.

• WorkOS – Everything you need to make your app enterprise ready. Companies like Anthropic, OpenAI, and Cursor already run on WorkOS. See why.

In this episode

Boris Cherny is the creator and Head of Claude Code at Anthropic. He previously spent five years at Meta as a Principal Engineer and is the author of the book Programming TypeScript.

In this episode of Pragmatic Engineer, we went through how Claude Code was built and what it means when engineers no longer write most of the code themselves.

We discuss how Claude Code evolved from a side project into a core internal tool at Anthropic and how Boris uses it day-to-day. We go deep into workflow details, including parallel agents, PR structure, deterministic review patterns, and how the system retrieves context from large codebases. We also get into how Claude Cowork was built.

As coding becomes more accessible, the role of engineers shifts rather than shrinks. We examine what that shift means in practice, which skills become more important, and why the lines between product, engineering, and design are blurring.

Key observation from Boris

Here are 10 observations from this conversation that I found the most interesting:

1. Boris ships 20-30 PRs a day by running 5 parallel Claude instances. Boris works across five terminal tabs (each a separate checkout), starting Claude in plan mode, iterating on the plan, then letting it one-shot the implementation. As he put it: “once there is a good plan, it will one-shot the implementation almost every time.”

2. Boris learned at Meta that code quality has a measurable, double-digit-percent impact on engineering productivity. At Meta, Boris led causal analysis showing clean codebases meaningfully boost output. This learning holds for AI-generated code, too: partially-migrated codebases with multiple frameworks confuse both humans and models. As Boris put it: “always make sure that when you start a migration, you finish the migration.”

3. Claude Code’s “agentic search” is really just glob and grep — and it outperformed RAG. The team tried several approaches to make agentic search better: local vector databases, recursive model-based indexing, and other fancy approaches. All had downsides (stale indexes, permission complexity). Plain glob and grep, driven by the model, beat everything. This approach was inspired by how Boris observed engineers at Instagram searched code when the click-to-definition functionality in Meta’s in-house coding editor was broken.

4. Boris automated himself out of code review well before AI. Boris was one of the most prolific code reviewers at Meta company. And he worked hard to minimize time spent on code review. His system::every time he left the same kind of review comment, he logged it in a spreadsheet. Once a pattern hit 3-4 occurrences, he’d write a lint rule to automate it away!

5. Everyone at Anthropic has the same title — “Member of Technical Staff” — and it’s by design. Without role-specific titles, the default assumption is that everyone does everything: product, design, infrastructure, research. As Boris put it: “It kind of inverts this relationship between people, even if you don’t know each other well yet.”

6. Claude Cowork was built in ~10 days — and it’s growing faster than Claude Code did at launch. The team spotted “latent demand” from non-engineers already hacking with Claude Code (data scientists, finance, sales). The bulk of the engineering complexity for Cowork wasn’t product logic, but around safety: building classifiers, a shipping VM, OS-level protections against accidental file deletion, and rethinking the permission model for non-technical users.

7. PRDs are dead on the Claude Code team — prototypes replaced them. Instead of writing Product Requirement Documents (specs), they build hundreds of working prototypes before shipping a feature. Boris: “There’s just no way we could have shipped this if we started with static mocks and Figma or if we started with a PRD.”

8. This is the year of the generalist (and maybe the year of those with ADHD). Boris’s work has shifted from deep-focus single-threaded coding to managing multiple parallel agents and context-switching rapidly. As Boris put it: “It’s not so much about deep work, it’s about how good I am at context switching and jumping across multiple different contexts very quickly.”

9. Fix infra before building a product. Working at Meta, when Boris moved to Instagram, the Python/Django stack was so poor that click-to-definition didn’t work and the type checker was broken. He abandoned his original team, and went straight to Dev Infra, leading migrations from Python to the Facebook monolith and from REST to GraphQL. He did this because you can’t build great products on a terrible foundation, and sometimes the highest-leverage move is fixing the platform rather than shipping features.

10. Could software engineers of today be the medieval equivalents of scribes? Boris brought up an interesting analogy: in the middle ages, scribes were a tiny literate elite employed by often-illiterate kings. When the printing press was invented, scribes technically lost their jobs. Still, many of them became writers and authors, and the market for written work expanded beyond prediction!

Boris wondered if we could see the same pattern with software engineers: coding is becoming accessible to everyone. Could the software engineers of today be building systems that have far broader reach, in the future, than ever than before?

The Pragmatic Engineer deepdives relevant for this episode

• How Claude Code is built

• How Anthropic built Artifacts

• How Codex is built

• Real-world engineering challenges: building Cursor

Timestamps

(00:00) Intro

(11:15) Lessons from Meta

(19:46) Joining Anthropic

(23:08) The origins of Claude Code

(32:55) Boris’s Claude Code workflow

(36:27) Parallel agents

(40:25) Code reviews

(47:18) Claude Code’s architecture

(52:38) Permissions and sandboxing

(55:05) Engineering culture at Anthropic

(1:05:15) Claude Cowork

(1:12:48) Observability and privacy

(1:14:45) Agent swarms

(1:21:16) LLMs and the printing press analogy

(1:30:16) Standout engineer archetypes

(1:32:12) What skills still matter for engineers

(1:35:24) Book recommendations

References

Where to find Boris Cherny:

• X: https://x.com/bcherny

• LinkedIn: https://www.linkedin.com/in/bcherny

• Website: https://borischerny.com

Mentions during the episode:

• Jarred Sumner on LinkedIn: https://www.linkedin.com/in/jarred-sumner-a8772425

• Vladimir Kolesnikov on LinkedIn: https://www.linkedin.com/in/voloko

• React: https://react.dev

• Will Bailey on LinkedIn: https://www.linkedin.com/in/willbailey

• Fiona Fung on LinkedIn: https://www.linkedin.com/in/fionafung

• Inside Meta’s Engineering Culture: Part 1: https://newsletter.pragmaticengineer.com/p/facebook

• Inside Meta’s Engineering Culture: Part 2: https://newsletter.pragmaticengineer.com/p/facebook-2

• Adam Wolff on LinkedIn: https://www.linkedin.com/in/adamwolff

• The Bitter Lesson: http://www.incompleteideas.net/IncIdeas/BitterLesson.html

• How Claude Code is built: https://newsletter.pragmaticengineer.com/p/how-claude-code-is-built

• Mike Krieger on X: https://x.com/mikeyk

• Dario Amodei on X: https://x.com/DarioAmodei

• Ben Mann on LinkedIn: https://www.linkedin.com/in/benjamin-mann/

• Marc Andreessen: The real AI boom hasn’t even started yet:

Lenny's Newsletter

Marc Andreessen: The real AI boom hasn’t even started yet

Marc Andreessen is a founder, investor, and co-founder of Netscape, as well as co-founder of the venture capital firm Andreessen Horowitz (a16z). In this conversation, we dig into why we’re living through a unique and one of the most incredible times in history, and what comes next…

Listen now

a month ago · 141 likes · 5 comments · Lenny Rachitsky

• Cat Wu on LinkedIn: https://www.linkedin.com/in/cat-wu

• Asana: https://asana.com

• Claude Cowork: https://claude.com/product/cowork

• Felix Rieseberg on LinkedIn: https://www.linkedin.com/in/felixrieseberg

• Electron: https://www.electronjs.org

• Building a C compiler with a team of parallel Claudes: https://www.anthropic.com/engineering/building-c-compiler

• Introducing Claude Opus 4.6: https://www.anthropic.com/news/claude-opus-4-6

• Thariq Shihipar on LinkedIn: https://www.linkedin.com/in/thariqshihipar

• Programming TypeScript: Making Your JavaScript Applications Scale: https://www.amazon.com/Programming-TypeScript-Making-JavaScript-Applications/dp/1492037656

• A General Theory of Reactivity: https://kriskowal.gitbooks.io/gtor/content/intro.html

• Ryan Dahl on X: https://x.com/rough__sea

• Anders Hejlsberg on X: https://x.com/ahejlsberg

• The Three-Body Problem: https://www.amazon.com/Three-Body-Problem-Cixin-Liu/dp/0765382032

• Accelerando: https://www.amazon.com/Accelerando-Singularity-Charles-Stross/dp/0441014151

• Functional Programming in Scala: https://www.amazon.com/Functional-Programming-Second-Michael-Pilquist-ebook/dp/B0C4LX999T

—

Production and marketing by Pen Name.

Ledgers are a “get your shit together” tool.

The goal isn’t to record account balances, or where money comes and goes. A ledger’s purpose is to make the company trustworthy. All the strictness and the weird complexity isn’t to make life harder for engineers, or to prevent software bugs, but to keep accountants and auditors happy.

If a ledger can’t be trusted, neither can the company.

In order to interact with your ledger, all the other services have to make sure that they’re sending the right data in the right way. Sure, you can create a translation layer between the other services and the ledger, but that defeats its purpose: a service that initiates, validates, or completes money movements must be, implicitly, as strict as the ledger.

And the way that strictness is enforced is with a ledger that tolerates no bullshit through its interfaces.

All the strictness and complexity isn’t there to slow you down. It’s to create consistency, traceability, and proof.

• Proof that every money movement is intentional

• Proof that nothing can quietly disappear

• Proof that what the company says in aggregate matches the collection of what every transaction whispers individually

A ledger is discipline encoded in software.

This week, we’re looking at the most fundamental building block of ledgers: immutability. In most engineers’ mind, it translates to “append-only”. And sure, append-only databases are immutable because you can’t UPDATE or DELETE rows on them.

But that’s only the beginning of what immutability means for a ledger.

Here’s what you can expect in today’s article:

• A practical definition of immutability for ledgers (and why you can have it with mutable databases)

• The difference between Journaling and Posting ledger entries, and why it matters

• Why git is a nice metaphor for what a ledger’s immutability is about

• And for the database nerds, read skews, and why are relevant

Enough intro, let’s dive in...

Which AI tools are software engineers using, and what do they really think of them? We asked The Pragmatic Engineer subscribers, and nearly a thousand of you have shared your experiences of using AI tools for work. This article provides a high-level overview of those findings from our latest AI tooling survey. Thank you to everyone who participated!

There are plenty of interesting details, most notably, validation of just how much Anthropic and Claude Code have risen to dominate tooling usage. Claude Code is today nearly as widespread as GitHub Copilot was in our survey three years ago (in the spring of 2023) – which shows how fast the AI market moves.

In today’s issue, we cover:

1. Interesting findings: Claude Code has rocketed to #1 in just eight months, AI is fully mainstream with 95% weekly usage among respondents, and more.

2. Most-used AI tools: Claude Code leads the pack, followed by chatbots and GitHub Copilot. Cursor’s rising fast, and newcomers like Codex and Antigravity are gaining traction. Most engineers juggle two to four tools at once.

3. Popular models: Anthropic’s Opus and Sonnet models dominate coding tasks by a wide margin, with more mentions than all others combined.

4. AI trends: mainstream adoption achieved. 95% of respondents report using AI tools at least weekly, 75% use AI for half or more of their work, and 56% report doing 70%+ of their engineering work with AI.

5. AI agent usage rising: 55% of respondents now regularly use AI agents, with staff+ engineers leading adoption on 63.5% usage in the survey results. Agent users are twice as excited about AI as non-users are.

6. Company size and tool usage: smaller places overwhelmingly favor Claude Code (75% at the tiniest businesses), while large enterprises default to GitHub Copilot. This popularity is probably down to enterprise procurement preferences – and Microsoft’s enterprise marketing efforts.

7. Tools engineers love: Claude Code is the most loved tool at 46%, far ahead of Cursor on 19% and GitHub Copilot at 9%. Senior leaders are especially enthusiastic about Claude Code.

8. Demographics: Overview of who took part in the survey.

Full subscribers also have access to a longer, 35-page report with additional details - linked at the end of this article.

The bottom of this article could be cut off in some email clients. Read the full article uninterrupted, online.

Read the full article online

1. Interesting findings

Here are my ten personal, most-interesting findings from this survey:

1. Claude Code has gone from zero to be the #1 tool in only eight months. Released in May 2025, it’s already the most-used AI coding tool, overtaking GitHub Copilot and Cursor.

2. AI is now mainstream. 95% of respondents use AI tools at least weekly, or more often, and 75% use AI for at least half their software engineering work. Among readers of The Pragmatic Engineer, it seems the question is no longer whether to use AI in day-to-day work, but which tools to use.

3. Cursor is catching up fast on GitHub Copilot. As much as we hear about companies dropping Cursor for Claude Code, Cursor is doing more than fine, growing in mentions 35% since our previous survey nine months ago.

4. Most engineers juggle multiple AI tools. 70% use between two and four tools simultaneously, while 15% use five or more.

5. Staff+ engineers are the heaviest agent users. 63.5% use agents regularly; more than regular engineers (49.7%), engineering managers (46.1%), and directors/VPs (51.9%).

6. Codex is seeing explosive early growth. Despite not existing during the last survey, OpenAI’s Codex already has 60% of Cursor’s usage (!!)

7. Using agents correlates strongly with being positive about AI. People using agents are nearly twice as likely to feel excited about AI while non-users are twice as likely to be skeptical.

8. Company size influences tool choice more than preference. Huge companies (10K+) more likely to use Copilot (56%), tiny startups mostly go with Claude Code (75%) and Cursor (42%). It seems like enterprise procurement, not individual preference, is behind this divergence.

9. A tight chatbot race. ChatGPT, Gemini, and Claude as standalone chatbots have nearly equal numbers of mentions, suggesting there’s no clear winner outside of coding-specific tools among software engineers.

10. Directors and senior leaders are especially into Claude Code. The survey finds this tool is twice as popular with these folks as it is at less senior levels, while Cursor gets less love as seniority increases.

Let’s jump into some of the data:

2. Most-used AI tools

Just eight months after its release, Claude Code is already the most-used tool, overtaking both GitHub Copilot and Cursor:

Tools mentioned, in order of popularity:

1. Claude Code: a terminal-first coding agent from Anthropic. We cover its history in the deepdive, How Claude Code is built

2. Chatbots: ChatGPT, Claude, Gemini, and others

3. GitHub Copilot: launched in 2021, it’s the “oldest” AI coding tool on this list

4. Cursor: agent-powered coding IDE. Learn more about it in our deepdive, Real-world engineering challenges: building Cursor.

5. Codex: OpenAI’s AI coding agent. We recently covered how Codex is built

6. Gemini CLI: Google’s command line agent

7. OpenCode: the most popular open source coding agent, where you can swap out the model being used, sidestepping vendor lock-in

8. Antigravity: Google hired the original team behind Windsurf and launched its own agentic IDE

9. JetBrains Junie: the AI coding agent by JetBrains

10. Zed: a fast editor with agentic workflows

11. Windsurf: when Google acquihired the team, it did not buy the product. An AI IDE, now owned and operated by Cognition

12. Amp: a model-agnostic coding agent. A free version is supported by ads

13. Augment Code: an enterprise-focused coding agent

14. Factory: agent-native software development, which calls agents “droids.”

It’s interesting to compare how people answered the same question just nine months ago, last May:

Notable trends:

• Claude Code has massive momentum and is already the market leader. Since being released in May 2025, it has become the most-used AI coding tool among survey respondents. Anecdotally, I’ve heard many teams are dropping Cursor for Claude Code.

• Cursor has grown circa 35% in nine months and now threatens GitHub’s popularity. In this survey, 35% more respondents mention using Cursor than in our previous research, last May. Such growth is impressive: at this rate, Cursor will have more users than GitHub in 6-9 months!

• Chatbot usage remains high. Combined mentions for ChatGPT, Claude, Gemini, Perplexity, and others used outside of coding apps are still higher than for any other tool except Claude Code. For context, the most-mentioned chatbot (ChatGPT, 107 times) only has as many as Gemini CLI (also 107).

• GitHub Copilot usage stable. Nine months ago, 46% of respondents said they used GitHub Copilot. Since then, it’s barely risen.

• Explosive growth for Codex. OpenAI’s Codex wasn’t available during our last survey. But it now already has 60% of Cursor’s usage(!), and could be growing even faster since this survey.

• Up-and-coming tools: OpenCode, Gemini CLI, Antigravity. None of these had launched nine months ago, but today they’re used by around 10% of respondents – no small feat!

• Tools growing more than before: The likes of Zed, Windsurf, Amp, Augment Code, and Factory appear less often in these results, but all are mentioned more by respondents than they were nine months ago.

Chatbot usage: ChatGPT leads – just about

Here’s how mentions of chatbot usage line up in our survey:

Tool usage: multi-tool

Most tech professionals use between two and four AI tools. An interesting detail is how many different ones are mentioned by respondents:

Noteworthy details:

• 70% of survey participants mention using between two and four tools

• 15% use a single tool

• 15% are using 5 or more

3. Popular models

Anthropic’s Opus and Sonnet dominate the ranking of models used for coding.

This is not even a contest: Opus 4.5 and Sonnet 4.5 (latest models at the start of our survey) come up more often than all other models, combined. Anthropic has become the go-to model developer for coding-related work – for now, that is. When this survey launched, Opus 4.6, Sonnet 4.6, and GPT-5.3 were not yet out.

Around 1 in 8 respondents say they just use whatever model is the default at their company. This is interesting to note: these are likely folks who might not bother changing default settings, and just go with whatever’s available. If the default model is powerful enough, that’s fine, but if the company’s default is a cheaper, less capable model, then these people could face a more frustrating experience than those who get to choose what they use.

In the “other” category of models, some other mentions include:

• Cursor’s custom Composer/Composer-1 model, and its “Cursor Auto” auto-select model

• Kimi/Kimi K2.5 — Moonshot

• DeepSeek model variants like R1, V3.2, Coder

• Alibaba’s Qwen/Qwen3

• xAI’s Grok

• Various Mistral models

4. AI trends: Mainstream adoption achieved

How often do people use AI tools? Very often, as it turns out; 95% of respondents are using them weekly, at a minimum:

It’s worth reflecting on this data in relation to insights presented by Laura Tacho at the recent Pragmatic Summit in San Francisco:

It seems that AI is now mainstream in software engineering. Anecdotally, this has been my sense since the beginning of the year: everyone whom I talk with is using AI tooling on a roughly daily basis. Now, there’s data to prove it.

How much software engineering work gets done with AI?

This year, we asked readers to estimate the percentage of their software engineering work that’s done using AI. The results:

The data show that AI is embedded in the workflows of participants in our survey:

• Only 25% of respondents use AI for less than 40% of their work

• 56% do 70% or more of their work using AI

• 75% use AI for at least half of their software engineering work

5. AI agent usage rising

Eighteen months ago, AI usage was mostly for code generation and tab completion. There were one or two respondents who experimented with early AI agents in March 2024, as something equivalent to a junior software engineer.

This year, 55% say they regularly use AI agents. This is 507 people, a massive jump!

The most common use cases for agents:

• Code review and code validation

• Automating manual / annoying tasks

• Bug fixing / investigating bugs

• Code investigation

• Debugging

• “Crafting” code, or “weaving” it together with the agent

Below is a typical-enough comment from one software engineer who uses agents at a smaller company:

“I use agents for pretty much all coding work, mostly prompting with Cursor Chat. I use it for code investigation, bug investigation, creating commits and pull requests. It’s my tool for reviewing code, I am always still in the loop. Almost all of my AI-written code is still reviewed and ‘crafted’. When using it for code review, I find it helpful to chat with and gain understanding, rather than letting it loose on code review. So, I use it for everything, but I am still very much in the loop.”

A common arrangement in the survey is the split-screen setup: a terminal with Claude Code open to drive work, and an IDE also open to review changes made by the agent.

The tools mentioned by those who regularly use AI agents split almost identically to the broader survey results:

Staff+ engineers are the heaviest users of agents. Here’s the data on agent usage by experience level:

This data point is slightly amusing because it shows there’s not much difference between the lowest and highest levels: 46% of leads and engineering managers say they use AI agents regularly, while for Staff+ engineers it’s 63%. Does it suggest the most experienced engineers are also the most curious?

The more someone uses AI, the more they also use AI agents. We segmented the data by the percentage of software engineering work that respondents do with AI:

• Heavy users have AI for 80% or more tasks, or use AI on an hourly basis

• Moderate users have AI for 30-80% of tasks, or use AI on a daily basis

• Light users employ AI for 30% of tasks or less, or use AI on a weekly or monthly basis

The more positive someone is about AI, the more likely they are using agents on a regular basis. In contrast, those negative about AI barely use agents:

One question is whether this finding indicates correlation or causation: that is, does starting to use AI agents more, actually cause people to feel more positive about AI?

A couple of details:

• Using agents seems to make people nearly twice as enthusiastic about AI (61%) as those who do not use them (36%)

• Respondents who don’t use agents are twice as likely to be skeptical (22%) about AI than those using agents regularly (11%)

It looks like that if you don’t use AI agents on a regular basis, you may have a negative opinion about the tools, in general, which could come at the cost of not experiencing what the technology has to offer.

6. Company size and tool usage

In our results, company size and tooling choice correlate for some tools; for example, the smaller a team or company is, the more likely it is to use Claude Code or Codex:

Claude Code is used by a whopping 75% of the smallest companies and teams. This is a big number, far ahead of any other tools. At the smallest places, the most-used tools are, in order:

1. Claude Code: 75%

2. Chatbots: 55%

3. Cursor: 42%

4. GitHub Copilot: 35%

5. Codex: 26%

6. Gemini CLI: 14%

7. OpenCode: 13%

GitHub Copilot overtakes Claude Code at large companies. This confirms what was known: Microsoft is very good at enterprise sales, and at bundling GitHub Copilot in its suite of products:

Cursor and OpenCode usage drops at massive companies with similar usage patterns. Across the board, usage is roughly the same, regardless of company size. We only see a drop at the very largest of companies with 10,000+ employees:

One theory for such a drop at massive companies could be that large companies often build their own internal coding agents that engineers use; e.g., at fintech, Block, the agent is called Goose, Meta has its own agent, as does Google with Jetski (its version of Antigravity) and Cider.

Google’s tools are evenly used across the spectrum of company size. Google’s Gemini CLI and Antigravity are the only tools in this survey whose usage is notably stable, regardless of company size. Both tools hover at around 10% from the smallest to largest workplaces:

The feeling among survey respondents that they can experiment at work, correlates with Claude Code being available. We asked if readers experiment frequently with tools. Below are the “yes” responses by company size:

When these responses are mapped to the percentage of people using Claude Code, there’s a very similar distribution. My theory is that Claude Code is new enough at 9 months old to have not yet been approved at companies with bureaucratic processes for approving new tools, and this is partly why some respondents feel their chance to experiment with the range of tooling is being thwarted.

Engineers at places with lots of red tape for tooling are less empowered to experiment with new AI tools; not just Claude Code, but any new, interesting tool.

7. Tools engineers love

We asked respondents: “Which AI tools do you love using the most, and why?” Below are the tools which respondents enjoy most, in descending order of number of mentions:

Claude and Cursor stand out in terms of how much they are loved. A whopping 57% of respondents mention either Claude Code (46%) or Claude models (11%) as the tools they are attached to. Cursor was at a respectable 19% – double GitHub on 9%.

Other notable tools with two or more mentions:

• Warp: a terminal for building agents

• Zed: a fast editor with agentic workflows

• Amp: a model-agnostic coding agent. A free version is supported by ads

• Cline: an open source coding agent

• RooCode: an open source, AI-powered coding assistant running in VS Code

• Continue.dev: AI checks on every pull request

Claude Code is especially loved by Director-and-above folks. Segmenting the “most loved” responses by level (engineers up to the senior levels of staff+ engineers, leads/eng managers, and Director+ folks):

Both Claude Code and Cursor become less loved – or used! – as seniority goes up, but it’s notable that folks in senior engineering leadership positions are obsessed with Claude Code, but not Cursor.

GitHub Copilot is equally loved by engineering managers as Cursor is — and this is surprising:

Both OpenCode and GitHub Copilot are surprisingly loved by Staff+ engineers. Another unexpected detail is that, despite OpenCode being used about a quarter as much as GitHub Copilot, it rivals the “loved” mentions. For Staff+ engineers, it matches GitHub on those terms:

Finally, when segmenting based on company size, we see the familiar pattern of Claude Code vs GitHub Copilot. Claude Code is less frequently mentioned as a “loved” tool as company size increases.

GitHub Copilot sees the opposite trajectory: it’s more loved within larger companies where it’s likely to be harder to experiment with alternatives.

8. Demographics

In closing, below are details about who took the survey, and how the 906 responses came together.

Engineers comprise 55% of respondents, and engineering leadership another 34%:

Respondents are experienced professionals. The median respondent has 11-15 years of experience:

Company size is also a fairly even split across this group:

Region-wise, most respondents are in Europe or the US:

Takeaways and the full report

We have compiled additional findings from this survey which did not fit in this article: it’s a 35-page article:...

Subscribed

In this issue, I talk about a very important topic for me: CI/CD pipelines, lousy dependency management tools (asdf-mise) and more importantly, YAML becoming a programming language for CI/CD, with bash code intermixed in YAML, impossible to test and develop locally, with the emergence of what I call: commit-driven-development. In order to test a coma, you have to commit to it and push it. This is not good, this is painful.

Dependency Management Is CI/CD’s Missing Primitive: from asdf and mise to Nix-driven pipelines

There’s a quiet category error that shows up in a lot of infrastructure work:

• “Dependency management” gets treated as language dependencies (npm/pip/maven…).

• Meanwhile, the toolchain + OS-level dependencies (Terraform, Node, Python, Docker, jq, protoc, compilers, libc quirks, CA certs, etc.) are managed ad hoc: random Homebrew installs, undocumented apt-get invocations, and—eventually—a lot of Bash embedded in YAML.

The result is familiar: “works on my machine” never really dies; CI pipelines become the only place the full environment exists; and the feedback loop turns into commit → push → wait → stare at logs → repeat.

This piece is about the tooling spectrum that sits underneath that mess: asdf, mise, Devbox, and Nix—and why the “local-first, reproducible pipeline” story becomes much more realistic once the environment is treated as a first-class artefact.

1) The dependency-management spectrum: tool versions, environments, and builds

Not all “dependency tools” solve the same problem. In practice, there are three overlapping layers:

Layer A: tool version managers (polyglot runtime/CLI pinning)

These focus on “this repo needs Node 20, Terraform 1.7, Python 3.11”.

• asdf popularised the “one file per repo” pattern using .tool-versions, with a plugin model per tool/runtime.
  Source: https://asdf-vm.com/manage/versions.html

• mise (mise-en-place) positions itself as a polyglot tool version manager that replaces a stack of point solutions (asdf, nvm, pyenv, etc.).
  Source:

https://mise.jdx.dev/

• aqua is another take: declarative CLI version management with a registry and “lazy install” approach.
  Source: https://github.com/aquaproj/aqua

These tools are very good at pinning versions of developer-facing CLIs and runtimes.

Layer B: dev environment managers (a consistent shell, per-project variables, runnable tasks)

This extends beyond “versions” into “the environment that runs the work”.

• Mise explicitly includes env-var management and a task runner, aiming to replace tools like direnv and make, in addition to version management.
  Source:

https://mise.jdx.dev/

• Devbox creates an isolated environment from a devbox.json and provides a shared shell where “everyone gets the same version of those tools.”
  Sources:

  • https://www.jetify.com/devbox

  • https://www.jetify.com/docs/devbox/configuration

  • https://www.jetify.com/docs/devbox/guides/scripts

Layer C: reproducible build systems (hermetic-ish builds, composable artefacts)

This is where the story shifts from “pin versions” to “define everything deterministically”.

• Nix is a package manager and build system designed for reproducible, declarative systems.
  Sources:

  • https://nixos.org/

  • https://wiki.nixos.org/wiki/Nix_%28package_manager%29/en

Nix isn’t just “install tool X”. It’s “define the whole world this code needs”.

2) Quick reality check: why Nix/Devbox get labeled “scary”

The “Nix is powerful but scary” meme exists for a reason: new concepts (the store, derivations, flakes), a different mental model, and a lot of surface area.

But two things changed the practical onboarding curve:

1. Wrapper tools like Devbox intentionally hide most Nix syntax behind JSON config (“no Dockerfiles or Nix required”), while still using Nix underneath.
   Sources:

   • https://www.jetify.com/devbox

   • https://github.com/jetify-com/devbox

2. Code agents now handle much of the boilerplate generation/iteration. OpenAI’s GPT-5.3-Codex is explicitly positioned as a Codex-native coding agent for long-horizon technical work.
   Source: https://openai.com/index/introducing-gpt-5-3-codex/

The interesting consequence isn’t “AI writes your infra”. It’s that the cost of trying Nix/Devbox drops dramatically when a model can spit out a working flake.nix or devbox.json, refine it, and adapt it to your repo shape quickly.

3) Capability scorecard (1–5): asdf vs mise vs Devbox vs Nix (+ adjacent tools)

Interpretation of scores:

• 1 = weak/limited, 3 = decent, 5 = strong/best-in-class

• For “Approachability”: 5 = easier to adopt (gentler curve)

Table A — Scorecard

Why Nix wins on “breadth” and “reproducibility”: it’s the only option here that is simultaneously a package manager and a build system with a strong “reproducible/declarative” core.
Sources:

• https://nixos.org/

• https://wiki.nixos.org/wiki/Nix_%28package_manager%29/en

Why Devbox scores high on “CI portability”: it’s explicitly designed to provide a consistent environment definition (devbox.json) that can be used by everyone on a team, and it includes a “scripts” mechanism to run the same commands inside that environment.
Sources:

• https://www.jetify.com/docs/devbox/configuration

• https://www.jetify.com/docs/devbox/guides/scripts

Notes on Dev Containers: they’re a strong story for “consistent environment”, but they’re container-image-centric; the reproducibility depends on how deterministic the Dockerfile/build is and how images are pinned. The spec centres around a devcontainer.json describing a deterministic way to create the dev container.
Source: https://containers.dev/implementors/spec/

4) Reproducibility: what “works the same” actually means

“Reproducible” gets used loosely, so it’s helpful to separate levels:

Level 1: “same tool versions”

asdf/mise/aqua excel at this: pin versions of Terraform, Node, Python, etc. It eliminates a big source of drift.
Source: https://asdf-vm.com/manage/versions.html

But tool versions aren’t the full environment. Compilers, system libraries, and transitive OS dependencies still matter.

Level 2: “same environment”

Devbox is explicitly about “a consistent shell for everyone on the team” defined in devbox.json.
Sources:

• https://www.jetify.com/devbox

• https://www.jetify.com/docs/devbox/configuration

It also supports repo-defined scripts (devbox run) so the environment and the commands are bundled together.
Source: https://www.jetify.com/docs/devbox/guides/scripts

Level 3: “same build graph”

Nix pushes further: it’s designed around declarative, reproducible builds and environments, using Nix expressions/derivations.
Sources:

• https://nixos.org/

• https://wiki.nixos.org/wiki/Nix_%28package_manager%29/en

This is where you stop thinking “install dependencies” and start thinking “define outputs”. That mindset maps unusually well onto CI/CD.

5) CI/CD today: YAML as the place where logic goes to become untestable

Most modern CI systems are YAML-driven. That’s not inherently bad—YAML is a reasonable orchestration format.

The failure mode is when YAML becomes:

• the programming language (logic inlined as Bash),

• the dependency manager (install steps embedded everywhere),

• and the only executable spec of how to build/test/release.

The compounding problem: indirection libraries (GitLab includes, CircleCI Orbs)

GitHub Actions workflows are YAML files in .github/workflows.
Source: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax

GitLab CI pipelines are YAML, and GitLab explicitly supports composing pipelines by include-ing YAML from other files or repos.
Source: https://docs.gitlab.com/ci/yaml/includes/

CircleCI pipelines are YAML, and “Orbs” are reusable packages of configuration elements (jobs/commands/executors) that you import into config YAML.
Sources:

• https://circleci.com/orbs/

• https://circleci.com/docs/orbs/use/orb-intro/

Local testing stories exist, but they’re still CI-shaped:

• CircleCI CLI can run some jobs locally in Docker (with limitations).
  Source: https://circleci.com/docs/guides/execution-managed/run-a-job-in-a-container/

• GitHub Actions can be run locally with act (Docker-based).
  Source: https://github.com/nektos/act

• GitLab has runners and tooling, but debugging pipelines assembled from multiple includes often becomes “follow the YAML graph across repos.”
  Source: https://docs.gitlab.com/runner/

All of these are legitimate tools. The deeper point is that once pipelines are mostly YAML + embedded shell, local iteration tends to remain awkward—especially as the amount of shared YAML grows across repos.

6) Local-first CI/CD: treat the pipeline as code, and YAML as wiring

A different architecture flips the emphasis:

• Put the real work (build, lint, test, package, publish) into locally runnable code.

• Use CI YAML primarily for:

  • triggering,

  • fan-out/fan-in orchestration,

  • secrets/permissions,

  • and environment selection.

This is where Nix becomes more than “a dependency tool”. It becomes the packaging format for your pipeline.

Nix’s own framing is “reproducible, declarative and reliable systems.”
Source:

https://nixos.org/

So instead of writing “install X, run Y” in YAML, the pipeline can call pre-defined Nix outputs.

Nix also has an official guide on CI with GitHub Actions, emphasising reproducible builds and caching.
Source: https://nix.dev/guides/recipes/continuous-integration-github-actions.html

Common operational glue:

• Determinate Systems’ GitHub Actions for installing/caching Nix and working with flakes.
  Source: https://docs.determinate.systems/guides/github-actions/

• Cachix for binary caching of Nix build artefacts in CI.
  Source: https://github.com/cachix/cachix-action

7) Concrete example in the wild: Mitchell Hashimoto using flakes for CI/dev test reproducibility

Mitchell Hashimoto has written about using Nix to keep environments aligned across dev and CI, framing it as a “single source of truth” problem.
Source: https://mitchellh.com/writing/nix-with-dockerfiles

For a very concrete “flake in CI” example: his libxev GitHub Actions workflow installs Nix and runs flake-based checks, explicitly aiming to keep environments consistent between local dev and CI runs.
Source (workflow YAML in repo):
https://raw.githubusercontent.com/mitchellh/libxev/e7d4e6dfd208b4d90715766f92aeaf0163e4bdd9/.github/workflows/test.yml

The core pattern is the point:

• define checks and dev shells in a flake,

• run them locally the same way,

• have CI just call those same flake outputs.

8) What “CI/CD libraries” look like in a Nix-first workflow

Instead of writing complex YAML logic, the flake (or Nix module set) becomes the library boundary.

Typical building blocks:

• devShells: the canonical dev environment used by humans and CI jobs

• checks: standardised test/lint/build checks (often what nix flake check runs)

• packages/apps: build artifacts or runnable command entrypoints

Then CI calls:

• nix flake check for a consistent “does the repo evaluate and pass checks?” gate

• nix develop -c <command> for anything that should run inside the pinned toolchain

• nix build for artifacts

YAML remains as orchestration and policy, not as an untestable programming substrate.

9) YAML’s best role: permissions, policy, and controlled deployment paths

The strongest argument for keeping YAML thin isn’t aesthetics—it’s governance.

When pipeline logic runs locally, a developer could run the deploy command locally too. Many orgs want deployment credentials and side effects to remain centrally controlled.

CI platforms are designed for that control plane:

• GitHub Actions supports job/workflow-level permission scoping for the GITHUB_TOKEN via the permissions key.
  Source: https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/

• GitHub Actions supports OIDC to AWS for short-lived role-based access (useful for controlled pushes to ECR).
  Source: https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-aws

• GitLab supports protected environments (role-based restrictions on deployments).
  Source: https://docs.gitlab.com/ci/environments/protected_environments/

• CircleCI supports Contexts to control access to sensitive env vars.
  Source: https://circleci.com/docs/guides/security/contexts/

In a “Nix as pipeline logic” setup, YAML becomes the place where those controls live:

• Which branches can run the deploy job?

• which contexts/secrets are attached,

• which permissions are granted for cloud pushes.

Meanwhile, the build/test/package logic is still a locally runnable artefact.

10) Companies and products using Nix (signals that this is not a hobby-only approach)

• Shopify: “What is Nix?” An engineering post describing Nix as a paradigm shift.
  Source: https://shopify.engineering/what-is-nix

• Replit: “Powered by Nix” (they migrated new Repls to Nix-based environments).
  Source: https://blog.replit.com/powered-by-nix

• IOG / IOHK: “How we use Nix at IOHK” (dev environments and caching workflows).
  Source: https://www.iog.io/news/how-we-use-nix-at-iohk

• Hercules CI: a Nix-native CI/CD system (existence proof of “Nix-first CI” as a product).
  Source: https://docs.hercules-ci.com/hercules-ci/

Closing thought: “dependency management” is the upstream of “CI/CD ergonomics”

If the environment is not reproducible locally, CI becomes the only reliable execution environment—and YAML inevitably accumulates logic.

If the environment is reproducible locally, CI can become what it always wanted to be:

• a secure runner,

• a policy engine,

• and an orchestrator for pre-defined, testable build steps.

That’s the core connection:

environment reproducibility → local testability → CI/CD simplicity

asdf and mise are excellent at making tool versions predictable:

• https://asdf-vm.com/manage/versions.html

• https://mise.jdx.dev/

Devbox makes the “reproducible shell + scripts” story approachable:

• https://www.jetify.com/devbox

• https://www.jetify.com/docs/devbox/guides/scripts

Nix is the fully general model: packages, shells, and builds as reproducible artefacts:

• https://nixos.org/

• https://wiki.nixos.org/wiki/Nix_%28package_manager%29/en

And modern coding agents (like GPT-5.3-Codex) lower the barrier to expressing those artefacts as code:

• https://openai.com/index/introducing-gpt-5-3-codex/

Thanks for reading Infra Weekly Newsletter! Subscribe for free to receive new posts and support my work.

Subscribed

Openclaw

A must-see video. There are huge security concerns, but this is a revolution.

“Made in EU” - it was harder than I thought.

A post about not using US services and using EU providers. But he had to use logins with the usual Google and the like, and also for distributing phone apps, he had to deal with Apple. However, there are many good and cheap hosters in the EU, including auth services, mail services, and your data stays where it belongs.

https://www.coinerella.com/made-in-eu-it-was-harder-than-i-thought/

Sailfish OS

A de-Googled OS, for your Android phone.

https://sailfishos.org/

A LinkedIn Post on Data Sovereignty

Jacek says: “Technical sovereignty is currently one of the most pressing topics in Europe. Governments and organisations are increasingly - and rightly - rethinking their dependence on US tech giants and payment providers.“

Linkedin link

Nix Kubernetes and the Pursuit of Reproducibility - Josh Rosso, Reddit

Interesting and educational video on how to create VMs and a Kubernetes cluster on NixOS. Kubernetes is created inside the VMs, but I don’t think there is a need for that, since NixOS is declarative and supports atomic updates and rollbacks. The fact that it is using KubeAdmin, which is an imperative way to manage Kubernetes, is a bit off, but see Josh's opinion on it.

Subscribed

Stream the latest episode

Listen and watch now on YouTube, Spotify, and Apple. See the episode transcript at the top of this page, and timestamps for the episode at the bottom.

Brought to You by

• Statsig — ⁠ The unified platform for flags, analytics, experiments, and more. See why companies like Notion, Brex, and Atlassian use Statsig.

• Sonar – The makers of SonarQube, the industry standard for automated code review. Join me online at the Sonar Summit on March 3rd, where myself, other eng leaders and devs will share practical strategies for the AI era.

• WorkOS – Everything you need to make your app enterprise ready. If you’re building SaaS — especially an AI product — WorkOS provides all the enterprise building blocks you need. Check out WorkOS.

In this episode

How has the day-to-day workflow of Mitchell Hashimoto changed, thanks to AI tools?

Mitchell Hashimoto is one of the most influential infrastructure engineers of our time, and is one of the most pragmatic builders I’ve met. He is the co-founder of HashiCorp and creator of Ghostty. In this episode, we talk about how he got into software engineering, the history of HashiCorp, and the challenges of turning widely used open-source tools into a durable business. We also go into what it’s really like to work with AWS, Azure and GCP as a startup.

Mitchell shares how he uses AI these days, and how agents have completely changed how he works. We touch on Ghostty, open source, and what’s changing for software engineers and founders in an AI-native era.

Key observation from Mitchell

Here are 9 observations from this conversation that I found the most interesting:

1. Vagrant was created because dev environment setup was an unbillable time sink at a consultancy. At the Ruby on Rails shop where Mitchell worked, jumping onto another client’s project could waste half a day just setting up the environment, plus destroy your existing one. Vagrant solved this in a simple and elegant way, with VirtualBox VMs.

2. Terraform won, despite being 7th to market. Mitchell is frustrated by the narrative that Terraform won because it was first to market in infrastructure-as-code. “We were seventh to market... no one was a clear winner. It was a warring market.” Terraform won through relentless conference presence, community building, and a better developer experience — not timing.

3. HashiCorp had no real business for four years and their first commercial product was a full-on failure. The initial product, Atlas, required customers to adopt the entire HashiCorp stack, which created an unsolvable internal budget problem: no one org within a company would want to purchase the whole stack! HashiCorp pivoted to selling individual services like Vault, and this approach turned out to be a winner.

4. VMware almost bought HashiCorp for ~$100, and Terraform would have not happened if it did. When HashiCorp was only 3 people, VMWare made an initial offer of $20M for the company. Mitchell and Amon (the founders) asked for $100M as the number they would sell for. VMWare took this to their board, where they rejected to buy with a single vote. Mitchell said that Terraform probably never would’ve existed if the VMWare purchase went through.

5. Mitchell’s new rule for building software: always have an agent running in the background doing something. “If I’m coding, I want an agent planning. If they’re coding, I want to be reviewing.” He kicks off tasks before leaving the house — research, edge-case analysis, library comparisons — so work progresses while he drives or is away.

6. Open source is moving from “default trust” to “default deny” — and Mitchell thinks that’s how it should be. This is because AI makes it trivial to create plausible looking but incorrect and low-quality contributions. As he put it: “open source has always been a system of trust. Before, we’ve had default trust. Now it’s just default deny.”

7. Git and GitHub may not survive the agentic era in their current form. Agents cause so much churn that merge queues become untenable, branches proliferate, and repos balloon. Mitchell compares the needed shift to Gmail’s revolution for email: “We’re at the Gmail moment for version control... never delete, archive everything.”

8. The best engineers Mitchell ever hired had boring, invisible backgrounds. “They don’t have social media profiles... they’re honestly nine-to-five engineers. They go back and they don’t code at night.” No GitHub contributions, no public profiles, companies you’ve never heard of. “Every moment you spend on social media is taking away from something else... the best engineers are the ones that context-switch the least.”

9. Mitchell’s advice for AI-skeptical engineers: start by reproducing your research, not your code. “There’s a lot of people like, ‘I don’t want it to write code for me.’ But just delegate some of the research part.” He uses agents for library comparisons, edge-case analysis, and deep research — not just code generation. “You don’t need to pick up on the ‘it must replace you as a person’ kind of propaganda.”

The Pragmatic Engineer deepdives relevant for this episode

• AI Engineering in the real world

• The AI Engineering stack

• Pressure on commercial open source to make more money – and HashiCorp changing its license

• How Linux is built with Greg Kroah-Hartman

Timestamps

(00:00) Intro

(02:03) Mitchell’s path into software engineering

(07:19) The origins of HashiCorp

(15:52) Early cloud computing

(18:22) The 2010s startup scene in SF

(23:11) Funding HashiCorp

(25:23) The Hashi stack

(32:33) Why HashiCorp’s business lagged behind its technology

(35:28) An early failure in commercialization

(38:28) The open-core pivot and path to enterprise profitability

(48:08) Taking HashiCorp public

(51:58) The near VMware acquisition

(59:10) Mitchell’s take on all the cloud providers

(1:06:02) AI’s impact on open source

(1:07:00) Why Mitchell built Ghostty

(1:09:11) Why Mitchell used Zig

(1:10:38) How terminals work and Ghostty’s approach

(1:17:31) AI’s impact on terminals and libghostty

(1:19:13) How Mitchell uses AI

(1:22:02) Ghostty’s evolving AI use policy

(1:28:36) Why open source must change

(1:31:46) The problem of Git in monorepos

(1:36:22) What needs to change to work effectively with AI

(1:39:57) Mitchell’s hiring practices

(1:47:52) Mitchell’s AI adoption journey

(1:50:41) Advice to would-be founders

(1:52:21) Mitchell’s advising work

(1:53:20) What’s changing for software engineers

(1:55:03) How Mitchell recharges

(1:55:50) Book recommendation

References

Where to find Mitchell Hashimoto:

• X: https://x.com/mitchellh

• LinkedIn: linkedin.com/in/mitchellh

• Website: https://mitchellh.com

• Ghostty: https://ghostty.org

• How Mitchell adopted AI: https://mitchellh.com/writing/my-ai-adoption-journey

Mentions during the episode:

• HashiCorp: https://www.hashicorp.com

• PHP Manual: https://www.php.net/manual/en/index.php

• Ruby on Rails: https://rubyonrails.org

• Armon Dadgar on LinkedIn: https://www.linkedin.com/in/armon-dadgar

• Amazon S3: https://aws.amazon.com/pm/serv-s3

• How AWS S3 is built: https://newsletter.pragmaticengineer.com/p/how-aws-s3-is-built

• Vagrant: https://developer.hashicorp.com/vagrant

• Google App Engine: https://en.wikipedia.org/wiki/Google_App_Engine

• Packer: https://www.hashicorp.com/en/products/packer

• Consul: https://www.hashicorp.com/en/products/consul

• Kubernetes: https://kubernetes.io

• Terraform: https://www.hashicorp.com/en/products/terraform

• Vault: https://www.hashicorp.com/en/products/vault

• Nomad: https://www.hashicorp.com/en/products/nomad

• VMware: https://www.vmware.com

• Microsoft Azure: https://azure.microsoft.com

• Google Cloud: https://cloud.google.com

• Zig: https://ziglang.org

• Kitty: https://sw.kovidgoyal.net/kitty

• Alacritty: https://alacritty.org

• Mitchell’s post on X about improving rendering performance:

Mitchell Hashimoto @mitchellh Love doing highly targeted performance work. I've been working the past few days on changing the way the render thread in Ghostty reads the terminal data (which requires a lock that blocks IO). I've got lock held time down 2.4x so far. Too early to PR, but getting close! This 1:43 AM · Nov 19, 2025 · 31K Views 10 Replies · 3 Reposts · 279 Likes

• Gastown: https://github.com/steveyegge/gastown

• Lobsters: https://lobste.rs

• Real-world engineering challenges: building Cursor: https://newsletter.pragmaticengineer.com/p/cursor

• My AI Adoption Journey: https://mitchellh.com/writing/my-ai-adoption-journey

• The Invisible Life of Addie LaRue: https://www.amazon.com/Invisible-Life-Addie-LaRue/dp/0765387565

—

Production and marketing by Pen Name.

The biggest obstacle to multi-currency ledgers is a misunderstanding of what the balance rules really are.

Currencies can’t be balanced; you’re comparing apples to oranges. In theory you can balance them using comprehensive exchange rate lists, so that currencies can be comparable. In practice, this never works: it’s like trying to join database tables by timestamps. ASOF joins might work, but time series data is never aligned perfectly. Slight delays between cause and effect can make the reconciliation process unwieldy.

What we need is to reinterpret the balancing process when multiple currencies are in play.

I’ve hinted at this idea in Ledgers of Catan, but the reality is that virtually every company that deals with more than one currency compiles a list of exchange rates (or gets one from an external provider) and uses that as a “best effort” to reconcile numbers, accepting that a compensation will be needed at the end of the period.

They’re doing ASOF joins with their money.

I’m Alvaro Duran, and this is The Payments Engineer Playbook. You’re already subscribed to free newsletters that “teach” you how to get a job as a software engineer.

But you don’t want to get a job; you already have one. What you want is to learn how to do your job exceptionally well. Especially as a payments engineer, where stakes are sky high, and the margin for errors is razor thin.

In The Payments Engineer Playbook, we investigate the technology that transfers money. All to help you become a smarter, more skillful and more successful payments engineer. And we do that by cutting off one sliver of it and extracting insights from it.

In this article, I’m going to use a multi-currency wallet company as a practical example of how to balance multiple currencies without the strictness of the rule that “every transaction must be balanced” that every accountant uses in practice. This is dangerous territory: nobody does it.

But you’ll see that it can be done, and that it makes sense...

Two weeks ago, I hosted The Pragmatic Summit in San Francisco, a few days after attending a 50-person workshop entitled The Future of Software Development in Deer Valley, Utah. Each event attracted experienced software engineers, leaders, and deep thinkers to share thoughts about the state of the software engineering industry today and in the future.

It was well-timed, considering that right now seems like a period of change for tech that’s unfolding faster than before. That was a consensus opinion at both events, also held by veterans like Martin Fowler and Kent Beck, who said things haven’t shifted so rapidly during their 50+ years in the industry.

At the very start of this year, I predicted AI will write almost all code, going forward, and several others have said the same. But at the Pragmatic Summit, I met an embedded engineer writing Assembly and C code who is still writing more of his code by hand than with AI agents – and was the only person I spoke with in San Fran who was not yet “giving in” to AI agents.

Even so, today, this engineer has between a third and a half of their own low-level code being generated by AI agents since the launch of Opus 4.5, and this share keeps on rising. Their view was an interesting counterpoint to the prevailing trend.

This article shares some thought-provoking ideas and conversations from both events, covering:

1. Data vs hype: how orgs actually win with AI. Laura Tacho’s keynote at The Pragmatic Summit. Exclusive data reveals 92% of devs use AI coding tools monthly (!!), “unhealthy” orgs see 2x more incidents, healthy ones have 50% more, and other new data.

2. Building world-class engineering orgs in the AI era. The closing session of the summit dug into what AI-native teams look like, in a fireside chat with GitHub’s former CEO and the CTO of Atlassian.

3. The Future of Software Development with Martin Fowler. Laura Tacho, distinguished engineer Annie Vella, Martin Fowler, and myself, look back on the event in Utah. Nobody has the AI shift all worked out, which is reassuring!

4. Mid-level engineers’ quiet crisis. Something I heard that engineering leaders talk about behind closed doors a lot is that mid-career engineers are being left behind by the AI wave. New grads are more productive with the tools, while seniors have more of that all-important experience. Advice on how to catch up fast.

5. Future of refactoring in an AI-native world. Refactoring legacy code has long been an important tool for keeping software maintainable. With AI generating most code now, is there any point? One answer is “hell, yeah!”

6. Future of Agile. It was only fitting to consider the future of Agile on its 25th anniversary, in the company of two of the writers of the Agile Manifesto. Amusingly, one major trend is the return of Extreme Programming (XP) practices which predate Agile.

The bottom of this article could be cut off in some email clients. Read the full article uninterrupted, online.

Read the full article online

1. Data vs hype: how orgs actually win with AI

At the debut Pragmatic Summit in SF, Laura Tacho delivered the keynote as a well-known expert on developer productivity, and former CTO of DX. She presented new and exclusive data on AI usage, and what currently works with AI adoption. Her session was one of the most popular at the conference – and you can watch the whole thing here. Full subscribers also get access to Laura’s slides.

New data points on AI adoption shared at The Pragmatic Summit, provided by DX:

Usage:

Time management:

Onboarding impact:

There’s no typical experience with AI, said Laura:

“AI is extremely different in every company because each place has its own problems and its own culture.

Organizational performance is multidimensional and these organizations are just going off to different extremes, based on what they were doing before. AI is an accelerator, it’s a multiplier, and it is moving organizations in different directions.

Some organizations are facing twice as many customer-facing incidents. At the same time, some companies are also experiencing 50% fewer incidents. So, for some companies that have used AI and have a really healthy system, it has amplified that system. They are seeing fewer incidents, moving faster, accelerating with higher quality, higher code maintainability, and higher change competence.

On the other side, we have organizations which were dysfunctional already and are now more dysfunctional: they’re dysfunctional faster. Similarly, organizations are seeing really uneven results economically from using AI.

There are a lot of steep drop-offs when it comes to using AI in a pilot context with production, and then trying to tie it to profit. This is from an MIT study in July 2025, The Gen AI Divide”.

Good analogies for the age of AI might be the space race of the previous century and the age of exploration in the 15th-17th centuries, said Laura.

• Wonder of space: space exploration includes immense hope and grounded scepticism.

• Defining moments: even though the space race was incredibly expensive – or utterly wasteful – landing on the moon was a big moment for humanity.

• Delivering but not on the grandest ambitions: in the 1960s, going to the moon carried the expectation of human habitation on the lunar surface. As yet, that hasn’t happened but landing on the moon created progress back on Earth:

There’s a rare opportunity to channel the energy around AI into practical improvements, said Laura in closing remarks:

“I want to urge you to find that balance between a sense of wonder, aiming for Mars, and a moon colony, but also understanding we need to solve problems here on Earth and we have to live in this reality.

So, please stay grounded, stay skeptical, stay human. Most of all, stay pragmatic”.

Watch Laura's keynote

Access Laura's slides

2. Building world-class engineering orgs in the age of AI

Also at the Pragmatic Summit, Thomas Dohmke (founder & CEO of Entire, and former CEO of GitHub) and Rajeev Rajan (CTO of Atlassian) took part in a fireside chat to explore what a modern, world-class engineering team looks like today. Thomas is building a new, AI-native startup with Entire – an “AI-native GitHub” – while Atlassian has more data than anywhere else on developer productivity after acquiring DX.

A number of timely, thought-provoking topics were covered by the pair on stage:

#1: What does an AI-native team look like?

Rajeev (Atlassian):

“It starts with the mindset. You have to really believe in doing AI-native work. Some teams at Atlassian have engineers basically writing zero lines of code: it’s all agents, or orchestration of agents. As a result, teams are not necessarily getting smaller, but they’re producing a lot more, sometimes 2-5x more, and creativity is up.

Efficiency framing is missing the point, it’s more about what you can create now with AI which you could not before”.

Thomas (Entire.io):

“AI native is the new ‘cloud native’ and what we are calling AI native now is going to be very different from AI native in a few years’ time.

There’s a lot of BS out there about how all day-to-day tasks are now ‘AI native’, and using agents for everything. I’m a startup founder: most of the time, I’m still dealing with things like old school HR school systems”.

#2: AI makes being distributed an advantage again

Thomas:

“A remote team is kind of lonely, right? But agents basically gave us these sparring partners, these experts that I can just ask “bring some help in for this topic, I need to write an ADR or solve a problem.

This help has taken it to a new level for remote work. I now have my code review agent, my coding agent, my brainstorming agent, my research agents. In some ways, agents have given an advantage again for being remote-first.”

Rajeev:

“Agents have changed things a lot. I remember the days when I was in the office at 2:00AM writing code and would get stuck. All you can do is read the code, then read the code some more until you figure it out.

Well, now you can ask an agent to explain it, or even better, do the code for you. So, with agents it’s gotten even better and easier for us to be able to be distributed.”

#3: Why restrictive corporate IT gives startups a massive advantage

One hilarious exchange between Rajeev and Thomas was about how large companies are slow with AI due to restrictive IT:

Rajeev: “Over the holidays, I bought a laptop because sometimes you can’t install things because of IT. So, I bought my own personal laptop at the Apple store, installed Claude Code, built an app, a bunch of Python scripts, and things like that. As someone who has grown up writing code to my personal bar, it’s super high – as it is for all my engineers. Now, I can write code much faster with agents and things like that.”

Thomas: “To all startup founders: when an investor asks how you’re preventing the incumbent from doing the same thing you’re doing: just tell them the CTO of Atlassian had to buy a laptop on his own money to start coding!

That’s the best answer I can give because it shows you how even relatively agile companies [like Atlassian, a promoter of Agile] that actually develop agile tools, can’t really do what you can do in five minutes!”

#4: Why CTOs are rolling out agents with top-down mandates

Thomas discussed how engineering leaders introduce agentic tools after playing with them as side projects.

“What happened in the last two years through coding agents like Copilot, Cursor, and Devin, is that many CTOs and CIOs, even in the largest banks, realized they can go back to coding. It no longer takes hours to install all the packages and figure out all the problems.

I actually have friends in these spaces who tell me stories of how every night they’d give the agent a task and say: “build me this.” Then, in the morning they would check in with the agent and instruct it to keep going. And then they have their normal day-to-day as CTO of a big bank.

You do that for two weeks and you realize everything is going to change – and that it has to change in my organization. And in contrast to the Twilio founders – in their case, they had developers decide, bottom up, what tools to use – these CTOs and CIOs say: “I don’t want to hear any excuses. We’re going to roll out agents.”

Still, many banks are on very archaic systems and have developers log into Citrix, and jump through all sorts of hoops to use agents.”

Claude Code was introduced in a similar way at Canadian fintech, Wealthsimple, as we covered two weeks ago.

The fireside chat touched on more subjects, including the changing role of software engineers and engineering leaders, and the biggest changes Thomas and Rajeev expect this year.

Watch the full session here

Full subscribers can already check out all sessions at The Pragmatic Summit, Q&A included. You can now also watch the other keynote session: How AI is reshaping the craft of building software with OpenAI and the Codex team. The other sessions without Q&As will be released next week for everyone.

The remainder of this article covers an event hosted by Martin Fowler.

3. ‘Future of Software Development Summit’ with Martin Fowler

Back in February of 2001, a group of 17 software developers gathered at a ski resort in Snowbird, Utah, where they drafted and signed the famous Agile Manifesto.

Almost exactly 25 years later, Martin Fowler and Thoughtworks organized a retreat at almost the same place in Deer Valley, Utah. He invited around 50 tech leaders from large enterprises and nimble startups, researchers, authors, and experienced, hands-on software engineers. Held earlier this month, it was “The Future of Software Development,” and I was delighted to attend the two-day gathering featuring Annie Vella, Kent Beck, Steve Yegge, Gene Kim, Laura Tacho, – and of course, Martin himself.

This was no attempt to draft a second landmark manifesto; rather, it was an opportunity to share notes and consider where the tech industry might be headed. It was an intense day of back-and-forth about what we’re seeing and what to make of it.

One declaration was drafted. Kent Beck, Laura Tacho, and Steve Yegge, came up with an apposite statement on inflated expectations upon AI to magically improve everything in workplaces:

“Organizations are constrained by human and systems-level problems. We remain skeptical of the promise of any technology to improve organizational performance without first addressing human and systems-level constraints.

We remain skeptical and we remain human”. – Kent Beck, Laura Tacho, and Steve Yegge.

Personal notes

I have my own thoughts on the topics covered:

Everyone, everywhere is adopting AI rapidly, which in some ways is very surprising. Looking back on tech innovation over the last 20 years, such as mobile, cloud, or even crypto – adoption was gradual. For example, native mobile progressed like this:

1. Indie devs: in the first few years, startups, experimental individuals, and teams onboarded to the new technology. For native mobile apps, 2008 was when iOS and Android launched their app stores. Between 2008 and 2010, it was mostly indie developers, small teams, and companies that built their apps.

2. Startups and forward-thinking companies: a few years later, more startups saw the opportunity to jump in. For example, Uber was founded in 2010 and Snap in 2011. Some forward-thinking places also launched in this period, like Starbucks with an iOS app in 2009.

3. Larger tech companies: Years on, some forward-looking, larger tech companies adopted the technology. For example, Bank of America launched an app in 2011 (3 years into native mobile), Yahoo started to go all-in on native mobile apps from late 2012.

4. “Traditional” tech companies finally catch up: Eventually, slow-moving companies also move over when it becomes a baseline expectation to use a new technology. For example, Ryanair launched its native iOS app in 2014, six years after native mobile apps emerged.

Contrast that to today, when it seems like everyone is moving all at once. I talked with folks from companies like John Deere (agriculture), 3M (industrial products), Cisco (networking hardware), WealthSimple (finance), AWS (cloud), and startups, and none could be called “behind.” Every company is rolling out agentic AI tools; for example, WealthSimple did a global Claude Code rollout just a week earlier.

Based on past experience, you might expect at least some traditional companies with no exposure to AI to wait and see what happens. But I found none doing so.

Traditional, “old school” companies don’t seem to be lagging behind the pace. A traditional company with 10,000+ developers has more than 50% of software development outsourced. This place founded an AI platform team with a mission to eliminate outsourcing activity via a mix of efficiencies from AI tools and targeted hiring.

They have already built an AI debugging agent popular across the whole business that’s connected to all internal systems like monitoring, logging, and internal data stores. It helps a dev pinpoint any and all errors and bugs. This platform team is building more internal tools and hiring aggressively.

It’s a similar story at other trad places: most are already using AI agents, some are experimenting with AI used for large-scale refactors, and others are seeking use cases for agent swarms.

Smaller engineering teams are a certainty. Around 20 engineering leaders – many at large enterprises, some at tiny startups – said that engineering teams are shrinking. One head of engineering at a 200-year-old company in the agriculture sector put it like this:

“We are already seeing the end of two-pizza teams (6-10 people) thanks to AI. Our teams are slowly but surely becoming one-pizza teams (3-4 people) across the business”.

To emphasize, this is one of the most traditional companies which sells physical goods and hardware, and whose business has no disruption to fear from AI. But they’ve also adapted!

Observations from Laura Tacho

Laura was kind enough to share her notes on this event for this article:...

Stablecoins will have truly achieved adoption when we no longer need to talk about stablecoins.

When you pay with your credit card, the last thing you want to know about is the infrastructure involved in it. What you want to see is the green light, the check mark, the “Accepted” message. The end user of a card doesn’t even want to think about the payment at all.

The best payment experience is the one where you think that the money was instantly transferred. Even when it wasn’t.

The biggest promise that stablecoins are making is that it won’t change anything in the real world. That stablecoin’s actual goal isn’t to upend the payments industry, but to clean house. Ideally, using stablecoins to move money around might change the players, but leave everything else the same.

Sweeping clean the messy back, but leaving the facade alone.

On another level, the same thing has to happen to payments engineers. Stablecoins have to feel exactly like ACH, FedNow and Wire: battle-tested protocols for transferring money that, to some extent, are interchangeable.

So, apropos of their launching of a new integrated PSP for fiat and stablecoins, I sat down with Sam Aarons, CTO and co-founder of Modern Treasury, and Dan Mottice, founder of Beam, and now Head of Stablecoins at Modern Treasury following Beam’s acquisition.

The team at Modern Treasury and I have been circling each other for quite some time since I published an article on their approach to ledger authorization using events a while ago.

Finally, the timing and the topic have aligned completely. As I told them, I wanted to have a conversation so that we could talk shop and have a good time, with complete freedom to write an article afterwards that was valuable to readers.

This article is the result of that conversation.

I’m Alvaro Duran, and this is The Payments Engineer Playbook. It is the only newsletter on Earth tailor-made for engineers of money software. Every week, we investigate the technology that moves money around, so that you become a smarter, more skillful and more successful payments engineer.

And we do that by cutting off one sliver of it, and extract insights from it.

This week’s article is the first interview-based article I’ve done in The Playbook. Following my skeptic take on stablecoins, I sat with two of the engineering leaders of Modern Treasury to put my skepticism at ease, and see what the future holds for payments as this interesting piece of tech gains adoption.

Enough intro, let’s dive in.

A new form of liquidity

Seems like I hit the nail in the head a couple of weeks back when I said that stablecoins were the international transfer method that you would’ve come up with if you really didn’t want to deal with banks at all:

The good thing about crypto, and the reason why the transaction costs are so low, is because there’s nothing central about it. The recipient may be on the other side of the world, and they have the same level of access and visibility to it than you. It may be slow, but not SWIFT slow. And it’s way cheaper.

So what we probably need is something that’s crypto-like, to retain the global aspect of such a ledger, but without the volatility of cryptocurrencies. One way to do that is to have a blockchain that distributes the value of a predefined pool of resources, something that doesn’t change in value against a fiat currency.

So that’s what stablecoins really are. And they’re now facilitating $30bn of transactions daily.

TigerBeetle's Stablecoin Mistake Alvaro Duran · Jan 21 Read full story

When I mentioned this to Sam and Dan, they both laughed. “We internally call that Stablecoin Sandwich.”

It’s so visual: you have fiat on both ends of the transfer, but there’s a black box in the middle, responsible for moving value from left to right, in which your Canadian dollars get converted to stablecoins by an on-ramp partner, and then into dollars by an off-ramp partner. Modern Treasury then can send those dollars with traditional rails like ACH or FedNow.

Fiat on both sides, with stablecoins in the middle.

The stablecoin sandwich is what bridges the crypto and the fiat world. It’s what makes stablecoins “feel” like fiat, even though they aren’t.

Cross-border payments have been clunky since time immemorial. SWIFT, or more generally correspondent banking, was devised when most “long distance” transfers were made by flying checks in bags all over the US. Western Union, or money transmission, was the first private approach to solve cross-border transfers, by setting up a massive enterprise with agents in multiple countries around the world on the ground.

Then came Wise, whose founders realized that money didn’t need to move cross-border at all. Payment aggregation simulates “sending money” by finding and crossing supply and demand for foreign currency within the country of origin and destination separately.

Still, there’s always a company in the middle. Unlike other cross-border transfer methods, stablecoins are interoperable: the blockchain is publicly accessible, and moving money on top can be done without the need for intermediaries.

Stablecoins are a bit more difficult to use, and that’s why you may benefit from using liquidity providers to make things easier. But you don’t need them, not in the sense that you need banks to send money via ACH.

And not needing a bank is precisely what Modern Treasury is aiming at.

No bank? No problem

It’s not that banks are a problem. It’s that dealing with them makes everything way slower:

Too many companies are held back by unreliable payments infrastructure and slow, complex bank integrations. With Payments, we’re giving teams a faster path to market than BaaS or securing their own bank sponsorships.

— Matt Marcus, CEO of Modern Treasury, on the Payments announcement

MT’s strategy is to move from nothing to providing financial services as fast as possible. But payment orchestration and ledgering are just the technical steps; non-technical steps like bank partnerships and compliance with regulators across countries are also required.

There are two ways to approach this problem.

One is to Bring Your Own Bank, an acronym that I keep seeing in the fintech space even though it was first used elsewhere. With BYOB, you handle the non-technical side of things yourself, and bring a technical partner like Modern Treasury or a BaaS into the mix. BYOB sounds complex, but it’s sometimes the only option available. Most BaaS work exclusively with one bank, coupling your choice of BaaS with your choice of bank.

On the other hand, an integrated PSP handles everything for you. Modern Treasury’s PSP handles most of the paperwork and the banking relationships, and you deal with MT directly.

You trade control for go-to-market speed.

Problem is, in the beginning, you may not have support for some features, even when you’ve done everything you could to start. That’s where stablecoins come in. Since no bank is required, you could theoretically start transferring value in stablecoins right away.

This was the missing piece in the PSP puzzle that is now available thanks to stablecoins. But there are more things you can do with them.

The Flow and The Meta-flow of Funds

Yes, cryptocurrencies were built on speculative use cases. But that’s a boring form of skepticism.

Given where crypto has evolved to, stablecoins represent a maturing phase of decentralized finance. One that acknowledges that fiat isn’t going away, and attempts to bridge some of the functionality that’s useful about blockchain (decentralization, trust-less value transfer) to the world of the normies.

There’s the flow of funds, and there’s the meta-flow: moving more of fiat into usable crypto.

• Bank accounts become crypto wallets that store stablecoins. You can now hoard dollars, even when you can’t hold them.

• Treasury management becomes “hybridized”: moving actual dollars may be difficult, or incur taxes, but moving stablecoins isn’t.

Yes, there was a time when private keys were much more exposed and easier to steal; the industry is now aware of this problem. Blockchain is trustless, but you can trust someone with your keys and never have to fend off hackers anymore.

That’s not the thing you must be alert about stablecoins.

The Skeptic’s Last Question

Stablecoins are cheaper and faster than fiat. They’re not volatile like Bitcoin, and are even programmable, so you don’t have to deal with lawyers, but with transparent code.

So what’s the catch?

In what way are stablecoins inferior to the traditional way of moving money across countries, that accounts for more than 99 percent of the total flow of funds right now?

The answer is: usability.

“Stablecoins are unforgiving” is how Sam put it. There’s no takesies-backesies in the crypto world. That’s what removes banks from the equation. In ACH, you get your funds returned when you send money to a dead person; in crypto, you have to ensure that everything is correct in advance, because once you hit Pay, there’s no going back.

In a world where the rules are written in code, comments are for information, not control.

“The plus side of this”, Sam followed up, “is that some players may like this trade-off, which wasn’t available for them before”.

Stablecoins are consistent payments experience

For crypto to become usable, developers must not have to use a different set of APIs to deal with them.

This echoes an idea that I’ve continually come back to: the mistake that Stripe made when they assumed that all payments were card payments:

Payments are deceptive.

Representing a Payment with a single object sounds simple, but that’s because you’re moving the complexity elsewhere. The Token/Charge architecture was the obvious choice, but it made integrating other payment methods way more difficult.

And that could work if all you need is credit card payments. But that is less likely than it used to be.

In time, Stripe’s engineers understood that 7 lines of code wasn’t everything. They looked at the problem as a whole, and asked how they could make adding new payment methods easier.

That, in the end, is what’s making developers more productive. Which was Stripe’s goal all along.

Stripe Made The Obvious Choice When Building Its Payments API. It Took Two Years To Fix It. Alvaro Duran · July 31, 2024 Read full story

What MT is trying to do here is something similar: build an API that’s consistent across all forms of money transfer.

Sure, faster go-to-market is a good thing for many companies. But the real boost is in the technical integration and expansion of those who are interested in crypto, but deeply embedded into fiat.

How can they test the waters with minimal developer effort?

Major businesses, even when curious, aren’t going to deploy a team of engineers just to see if stablecoins are hype or not. They want to get their feet wet, and therefore won’t commit to it unless it requires almost no effort to do so.

Such an approach is only possible when both fiat and crypto use the same set of endpoints to operate.