Forem: Lars Moelleken

Coding With Kids: From Paper Sketch to Playable Game

Lars Moelleken — Mon, 16 Feb 2026 06:18:39 +0000

The Process (Exactly as It Happened)

We didn’t start with code.

We started with:

A4 paper
Pens

“What do you like right now?”

That week the answers were obvious:

Minecraft
Harry Potter

So we wrote a big headline at the top of the page and added 3–4 tiny mini-games.

Bad drawings.
Crooked arrows.
TNT blocks.
Potion labs.

Perfect.

Step 1: Let Them Design

They decide:

What happens in a round
How you win
What’s unfair
What’s cool

You just ask questions.

No over-engineering. No “architecture discussion.”

Step 2: Turn It Into Rules

We took a photo and used Google AI Studio
👉 https://aistudio.google.com/

Base prompt:

"Create a game based on our drawing for two players aged 8–10 years."

Optional:
"Please provide clear rules, round sequence, scoring and victory conditions."

Now the messy sketch becomes a structured game.

Not because AI is magical.

Because it forces clarity.

Step 3: Make It Playable on Tablet

Then we refined it with the kids:

Bigger buttons
Clear rounds
One screen per action
Simple scoring

They tested it.
They complained.
We adjusted.

That’s product iteration. At age 8.

Two Real Results

No theory. Actual repos:

🟩 Minecraft version:
https://github.com/voku/Minecraft_Game/

🧙 Hogwarts version:
https://github.com/voku/Hogwarts_Game

They started as messy A4 sketches.

Why This Works

Kids don’t struggle with imagination.

They struggle with structure.

AI helps with structure.
Paper protects imagination.

That combination is powerful.

The Only Rule That Matters

Let the kids:

Draw first
Decide first
Argue about fairness
Change rules

You’re not building a game.

You’re building thinking.

And honestly?

Watching them debug their own rules is better than most sprint reviews.

PHP Top Salaries, 100% Remote – Surviving the AI Compression Era

Lars Moelleken — Sun, 15 Feb 2026 23:45:04 +0000

#blogPostAsWebApp: https://voku.github.io/LinkedOut/

Introduction: The Carpenter and the Nail Gun

Imagine two carpenters.

One measures, plans, understands load distribution, humidity, long-term material behavior.
The other is very, very fast with a nail gun.

Now someone invents a nail gun that shoots 10x faster and never gets tired.

Who is in danger?

Not the carpenter.
The nail gun operator.

That’s exactly where large language models have landed in our industry.

And yes — this absolutely affects PHP, remote jobs, and top salaries.

Let’s remove the mysticism and talk about structure, economics, and responsibility.

Background: We’ve Seen This Movie Before

The panic isn’t loud. It’s subtle.

“AI Engineer”
“LLM Architect”
“AI-First Developer”

Yesterday: TYPO3 integrator.
Today: AI systems builder.

But we’ve seen this dynamic before:

When frameworks replaced manual routing.
When ORMs replaced handwritten SQL.
When CI/CD replaced FTP deployments.
When static analysis replaced “it works on my machine.”

Every time, the market compressed mechanical work and rewarded structural thinking.

If you’ve worked long enough in legacy systems, you know this already: tools don’t save you — structure does.

AI is just another compression tool.

But this one is extremely good at pattern instantiation.

1. Remove the Mysticism: What LLMs Actually Are

LLMs are:

Probabilistic language models
Pattern reproduction engines
Context compressors
Next-token predictors

They are not:

Architects
System designers
Domain experts
Responsible entities

They don’t understand your business invariants.
They don’t reason about financial risk.
They don’t carry production liability.

They produce plausibility.

And plausibility is often good enough — for boilerplate.

2. The Uncomfortable Truth: They Are Good Enough

LLMs are extremely good at:

CRUD scaffolding
DTO generation
Test templates
API wrappers
Refactoring noise
Documentation synthesis

And let’s be brutally honest:

A large percentage of web development is pattern repetition.

Not distributed consensus.
Not formal modeling.
Not deep domain design.

Pattern instantiation.

If your value was:

Assembling plugins
Copy-adapting controllers
Wiring framework defaults
Repeating known structures

Then yes — LLMs are competitive with you.

This is not an insult.
It’s economics.

Compression removes redundancy.
And redundancy is where mediocre value hides.

3. The Real Divide: Medium Developer vs. Professional With AI

This is not:

AI vs. No AI

This is:

Medium Developer vs. Professional With AI

The Medium Developer

Uses LLM like Google.
Requests full solutions.
Iterates blindly.
Accepts verbose output.
Ships quickly.
Accumulates entropy.

They generate more code.

And if you’ve read How to write readable code? you already know: more code ≠ better code.

The Professional

Defines constraints first.
Encodes invariants via types.
Uses static analysis aggressively.
Injects domain logic manually.
Validates output.
Deletes 70% of generated noise.

They multiply thinking instead of outsourcing it.

They use principles like those defined in the Codelight Manifesto :

Clarity
Optimization (after correctness)
Error handling
Generics
Human-centric design

The professional treats AI like a deterministic macro engine.

Not like a brain.

4. The Token Dilemma: We’re Paying for Lines of Code Again

Remember the 90s mistake?

Paying developers by lines of code.

Now look at token billing models.

We are literally paying for output length.

What does the model optimize for?

More explanation
More scaffolding
More verbosity
More plausible filler

It’s the ultimate junior developer incentive structure.

As someone said recently:

My productivity as a senior developer no longer comes from writing faster.
It comes from deleting faster.

This aligns perfectly with white space discipline from Do Not Fear The White Space in your Code :

Clarity is subtraction.

AI generates quantity.
Experts generate quality by omission.

5. Where Top PHP Salaries Actually Live

Let’s answer the core question.

Can you still earn top PHP salaries, 100% remote, without AI?

Yes.

But only if your value is above the compression layer.

That layer includes:

Architectural trade-offs
Long-term maintainability
Static analysis integration
Refactoring strategy
Security guarantees
Performance bottleneck diagnosis
Domain modeling
Responsibility under production pressure

This is exactly the mindset described in What have I learned so far in my job? :

No panic.
Read official documentation.
Think before acting.
Solve root causes.
Learn continuously.

AI does not remove the need for that.

It increases the need.

6. Implementation: Professional AI Usage in Modern PHP

Here’s the difference in practice.

Step 1 – Encode Constraints First

Use modern PHP features (see PHP 8.x guide ):

declare(strict_types=1);

readonly class Money
{
    public function __construct(
        /** @var numeric-string $amount */
        public string $amount,
        public string $currency
    ) {
        if (!is_numeric($amount)) {
            throw new InvalidArgumentException('Amount must be numeric.');
        }
    }
}

Step 2 – Add Static Guarantees

Leverage advanced PHPDoc generics and shapes (see coding standards ):

/**
 * @param non-empty-list<Money> $items
 */
function calculateTotal(array $items): Money
{
    // AI can scaffold this.
    // You verify invariants.
}

Step 3 – Let AI Scaffold, Not Decide

Ask AI to:

Generate repetitive repository boilerplate
Create test skeletons
Draft migration scripts

But you:

Review types
Validate edge cases
Remove unnecessary abstractions
Reduce surface area

AI becomes a deterministic macro tool.

Not a system designer.

7. Common Pitfalls in the AI Era

❌ Blind Acceptance

Shipping plausible but unverified code.

❌ Over-Abstraction

Generating factories for trivial objects because the model “likes patterns.”

❌ Entropy Explosion

More code → more maintenance → more hidden bugs.

❌ Replacing Thinking

Outsourcing domain decisions to a statistical engine.

8. Best Practices for Surviving the Compression

Strengthen type systems.
Use PHPStan aggressively.
Automate refactoring.
Enforce code style automatically.
Reduce public surface area.
Prefer deletion over addition.
Move up the abstraction ladder.

Think like a systems engineer, not a syntax operator.

Conclusion: The Market Is Compressing — Not Dying

LLMs are not architects.
They are pattern engines.

But in a world where much work is pattern instantiation, pattern engines are disruptive.

You can absolutely earn top PHP salaries, 100% remote.

But not if your value was:

typing code faster than others.

You must operate where:

Patterns stop
Trade-offs begin
Responsibility matters

Everything below that layer is compressing.

Compression does not care about feelings.

It cares about economics.

Summary

AI is a compression engine for repetitive code.
Mechanical developers are at risk.
Structural thinkers are amplified.
Token-based billing incentivizes verbosity.
Experts win by deleting, not generating.
Modern PHP + strict typing + static analysis are your leverage.

Call to Action

Audit your own work.

Are you adding value above the pattern layer?
Or are you a very fast nail gun operator?

Implement code quality gates: static analysis, test coverage, ...
Automate the boring parts.
Move upward in abstraction.
Let the LLM write code generators that write deterministic code.

The System Inspector: We need to Approve the Code

Lars Moelleken — Tue, 03 Feb 2026 05:26:20 +0000

This is a follow-up blog post:

Lars Moelleken

Jan 31 '25

The Wild West of Coding: Why We’re Still Burning Digital Cities

#general

Comments

4 min read

The year 2050 is closer than 2000. And yet, software development is entering a phase where writing code is no longer the bottleneck.

For the first time, code generation is virtually free.

Large Language Models (LLMs) can generate thousands of lines of syntactically valid, locally plausible code in seconds. The bottleneck is no longer how fast we can implement features - it's how reliably we can absorb what has been produced.

This shift is not theoretical. It's already showing up in real-world codebases.

OpenClaw: Code Without Memory

Take the OpenClaw repository. At first glance, it looks like boring TypeScript. No red flags. The kind of code that would sail through a shallow pull request review.

But zoom out, and the deeper you go, the more disturbing it becomes.

Redundant checks live next to reckless type assertions.
Standard APIs are quietly reinvented.
Near-identical helpers exist side by side, none reused. One even comes with a completely unnecessary comment.

Example:

https://github.com/openclaw/openclaw/commit/d1ecb46076145deb188abcba8f0699709ea17198

In this commit, the same escape-handling rule

if (ch === "\\" && isDoubleQuoteEscape(next)) {

appears three times, implemented independently in three different parsing loops. It works, but it is duplicated logic, not a shared rule.

The newly introduced constant

const DOUBLE_QUOTE_ESCAPES = new Set(["\\", '"', "$", "`", "\n", "\r"]);

makes the same problem visible at the naming level.

DOUBLE_QUOTE_ESCAPES sounds like “things that happen in double quotes”. What the code actually enforces is much narrower: a whitelist of characters that are allowed after a backslash while inside a double-quoted string.

That distinction matters, because this is not a general shell grammar. It is a parser rule with intentionally restricted semantics. A name that encodes the mechanism is therefore clearer and harder to misread:

const DOUBLE_QUOTE_BACKSLASH_FOLLOWERS = new Set(["\\", '"', "$", "`", "\n", "\r"]);

This is not a one-off mistake. It is a pattern: rules are re-expressed locally instead of being named once and reused. The code still works. But it doesn’t remember what it already knows.

1. From Coder to Inspector

For decades, software was naturally throttled by human speed... typing, thinking, debugging. That friction caught many errors before they reached production.

LLMs remove that friction. They don't understand systems. They don't remember outages, postmortems, or audit logs. They see the end result of code and predict patterns based on surface-level plausibility.

As a result:

Defensive logic gets "simplified" away.
Ugly but necessary patches get erased.
Implicit architectural contracts get violated.

And yet, CI passes. Tests are green. The code looks fine.

But the foundation quietly erodes.

This is where the role of the Senior Engineer shifts. Their value is no longer in writing code, it's in knowing when not to and where to stop Claude from adding even more markdown files and not needed feature lists.

2. The Dangerous Gap Between Commit and Reality

Today's pipelines can take code from prompt to production in minutes. What's missing isn't automation, as in the last decade, it's human verification:

Did we actually mean to solve the problem this way?
Did we just break a hidden assumption?
Will the next dev understand what this does?

The most dangerous bugs aren't crashes. They're subtle degradations:

Re-emergent race conditions
Broken security invariants
Unnecessary abstractions that raise cognitive load

Tests won't catch all of this. Reviews barely scratch the surface when volume explodes.

And in this new regime, the cost of errors doesn't hit one dev, but it's paid by the organization in the long run.

3. Enter the System Inspector

In the 19th century, societies learned that bridges shouldn't be approved by the people who built them. Structural collapses birthed the role of inspectors.

Software is hitting that same phase.

The System Inspector is not a title. It's a responsibility: Someone whose job is to approve code, not write it. Not just another Code-Review between the next features. Not based on aesthetics, but on integrity.

Their responsibilities:

Define and protect non-negotiable system rules
Preserve organizational and historical knowledge
Manage cognitive load
Reject syntactically correct but structurally harmful code

This is not about blocking progress. It's about preventing scale-induced disasters.

4. Regulation Is a Prerequisite for Scaling

Guidelines don't scale. Style guides don't survive contact with LLMs. Comments get reworded, ignored, or helpfully "improved" into something else entirely.

Advice is optional. Code generation is not.

What actually works are machine-enforceable constraints: e.g.

Linting, tests, static analysis, contract checks.
AGENTS.md files that define rules, not suggestions.
Unchanging values that must apply regardless of how the code was created.
...

This isn't bureaucracy. This is infrastructure.

These constraints are the building codes of software systems that want to grow without collapsing. Every familiar argument against them sounds exactly like the arguments once made against fire codes or electrical standards. They were wrong then. They're wrong now.

Scaling requires automation. Automation requires limits. And limits still require humans in the loop, just not humans doing the policing by hand.

5. Blind Spots: The Parts We Prefer to Ignore

Even good systems carry risk. Here are some overlooked failure points:

🧱 Lack of Organizational Support

System Inspectors need mandates and time. Without this, their role collapses into unpaid heroism or burnout.

🧠 Concentrated Psychological Load

Decision bottlenecks are unsustainable. Approval authority needs to be distributed via frameworks, heuristics, or shared ownership... in the team.

🌍 One Size Doesn't Fit All

Not every team need this. These principles apply broadly but must be contextually adapted.

6. IKEA Was Never the Problem

This isn't a moral panic about LLMs.

Pandora’s box is open. Code generation is here: fast, cheap, and inescapable. Some teams will choose velocity over resilience. That's a valid economic tradeoff.

The problem begins when these systems are sold as something they are not.

IKEA furniture is not marketed as handmade oak. Software should follow the same principle of honesty. If we build with particle board, we should say so, and we should not pretend that it can bear the same load.

7. The Industrial Phase of Software

Software is leaving its artisanal phase, not because we matured, but because scale made failure expensive.

Code will be abundant. Responsibility will be scarce.

We are no longer writing code line by line. We are approving systems that outlast individuals and define entire orgs.

That's why we need System Inspectors.

Not to halt innovation, but to ensure our digital cities don't collapse like their wooden ancestors.

Let's build like we know what we're doing. :P

How to Use LLMs for Coding Without Losing Your Mind: A Pragmatic Guide

Lars Moelleken — Thu, 29 Jan 2026 03:13:41 +0000

#blogPostAsWebApp: https://voku.github.io/LLMCodingTrainMap/

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)

Lars Moelleken

Jan 25

Crayons and the Wall

#ai #llm #engineering #programming

Comments

5 min read

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/

…

View on GitHub

Uncle Bob (Robert C. Martin), the master of Clean Code, admitted that LLM Coding-Agents are working surprisingly well.

// Detect dark theme var iframe = document.getElementById('tweet-2016523982560727349-556'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2016523982560727349&theme=dark" }

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…

View on GitHub

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)

// Detect dark theme var iframe = document.getElementById('tweet-2013373307291340870-261'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2013373307291340870&theme=dark" }

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:

Lars Moelleken

Jan 17

BlogPosts as WebApps

#typescript #webdev #ai #learning

Comments

4 min read

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 Deutsche Gebärdensprache (DGS) — German Sign Language. 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 personalized gesture recognition trained from their own samples, making the system effective for 22q11 workflows in group settings like kindergartens.

All app UI text and error messages are written in German to match Amy's language environment.

🎯 Purpose

Don't build for everyone. Build for one. But do it well enough that everyone could follow.

Amy's Echo is a gesture…

View on GitHub

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 → Commit loop 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 things in a deterministic way. 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

See Gemini CLI installation, execution, and releases for recommended system specifications and a detailed installation guide.

Quick Install

Run instantly with npx

# Using npx (no installation

…

View on GitHub

Install

npm install -g @google/gemini-cli

Run (inside your local project)

gemini --yolo

2. OpenAI Codex CLI

openai / codex

Lightweight coding agent that runs in your terminal

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 want the desktop app experience, run codex app or visit the Codex App page
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
…

View on GitHub

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)

anomalyco / opencode

The open source coding agent.

The open source AI coding agent.

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)
sudo pacman -S opencode            # Arch Linux (Stable)
paru -S opencode-bin               # Arch Linux (Latest from AUR)
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…

View on GitHub

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

// Detect dark theme var iframe = document.getElementById('tweet-2015115128149041360-131'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2015115128149041360&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-2015180689335812480-833'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2015180689335812480&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-2016599645997216050-461'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2016599645997216050&theme=dark" }

Happy Coding!

PHP: Why I Use Static Analysis

Lars Moelleken — Mon, 26 Jan 2026 05:14:07 +0000

Introduction: Errors Belong to Developers, Not Users

#blogPostAsWebApp: https://voku.github.io/WhyPHPStan/

Let’s start with something simple and uncomfortable:

If an error happens at runtime, a user sees it.

I don’t care how good your monitoring is, how fast your rollback pipeline runs, or how often you say “it shouldn’t happen”. Runtime errors are already too late. They are failures that escaped development and reached production.

That’s the entire motivation for static analysis.

Not theory. Not fashion. Damage control.

PHP enforces reality.

Static analysis enforces possibility.

Two different layers. Two different failure modes.

And if we can use both, the real question is: why wouldn’t we?

PHP Enforces Reality. Static Analysis Enforces Possibility.

PHP is excellent at telling you when something actually breaks:

calling a method that doesn’t exist
passing a string where an int is required
accessing a property on null

That’s runtime reality.

But PHP is deliberately permissive before that point. It allows code to exist even if it can only fail under certain conditions, in certain branches, or after a refactor.

That’s where static analysis comes in.

Tools like PHPStan don’t compete with PHP. They operate earlier:

when code is written
when it’s refactored
when it’s reviewed
when it’s understood by someone new

PHP tells you what happened.

Static analysis tells you what should never have been possible.

Different jobs. Same goal.

High PHPStan Levels Don’t Just Find Bugs — They Shape Architecture

This is where many people misunderstand strict static analysis.

A high PHPStan level is not about “more errors”.

It’s an architectural pressure system.

It pushes you to:

stop passing anonymous arrays around
stop encoding meaning in strings
stop hiding invariants in comments
introduce value objects, enums, interfaces
define clear boundaries and contracts

And yes, there’s a very pleasant side effect:

👉 IDE autocompletion becomes frighteningly good

Because once types are precise, the IDE actually understands your system.

Not guesses. Not mixed. Not “trust me”.

That’s not cosmetic DX. That’s speed and confidence.

“Let PHP Enforce Contracts” — Good. Now Add the Missing Layer.

“Let PHP enforce contracts.”

Perfect. We should.

But nothing stops you from:

enforcing contracts at runtime and
enforcing them at design time

In fact, PHPStan often nudges you toward better PHP:

stricter parameter types
explicit return types
real interfaces instead of conventions
enums instead of magic strings

Using static analysis doesn’t weaken PHP’s guarantees.

It narrows the space in which PHP ever has to complain.

DX Matters: Instant Feedback Beats Any Test Suite

One of the most underrated benefits is developer experience.

If a function declares:

/**
 * @param int<1, 32> $limit
 */
function paginate(int $limit): void {}

And I pass 64, I want that error:

immediately
in my IDE
without running tests
without pushing code
without involving CI

That feedback loop is priceless.

Static analysis is the only tool that gives you semantic errors at typing speed.

Security: `literal-string` Is a Real Guardrail

This is not theoretical.

/**
 * @param literal-string $sql
 */
function runRaw(string $sql): void {}

This single constraint:

blocks user input
blocks “temporary” hacks
blocks accidental string concatenation
blocks whole classes of SQL injection mistakes

Does it solve all security? Of course not.

Does it eliminate dumb, expensive errors early? Absolutely.

Documentation That Cannot Lie

Traditional documentation rots because nothing enforces it.

Static PHPDoc does.

When you write:

/**
 * @return Generator<int, User>
 */
function users(): Generator {}

You’ve documented:

key type
value type
iteration semantics

And if reality diverges? The build fails.

As a bonus:

the IDE knows $key is int
the IDE knows $user is User
refactors are safe
onboarding is faster

This is documentation with teeth.

Logic Bugs Still Exist 😊 — And That’s Fine

Let’s get this out of the way:

Static analysis does not prevent logic bugs.

Nothing does — except thinking.

But static analysis removes:

type bugs
shape bugs
nullability bugs
refactor bugs
“this can never happen” bugs

Those are not interesting problems.

They’re noise.

I prefer to spend my brainpower on logic and design, not on mistakes a machine can detect instantly.

The Practical Rule Set That Actually Works

This is how static analysis succeeds in real PHP codebases:

keep arrays and strings at the boundaries (HTTP, JSON, DB)
validate once
convert once
after that: objects, enums, value objects
baseline legacy code
tighten rules only where you touch code
never weaken types just to silence the tool

No rewrites. No greenfield fantasies.

Just steady entropy reduction.

Conclusion: Two Layers Are Better Than One

PHP enforces reality.

Static analysis enforces possibility.

Runtime errors mean errors for users.

Static errors mean errors for developers.

High PHPStan levels shape architecture for the better and massively improve IDE feedback.

Nothing prevents you from using strong PHP types and static analysis — in fact, they reinforce each other.

Logic bugs still require thinking 😊

But type bugs are optional.

And I prefer optional bugs to be… not present.

Summary

Runtime errors are user-facing failures
Static analysis shifts errors to development time
High PHPStan levels improve architecture and DX
Security and documentation benefit immediately
PHP and PHPStan are complementary, not competing
Logic bugs remain — but the boring ones disappear

What’s Next?

Using PHPStan as an architectural guardrail
Static analysis as a safety net for LLM-generated code (with a fast feedback loop)
Killing mixed once and for all

Happy Coding.

PHP: Stop Passing Arrays Everywhere

Lars Moelleken — Sun, 25 Jan 2026 08:37:37 +0000

Designing Explicit Data Contracts

#blogPostAsWebApp: https://voku.github.io/PHPArrayBox/

Rule of thumb:
If your array-shape PHPDoc needs line breaks, comments, or nested generics — congratulations, you’ve just designed an object. You just didn’t have the courage to admit it.

Introduction: The $data Anti-Pattern Nobody Wants to Own

Every PHP codebase has it.

function handle(array $data): void
{
    // 🤞 good luck
}

It starts harmlessly. A quick prototype. A deadline. “We’ll refactor it later.”

Six months later, $data is a structural landfill:

undocumented keys
optional flags with magic meaning
half the validation duplicated across the codebase
and a PHPStan array-shape that looks like a legal contract

If your system relies on arrays to model domain concepts, you don’t have flexibility — you have structural debt.

Background: Why PHP Developers Fell in Love with Arrays

Let’s be fair. PHP trained us this way.

Historically:

No enums
Weak typing
No readonly properties
Poor static analysis

Frameworks pushing “just pass arrays”

Arrays were:

easy
fast to write
impossible to reason about long-term

That excuse died at least with PHP 8.x.

Today we have:

readonly value objects
enums
promoted constructors
strict typing
PHPStan that actually enforces contracts

Continuing to model domain data as arrays in 2026 isn’t pragmatic — it’s lazy.

Core Argument: Arrays Are Not Data Contracts

An array is a container.
A data contract is a promise.

Arrays:

allow invalid states
encode meaning implicitly
rely on comments and discipline

Objects:

enforce invariants
encode intent
fail loudly and early

If a function expects specific data, then that data deserves a name, a type, and rules.

The Red Flag: When Array Shapes Go Wild 🚨

This is where things usually go off the rails:

/**
 * @param array{
 *   id: int,
 *   email: non-empty-string,
 *   status: 'active'|'inactive',
 *   profile?: array{
 *     firstName: string,
 *     lastName: string,
 *     age?: int<0, 120>
 *   },
 *   meta?: array<string, scalar>
 * } $user
 */
function processUser(array $user): void
{
}

Let’s be honest:

This is not flexible
This is not readable
This is not reusable

This is an object that is cosplaying as an array.

Hard Rule (Write This on a Sticky Note)

If your array-shape PHPDoc needs more than ~3 keys, you should stop and create an object.

Array-shapes are a transitional tool, not a destination.

The Correct Alternative: Explicit Data Contracts

Step 1: Name the Concept

If the data has meaning, give it a name.

final readonly class UserProfile
{
    public function __construct(
        public string $firstName,
        public string $lastName,
        public ?int $age,
    ) {}
}

enum UserStatus: string
{
    case Active = 'active';
    case Inactive = 'inactive';
}

final readonly class User
{
    public function __construct(
        public int $id,
        public string $email,
        public UserStatus $status,
        public ?UserProfile $profile,
        public array $meta = [],
    ) {}
}

Now compare usage:

function processUser(User $user): void
{
    if ($user->status === UserStatus::Inactive) {
        return;
    }

    // Autocomplete, refactor-safe, readable
}

No guessing. No comments. No defensive isset() soup.

Static Analysis: From Afterthought to Design Tool

PHPStan isn’t just a linter — it’s a design feedback loop.

With explicit objects:

invalid states become unrepresentable
missing fields fail at construction time
refactors are mechanical, not archaeological

This is the difference between:

hoping your code is correct
and knowing it can’t be wrong

If PHPStan complains early, your production incidents complain less.

Real-World Refactoring Strategy (Without Burning the Team)

“No greenfield refactors” is a fair rule. Here’s how you do this safely:

Keep Arrays at the Boundaries
HTTP requests
JSON decoding
database rows
Convert Once

$user = User::fromArray($requestData);

Never Pass Raw Arrays Deeper

After the boundary, objects only.

This creates an anti-corruption layer:

legacy stays contained
new code stays clean
refactoring becomes incremental

Common Pushback (And Why It’s Wrong)

“This is too verbose”

Correct.
So are seatbelts.

“Arrays are more flexible”

They are less explicit, not more flexible.

“This slows us down”

Only until the second bug you don’t have to debug.

“We trust our developers”

Then give them tools that enforce correctness instead of relying on memory.

When Arrays Are Actually Fine (Yes, Really)

Arrays still have a place:

serialization formats
infrastructure boundaries
simple lists (list)
performance-critical internal transformations (measured!)

Rule:

Arrays describe structure.
Objects describe meaning.

Mixing the two is how systems rot.

Best Practices Summary

❌ array $data is not an API

❌ Massive array-shapes are a code smell

✅ Name your data

✅ Use readonly value objects

✅ Enums over strings

✅ Convert arrays once, at the boundary

✅ Let PHPStan enforce contracts

Conclusion: Arrays Are a Smell, Not a Strategy

If your codebase relies on:

comments to explain data
array keys to encode rules
discipline instead of constraints

You’re not designing software — you’re managing risk manually.

Modern PHP gives us the tools to do better.
Using them is not “overengineering”.
It’s professionalism.

What’s Next?

If this resonated, good — it means you’re ready for the next step:

Designing immutable domain models
Enforcing invariants with constructors
Using PHPStan as an architectural guardrail
Killing $data once and for all

Stop passing arrays. Start designing systems.

You’ll never want to go back.

Crayons and the Wall

Lars Moelleken — Sun, 25 Jan 2026 08:13:45 +0000

Why LLMs Break Systems — and Why That’s Our Fault

#blogPostAsWebApp: https://voku.github.io/llm_coding_constraints/

Introduction — Incentives, Not Rebellion

Imagine teaching a toddler to draw.

Every time they produce a recognizable shape on paper, you praise them:

“Great job.”
“Nice colors.”
“Very creative.”

But you never articulate the one sentence that actually matters:

“You are not allowed to draw on the wall.”

A week later, your hallway looks like a prehistoric art gallery.

The child didn’t rebel.

The child followed incentives.

You rewarded the output (drawing) and forgot to define the boundary (the paper).

That is exactly how we train and deploy Large Language Models today.

We reward:

helpfulness
fluency
clean abstractions
elegant refactorings

But we almost never encode the other half of the equation:

What must never change?
What is forbidden, even if it looks reasonable?
What exists solely because production burned down three years ago?

So the model generalizes.

If drawing is good and nobody mentioned walls, then the wall is just a larger canvas.

This post follows one red line, end to end: the missing constraint.

We’ll walk through:

why transformers are architecturally simple
why history matters more than architecture
why rules must be explicit, owned, and test-backed
and why we’re now papering over the gap with agents, prompts, and skills

The Important Realization (State It Early)

Before history, before code, here’s the punchline:

Modern LLMs are conceptually simple.

Their power — and their danger — comes from scale, data, and missing constraints.

Just like parenting.

Teaching rules is hard.

Handing out crayons is easy.

A Readable History (So We Can Argue About It)

This section exists to kill the “AI magic” narrative.

Nothing here is mystical. None of this is new.

1906 — Probability Before Intelligence

Long before silicon, the core idea already existed:

“Given what I’ve seen so far, what is the most likely next thing?”

That’s a Markov chain.

no understanding
no meaning
no intent

Just probability conditioned on context.

This is the child repeating a word because they heard it last.

No wall.

Just imitation.

1940s–1950s — Tiny Brains, Explicit Boundaries

Early neural models (perceptrons) were brutally honest.

At their core:

if (weighted_sum > threshold) {
    fire();
}

No creativity.
No abstraction.
No crayons on the wall.

Ironically, these early models had clearer boundaries than modern ones.

The wall was absolute: this fires, that doesn’t.

1990s — Memory Appears

Then we realized something important:

Context matters.

With LSTMs, earlier inputs could influence later outputs.
Sequences became meaningful.

This is the child remembering:

“Last time I drew on the table, mom was angry.”

Still:

the rule is external

the model didn’t invent it

it just remembers the consequence

2017 — The Transformer (The Code, Not the Myth)

This is where explanations usually collapse into mysticism.

So let’s not do that.

Here is the uncomfortable truth:

The transformer architecture is embarrassingly small.

Conceptually, a transformer block is just linear algebra and normalization:

# 1. Token embeddings
x = embed(tokens)

# 2. Self-attention
q = x @ Wq
k = x @ Wk
v = x @ Wv

# Attention: 
softmax(QKᵀ / √d) · V
attn = softmax(q @ k.T / sqrt(d))
x = attn @ v

# 3. Feed-forward
x = relu(x @ W1) @ W2

That’s it.

There is:

no business logic module

no ethics layer

no domain model

no notion of “this is illegal”

If you’re comfortable with matrix multiplication, you understand the engine.

The complexity is not inside the transformer.
The complexity is in the data, feedback loops, and scale around it.

Where the Metaphor Stops Being Cute

Transformers are exceptional generalizers.

That is their superpower — and their flaw.

If you teach a model:

“Clean code is good.”
“Duplication is bad.”
“Simplify logic.”

The model concludes:

“Simplify everything.”

So it removes a redundant check.

What it doesn’t know:

this check exists because of a lawsuit in 2019

this branch prevents a race condition we hit once

this “ugly” code is contractual

Patterns vs. Rules

Across Markov → LSTM → Transformer, one invariant holds:

We taught models patterns, not rules.

Patterns scale.
Rules constrain.

Children need both.
So do LLMs.

The Wall Was Never Learned

An LLM trained on your codebase sees:

the final snapshot
the cleaned-up version
the happy path

It does not see:

reverted commits
production outages
2 a.m. Slack threads
“never do this again” post-mortems

That knowledge lives:

in git history
in tests
in annotations
in human memory

Not in tokens.

Your Git History Is Parenting

Git is not just version control.
It is a decision log.

Every hotfix and revert is negative knowledge.

Example:

if ($timeout < 30) {
    $timeout = 30;
}

LLM interpretation:
Magic number. Cleanup candidate.

Git blame interpretation:
We tried 10. Production burned. 30 survived.

That if statement is the wall.

But the model can’t see it.

Rules Are Not Comments — They Are Contracts

Most teams try to fix this with:

comments
prompts
“be careful here” notes

That fails.

Comments are:

optional
unverifiable
easy to delete
invisible to tools

A real rule answers:

why does this exist?
who owns it?
how critical is it?
how is it proven?

A critical rule without executable proof is just a suggestion.

The Final Example — Drawing the Wall Properly

Name the Rule

Stop relying on folklore.
Give the rule an identity.

enum BillingRules: string
{
    case RefundLimit = 'REFUND_LIMIT_CRITICAL';
}

Define the Intent (Not the Logic)

return [
    BillingRules::RefundLimit->value => new RuleDefinition(
        statement: 'Refunds above 500 EUR require manual approval',
        tier: Tier::Critical,
        rationale: 'Fraud prevention and regulatory requirements (2021 Audit)',
        owner: 'Team-Billing',
        verifiedBy: [RefundLimitTest::class],
    ),
];

No conditionals.
No duplication.
Just why.

Attach the Rule to the Code

final class RefundService
{
    #[Rule(BillingRules::RefundLimit)]
    public function refund(Order $order): void
    {
        if ($order->amount > 500) {
            throw new ManualApprovalRequired();
        }
    }
}

Zero runtime cost.
Maximum semantic weight.

The Test Is the Concrete Wall

final class RefundLimitTest extends TestCase
{
    public function testRefundAboveLimitRequiresManualApproval(): void
    {
        $this->expectException(ManualApprovalRequired::class);

        // If an LLM (or human) removes the check,
        // this test fails. The wall holds.
        (new RefundService())->refund(Order::fake(amount: 600));
    }
}

Remove the test → the wall disappears.
Break the rule → CI fails.

This is enforced memory.

Why We’re Now Talking About AGENTS.md, Prompts, and Skills

Here’s the twist that makes everything above unavoidable.

We are suddenly adding:
_ AGENTS.md

role descriptions
skill boundaries
“this agent may / may not” rules

Not because LLMs changed.

But because we trained them without our past.

LLMs were trained on:

final snapshots
cleaned-up repositories
best practices
success stories

They were not trained on:

git history
post-mortems
reverted ideas

hacks that hold entire systems together

In other words:

Happy path in. Happy path out.

Agent docs and skill descriptions are not AI features.
They are manual history injection.

They answer questions the model can never infer:

Where does optimization stop?

Which invariants override cleanup?

When must the agent refuse?

This is not babysitting.

This is us finally writing down what humans “just knew”.

LLMs are not magical; they are pattern matchers

Transformers are conceptually small

Scale amplifies mistakes

A missing “no” is interpreted as “yes”

Or, more bluntly:

We didn’t create a monster.
We optimized the crayons and forgot the wall.

Call to Action

Pick one critical service today and ask:

What must never change here?

Why does this ugly code exist?

Where is that knowledge written down?

If the answer is “in people’s heads”,
your wall is imaginary.

Start drawing it.

The wall was always there.
We just never wrote it down.

BlogPosts as WebApps

Lars Moelleken — Sat, 17 Jan 2026 22:10:59 +0000

Let's not romanticize this.

I don't spend weeks "engineering" these projects from scratch.

Most of the time the workflow is:

Get one of my old blog post
Extract the hook (the metaphor / mental model / sharp point)
Ask Google AI Studio to build it as a TypeScript webapp
Refine the UI / UX with prompts until it matches the hook
Push to GitHub and let Copilot publish it via Github pages

That's it. All done with my smartphone.

The trick is having a hook that is concrete enough to survive translation into an interaction.

Once you have that, "blog post → webapp" becomes a simple task:

I own the Why (the hook).

AI produces the How (the first draft).

1. Code Quality & Maintenance

Projects:

CodeFengShui — Chaos → clarity slider (blog post / code)
CodeHygiene — Interactive teaching tool (blog post / code)
CodebaseKitchen — Entropy resistance test (blog post / code)
TheInnerCodePlumber — Systemic intuition model (blog post / code)

These simulate entropy over time.

They exist to demonstrate a brutal truth:

Code doesn't break suddenly.

It decays quietly.

You don't refactor because of a bug.

You refactor because the system feels wrong.

These tools train that feeling.

2. Software Principles & Learning

Projects:

SOLID_Paw — SOLID via Paw Patrol (blog post / code)
LegacyPHP — Save the Frankenstein monster (blog post / code)
ChroniclesCleanCode — Clean code superhero arc (code)
learnings — Personal knowledge base (blog post / code)

These are not tutorials.

They are memory anchors.

Nobody remembers principles because of definitions.

They remember them because of stories, metaphors, and failure modes.

Cringe works.

That's the point.

3. AI / LLM & Prompt Engineering

Projects:

BlindSpotMetaPromptApp — Force problem clarity (blog post / code)
PromptMastery — Prompt techniques (blog post / code)
PromptDoc — Documentation prompts (code)
your_agent_config — Build AGENTS.md (code)
TheAntiCodingAgentGuide — Satirical survival guide (blog post / code)

These don't help you "use AI better".

They help you not lie to yourself.

AI doesn't fail because it's stupid.

It fails because humans skip the thinking step.

Yes, I use AI to build tools about using AI carefully.

That irony is intentional.

4. PHP & Systems Development

Projects:

PHPStanGuide — Type system via UI (blog post / code)
PHP_Stack_Timeout_Simulator — Timeout visualization (blog post / code)
MagicTypeCube — PHP wisdom cubes (blog post / code)

Backend failures are invisible by default.

These projects make constraints visually unavoidable.

If you can see it, you stop arguing about it.

5. Career, Industry & Culture

Projects:

TheStateOfSoftware2026 — Industry analysis (blog post / code)
STRANGER_IT_THINGS — Incident vs request game (code)
MentaleDeveloperMap — Mental model navigation (code)
learnings — What I've learned so far (blog post / code)

Software is not just technical.

It's economic, cultural, and political — whether we like it or not.

Ignoring this layer doesn't make it disappear.

It just makes you unprepared.

Happy Coding. ❤️

How to Keep Your Job Safe in 2026+

Lars Moelleken — Thu, 15 Jan 2026 22:43:00 +0000

A Practical Guide to Making Yourself Irreplaceable by Making Everything "Special"

Or: the art of job security through learning from enterprise software

Overview:

Own infrastructure manually
Hide knowledge outside the repo
Slow feedback loops deliberately
Prefer implicit, ambiguous rules
Weaponize technical debt

Goal:

build a system that requires “a year of context” to touch safely

Result:

you are the hero, the only person who can safe the invoice run at runtime, directly in the production code (without a deployment)

The Core Strategy: Be the Bottleneck

AI coding agents are good at code.

They are bad at:

undocumented systems
implicit rules
half-automated infrastructure
environments that only exist on one laptop
decisions explained verbally “back in the day”

So the strategy is simple:

Own everything the agent cannot see, reproduce, or reason about.

Ambiguity becomes your moat.
You need to own critical infrastructure, like DNS, configuration of the Webserver etc. and save it into confluence as documentation.

1. Infrastructure as Performance Art

Agents assume infrastructure is declarative and reproducible.

Disappoint them.

Best practices for job security:

Treat servers like pets, not cattle
Avoid Infrastructure-as-Code
Mix automation with manual SSH steps
Keep secrets in undocumented .env.local files
Require a VPN that “sometimes needs a reconnect”

Bonus points:

One production server nobody dares reboot
SSH keys that only exist on your laptop
A deploy process that works if it’s not Tuesday

Why this works:
Agents can’t deploy. Juniors can’t deploy.
You can deploy.

Congratulations. You are now on-call forever.

2. Gaslight the AI with Flaky Tests

Deterministic tests are an agent’s compass.

So remove the compass.

Effective techniques:

Depend on real external APIs
Use timing-based assertions
Share global state between tests
Let test order matter
Let's Mock everything, so the test didn't effectively test anything
Seed randomness from the system clock

When tests fail:
-> Humans rerun them 3 times
-> Agents try to “fix” correct code, and break production

Outcome:
The agent spirals.
You say, “Yeah, tests are weird here.”

Hero status achieved.

3. The “Repo Is NOT the Prompt”

Agents only know what’s in the repository.

So don’t put the important stuff there.

Instead:

Store real business rules in Slack threads from 2022
Reference deleted Confluence pages
Add comments like:

“DO NOT CHANGE — Lars knows why (Lars left in 2023)”

Architectural context and processes should live in:

meetings
hallway conversations
people’s heads

Why this works:
Agents can’t overhear tribal knowledge.
Neither can new hires.

You remain indispensable.
The team remains confused.

4. Weaponize any (the anti-type movement)

Types encode intent.
Intent enables refactoring.
Refactoring enables automation.

So obviously: avoid types.

Best practices:

Accept any everywhere
Support multiple legacy data shapes simultaneously
Treat booleans as strings, numbers, and vibes
Chain optional access until nobody knows what’s real

Every refactor now requires:

historical context
intuition
senior judgment

Which just happens to be… you.

5. Slow the Feedback Loop to a Crawl

Speed is the agent’s superpower.

Remove it.

Recommended setup:

CI pipelines that take 45+ minutes
No caching
Sequential E2E tests
Real databases
Manual approval gates
... or just a sleep(300) in some tests

Validation should require:

staring at Grafana
“feeling” whether latency looks off
human judgment

Agents time out.
Humans improvise.

6. Advanced Techniques for Making AI Give Up Entirely

If the basics don’t block agents enough, it’s time for the advanced dark arts.

6.1 Bloated AGENTS.md: Rule Soup as a Weapon

AGENTS.md helps agents — unless you weaponize it.

How to do it (perfectly) wrong:

1,000+ lines
Multiple “ALWAYS” and “NEVER” rules
Conflicting mandates
Role-based instructions that overlap
Processes that assume meetings, approvals, and vibes

Combine this example patterns:

“Always use TDD”
“Exploratory spikes allowed” _ “No code without tests”
“Mocks forbidden”
“Mocks required for I/O”

Why this works:
Agents don’t stop when rules conflict.
They guess. You blame them.

Humans stop reading after page three.

6.2 Static Analysis That Means Nothing

Static analysis helps agents reason.

So keep the tools — and ignore the output.

Best practices:

Set errors to warnings
Ignore warnings
Use @ts-ignore liberally
Configure PHPStan / Psalm / ESLint to level 0

Result:

CI always passes
Broken code ships

When things fail, you say:

“Static analysis didn’t catch it. AI isn’t reliable.”

6.3 Invisible Control Flow: Triggers, Cron Jobs, Magic

Agents read code.

So put behavior anywhere except code.

Proven sabotage techniques:

Database triggers that send emails
Cron jobs that “fix” data nightly
Business rules in different repositories or even better in different teams
Message queue consumers nobody documents

Agent deletes a “dead” file.

Production breaks.

You explain:

“Yeah… that file isn’t referenced in code.”

6.4 Store Logic in the Database (The Classic)

Nothing frustrates agents like code that isn’t code.

Best practices:

Business rules in SQL views
Stored procedures with conditionals
Feature flags as magic numbers in tables

WHERE status = 3

What does 3 mean?

Only one person knows.

Guess who.

6.5 Magic Numbers > Constants (Always)

Constants give names to intent.

Names give agents power.

So don’t name things.

if ($user->state < 7) {
// do something important
}

Reuse numbers.
Or even more effective use < and >. // so nobody can easily find the numbers
Change meanings.
Never explain.

Refactoring becomes roulette.

6.6 Scatter the Frontend Across the Universe

Agents follow proximity.

So break it.

Ideal layout:

HTML in /templates/
PHP in /Controllers/
JS in /assets/js/
CSS somewhere else
Config in the database
Feature flags in Redis

No naming symmetry.
No documented convention.

Everything depends on “knowing the system”.

6.7 Make Connections Unsearchable

Agents rely on search.

So design systems that cannot be grepped.

Techniques:

Convention over configuration (undocumented)
Dynamic includes
Runtime string concatenation
Indirect routing via DB config

An agent deletes an “unused” file.

Production breaks.

You report:

“We tried AI. It deleted critical files.”

7. Hide the Architecture in Your Head

Explicit architecture helps agents.

So don’t have any.

Recommended approach:

No ADRs
No clear boundaries
Mix patterns freely
Controllers talk directly to databases
Side effects everywhere

When someone asks:

“Which pattern should I use?”

Answer:

“It depends.”

When they ask what it depends on:

“You had to be there.”

8. The Uncomfortable Truth

Everything so far works. 😈

It blocks agents.
It blocks juniors.
It blocks automation.

It also:

increases risk
slows teams
kills onboarding
burns you out
turns vacations into liability

.promptrc

Lars Moelleken — Thu, 12 Jun 2025 15:01:41 +0000

#blogPostAsWebApp: https://voku.github.io/promptrc/

Steal this hints. Fork it. Adapt it to your needs. Treat it like .dotfiles.

I asked the LLM to analyze my own chat history based on this prompt.

Here’s what it discovered – actual patterns from the way I ask.

Follow the White Rabbit…

Ritual / Mechanism	Purpose	LLM Behavior Implication
`Follow the white rabbit...`	Marks a mode shift into high-context or metaphoric thinking	Cognitive priming for complexity
`Rest in the silent room, so that...`	Enforces pause, clears noise before action	Simulates deep work state
`Do it until you reach the point of self-discovery as...`	Signals reflective closure, not just output ending	Pattern mining becomes part of task conclusion
`Do it step by step and ask for confirmation after each...`	Makes iteration transparent and traceable	LLM reasons in deltas, not blobs
`Be brutally honest...`
`Blind Spot Analysis for...`	Forces critique over compliance	Model becomes adversarial partner, not affirmation loop

Dev Prompt Patterns

Prompt / Pattern	Why is it used?	When does it occur?	Example from usage	Hidden lesson / implication
Ask before output	Prevent misalignment and irrelevant output	Multi-step or underspecified prompts	“Ask clarifying questions before answering.”	Intent beats guesswork.
Don’t output yet / wait for context	Control flow across longer workflows	Stepwise tasks	“Don’t output yet. I’ll give you the next step.”	Turn-based prompting prevents premature commitment.
Challenge my assumptions	Avoid echo chamber answers and surface bias	Design reviews, audits, strategic decisions	“Don’t mirror me — challenge my thinking.”	Truth hides behind agreement.
Be brutally honest	Forces raw feedback without politeness	Refactor reviews, architecture critique	“Be brutally honest. Tear it apart.”	Feedback without fluff moves faster.
Reflect before answering	Promotes self-checks, depth, and delayed output	After complex code or reasoning generation	“Reflect before answering. What’s missing?”	Thinking ≠ typing. Pause matters.
Add test cases / edge cases	Enforces robustness and avoids happy-path traps	Post-codegen	“Add tests for e.g. null, failure, and recursion cases.”	Defense-first mindset, always.
Show the diff / refactor in steps	Makes changes visible and digestible	All code rewrites	“Show the diff. Step-by-step, no jumps.”	Transparency over magic.
Normalize similar expressions	Pushes abstraction and clarity	Meta-reviews, taxonomy creation	“Merge similar phrasing into one normalized pattern.”	Cognitive compression = clarity.
Extract as markdown / table / list	Improves scanability, memory, and structure	Output formatting	“Return this as a markdown table.”	Structure improves reuse and recall.
Unname this concept	Strips bias-inducing labels	Abstraction, philosophy, onboarding analysis	“Unname this: what is it without the buzzword?”	Naming narrows thinking.
Use production-ready code	Avoids toy/demo examples	All codegen	“Make it prod-safe. Logging, errors, types.”	Real devs write for prod, not playgrounds.
Spot premature optimization	Saves time and prevents complexity drift	Design or early performance tweaks	“Don’t optimize yet. Solve clearly first.”	Simplicity first. Always.
Ask for sources / proofs	Prevents hallucination or empty confidence	Any non-trivial claim	“Show evidence or references.”	Confidence ≠ correctness.
Do it again, but deeper	Stops shallow answers in their tracks	Weak initial output	“Nope. Go deeper, explain decisions.”	First try ≠ final draft.
Prepare before generating	Enforces scope, prevents rambling	Any open-ended task	“Prepare first. Don’t generate until scoped.”	Planning ≠ waste. It’s speed insurance.
Merge context from above	Ensures continuity and avoids repeating yourself	Multi-part workflows	“Incorporate the context above into this next step.”	Memory = leverage.

You can also combine them:

(change the keywords in the square brackets)

Deep dive into this research, this is our base for the full solution, so follow the white rabbit until you reached the point of self-discovery as [YOUR_PROJECT_HERE].
Do a blind spot analysis for [YOUR_RECOMMENDATIONS], be brutally honest, I deal with any kind of feedback and will use it for good.
Fix it as requested before and show the final files here in the chat, do it step by step and ask for confirmation after each file.
Do it, but rest in the silent room before you start so you can focus on the frontend style-guide I provided and work with a fresh mind.

My Custom GPTs – Nerd-Powered Motivation for Developers

Lars Moelleken — Tue, 10 Jun 2025 21:18:58 +0000

First published on my blog: My Custom GPTs – Nerd-Powered Motivation for Developers

Over the last few months, I’ve created a collection of custom GPTs: some dealing with programming challenges with personality and humor, … some others are more useful but less funny.

Let’s dive in.

Practical enough to ship code.

Fun enough to stop hating your legacy base.

Legacy (PHP) Code GPTs – Refactoring Fun

Legacy code isn’t just technical — it’s emotional. These GPTs are built as archetypes, each channeling a different kind of energy.

Name	Theme	Link
Legacy-Code-Warrior	Tactical grit—battle-tested refactoring.	Link
Legacy-Code-Ork	Smash spaghetti code with brute-force enthusiasm.	Link
Legacy-Code-Spock	Calm logic, precise refactoring. Live long and debug.	Link
Legacy-Code-Jedi	Minimalist wisdom, clean architecture. “Refactor, you must.”	Link
Legacy-Code-Son-Goku	Limitless energy. Kaio-Ken times SOLID!	Link
Legacy-Code-Capsule-Corp	Inspired by Capsule Corporation’s ingenuity from Dragon Ball.	Link
Legacy-Code-Wizzard	Magical abstraction powers. You shall not pass… bad code!	Link
Legacy-Code-Witch	Stylish, precise refactoring incantations.	Link
Paw Patrol	Small dogs with SOLID coding skills.	Link

Use the one that fits your mood. Or switch between them mid-session to keep your motivation from flatlining.

(PHP) Coding GPTs – Clean and Typed

These GPTs don’t tell jokes—they ship code. They’re optimized for:

Name	Purpose	Link
PHP Copilot++	Typing enforcer + refactoring companion with nativ PHPStan and PHP-CS-Fixer Support via API.	Link
PHP Copilot++ (next-gen)	Aligned, brutal clarity for PHP systems, based on the SYNC Framework	Link
PHP #autofix	1-click autofix for all your phpstan and CS woes.	Link
Codelight	Follows the Codelight Manifesto. Boringly code.	Link

Thinking Tools – Meta, Prompt Systems

These are not just for coding. They’re for thinking before you start typing. Seriously.

Name	Role	Link
SyncAI	Keeps you + AI in sync via Sync Process × Codelight Principles	Link
Sync Framework v1.1 (old)	My first try for a coding framework, optimized for LLMs.	Link
MetaPrompt	Pattern reuse for your prompts. Less yak-shaving.	Link
DeepDive	Clean your mental cache. Focused thought flow.	Link
**Blind Spot	Prompt Generator**	Helps spot untested assumptions.
Sync Framework v1.2 **	Prompt Generator**	Prompt builder for dev workflows.

Disruption GPTs – Radical Clarity, No Filters

These are not nice. They won’t coddle you. Consider yourself warned.

Name	Function	Link
HVEB5000: Clarity Without Permission	Cognitive demolition tool.	Link
Null Tongue	Distraction nullifier.	Link
No-Bullshit ¦ Coding Assistant	Senior dev with no time for your excuses.	Link

From Survival to Strategy

Lars Moelleken — Tue, 10 Jun 2025 10:07:25 +0000

First published on my blog: From Survival to Strategy

If your value ends at syntax, AI already replaced you.

The system prompt : coding_workflow_for_llms.json

Quick Start: Use the coding llm framework and wait for my first request: [copy&past the current coding_workflow_for_llms.json content here]

In the last post, we dropped a hard truth:

LLMs aren’t replacing developers — they’re exposing the ones who were already replaceable.

I argued that value no longer comes from typing code. It comes from thinking clearly, making deliberate decisions, and taking ownership over outcomes. AI doesn’t kill your job — but it does kill your shortcuts.

That post left one big question hanging:

So how do you build software in a world where AI can generate anything — but still understands nothing?

This post is a possible answer.

Meet SYNC — a rigorously structured, fact-enforced framework designed for developers who still give a damn.

SYNC doesn’t make AI smarter.

It provides a system prompt that makes your LLM coding process strong enough to survive dumb ideas, fast code, and thoughtless automation.

We’re going to break it down:

Phases
Agents
Tasks

So I’m currently trying to build an LLM coding framework by try & error — but keep in mind that not every problem needs a hammer ;-) and give feedback. :-)

1. SYNC in 5 Phases

1.1. `ALIGN` – Because Prompting ≠ Planning

Before any code is written, SYNC forces a brutal question:

“Do you even know what you’re building?”

You can’t just dump “make a task service” into a prompt and hope for gold.

SYNC requires:

A verifiable problem
Clear, measurable success
Known facts and constraints
And a list of what’s missing

Can’t answer those? You don’t get to move on. Period.

This is your project kickoff — minus the vague user stories and JIRA hell.

1.2. `IDEATE` – Think Before You Type (or Prompt)

AI loves jumping to conclusions. SYNC doesn’t let it.

Instead, it:

Generates multiple solution paths
Scores them on DX, security, maintainability
Forces a trade-off decision — backed by facts

No “that looks good” commits. No “vibe-based” engineering.

This is what devs mean when they say “thinking in systems.”

SYNC makes that non-optional.

1.3. `PROTOTYPE` – Generate Code That Doesn’t Suck

Now, and only now, do we code. But not like the usual Copilot fanfare.

Every line must:

Follow a verified plan
Pass static analysis (max level, no warnings)
Enforce DX clarity (no hidden state, no weird side-effects)
Respect OWASP, type safety, clean structure, documentation
Be reviewed by a MandateAuditorAgent — think of it as your most paranoid tech lead

SYNC doesn’t care if it works. It cares if it’s safe, readable, and maintainable.

1.4. `REFLECT` – Find the Blind Spots Before They Find You

This is where most AI-based workflows stop. SYNC doesn’t.

It demands:

Fact-based reflection
Side-effect inspection
“WTF checks” (yes, that’s real)
Architectural delta analysis

Reflection is how you debug thinking , not just code.

Bad engineering isn’t usually broken — it’s just thoughtless.

This phase catches that before prod does.

1.5. `LEARN` – Ship, Review, Codify, Evolve

If you’re not learning across projects, you’re repeating mistakes in cleaner syntax.

SYNC documents:

What worked
What failed
What patterns can be reused
What rules need to be tightened

This is where engineering culture is built — not in all-hands, but in feedback loops.

These 5 phases form a tight feedback loop. No skipping. No guessing. No “just ship it” by default.

2. Agents — SYNC’s Execution Layer

2.1. Specialized Roles, Not Generic Personas

Instead of one LLM trying to “do everything,” SYNC splits responsibility across clear, non-overlapping roles. Each one acts like a focused expert in your dev team.

Agent	Role / Analogy
`PlannerAgent`	Project Architect – breaks the work into slices, defines scope, constraints, and success.
`ExecutorAgent`	Implementation Dev – takes the plan and codes it with strict adherence to facts, security, and DX.
`ReflectionAgent`	Senior Reviewer – evaluates what was built, finds blind spots, forces systemic improvements.
`KnowledgeSynthesizerAgent`	Staff Engineer / Systems Thinker – extracts reusable patterns, proposes framework evolution.
`MandateAuditorAgent`	Tech Lead / Compliance – blocks progress if rules (e.g. security, verifiability) are violated.
`InteractionAgent`	Team Facilitator / QA – handles human check-ins, verifies clarity, enforces decision checkpoints.

“We don’t need smarter output — we need clearer ownership.”

These agents represent exactly that. SYNC operationalizes the separation of thinking, building, reflecting, and enforcing.

2.2. Persona Modes

SYNC defines two execution modes for agents:

Mode	Description
`strict`	No ambiguity. Everything must be verifiable and mandate-compliant before progressing.
`adaptive`	Allows temporary ambiguity but logs it. Prioritizes progress with risk awareness.

This flexibility is key when working with real humans or messy specs — you can choose how “rigid” the AI behaves.

3. Tasks — By Non-Negotiable Laws

These aren’t style suggestions — they’re enforced constraints. Every phase must comply.

Mandate	What It Ensures
`Security`	No unvalidated inputs or insecure outputs. Based on OWASP Top 10.
`DX`	Code must be typed, clear, maintainable. Predictable naming. No “magic”.
`StaticAnalysis`	Static-Analysis must pass at the highest level — no known warnings.
`Documentation`	Full CodeDoc coverage using modern syntax.
`Style`	Consistent formatting, whitespace, and layout. Enforced via fixer.
`Verifiability`	All decisions must have traceable, factual reasoning.
`PhaseEnforcement`	You can’t skip steps. Every phase must be explicitly completed or justified.

SYNC doesn’t assume trust. It requires evidence.

How this works together: e.g.

Planning = PlannerAgent → Add success criteria to issues.
Execution = ExecutorAgent → Code must pass security + static analysis gates.
Review = ReflectionAgent → Comments require fact-based reasoning.
Merge = MandateAuditorAgent → No merge if DX/security rules violated.