I went and did some instructing.

Through a contact I made when delivering a project to a Seoul National University lab, I ended up getting connected to a lecturing opportunity and taught AI usage and Workflow best practices to childcare center instructors.

The main topic I presented was essentially Prompt Engineering, specifically material adapted from Google's technical whitepaper with practical examples.

While preparing the lecture, I looked into administrative tasks at childcare centers and best-practice examples of AI use. There turned out to be far more document-writing and organizing work than I expected, including parent newsletters, childcare activity plans, various records, and informational notices.

So, drawing on the best-practice collection, I focused primarily on how to break tasks down and structure inputs to get the work done.

The main subject of the lecture was Prompt Engineering. It has an intimidating name, but simply put, it is the skill of figuring out how to structure and refine the inputs and instructions you give an AI in order to get the results you want.

One of the references I drew on was a technical whitepaper titled Prompt Engineering, written by Google's Lee Boonstra.¹

Many people still use AI in chatbot form and tend not to know how to apply it beyond that, so the session was largely explanatory in nature.

I talked energetically for about an hour and ten minutes, though I honestly have no idea how well it went.

I spent the first forty minutes going over concepts, then showed examples from other cities' AI best-practice collections and explained them using actual Prompt Engineering concepts.

At the very end, I showed a children's game I had delivered in a previous project, rebuilt using AI, as a concrete usage example.

The reaction was mixed: some people were clearly engaged, while others couldn't quite follow what I was saying. Even so, I exchanged contact information with a few local childcare center directors.

Getting out into the field, I found that people knew far less about how to use AI than I had expected.

In developer communities, the conversation is about how to run Agents using a model + Context + tools + Orchestration architecture, and then how to map out the full Harness structure alongside MCP and SKILLS.

Or in LLM development communities, most of the talk is technical: local model Fine-tuning, reasoning about model internals, and getting good at working with Harnesses. So even though there is plenty of discourse about how AI is structured and what it can do, stepping outside developer communities makes you acutely aware of just how large the information gap still is.

Where developer communities are talking about Agent Tool Calling, Cache Hits, and Context Management, the actual field is still dominated by people using AI as a chatbot.

I always notice this, but while reasoning about model internals and academic value in developer discourse is genuinely interesting, the things that get the strongest reaction are "cases where someone else used it and it really helped." That's also where the questions came from.

It made me think that most of the value users actually receive comes from Workflow integration and trust.

At the same time, I feel a certain self-deprecation. I want to build AI-native Applications or create Agents or LLM models, but what I mostly end up doing is translating these technologies for others.

Some days I connect a factory PLC; other days I implement an experimental procedure from a research lab as software. This time, I explained to childcare center staff how they could make use of AI.

What I care about is the technology itself, but the reason the market needs me is the translation role: explaining how that technology connects to real-world work in accessible terms.

Should I count myself lucky that at least this kind of work exists? I think it does exist, at least in part, because programmers are scarce in the regional market I'm in.