Overview

New engineering specializations are emerging. These are disciplines that didn't exist five years ago and will be core competencies by 2028. They require different skills, different thinking, different practices than traditional software engineering.

If your organization doesn't have people developing expertise in these areas, you're behind. Not catastrophically, but noticeably. Your competitors are getting smarter at building with AI while you're still treating it as a feature.

AI Engineering: Building Systems With Models as Components

AI Engineering is the discipline of building systems where AI models (language models, image models, code models) are core components.

This is distinct from ML Engineering. ML Engineers train models. AI Engineers build systems using models. Both are valuable; the distinction is useful.

What AI Engineers Do**

Select the right model for the task: Claude for reasoning, Llama for on-device, custom fine-tuned models for domain-specific work. Understanding model trade-offs is crucial.

Design effective prompts: not just "write code" but "write code following this architecture pattern, using these libraries, with these error handlers." Good prompts are powerful. Bad prompts waste tokens and time.

Chain multiple models: one model for understanding the query, another for generating code, another for validation. Orchestrating models is an art.

Handle failures gracefully: models make mistakes. Hallucinate. Refuse tasks. Timeout. Good AI engineers design systems that degrade gracefully, not crash.

Optimize for cost, latency, and quality: Use cheaper models when possible. Cache results. Batch requests. Balance quality against resource consumption.

Build and maintain RAG/retrieval systems: integrate external knowledge so models have facts, not guesses.

Monitor model behavior in production: accuracy, latency, failure modes, user satisfaction. Models degrade silently. You have to watch them.

Skills AI Engineers Need**

Deep understanding of language models: how they work, what they're good at, what they fail at. Not theoretical. Practical. "Can Claude do this task accurately?" You need to know.

Prompt engineering: the ability to write prompts that get consistent, high-quality results. This is a learnable skill that few people have yet.

API integration: working with model APIs (Claude, GPT, etc.), managing authentication, handling rate limits, costs.

Systems thinking: understanding how to compose models into larger systems. Error handling. Validation. Monitoring.

Data engineering: understanding how to prepare and structure data for models. Feature engineering for models is different from traditional feature engineering.

How to Build AI Engineering Capability**

Hire someone with deep LLM experience. Or grow it internally. Start with engineers who are curious, build projects with LLMs, learn through doing.

Share knowledge: have your AI engineers teach others. "Here's how to write better prompts." "Here's how to chain models." "Here's how to optimize costs." Build organizational knowledge.

AI Engineering is Young: There's no formal degree. No standard curriculum. You're building expertise by doing. Hire people who are curious, who are already experimenting, and who learn by building.

Prompt Engineering: A New Craft

Prompt engineering is the discipline of writing text inputs to AI models that get consistently good outputs.

This sounds simple. It's not. A one-word difference in a prompt can make a model's output go from useful to useless.

What Prompt Engineers Do**

Design prompts for specific tasks: "Write customer support responses in a friendly but professional tone, addressing the specific issue, offering a solution, and a next step." This is more than a template. It's a specification.

Test and iterate: try one prompt, see results, adjust. "That was too formal. Try adding 'be conversational.'" Iterating until results are good.

Create prompt libraries: Document good prompts. Why does this prompt work? What variations work? What breaks it? Build organizational knowledge.

Debug failures: A model is giving weird outputs. Is it the prompt? The data? The model? Prompt engineers are good at debugging these situations.

Optimize for efficiency: Use fewer tokens. Get the same or better output. A prompt engineer might rewrite a 500-token prompt as a 200-token prompt with better results.

Adapt prompts to different models: A prompt that works for Claude might not work for GPT. A good prompt engineer understands model differences.

Skills Prompt Engineers Need**

Writing skill: clear, precise language. Able to specify requirements unambiguously.

Understanding of model behavior: when models work well, when they fail. What can be prompted and what can't.

Iterative thinking: comfort with trying things, measuring results, adjusting. Not expecting first attempt to be perfect.

Domain knowledge: understanding the task deeply. A prompt engineer for customer support should understand support workflows.

Is Prompt Engineering a Long-Term Career?**

Probably not. As models improve, the need for elaborate prompting decreases. But in the next 2-3 years, as organizations scale AI, good prompt engineers are valuable.

Think of it like early HTML development. It was a specialty. Now every developer knows HTML. Prompt engineering will likely follow the same path.

Model Operations (ModelOps)

Just like DevOps manages code in production, ModelOps manages models in production.

What ModelOps Engineers Do**

Version and track models: which model version is in production? What data was it trained on? What's its accuracy?

Monitor model performance: is accuracy degrading? Are certain inputs failing? Are latencies spiking?

Manage model lifecycle: training, validation, deployment, monitoring, retraining.

Set up governance: which models can be used where? What's approved? What's risky?

Optimize costs: which model is most cost-effective for which task?

Skills ModelOps Engineers Need**

Systems administration: Linux, containers, Kubernetes, cloud infrastructure.

Understanding of ML/AI: not building models, but understanding how they work, what can go wrong.

Monitoring and observability: setting up systems to watch model behavior.

Data pipeline management: ensuring data quality, versioning, governance.

Other Emerging Disciplines

AI Product Management**

Traditional product managers work on features. AI PMs work on capabilities. "How do we build this in an AI-native way?" Different skill set. Requires understanding of AI possibilities and limitations.

AI Quality Assurance**

Testing AI systems is different from testing traditional software. You need: adversarial testing (trying to break it), bias testing (does it work equally well for all groups), safety testing (what bad outputs could it generate?).

AI Ethics and Governance**

As AI systems get integrated into critical decisions (hiring, lending, medical), governance becomes important. Someone needs to: audit models for bias, ensure compliance, manage risk.

Domain AI Specialist**

Expert in a domain (healthcare, finance, legal) who understands how to apply AI to that domain. Bridge between domain experts and engineers.

When This Goes Wrong: Discipline Failures

No AI Engineering Foundation**

You hire a prompt engineer but don't have anyone who understands systems, model selection, and architecture. The prompt engineer optimizes prompts, but the system still fails because of architectural problems (wrong model for the task, no error handling, no monitoring). Solution: hire an AI engineer first. They set the foundation. Then hire specialists.

Prompt Engineering Without Testing**

Someone writes what they think is a good prompt. Deploys it. Quality is 60% (outputs are sometimes good, sometimes bad). They never measured baseline or iterated. Solution: evaluate all prompts on a test dataset before deploying. Measure accuracy, consistency. Only deploy if quality exceeds a threshold.

ModelOps Invisibility**

You deploy a model. It works for 3 months. Then quality degrades silently. No one notices until customers complain. No one was monitoring. Solution: assign someone to ModelOps. Their job: monitor model accuracy, latency, failure rates monthly. Alert when metrics degrade.

Advanced Coordination: How These Disciplines Work Together

The real power emerges when these disciplines coordinate. Let's walk through a practical scenario: a fintech company building an AI system for trade analysis.

The AI Engineer scopes the problem: "We need to ingest market data, analyze sentiment from news and social media, and generate buy/sell signals." They decide this needs 3 models: one for sentiment analysis (lighter weight, higher throughput), one for technical analysis (deterministic rules plus learning), and one for final signal generation (rules-based to ensure explainability in financial contexts). Cost estimate: $2,400/month in API calls. Latency requirement: decisions must be generated within 30 seconds of new data.

The Prompt Engineer then works on the sentiment model. Raw LLM outputs are inconsistent, sometimes missing nuance, sometimes overthinking. She designs a prompt that: (1) provides context about financial sentiment vs. general sentiment, (2) includes 5 examples of strong positive/negative/neutral sentiment for financial markets, (3) requests structured JSON output with confidence scores. Initial quality: 71%. After 3 iterations incorporating financial domain knowledge, quality reaches 87%. The prompt is now 340 tokens instead of the original 180, but the improved accuracy saves 15 hours/week of manual review.

The ModelOps Engineer sets up monitoring. They establish baselines: 87% accuracy on a held-out test set. They log every prediction with metadata (timestamp, input characteristics, confidence). They set up alerts: if weekly accuracy drops below 82%, page someone. If latency exceeds 35 seconds in >2% of requests, investigate. Why these thresholds? Because trades need to execute fast; if analysis is slow or wrong, the system becomes a liability. They create a retrain pipeline that runs weekly with new data. After 6 months of monitoring, they notice accuracy degrades on Fridays during market volatility, the training data had low representation of extreme market conditions. They supplement training data and accuracy stabilizes.

The product team (AI PM) uses data from all three disciplines to make decisions: "Our sentiment model is reaching ceiling at 87% accuracy. Cost is $800/month. We could switch to a fine-tuned model that might reach 92% accuracy but costs $3,200/month. Is the 5% improvement worth 4x cost?" They analyze historical trades: of the 15 trades that lost money last quarter, 6 were due to sentiment misclassification. At $50K average trade size, that's $300K in losses. The $2,400/month additional cost (=$28,800/year) to prevent those losses is justified. They make the switch.

This coordination doesn't happen accidentally. It requires clear ownership, communication channels, and metrics that connect disciplines to business outcomes.

Case Study: Healthcare Startup Building AI Teams

A healthcare startup built an AI system to diagnose conditions from patient descriptions. They hired great engineers, but most had never worked with AI. They made these mistakes:

Mistake 1:** No AI engineer. Engineers built the system using whatever model seemed popular (GPT-4). No systematic evaluation of model fit. No cost optimization. Result: over-engineered, expensive. Monthly costs were $47,000 (running GPT-4 on every patient query). An AI engineer would have identified that a smaller, fine-tuned model could handle 70% of cases for $8,000/month, with GPT-4 only for complex cases. Annual savings: $468,000.

Mistake 2:** No prompt engineering rigor. Doctors wrote the prompts ("diagnose this patient"). Prompts were inconsistent. Results were unpredictable. In their test set of 500 cases, accuracy was 65% but wildly variable, 78% on obvious cases, 31% on ambiguous ones. Solution: hired a prompt engineer. She standardized prompts, added context (patient age, vital signs, symptom duration, relevant medical history), included reasoning instructions ("list 3 possible diagnoses, explain reasoning for each, then provide most likely"), tested variations. Quality jumped from 65% to 82%. More importantly, variance decreased; confidence intervals became reliable.

Mistake 3:** No ModelOps. They deployed and forgot. 6 months later, noticed accuracy had drifted to 71%. Why? The model's training data was from 2023. Medical knowledge had advanced. New diagnostic criteria existed. They weren't monitoring. Users reported the system was occasionally suggesting outdated treatments. Solution: assigned someone to ModelOps. She now: monitors accuracy weekly (comparing AI suggestions against confirmed diagnoses), tracks false positive rate (overly cautious suggestions), tracks false negative rate (missed serious conditions), reruns the prompt optimization quarterly with new medical literature, maintains a manual feedback loop with 3 senior doctors who review hard cases. Annual investment: $140,000 (1 FTE). Result: accuracy stabilized at 84% with <3% false negative rate on serious conditions.

Financial Impact:** Year 1 costs: $1.4M (salary + infrastructure). Result: 12,000 patient assessments, 87% of which required no doctor review (11,400 patients served with just AI, generating $2.1M in subscription revenue). Year 2, with all disciplines in place: same costs, but automation improved to 91%, generating $2.8M revenue. Year 3: added an AI PM who looked at usage data and identified that 18% of the assessments were for conditions the system wasn't confident in. Rather than force a diagnosis, they built a "escalate to doctor" path that preserves patient safety and increases user trust. Product NPS improved from 42 to 67. Enterprise customers (large hospital systems) started adopting because they could verify the system was safe and trustworthy.

Result:** By building AI engineering discipline, they went from "hope it works" to "we know it works, we can prove it, we can measure its impact, and we can improve it continuously."

Building These Capabilities in Your Organization

Start With AI Engineers

These are generalists who understand models and systems. Hire them or grow them internally. They're your foundation.

Identify and Develop Specialists**

As you scale, identify who in your organization has strong prompt engineering instincts. Who's good at operations? Develop them. Not everyone needs to specialize, but having some specialists accelerates progress.

Cross-Train the Whole Team**

Not everyone needs to be an expert. But everyone should understand: how models work, how to prompt them effectively, how to spot when something's wrong.

Create Communities of Practice**

Engineers experimenting with AI should share what they learn. Prompt engineers should share good prompts. ModelOps folks should share techniques. This builds organizational knowledge.

Invest in Learning**

These are emerging disciplines. There's no degree program. Invest in: courses, workshops, books, conferences. Send people to learn. They'll come back and teach others.

What to Do Monday Morning

• Assess your organization: do you have people developing expertise in AI engineering? Prompt engineering? ModelOps?
  - Identify gaps: which of these disciplines are you weak in?
  - Plan hiring or development: do you need to hire specialists? Or grow them internally?
  - Start a project: pick one AI initiative. Assign an AI engineer to lead. Have them experiment, learn, share what they discover.
  - Create forums: Slack channel, office hours, brown bag sessions. Build communities around these disciplines.
  - Document and share: when someone learns something about prompting or models, capture it. Share with the team.
  - Measure impact: are these disciplines making your organization more capable with AI? How?

FAQ

Q: Do we need to hire AI engineers, or can current engineers learn this?**

A: Both. Your best engineers can learn AI engineering if they're curious and willing to invest time. But hiring someone with experience accelerates learning. Ideally: hire one experienced AI engineer. Have them teach others.

Q: Is prompt engineering a real job or just marketing?**

A: Real, but temporary. In 2026, good prompt engineers are valuable. In 2028, models will be better at understanding intent and the job will be less critical. Think of it like "HTML developer" in 1998, real, but the role evolves as technology improves.

Q: What's the difference between AI engineering and ML engineering?**

A: ML engineers build models (data prep, training, evaluation). AI engineers build systems using models. A company might have 5 AI engineers for every ML engineer. Both are needed but for different things.

Q: How do we know if someone is good at AI engineering?**

A: Give them a real AI problem. Can they scope it? Can they identify the right approach? Can they prototype quickly? Can they think about failure modes? Give them something to build. See how they approach it.

Q: Should we certify people in these disciplines?**

A: Not yet. There's no standard curriculum or certification body. In 2-3 years, probably yes. For now, certifications don't mean much. Look for: projects they've built, results they've shipped, knowledge they can articulate.

Q: How much should we invest in each discipline?**

A: Start with 1 AI engineer for every 4-6 software engineers. Hire prompt engineers only after you have AI engineers and projects mature. For ModelOps, hire 1 for every 3-4 deployed models. Adjust based on complexity and criticality. A fintech company might need more ModelOps oversight than a internal tool team. A content company might need more prompt engineers. Size teams to match your risk tolerance and scale.

Q: Can one person wear multiple discipline hats?**

A: Early stage, absolutely. A strong engineer can do AI engineering and ModelOps simultaneously. But as systems scale and complexity increases, specialization becomes valuable. At 5+ models in production, you need dedicated ModelOps. At 10+ different AI workflows, you need a prompt engineering team. Don't force specialization too early, let it emerge naturally as scale demands it.

Q: What's the biggest mistake in building AI teams?**

A: Assuming traditional software engineers will automatically be good at AI engineering. They won't. The skills overlap but the thinking is different. Software engineering: build reliable systems from specifications. AI engineering: handle uncertainty, manage model tradeoffs, iterate on behavior. You need people who can think probabilistically about systems, not just deterministically. Hire for learning agility and curiosity about AI. Experience matters less than the right mindset.

New engineering disciplines are emerging: AI engineering (building systems with models), prompt engineering (designing effective inputs), model operations (managing models in production), and others. These disciplines require different skills than traditional software engineering. Your organization needs people developing expertise in these areas. Start by hiring or growing AI engineers. Invest in learning. Create communities of practice to share knowledge. Build organizational capability intentionally. By 2028, these disciplines will be table stakes.

On This Page

Watch the Lecture
AI Engineering
Prompt Engineering
Model Operations
Other Disciplines
Failure Modes
Case Study
Building Capability
Monday Morning Action
FAQ

Chapter Details

Part ofChapter 4