Manuel Odendahl uses LLMs as translation engines between languages and representations, rather than treating them as autonomous programmers.
2
Breaking a task into small translation steps produces useful artifacts such as summaries, scripts, RFCs, YAML, and GitHub issues.
3
Programming fundamentals still matter because they let engineers judge generated work, while detailed API knowledge can often be delegated to the model.
Summary
Manuel Odendahl presents a practical workshop built around using LLMs during ordinary software work. He recommends regenerating outputs, editing bad responses directly, clearing context often, switching models, creating task-specific system prompts, and summarizing useful conversations into documents that other people can read. His central idea is to treat models as translation engines. A meeting transcript can become topics, then technical details, then action points, then structured GitHub issues. Code and documentation can be converted into small, understandable representations, often through a generated DSL. Odendahl also demonstrates "world simulation", where a model reviews code as a reality TV show or pretends to be the application being built. He is enthusiastic about the speed, but honest about the risks of producing too many unfinished programs and getting trapped in rabbit holes. Fundamentals, judgment, language design, and knowing when to stop remain human responsibilities.
Regeneration and short contexts make model output easier to test
Odendahl says programmers often try one prompt, accept a good result, or abandon a bad one. He recommends regenerating several times because outputs vary in quality. He also suggests editing the model's response directly, so the model treats the corrected code as its own previous answer. Conversations should stay short, often three or four prompts, before the useful output is copied into a new conversation. This makes the technique easier to understand and tests whether it works without relying on a long, opaque context. He also recommends trying different models, since smaller models may need more coaxing while still handling the same task.
Small helper scripts and summaries turn LLM use into reusable work
Odendahl recommends changing a system prompt for the current programming session, such as specifying PHP libraries and formatting rules. He also asks the model to generate throwaway helpers for small annoyances, such as a shell script that opens clipboard contents and removes imports before pasting them into an IDE. His most important practice is summarizing the final conversation as a README, how-to, wiki entry, or RFC. A colleague can read one clean document instead of a ten-page chat. He contrasts this with ordinary web research, where people would not normally share their entire search history.
LLMs work better when the task is decomposed into language translations
Odendahl's central model is that an LLM transforms tokens across languages. Code, German, mathematical notation, meeting language, and domain-specific terms can all be used as inputs or outputs. He says programming with an LLM means breaking a problem into translation steps. For a meeting transcript, he first asks for the topics, then asks for the exact details of each topic, then extracts action points, and finally creates structured GitHub issues. Each step gives the model a narrower target. The same process can turn an RFC into a refactoring plan or update an RFC from review comments.
Meaningful names and domain language give the model better access to patterns
Odendahl argues that names such as "year-over-year revenue" carry more useful information for a model than a variable called "A". The model can connect domain terms to finance literature and other human-created material. This means programming tasks can draw on theater, poetry, marketing, textbooks, and mathematical formulas. He uses deliberately strange examples, such as a real-time operating system for a remote-controlled T-Rex, to expose which parts of an output are structural placeholders and which parts are domain-specific. The unusual domain can make ambiguous programming jargon easier to inspect.
Generated DSLs provide a compact interface between code and the model
Odendahl uses domain-specific languages to create a representation that the model can handle. For packet captures, he proposes a YAML DSL for interesting DNS traffic, followed by a Python program that converts the pcap file into that YAML. For a codebase, he asks the model to invent a YAML DSL that finds Python functions, classes, docstrings, and Markdown titles. The resulting small context can be regenerated as the codebase changes and pasted into later prompts. He uses the same approach for reports, text adventure games, application interfaces, and self-contained HTML prototypes. The DSL becomes a target language the model can generate and an interpreter can execute.
Role-play and simulated worlds can produce more critical code reviews
Odendahl says models are trained to be agreeable, which can make ordinary code reviews too polite. He instead asks the model to stage a reality show called "Code Survivor", with variables and functions as contestants that attack one another and vote out the worst code. A concept such as SQL injection can also become a character. After the simulated discussion, he asks for a sober code review report with the role-play removed and concrete fixes retained. He describes this as useful engineering rather than a novelty because the artificial conflict prompts the model to identify issues such as missing sanitization or error handling.
The programmer's job shifts toward fundamentals, judgment, and language design
Odendahl says generated code can arrive faster than a person can review it, so engineers need to know when to step away. If a task does not work within about ten minutes, he recommends doing it by hand or returning later to identify the translation step the model misunderstood. Fundamental knowledge remains valuable because it lets an engineer recognize a broken RTOS, assembly, or framework pattern. Detailed API knowledge matters less to him, while broader patterns such as infrastructure deployment still matter. He also values divergent thinking, abstraction, and designing useful formats for humans. A readable README remains useful to both people and models.
"When you talk about doing something, just type that into the LLM and then it will do it."14:21
Who should watch
You write software and want concrete ways to use LLMs beyond asking for a complete implementation.
Your team has meeting transcripts, codebase documentation, or repetitive issue and script work that could be split into smaller transformations.
You are experimenting with generated code and need a practical view of when fundamentals and manual programming still matter.
