Using AI Well as a Developer: Sharing Session, Deck, and Demo

Junior developers were already using AI. Some used it well. Some pasted a problem into chat, accepted the first answer, and moved on.

I wanted the session to be simple: AI is useful, but it does not remove your responsibility as a developer.

You can let AI explain code, draft a change, write a test, or help debug. You still need to understand the answer, run the checks, review the diff, and decide if it is good enough to ship.

Open the deck -> Open the demo repo ->

The main idea

AI predicts what text should come next. It is helpful, but it can be wrong.

That is the most important idea in the session.

An LLM reads your prompt and predicts the next token, then the next one, then the next one. It does not always know the truth. It writes what looks likely.

Once developers understand that, their behavior changes. They stop treating AI like an answer machine. They start treating it like a fast assistant whose work needs review.

What the session covers

The talk moves from basic mental model to daily practice:

What an LLM is, in plain language.
What tokens and context windows mean.
Where AI helps in the developer workflow.
The difference between chat and an agent.
How project context, like CLAUDE.md, improves answers.
How to write a better prompt with role, context, task, and format.
How to verify AI output before using it.
What data should never be pasted into a public model.
How to use a small demo repo to practice the full loop.

The session is meant to be practical. I show bad prompts, improve them, and then check the result like a developer would on real work.

The demo

The demo repo gives the team a safe place to practice without touching production code.

The loop is small on purpose:

Read the existing code.
Ask AI to explain the part you need.
Ask for one small change.
Run the app or tests.
Review the diff before accepting it.

That is the real lesson. AI can help you move faster, but the developer still owns the result.

Open the demo repo ->

What I repeated

I repeated a few ideas because they are the ones that change daily habits:

Use English for technical work. Code, errors, docs, API names, and technical prompts should stay in English. Thinking and discussion can be in Thai. Do not translate error messages. Paste them as they are.
Always verify. AI is not wrong every time. That is why it is risky. It can be wrong in a confident way, so every useful answer still needs a check.
You own what you ship. AI is the assistant. The engineer is responsible for the code, the design, and the trade-offs.

The deck itself

The deck is a small build by itself. I wanted it to open in any browser, on any machine, even with no internet connection.

So the deck is a single HTML file:

The font is embedded, so the hand-drawn style works offline.
rough.js is inlined, so sketch-style boxes do not need a CDN.
Slides sit in one horizontal track and move like a canvas.
Arrow keys and space move through the deck.
F opens fullscreen.
Reduced-motion settings are respected.

No external dependencies. One file. It works in a meeting room, on a plane, or anywhere with a browser.

What I wanted the team to remember

I did not want people to memorize prompts.

I wanted them to remember a simple working posture:

Give AI clear context.
Ask for a small, reviewable output.
Check the answer before using it.
Never paste secrets or customer data into the wrong tool.
You are still the engineer.

AI can remove some boring work. It does not remove judgment.

Open the deck -> Open the demo repo ->