Are Agents Doing to Employees What the Cloud Did to Servers?

Let’s start with a guided visualization:
The year is 2008. You’re the founder of an early-stage B2B2C startup. You’ve raised capital (a $1M seed, following your family & friends round), and there are two major blocks you need to spend money on and take care of:

• Hiring employees.
• Buying servers.

Let’s start with the servers.

First of all, you had to plan. A lot.

Understand the architecture, figure out which hardware fits your needs and your code, figure out how to handle scale. What happens if the app blows up to thousands of users next week? What happens if your app doesn’t blow up at all, and you might need to pivot to something else entirely? What happens if a huge customer onboards?

Scale, for example, is not a problem you can solve easily.

Demand for the app explodes -> you need more compute -> you need to order more servers -> you need to wait for them to arrive -> you need to hook them up to power and network and deploy your software on them - all of that just to meet existing demand, which may well have shifted by the time those servers arrive.

When you want to expand to another region and keep latency low, you need to find and buy/lease new real estate, order new servers for it, and so on.

From an accounting standpoint - a startup has to pay for the servers upfront. According to a 2011 Forbes article¹, we’re talking about tens to hundreds of thousands of dollars, depending on size.

That purchase is CapEx - a capital expenditure. The cash goes out upfront, but on the books the servers aren’t recorded as an expense; they’re recorded as an asset on the balance sheet, depreciated over the years as it loses value. That’s the defining trait of CapEx: a large payment before a single dollar of revenue comes in, an asset sitting on the company’s books, and gradual recognition of the cost over its life.

This can be a real disadvantage for small startups that want to move fast, change direction, or whose app might blow up beyond expectations. Server costs can be a large chunk of the runway, spent upfront - especially in an era when a seed is $1M and an A is ~$4M.² You need to operate the servers, house them, and eventually sell them when they’re no longer needed (which makes this expense significantly less flexible).

You can also look at this model as a serious technological moat for the big companies. Large companies have higher server redundancy. For a given initiative, the right server might already exist inside the company. And if the initiative fails, they can use those servers for another project (instead of selling them), avoiding that expense the next time around.

And then came the cloud

You’re a founder in 2015. The server problem is already solved.³ Scale is now a matter of a few button clicks (and even that got automated). You don’t need to wait, to order in advance, to plan in advance; you don’t need to buy real estate in another region to place servers in. And if you need to pivot - you simply throw the servers in the trash and buy different services.

There’s no big upfront expense burning your runway. No need to buy excess servers for scale that may never come. And the reverse is true too - you can scale up to almost any level instantly, without waiting weeks for servers to be ordered and installed.

Important note: solving the server problem ≠ free servers. In the long run, cloud is not cheaper than buying servers.⁴ It’s just that the money is no longer an upfront problem.

Not by coincidence, since the revolution began we’ve seen a surge in the number of startups positioned to enjoy these advantages of the cloud, both technical and accounting-related. About 73% of all SaaS companies were founded after 2010⁵ - right after the cloud established itself - and today it’s rare to find a startup that isn’t cloud-native.⁶

For the incumbents - that’s one moat fewer.

One model that broke out in a major way after this revolution is SaaS. The server problem was solved so thoroughly that global scale became possible especially for relatively young startups (such as Shopify, Slack). Before that, it was significantly harder for a new player to break through from below, so this was mostly the domain of incumbents, who could sustain a large, sprawling, international operation.

In short: bring an idea, bring developers - and the scale you can reach is infinite and flexible.

Accounting-wise:
Cloud costs are current expenses, not capital ones: no asset on the balance sheet, no depreciation, and you pay per use.

One thing that characterizes software companies in particular, and companies whose business model is built on near-zero marginal cost in general, is high OpEx - much higher than revenue at first, on the expectation that a point will come when revenue far outruns OpEx. In addition, their marginal cost is close to zero, so COGS is low relative to revenue - a gross margin of 70-80% for a typical SaaS company.

This move wasn’t born in software. It started in the chip industry - the one that gave Silicon Valley its name. The software industry then perfected the business model; take early Microsoft, for example - selling the millionth-and-one copy of Windows cost the company little more than the price of the disk it was burned onto (and even that disappeared in the OEM world). In the SaaS world, marginal cost is nearly zero: for Facebook, for example, an additional user joining costs the company almost nothing. They don’t need to buy dedicated hardware for them, and the compute required for everything that user does is negligible.

For most B2B software companies today, what falls under COGS might be a proportional share of the infrastructure allocated to a given customer, and a proportional share of the support and customer success staff serving them - and that still preserves a cost structure of low COGS relative to exceptionally high margins.

Now let’s turn to another large piece a startup has to maintain in order to exist: employees. We’ll talk about R&D employees.
The reason this article focuses mainly on the R&D department is that at most startups, up to around the Series B stage, R&D spend makes up the lion’s share of OpEx.⁷

After the cloud broke into the mainstream, startups would raise a seed to get to an MVP, and once there was strong validation there, plus a forecast of massive customer growth, a relatively large Series A or B would usually follow, meant to bring in a lot of R&D - from the sharpest talents and architects on the market down to mid-level developers, juniors, and QA.

Essentially, more customers means more demands: demands for complex features as well as simple ones, for scale, for different languages, for bug fixes, maybe even for complementary products. And to meet those demands as fast as possible, you need to hire a lot of people - and quickly.
Development capacity is linearly bounded by headcount. R&D employees take development tasks and execute them.

Headcount is not a particularly flexible business:

• Filling a position takes time and attention.⁸
• Onboarding a new employee takes time. That is - until an employee becomes effective, they need a ramp-up period, and they usually eat into their colleagues’ effectiveness along the way.
• Backfilling for people who decided to leave takes time (unlike servers, human beings have free will).
• If a project shuts down - the people who worked on it may be laid off or moved to other departments and products. If they’re moved, it isn’t always the best fit. If they’re laid off - that’s a non-negligible cost for the company: in money, in reputation, and in workforce morale.

By the way, this list is not a new insight. Labor economists have known it since 1962, when Walter Oi coined the concept of labor as a quasi-fixed factor of production: an employee is not a purely current expense, but an investment with an entry cost (recruiting, onboarding) and an exit cost (severance, morale, knowledge walking out the door). These costs are exactly what makes headcount inflexible.⁹

The similarity in inflexibility is easy to see from the previous paragraph alone. Even if, in the end, the function a software architect needs to fulfill inside the company is well defined for the product they’re assigned to work on - that person has their own professional aspirations, their own personal interest in the work, and their own desire to grow their career.

Finding the right employee, especially for complex roles, takes enormous time, effort, and money. Their salary is usually higher (which takes a chunk of the runway), the effort to land them is higher, and it can take weeks and months until the role is filled.

If some of the features required at a later stage of the company are easy to implement, that architect won’t want to work on them, and for that the company has to employ mid-level and junior developers to build those features.

If an initiative fails, the company has to let the employee go. The recruiting and onboarding costs for that employee are already sunk and unrecoverable (and unlike a server, which is an asset that can be sold or repurposed - an employee is not). What decides the matter is the costs going forward: layoffs cost money in severance, morale, and reputation, and hiring a replacement costs even more - according to Gallup, replacing an employee costs between half a year’s and two years’ salary.¹⁰ So companies prefer to move that employee to a different role (not necessarily one they’re better suited for) and accept that this role, too, will require onboarding (meaning that in the short term, their output takes a hit).

Here too, it’s easy to see that large companies have a certain advantage. Incumbents can span multiple products, they can offer a broader growth horizon with more disciplines, and internal mobility can be more efficient than at a small, single-product startup trying to break into the market.

The function servers fulfill is processing capacity, and the cloud makes companies’ ability to consume that function as flexible as it can possibly be.
R&D is a function of development capacity. The way companies acquire that capacity has been, as described, hiring more and more employees. Until now.

Agents break into the mainstream

In a gradual process starting in 2023, which picked up real speed in late 2025, LLM-based agents came into being. Today, agents can write code, write specs, run tests, handle CI/CD pipelines, and help with decision-making in almost every area.

It seems, to a degree, that the second (and last) big block left standing for small startups is being breached by those agents. We can see similarities between what agents are doing to R&D organizations and what the cloud did to servers.

For example: agents, much like the cloud, are not necessarily cheaper than employees in the long run. The working models aren’t fully settled yet, token costs can reach thousands of dollars per employee per month, and given that this is a new technology - the work isn’t necessarily done in the most efficient way, the way the market will translate it a few years from now, once the process is fully adopted.

The more substantive similarities:

Speed. Agents don’t need recruiters, don’t need weeks of interviews, and when they’re no longer needed - there’s no need to lay them off or move them to another role. You can simply delete them. Much like the speed advantage of cloud over servers.

Pricing. While an employee’s cost is fixed across the months they work at the company, an agent’s cost varies with the operations it runs. An agent can work 24/7, and when it’s not needed - even temporarily - it costs nothing at all. Exactly like the cloud model. Or, to put it in the economists’ terms: if an employee is a quasi-fixed factor of production, the agent is the first factor of development-work production with near-zero entry and exit costs. The first that truly behaves like variable OpEx.

Today, a hand-picked team of product and engineering experts, possibly tiny - say 5-15 people (a size typical of a company’s very early days, usually after the pre-seed or seed stage) - plus an army of agents, can wield firepower and delivery capabilities resembling those of a company several times its headcount (which usually reflects a larger raise, an A or a B). Especially given the lean codebase, the team’s expertise, and the precise fit of each person to the role they perform.¹¹

Just like the cloud: you can stand up a lean cloud footprint at a tiny cost relative to buying the servers upfront, housing them, and maintaining them.

It will be interesting to watch, over the next few years, how this affects the OpEx line. Will the graph of feature production and bug fixing as a function of headcount remain linearly bounded, or break through it?
That is, can the right team mix - few employees, many agents - produce output equal to a development team an order of magnitude larger?
And will it be possible to harness this scalable, pay-per-use workforce at high speeds - much like the gap between consuming cloud as a service versus buying it as a server?

Here, too, let’s look at the incumbent

Today’s incumbents were built before the agent era. Over the past year we’ve been witnessing a wave of layoffs across many of the big tech companies. AI appears to be cited as one of the main reasons.¹²

Even if on paper the cuts are meant to support integrating agentic technologies into development and build processes, their implementation doesn’t necessarily serve that goal. Most likely, the layers being laid off belong to less economical projects, and resources are being shifted to features better suited to the current era. Some cuts may be performance-based - but performance that reflects pre-AI-era work.

At the incumbents, once the excess weight is shed, there’s no guarantee the remaining team can actually integrate an agentic environment as efficiently as a small startup raised on AI. The remaining workforce doesn’t necessarily know how to operate these tools optimally, and the infrastructure and codebase won’t necessarily support the use of AI tools optimally either.¹³

In the past we’ve seen plenty of incumbents lose their greatness to efficient disruptors rising from the bottom of the market (a phenomenon covered extensively in Clayton Christensen’s Innovator’s Dilemma). One of the incumbents’ effective ways of overcoming it is simply to buy those companies - before they get big and threaten their position - and bring their technology and products in-house.

A good example is happening in security - the field I’ve worked in for the past decade. In recent years we’ve been seeing major consolidation in the space. There are a handful of platform companies bundling security solutions for nearly every product on the market. When a need arises for a new security product, those incumbents can build a solution themselves, or wait for the market to run its course until there are a few established players in the space. They can even choose to invest in startups early on. Once a few startups succeed (stable PMF is found for them, sometimes even paying customers) and their solution proves genuinely effective - the incumbents buy the products and add them to their suite. That’s how they preserve their market dominance.¹⁴

It may be that an effective way for incumbents to adopt the paradigm is this: given a meaningful market signal toward a particular technology - they’ll start building the solutions themselves, in lean, fast internal incubators. That could significantly raise the odds that the re-org done as part of AI-driven cuts is actually effective, rather than just a trim of the expense line.
It’s not that incubators of this kind didn’t exist at large companies before, but with the flywheel described above it becomes more and more scalable - and it may affect startups’ ability to get acquired by those companies.
A paradigm shift like that could affect the exit strategies of startups being founded today.

To sum up, there appear to be strong similarities between the cloud-servers relationship and the relationship between AI-based agents and employees in organizations:

• The function one replaces in the other
• Characteristics: the ability to scale up & down, the speed, the price
• Accounting line items and how they’re treated
• Companies’ ability to make their consumption of capacity (processing/development) flexible

Of course, at the end of the day these are entirely different revolutions - development agents are just one utilization of AI, replacing a person with an agent is not one-to-one (the way a server can be swapped for EC2), and so on.

In the cloud, these characteristics enabled several revolutions, SaaS first among them. It’s still too early to say what the equivalent(s) for agentic AI will be - or whether there will be one. Only in hindsight will we know which of today’s early sprouts fueled those revolutions, if and when they happen.

In the next post I’ll dive deeper into how agentic AI is already affecting product development today, into more accounting matters, and into whether it’s exposing the first cracks through which disruptors could bring incumbents down.

Feel free to reach out and discuss on any platform you find here. Predicting the future is hard, so I’d love to hear more opinions, feedback, and good food recommendations.

---

Footnotes

1. Joe McKendrick, “Cloud Computing Is Fuel For The Next Entrepreneurial Boom”, Forbes, November 2011. ↩

2. The typical seed round in the era before round inflation was $500-900K (PitchBook); at Series A, mid-2000s funds typically invested $3-5M (Crunchbase News), and the median A still stood at $2.8M in 2012 (PitchBook). ↩

3. Although AWS launched EC2 back in 2006, adoption was gradual: in a 2009 Forrester survey, only 3% of enterprises were using pay-per-use virtual server hosting, and about half cited security and privacy concerns as the main reason for avoiding the cloud. Only toward the middle of the following decade did the cloud become the default. ↩

4. Forbes noted as early as 2011 that the economic advantage converges after two to three years; a16z showed that at scale it’s even more expensive. ↩

5. Cloudwards, SaaS Statistics. ↩

6. Gartner, November 2021: by 2025, ~95% of new digital workloads will be deployed on cloud-native platforms (up from 30% in 2021), and 85% of organizations will embrace a cloud-first principle. Coverage in TechRepublic. ↩

7. According to Scale Venture Partners (Scale Studio, 1,000+ private companies), in the $0-1M ARR range S&M makes up only ~25% of OpEx - meaning R&D is the majority - and only above $25M ARR does it become the largest line item. According to the 2026 SaaS Capital survey (1,000+ private B2B SaaS companies), the medians at mature companies are: R&D 22% of ARR, Sales+Marketing 23%, G&A 15%. ↩

8. The average time to hire a software engineer stands at about 35 days, the median in engineering is 41 days, and according to Workable, the global average for engineering roles reaches 62 days. For senior roles, about 40% of positions take 90+ days to fill (SHRM 2025). ↩

9. Walter Y. Oi, “Labor as a Quasi-Fixed Factor”, The Journal of Political Economy, Vol. 70, No. 6 (1962). ↩

10. Shane McFeely & Ben Wigert, “This Fixable Problem Costs U.S. Businesses $1 Trillion”, Gallup, 2019 - the cost of replacing an employee ranges from one-half to two times their annual salary. ↩

11. According to Bessemer, the fastest-growing AI companies generate about $1.13M ARR per employee - 4-5x a typical SaaS company - and Lovable reached $200M ARR with only about 45 employees. ↩

12. According to Challenger, Gray & Christmas, nearly 55,000 US layoffs in 2025 were explicitly attributed to AI, and according to a 2026 tracker, about 54% of tech layoff events explicitly cite AI or automation as a factor. Notable examples: Amazon cut ~30,000 corporate roles within three months (~9%), Meta 10%, Atlassian 10%, Snap 16%, Oracle ~13%, and Salesforce cut ~4,000 support staff, with Benioff’s famous line: “I need less heads”. ↩

13. A Stanford study of 100,000+ developers found that AI delivers a 30-40% improvement on simple greenfield tasks, but only 5-10% (and sometimes even negative) on complex legacy code. An AI-native startup lives at the high end; an incumbent with a twenty-year-old codebase - at the low one. ↩

14. This is how Palo Alto Networks built its platform over a decade - acquisitions like Demisto (SOAR), Twistlock (container security), Expanse (ASM), Cider (AppSec), Dig and Talon - and at the peak, the ~$25 billion acquisition of CyberArk, the largest in its history, which added an entire Identity Security pillar. A notable competitor - CrowdStrike followed a similar path (Humio for logging, Preempt for Identity, Bionic for ASPM, Flow Security and Adaptive Shield). ↩