The One-Person Team

Almost every week now, some AI player releases new models. Progress is being made on several fronts, from long-running tasks to cost to video generation.

I keep telling people that the operational capabilities are skyrocketing, too. While my use cases are small right now, Grok Build is showing great potential for DevOps and SRE work.

I also heard from a friend working at big tech that he is seeing the same thing. Agents are doing great work as sidekicks for huge deployments, for example. It is hard to keep a close eye on hundreds or thousands of downstream infrastructure changes, but you can spin up agents to monitor everything and report back to you.

That got me thinking about my previous jobs, going back 15 or 20 years.

I always excelled at working alone, but there is only so much you can do by yourself. While it was very rewarding, there is a ceiling on how many productive hours you can put in and how many clients you can have. You can stretch that a lot with automation, good documentation, and cheat sheets, but still.

If I’d had the current AI models at the time, I would not have jumped into the corporate world.

There was also a point where I was running the IT at a SaaS company, and we had enough work that we needed five people to run the infrastructure plus internal IT. For a fairly small company, that was a lot of people.

I am guessing that with the SOTA models we have today, I could have run that shop by myself part-time.

Well, except for printers. Even AI hates printers.

I could bring many more examples, but the point I want to make is that AI enables a one-person team to be highly effective and productive, as long as you know what you are doing.

And that last part is important.

Knowing what you are doing depends on your field, but for the sake of the argument, I will stick to what I know: IT.

And this is where things get really interesting.

The people who will get the most out of AI are not necessarily the people who know the most about AI. They are the people who understand the problem they are trying to solve.

If I ask an AI agent to “build me a Kubernetes cluster,” it can probably do a surprisingly good job.

But should I have a Kubernetes cluster in the first place?

What problem am I trying to solve? What are the operational requirements? What are the business constraints? How much complexity am I willing to take on? What happens when something goes wrong at 3 AM? Who is going to maintain it six months from now?

Those are very different questions.

This is why I think a combination of SRE, Business Analysis, and Product Management is becoming an unusually powerful skill set.

SRE teaches you how to think about systems. You learn to care about reliability, failure modes, observability, automation, scalability, operational cost, and what happens after something goes into production.

You learn that “it works” is not the same thing as “it works reliably.”

Business Analysis teaches you to understand the problem before jumping into a solution. You learn how to ask questions, identify requirements, understand constraints, map processes, and distinguish what people say they want from what they actually need.

Product Management adds another dimension: deciding what is worth doing.

You have to balance value, cost, risk, priorities, and the needs of different stakeholders. You have to be able to say no, even when something is technically possible.

AI is extremely good at turning a well-defined problem into an implementation.

It is much less useful when you do not know what problem you are trying to solve.

And this changes the economics of all three disciplines.

A good SRE can now use AI to investigate incidents, write automation, analyze configurations, review infrastructure changes, generate documentation, and monitor systems.

A good Business Analyst can use it to analyze processes, turn conversations into requirements, identify gaps, generate documentation, and explore alternatives.

A good Product Manager can use it to research markets, analyze feedback, explore product ideas, create specifications, prototype workflows, and test assumptions.

But the really interesting part happens when one person can do all three.

You can start with a business problem, figure out what the actual requirement is, design the solution, build it with AI, deploy it, monitor it, analyze the results, and iterate.

There is no handoff.

That last part is important.

Traditionally, these responsibilities are split across several people or teams. A business analyst talks to the business. A product manager decides what to build. Engineers build it. SREs operate it.

Each handoff introduces latency, communication overhead, and the possibility of losing context.

AI dramatically reduces the cost of those handoffs.

A single person with enough breadth can keep the entire context in their head while using AI as an army of specialists.

That does not mean one person suddenly has the knowledge of an entire organization. It means that one person can leverage AI to cover a much larger portion of the work that previously required an organization.

And I think that is the real opportunity.

The advantage is not simply knowing how to use ChatGPT, Claude, Gemini, or whatever the model of the month happens to be.

The advantage is knowing enough about your domain to recognize a good solution, identify a bad one, ask the right questions, and know when the AI is confidently doing something stupid.

AI makes implementation cheap.

It does not make judgment cheap.

In fact, I suspect the opposite may happen. As the marginal cost of producing software and automation becomes extremely low, the ability to decide what should exist, why it should exist, and how it should operate becomes increasingly valuable.

That is why I am increasingly interested in the intersection of SRE, Business Analysis, and Product Management.

It may be one of the best combinations of skills for the AI era.

Need help? If you are trying to figure out how AI can help your engineering or operations teams become more effective, or you are struggling with reliability, operational maturity, infrastructure, or simply too much complexity, I may be able to help. I offer selective consulting engagements focused on practical, pragmatic solutions. If you think I could help your team, learn more about what I do at ebastos.dev/about.