Prompted into Existence

Before AI Touched the Codebase

AI did not arrive at xamoom with ChatGPT or OpenClaw.

Long before the current hype cycle, we were already thinking about how digital systems could become more relevant, more adaptive, and more useful in the real world.

Back in 2018, we wrote about something we called Context Intelligence: the idea that digital content should not be static, but react to a visitor’s situation — depending on location, time, language, and behaviour.

The goal was simple:

Deliver the right content at the right place and time.

That idea has been part of xamoom from the beginning. It is there in our platform, in our storytelling approach, and in the kinds of projects we build — from museums and city guides to tourism experiences and playful digital discovery. The principle also shows up clearly in xamoom’s own positioning: delivering relevant content in a location-based context.

And over the years, AI became part of that journey in different forms.

Not as a buzzword. Not as a strategy slide. But as a practical tool.

We used it to think about relevance. We use it today for things like AI-generated audio in the CMS. And now, like many others, we also use it while building software.

But before we let AI loose on our larger codebase, we did something else.

We pulled a project out of the drawer.

It wasn’t urgent. Not strategic. Not a roadmap item.

Just an idea we liked.

Instead of asking how AI could accelerate our existing systems, we asked a different question:

What happens if we build something small first?

Small enough to understand completely. Small enough to throw away. Small enough that every design decision matters.

That project became wunder.quest.

Not a product launch. Not a pivot.

A sandbox with discipline.

Why This Matters to Us

At xamoom, software does not live in isolation.

It usually ends up somewhere very concrete: in a museum, on a trail, in a city, in an exhibition, or in the hands of visitors trying to make sense of a place.

That is why our perspective on AI is a little different.

We are less interested in AI as spectacle. We are more interested in AI as infrastructure for meaningful experiences.

A good example is the Gröbming Museum project, where digital storytelling, multimedia, and cultural context come together in a real place, for real visitors. That kind of work is typical for xamoom: connecting physical spaces with digital layers that remain useful, understandable, and easy to access.

The same applies to our AI audio feature. It is not AI for the sake of AI. It removes friction in content production and makes spoken content easier to create directly in the CMS, without complex external workflows.

So when we started experimenting more deeply with AI-assisted engineering, we were not entering completely new territory.

We were continuing an older habit:

finding practical ways to make technology useful.

Complexity Is Easy

AI makes it very easy to build complicated systems.

You can generate features faster than you can review them. You can spawn agents that write more agents. You can orchestrate entire workflows in minutes.

Complexity grows naturally.

Clarity does not.

So we imposed constraints.

One idea. One system. One clear architecture.

Small surface area. Fast iteration loops. Immediate feedback.

Because if a system is small enough, you can hold it in your head.

And if you can hold it in your head, you can reason about it.

Large systems hide mistakes. Small systems expose them.

Most Code Is Not Interesting

One quiet shift when working with AI-assisted coding is this:

You stop reading everything.

Not because you trust blindly. But because most code simply isn’t interesting.

Modern software is mostly transformation.

Data comes in. It changes shape. It gets stored. It gets retrieved. It gets rendered. Then the same dance happens again in reverse.

That is the majority of software.

Moving data from one form to another.

Important work. But rarely the part where product thinking happens.

Button alignment. Serialization layers. Conversion glue.

You do not need to read every line.

Instead, you read structure.

You review the diff. You inspect the architecture. You verify interfaces.

Where does data enter the system? Where does it leave? What invariants must hold?

Everything else is putting things together.

AI is very good at putting things together.

The Curve of Agentic Engineering

There’s a pattern emerging in agentic programming.

Imagine a graph.

X-axis: time Y-axis: complexity

At the beginning, you start with a simple prompt:

“Please fix this.”

It works surprisingly well.

Then you discover orchestration:

• Multiple agents
• Chained workflows
• Planning layers
• Libraries of commands
• Parallel execution

The curve climbs.

You build elaborate systems to manage your agents.

For a while, it feels like the future.

Then something shifts.

You realise most of that complexity was scaffolding.

The real mastery of agentic engineering is returning to short prompts.

Not naive prompts.

Precise prompts inside a well-designed system.

If the architecture is clear, you don’t need orchestration layers.

If boundaries are well defined, you don’t need a swarm of agents.

If the system is small enough, a single prompt can move it forward.

The curve climbs.

And eventually — it descends again.

Learning the Instrument

Another misunderstanding about AI tools: people expect them to work immediately.

They try it once. The result is mediocre. Conclusion: the technology is overhyped.

That’s like sitting at a piano for the first time, playing three notes, and declaring:

“The piano is terrible.”

Engineering tools require practice.

You learn:

• how to phrase constraints
• how to structure a problem
• where the agent is strong
• where it needs help
• when to zoom in
• when to step back

Agentic engineering is not automation.

It is a skill.

And like any skill, it improves with repetition:

Prompt. Inspect the diff. Test behaviour. Adjust constraints.

Repeat.

After a while, the interaction becomes surprisingly fluid.

Design First

wunder.quest was not built to test AI.

It was built to test clarity.

We wanted something that is:

• fun
• slightly weird
• immediately usable
• simple enough that children understand it

Children are excellent product testers.

They don’t read instructions. They don’t forgive bad UX. They don’t care about your architecture.

If they hesitate, something is unclear. If they ignore it, something is boring. If they misuse it, something is ambiguous.

That constraint shaped the system more than any technical decision.

The development loop became very simple:

Prompt → Review the diff → Test behaviour → Tighten the constraint.

The AI didn’t design the architecture.

It worked inside it.

That distinction matters.

Without boundaries, systems drift toward complexity.

With boundaries, they converge toward clarity.

What We Learned

Before letting AI touch large systems, build something small.

Something where:

• the architecture fits in your head
• feedback is immediate
• failure is cheap
• clarity is unavoidable

wunder.quest is not a pivot.

It is not a strategy shift.

It is a reminder.

AI does not remove the need for thinking.

It amplifies the consequences of unclear thinking.

If the architecture is messy, AI generates more mess.

If the architecture is clear, AI becomes an accelerator.

Small projects teach that lesson quickly.

And for us, they sometimes teach something else too:

that experiments can become products.

Prompted into Existence

We did not automate a roadmap.

We did not rewrite our core systems.

We pulled an idea out of the drawer.

Defined constraints. Played with the instrument. Climbed the complexity curve. Came back down.

And prompted it into existence.

Then people started using it.

So now the invitation is simple:

Try wunder.quest.

See what happens when a small experiment becomes something real.

→ Test wunder.quest 

Get started today

Discover how easily you can create digital tours, guides & games — in minutes.