DEV Community: Steve Fenton

Continuous Delivery Office Hours Ep.3: Branching strategies

Steve Fenton — Mon, 15 Jun 2026 12:09:50 +0000

Your branching strategy can support Continuous Delivery, or make it an impossible goal. You should assess the impact of how you branch on your ability to deliver software at all times, and you'll find some branching techniques that work, while others that make software delivery more like walking in the dark through a field of rakes.

Continuous Integration is the practice of integrating code changes frequently, typically multiple times a day. This means you should check your code multiple times a day and keep your main branch deployable. Continuous Integration is a prerequisite for Continuous Delivery.

The name "Continuous Integration" provides solid hints about the crucial parts of the practice. Everyone should integrate their code into a shared branch (feature branches don't count) and this should be done continuously, which means you're doing it all the time; at least once a day, but ideally more often.

You'll often speak to developers who want to stretch the definition of Continuous Integration, but you can't escape those foundations. Merging the main branch into a long-lived branch feels like Continuous Integration, but you'll notice no changes come back for ages until someone finally merges to main. Then you have to perform a large, complex merge, which you should avoid.

The DORA research on Continuous Delivery includes the capabilities of Continuous Integration and trunk-based development. The statistics suggest you can get similar benefits as long as you limit yourself to 3 (or fewer) short-lived branches (less than a day old).

Watch the episode

You can watch the episode below, or read on to find some of the key discussion points.

Watch Continuous Delivery Office Hours Ep.3

The worst branching strategy

Since the ability to branch code was invented, developers have applied a great deal of creativity to how to use branches. The most common approach is feature branching, where each feature gets a branch of main that evolves separately until the feature is complete, and it's merged back into main. Release branching allows development to continue on main by taking a cut of the main branch that will be released. This allows hotfixes to be applied to the release branch without further destabilizing it.

The utility of branching strategies is often eroded by the coordination overhead of maintaining the separate branches and merging different changes back together. The more complex the branching strategy, the more likely it is that you'll have merge conflicts and lost bug fixes. For example, you might fix a release branch and forget to merge the fix back to main, so the next release reintroduces the bug.

This is why the worst branching strategy is Gitflow. This is a complicated branching strategy that creates dedicated branches for features, releases, and hotfixes alongside permanent main and develop branches. The overhead of Gitflow vastly outweighs its benefits.

This is where trunk-based development shines, as it removes unnecessary complexity.

The best strategy is trunk-based development

Trunk-based development is the process of making all commits directly to the main branch. This is complemented by out-of-band reviews that don't block merging and by feature toggles that decouple deployments from releases. It should be possible to deploy your software from the main branch at all times, even if features aren't complete.

The DORA research allows up to 3 short-lived branches, which can be useful for teams working remotely (like open-source project teams), who can use branches and pull requests to coordinate their work. Even so, the goal is to keep branches short-lived and to merge frequently.

Trunk-based development is complemented by automated builds and checks that run when code is committed to the main branch. If a problem is found during these checks, the team should prioritize the fix over other development work.

Elite performance comes from small batches

Teams with the best software delivery performance work in small steps. Trunk-based development and Continuous Integration are crucial practices for controlling batch size. Problems are discovered sooner and are easier to fix when you only have a small amount of change to reason about.

Making frequent commits makes it easy to back out a bad change. If a test fails, you can discard changes since the last commit and try again, instead of trying to debug the problem. This is especially true when using AI coding assistants or other code generation techniques.

Ultimately, for trunk-based development to succeed without friction, the entire team must be aligned on the process. It doesn't work if only some of the team are on board.

Continuous Delivery Office Hours is a series of conversations about software delivery, with Tony Kelly, Bob Walker, and Steve Fenton.

You can find more episodes on YouTube, Apple Podcasts, and Pocket Casts.

Gravity Applies To Robots

Steve Fenton — Thu, 11 Jun 2026 06:57:04 +0000

Or, why AI systems fail in surprisingly familiar ways.

With the introduction of AI-assisted coding tools and agents, many people were hoping we’d solve all the problems of human teams. Without the people, politics, and personalities software delivery would be easy.

This vision is appealing because we’ve long blamed people for the failures in the system. But the evidence from multi-agent AI provides an awkward truth. The same classes of failure still happen in the same places, for reasons that have nothing to do with humanity.

So, why do large batches of work still fail once you’ve eliminated laziness and stupidity?

Project Village

Traditional thinking on software projects is like a strange village. It has been cut off from the rest of the world for thousands of years and has developed some interesting beliefs about the laws of nature. They carpet their walls, which makes it hard to vacuum. They make their roofs out of glass and struggle with indoor temperatures. And they make clothes from hair, because nobody is allergic to their own hair.

Perhaps the strangest thing about the village is that they believe gravity is an act of human willpower.

All the animals in the valley are birds, which seem to cling to the branches of bushes, else they glide away into the sky. They also have no fruit trees, which means they’ve never had a Newtonian epiphany. Without evidence to the contrary, their collective delusion has persisted for many generations.

If you visited the village, you’d hear such philosophical musings as “The earth keeps those who keep themselves,” and “I will, therefore I stand.” Every Wednesday they gather in the town hall to remind each other that “If you stand firm in mind, the ground will rise to meet you.”

To tackle the problem of carpet cleaning, the village invented a cast iron humanoid robot that vacuum-cleans the walls. To stop the robot floating away, they built suction devices into its heels. One day, a robot is being moved between houses when its power fails.

To their amazement, the robot doesn’t float away. The village philosophers gathered together to discuss this strange event. The only logical conclusion they could reach was that the robot had developed human willpower, which allowed it to remain earthbound. How else could it stay on the ground?

It’s Not Willpower, It’s Gravity

Outside of the village, we all know that gravity works on robots, just like it works on people, birds, and rocks. That doesn’t prevent us from making a similar mistake when it comes to building software.

Large software projects frequently fail and the people in charge blame human factors. Blaming people for these failures because they’re slow, lazy, dim-witted, and require rest is like the village believing gravity is a manifestation of willpower.

The reality is that software delivery has a form of gravity that increases relative to batch size. This is why swarms of AI agents fail in all the same ways teams do when you give it large and complex tasks.

In The Organizational Physics of Multi-Agent AI, Jeremy McEntire describes an experiment where the same multi-service backend system was created by different arrangements of AI agents. There is a belief that co-ordinating a team of AI agents will allow more complex tasks to be handled by AI, but the result of the experiment was that the coordination complexity outweighs the benefits of the division of work between multiple agents.

The failures of multi-agent work look familiar. They are the same as the failures of large projects, except there are no humans to blame. This proves the challenges are inherent to complex work and cannot be attributed to human factors.

It strikes me that we have been blaming human factors for bad systems for too long and we need to acknowledge they’re not the reason for past IT system failures.

A Babbling Equilibrium

“When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean — neither more nor less.” — Lewis Carroll, Alice’s Adventures in Wonderland

When I say “rock”, some of you will think of geology (rocca comes from Latin) while others will think of music (roccian comes from Old English). A select few may think of a seaside hard-sugar treat, or a tool used to hold unspun fibers.

For something as simple as a word, I can reduce your interpretive preference by putting the word into a sentence. When more complex communication takes place, it’s rare to have perfect alignment on the meaning we intend to communicate. Communication precision reduces from perfect alignment and can degrade to a babbling equilibrium where no information is received in the message.

This misalignment can be understood through the pre-DevOps problem of having a development team measured for throughput and an ops team measured for reliability. When you communicate the same information to these two silos, interpretation will vary drastically.

This challenge in transferring information remains when a human instructs an AI agent to do work. Hence the counter-arguments of “you’re prompting it wrong.” What surprises more people is that it remains when AI agents send messages to other AI agents. This is why the multi-agent configurations performed worse than single-agent setups.

When you understand why agent swarms compound the problem rather than solving it, the answer starts to look familiar. These aren’t new problems. Long before AI agents, human development teams were failing for exactly the same structural reasons. The teams that recovered did so by tackling the structure, not the people.

Fixing the System of Work

In my past roles, I was often asked to join a company to “fix the development team.” They had reached a stage where every deployment turned into a high-severity incident, every change resulted in highly visible bugs, and the business had lost faith in the ability of the team to deliver working software.

The teams usually had basic tools in place, like version control and automated builds. What was missing was the rest of the deployment pipeline, and this was the root cause of all the problems. Here’s how I’d fix it.

Deployment automation made production releases repeatable and reliable, removing the most painful and wide-reaching failures of these teams. This led to more frequent deployments, which in turn reduced the size of work batches. Breaking work into smaller steps is a good way to improve communication success.

Test automation increased our confidence that the software was deployable. It wasn’t uncommon to find teams with no automated tests, so adding characterizing tests around the most important features reduced the number of embarrassing software versions the team produced, such as the kind where nobody can even sign in.

Monitoring and alerting helped the team understand how the system ran in production. As we fine-tuned the tools, the team became the first people to know when there was a problem, or the early signs a problem was emerging. By prioritizing work that kept the software healthy, we improved the relationship with the business, including executives who dealt with complaint escalations, and we made customers happier with the software.

The result of these three changes isn’t just improvements to deployments, software quality, and observability. Having a complete pipeline lowers your batch size. This keeps complexity low and solves the communication and co-ordination problems that become insurmountable in large batches of work. The kind of problems that make it impossible for AI agents to deliver working software, just as they prevented teams from doing it.

Batches Have Gravity

There are fundamental laws of software delivery that mean batches have a gravitational force that becomes unmanageable by human teams or AI agents. The larger the batches, the heavier everything gets, increasing the amount of energy needed to move things.

Rather than searching for bigger tractors to move giant objects, organizations with modern software engineering practices make everything fit in a lightweight backpack. Small batches are the secret sauce behind Continuous Delivery and the DORA research increases our confidence in this approach.

Just as Fred Brooks observed in “The Mythical Man Month”, adding people to a late software project makes it later. McEntire’s research suggests this applies equally to situations where you simply increase the number of AI agents tackling the work.

Continuous Delivery remains the best way to deliver software, no matter who or what is writing the code.

Why Octopus invests in developer experience

Steve Fenton — Mon, 08 Jun 2026 16:27:59 +0000

When you join Octopus, you get a great laptop and your choice from a range of docks, monitors, webcams, and input devices. You also get a home office allowance, which lets you upgrade your space and get 50% back. You may want a sit/stand desk, an awesome chair, and portrait lighting so everyone can see how delighted you are when they demo their cool new feature.

What we ask in return is that you set yourself up to do your best work. Invest in your brain, bytes, back, and buns, as Scott Hanselman put it. The essential idea behind this is that when you win, Octopus wins. We all win!

Yet you can throw a soggy cat at a conference, and the chances are it will splash someone from an organization with a completely different approach to developer experience. One that doesn't value the sustainable delivery of their people's best work. Why is that?

A fork stuck in the road

As we've seen in the software industry, silos are the source of all kinds of chaos. DevOps was created when someone realized the scale of the problem caused by having two teams with conflicting goals working on opposite sides of the same problem. Leaders whipped developers up for feature throughput and wanted to hold operations teams to account for reliability.

In hindsight, it's obvious that this isn't going to work, but we did it for decades. You can get halfway to DevOps just by aligning the goals. When both teams share the same target, they'll work out how to get you the rest of the way.

If we zoom out on our organization, we're likely to find a similar silo/goal conflict between engineering managers and the finance team. We ask the engineering manager to build a high-performing team, while we direct finance to spend as little money as possible. This structural incentive problem leads developers to get laptops and tools that someone has negotiated to be "good enough," and trust me, they aren't.

When you look at developer experience through a FinBoss lens, where finance and engineering managers align around the return on investment, you'll find the optimal spend on developer tools shifts right rapidly.

FinCost organizations reduce costs through standardization, commoditization, and by delaying kit refreshes for as long as possible. They often spend less than $1,000 on a laptop without realizing the true cost of an under-spec'd machine. Meanwhile, FinBoss organizations are seeking the $30,000 annual return on a $3,000 investment.

To achieve this ROI, finance and engineering leadership work together to design policies that allow engineers to choose from a set of well-designed options. The combination of investment in great tools and individual choice in building the right setup is the path to success.

Tiny visible costs

FinCost organizations are driving decisions based on small, visible costs. Where there's a paper trail, there are savings to make: the purchase of a laptop, the training budget, and the conference invoice. These are part of the legible model, so there is no guesswork or experimental method needed to cost them. The numbers are right there on the page.

Once you're managing costs, it's not uncommon to dial up the control, too. You limit options, standardize across the organization, and negotiate in bulk on everything to drive costs even lower. Compared to competitors, you could be spending 75% less on laptops, and just look at the savings from those pesky licenses and SaaS tools various teams were using. Hooray.

Instead of letting engineers attend conferences they find relevant to their work, the organization negotiates a bulk purchase for a single conference. Instead of teams buzzing with diverse ideas and approaches, they all sit and watch the same talk. It's cheaper that way.

A wooden fence encloses my garden. A fence lasts a long time if you give it a protective coat of wood preserver every once in a while. A tin of wood preserve costs about $20 and a few hours of mindful application each year. Over 5 years, I can save $100 by skipping the treatment. If I do this, my fence lasts about 10 years instead of 30.

The cost of a tin of wood preserver is immediate and visible. The cost of replacing the fence is far higher, but it won't be visible for years. Additionally, if the fence provides value beyond privacy, like keeping a goat out of my vegetable garden, the cost of the fence failing could be the cost of my whole crop, which is even less legible to my cost control mindset.

If you're creating software, it's likely to be more valuable than a fence. In fact, it should be giving you returns multiple times your investment. It's like a golden goose. You feed it well, and you get regular, valuable deliveries. If you had a golden goose, you wouldn't try to save on food costs if it reduced the flow of golden eggs.

The same logic plays out with training. A FinCost organization cuts the training budget because the line item is visible and the return isn't. Individual engineers stop attending relevant courses, and teams miss out on the steady accumulation of skill that comes from ongoing, targeted learning. Nobody raises a purchase order for "capability that didn't grow this year."

Then something goes wrong. Delivery is slow, the codebase is a mess, or a competitor pulls ahead. Someone decides the answer is transformation, and that means Scaled Agile, or whatever flavor of desperation is in fashion in exec suites at the time.

So the whole department gets booked onto an external SAFe course. Not one or two people who need it. Everyone. The invoice lands, and it's eye-watering: many times what a thoughtful, ongoing training program would have cost across the same period. The organization that was too cautious to spend $500 on a course people wanted just spent $50,000 on one nobody asked for.

This is the hidden tax of FinCost thinking. Small, visible costs get cut. The problems that those small costs would have prevented quietly compound. Eventually, the pressure releases all at once, in an expensive, rushed, and hard-to-argue-against way, because now there's a crisis with a visible price tag.

The tin of wood preserver was the right investment all along.

The invisible people-hours

Developers work around 40 hours a week. Stripe's Developer Coefficient found that productivity friction can eat up roughly half of those hours. That's the time that evaporates before a single line of useful code is written. Across the global developer workforce, Stripe put a number on that loss: $300 billion. It's worth noting that only $85 billion of this is attributable to bad code. The rest is pure friction: slow tools, broken environments, waiting for builds, wrestling with under-spec'd machines. Productivity means more than writing code faster.

That friction has a texture. It's a developer losing flow because their laptop is thrashing memory, and they've lost the thread of what they were thinking.

It's waiting 10 minutes for a build that would have completed in 2 minutes on a faster machine. It's the workarounds you built because the approved tool wasn't good enough, which obliterates hours of your week for maintenance. It's the skilled engineers who start looking for a new role because the environment makes them feel like you don't take their work seriously.

None of this appears on a purchase order. None of it shows up in a variance report. It just quietly drains the value your software could be creating.

There's also an upside case, not just a loss case. Software that ships faster captures more market share. Developers who stay in flow write better code with fewer bugs, which means less rework and fewer incidents. A high-performing team attracts other high performers. The return on investing in developer experience isn't just "we lose less time"; it's sales opportunities, reduced churn, higher product quality, and a compounding advantage over competitors who are still buying $800 laptops and calling it responsible.

When you focus on cost control, there's a ceiling on how much you can save. When you look for return on investment, there's no equivalent ceiling on how much you can gain.

The CFO lens

When I asked Sammy, our CFO, about why we invest in people, powerful machines, and great tools, he said: "At Octopus, we think about equipment as a productivity tool. Developers are one of our most expensive and constrained resources. If spending a few extra thousand dollars on a fast machine and proper screen space saves time, reduces cognitive load, or keeps someone in flow more often, it pays for itself very quickly."

That means our finance team doesn't ask "What's the cheapest laptop we can buy?" Instead, they ask, "What setup helps this person do their best work?" From a finance perspective, this is about a high-ROI spend, not indulgence.

Octopus is running the FinBoss playbook, which aligns finance and leadership in empowering employees to do their best work. That means expanding what you're willing to measure so that you can balance the visible costs with traditionally invisible returns.

The responsibility for providing this environment for employees rests with all leaders, including Sammy, and is part of the deal employees have with the company; we'll give you the best environment and tools if you give us the greatest work of your career.

The reckoning

If we've ever met, I've likely mentioned DORA's research. I'm a super-fan of their State of DevOps reports, because they provide us techniques, practices, and outcomes that are all linked through complex relationships. The model shows that transformational leadership, lean product management, and Continuous Delivery drive software delivery performance and organizational outcomes.

While many of the capabilities in the DORA model are technical, many others relate to leadership. Particularly relevant to developer experience are generative organizational culture, transformational leadership, empowering teams to choose tools, team experimentation, and a learning culture. You can read about these and more on the DORA website. Together, they back up the FinBoss concept with tens of thousands of survey samples that support the case.

The question is: Which organization are you now, and which do you want to be? Is it FinCost, operating myopically against the bottom line, or FinBoss, sharing the responsibility for developer experience and employee productivity? The fork in the road was never a choice. We know FinCost is a dead end, and the benefits of FinBoss aren't soft claims; they're measurable outcomes.

Automatically update GitHub Action versions

Steve Fenton — Mon, 01 Jun 2026 19:20:26 +0000

You don’t notice your GitHub Actions versions until you start getting warnings about things like “Node 20 is no longer supported”. When you think about it, GitHub Actions are yet another dependency that needs to be kept up to date and present supply chain risks.

Get Dependabot to do the work

The good news is, you can get Dependabot to keep your GitHub Actions up to date for you. You can add instructions for this to your .github/dependabot.yml:

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

In my case I already had configuration for my npm dependencies:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

But it’s trivial to add multiple updates to the same file:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Automatic pull requests

When you first commit this file, you’ll notice pull requests start appearing for your review.

- name: Setup pnpm cache
    uses: actions/cache@v4 (-)
    uses: actions/cache@v5 (+)

This is a simple example of how you can use Dependabot to keep your GitHub Actions up to date. You can find more information about Dependabot in the GitHub documentation.

Harness engineering: The power of AI, guided by human intelligence

Steve Fenton — Tue, 26 May 2026 06:25:39 +0000

Vibe coding offered us a tantalizing dream. Have a conversation with AI, forget the code exists, and ship software. This can be a useful way to solve localized and one-off problems. For production systems that need to live, breathe, and evolve for years, it's a different story.

A new idea called "harness engineering" points to what you need to create production-grade AI-generated code, and the metaphor hidden in the name tells you everything.

The horse and the harness

Horses are powerful animals, but left to their own devices, they direct their power toward whatever they want. A harness doesn't diminish the horse's strength; it channels it. The human holding the reins isn't doing the physical work; they're doing the intelligent work: choosing the destination, reading the terrain, knowing when to slow down.

Harness engineering works the same way. The AI agent is your horse. It's generative, fast, tireless, and capable of producing large software systems with a small team of engineers directing the work. The harness is the system of tools, constraints, and feedback loops that channels all that raw capability toward something coherent, maintainable, and trustworthy.

When teams attempt to deliver large systems with AI agents without a harness, they typically get run over and trampled by the horse. You'll know if you're missing the harness if you find yourself scheduling fixing sessions and tidy-up days as part of your process.

Why vibe coding doesn't scale

When Andrej Karpathy coined "vibe coding" in early 2025, he was describing something delightfully honest: a mode where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists."

When you vibe code, you accept all changes without reviewing them and pass any error messages back to the AI to fix. When you use this approach, you let the levels of success and failure push you down different routes. If it won't do what you want, you flex on your ideas to get something that works.

Karpathy said this works for "throwaway weekend projects," and a year later, he's moved on to calling the professional version "agentic engineering."

The distinction matters. Vibe coding is epistemically passive: you surrender understanding along with the keyboard. Harness engineering is epistemically demanding; it just redirects what you need to understand. Instead of understanding every function, you need to understand the system that constrains how functions get written.

OpenAI created harness engineering as part of an experiment. A team spent 5 months building an internal product with no manually written code. The logic, tests, build configuration, documentation, and observability tooling were all created by AI agents. They created over a million lines of code with 3 engineers and deployed the system to internal users and external alpha testers. They estimate this took 10% of the time it would have taken a team to write the system without AI agents.

The insight from this experiment was that environment legibility is the crucial factor in getting AI agents to deliver software that works. Without this legibility, agents fail as they can't find or reason about the information needed to complete the task.

The 3 practices that make harness engineering work

Based on OpenAI's write-up and Birgitta Böckeler's sharp analysis on the Thoughtworks blog, harness engineering clusters around three categories of practice.

Context engineering

When it comes to currently available AI agents, context is a precious resource. You don't have an unlimited context window, so you need to be smart with how you use it. Providing a giant agent markdown file filled with instructions only crowds out the real task. Large agent markdown files are also hard to understand and update.

Instead, limit the agent markdown file to a hundred lines and use it as a table of contents. You can link out to individual documents with maps, execution plans, and design specifications. They should be well-organized within the codebase so they are versioned and discoverable.

You can provide dynamic context from observability data, logs, metrics, traces, and information from browser dev tools. That will let the agent detect and fix bugs it introduces.

Architectural constraints

This is where harness engineering most clearly diverges from vibe coding's "anything goes" philosophy. The OpenAI team enforced a rigid architectural model whereby the business domain was divided into a sequence of fixed layers:

Types → Config → Repo → Service → Runtime → UI

Dependencies can flow only in the direction of the arrows, and cross-cutting concerns like auth, telemetry, and feature flags enter through a single explicit interface called "Providers". Nothing else is allowed. You should enforce your design with custom linters and structural tests, which you can implement using AI agents.

You can use the error messages in custom enforcement tools to provide remediation instructions so AI agents can fix violations themselves.

Entropy management as garbage collection

Agents are pattern replicators. If you give them a codebase full of inconsistencies, they'll faithfully reproduce them at scale. You can solve this by running background agents that scan for deviations and automatically fix them. You need to keep the code well factored and consistent to make it legible for future agent runs.

When an agent struggles with a task, you shouldn't fix it by hand. Identify what capability is missing, and then make it legible and enforceable for the agent. After making adjustments, you get the AI tools to write the fix. This improves the harness and makes it more valuable over time.

The human's job in harness engineering

With agents handling the coding, humans shift their focus to designing environments, specifying intent, and building feedback loops.

Environment design concerns the arrangement of code, documentation, and constraints. Intent is specified through precise prompts that connect high-level goals to coherent implementations. Feedback loops come from test automation, structural checks, and agent-led reviews, minimizing the need to step in and fix what agents are doing.

The code review burden is managed through mechanical checks built into the harness, with agents handling the initial review. A review is escalated only when human judgment is needed, for example, to approve a novel architectural design. This prevents the code review from becoming a bottleneck.

What this means for the future

In the Platform Engineering community, we have been discussing the role of platform engineers as organizational enablers of AI. Platform teams may create and maintain templates for harness engineering that provide a solid starting point for environment legibility and for providing appropriate constraints. They might even provide shared custom linters and structural testing tools.

Bringing harness engineering into an existing codebase may be more difficult than applying the technique to new systems. There will be fewer clear standards that will weaken the harness. The accumulated entropy of an established code base will pose similar problems to introducing test-driven development or a code linter for the first time.

If harness engineering gains traction, it will encourage the industry to converge on boring, well-established technology choices. Languages and tech stacks with more high-quality samples in training data and years of community Q&A coverage will naturally produce better results than niche tech stacks.

Harness engineering and Continuous Delivery

For teams already practicing Continuous Delivery, harness engineering is a natural fit. The techniques will fit into existing feedback loops and validation practices.

Harness engineering forces teams to adopt long-standing good practices like high-quality documentation, modular design, consistent naming, and capturing architectural decisions. Agents have no tacit knowledge; until it is made explicit, it doesn't exist.

You'll need to supplement harness engineering with a robust automated test suite that proves the system works as intended, since the harness constrains how code is written; it doesn't validate that user needs are satisfied.

Getting started

Building a harness is a continuous process, and it might not prove its value until you've completed months of iteration. You should look for existing foundations that will give you a head start, like pre-commit hooks, custom linters, structural testing frameworks, documentation, and test automation.

Each existing foundation can be woven into a harness, which you then iterate on as you identify gaps. By making fixes through the harness rather than directly in the code, you strengthen the harness and make agents more capable. At the same time, the human's work shifts to the interesting work of choosing the direction and reading the terrain.

Continuous Delivery Office Hours Ep.2: Remaining deployable at all times

Steve Fenton — Mon, 18 May 2026 11:10:22 +0000

When you can’t deploy on demand, you’ve lost control of your software. Risk accumulates in unreleased code, and the more changes you store in one place, the more chance they have of triggering overheads, rework, and failures. When you have blockers stopping you from going live, you’ll start to accumulate dangerously high levels of risk unless you prioritize deployability.

By choosing to do work that returns software to a deployable state ahead of any other kinds of work, like feature development, you’ll avoid the toxicity of tangled work batches. Instead, you can smoothly flow changes between test and production and get the feedback you need to be confident that your software works.

Crucially, if you discover a high-severity bug or security problem, there are no roadblocks to getting fixes into production. You don’t need a special “expedited lane” for these changes, which means you don’t skip steps that let bad changes into your codebase.

Let’s take a look at problem indicators that will help you identify and fix common deployability issues. The goal of answering the deployability question is a mile marker, not the destination, but if you can’t answer the question, you’re going to waste time looking for landmarks!

Watch the episode

You can watch the episode below, or read on to find some of the key discussion points.

CD Office Hours: Episode 2.

The awkward silence problem

When you ask your team, “Are we ready to deploy?”, the correct answer is either “absolutely” or “no way”. The worst possible answer is silence or confusion. If the team doesn’t know whether they can deploy, they’re missing the deployment pipeline that would generate the answer.

When you commit a code change, build errors should be returned to you within a couple of minutes. At the end of 5 minutes from your commit, a suite of fast-running tests should tell you if you’ve broken functionality or the quality attributes of your application. Dependency checks, code scanning, and other static analysis tools should have told you if you have a problem. If you have long-running tests or tests that depend on the new software version being deployed to a test environment, you should know in another 5-20 minutes if they’ve detected a problem.

After all these checks, you should have a version of your software running in a test environment that you have high confidence in. If someone asked you whether you’re ready to deploy, you’d answer “absolutely”.

Deployment automation makes sure the deployment is a non-event. It guarantees the same process is used to deploy to all environments, and makes it trivial to deploy on demand. A solid deployment pipeline contains all the checks you need to know whether you can deploy.

Manual testing is a ceiling, not a floor

Teams often treat manual testing as a foundation for verifying that a software version works. In reality, it acts more like a ceiling, limiting your ability to flow changes to production. As your software becomes more complex, the ceiling descends as the testing takes longer.

Long test cycles make you subvert your process to the speed at which you can test. You’ll notice when this happens because you’ll keep looping back to fix bugs and restart the test process. From the earliest change you make, through each bug list and all the re-testing, right through to the final software version, you are not deployable.

Automating your tests is the real foundation for your software. This raises the ceiling and moves the constraint away from the test cycle.

Your old code wasn’t written to be tested

If your application is successful, it will have some history. Part of that history is often that it wasn’t written with test automation in mind. That means you need to identify where your risk is, work out how to find the seams that will make it testable, and start adding characterizing tests.

Once some old code is wrapped with tests, it becomes far easier to change the code design, because the tests will fail if you break something.

Automation is living documentation

When developers move on, a portion of your institutional knowledge goes with them. High-quality documentation can help teams distribute this knowledge and reduce its loss, and the best kind of documentation is test automation.

Well-written automation, like tests, deployment automation, and infrastructure as code, performs useful functions while effortlessly documenting them. Because you make all changes through the living documentation, it is always up to date.

The hidden cost of undocumented knowledge becomes painfully clear when you have to deploy without the person who normally handles it. You follow their checklist carefully, confirm every step, and everything looks right; yet the deployment still fails. What you didn’t know is that the checklist stopped being accurate months ago, because the person doing the deployments stopped consulting it. All the new steps they introduced lived in their head, not on paper.

The living documentation built into automation tools is especially valuable when onboarding new developers. Rather than relying on tribal knowledge passed down through conversations and shadowing, a new team member can read the test suite and understand not just what the software does, but what it’s supposed to do and why certain behaviors matter. That’s documentation that keeps pace with the code because it is the code.

The value of long-term sustainability

Like its Agile predecessors, Continuous Delivery values long-term sustainability. That means you invest a little more effort up front to constrain maintenance costs over the long term. Writing tests may mean a feature takes 20-25% more time to implement, but the defect density can be 91% lower than similar features not guided by tests (Microsoft VS).

You could reduce 40 hours of bug fixing to just 3.6 hours by guiding feature development with tests, and you also save on other overheads caused by escaped bugs, like reputational damage, customer churn, support costs, pinpointing and debugging, test cycles, and feature delay.

Conclusion

While it takes some effort to set up a strong deployment pipeline, knowing whether a software version is deployable pays dividends. Technical practices like test-driven development and pair programming are needed to keep software economically viable in the long term, even though they require a little more effort up front.

If you can’t answer the question “Is your software deployable?”, you’re sure to run into trouble.

Happy deployments!

How AI Makes You 56% Faster and 19% Slower

Steve Fenton — Tue, 12 May 2026 11:32:13 +0000

The flow rate of change means we don’t have all the answers!

There’s a growing body of research around AI coding assistants with a confusing range of conflicting results. This is to be expected when the landscape is constantly shifting from coding suggestions to agent-based workflows to Ralph Wiggum loops and beyond.

The Reichenbach Falls in Switzerland has a drop of 250 meters and a flow rate of 180–300 cubic meters (enough to fill about 1,500 bathtubs) every minute. This is comparable to the rate of change in tools and techniques around coding assistants over the past year, so few of us are using it in the same way. You can’t establish best practices under these conditions; only practical point-in-time techniques.

As an industry, we, like Sherlock Holmes and James Moriarty, are battling on the precipice of this torrent, and the survival of high-quality software and sustainable delivery is at stake.

Given the rapid evolution of tools and techniques, I hesitate to cite studies from 2025, let alone 2023. Yet these are the most-cited studies on the effectiveness of coding assistants, and they present conflicting findings. One study reports developers completed tasks 56% faster, while another reports a 19% slowdown.

The studies provide a platform for thinking critically about AI in software development, enabling more constructive discussions, even as we fumble our collective way toward understanding how to use it meaningfully.

The GitHub Self-Assessment

The often-cited 56% speed up stems from a 2023 collaboration between Microsoft Research, GitHub, and MIT. The number emerged from a lab test in which developers were given a set of instructions and a test suite to see how quickly and successfully they could create an HTTP server in JavaScript.

In this test, the AI-assisted group completed the task in 71 minutes, compared to 161 minutes for the control group. That makes it 55.8% faster. Much of the difference came from the speed at which novice developers completed the task. Task success was comparable between the two groups.

There are weaknesses in this approach. The tool vendor was involved in defining the task against which the tool would be measured. If I were sitting an exam, it would be to my advantage to set the questions. Despite this, we can generously accept that it made the coding task faster, and that the automated tests sufficiently defined task success.

We might also be generous in stating that tools have improved over the past three years. Benchmarking reports like those from METR have found that AI has doubled the length of tasks it can handle every 7 months; other improvements are likely.

We’ve also observed the emergence of techniques that introduce work plans and task chunking, thereby improving the agent’s ability to perform larger tasks that would otherwise incur context decay.

And METR is also the source of our cautionary counter finding on task speed.

The METR sense check

The METR study in 2025 examined the impact of contemporary tools on task completion times in real-world open-source projects. The research is based on 246 tasks performed by 16 developers who had experience using AI tools. Each task was randomly assigned to an AI-assisted group and a control group. Screen recordings were captured to check and categorize the task completion.

The research found that tasks were slowed by 19%, which appears to contradict the earlier report. In reality, the active coding time was reduced by AI tools, as was the task of searching for answers, testing, and debugging. The difference in the METR report was that it identified tools that introduced new task categories, such as reviewing AI output, prompting, and waiting for responses. These new tasks, along with increased idle/overhead time, consumed the gains and pushed overall task completion times into the red.

Source: METR Measuring the Impact of Early-2025 AI. Task category comparison.

One finding from the METR study worth noting is the perception problem. Developers predicted AI assistants would speed them up. After completing the task, they also estimated they had saved time, even though they were 19% slower. This highlights that our perceptions of productivity are unreliable, as they were when we believed that multitasking made us more productive.

Lack of consensus

A recently released study from Multitudes, based on data collected over 10 months in 2025, highlights the lack of consensus around the productivity benefits of AI coding tools. They found that the number of code changes increased, but this was countered by an increase in out-of-hours commits.

This appears to be a classic case of increasing throughput at the expense of stability, with out-of-hours commits representing failure demand rather than feature development. It also confuses the picture as developers working more hours would also create more commits, even without an AI assistant.

Some of the blame was attributed to adoption patterns that gave little time for learning and increased delivery pressure on teams, now that they had tools to that were supposed to help them.

The wicked talent problem

One finding that repeatedly comes up in the research is that AI coding assistants benefit novice developers more than those with deep experience. This makes it likely that the use of these tools will exacerbate a wicked talent problem. Novice developers may never shed their reliance on tools, as they become accustomed to working at a higher level of abstraction.

This is excellent news for those selling AI coding tools, as an ever-expanding market of developers who can’t deliver without the tools will be a fruitful source of future income. When investors are ready to recoup, organizations will have little choice but to accept whatever pricing structure is required to make vendors profitable. Given the level of investment, this may be a difficult price to accept.

The problem may deepen as organizations have stopped hiring junior developers, believing that senior developers can delegate junior-level tasks to AI tools. This doesn’t align with the research, which shows junior developers speed up the most when using AI.

The AI Pulse Report compares this to the aftermath of the dot-com bubble, when junior hiring was frozen, resulting in a shortage of skilled developers. When hiring picked up again, increased competition for talent led to higher salaries.

Source: The AI Pulse Report. Hiring plans for junior developers.

Continuous means safe, quick, and sustainable

While many practitioners recognize the relevance of value stream management and the theory of constraints to AI adoption, a counter-movement is emerging that calls for the complete removal of downstream roadblocks.

“If you can’t complete code reviews at the speed at which they are created with AI, you should stop doing them. Every other quality of a system should be subverted to straight-line speed. Why waste time in discovery when it would starve the code-generating machine? Instead, we should build as much as we can as fast as we can.”

As a continuous delivery practitioner and a long-time follower of the DORA research program, this makes no sense to me. One of the most powerful findings in the DORA research is that a user-centric approach beats flat-line speed in terms of product performance. You can slow development down to a trickle if you’ve worked out your discovery process, because you don’t need many rounds of chaotic or random experiments when you have a deep understanding of the user and the problem they want solved.

We have high confidence that continuous delivery practices improve the success of AI adoption. You shouldn’t rush to dial up coding speed until you’ve put those practices in place, and you shouldn’t remove practices in the name of speed. That means working in small batches, integrating changes into the main branch every few hours, keeping your code deployable at all times, and automating builds, code analysis, tests, and deployments to smooth the flow of change.

Continuous delivery is about getting all types of changes to users safely, quickly, and sustainably. The calls to remove stages from the deployment pipeline to expedite delivery compromise the safety and sustainability of software delivery, permanently degrading the software’s value for a temporary gain.

It’s a system

There’s so much to unpack in the research, and many of the studies are zoomed in on a single link in a much longer chain. Flowing value from end to end safely, quickly, and sustainably should be the goal, rather than merely maintaining flat-line speed or optimizing individual tasks, especially when those tasks are the constraining factor.

With the knowledge we’ve built over the last seven decades, we should be moving into a new era of professionalism in software engineering. Instead, we’re being distracted by speed above all other factors. When my local coffee shop did this, complete with a clipboard-wielding Taylorist assessor tasked with bringing order-to-delivery times down to 30 seconds, the delivery of fast, bad coffee convinced me to find a new place to get coffee. Is this what we want from our software?

The results across multiple studies show that claims of a revolution are premature, unless it’s an overlord revolution that will depress the salaries of those pesky software engineers and develop a group of builders unable to deliver software unless it’s through these new tools. Instead, we should examine the landscape and learn from research and from one another as we work out how to use LLM-based tools effectively in our complex socio-technical environments.

We are at a crossroads: either professionalize our work or adopt a prompt-and-fix model that resembles the earliest attempts to build software. There are infinite futures ahead of us. I don’t dread the AI-assisted future as a developer, but as a software user. I can’t tolerate the quality and usability chasm that will result from removing continuous delivery practices in the name of speed.

Continuous Delivery Office Hours Ep.1: Continuous Delivery should be your top priority

Steve Fenton — Tue, 05 May 2026 09:07:21 +0000

Continuous Delivery promotes low-risk releases, faster time-to-market, higher quality, lower costs, better products, and happier teams. Software is at the core of everything a business does today, so organizations must be able to respond to customer needs more quickly than ever.

Taking a quarter or a month to deliver new functionality puts companies behind their competition and prevents them from serving their customers. Few practices offer as much return on investment as Continuous Delivery, but many organizations continue to resist it, often making their deployment problems worse in the process.

Understanding why Continuous Delivery matters and how to implement it effectively can transform not only your deployment process but also your entire software development approach.

Watch the episode

You can watch the episode below, or read on to find some of the key discussion points.

Watch Continuous Delivery Office Hours Ep.1

What is Continuous Delivery?

At its core, Continuous Delivery means you can deploy your software at any time. A good indication of whether a team practices Continuous Delivery is whether they prioritize work that keeps software deployable. Other development styles usually continue working on features and return to deployability issues later.

That means teams must have fast, automated feedback for every change, highlighting when the software has an issue that would prevent its deployment. Deployments to all environments must be automated, with artifacts and deployment processes pinned to avoid unexpected changes between deployments.

The big three: Time, risk, and money

The longer the intervals between deployments, the more you accumulate risk, and the more you delay the value the changes will realize. If you wait six months between deployments, you're more likely to get caught in a firefighting loop, spending more time pinpointing bug sources because of the volume of changes.

Crucially, until you place new features in users' hands, you accumulate market risk that the changes won't solve the underlying problem in a way users accept.

The deployment paradox

Human psychology works against us when deployments go wrong. Having waited six months to deploy, the pain of the firefighting stage and the increased risk of deploying large batches of changes mean people develop an aversion to deployments.

When a process is stressful and goes wrong, we naturally want to do it less often. You might think: "If we do fewer deployments, we'll have less pain." But this is precisely backwards.

Decreasing deployment frequency increases batch size, making the next deployment more likely to go wrong and cause pain. This is like avoiding the dentist after a painful checkup; the longer you leave it, the worse the next visit will be.

Risk-averse organizations have instincts that work against their goal of safety. The solution isn't to deploy less often; it's to deploy more frequently with smaller batches of changes.

Keeping software deployable during feature development

Another objection to Continuous Integration and Delivery is that features take time to build, so you can't deploy while a feature is in flight. With an infinity of overlapping feature development, this would result in never deploying (or, more likely, work taking place in long-lived branches).

The solution is to separate deployments from feature release. Trunk-based development (integrating changes into the main branch every day, often many times each day) and feature toggles make it possible to work from a shared code base without making in-flight features visible to users.

There are many benefits to feature toggles beyond supporting Continuous Delivery. They also let you share features early with specific user segments or roll them out progressively rather than all at once.

Changing what deployment success means

When you separate deployment from release, you also transform how you measure deployment success. You're no longer testing whether new functionality works during deployment. You're only verifying that the application is running and healthy. This focus makes deployments faster and less stressful.

Feature toggles reduce the stress and burden of deployments because you'll no longer miss deployment issues while checking functionality or miss functionality problems while monitoring deployments. Separating these concerns means each gets proper attention.

Solving dependency challenges

Feature toggles also address one of the most complex problems in microservices: deployment dependencies. Despite the promise of independently deployable services, teams often create elaborate deployment choreographies to ensure services are deployed in a specific order. Sometimes they give up entirely and deploy everything simultaneously. They accept unpredictable behavior during deployment or direct users to a holding page until it's complete.

When deployments form a chain of dependencies, the architecture isn't truly microservices but a distributed monolith. Real microservices should deploy independently. Feature toggles make this possible. Deploy all services when ready, then switch on functionality once dependencies are in place.

Conclusion

Continuous Delivery isn't just about deploying more often. It's about reducing risk through smaller changes, separating deployment from release, maintaining deployable code at all times, and giving teams the confidence to move quickly and safely.

The instinct to slow down after problems is natural, but it's counterproductive. The path to safer deployments runs through more frequent deployments, not fewer. Organizations that embrace this counterintuitive truth gain a competitive advantage through faster feedback, lower risk, and ultimately, better software.

Running Astro in a preview container

Steve Fenton — Mon, 27 Apr 2026 15:12:52 +0000

If you’ve ever worked on a collection of different Node apps, you’ve likely encountered version conflicts. Everyone wants a different version of Node or PNPM, and your new job is trying to align them all, or managing versions daily.

That’s when open-source hero Kostis Kapelonis said, “Why don’t we run the preview in a container?” In fact, he didn’t just say this; he also submitted a PR. I told you he’s an open-source hero.

The PR added a Dockerfile and a docker-compose.yaml file to the project, which let you spin up the preview site using:

docker compose up

Once Kostis had done all the hard work, I added a small enhancement to make Astro’s live preview work when you change files. That meant you could start the container and keep working while all your changes are instantly visible in the preview. That keeps the developer inner loop nice and tight.

If you want to do the same, here’s how to make it happen. Once again, I added a very small cherry to Kostis’ wonderfully fluffy cake, so send your adoration his way.

Add a Docker compose file

Here’s the docker-compose.yml file for your Astro project. It goes in the root directory.

services:
  astro:
    build: .
    ports:
 - "3000:3000"
    volumes:
 - .:/app
 - /app/node_modules
    environment:
 - NODE_ENV=development
 - HOST=0.0.0.0
    stdin_open: true
    tty: true

This maps the volumes, with a special case for node_modules. It exposes Astro’s port 3000 inside the container to port 3000 on your machine so you can open it in your browser.

The Docker file

Here’s the Dockerfile, which also goes in your project’s root directory.

# Use Node 20 as the base image
FROM node:20-slim

# Install pnpm globally
ENV PNPM_HOME="/pnpm"
ENV PATH="$PNPM_HOME:$PATH"
RUN corepack enable

# Set the working directory
WORKDIR /app

# Copy package files
COPY package.json pnpm-lock.yaml* ./

# Install dependencies
RUN pnpm install

# Copy the rest of the source code
COPY . .

# Expose the default Astro port
EXPOSE 3000

# Start the dev server
CMD ["pnpm", "compose:dev"]

There’s an optimization here around the package files, which is why they get their own copy command. There’s an extra command in the package.json file that we call here, too. It’s a variation of the dev script we use, but switches out the Astro run with a slight variation (the addition of the --host flag) lets just show the important bits in this code snippet:

"scripts": {     
    "compose:dev": "npm-run-all --parallel dev:img dev:dictionary compose:dev:astro dev:watch",
    "compose:dev:astro": "astro dev --host",

The Vite config change

The final change is the one that makes the live refresh to work. This goes in your astro.config.mjs file, and I popped it right after the existing server config.

server: {
    port: 3000
}
vite: {
    server: {
        watch: {
            usePolling: true,
        },
    },
},

Spinning it up

The first time I ran this, I started things up with:

docker compose up --build

You can then stop the container with

docker compose down

If you haven’t changed the container, you can start it with the faster:

docker compose up

Developer Productivity in the Age of AI: Why Your Past Predicts Your Future

Steve Fenton — Mon, 20 Apr 2026 11:57:29 +0000

You're looking at a list of things you'd love to do, and you're looking at AI coding tools as a way to boost your way down that list. You might not have the relationships mapped out, but you can see there is some route to value if you spend on LLMs that speed up code.

You're now in the developer productivity game.

The idea behind developer productivity

The roots of developer productivity are straightforward. Some smart engineering managers figured out that a small team of developers with the best machines, screens, and development tools could generate value at a rate and quality that far exceeded their "head count". You could also supply all these upgrades to developers at a cost way below the fully loaded cost of 1 more developer.

The return on investment for this approach was incredible, but traditional engineering managers didn't understand it. They thought developers were asking for more screens because it made them look more important. This emerged from organizations that rewarded managers for empire-building by granting them larger offices with better views.

I'm a big fan of Ron Westrum's Typology of Organizational Cultures. For this post, though, we'll keep things simple and refer to traditional thinking (keep equipment costs low) and modern thinking (provide high-quality tools).

We have never shaken off this traditional-versus-modern divide over developer productivity. And now, the subject has returned to the spotlight due to AI and, more specifically, LLM-based coding tools. Your organization's past approach to developer productivity will determine whether you can successfully integrate AI tools into your development teams.

Let's look at why.

A tale of two cities

Traditional organizations operate through control. Managers dictate how work is done, choosing the processes and tools workers must use. Instructions flow downward, and managers define efficiency. Workers are evaluated individually against the manager's prescribed methods, rather than by outcomes.

Modern organizations operate through trust. Teams choose how to work, selecting from available options or proposing new tools when needs emerge. Authority flows to those closest to the work. Performance is a team sport measured by outcomes.

Traditional	Modern
Operates through control	Operates through trust
Efficiency is manager directed	Productivity is worker-led
Finds the cheapest tools	Chooses the best tools for each job
Prefers expanding teams	Prefers small teams
Tooling is a cost	Tooling increases value
Performance is individual	Value flows from collaboration

As we experiment with AI coding tools, we are gaining crucial insights. We are developing a better understanding of how much human oversight is needed to successfully and sustainably deliver high-quality software to users. A strong guiding hand is crucial in directing and correcting the output of these tools.

The value of any software you build, by hand or with assistance, comes from the flow of information. That means listening to software users and collaborating internally. While the code is what gets left behind by the process, it's only an artifact of a more fundamental learning process. The ability to learn and share knowledge will also benefit teams as they discover how to apply AI coding tools to this process.

It's also clear that Continuous Delivery and automation remain paramount. In the past, automated linting, security scanning, and tests gave us confidence in the code teams wrote; now, they can provide us with confidence in code generated by LLMs. DORA's AI Capabilities Model includes 7 capabilities essential to successful AI adoption, including user-centric focus, strong version control practices, and working in small batches.

For organizations that haven't adopted Continuous Delivery, rocky shores lie ahead when they unleash AI tools on their codebases.

Return on an unspecified investment

Now here's the fascinating conundrum for anyone trying to calculate a return on investment for AI coding tools. The commercial tools indeed remove many tasks that, as a developer, I don't want to do, though they also introduce new ones. I see why people would like to use them to remove much of the noise and focus on the essential details in the software. The problem is, you run out of credits fast, so if you want to use these tools full-time, you'll need subscription levels that support that.

Credit exhaustion is the first friction point where traditional organizations will come unstuck. Developers who rely heavily on AI coding tools will slow drastically when credits run out. This will likely become a significant problem over time as developers become more dependent on working at the high level of abstraction that prompting offers.

Imagine if coding languages had similar limits. You'd run out of Python hours and have to continue your work using assembly language.

Organizations with a cost focus will challenge developers who want a higher budget for these tools. Any manager who has previously denied more screen real estate is likely to reject higher subscription costs for AI coding tools. Their view in both cases is that the promised productivity isn't real.

The second hurdle for these commercial tools is the uncertain future pricing. We know some AI companies are burning through investment cash, which means the price we pay is subsidized by their desire for growth. There must be a pivot point at which they begin the search for profitability. This will once again trigger problems in cost-focused organizations.

Some developers are already thinking ahead and looking for open-source models they can run locally to reduce cost uncertainty, but, as always, you pay one way or another. The time spent assessing, updating, and managing these models is a direct loss of the productivity you're trying to gain.

One solution may be for commercial vendors to offer fixed-price, unlimited use through local models. The challenger to this solution will come from Platform Engineering or DevEx teams, who could supply a packaged open-source local solution for developers to reduce the overhead of selection and maintenance.

The nature of problems changes

Traditional and modern organizations face the same challenges, but you can see that culture fundamentally shapes how they are addressed.

Modern organizations will judge their return on investment by the value they deliver. Their past investments in Continuous Delivery will provide a solid foundation for them to experiment with new tools, and they'll creatively address the cost issues associated with AI coding tools.

Traditional organizations will seek to minimize costs, avoid investing in automated pipelines, and demand higher developer output with no real basis for expecting it.

The set of capabilities a modern organization applies to high-throughput, high-quality software delivery is surrounded by subtle, interconnected relationships. For the traditional organizations that just want to "buy AI", the benefits are unlikely to arrive.

Happy deployments!

Setting GitHub as a trusted publisher for npm

Steve Fenton — Mon, 13 Apr 2026 13:36:59 +0000

So, stuff happened and npm has been updated to reduce the volume of stuff happening. In a world of SBOMs, SLSA, and supply chain attacks, it's time to get serious about publishing packages. In this case, that means using the new Trusted Publisher feature to connect GitHub (or GitLab) to npm.

Set the trusted publisher on npm

Sign into npm
Select the package you want to set up, for example astro-accelerator-utils
Click Settings
In the Trusted Publishers section, select your provider, in my case it's GitHub
Enter you repository information:
- Organization or user name, for example Steve-Fenton
- Repository name, for example astro-accelerator-utils
- The result should be that Steve-Fenton/astro-accelerator-utils matches your repo in GitHub
Provide the workflow file name
- This should match the workflow that will publish the package, in my case build-astro.yml
- The file must be in .github/workflows/
Click Set up connection

If you use environments, you can optionally limit publishing by environment.

Check you GitHub Action

In your permissions section, you need to allow id-token to be written.

permissions:
    id-token: write

You can then use the npm publish step in your workflow.

I conditionally publish based on the version number, so I only publish when the version number changes.

- name: Publish if version has been updated
    env:
        NPM_AUTH_TOKEN: ${{ secrets.NPM_AUTH_TOKEN }}
    run: |
        PACKAGE_NAME=$(node -p "require('./package.json').name")
        LOCAL_VERSION=$(node -p "require('./package.json').version")
        REMOTE_VERSION=$(npm view $PACKAGE_NAME version || echo "0.0.0")

        if [ "$LOCAL_VERSION" != "$REMOTE_VERSION" ] && [ "$(printf '%s\n%s' "$REMOTE_VERSION" "$LOCAL_VERSION" | sort -V | tail -n1)" = "$LOCAL_VERSION" ]; then
        echo "Local version $LOCAL_VERSION is higher than remote version $REMOTE_VERSION. Publishing..."
        echo "//registry.npmjs.org/:_authToken=$NPM_AUTH_TOKEN" > ~/.npmrc
        npm publish --access public
        else
        echo "Version $LOCAL_VERSION is not newer than $REMOTE_VERSION. Skipping publish."
        fi

This is a more secure way to publish npm packages, but it's also easier because you don't need to keep updating tokens and secrets.

Roll up your chair: How one small change sparked a DevOps revolution

Steve Fenton — Tue, 31 Mar 2026 09:22:47 +0000

My first encounter with DevOps was so simple that I didn’t even realize its power. Let me share the story so you can see how it went from accidental discovery to deliberate practice, and why it was such a dramatic pivot.

The backdrop to this pivotal moment was a software delivery setup you might find anywhere. The development team built software in a reasonably iterative and incremental fashion. About once a month, the developers created a gold copy and passed it to the ops team.

The ops team installed the software on our office instance (we drank our own champagne). After two weeks of smooth running, they promoted the version to customer instances.

It wasn’t a perfect process, but it benefited from muscle memory, so there wasn’t an urgent imperative to change it. The realization that a change was needed came from the first DevOps moment.

The unplanned first moment

When the ops team deployed the new version, they would review the logs to see if anything interesting or unexpected popped up as a result of the deployment. If they found something, they couldn’t get a quick answer, and it sometimes meant they opted to roll back rather than wait.

This was a comic-strip situation because the development team was a few meters away in their team room. It’s incredible how something as simple as a door transforms co-located teams into remote workers.

The ops team raised their request through official channels, and the developers didn’t even know they were causing more work and stress because the ticket hadn’t reached them yet.

Thankfully, one of the ops team members highlighted this. The next time they started a deployment, a developer was paired with them to watch the logs. A low-fi solution and not one you’d think much about. That developer was me. For this post, we’ll call my ops team partner “Tony”.

Shared surprises lead to learning

The day-one experience of this new collaborative process didn’t seem groundbreaking. When a log message popped up that surprised Tony, it surprised me too. The messages weren’t any more helpful to a developer than they were to the ops team.

I could think through what might be happening, talk it through, and then Tony and I would come up with a theory. We’d test the theory by trying to make another similar log message appear. Then we’d scratch our heads and try to decide whether this could wait for a fix or warranted a rollback.

The plan to bring people from the two teams together was intended to remove the massive communication lag, and it did. But further improvements were to come as a side effect, yielding more significant gains.

Resolve pain pathways by completing the loop

As a developer, when you generate log messages and then have to interpret them, you’ve completed a pain loop. Pain loops are potent drivers of improvement.

Most organizations have unresolved pain pathways. That means someone creates pain, like a developer throwing thousands of vague exceptions every minute, and then someone else feels it, like Tony when he’s trying to work out what the log means.

There are two ways to resolve the pain pathway.

Process: You create procedures to bring pain below the threshold and to limit the rate at which it is generated.
Loops: You connect the pain into a loop, so the person causing the pain feels its signal.

If I’m the one who gets the electric shock when I press the button, I stop pushing it, even if someone in a white coat instructs me to continue the experiment.

With the pain loop connected, I realized we should log fewer messages to reduce the scroll and review burden. Instead of needing institutional knowledge of which messages were perpetually present and could therefore be ignored, we could stop logging them.

The (perhaps asymptotic) goal was to log only the events that required human review, with a toggle that let more verbose logging be generated on demand. Instead of scrolling through a near-infinite list of logs, you’d have a nearly empty view. If a log appeared, it was important enough to warrant your attention.

The next idea was to improve the information in the log messages. We could identify which customer or user experienced the error and provide context for it. By improving these error messages, we could often identify the bug before we even opened the code, dramatically reducing our investigation time.

This process evolved into the three Fs of event logging.

Create positive spirals with delightful deployments

Another thread that emerged from the simple act of sitting together during deployments was the realization that the deployment process was nasty. We created an installer file, and the ops team would move it to the target server, double-click it, then follow the prompts to configure the instance.

Having to paste configuration values into the installer was slow and error-prone. We spent a disproportionate amount of time improving this process.

Admittedly, we were solving this one “inside the box” by improving an individual installation with DIY scripts, a can of lubricating spray, and sticky tape. This didn’t improve the experience of repeating the install across several environments and multiple production instances.
However, I did get to experience the stress of deployments when their probability of success was anything less than “very high”. When deployments weren’t a solved problem, they could damage team reputation, erode trust, and reduce autonomy.

Failed deployments are the leading cause of organizations working in larger batches. Large batches are a leading cause of failed deployments. This is politely called a negative spiral, and you have to reverse it urgently if you want to survive.

At last, a panacea

The act of sitting a developer with an ops team member during deployments isn’t going to solve all your problems. As we scaled from 6 to 30 developers, pursued innovative new directions for our product, and repositioned our offering and pricing, new pain kept emerging. Continuous improvement really is a game of whack-a-mole, and there’s no final state.

Despite this, the simple act of sitting together, otherwise known as collaboration, caused a chain reaction of beneficial changes.

Sharing goals and pain

When you’re sitting with someone working on the same problem, all the departmental otherness evaporates. You’re just two humans trying to make things work.

Instead of holding developers accountable for feature throughput and the ops team for stability, we shared a combined goal of high throughput and high stability in software delivery.

That removed the goal conflict and encouraged us to share and solve common problems together. This also works when you repeat the alignment exercise with other areas, like compliance and finance.

Completing the pain loop

The problem with our logging strategy was immediately apparent when one of the people generating the logs had to wade through them. This is a powerful motivator for change.

Identifying unresolved pain paths and closing the pain loop isn’t a form of punishment; it’s a moment of realization. It’s the reason we should all use the software we build: it highlights the unresolved pain paths we’re burdening our users with.

Pain loops are crucial to meaningful improvements in software delivery.

Reducing the toil

Great developers are experts at automating things. When you expose this skill set to repetitive work, a developer’s instinct is to eliminate the toil.

For the ops team, the step-by-step deployment checklist was just part of doing business. They were so familiar with the process that it became invisible.

When we reduced the toil, the ops team was definitely happier, even though we hadn’t solved all the rough edges yet.

Refining the early ideas

The fully-formed ideas didn’t arrive immediately. The rough shapes were polished over time into a set of repeatable and connected DevOps habits.

The three Fs, incident causation principles, alerting strategy, and monitor selection guidelines graduated into deliberate approaches long after this story.

I developed an approach to software delivery improvement that used these ideas to address trust issues between developers and the business. By reducing negative signals caused by failed deployments and escaped bugs, we increased trust in the development team, enhanced their reputation, and increased their autonomy.

We combined these practices with Octopus Deploy for deployment and runbook automation and an observability platform, which meant the team was the first to spot problems rather than users. When there was a problem, it was trivial to fix, and the new version could be rolled out in no time.

Unlike the original organization, where we increased collaboration between teams, we created fully cross-functional teams that worked together all the time. Every skill required to deliver and operate the software was embedded, minimizing dependencies and the risk of silos, tickets, and bureaucracy.

These cross-functional teams also proved to be the best way to level up team members.

Unicorn portals

You can’t work with a database whizz for long before you start thinking about query performance, maintenance plans, and normalization. You build better software when you develop these skills. You can’t work with an infrastructure expert without learning about failovers, networking, and zero-downtime deployments. You build better software when you develop these skills, too.

When people say they can’t hire these highly skilled developers, they miss the crucial point. A team designed in this cross-functional style takes new team members and upgrades them into these impossible-to-find unicorns. You may start as a backend developer, a database administrator, or a test analyst, but you grow into a generalizing specialist with many new skills.

Creating these unicorn portals is the most valuable skill development managers can bring to an organization. You need to hire to fill gaps and foster an environment where skills transfer fluidly throughout the team.

Roll up your chair

What became a sophisticated and repeatable process for team transformation could be traced back to that simple act of sitting together. It was a small, easy change that led to increased empathy and understanding, and then a whole set of improvements.

Staring at that rapid stream of logs was the pivot point that led to the most healthy and human approach to DevOps.

We didn’t have the research to confirm it back then, but deployment automation, shared goals, observability, small batches, and Continuous Delivery are all linked to better outcomes for the people, teams, and organization. Everybody wins when you do DevOps right.