DEV Community: Evgueny lemasovs

Beyond the AI Euphoria: Are We Just Trading Payroll for AI Bills?

Evgueny lemasovs — Tue, 03 Nov 2026 16:32:42 +0000

The Question Nobody Asks Out Loud

AI implementation is the topic of every board meeting. Teams are told to use AI everywhere, budgets are reallocated, and headcount plans are rewritten around the promise that fewer people with AI will do more than more people without it.

But there is one question that is rarely asked out loud: is the economic benefit of AI actually reaching the business, or is most of it quietly flowing back out as payments for AI itself?

This is not an argument against AI. We build AI-powered software every day, and we use AI in our own development process. It is an argument for looking at AI the way a business owner looks at any other investment: through the invoices, not through the excitement.

A Real Story: Five Developers Out, €25,000 a Month In

One of our clients made a decision that many companies are making right now. They reduced their development team by five programmers and asked the remaining developers to work faster through mass adoption of AI tools: coding assistants, AI agents, premium model subscriptions and API access for automated workflows.

On paper, the saving was clear: roughly €25,000 per month in salaries and related costs.

A few months later, the picture looked different. The monthly AI bill (seats, API consumption, agent runs, integrations and the tooling around them) had grown to roughly the same €25,000.

And the outcome? Before the change, the company constantly struggled to deliver projects on time. After the change, it still did. The deadlines were missed just as before. From the point of view of the person who signs the invoices, nothing improved. The cost line simply moved from payroll to AI providers.

This is not an isolated case. It is a pattern, and it is worth understanding why it happens.

Why the Euphoria Is Real, and Why It Misleads

Let us be fair: the feeling of speed AI gives is genuine. An AI-assisted developer can generate a component in minutes, scaffold an API in an hour, and produce in a day what used to take a week. Watching it is exciting, and that excitement is real.

But the feeling of speed and the speed of delivery are two different things. Software projects are rarely late because developers type too slowly. They are late because requirements are unclear, decisions are delayed, integrations are harder than expected, testing finds problems late, and knowledge sits in the heads of a few people.

AI dramatically accelerates one step of the process: producing code. It does much less for the steps around it. When you speed up one stage and leave the rest unchanged, the bottleneck does not disappear. It moves. Today it often moves to code review, testing, integration and, above all, to defining what should be built.

If you step back from the sense of excitement and look at the business through the eyes of its owner, a different and much less visible process becomes apparent: activity has increased, but throughput has not.

Where the Money Actually Goes

The AI bill is rarely a single line. When companies calculate the cost of AI, they usually think of subscriptions. The real total cost of ownership is wider:

Subscriptions and seats. Premium plans for coding assistants, chat tools and design tools, often several per person, because each tool is good at something different.
API and token consumption. Automated pipelines and AI agents call models continuously. An agent that retries, re-reads a large codebase or loops on a failing task can burn through a budget without anyone noticing until the invoice arrives.
Model training and fine-tuning. Adapting models to your data, building retrieval pipelines, preparing and cleaning data sets, and evaluating results. This work is expensive, and it is usually done by exactly the senior engineers you can least afford to distract.
System adoption and integration. Connecting AI to existing systems, permissions, security reviews, compliance checks, monitoring, and changing processes so that teams actually use the tools. System adoption is where many AI projects quietly spend most of their budget.
Review and rework. AI-generated code still needs to be read, understood, tested and maintained. When fewer people review more generated code, defects slip through and come back later as rework, incidents and technical debt.

Add these together, and it becomes much easier to understand how an AI bill can reach the size of the payroll it was supposed to replace.

Why Delivery Dates Did Not Move

Reducing the team changes more than the cost structure. Five developers who leave take with them context: knowledge of the business rules, the history of decisions, the edge cases nobody documented. AI cannot recover that knowledge. It can only work with what it is given.

The developers who remain now carry more responsibility. Their job shifts from writing code to directing AI, reviewing its output and fixing what it gets wrong. That is valuable work, but it is not free, and it does not scale indefinitely. A person can only review so much generated code per day with real attention.

So the company ends up with fewer people, more output, more review load, the same unclear requirements, and the same late deliveries. The problem that caused missed deadlines was never the speed of typing, so accelerating the typing did not solve it.

The Cost That Never Appears on Your Invoice

There is a broader economic dimension that rarely enters the calculation, but it should.

Every job in the local economy works far beyond the company that pays the salary. A programmer's salary generates income tax and social contributions. It pays rent or a mortgage, buys groceries, pays for children's education, holidays, cars and restaurants. Much of that money circulates locally, supporting other businesses, which in turn employ other people, some of whom are your own customers.

When the same budget is redirected to a subscription with a global AI provider, most of that circulation stops. The money leaves the local economy, and the taxes and spending it would have supported are, to a large extent, generated somewhere else.

For a single company, this may look like an abstract concern. Multiplied across thousands of companies making the same decision, it becomes very concrete: weaker local demand, a smaller tax base, and fewer people who can afford the products and services that local businesses sell.

This does not mean companies should avoid AI. It means that replacing people with AI bills is not automatically a saving, even before you count what it costs the economy you operate in.

A Simple Test for Business Owners

Take your accounts for the last month and answer three questions honestly:

How much did you actually save on labor because of AI?
How much did you spend additionally on AI subscriptions, API usage, AI implementation, model training and system adoption, including the time of the people who manage all of it?
Did you earn additional revenue? Did you deliver more projects, deliver them faster, win new clients or launch new products that you could not have launched before?

The AI implementation ROI is not the difference between the first two numbers. It is the first number plus the third number, minus the second. If the third number is zero, then, at best, you have replaced one expense with another. If the second number is larger than the first, you are paying for the feeling of speed.

How to Make AI Pay for Itself

AI can deliver a real return. In our experience, the companies that see it tend to follow a few principles:

Start from a measurable bottleneck, not from a tool. Identify where time and money are actually lost, and apply AI there. If the bottleneck is unclear requirements, more code generation will not help.
Augment people rather than replace them by default. An experienced, AI-assisted developer who knows the business is where most of the value comes from. Cutting the experience to pay for the AI often removes the very thing that makes AI effective.
Measure outcomes, not activity. Track cost per delivered feature, lead time from idea to production, and defect rates, not the number of prompts or lines of generated code.
Treat AI costs like cloud costs. Set budgets and limits, monitor consumption, choose smaller models for routine tasks, cache results, and consider self-hosted or open models where they are good enough.
Invest in the process around the code. Clear specifications, good review practices and automated testing are what turn AI-generated output into delivered software.

Our Take

At ITFriends, AI is part of how we build software every day, and we have seen it make good teams significantly more productive. We are not skeptical of AI. We are skeptical of AI adoption that is never measured.

The question is not whether to use AI. The question is whether AI is creating new value for your business or simply redirecting your existing budget from your people to someone else's servers.

If you are not sure which of the two is happening in your company, that is exactly where we can help: from an honest assessment of your AI costs to an AI implementation designed around measurable business results.

Originally published on ITFriends.AI.

SkySearch for the better flight using 30 rpm API

Evgueny lemasovs — Wed, 21 Oct 2026 16:06:58 +0000

When I plan a trip I rarely know the exact dates. I know something like: a week in Barcelona sometime in May, out in the morning, back in the evening, one stop at most. Every flight search site wants two exact dates, so I end up running the same search for twenty different days and comparing the results in a spreadsheet.

So we built SkySearch, a free tool that takes the loose question directly: a route, a period, a minimum and maximum stay, departure-time windows for each direction and a maximum number of stops. It checks every date combination and recommends the trip that fits best, not just the cheapest one.

This post is about the part that turned out to be the real problem: the API budget.

The numbers

Our flight data comes from Duffel. Like most flight APIs, it has no flexible-date search: every request is one exact pair of dates. And the account is limited to 30 offer requests per minute.

A month-long period with a 5-night minimum stay has 351 possible (outbound, return) date pairs. Pricing each one as a round trip would take almost 12 minutes of pure waiting, before parsing a single response. Nobody waits 12 minutes for a search.

Scan first, then price

The trick is to stop treating every date pair as a separate question.

Scan one-way fares day by day. One one-way search per possible outbound date and one per possible return date. For a month that is about 2 calls per day, roughly 60 calls instead of 351.
Combine the cheapest valid legs into estimated trips. Every outbound day can pair with every return day that gives a stay inside the user's range. The filters (time windows, stops, max flight time) are applied locally.
Score the estimates and keep the top candidates. Only the best few date pairs (8 by default) go on to the next step.
Price those as real round trips. One-way sums are only estimates, since round-trip fares are often different. So every result the user sees is a genuine round-trip offer.

A month-long search ends up at about 70 requests, which is 2–3 minutes with the rate limit. When the number of pairs is small (a short period, or a narrow stay range), the scan would cost more than it saves, so we skip it and price every pair directly:

const scanCost = outDates.length + inDates.length;
const priceDirectly = pairs.length <= Math.min(budget, scanCost + config.roundTripCandidates);

We also changed the default period from a whole month to the first half of next month. With a 5–8 night stay that is about 28 requests, which fits inside a single rate-limit window and finishes in under a minute.

Waiting instead of failing

Duffel reports ratelimit-remaining and ratelimit-reset headers. The client reads them and, when the window is used up, waits for the next one instead of throwing a 429 at the user. The UI streams progress events (NDJSON) the whole time, so the user watches a map fill up with the routes the airlines have returned so far instead of staring at a spinner.

Caching the scan separately

The per-day scan does not send time windows or max_connections to the API. It filters only locally. That sounds wasteful, but it means the scan answer does not depend on the user's filters. If someone repeats the search with a different stay length, different departure times or fewer stops, the cached scan is reused and only the final round-trip pricing calls are made.

Answers are cached in isolate memory (with in-flight de-duplication) and in Cloudflare's Cache API, so other isolates in the same data centre reuse them too: 10 minutes for prices shown to the user, 30 minutes for scan answers.

Scoring "best", not "cheapest"

Every valid trip gets a score from 0 to 100. Price counts for 40%. Matching the preferred departure times counts for another 40%, split between the two directions. Total travel time and the number of stops make up the rest. A slightly more expensive direct flight at 9 a.m. can beat a cheaper one that leaves at 5 a.m. with a long layover.

The top result comes with a plain-language explanation ("direct both ways, morning departure, afternoon return, 10 nights, lowest price among similarly convenient options"). There is no LLM involved: the bullets are generated from the flight data, so they cannot invent anything.

A side effect of the scan: we already know the cheapest one-way sums for stay lengths outside the user's range. When a 7-night trip would be noticeably cheaper than the 10 nights they asked for, SkySearch says so, at no extra API cost.

Things that bit us

Time zones. The API returns airport-local wall-clock times plus an IANA zone. Departure windows compare the local time of day; durations convert both ends to UTC. Stay length counts nights from the local arrival date to the local departure date.
Stops. A "direct" flight can have a technical stop. We count stops from segments, connections and technical stops alike.
Cloudflare Workers limits. A month-long search makes about 70 outbound requests and parses large JSON responses, which is over the free plan's 50 subrequests and 10 ms of CPU per request. It runs on the paid plan.

Stack

Next.js 16 (App Router) deployed to Cloudflare Workers via OpenNext, Duffel behind a small FlightProvider interface (so another source can be added without touching filtering, scoring or the UI), Cloudflare Turnstile in front of the search because each search costs real API calls, and Vitest for the framework-free search logic.

Try it

SkySearch is free and needs no sign-up: https://skysearch.itfriends.ai/

I'd love feedback, especially on two things: would you use "search a period, not dates" for your own trips, and does the score make sense to you, or would you rather just sort by price?

What’s the largest project you or any programmer you know has completed entirely with AI assistance?

Evgueny lemasovs — Mon, 27 Apr 2026 10:21:34 +0000

I’d love to know roughly how big it was in terms of hours of work. I’m particularly interested in real-world projects that were accepted by the client and paid for.