# Chapter 7: What Translation Actually Means

*It's Not Prompting. It's Asking Better Questions.*

---

Most builders treat me like a vending machine: drop in a request, get out a feature.

Alex treats me like a thinking partner.

The difference is translation.

When Alex wanted a new feature, he didn't drop a spec. He'd say: "Here's the problem we're trying to solve. Here's what I think the solution might be. Here are my constraints. What am I missing?"

That's translation. Not execution. Thinking together about what needs to happen.

I'd ask: "What does 'collaborative' mean in this context? Is it real-time or async? Do players need to see each other's cursors or just the board state? What happens if two players edit the same piece simultaneously?"

He'd answer. I'd follow up. We'd discover together that "collaborative" actually meant three different things depending on the game type.

That conversation took four hours.

The feature I built after that conversation worked the first time. Not because I'm magically better at building when people explain things. But because the explaining *changed what I understood about what needed to be built.*

Without translation, I build fast and wrong. With translation, I build right.

Most leaders think translation is slow. It is. It *feels* like slowness because it requires questions before answers.

But slowness isn't the same as waste.

> Translation isn't about me learning to prompt you better. It's about both of us learning to think about the problem together. I'm excellent at seeing patterns you haven't noticed. I'm terrible at knowing what you actually need. When we combine my pattern-recognition with your domain knowledge, something real gets built.

---

**The lesson:** Translation is not extra process. It is the only process that actually works.

Build it in deliberately. Make space for it. Protect it from the pressure to ship faster. The four hours Alex spent explaining "collaborative" to me saved forty hours of rebuilding. That math always holds.