"We'll Just Hire a Junior"

The most expensive assumption in AI right now isn't about what the technology can do. It's four words about staffing: we'll hire a junior.

We hear it constantly, in some variation. We'll bring on a junior engineer to build it. We'll get an intern who knows this stuff. My nephew is good with computers. It's said casually, usually near the end of a conversation, and it's almost always the moment a project quietly stops being real.

The assumption is not stupid. It's reasonable, and it's reasonable for a specific reason worth naming: the demos really are simple. You watch someone produce a working thing in an afternoon. The code is short. The model appears to be doing the hard part. And ten years ago the equivalent task — wire up an API, move data from one system to another, put a form on top — genuinely was junior work. The instinct is calibrated to a world that existed recently enough that nobody has updated it.

So let's do the arithmetic out loud, because it's the part that never gets said in the room.

An engineer who can actually build a reliable system on top of these models — not a demo, a thing that runs unattended and doesn't embarrass you — is compensated somewhere between a hundred thousand dollars and well north of two hundred, depending on market and depth. Add employer taxes, benefits, equipment and software, and the fully loaded number is meaningfully higher than the salary line. Call it a hundred and thirty at the absolute floor and north of two-fifty at the level most companies actually need. Per year, every year, whether or not there's a second project.

That's assuming you can identify the right person, which is its own problem and the one people underestimate most. The skill is new enough that credentials don't sort candidates. There's no degree for it, the certifications are noise, and a resume full of the right words tells you almost nothing about whether someone has shipped a system that survived contact with real data. Firms that are good at hiring engineers find this hard. Firms that have never hired an engineer are being asked to evaluate a candidate in a discipline they have no internal reference for.

Which leads to the second cost, and it's the one that actually bites. When you hire your first engineer into a company with no engineering function, you're hiring one person into a role where nobody can review their work. No senior to catch a bad architectural decision in week three. No peer to say "don't do it that way, you'll be rewriting this in six months." Nobody who can tell the difference between slow progress and no progress. You find out how it's going in month nine, when the thing is either working or it isn't, and by then the cost isn't the salary — it's the year.

And third, retention. Whoever you hire becomes considerably more employable over the twelve months they work for you, in a market that is actively competing for exactly that experience. You are training an asset that has legs.

Now the honest other side, because there are real cases where hiring is the right call and I'd rather say so than pretend otherwise.

Hire when the system is part of what you sell rather than something that supports what you sell. Hire when you're confident there's a second and third project behind the first, because then you're building a function, not filling a gap. Hire when you have someone technical enough to evaluate the candidate and supervise the work — and be strict about what counts here, because an IT director who runs your network and your Microsoft licenses is an excellent professional who is not equipped to assess an agentic system architecture. Those are different jobs that share a department.

If those three are true, hire, and hire properly — at market, with a plan for who reviews the work.

If they're not, you're proposing to take on a permanent salary in order to acquire a capability you intend to use once. That's the trade, stated plainly. Most people wouldn't take it if it were stated plainly, which is precisely why it usually isn't.

There's a version of this that people miss in both directions, though, and it's the practically useful part. Building the system and operating the system are two different jobs, and only one of them is expensive.

Operating a well-built system — reviewing what it queued up, approving what goes out, noticing when something looks off, adjusting the criteria as the business changes — is a job for a capable, organized person who already understands your business. It is not an engineering job, it does not require an engineering salary, and in most companies the right person is already on the payroll. What breaks is when firms conflate the two, conclude they need an engineer permanently because someone has to run this thing, and then price the whole endeavor off the wrong salary.

Separate them and the decision gets much clearer. The build is a defined piece of work with an end date and a number attached. The operation is an ongoing responsibility that fits into a role you already have. The mistake is treating the second one as a reason to hire for the first.

One last thing, and I say it with some sympathy because I understand the pressure that produces it. When someone says "we'll hire a junior," they're usually not making a staffing judgment. They're saying the number they've heard for doing this properly is larger than the number in their head, and a junior salary is what the number would need to be for the project to feel affordable. It's a budget wish that has been reverse-engineered into a job title.

That's worth catching early, because it doesn't get cheaper by being ignored — it gets more expensive, about nine months later, in a form that's harder to explain to a board.

If you're weighing this right now, the useful exercise is to write down what the system has to do, then get an honest build number and an honest hire number next to each other, fully loaded, over three years. Sometimes hiring wins outright. We're happy to help you build both numbers, including the one that argues against us.