You Don't Work with LLMs — LLMs Work for You
If you treat an LLM like a teammate, you'll be disappointed.
If you treat it like a compiler, you'll ship valuable results.
Developers fail with LLMs for the same reason they fail at planning tasks like writing Jira tickets:
- vague inputs
- missing constraints
- no stopping condition
- no definition of done
- blind trust
This guide is not about what LLMs are. (I alread did that here)
It’s about how to use them every day without losing time, correctness, control or your mind.
Vibes are good. Prompting is not that helpful in 2026, so remove your collected prompts e.g. Me as PHP chat bot. 🤖 and use your context window for real work.
But context, workflows and hard constraints are what actually work in production.
Let's get hands-on.
Mental Model: LLM as a Probabilistic Compiler
Before tools, prompts, or rituals, internalize this model:
| Programming Concept | LLM Equivalent |
|---|---|
| Source Code | Prompt + Context |
| Include Paths | Files, snippets, constraints |
| Compiler | LLM |
| Intermediate Representation | Generated output |
| Type Checker | Static analysis, tests |
| Linker | Manual edits |
| Runtime | Production |
If something breaks, the bug is in the input, mostly not in the compiler. (even if we sometimes think it is)
PS: Here are some 01/2026 facts about LLM usage: If a colleague argues that this doesn't work at all, remind them ...
- The Cursor Team used hundreds of concurrent AI agents to write over a million lines of code for a browser prototype in a week. Autonomous workflows are real.
wilsonzlin
/
fastrender
Experimental new browser engine
FastRender
A browser rendering engine in Rust. Parses HTML/CSS, computes styles, performs layout, and paints pixels. Includes a desktop browser shell and JavaScript execution via an embedded JS engine.
Under heavy development. APIs are unstable and change frequently. Not recommended for production use.
Developed as part of research into collaborative parallel AI coding agents.
Repository structure
src/
├── api.rs # Public API (FastRender, RenderOptions)
├── dom.rs # DOM tree, parsing, shadow DOM
├── dom2/ # Live DOM for JS mutation
├── css/ # CSS parsing, selectors, values
├── style/ # Cascade, computed styles, media queries
│ ├── cascade.rs # Cascade algorithm, layers, scope
│ ├── properties.rs # Property definitions
│ └── values.rs # Value types, calc(), colors
├── tree/ # Box tree generation
│ ├── box_tree.rs # Box nodes, formatting contexts
│ ├── box_generation.rs # Styled → box mapping
│ └── table_fixup.rs # Anonymous table wrapper insertion
├── layout/- Uncle Bob (Robert C. Martin), the master of Clean Code, admitted that LLM Coding-Agents are working surprisingly well.
- Linus Torvalds himself used tools like Google Antigravity for hobby projects and accepted the results.
torvalds
/
GuitarPedal
Linus learns analog circuits
Random guitar pedal board design
This project is archived
I got about as far as I was interested to get in this form.
The analog pedals were never very interesting from a sound perspective but they were great for learnign the basics. That last boost pedal (not in a 1590LB form factor, despite the pathname) with a long-tailed pair and a few current sources, was really about as far as I was interested in the analog side.
Along the way, I learnt about transistors (BJTs, MOSFETs and JFETs), about diode mixers, Gilbert cells etc. None of the pedals made pleasing sounds, and I still think analog pedals are pointless, but as a learning exercise they were great.
The digital pedal then took me longer to get around to because there were so many choices and the initial step was bigger - but I was never interested in just connecting together…
1. Input Discipline (Before You Ask Anything)
Rule: Never Prompt Raw Thought
LLMs amplify ambiguity.
If your input is fuzzy, the output will be confidently wrong.
Bad input:
Implement the refund logic.
Good input:
Context:
- PHP 8.2
- Existing service RefundService
- Amounts are integers (cents)
- Manual approval required above 500 EUR
Constraints:
- Do not change public interfaces
- No new dependencies
- Existing tests must pass
Task:
Draft the internal calculation logic only.
Related Files:
...
Pro Tip for Long-Term Memory: Don't try to hold everything in the active chat context. Have the LLM write summaries or decisions into markdown files in the repo. Use repository artifacts as the LLM's long-term memory.
PS: Google Gemini has currently the highest context window, so switch to that model for those tasks if needed
2. The 90% Rule (Where LLMs Are Actually Good)
LLMs are excellent at the first 80–90%:
- scaffolding
- DTOs
- adapters
- mappings
- test skeletons
- documentation that mirrors code
- mechanical refactoring
They are bad at:
- domain invariants
- legal constraints
- historical edge cases
- “this legacy code is ugly for a reason”
Rule
Mostly you don't want to prompt the last 10%.
The moment you think “it’s almost right”, stop prompting.
You either:
- fix it manually, or
- encode the missing rule as a test or type
Anything else becomes prompt addiction.
3. Daily Workflows
Step 1: Planning — Use LLMs for Triage, Not Code
Start the feature or project by converting chaos into structure.
Use LLMs to:
- summarize long ticket threads
- extract precise acceptance criteria
- identify system invariants
- list unknowns and highlight risks
- debate technical trade-offs (ping-pong arguments)
- run a "blind spot analysis" against your plan (Meta-Prompt or via Chatty)
No code yet.
Hint: And remember, before you use the latest shiny framework version, that the current models were trained with data from last year, so you should “at least” be from that time, maybe even older, so that more training data was available at that time.
If you skip this, you’re outsourcing thinking, not typing.
Note: If you are typing a lot, voice tools like wisprflow.ai can reduce friction (and yes, that matters).
Step 2: Implementation
Lane A: The "Legacy Stack" Approach (e.g., older PHP, Java)
If the LLM struggles with your 1996 template engine quirks:
Generate a Mockup (image) after you provided your "style guide" and examples PS: if you haven't a style guide yet, let the LLM help you also with that task - https://gist.github.com/voku/8615cc2b095ec2d46a3e69faa2595dad
Generate a Click-Dummy of the Mockup: Turn the mockup into a clickable prototype to verify flows against constraints.
Manual Integration: Use the Click-Dummy to integeate the feature into the real code, mostly by hand
Tests: Let the LLM add some tests in the end :) (I know we want to use TDD but anyway)
Lane B: Frontend "Vibe-Coding" (The 2026 Way)
For modern stacks where iteration is cheap:
Go to AI Studio
Use your planning from before, and copy&past just the full document into the input.
PS: for me ChatGPT is still best in planning such stuff without adding un-wanted stuff like Claude often does
Now is Ping-Pong time, let's shape the results by using the AI-Studio to providing direct feedback and ideas that pop-up while seeing the results. :)
Push the 90% version to github (just one click in the UI)
Agentic Cleanup: Now let's use another LLM (e.g. codex web or github agent) ... and you can give the agents more than one task, if the tasks are small, so that you do not need 10/100 free request but just 1/100 e.g.:
Remove GEMINI references
Update README.md to remove AI Studio ads and references
Update README.md with production-ready documentation
Add "Key Files Detector" helper prompt to README.md
Add a favicon
Create a contribution link (https://github.com/[YOUR_LINK_HERE]) in the webapp
Configure GitHub Pages deployment with Vite build
Add GitHub Actions workflow for automatic deployment
Build and verify the application works
Review and finalize changes and make sure the entry point from the webapp is in the html file
- Activate github pages (for free) and your Webapp is online while you managed all this with your phone :)
PS: here are my example Webapp stuff that I created mostly this way:
Lane C: Agentic-Coding (Vibe-Coding with Control)
Plan with Restrictions: Ensure your planning phase is solid and you have clear constraints documented (e.g., in an AGENTS.md file in your repo root).
Define Tasks: Add clear, bite-sized tasks into a docs/TODO.md file via the LLM.
Run the Agent: Use CLI tools (see "What's Next" below) to execute the list.
Example: codex --yolo "Implement the open tasks from docs/TODO.md"
This tools are also working with your subscription, and often has a free try and at the end of the post I wrote a quick one minute intro to install it, see What’s Next: Agentic Coding (Try It)
I created the next project via agents (without any IDE) and while working on it, I saw that the agents really has problems with e.g. Android Apps because the build time (feedback loop) was way to slow with my mini pc :/ so I asked the agent to convert it into a Webapp and it worked. :D
My main pain point is that if you didn't do the coding work anymore you haven't this mental model of the project in mind and it's more and more complicated to plan new things and to keep it stable.
(still not 100% done, we need to train the ML Engine now)
voku
/
AmysEcho
This repository contains the development work for my little girl — to help her be understood, to help her learn, and to help others understand her world.
Amy’s Echo
This repository contains the development work for my little girl — to help her be understood, to help her learn, and to help others understand her world.
Amy is four years old. She was born with 22q11 Deletion Syndrome and communicates using German Sign Language (DGS). Her gestures are expressive, her intent is clear — but most people around her don’t understand what she’s trying to say.
This project turns those gestures into speech and symbols so she can be heard anywhere Each child profile receives a personalized gesture model trained from its own samples, making the system effective for 22q11 workflows in group settings like kindergartens Runtime classification relies on downloaded MLP weight bundles cached on the device; no TFLite files remain in the project.
All app UI text and error messages are written in German to match Amy's language environment.
📚 Documentation
Lane D: The Daily Driver (IDE-Centric Coding with Guardrails)
This lane is for daily engineering work inside the IDE (e.g. PhpStorm + GitHub Copilot). Maintenance, debugging, and refactoring where correctness matters more than speed.
No agents. No pipelines. Just quick feedback loops.
- Curate Context Explicitly: Copilot does not understand your project:
- Open the interface or contract
- Open the concrete implementation
- Open the relevant test
- Open involved DTOs or config files
Rule: If the file is not open tab, it doesn’t exist for the LLM.
- Prefer Inline Edit Mode Over Chat: Use Copilot where diffs are visible and reversible.
- Select code in the editor
- Trigger inline edit (Ctrl + Shift + I)
- Prompt with a precise, local instruction
Example: "Extract the loop logic into a private method processItems with an explicit return type."
Review the diff. Accept deliberately.
- Stabilize Legacy Code via Reverse Documentation: For unclear or fragile code, do not ask for a refactor immediately.
- Select the code.
- Ask Copilot to describe it, not change it.
- "Write a PHPDoc explaining exactly what this code does, including edge cases."
- Validate the explanation first.
Refactor only after the behavior is explicit.
Actively Prevent "Passenger Mode": The
Tab→Accept→Commitloop is a trap.Read generated code before accepting.
If you can’t explain it, reject it.
Copilot accelerates thinking. It should not replace it in this lane.
Step 3: Validation — Treat Output as Untrusted
LLM output is never final code.
It must pass:
- strict type checking
- aggressive linters
- automated tests
- static analysis tools
If it doesn’t:
- fix the constraint
- or add more context
A compiler that issues warnings is telling you something.
An LLM often believes it has done everything correctly and therefore also requires similar validation steps
Adding more context sounds more easy that it sometimes: UI Bug Example
- Provide the exact error message from the CI pipeline.
- Use an MCP (Model Context Protocol) tool to let the LLM view the app in a headless browser.
- Provide a screenshot with browser DevTools open showing the DOM state.
Step 4: commit&push — Let the Repo Remember
Humans forget why things exist.
LLMs don’t, if you ask at the right moment.
Use them to:
- Summarize diffs into commit messages. Crucial: Manually add the "WHY" to the message; the LLM usually only sees the "WHAT".
- Draft Architectural Decision Records (ADRs). Hint: Add a note in generated docs that they are drafts and need human review.
- Explain "why this legacy code is ugly" and document it in a comment near the code.
This kills tribal knowledge without requiring meetings.
4. Constraints Beat Prompts (Always)
Stop writing clever prompts. (https://voku.github.io/PromptMastery/)
Start writing constraint boxes.
Constraints:
- No new public methods allowed.
- Must preserve backward compatibility with API v2.
- Assume input is already validated (do not add redundant checks).
- Output must be deterministic (seed random number generators).
- Fail fast with a specific Exception class on invalid state.
Constraints shrink the solution space, making correct answers more likely. But sady they traind the current LLMs just the happy path. :P
5. Generators Over Code
If you ask an LLM to write the same thing 5x, you already failed.
Bad: "Generate 30 DTOs for these tables..."
Good: "Write a Python script using Jinja2 templates that reads this database schema YAML and generates the 30 DTO files fitting our project structure."
This turns:
- probability → determinism
- conversation → reusable tooling
- magic → a reproducible build step
Other example: PHP
In larger legacy systems, I recently had the LLM create various custom PHP-CS fixer rules so that we could easily migrate i18n and other things in a deterministic way. Here's how it works. That's the way.
What’s Next: Agentic Coding (Try It)
If you haven’t played with CLI-based code agents yet, you’re missing the point of all this.
- Don’t overthink it.
- Don’t integrate it into prod.
- Try it locally and break things safely.
Here are three options you can test quickly.
1. Google Gemini CLI
google-gemini
/
gemini-cli
An open-source AI agent that brings the power of Gemini directly into your terminal.
Gemini CLI
Gemini CLI is an open-source AI agent that brings the power of Gemini directly into your terminal. It provides lightweight access to Gemini, giving you the most direct path from your prompt to our model.
Learn all about Gemini CLI in our documentation.
🚀 Why Gemini CLI?
- 🎯 Free tier: 60 requests/min and 1,000 requests/day with personal Google account.
- 🧠 Powerful Gemini 3 models: Access to improved reasoning and 1M token context window.
- 🔧 Built-in tools: Google Search grounding, file operations, shell commands, web fetching.
- 🔌 Extensible: MCP (Model Context Protocol) support for custom integrations.
- 💻 Terminal-first: Designed for developers who live in the command line.
- 🛡️ Open source: Apache 2.0 licensed.
📦 Installation
Pre-requisites before installation
- Node.js version 20 or higher
- macOS, Linux, or Windows
Quick Install
Run instantly with npx
# Using npx (no installation required)
npx @google/gemini-cli
Install
…Install
npm install -g @google/gemini-cli
Run (inside your local project)
gemini --yolo
2. OpenAI Codex CLI
npm i -g @openai/codex
or brew install --cask codex
Codex CLI is a coding agent from OpenAI that runs locally on your computer
If you want Codex in your code editor (VS Code, Cursor, Windsurf), install in your IDE.
If you are looking for the cloud-based agent from OpenAI, Codex Web, go to chatgpt.com/codex
Quickstart
Installing and running Codex CLI
Install globally with your preferred package manager:
# Install using npm
npm install -g @openai/codex
# Install using Homebrew
brew install --cask codex
Then simply run codex to get started.
You can also go to the latest GitHub Release and download the appropriate binary for your platform.
Each GitHub Release contains many executables, but in practice, you likely want one of these:
- macOS
- Apple Silicon/arm64:
codex-aarch64-apple-darwin.tar.gz - x86_64 (older Mac hardware):
codex-x86_64-apple-darwin.tar.gz
- Apple Silicon/arm64:
- Linux
- x86_64:
codex-x86_64-unknown-linux-musl.tar.gz - arm64:
codex-aarch64-unknown-linux-musl.tar.gz
- x86_64:
Each archive contains a single entry with the platform baked into the…
Codex CLI is explicitly designed to run locally and operate on the selected directory. (developers.openai.com)
Install
npm i -g @openai/codex
Run
codex --yolo
⚠️ Use this only in a local / restricted environment. It can delete things. That’s not a joke.
3. opencode-ai (open source)
The open source AI coding agent.
English | 简体中文 | 繁體中文 | 한국어 | Deutsch | Español | Français | Italiano | Dansk | 日本語 | Polski | Русский | العربية | Norsk | Português (Brasil) | ไทย
Installation
# YOLO
curl -fsSL https://opencode.ai/install | bash
# Package managers
npm i -g opencode-ai@latest # or bun/pnpm/yarn
scoop install opencode # Windows
choco install opencode # Windows
brew install anomalyco/tap/opencode # macOS and Linux (recommended, always up to date)
brew install opencode # macOS and Linux (official brew formula, updated less)
paru -S opencode-bin # Arch Linux
mise use -g opencode # Any OS
nix run nixpkgs#opencode # or github:anomalyco/opencode for latest dev branch
Tip
Remove versions older than 0.1.x before installing.
Desktop App (BETA)
OpenCode is also available as a desktop application. Download directly from the releases page or opencode.ai/download.
Platform
Download
macOS (Apple Silicon)
opencode-desktop-darwin-aarch64.dmg
macOS (Intel)
opencode-desktop-darwin-x64.dmg
Install
npm i -g opencode-ai@latest
Important (learn this early)
- run agents locally or in Docker
- combine them with:
- static analysis
- code style checks
- tests
- treat agents like a junior dev with root access
- add skills/instructions (AGENTS.md etc.) step by step
- less is more
- MCP and tool calls are cool, but it eats your context window
- ideas: https://voku.github.io/your_agent_config/
Agentic development isn’t magic, but at some point we need a IDE again. :D
Some !funny takes at the end
Happy Coding!
Top comments (0)