DEV Community

Cover image for Stop Force-Feeding AI to Your Developers
Steve Fenton
Steve Fenton

Posted on • Originally published at thenewstack.io

Stop Force-Feeding AI to Your Developers

Before You Buy Another AI Tool, Fix These 5 Things

It’s great that you want your developers to be productive. They want this, too. What I struggle to understand in many managers is the stark contrast between their directive adoption of brute-force AI and their indifference to straightforward techniques that have been proven to be more impactful than coding assistants.

This isn’t a new problem; it’s common for a top-down productivity drive from management to be a smokescreen that hides a deeper problem in their organization. Often, the underlying issue is managers who have lost touch with their teams’ work.

The Great AI Gavage

There’s a rather unsavory practice called “gavage”, which is the process of force-feeding a duck or goose through a tube to increase the size of its liver by up to ten times. The mentality of “force more in, get more out” is how many managers approach AI adoption.

Unsurprisingly, there are animal welfare concerns with this approach, and some countries have banned force-feeding and the production, import, and sale of foie gras. If you’re a developer, there is no law to prevent the force-feeding of AI into your workflow. You depend on having great leaders who want real outcomes.

Like all technology, AI needs an adoption strategy that starts small, tracks its impact, and encourages experimentation at the ground level. You can achieve successful outcomes by engaging developers and allowing them to explore tools, determining where they are most helpful and how to integrate them into daily workflows.

Developer vs Manager-Led Productivity

You don’t find many developers who don’t want to be productive. Over the past three decades, most of the complaints I’ve heard from developers are about obstacles that hinder their progress. Their desire to deliver high-quality software drives their efforts to acquire better computers, additional screens, and secure a budget for a cloud test runner.

These have a comparable annual cost to the license for an LLM-based tool. Getting a machine with double the RAM, an extra monitor that you’ll use for several years, or a faster build server are all small costs compared to a developer’s salary. Increased developer productivity pays back at a higher-than-salary rate if you create valuable software.

If you make developers beg for better kit or tools while forcing them to use the AI tools you selected, I question whether you are motivated by productivity. Some other organizational pathology is in play here, and this path leads away from success.

Most developers want to experiment with LLM-based tools. They want to compare different options and see how they fit into the overall picture. You need them to take this experimental approach, as this technology is still in its infancy. Working out where it makes a meaningful difference will take time and knowledge sharing.

If you genuinely want productive developers, start with the productivity blockers they are already raising to you.

Five Productivity Ideas To Try Before AI

There have been several studies on the productivity benefits of AI. An expectation was set for some multiplicative factor benefit, like 2x or 10x productivity improvements. While you may achieve these numbers on an example task, they don’t accrue to the organization unless you look at the whole value stream.

The real-world productivity benefit of LLM-based tools is typically between 5% and +20%.

Assuming you’ve given your developers the basic tools of the trade (fast computers, plenty of screen real estate, the best development tools), here are five developer productivity boosts that all beat AI in terms of impact, based on research by DX.

1. Reduce Meeting-Heavy Days

Some people are more productive in the morning, while others hit their peak productivity late in the afternoon. Everyone is different, but they all have something in common: Nobody is productive when their day is stacked full of meetings.

Developers lose productivity when their calendars become fragmented. A day with four one-hour meetings scattered throughout isn’t just four hours of lost coding time; it’s often a complete write-off for deep work.

2. Encourage Flow

When a developer gets their productivity flywheel spinning, it’s worth protecting. Each random interruption brings the flywheel crunching to a halt, and it takes time to bring it back up to speed. That doesn’t mean developers shouldn’t talk to each other, as having healthy information flow is crucial. It does mean creating a space where they can get up to speed and stay there for extended periods.

Flow state, that magical condition where developers lose track of time and produce their best work, is fragile and valuable. For developers working on intricate logic or system design, interruptions don’t just pause progress; they can completely derail their mental model of the problem they’re solving. If you’re in an office, get them a space away from noisy phone calls and foot traffic where every person walking past diverts attention away from the work.

3. Improve CI/CD Pipelines

When a developer commits a change, streamlining feedback loops is crucial. If the build takes 20 minutes, developers must choose whether to be idle or context switch to another task. If the build fails, fixing it will be delayed because the developer is currently focused on another task. Switching between tasks means losing context around changes, which makes fixes take longer.

This pattern continues throughout the CI/CD pipeline, with each delay amplifying the problems caused by late feedback, context switching, and increasingly large batches of change. Slow pipelines increase the cost to fix issues and discourage good development practices like refactoring, as it takes too long to flow changes to production.

4. Organize Information

Developer productivity plummets when they can’t find the information they need to do their work. This includes everything from API documentation to deployment procedures, architectural decisions, and debugging runbooks. When information is scattered, outdated, or buried in someone’s email, developers waste hours hunting for answers they need to make progress.

High-quality documentation isn’t necessarily comprehensive. It’s more important that it’s up to date and easy to find. Organizations that value extensive documentation make it harder to find what you need and impossible to keep current. When managers fail to recognize documentation as real work, developers tend to optimize for tasks that are rewarded, which slows down the entire team.

5. Simplify Developer Inner Loops

The developer’s inner loop is the cycle of making, testing, and iterating changes. This is the heartbeat of productivity. When this loop is slow, cumbersome, or unreliable, it creates friction that compounds throughout the day. A developer who can make a change and see results in seconds will iterate more, experiment more, and ultimately build better software than one who waits minutes for each feedback cycle.

The inner loop encompasses the entire development process, from setting up a development environment to making code changes, running tests, reviewing results, and debugging issues. Modern development might involve spinning up containers, connecting to databases, running build processes, and coordinating multiple services. Each point of friction in this loop multiplies across hundreds of daily iterations.

The Productivity Whole

Managers force-feeding AI to developers think they have a productivity hole, but they need to stop and consider the productivity whole. Developers are surrounded by an environment that either supports or damages the team’s goals and outcomes. The productivity benefits of AI amount to 4% of a developer’s annual output, while eliminating meeting-heavy days yields a 29% improvement, and reducing deployment lead times brings an additional 16%.

Once you’ve done these stage-one productivity improvements, it’s time to empower teams to choose their AI tools and experiment with how they integrate with their workflows. Help them secure multiple options and funding while they determine what works best for their workloads. Measure AI adoption by existing success measures, rather than inventing new ones or trying to capture the ever-intangible “productivity”.

The Golden Gooseherd

Your development team is your golden goose. They produce valuable software that drives your business. You don’t use gavage on a golden goose because you want those valuable eggs, not inflamed organs. Force-feed it and you’ll lose the golden eggs entirely.

Managers practicing AI gavage focus on the immediate gratification of “AI adoption metrics” going up. They aim to boost developer productivity to the level of foie gras, simply because it sounds impressive in boardroom presentations. However, forced AI adoption creates artificially inflated metrics that mask underlying organizational dysfunction.

The wise manager tends their golden goose instead. They remove obstacles, provide the right environment and tools, and give teams autonomy to thrive naturally. In that healthy environment, developers naturally experiment with AI tools that genuinely help them, rather than rejecting forced mandates.

The golden eggs of reliable, high-quality, high-performance software delivery come from healthy geese, not force-fed ones.

Top comments (0)