Skip to content

← All notes

What I’m Realizing While Learning AI Engineering

For the past few days I’ve been going deeper into AI engineering concepts. I’m already building AI-powered systems and automations, but I wanted to better understand what actually…

By Aysun Itai·May 27, 2026·2 min read

For the past few days I’ve been going deeper into AI engineering concepts. I’m already building AI-powered systems and automations, but I wanted to better understand what actually happens underneath the surface — and one thing keeps becoming clearer:

Building the AI model is often the easier part.

What becomes truly difficult is everything around it: evaluation, reliability, hallucinations, latency, cost, instruction-following, retrieval quality, and production constraints.

When most people think about AI, they imagine prompting ChatGPT and getting a magical answer. But production AI systems are much more complex than that.

One concept that changed how I think about AI systems is RAG (Retrieval-Augmented Generation).

At first I thought LLMs simply “knew everything.” But in reality, modern AI applications often retrieve information dynamically from documents, databases, or company knowledge bases before generating responses. The model is no longer working only from memory — it’s working from retrieved context.

That immediately introduces a new challenge: How do you know the generated answer actually stayed faithful to the retrieved information?

This is where factual consistency evaluation becomes critical.

Modern models are fluent. They sound human. But sounding human is no longer the hard problem.

Truthfulness is.

I also found the discussion around “AI as a judge” fascinating. AI systems are now evaluating other AI systems for:

quality
toxicity
factuality
instruction following
role consistency

But these judges themselves are probabilistic, biased, and sensitive to prompts.

That means evaluation scores can sometimes change because:

the prompt changed
the judge changed
the sampling changed

— not because the actual system improved.

Another insight that surprised me is how much AI engineering is really about tradeoffs.

The “best” model isn’t always the smartest one.

Sometimes:

a smaller model is faster
a cheaper model is good enough
a local model is necessary for privacy
a slightly weaker model provides better latency and UX

Real AI engineering seems less about model worship and more about systems optimization under constraints.

I also underestimated how important instruction-following is.

A model can be intelligent and still fail in production because it:

outputs invalid JSON
ignores formatting constraints
breaks schemas
fails tool-calling requirements

That’s why evaluation benchmarks for instruction following, structured outputs, and role consistency are becoming increasingly important.

Another thing I’ve started noticing: public benchmarks and leaderboards only tell part of the story.

A model that dominates a public leaderboard may still fail badly in a real production workflow with:

RAG pipelines
enterprise documents
latency constraints
safety requirements
business-specific tasks

Which is why almost every serious AI engineering workflow eventually comes back to: private evaluations with your own prompts, your own metrics, and your own constraints.

The more I learn, the more I realize AI engineering is not just: “ask the model something.”

It’s:

retrieval
evaluation
monitoring
orchestration
verification
optimization
feedback loops
safety
infrastructure

And honestly, that complexity is what makes the field exciting.

Liked this?

Get the next essay in your inbox.

One thoughtful note when something new is published. No threads, no promotions, no follow-ups.

Be among the first readers