{"id":4695,"date":"2025-07-28T20:23:09","date_gmt":"2025-07-28T20:23:09","guid":{"rendered":"https:\/\/www.aviator.co\/blog\/?p=4695"},"modified":"2025-11-06T14:58:36","modified_gmt":"2025-11-06T14:58:36","slug":"throwing-ai-at-developers-wont-fix-their-problems","status":"publish","type":"post","link":"https:\/\/www.aviator.co\/blog\/throwing-ai-at-developers-wont-fix-their-problems\/","title":{"rendered":"Throwing AI at Developers Won\u2019t Fix Their Problems"},"content":{"rendered":"
\"ai-software-developers\"<\/figure>\n\n\n

If you ask engineers how much time they think they’re saving with AI, they’ll often give optimistic answers. But when you compare that sentiment with real quantitative data, the numbers don\u2019t add up. <\/p>\n\n\n\n

People tend to think about personal time savings in isolation: \u201cI finished my PR faster.\u201d That pull request (PR) might sit unreviewed for three days before being tested, fail in testing, and bounce back for fixes. The result is inefficiencies across the engineering organization that eat up any productivity gained.

Most engineering organizations do not need faster typers. The common engineering bottlenecks are flaky pipelines, no testing strategy, poor documentation, or organizational structures \u2014 the usual roadblocks to getting to business value. Your team might get marginally faster at writing code, but unless you address those systemic issues<\/a>, you\u2019re never going to realize the full value of AI tools.<\/p>\n\n\n\n

\u201cIf We\u2019re Not Using AI, We\u2019ll Be Left Behind.\u201d <\/h2>\n\n\n\n

Developer experience was already a tough topic before AI. When we talk about developer experience (DevEx) in the age of AI<\/a>, let\u2019s start by acknowledging that even the definition of \u201cdeveloper\u201d is changing<\/a>. It\u2019s no longer someone getting requirements from the product team and quietly coding away. Instead, they might generate partially working proofs of concept from AI tools or collaborate more fluidly with non-engineers who use AI to prototype ideas.

There\u2019s also the explosion of AI tools. Every day it feels like there\u2019s something new on the market. On one hand, that\u2019s exciting for engineers: shiny new tools, new ways of working. Then there\u2019s pressure from leadership, what I\u2019d call a bit of FOMO. You see executives thinking: \u201cIf we\u2019re not using AI, we\u2019re going to be left behind.\u201d
<\/p>\n\n\n\n

Don\u2019t Just Pick a Tool, Pick a Problem<\/h2>\n\n\n\n

Organizations are spending too much time, money, and energy focusing on the tools<\/em> themselves. \u201cShould we use OpenAI or Anthropic? Copilot or Cursor?\u201dWe see two broad patterns for how organizations approach AI tool adoption.<\/p>\n\n\n\n

The first is that leadership has a relationship with a certain vendor or just a personal preference, so they pick a tool and mandate it. This can work, but you\u2019ll often get poor results \u2014 not because the tool is bad, but because the market is moving too fast for centralized teams to keep up.<\/p>\n\n\n\n

The second model, which generally works much better, is to allow early adopters to try new tools and find what works. This gives developers autonomy to improve their own workflows and reduces the need for a central team to test every new tool exhaustively.

Comparing the tools by features or technology is less important every day. You\u2019ll waste a lot of energy debating minor differences that won\u2019t matter next year. Instead, focus on what problem you want to solve. Are you trying to improve testing? Code review<\/a>? Documentation? Incident response? Figure out the goal first. Then see if an AI tool (or any tool) actually helps.<\/p>\n\n\n\n

If you don\u2019t, you\u2019ll just make DevEx worse: you\u2019ll have a landscape of 100 tools nobody knows how to use, and you\u2019ll deliver no real value.<\/p>\n\n\n\n

Complexity Can\u2019t Be Removed, Only Abstracted<\/h2>\n\n\n\n

There\u2019s a lot of hype about an AI future without software engineers. The reality is that you can’t remove complexity from engineering. You can abstract it away, but the complexity remains.

Even if this utopia existed, where AI and agents do all the work, we\u2019d still need to create the agents, train them, add new levels of observability, implement better FinOps controls to understand cost and complexity, manage what models they use, and add new layers of governance to audit the reasoning that leads to their decisions.

Imagine you let an AI agent handle incident response: It can gather logs and generate a report. That’s a good use case. Another agent or set of agents can then toggle feature flags via Model Context Protocol (MCP) or trigger rollbacks. That sounds great \u2014 until something goes wrong. Do you have rigorous audits, controls, and a plan for what happens if the AI makes the wrong call?<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

It\u2019s additional layers of complexity. It\u2019s not less work; it\u2019s different work.

In practice, AI tools can add cognitive load rather than reduce it. You might be using five different AI-enhanced integrated development environments (IDEs). Instead of 20 browser tabs, now you have 50. Without thoughtful integration, you\u2019re just making your life harder.<\/p>\n\n\n\n

\"CTA\"<\/a><\/figure>\n\n\n\n

Reducing Cognitive Load With AI<\/h2>\n\n\n\n

If you want your engineering organization to get real value from AI, you have to identify the waste and friction<\/a> that are in people’s way and address them in the same old way \u2014 by having a good supporting platform (whether you call it platform engineering or something else<\/a>). The only way to improve developer experience with AI tools is to approach it from the platform perspective and apply that thinking over and over again. 

Think about platform engineering that not only abstracts away the problems into static dashboards, but also curates the AI-powered layer that summarizes the important<\/em> problems.<\/p>\n\n\n\n

Emphasis on the important<\/em>. There are now AI site reliability engineering (SRE) tools that can help you investigate incidents, but they\u2019ll give you a list of 20 things that could have gone wrong. That\u2019s not helpful from a developer-workflow perspective; devs need one right answer, not 20 possibly right answers.<\/p>\n\n\n\n

Be careful about replacing dashboards curated by humans with opaque AI reasoning. Make sure your data model is solid enough to support it. Once you lose that transparency, you introduce new risks, like your AI confidently telling you \u201ceverything is fine\u201d when it isn\u2019t.<\/p>\n\n\n\n

The Question Isn\u2019t \u201cWhat\u2019s Your AI Strategy?\u201d<\/h2>\n\n\n\n

Around 90\u201395% of engineering inefficiencies are caused by flawed systems, not by people. So don\u2019t just throw AI at everything and measure success by asking people, \u201cDid it save you time?\u201d in isolation. Instead, look holistically across your software delivery lifecycle:<\/p>\n\n\n\n