Main ideas & lessons conveyed

Broken window theory (and the opposite)

• The example shows how neglect leads to gradual deterioration:
  • One window breaks, people don’t care → more windows break over time → eventually the whole building looks unmaintained and unattractive.
• The “opposite” strategy is repair immediately:
  • Each time a window breaks, repair it right away → the building remains in good condition.
• Tech/learning lesson: don’t let small issues accumulate—address problems early.

Using AI in engineering/IT education—boosts productivity, but discipline matters

• AI can increase productivity and speed:
  • Tasks that might take months can be done in days.
• Key concern: over-reliance can weaken students’ ability to solve problems on their own:
  • If students submit assignments entirely generated by AI without learning, then when AI is removed, they can’t solve tasks.
• Recommended use:
  • Use AI as a study partner by asking:
    • “why,” “what,” “how,” and what the solution means.
  • Treat AI as a multiplier for learning progress:
    • Skills grow as students guide AI and understand its outputs.
  • Students must not only aim to “finish,” but to understand.

AI-assisted debugging vs manual debugging

• Real-world debugging often involves issues across multiple areas, and humans face limited time/deadlines.
• AI can help beginners find problems faster (hours instead of days/weeks), reducing downtime.
• Best practice:
  • Use AI to help locate and understand problems, then learn the reasoning.
  • Ask AI to explain:
    • the root cause
    • prevention steps

Hallucinations and “direction”

• AI may produce incorrect/irrelevant results (hallucinations).
• Students must direct AI carefully with clear requirements.
• Recommendation: build applications in stages
  • Don’t generate a huge app all at once (e.g., “100 pages”).
  • Instead, complete and review page/feature-by-feature.
  • Staged review makes it easier to catch mistakes and limits hallucinations.

Understanding code AI generates

• Even if AI writes code, students must still learn what the code does.
• If AI generates code in a language you don’t know (e.g., you learn PHP but AI generates JavaScript):
  • you must learn the missing knowledge, or at least ask AI to explain purpose and usage.
• Don’t only “accept and run”:
  • Ask questions until you understand:
    • “Why is it like this?”
    • “What is this code for?”
    • “Explain until I understand.”

AI can perform visual testing, but token usage can be costly

• AI can be used to operate computers / interact with apps through visual actions (e.g., open browser, click login, press buttons).
• Cost concern:
  • Visual testing uses more tokens than non-visual tasks.
• Practical advice:
  • In school: use free tiers when practicing.
  • In workplaces: the company usually provides AI access.
  • To save tokens:
    • Choose the right model
      • expensive models for difficult/hard logic
      • cheaper models for simpler tasks (e.g., UI/web page display)

Documentation is required for maintainability

• If developers create code without documentation, future maintainers may:
  • be confused about how the system works
  • decide to rewrite the app from scratch
  • waste time and incur higher costs
• Documentation supports continuity when teams/jobs change.
• Lesson: documentation helps others (and future you) continue and extend the system.

Closing message about AI use

• AI should not be used to “throw tasks” to AI.
• Use AI as a learning partner that grows skills.
• Avoid becoming overly dependent—future AI availability can’t be guaranteed.

---

Methodology / instruction lists

A) Immediate repair strategy (broken window opposite)

• When a problem appears (a “window breaks”):
  • Repair immediately
  • Do not ignore small failures
  • Repeat the same response each time a new issue occurs
• Expected outcome:
  • The system stays in good condition rather than progressively degrading.

B) How to use AI effectively as a learner (avoid over-reliance)

• Use AI to:
  • generate guidance and suggestions
  • support learning through explanation
• For each AI output, ask:
  • Why is this approach used?
  • What is the purpose of each part?
  • How should it be applied?
• If you don’t understand code:
  • ask AI to explain until understanding is achieved.
• Build skill growth behavior:
  • don’t just submit completed outputs
  • treat AI as a multiplier for concepts you also learn

C) Debugging with AI (faster learning + real understanding)

• Use AI to help identify:
  • where errors happen
  • why errors happen
• Don’t wait long for deadlines:
  • aim for fixes in hours, not days/weeks
• When debugging, ask AI for:
  • root cause
  • steps to fix
  • how to prevent the same problem later

D) Prevent hallucinations (staged building + directed prompts)

• Direct AI with clear requirements (don’t let it “do whatever it wants”).
• Build applications in stages/features:
  • review after each small portion
  • avoid generating everything at once for massive outputs
• If hallucinations occur:
  • correct the requirements and re-direct AI
  • limit freedom by specifying structure and expected behavior

E) Saving AI tokens (model selection)

• Recognize there are:
  • expensive models
  • cheap models
• Use:
  • expensive models for complex/hard tasks (e.g., difficult logic)
  • cheap models for simpler tasks (e.g., basic UI/web display)
• Be aware:
  • visual testing costs more tokens than non-visual tasks
• For school practice:
  • use free options when possible

F) Documentation requirement (what to do / what happens if not)

• Do:
  • create documentation so others can continue your app
  • document how modules work, data structures, and what tables exist (example mentioned)
• Don’t:
  • ship code with no documentation
• If documentation is missing:
  • future maintainers may rewrite from scratch
  • confusion and costs increase

G) Assignment instructions (from organizers)

• Create a summary video of the session
  • Content requirement: summarize insights/messages from the resource person (Kak Eko)
• Format:
  • can be posted as Reels/fit (creativity encouraged)
  • can be:
    • talking video (face optional), or
    • presentation-style (not too “PPT-like”)
• Length:
  • minimum 1 minute
  • maximum 2 minutes
• Upload requirements:
  • Upload to Instagram (Fit/Reels preferred)
    • Tag @direktoratsmk (blue tick)
    • Use hashtags including:

      • SteamTrainerCompetition

      • SteamTrainer

      • SteamVocationalSchool

      • Steam5M

      • plus an online training / “stamprener” session tag for Session 3
  • Also upload to Google Classroom
    • Facilitators will assess feasibility and whether the task was completed
• Deadline:
  • due by Thursday (latest); submit by tomorrow if possible
• Scoring idea mentioned:
  • better presentation/appearance may earn extra “stars”/bonus points

---

Speakers / sources featured (identified)

• Brother Eko (main resource speaker)
• Sis Elva (host/organizer; gave assignment instructions)
• Sis Elfa (participant/organizer; managed chat and question selection; also mentioned as writing in chat)
• Anis (participant who asked a question)
• Artika (participant who asked a question alongside Anis)
• Muhammad Ben Akil Akbar (participant from SMK 4 Kendari)
• Aisyah Amin Abidah (participant from SIBSA team)
• Muhammad Zarfai (participant from SIBSA team)
• Ahmad Danang Widiantoro (participant from State Vocational School 1 Rejo Tangan)
• Bastian (participant from SMK Ananda Mitra Industri; referenced as Nanda Mikraas)
• Joko Imam / Coach Joko Imam (IT facilitator/coach; added assignment/checking instructions)

Schools/teams mentioned as sources of questions

• SMKN Pengaran
• SMK N1 Kuwus (spelled in subtitles)
• SMK 4 Kendari
• Salafiah IT Vocational School (spelled in subtitles)
• SMK Karya Nasional Kuningan
• Bastian / SMK Ananda Mitra Industri
• State Vocational School 1 Rejo Tangan (spelled in subtitles)
• SMP Negeri 2 Kerinci
• SIBSA team