Seven Weeks to Southeast Asia

I want to tell you about a Monday morning in Southeast Asia, because it's the kind of evidence that's hard to fake.

A colleague of mine, Teryl, sat down with a translation team — mother-tongue translators, quality checkers, in-country trainers — and opened a tool we had built together. It was the first real deployment. First time with a real team in a real field context in Southeast Asia. She pressed start.

It worked.

That's not a small thing. What made it possible was a year of hard work that came before any of it. The team — Steve, Andy, Teryl, Amanda, and their broader network — had spent that year developing the methodology, designing the questions, building the agency partnerships, and establishing the framework. All of that was real and valuable. What it hadn't yet produced was a path from that knowledge to working software: no app, no proof of concept, no verified architecture, no single source of truth across the documents. A hard departure date. A team scattered across time zones. That gap — between rich knowledge and working software — is what seven weeks closed.

Here's the question I want to sit with you on: how does that happen?

Because if you've ever tried to build something complex with AI — really complex, the kind that involves multiple stakeholders and competing requirements and a deadline that doesn't move — you know the pattern. You have a great session. Things feel productive. The AI builds something. And then two weeks later you're explaining the same context again, correcting the same assumptions, undoing something you thought was already decided. The tool is fast. The collaboration is leaky.

The bottleneck in AI-augmented development isn't implementation. It's verification. And most teams never fix it because they can't see it.

---

Think about how you use AI today. You open it, ask it something, it answers. Maybe you ask a follow-up. Then you close it and move on. The next time you open it, it knows nothing about what you worked on before. You're always starting from scratch. It's useful — but each use is an island.

Now think about what it would mean for AI to be present at every stage of a project — and for each stage to build on the last. Not resetting. Compounding. The context from the first meeting informing the second. The decisions from the second shaping what gets built in the third. By the time you're ready to deploy, the AI knows as much as your team does — because it's been in every room.

That's what this project did. And the difference isn't subtle.

Before the first call, I uploaded everything: every framework draft, every survey instrument, every metadata spec — 20-plus documents that the team had accumulated over months. That became the baseline. During the call itself, I copy-pasted the live transcript into the system in real time, chunk by chunk, as the conversation unfolded.

The AI wasn't a tool I used after the meeting. It was in the meeting. Reading what was being said as it was said, building against the baseline that was already loaded.

By the time we hung up, we had a working prototype. Not a plan for a prototype. A prototype. And the team had stopped talking about what they wanted and started reacting to what existed — which is a completely different kind of meeting.

---

Here's what I've noticed about the moment when something concrete appears on screen while a team is still talking.

Before the prototype: everyone is planning. Planning conversations produce intentions. People describe the shape of the thing they're imagining, agree on things that aren't actually specific enough to act on, and leave feeling productive. The decisions evaporate by Thursday.

After the prototype: the conversation grounds. Teryl immediately named a delivery constraint that appeared in none of the 20 documents. Steve said, out loud, that respondents should never see scores — something the prototype had gotten wrong, and something he might not have articulated until a real respondent saw a number they weren't supposed to see. A requirement for routing reports to different partner organizations surfaced near the end of the call, almost as an afterthought, because Teryl was looking at something real and noticed what was missing.

That's what stacking looks like in Session 1. But the real compounding happens between sessions.

After every meeting, we ran an Epistemic Surface Extraction — ESE — comparing what was built against what was said, and what was said against what the documents required. Session 1 surfaced 14 specific tensions before the next session started. Session 2's ESE pre-identified 8 more before the team's written feedback even arrived. By Session 3, three rounds of capture and verification had resolved enough contradictions that a listening session — no building, just gathering — produced a build spec clean enough to hand to an AI code builder.

Lovable built the full progressive web app in approximately one hour.

Each session had stacked on the last. The AI that built the app in an hour wasn't working from a first draft. It was working from the accumulated clarity of every session that came before it. That's compounding. And it only happens if you treat each meeting as an input to the next one — not as a standalone event.

---

By Session 3, something had shifted.

Three sessions of ESE and encoding had resolved the major contradictions. The canonical source had been consolidated from 19 documents to two. The architecture decisions — puzzle model with role-specific links, no scoring shown to respondents, questions as a swappable data layer, print forms as a first-class workflow for low-tech contexts — were locked in and verifiable.

So I made a different call for Session 3. No live build. I just listened.

Andy named it later: "I prefer that you listen and kind of gather all of it, and then the next thing takes into account the whole meeting."

The team refined the authentication model. Confirmed the multi-language hierarchy. Steve stated his data normalization requirements. Teryl identified that the role labels wouldn't be recognizable to respondents in Southeast Asia and proposed a two-question approach that would let people self-identify without requiring them to know our internal taxonomy.

After the session, I converted the transcript into a build spec. Then I fed that spec to Lovable.

The full progressive web app — role-specific survey links, print form generation, CSV export, media upload for scripture passages, authentication, multi-language hierarchy — was built in approximately one hour.

One hour.

I want to be careful here, because I've seen this kind of claim before and I know how it sounds. So let me be precise: the hour was not fast because Lovable is fast. It was fast because the spec was unambiguous. Three sessions of verification had done the disambiguation work before the first line of code was written. The builder doesn't have to guess when the spec is clean. And when the builder doesn't have to guess, the hour is real.

What does this mean for how you work? If your AI-augmented builds keep taking longer than you expect — if you keep rebuilding things you thought were done — the problem is almost certainly upstream. The spec you're feeding is still ambiguous. The decisions you think were made haven't been verified. The sessions are overhead instead of the work itself.

---

Here's where it gets honest.

Teryl landed in Southeast Asia, sat down with the team, and discovered things that four sessions of careful work had not surfaced.

The project/assessment hierarchy didn't match the cluster model the team had intended. Language identity appeared at the project level instead of the assessment level — so there was no field to specify which language an assessment belonged to. She worked around it by putting language information in the Scripture field.

Every translator had to fill out project-level metadata — team formation, education levels, role composition — individually before they could reach the actual survey questions. This held everyone up. Daniel, the director of training at the managing partner organization, named this as his number one piece of feedback. It wasn't a small thing.

The role taxonomy had no category for quality checkers, in-country trainers, or QA mentors — roles that exist between translator and consultant in this organization's structure, all of whom contribute to translation quality and can assess it. She directed them to the translator questions as the closest fit.

None of this is a failure of the system. It's the honest boundary of what pre-flight instruments can see. ESE catches structural drift. Dry runs catch behavior. Field deployments catch reality. You need all three, and each one surfaces things the others cannot.

What the field validated: the tool worked. Pastor and consultant surveys were completed. The community pastor for the Sela language produced encouraging data about use and impact in his congregation. The teams chose paper forms for village surveys — which is exactly what they were designed for. In many field contexts around the world, paper isn't a backup. It's Plan A. We had designed it that way deliberately, knowing that low-tech and no-tech solutions need to be first-class citizens of the tool, not afterthoughts. In an AI world, we assume paper can't coexist with the fancy app. It can. But it has to be intentional.

Teryl shared a vignette from that day that I keep coming back to. One of the village pastors had come in specifically for the 3D Review. He had no laptop. No smartphone. When the younger participants started pulling out their devices, she could see it on his face and in his body language — what she described as "deer in the headlights, and shame." He wanted to contribute. He just felt swamped by the technology around him.

When she said they could do it on paper, the relief was immediate and unmistakable.

He wasn't overwhelmed by the task. He was overwhelmed by the delivery mechanism. And because paper had been designed in from the start — not as a contingency but as a legitimate path — he could participate fully, with his dignity intact. That's what intentional low-tech design actually looks like in the field. Not a workaround. A welcome. On Tuesday, Teryl observed the teams and confirmed that what they had reported in their surveys matched what she saw them doing in practice.

Teryl's bottom line, from her field notes: "I think we have a viable tool."

---

I want to be fair here. The problems we found in Southeast Asia — the hierarchy mismatch, the metadata burden, the role taxonomy gaps — those exist in every project. The question is when you find them.

In most AI-augmented development, you find them in the field. Or worse, after the field, when someone tries to analyze data that isn't structured the way they expected.

That's because the default process looks like this: meetings happen, things feel productive, the AI builds something, nobody stops to verify what was actually decided, the next session rebuilds context that evaporated since the last one, and the implementation reflects the accumulated ambiguity of every handoff that wasn't cleaned up.

The tool is powerful. The process is leaky. And the leaks compound.

What made the difference here wasn't a better AI. It was a different relationship with verification. Every session produced a record before memory degraded. Every record was compared against what the documents actually said. Every contradiction was surfaced before it could become technical debt.

The sessions were the work. Implementation was the output.

---

I should name the tool I was using, because it's relevant — and because I want to be honest about both sides of it.

oddkit is the knowledge server I've been building: a queryable canon of decisions, constraints, and learnings that persists across sessions and surfaces relevant context on demand. When a decision was made during a session, it was encoded into oddkit before the meeting transcript went cold. When the next session started, I oriented against the current state. When the build spec was being written, oddkit's constraints governed its structure.

What it unlocked: decisions that would have evaporated — the kind that get made verbally and then silently contradict the next build — were instead locked as verifiable records. When a new session started, the system already knew what had been decided. I didn't have to re-explain. The AI didn't have to guess.

What it didn't do: it didn't predict that the translator metadata would hold up the entire team on Monday morning in Southeast Asia. It didn't know that Beyond Translation has three distinct roles between translator and consultant that the taxonomy had no category for. It didn't anticipate that denominational leaders operate at the cluster level, not the language level, making the data model structurally wrong for a specific class of respondent.

These are not failures of the tool. They are the honest boundary of what any pre-flight instrument can see. The field is irreplaceable. What oddkit ensured is that the team arrived in Southeast Asia with a working tool, a clean record, and enough verified decisions that the gaps Teryl found were fixable — not catastrophic.

---

I want to close with Teryl's phrase, because I think it's the right frame.

Viable. Not finished. Not perfect. Viable.

The community surveys are still outstanding — deferred to April 30 because of Easter and a major national holiday. The role taxonomy needs work. The cluster/language hierarchy needs a structural fix. The metadata burden needs to be moved upstream so respondents aren't filling out project-level information individually.

These are the next version's problems. They are also evidence that the system worked — because they were found in Southeast Asia, not in a conference room six months later, and they were found by someone who had a tool in her hands that was functioning well enough to reveal where it needed to go next.

That's what verification buys you. Not a perfect first deployment. A field-ready one — where the gaps you find are the productive kind, the kind that tell you what the next version needs, not the catastrophic kind that tell you the whole thing was built on the wrong foundation.

Here's what I keep coming back to: the most expensive failure mode in AI-augmented development isn't a bad AI. It's a good AI executing a bad spec confidently. Because speed and confidence without verification don't just fail — they fail at scale, compounding every ambiguity that wasn't caught upstream.

This is one engagement. We'll do more. But the pattern held clearly enough here to be worth studying — and worth sharing before it's been replicated a dozen times, because that's how useful things get built: in the open, while they're still being tested.

The question I'd ask you is this: in your last complex AI-augmented project, when did you last stop and ask — what did we actually verify? Not what did we say. Not what did we plan. What did we put in a form that could survive the handoff?

If you don't have an answer, that's where to start.

---

This essay is based on a real engagement. Session transcripts, ESE documents, a dry run meeting record, and Teryl's field notes — recorded by voice memo in real time during the field deployment, March 23–24, 2026 — were the primary sources. The build-spec-to-Lovable timing (~1 hour) is reported from the builder's account. Community survey data is still being collected; full results expected by April 30, 2026.

For the security of field workers and the language communities they serve, the names of specific countries, languages, and individuals have been changed throughout this piece.