"A booth conversation at AI Fest 2026 in Iloilo turned into a hard look at what it actually means to 'know' something — as a teacher, and as a developer gating five AI agents' output."
The Booth, the Noise, and Two Teachers Who Asked the Right Question
I spent August 3–5 at AI Fest 2026 in the Iloilo Convention Center, exhibiting under KWADRA TBI Cohort 5, representing Syntaxure Labs. Three days of pitching, demoing, and explaining "governance over generation" to anyone who'd stop long enough to listen.
Somewhere in the noise, two women stopped by the booth. Both DOST scholars. Both physics teachers, working on their master's degrees. And — as it turned out — both building a startup of their own, called Dalubasa, focused on early childhood literacy.
They weren't there for the AI pitch. They wanted to talk about kids.
"Knowing How To Doesn't Always Mean Understanding It"
Their startup idea came out of something they kept seeing in their own classrooms: young learners can speak English fluently — but that fluency is often pure imitation. The words come out right. The grammar lands. But shift the context slightly, ask a follow-up question the kid hasn't rehearsed, and the understanding underneath isn't actually there.
They put it simply, standing right there at the booth:
"Knowing how to doesn't always mean understanding it."
Coming from two physics teachers, that line hit different. Physics is basically the discipline built around catching people who can plug numbers into a formula and get the right answer without having the faintest idea why the formula works. Every physics teacher has graded that exam — a student nails F = ma on every problem set, then freezes the second you ask what force actually means in a scenario they haven't memorized yet.
Turns out five-year-olds learning English and physics students learning mechanics are doing the exact same move: pattern-match the surface, skip the model underneath.
Which Is When I Remembered I Do This For a Living
I build software. More specifically, these days I mostly architect it — I run a multi-agent pipeline where one model scaffolds, another handles the genuinely hard parts, another does quick edits, another builds frontend UI, another reasons through tradeoffs, and I sit on top of all of it as the gating reviewer deciding what actually ships.
Which means what those two teachers described isn't just a kids-learning-English problem, or a physics-101 problem. It's my problem too — just one layer up. I'm not the one typing every line anymore. I'm the one deciding whether the line that got typed is actually right, and that call is only as good as how deeply I understand what's underneath it — not how fluently I can skim a diff and think "yeah, that looks fine."
Fluency and understanding look identical from the outside. A kid saying a perfect English sentence looks the same whether they understand every word or none of them. A pull request that passes CI looks the same whether the person approving it understands the failure modes or is just pattern-matching "this looks like code I've seen before." The gap only shows up under pressure — a follow-up question, an edge case, a context nobody planned for.
That's the expensive version of "looks right." And it's exactly the version that agent-assisted development multiplies, because now there's more fluent-looking output to gate, faster, than any one person used to have to review.
The Actual Lesson
I don't think the answer is "understand everything, all the way down" — nobody does that, ever. I don't understand Postgres's internals well enough to rebuild them, and I use Supabase daily anyway. The physics teachers don't re-derive quantum field theory before teaching torque.
The lesson is narrower than that, and more useful: know exactly which layer you're responsible for understanding, and don't let fluency at the layers above or below it convince you that you've got it covered. For a kid learning English, that's whether they know what the words mean, not just how they sound. For a physics student, it's whether they know why the equation holds, not just how to rearrange it. For me, sitting on top of a handful of models producing code I didn't type — it's whether I understand the architecture and the failure modes well enough to catch it when something fluent is also wrong.
Two physics teachers reminded me of that at a booth in Iloilo, in between demos, completely by accident. Sometimes the most useful thing at a tech conference isn't the tech.
Have you run into your own version of this — fluent output masking a gap in real understanding, whether in code, in a classroom, or somewhere else entirely? I'd like to hear it in the comments.
Top comments (0)