In some pockets of the industry, an axiom of software development is that deploying software quickly is at odds with thoroughly testing that software. One reason that teams believe this is because a fully automated deployment process implies that there’s no opportunity for manual quality assurance. In other pockets of the industry, the axiom is quite different: you can get both fast deployment and manual quality assurance by using feature flags to decouple deployment (shipping the code) and release (enabling new functionality).
There's no reason for software to be slow anymore
The other day, I saw a viral tweet saying that people talking about how LLMs are causing slow, bloated, code are going to eat crow once they re-write everything in super-optimized assembly. We're not quite at the point where we want to write everything in assembly, but some variant of what Nolan Lawson said about testing, you can choose how many bugs you want now, which I less eloquently noted here, is becoming more true for performance.
Slow Software
What it means for software to be fast, and why most software is not.
Towards zero-downtime upgrades of stateful systems
Most deployed programs need to be upgraded at some point. The reasons vary from adding new features to patching a bug and potentially fixing a broken state. Even though upgrades are an essential part of software development and maintenance, programming languages tend to not help the programmer deal with them in any way.
Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools
How do the productivity effects of AI evolve across successive generations of tools, and to what extent do task-level gains ultimately translate into final output? We study these questions in the context of software development, using data on more than 100,000 GitHub developers combined with their AI usage telemetry. In a matched event study design, we find that autocomplete, interactive coding agents, and autonomous coding agents each significantly increase coding activity ("commits"), with respective cumulative effects of 40%, 140%, and 180%. These gains, however, attenuate sharply across the production hierarchy: the 180% cumulative effect falls to 50% for the number of projects, and to 30% for actual releases. This pattern is consistent with the weak-link hypothesis: the strong productivity gains from AI are attenuated by human bottlenecks in the production chain, with an estimated elasticity of substitution of 0.25 between AI and human effort, which indicates strong complementarities. We further confirm these results across four major app marketplaces, finding a moderate increase in the number of new apps but no increase in total usage. Large task-level AI productivity gains have therefore translated only partially into shipped and used software thus far.
The Case for ‘Developer Experience’
How are developers supposed to manage and coordinate fast-moving, heterogeneous systems including maintenance & operations — and free themselves to build?
Architecture - Continuous Delivery
In the context of enterprise architecture there are typically multiple attributes we are concerned about, for example availability, security, performance, usability and so forth. In continuous delivery, we introduce two new architectural attributes: testability and deployability.
The 10 Best Practices for Remote Software Engineering
At face value, when we think of developer productivity we might think of effectiveness in time management, communication, and task completion.14 Although we are drawn to personal workflow or time management tools, and learning secrets to improving our productivity, ironically this quest for the holy grail can sometimes take us off course and be a detriment to our productivity. The problem is that accomplishing tasks or having a filled up schedule does not necessarily equate to productivity. Creating a formulaic working strategy, as was common in the last century, does not either.a,8,13 Productivity is less a quality that can be easily measured,b controlled, or improved directly with tools, but instead is a human element that manifests from developer happiness.
The disproportionate influence of early tech decisions
On how software that survives first encounter with production tends to live longer than we think it should.
The Software We Haven’t Invented Yet, discussion and dinner hosted by Boxd and BlueYard · Luma
If this is such a big moment for software, why are we mostly imagining faster versions of what we already do? Better coding tools are the obvious part. The…
On genAI: Was prototyping really a bottleneck?
I keep hearing folks claim that the fact we can ‘prototype’ so quickly now is a good thing (thanks to modern genAI). But what if the slow parts about prototyping are actually what make it worth doing?
AI Tools Accelerates Coding, but Not Overall Software Delivery, GitLab Research Finds
GitLab's 2026 AI Accountability Report highlights an AI Paradox: although 78% of developers say they code faster, overall software delivery has not accelerated due to downstream testing and review bottlenecks and new challenges for enterprise governance and traceability.
Balancing “If it ain’t broke, don’t fix it” vs. “Release early and often”
Every organization faces a war between two schools of thought, with “If it ain’t broke, don’t fix it” on one side and “release early and often” on the other. This blog post looks for a way for enterprise consumers to embrace fast-paced changes in the software industry.
AI Makes Better Software
Don't use AI to ship software faster. Use it to ship better software.
Is High Quality Software Worth the Cost?
We usually perceive that it costs more to get higher quality, but software internal quality actually reduces costs.
Code Is Cheap Now. Software Isn’t.
The barrier to entry for building software has collapsed. The barrier to building something that matters hasn’t moved an inch.