The generalist and responsibility

I spent a good part of my career feeling like a duck: it swims, walks, and flies, but doesn’t do any of the three very well. A bit of code, a bit of data, a bit of design, a lot of product. In a market that rewarded specialists, that looked like a flaw.

It stopped looking like one.

What happens when knowing how to do things gets cheap?

The person who put a name to what I’d been feeling was Karim Lakhani, who researches how AI changes work. The thesis he has been repeating for years: the marginal cost of expertise is going to zero. And he follows it with a provocation for companies: if a company is, at bottom, a bundle of expertise, what does it do when that cost collapses?

I very much agree, with one addition: when expertise gets cheap, what starts to count is the will to build. And there’s the joke I keep repeating: I used to blame the team for delays, poorly implemented stuff, a bad experience. Now I’ve found out that I’m the one who’s bad at defining the product. It hurts, but it’s true.

It doesn’t mean specialists became useless — the previous chapter has an accountant saving my skin. It means access to specialized execution got cheap. I’m no longer afraid of data analysis, of code, of design. Not because I got good at all three: because I can get to a decent result in all three, fast, and I know where to call someone.

What this rewards is the person who sees the whole process. Someone who understands the client’s problem, knows what to ask for, notices when the result doesn’t make sense, and puts the pieces together. I called this becoming a “full-service” person back when it was still a bet.

Today I have an autonomy I never had before. I’ve always been a bit of a lone wolf; now I can go from problem to working product without waiting for anyone. That’s powerful, and it has a price that deserves to be said out loud.

What if expertise came in a format I can read?

There’s a detail in this story that, for me, is the center of everything. It’s not just that specialized execution got cheap. It’s that expertise now arrives in natural language — in a format I can read.

Before, a specialist’s knowledge came wrapped in the craft: the code, the statistical model, the design file, the contract clause. To evaluate it, I had to master the craft or trust blindly. Today, when I ask for an analysis, I get the plan, the reasoning, the alternatives that were discarded and the explanation for each choice along with it — in plain language. I can read it, ask “why?”, ask for the counterargument, and only then decide.

That’s why I don’t like the term vibe coding. It suggests programming on vibes, accepting whatever comes without looking. My experience is the opposite.

I’ve had a problem with the term since it first appeared. At first the reason was about identity: I didn’t want to be a mediocre dev, I wanted to be better at product. Later it became clearer that the problem is something else — critical thinking. And I confess: I often catch myself “vibing,” not thinking about what I’m doing. That’s exactly why I keep an eye on myself.

So did the work get lighter?

The biggest change in my day wasn’t that I stopped writing code. It was that I started reading all day long. I even wrote it in all caps: I have NEVER read so much in my life.

The agent shows the plan: I read it. It shows its reasoning: I read it. It explains why it chose a path: I read it, and sometimes I disagree. It delivers the result: I read it before accepting. My job became reviewing, deciding, and redirecting.

Lakhani’s research with consultants gives names to the ways people work with AI. Most act as cyborgs, solving the problem together with the AI in constant back-and-forth; a smaller share as centaurs, who split the work (“I do this, it does that”) and supervise what comes back; and about a quarter as self-automators, who press play and hand in whatever comes out. The third group learns the least — in his words, because they stopped thinking.

He’s tough on people who fall into that. If all you are is a meat interface to the silicon, what’s your value? He says he has fired people who justified poor work with “the AI gave me that.” And he has a personal rule worth copying: never take the first answer. Ask for alternatives, make the model argue against its own proposal, look for the red flags. The first answer is the average answer; the good one shows up after someone with judgment pushes.

My request is always the same: don’t be a proxy from one AI to another AI. Working with AI has two cycles, generating and reviewing, and you can learn in both. I understand a lot more about code today because of reviewing, not generating.

Anyone who pictures using AI as pressing a button and going for coffee is describing the way of using it that goes wrong. And it’s that person, not the attentive generalist, who becomes easy to replace.

How do you teach this?

The conversation in which he makes this case has the part that interests me most as a teacher. At one of the world’s most traditional business schools, the required course on AI changed in nature when the faculty realized you can’t just talk about AI — you have to do AI.

What changed, in practice:

• Half the course became building. Students solve business problems by building tools with AI.
• The final exam is gone. The argument is simple: how can you have a course on AI where you can’t use AI in the assessment? Projects took its place — the whole class had to deliver working solutions.
• The cases stay, in a different role. The discussion of economics, strategy and change management now comes after the class has gotten its hands dirty: “I can do all of this; so what does it mean for my company and for my job?”

He sums up the personal change honestly: for many years, it was enough to put a case in front of the class; now the classroom has a lot of “doing.”

That’s the invitation of this guide, and it’s what I try to practice: in my Information Systems classes, students ship real products to graduate. Swap the report about the case for the solution to the case. Whoever builds finds out where the tool fails, what needs checking, and what they didn’t know they didn’t know — three things no report teaches.

I only keep my reservation about the name. Lakhani calls it vibe coding. I’d call it building by reading.

What remains human?

• Knowing what’s worth doing. AI builds anything you ask for, including the wrong thing.
• Knowing the context. The team that uses that screen, the client who hates that term, the rule nobody wrote down.
• Judging the result. “It’s plausible” and “it’s right” are different things, and someone needs to know the difference.
• Communicating. Explaining a problem clearly to a person or to a model is the same skill.
• Answering for it. That one can’t be delegated.

Whose responsibility is it?

Every AI system was designed, trained, configured, and put online by people’s decisions. The moral and practical responsibility for what it does belongs to those who create it and those who use it. Never to the software. No matter how big the chunk of work you can delegate in one go gets, the responsibility is still yours.

If you create — train a model, set up an agent, write the prompt other people will use:

• Look out for who is in the data and who was left out (chapter 4).
• Bring in people different from you to try to break the system before launch.
• Write down where it fails. A known, documented limit is a tool; a hidden limit is a trap.
• Protect the data: consent, the minimum necessary, nothing sensitive where it isn’t needed (chapter 5).

If you use — and everyone does:

• Double-check when what’s at stake is someone’s health, money, rights, or safety.
• Treat the answer as an estimate, not as truth.
• Speak up when you find an error or a bias. That’s how it gets better.
• Take care of your data and, above all, other people’s data.

There’s no passing score. The items are more or less in chapter order; the first one you didn’t check is a good place to go back to.

What I don’t know

An honest guide needs a section like this.

I don’t know what happens to jobs. I see, from the inside, teams doing more with fewer people, and companies preferring to invest in tools rather than hire. Anyone who says this won’t affect anybody is selling something. Not even researchers agree on who is most at risk: Lakhani, for one, thinks the question is far from settled and bets the bigger danger sits in middle management, which resists change — not with people starting out, who absorb the tool without fear. My personal strategy — half joke, half serious — is to try to be in the last 1% to be replaced. That’s not an answer for society; it’s just what’s within my reach. The collective answer is a matter for public policy, and that’s why I teach where I teach.

I don’t know whether today’s prices will hold. Much of what we use is subsidized (chapter 12). There may be a bubble, and it may burst. Hence the insistence on not depending on one vendor and on keeping your knowledge in a place that’s yours.

I don’t know when the “do-it-all” agent will be safe enough. Maybe it already is, and the resistance is mine. I’d rather err on that side.

What I do know: there’s no going back. There are open models anyone can download and run. If today’s companies disappeared tomorrow, the technology would still be here. The choice that remains isn’t between using and not using. It’s between using it with understanding and using it believing in magic.