'We need an AI engineer' means one thing if you're shipping a single chatbot feature this quarter and a completely different thing if you're building shared AI infrastructure three teams will build on for the next two years. Companies routinely hire a feature-scoped engineer for a platform-scoped job (and stall for six months) or hire an expensive platform architect for a single-feature job (and overpay for instincts they'll never use).
Two genuinely different jobs, not two seniority levels
It's tempting to treat 'platform' as just a more senior version of 'feature,' but the difference is instinct, not experience. A feature engineer's best instinct is to cut scope ruthlessly and ship something narrow that works; a platform engineer's best instinct is to notice the pattern behind three different requests and build the one abstraction that serves all three, even if it takes longer up front. Put a platform-minded engineer on a single feature and they'll build configuration options and abstractions nobody asked for. Put a feature-minded engineer on a platform and you'll get three separate one-off implementations wearing a platform's name.
- Feature instinct: what's the fastest correct path to shipping this one thing well?
- Platform instinct: what will the fourth team ask for, and how do I not have to rebuild this for them?
- Feature engineers optimize prompts and retrieval for one use case's data and failure modes.
- Platform engineers optimize a gateway, an eval harness and shared guardrails that many use cases plug into.
Side by side
| Dimension | Feature hire | Platform hire |
|---|---|---|
| Primary output | One working AI feature in production | Shared infrastructure: gateway, evals, guardrails, templates other teams use |
| Success metric | Feature ships, works, and is cheap enough to run | Time-to-first-workflow for the next team drops; adoption across teams rises |
| Ideal background | Product-minded AI engineer, has shipped 2-3 similar features before | Has built or scaled infrastructure before; comfortable being a force multiplier, not a feature owner |
| Biggest risk if mis-hired | Over-engineered v1, missed launch window, budget overrun for a single feature | No usable platform emerges; every team builds its own tooling anyway, and you paid platform rates for feature output |
| Right time to hire | You have one or two clear AI use cases and a deadline | You have three or more teams independently building AI workflows, or a clear roadmap to get there within a year |
How to hire for the scope you actually have
- 1Count your real use cases, not your ambitions: one or two concrete AI features on the roadmap means hire a feature engineer, full stop, regardless of how big the long-term vision is.
- 2Ask candidates directly which job they'd rather do: strong feature engineers often say so plainly ('I like owning a thing end to end'), and strong platform engineers do too ('I like building the thing three teams use'). Believe their answer over their resume.
- 3For a feature hire, interview on shipping speed and judgment under ambiguity; for a platform hire, interview on how they'd design for a second and third use case they haven't seen yet.
- 4Don't hire platform-scoped seniority (and pay) for feature-scoped work; you'll either bore them into leaving or watch them gold-plate a feature that needed to ship in three weeks.
The transition point, and how to hire for it deliberately
The moment to bring in platform instincts is when a third team independently starts building something AI-shaped, that's the signal duplicated tooling is starting to cost more than a shared layer would. Don't wait until five teams are each maintaining their own retrieval pipeline to notice; but also don't hire a platform engineer on the strength of a single feature's roadmap slide. The scope of the hire should track the number of real, funded use cases, not the size of the vision deck.
