Stefan's engineering approach

This page summarizes how Stefan Preu approaches engineering with AI agents. It describes his stated working philosophy and reported practice, not guaranteed outcomes.

Context is part of the engineering

Stefan's central interest is how context changes what an agent produces. Useful context helps an agent understand the work without overwhelming or distracting it, and without burying the evidence that matters for the current decision.

A task becomes more useful when it is connected to its goal, the decisions behind it, evidence, history and related work. For Stefan, context also includes why an option was rejected, what changed and what is explicitly not a goal.

Durable context across fresh sessions

For Stefan, durable context does not mean letting one chat grow forever. It means keeping goals, decisions and evidence somewhere a fresh session can recover them, so the next person or agent does not have to rebuild the background by hand. Stable direction, discoverable information and practical tools work together.

He is explicit that this big picture must be accessible to agents as well as to people. It is a central part of his reasoning, not just a reporting layer for humans.

Stable goals, adaptable guidance

While developing PM CLI, Stefan has used a largely repeated main prompt and changes it mainly when the goals change. Much of the guidance lives around the prompt: in documentation, project data, skills and tool interfaces. That does not mean one prompt built the project without judgment or preparation.

He removes instructions that stop helping as models and tools change. Types, APIs, lint rules and deterministic contracts can express constraints more reliably than prose that goes stale. A technique that helped an earlier model may be unnecessary later, so he tests the current situation instead of assuming that more scaffolding is better.

Primitives over features

Stefan thinks in reusable parts and the relationships between them. He wants people and agents to compose the workflow they need from those parts without waiting for him to ship a dedicated feature.

New capabilities should not force existing users to change how they work, and a shared foundation should support different needs instead of imposing one universal schema or process. Status rules or required fields are examples of useful building blocks, not a mandatory lifecycle for every team.

Usable without him

Independence matters to Stefan in two directions. A system should stay usable without its original creator, and users should own their data and be free to adapt, replace or leave a tool, his own tools included.

He aims to avoid artificial dependency on a vendor, a model, a harness or on himself. On preu.at he sums this up as "usable without me": your data, your tools, your call. Source: preu.at

Room to explore, walls around the effects

Stefan gives agents as much room as practical to investigate, inside a deliberately bounded environment such as a sandbox or a replica. The boundaries sit at the system level: access, execution and anything that affects real services, people or infrastructure.

This does not remove permissions, human responsibility or checks on consequential actions. It also does not mean every harmless local edit needs individual approval. Human oversight, in his view, means keeping the goals and trajectory, noticing drift and checking the outcome. The right balance depends on the task and setting.

Keep the reasoning, not just the result

Stefan treats decisions, rejected alternatives and non-goals as part of the work. Code gets replaced; the reasons behind it should survive.

In his own words: "I build things to last, but I'm not emotionally attached to code." The emphasis is on preserving useful data and reasoning when the implementation changes.

Code remains an inspectable reference

Stefan still considers himself to be programming, even when language models write much of the code. Code remains something agents can revisit, inspect, debug and use as a reference for later work. He does not present working through LLMs as abandoning programming.

He combines deterministic programming and agents as part of systems engineering and architecture. Which one fits depends on the task and the checks available. Neither ordinary code nor agent output is trustworthy just because of how it was produced.

Learning through use

Stefan prefers building a useful foundation and learning through use. Agents that develop a tool also use it, and their difficulty finding information, composing a workflow or recovering state can reveal a design problem worth investigating.

Architectural decision records give an initial structure that evolves as experience accumulates. PM CLI's own development is tracked in PM CLI for this reason; see the PM CLI page.

Say what is proven

Stefan separates intent from evidence. Acceptance criteria describe the intended outcome; tests, task-specific checks and review show whether it happened. In his own workflow, every item carries acceptance criteria. Where he is still exploring, he says so.

Ambitions such as fully portable context across every provider, universally intuitive tools, complete automation or autonomous self-improvement remain hypotheses. He makes no general productivity, reliability or token-saving percentage claims.