{"id":139,"date":"2026-09-02T09:40:19","date_gmt":"2026-09-02T09:40:19","guid":{"rendered":"https:\/\/www.dobryakov.net\/blog\/139\/"},"modified":"2026-09-02T09:40:19","modified_gmt":"2026-09-02T09:40:19","slug":"ai-development-ideas-myth","status":"publish","type":"post","link":"https:\/\/www.dobryakov.net\/blog\/139\/","title":{"rendered":"The Business Has No Ideas for AI \u2014 No, It Just Gave Up on You"},"content":{"rendered":"

A common belief I keep hearing is about AI in software engineering is that the speed doesn't matter because the business doesn't have enough ideas to fill the pipeline.<\/p>\n

<\/p>\n

If you sit somewhere around the level of an average team lead, a DevOps engineer, or a QA, and it genuinely seems to you that the business doesn't have enough ideas \u2014 you may be misreading the signal.<\/p>\n

The backlog may reflect learned restraint, not lack of demand<\/h2>\n

It's not that the business lacks ideas. The business has so thoroughly been burned by your low throughput, your chronically missed deadlines, and the regular boomerang of tickets sent back into bug-fixing and refactoring that it simply gave up on you. What you see as a calm, manageable backlog is resignation. The business stopped asking for anything beyond the unavoidable critical fixes because watching you slowly massage your architecture and your patterns \u2014 and still ship bugs and rework \u2014 became unbearable.<\/p>\n

I spend a good portion of my time sitting on the development side of the table at C-level meetings across various companies. In those meetings, the discussion usually shifts to ROI, delay cost, and headcount. The discussion is usually blunt. Nobody in that room believes you are doing important work, building extensible and maintainable architecture, or covering a hundred edge cases. In any company \u2014 whether it's an offline retailer or a purely online SaaS product \u2014 developers are openly discussed as an unavoidable evil. A tax on getting things done.<\/p>\n

This is not a figure of speech. It is discussed literally, in the language of ROI, headcount budget, and cost of delay. One round of bug-fixing after a release, and the CFO is calculating losses not in developer-hours but in lost sales, customer churn, and dead time-to-market. In that model, developers are a line item with unpredictable return on investment.<\/p>\n

What they tell you versus what they think<\/h2>\n

Nobody tells you this, because you'd quit on the spot out of sheer depression.<\/p>\n

Instead, you get the mission speech. Business continuity. Reliability. Delivery guarantees. Geo-distributed resilience. Low recovery time objective. Data redundancy. the standard vocabulary of engineering excellence. management often uses this vocabulary because it makes engineering work easier to coordinate, because it's the only way developers become manageable \u2014 the only way you can be led by the hand toward a result.<\/p>\n

Look at it from management's perspective. You can't walk up to an engineer and say: "Listen, you're a consumable. Your job is to ship this feature faster and cheaper." They'll get offended and leave. Or worse, they'll get offended and stay \u2014 and quietly sabotage the work.<\/p>\n

So management frames the work as reliability, quality, and craftsmanship. SLAs. Fault tolerance. Architectural purity. Engineering craftsmanship culture. It's not a lie \u2014 reliability is genuinely needed. But the function of that narrative isn't reliability. The function is manageability. A developer who believes they're doing important engineering work moves predictably toward a result. A developer who discovers they're a line item in a spreadsheet \u2014 doesn't.<\/p>\n

But in budget and planning discussions, engineering is treated as a costly constraint to reduce where possible.<\/p>\n

The break<\/h2>\n

I have seen this shift when team leads move into engineering management<\/a>. Yesterday, the person lived inside the concepts of architecture, refactoring, and fault tolerance. Today, they're being openly and cynically required to see their former colleagues the way you see toner in a printer. While it's there, nobody thinks about it. When it runs out, you just replace it.<\/p>\n

That's the moment the former architect sits down in a meeting with the VP and the CEO and realizes: many engineering practices they valued \u2014 architectural decisions, SOLID principles, code reviews, coding standards \u2014 in this room, it's worth nothing. What this room counts is different. How much does a delayed feature cost in dollars. How many customers were lost in a quarter because of a production bug. By what percentage can engineering headcount be reduced if some of those tasks move to AI.<\/p>\n

CTOs and VPs usually evaluate architecture and process by whether they reduce incidents, coordination cost, and executive attention. Not jumping at every alert. Not mediating conflicts between teams. Not explaining to the business why the release got pushed again. And when someone offers them a way to get the same result with fewer people \u2014 they have no sentimental reason to say no.<\/p>\n

Example: AI adoption driven by management<\/h2>\n

At one company with $680M+ revenue, 15 million customers, and 9,000+ employees. AI transformation didn't come from the bottom up \u2014 no enthusiastic developer dragged ChatGPT into the building. The demand was formed at the decision-making level: management wanted it, management got it. Within six to eight months, a separate AI department was carved out. Non-technical staff \u2014 marketers, analysts, operations people \u2014 started building their own tools. Not because they were forced to, but because for the first time there was a way to get a result without waiting in the JIRA queue.<\/p>\n

AI bot connected to the data lake: time to insight went from days (a ticket in the analyst queue, prioritization, waiting, a report) to seconds. Instead of submitting an analytics ticket, employees could query the data lake directly through a bot.<\/p>\n

Another case: a SaaS product with several thousand bugs in the tracker and five to ten new ones arriving daily. Releases every few months. Customers were afraid to update because after every update, something would break. In that company, this was the normal release pattern \u2014 it's the standard reality the business had gotten used to and stopped expecting anything different from.<\/p>\n

And into that context arrives AI-assisted development, which turns a two-week sprint into ten to thirty minutes of work. Thousands of automated tests before every commit. Zero production crashes in six months.<\/p>\n

Why \u201cAI will not change team size\u201d is unlikely<\/h2>\n

So all the talk about how clients supposedly don't need AI-assisted coding, how clients supposedly don't have a stream of ideas, how everything will stay the same, nobody will be fired, and the same developers will just sit there in the same composition and code a little bit with AI \u2014 that assumption ignores how clients react once delivery time drops sharply.<\/p>\n

For many clients, the reaction is simple: long-delayed work suddenly becomes feasible.<\/p>\n

Small UI changes, data questions, and deferred features stop requiring months of queueing. Not next quarter. Now.<\/p>\n

In many cases, demand was suppressed by slow delivery; faster tooling can surface it again.<\/p>\n

The claim that business does not need speed may be a way to rationalize the current delivery pace. It protects teams from questioning whether the current pace is acceptable. If the client isn't asking for new things, then everything is fine, nobody will replace me.<\/p>\n

The client goes quiet not because there's nothing to want. They stop proposing work because each request has historically meant long waits, rework, and uncertain results. Every voiced idea means months of waiting, rework, estimates of "400+ hours," and a result that still doesn't match what was asked for.<\/p>\n

AI-assisted workflows make some of that work possible with fewer engineers.<\/p>\n

The change is not only acceleration; it can also reduce required headcount. Or with one person instead of a team of twelve.<\/p>\n

Management will replace expensive delivery paths when cheaper ones produce acceptable results.<\/p>\n","protected":false},"excerpt":{"rendered":"

One of the most absurd beliefs about AI in software engineering is that the business doesn’t have enough ideas to justify the speed. The reality is uglier.<\/p>\n","protected":false},"author":0,"featured_media":138,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[121,103],"tags":[2,124,107,123,122],"class_list":["post-139","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai","category-engineering-management","tag-ai","tag-c-level","tag-engineering-management","tag-productivity","tag-software-engineering"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t