GenAI engineering

to blog

GenAI Engineering: From Designing AI to Building It

For me, GenAI engineering started with a simple question:

What happens when a UX designer goes beyond designing the AI experience and actually builds the system behind it?

I've spent much of my career thinking about users, workflows, interactions and services. Moving into GenAI engineering has added a completely different layer to that thinking.

It has changed how I design.

From prompts to systems

My early experiments with GenAI were mostly about prompting and exploring what LLMs could do.

That quickly wasn't enough.

A production AI experience needs much more than a good prompt.

It needs:

LLM → Data → Retrieval → Tools → Agents → APIs → Evaluation → Observability → Governance

I started experimenting with RAG, embeddings, vector search, multi-agent workflows, LangChain, Azure AI Foundry and Databricks to understand what happens behind the interface.

That was a turning point.

Building changed how I design

When you only prototype an AI experience, it is easy to assume that the AI will simply respond.

When you build it, you encounter the reality:

The model doesn't always have the right context.
Retrieved information can be irrelevant.
Agents can take unexpected paths.
Responses need validation.
Latency matters.
Data quality matters.
Errors need graceful recovery.
AI behaviour needs to be evaluated continuously.

These aren't just engineering problems.

They directly affect the user experience.

A slow AI response is a UX problem.
A hallucination is a UX problem.
An unexplained recommendation is a UX problem.
An agent taking the wrong action is a UX problem.

RAG taught me something important

One of my biggest learning areas has been RAG.

Instead of expecting an LLM to know everything, we can give it access to relevant organisational knowledge.

The experience becomes:

User question → Retrieve relevant information → Generate response → Provide evidence

But building this made me realise that the quality of the experience depends heavily on what happens before the LLM generates anything.

Chunking, embeddings, metadata, retrieval quality and evaluation all become part of UX.

The designer doesn't necessarily need to become a data engineer—but understanding these concepts makes it possible to design better AI experiences.

Multi-agent systems changed the mental model again

I've also been exploring multi-agent architectures for procurement.

Instead of asking one general-purpose AI to do everything, specialised agents can perform different tasks:

RFP Agent → Supplier Q&A → Evaluation → Contract & Compliance

This creates a new design challenge.

We're no longer designing only:

Human → Interface

We're designing:

Human → AI → AI agents → Tools → Data → Human

The experience becomes a system of interactions.

Engineering gives UX another dimension

I don't want to become an engineer instead of a designer.

I want to become a designer who understands enough engineering to build and challenge the things I design.

That changes the conversation with engineering teams.

Instead of asking:

"Can we build this?"

I can start asking:

"What is technically possible, what are the constraints, and how should those constraints shape the experience?"

That's a much more valuable conversation.

What's next

I'm continuing to explore the full GenAI lifecycle:

Design → Build → Evaluate → Observe → Govern → Improve

The goal isn't to build AI simply because AI is possible.

It's to find where intelligence genuinely improves the experience—and design the surrounding system so that it is useful, reliable, transparent and human-centred.