Industry brief
What GenAI changes when you put it into production
Demos have not kept pace with generative AI. Here’s what engineering leaders should design when programmes have to run.
Technology organisations are building into a stack that has shifted underneath them. Demand is not simply “more data scientists” or “someone who has used ChatGPT.” It is a new blend of software engineering, model literacy, evaluation discipline, and product judgement — often inside the same operating week.
The quiet restructuring of engineering work
In product and platform teams, generative tools are no longer optional overlays. They are part of how code is written, tested, documented, and supported. That does not replace engineering skill. It raises the bar for how people interact with systems they cannot fully inspect.
Leaders who design only for traditional credentials miss people who can design retrieval pipelines, question model output, and teach peers how to use new workflows without compromising security or quality. AI literacy in IT is not a prompt hobby. It is the ability to read what systems surface and still own the human decision.
Where GenAI programmes feel the pinch
Shortages concentrate in roles that sit between the model and production:
- LLM and application engineers who can ship retrieval-augmented generation, tool use, and guardrails inside existing products.
- MLOps and platform talent who keep evaluation, cost, latency, and rollback as first-class concerns.
- Evaluation and quality profiles who translate “it feels good” into test sets, red-teaming, and production monitoring.
- AI product and domain specialists who connect use cases to data, risk, and the work engineers actually do.
These are not interchangeable “AI” workstreams. Each cluster has a different scarcity curve, cost profile, and ramp time. Treating them as one funnel is how organisations overpay for the wrong fit and under-engineer the real bottleneck.
Why conventional programme briefs fail
Many specifications still list tools and years of experience as if that guarantees performance. In GenAI programmes, the differentiator is judgement under constraint: how someone handles incomplete data, how they escalate, how they document, and how they protect customers when models hallucinate or costs spike.
A serious production brief for AI and GenAI should answer four questions before the first sprint:
- What decision does this person own in the first 90 days?
- Which risks must they prevent — quality, security, cost, or compliance?
- What systems and stakeholders will define their daily reality?
- Where is flexibility acceptable, and where is production ownership non-negotiable?
Core and surge: different risk profiles
Surge capacity remains essential for spikes, proofs of concept, and specialised model work. But temporary cannot mean “lower bar.” In AI programmes, a weak contribution damages trust faster than an empty roster.
Core ownership should concentrate on architecture, evaluation culture, and institutional knowledge — platform leads, security partners, product owners. Surge specialists can extend capacity around that core when the work is well defined and onboarding is intentional.
What leaders should do now
1. Rebuild role families around outcomes, not job titles. Map scarcity by cluster: LLM applications, evaluation, MLOps, data for AI, and AI product leadership.
2. Invest in realistic timelines. Production GenAI does not appear on commodity timelines. Architecture and interview processes must reflect that, or managers will invent workarounds that increase risk.
3. Pair delivery with capability building. Adding people alone will not close every gap. Upskilling existing engineers in evaluation, retrieval, and secure tool use reduces pressure on the external market.
4. Choose partners who understand production AI. An IT partner that treats GenAI like a generic office project will send volume. One that understands models, platforms, and delivery will ship systems that can stay.
Our view
The organisations who will ship well in AI and GenAI are not the ones talking loudest about “future skills.” They are the ones who design with engineering honesty — matching systems to the real work of products, platforms, evaluation, and cost.
We help technology organisations get that match right: surge where flexibility protects continuity, core where ownership matters, and always with a clear picture of what good looks like on day thirty — not just day one.