AI executes. The human designs, tests and secures.
Lucid coding is vibe coding with the human awake: the same speed, but knowing at every moment what the agent is doing, and steering it. It is for developers who already work with coding agents and want to do it with method. It grew out of a year of daily practice, measured over more than 21,000 real prompts. Its ritual word is the one typed most in them: “proceed” (from the Spanish «proceda»).
There is value in the items on the right, and we use them: the AI writes code and tests. But when they conflict, the items on the left win.
They are the backbone of the method. Everything that follows exists to hold them up. They are remembered by the five letters of LUCID, which work the same in English and Spanish.
Start from code and architectures that already exist and that the developer already knows. Hand the agent ready-made repos and tools that are already built, so it uses code templates that already work instead of doing everything from scratch.
The soul of the code. This is where the developer brings the vision: what needs to be done and how. It is where their creativity lives, and it is not delegated.
Always forward with the AI. In execution, the AI is in charge: it does everything it can, terminal and browser included, and never hands back work it could do itself.
Ready-made method templates, one per type of build, to guide the AI. They translate into concrete, linear rules that form the system's hard harness. Every error that repeats becomes one more rule.
Intensive product QA, mostly human: every element is tested separately and by hand. The AI automates only unit tests and controlled automations. The main techniques are driving the browser, debugging in a controlled way and using the CLI to simulate the user.
This is where you still code “by hand”, and where all available review time goes. Building on a solid grounding in information security, the human chooses components and parameters according to the architecture, the costs and the business. The AI implements them first, along with the unit tests and simulations. At the end, the developer reviews the code by hand.
Never delegated 100% to the AI.
In collaborative development, the team has to be able to see what each dev does with the AI. Session logs and the record of prompts given to agents are kept, together with the commit each one produced.
A written policy defines how AI is used in the project: which tools and models are allowed, which data and credentials the agent may see, and what gets logged. That gives you traceability for audits, above all of code security and credential use.
No log, no audit.
Not out of malice: that is how it works. It is wrong with total confidence, takes shortcuts and declares done what it never checked. That is why the method starts from suspicion, not faith.
Everything the agent does or says is a hypothesis until you see the proof. Make it test, verify and check, especially on what matters. “Done” without evidence (test output, URL, deployed version) does not count.
Ask it to run the e2e tests and check production. That way it works with the context that matters, what is actually running, not with what it thinks it remembers.
Once there is a solid codebase, another agent attacks it: pushes back, hunts for bugs and flaws. It starts from a clean context, without the builder's conversation or justifications, and evaluates only against evaluation rules defined in advance.
The agent that wrote the code defends its work. A new one has nothing to defend.
The smallest unit is the Change: one prompt that ends in one commit. Changes make up sessions, sessions make up milestones, and milestones move the product forward.
Seed → Proposal → MVP → Production → Polish → Operation → Retirement. The Proposal and the move to Production are always decided by the human.
A visible result: an MVP, a feature in production, a security hardening.
Opens with Kickoff and ends with Wrap-up.
Generation, Integration, Evaluation and Debugging, all complete. Auditable by another AI.
The agent starts from what is deployed, not from its memory.
Adversarial agent review, manual test of every element, line-by-line security review if sensitive code was touched, and a decision: continue, fix or stop.
The milestone's repeated errors become rules or templates.
Between Kickoff and Wrap-up, the loop is simple: the agent proposes numbered options, the human answers by number and says “proceed”.
On a one-person team, the same developer wears all three human hats. What never happens is handing one of them to the AI.
Chooses foundations and architecture, writes the invariants, prioritizes and decides at every gate.
Tests every element by hand: browser, CLI simulating the user, controlled debugging.
Chooses security components and parameters and reviews all sensitive code by hand.
Maintains BACKLOG and STATUS, proposes options, hands out and integrates branches.
Make changes within a template, one per branch, and close each one with a commit.
Attacks the code from a clean context with fixed evaluation rules: hunts for bugs, flaws and what the Guardian should read. It flags; it does not replace.
| File | What it holds | Rule |
|---|---|---|
CONTEXT | Index for the agent: stack, how to deploy, rules, links. In Claude Code it is CLAUDE.md; in other agents, AGENTS.md | Short. If it grows, split it |
INVARIANTS.md | Architecture, brand, language, i18n, style, security components | Written before the first change |
BACKLOG.md | Pending, done and blocked changes, numbered | Updated at every Wrap-up |
STATUS.md | Infrastructure, versions, deployed version, active branches | Kept out of the context file |
LOG.md | Dated incidents and lessons | What repeats is promoted to a rule |
The agent always works under a context cap, and every change has to complete its GIED cycle within it:
The stable rule: every change fits entirely before the first compaction. With today's models, around 200k tokens is usually enough. If a change does not fit, split it in two; if the session nears the cap, do a Wrap-up and open a new one.
Token management, measured: in the last month, context per turn was 25k tokens (median) and 50k (p90); only 10 sessions went past 200k. Still, there were 840 compactions, in 52% of sessions: they come from long sessions that pile up, not from big changes. Managing tokens means closing and reopening sessions on time, not asking for a bigger window.
No filler. Anything permanent goes into the context file or a template, not into every message.
Once the project structure is in place, each prompt asks for a single change, as narrow as possible. Another AI must be able to audit it by reading the prompt and the diff.
A URL, a repo of your own, the exact technical name and a test case. “Make it more modern” is not a request.
When facing a decision, the agent proposes 2 or 3 numbered paths and the human answers by number. “Proceed” always takes an object: proceed with what.
Few active branches, each with a clear purpose (a routine, an autopilot, an environment) and as little divergence as possible.
With too many branches the agent gets confused: it goes by the branch description more than by the commits, and on top of that come merges and divergences it overlooks.
If there is more than one agent in the repo, each works on its own branch and its own isolated copy (worktree), no exceptions. They coordinate through files, not memory, and the lead or the human decides the merge. Only independent work is parallelized.
Orchestration: the lead hands out bounded tasks; each subagent starts from a clean context and returns a summary, not a dump of files. Side tasks go to a fork so they do not block the main thread, and the lead integrates and verifies what comes back.
Last month: 1,022 subagents launched (512 general-purpose, 339 forks, 69 explorers), 204 messages between agents and ~2,490 worktree operations.
Before starting, define which credentials the agent will use and how they reach it.
Some agents have limits no instruction lifts, such as typing real passwords or making payments. For those, the agent gets everything ready up to that step and the human completes it.
Procedures repeated successfully are saved as templates or preloaded skills the agent loads (kickoff, wrap-up, deploy, browser QA, publishing). On the second successful use, it gets saved. The agent does not reinvent; it loads.
Last month: ~9,000 browser actions, but only ~30 skill invocations and a single project skill on disk. The procedure was rewritten every session; that is the gap this rule closes.
The main thread always uses the most capable model. Fast models only in subagents for search, exploration or bulk tasks whose output gets verified afterwards. Architecture, security, hard debugging and auditing never drop a tier.
Last month: ~99% of 94,606 responses came from the top model and ~0.5% from a fast one, always in subagents.
Almost all the corrections observed share the same root.
| Anti-pattern | Symptom | Fixed by |
|---|---|---|
| Backlog in the agent's head | “What's left?” every day | BACKLOG.md and Wrap-up |
| Giant, multi-topic sessions | The agent compacts and forgets the plan | Rule 0 |
| “proceed” with no object | The agent guesses what you approved | Rule 4 |
| Aesthetics with no reference | Design corrections at every milestone | INVARIANTS and rule 3 |
| Vague request that drifts | One technology is asked for and another gets built | Rule 3 |
| Agent that hands work back | “do it yourself” from the human | Proceed pillar |
| Credentials with no inventory | Dev keys reaching prod unrotated | Rule 7 |
| Agent that won't log in during dev | Blockers and work handed back to the human | Rule 7: tell it the stage |
| Several agents in one copy, or too many branches | Collisions and muddled context | Rules 5 and 6 |
| Believing the agent | “Done” with no proof; the bug shows up in production | The agent: rules 0 and 1 |
| The builder reviews itself | The agent defends its own code | Adversary with a clean context |
| Security delegated to the AI | Nobody read the auth code | Security pillar |
Create the five files, write the INVARIANTS, define environment variables, vault and credential inventory, and save the kickoff and wrap-up templates.
Every prompt ends in a commit, every session closes before compacting and every milestone goes through the gate. Friction goes into the LOG.
Count in your transcripts: compactions per session, “What's left?”, design corrections and prompts that end in a commit. Compare with before and adjust.
| Sign it's working | Target |
|---|---|
| Compactions per session | 0 |
| Prompts that end in a commit | ≥ 80% |
| “What's left?” per week | 0 |
| Active branches per repo | ≤ 3 |
| Sensitive code with human review | 100% |
| Dev credentials outside the inventory | 0 |
| AI commits with no traceable prompt or log | 0 |
Lucid coding comes from one developer's work over a year, with the full history measured: 21,310 typed prompts from November 2025 to October 2026, across 1,548 sessions and 195 projects, plus 135 context files. Compactions come from the transcripts the tool keeps, the last month. Counts were made with regular expressions and are approximate. Every rule in this guide comes from this data. Measure yours and compare.
| Signal | Measure | What it revealed |
|---|---|---|
| Messages of 3 words or fewer | 27% | The human steers; doesn't specify |
| “proceed” and variants | ~1,230 | Approving is the main act |
| “What's left?” / “Shall we wrap up?” | ~410 | The backlog lived in the agent |
| Compactions in the last month | 840 | One every ~6 prompts; 52% of sessions compacted: sessions too long |
| Complaints about design, logo, i18n | ~360 | Requirements that were never written down |
| “Do it yourself” | ~22 | The autonomy boundary wasn't explicit |
| Largest context file | 226 KB | The agent's memory grew with no ceiling |
What worked best, with almost zero corrections afterwards: answering numbered options by number, asking for 3 proposals and picking one, giving a URL or a repo of your own as a reference, naming the exact technique with a test case, and turning every successful session into a written procedure. With that loop, a complete SaaS product went from idea to production in 17 hours, and a deployment bot in one day.