Why Being a Generalist Is an Advantage in the AI Era

Being a generalist wasn’t a plan

I’ve been having a lot of fun experimenting with AI lately. I get an idea, open a terminal, start a conversation, and before long there’s something running. One thing keeps surprising me: the part of my background that helps most isn’t any single skill. It’s that I’ve done a little bit of everything.

I didn’t choose that. Startups chose it for me. When we started the company there was no budget for a specialist in every seat, so the work went to whoever was there, and a lot of the time that was me. I’ve written about being almost every department at once, so I’ll keep the list short. Over the years I’ve worked on product development and strategy, written the software, designed the architecture, run the servers and the network, handled security, done sales and business development, answered customer support, hired and mentored engineers, and watched the operating costs against what customers paid.

I wasn’t the world’s best at any of those. What I picked up was how they push on each other. In VoIP, least-cost routing was the everyday example. The cheapest carrier for a call and the carrier with the clearest audio were rarely the same one. So every routing rule was also a call-quality question for support and a margin question for the business. You learn to ask what a decision does to the parts of the company you aren’t looking at. That habit is most of what I mean by judgment.

AI makes the range more useful

AI changed how quickly I can move between those areas. In one sitting I can go from a rough product idea to a data model, a first version of the code, the infrastructure to host it, a draft landing page and a first guess at what it would cost to run. Each of those used to be its own project, and sometimes its own hire.

FedPath is the clearest example. It helps small businesses find and evaluate federal contracts, and it went from an idea to a working product much faster than I could have managed alone. Useful Little Tools and this site were built the same way, with an assistant in the loop and me reading what it wrote.

What AI doesn’t know is my business. It doesn’t know who the customer is, what they’ll pay, how many support emails a feature will create, or which shortcut will hurt in six months. Ask it for a plan and you’ll get a very confident one. It’s now cheap to get an answer in a field you don’t work in. Telling whether that answer is any good still takes some experience in the field.

Knowing enough to ask the right questions

Experience tells you which questions exist, so you can ask the AI, or an expert, before the problem shows up in production.

I don’t need to be a security engineer to notice that a login form has no limit on attempts. I don’t need to be in finance to ask what a feature does to the monthly bill. I only need to know those questions are there.

Here’s a hypothetical. Say I ask an assistant to add text-message login to a side project. It will write a working flow in minutes: a form, a code sent by SMS, a check, a session. The code will probably look fine. The questions that matter sit around it.

A specialist in each area would catch their own row. What a generalist adds is seeing that the rows are connected. The security answer changes the cost, because bots that trigger texts run up the bill. The cost answer changes the product decision, because in some countries a text costs enough that email login makes more sense. Coming from telecom, the cost row is the first one I’d look at.

The other half is noticing when something doesn’t add up. An AI cost estimate that ignores data transfer looks reasonable until you’ve paid a bandwidth bill. A design with five services for a tool three people will use looks professional until you’ve had to keep five services running. That’s the reason I wrote about when a microservice should actually be a microservice. You don’t have to be an expert to feel that something is off. You have to have seen the real version before.

Generalists still need specialists

None of this makes generalists better than specialists. As the company grew, the team grew to more than 30 people, including VoIP specialists and designers. I could talk with them about their work. I couldn’t do it as well as they did, which is why they were there.

Specialists find the problems a generalist walks past: the slow query that only shows up at a million rows, or the race condition that appears once a week. AI doesn’t replace that depth either. It gets you to a decent first answer in almost any field. The last stretch, where the hard bugs and the real risks are, still belongs to people who have spent years in that one area.

The generalist’s job on a team is connecting the parts. That means noticing that a security decision changes the support load, explaining an engineering tradeoff to the person who owns the budget, and asking the question that falls between two teams. I wrote about what happens when nobody watches those boundaries in specialization shouldn’t stop at your own code. Good teams need both kinds of people, and they need them to respect each other.

Why I’m enjoying building again

For a long time an idea had a price. To try a product, I had to find the time to build all of it myself, or find the people and the money to build it with me. Most ideas stayed ideas.

AI lowered that price. I can try something quickly and find out whether it deserves more of my time. Because I’ve done a bit of everything, I can carry an idea further on my own than I used to: past the code, into hosting, security, a landing page and a rough idea of whether the numbers work. Lately that has meant a job-search agent on Hermes, SurgeIQ for cycling stats, and a lot of work on this site.

I still get things wrong. I still hand the hard parts to people who know them better. But the distance from “I wonder if…” to something I can show people is short again, and I’m enjoying that more than I expected to.

Short answers