JetBrains' 2024 Developer Ecosystem survey found that 35% of developers use 6-10 development tools daily. Stack Overflow's 2025 survey puts the average at 7.3 distinct tools per developer per day. That is before counting the AI tools layered on top: Copilot for code generation, ChatGPT for research, Cursor for editing, Claude for code review, plus the AI features embedded in existing tools (VS Code's IntelliSense, GitHub's PR summaries, Jira's AI-generated stories).
Each tool has its own context, its own interface, its own authentication, its own notification stream, and its own cognitive load. The debugging tax is the cumulative cost of context-switching between these tools when something goes wrong.
I manage 35-50 engineers. We have opinions about tool selection. The short version: fewer tools, better integrated, is always cheaper than more tools, loosely connected.
The Numbers
JetBrains (2024, n=26,000):
- 35% of developers use 6-10 tools daily
- 12% use 11+ tools daily
- Average time spent switching between tools: 9-14% of working time
Harness (2025 Developer Experience Report):
- 62% of developers say context-switching between tools is their biggest productivity drain
- The average developer switches context 13 times per hour
- Each context switch takes 15-25 minutes to fully recover from (based on Microsoft Research and UC Irvine studies on attention recovery)
The math: 13 context switches per hour × 20 minutes average recovery = more time recovering than working. Obviously developers do not fully recover between every switch. They operate in a perpetual state of partial attention. The cost is not measured in minutes lost. It is measured in bugs introduced because the developer was thinking about the Slack notification while reviewing the PR while the CI pipeline was failing in the background.
Why Tool Sprawl Happens
Every problem gets its own tool
Somebody in the team encounters a problem. They find a tool that solves it. They introduce the tool. Nobody evaluates whether an existing tool already handles the problem, whether the new tool integrates with the existing stack, or whether the cognitive load of another tool exceeds the benefit.
Over 3 years, this pattern produces: GitHub for source control, Jira for project management, Confluence for documentation, Slack for messaging, Notion for notes (because Confluence is too slow), Linear for issue tracking (because Jira is too complex), Figma for design, Storybook for component documentation, Datadog for monitoring, Sentry for error tracking, PagerDuty for alerts, Postman for API testing, and whatever AI tools each developer personally prefers.
That is 13 tools. Each has its own browser tab, its own login session, its own notification settings, and its own mental model. Each requires the developer to remember where to look for what information.
AI tools amplified the problem
In 2023, the average developer used 5-7 tools. By 2025, that number is 7-10. The increase is almost entirely AI tools. Copilot in the editor. ChatGPT in the browser. Claude for complex reasoning. Cursor as an alternative editor. AI code review tools in the PR workflow. AI-generated documentation tools.
Each AI tool promises productivity gains. None of them account for the cognitive cost of one more context to manage. A developer using Copilot for generation, ChatGPT for research, and an AI code review tool is maintaining three separate AI contexts in addition to their 7 non-AI tools. That is 10 contexts. Each one interrupts the others.
The Debugging Tax
When something goes wrong in production — an error spike, a performance degradation, a customer-reported bug — the debugging process requires synthesizing information from multiple tools simultaneously:
- Sentry/Datadog: What is the error? Which endpoint? Which users?
- GitHub: What changed recently? Which PRs merged in the last 24 hours?
- CI/CD: Did the latest deploy pass all tests? Were there any warnings?
- Slack: Did anyone mention a related issue? Is this a known problem?
- Application logs: What does the server log show for the failing requests?
- Database: Is there a query performance issue? Did a migration run?
Six tools minimum to diagnose a production issue. Each requires opening, authenticating, querying, and interpreting. The information from each must be correlated mentally because the tools do not talk to each other.
The developer who has all six open in browser tabs, switching between them every 30 seconds, is not debugging efficiently. They are playing a memory game: "I saw the error timestamp in Sentry, now let me find the matching log entry in Datadog, now let me find the matching PR in GitHub, now let me check if the deploy happened after or before the error started." Each switch loses context. Each lost context risks missing the correlation that solves the problem.
This is the debugging tax. It is not the time spent in each tool. It is the time spent switching between tools and the bugs that persist because the developer lost context during a switch and missed the connection.
What We Do About It
Minimize the stack
At EltexSoft, we standardize on a minimal tool stack per project and resist adding tools without evaluating the cognitive cost.
Source control: GitHub. Always. Not GitLab, not Bitbucket, not both. One place for code, PRs, and CI/CD actions.
Project management: one tool, chosen by the client. Jira, Linear, or GitHub Projects. Never two project management tools in parallel.
Communication: Slack (or the client's chat tool). No parallel communication channels. If the conversation happens in Slack, the decision is recorded in Slack. Not in a Confluence page that nobody reads.
Monitoring: one observability platform. Datadog or Sentry, not both (unless the project scale justifies it). Logs, errors, and metrics in one place.
AI tools: individual developer choice, but the output goes through standard code review. No AI tool is mandated. No AI tool is banned. The code is what matters, not how it was generated.
Integrate before adding
Before introducing a new tool, we ask: can an existing tool handle this? GitHub Actions replaces a standalone CI tool. GitHub Projects replaces a standalone task tracker for small projects. Sentry replaces a standalone logging tool for most applications.
The best tool is the one you already have that does the job adequately. The second-best tool is the one that integrates with what you already use. The worst tool is the one that does its job brilliantly in isolation and requires manual context-switching for everything else.
Reduce the debugging surface
When production incidents happen, the debugging process should require as few context switches as possible. That means: deploy metadata in the monitoring tool (which commit, which PR, which engineer deployed), error context in the error tracker (full stack trace, request parameters, user context), and a single channel in Slack for incident communication (not scattered across 5 channels).
Our CI/CD setup on every project includes deploy annotations in the monitoring dashboard. When an error spike correlates with a deployment, the correlation is visible in one screen. The developer does not need to open GitHub, find the commit, find the deploy time, and manually correlate with the error timeline. The data is already joined.
The Productivity Gain Nobody Measures
When we join a client engagement and reduce the tool stack from 12 tools to 7, the productivity improvement is real but rarely measured. Nobody says "we saved 14% of developer time by eliminating tool sprawl." They say "the team seems faster" or "debugging is smoother." The improvement is diffuse: fewer context switches per hour, faster incident resolution, less time spent searching for information across multiple systems.
The savings are significant. JetBrains data says 9-14% of working time is lost to tool switching. For a 5-person team at $50-$100/hour, that is $36,000-$112,000/year in lost productivity. Reducing tool sprawl by 40% (from 10 tools to 6) does not eliminate all context-switching, but it reduces the cost by $14,000-$45,000/year. More importantly, it reduces the bugs that escape detection during debugging because the developer was juggling too many screens.
Fewer tools. Better integration. Less switching. Faster debugging. That is the practice. It does not require a FinOps platform or a developer productivity tool (which would, ironically, be one more tool).
Last updated August 4, 2024
Older
73% of CTOs Report Decision Anxiety. The AI Era Made It Worse. Newer
40% of Engineering Leaders Now Manage More People Than Last Year
