Engineering vibe coding: AI inside guardrails

I started with Cursor as a close coding assistant: useful for exploring a code path, drafting a change and shortening the distance between a question and a working implementation. That improved code-level throughput, but the quality of the result still depended heavily on how much project context I could fit into the conversation.

Claude Code changed the unit of collaboration from a code fragment to a repository. The first retained Henri commit containing its project instructions is from 5 December 2025; by January 2026 I had reorganised the supporting documentation and expanded the rules and reusable skills. The assistant could now start by reading how the product was supposed to behave, how the UI was designed, how the system was structured and how work should be verified.

Codex agent teams extended the same operating model. On AxIT, isolated agents and worktrees can research, implement or verify different parts of a problem in parallel. That only works because ownership is explicit: each agent has a bounded task, repositories hold durable specifications, unrelated work is preserved and evidence is reported at the level it actually proves.

My most useful mental model is not autocomplete and not an autonomous replacement for a team. It is a highly capable junior engineer: fast, broadly knowledgeable, able to learn, and strong at implementation, but still short of the product history, organisational context and judgement that experienced engineers build by living with consequences.

That changes how I communicate. I act as the lead and architect. I explain the goal and constraints, review the proposed approach, make the hard trade-offs and give feedback on recurring mistakes. I expect the assistant to participate in requirements discussions and technical design, not to receive an ambiguous ticket and quietly decide what the company meant.

The comparison also explains why communication cost does not disappear. Faster implementation can reduce development cost dramatically, but alignment still matters. A product manager, domain expert and engineer still need to agree on behaviour. The difference is that AI can turn those conversations into precise, reviewable artefacts much faster.

Each repository needs a compact entry point—originally CLAUDE.md, and later agent guidance that works across tools. That file does not try to contain the whole project. It routes the assistant to the sources that own behaviour, architecture, design, release procedure and verification.

The rules cover ordinary code quality, but also the things a generic model cannot infer safely. On Henri that included Apple Human Interface Guidelines, a design system with spacing, radius, typography and colour tokens, and a hierarchy of base and application components. A new screen could therefore reuse a coherent visual language even when no final design file existed.

The system made detailed decisions reusable as well: semantic typography rather than one-off font sizes, consistent spacing and radius scales, explicit timestamp formats, multilingual search behaviour, theme colours and component states. Those are small decisions individually; together they stop an AI-generated interface from looking and behaving like unrelated screens.

I also keep ‘critical rules’: concise records of mistakes that must not recur. During Henri's pre-release MVP, one rule rejected backwards-compatibility scaffolding that no real user needed; after launch, the production rule changed to preserve live data and behaviour. If a fallback once hid a configuration error, another rule can require failure to stay visible instead of inventing a default. If a component bypassed the spacing scale, the rule can point back to the token. This turns feedback from one task into training for every later task, while still allowing the rule to evolve with the product stage.

A requirements document—often exported from a product workspace—is an input, not an implementation plan. I ask the assistant to rewrite it as a behavioural specification: what a person can do, what the system shows, which state changes, and what must happen when an operation fails.

For combinatorial behaviour, the assistant drafts truth tables or state matrices so every meaningful combination has an explicit result. For workflows, it drafts state machines and flow diagrams. It enumerates edge cases, proposes the data model and lists deployment constraints that could make a locally correct design fail in production.

The assistant does the writing and analysis; the product and engineering owners do the confirmation. That distinction matters. A junior engineer can propose a table structure, but the lead must confirm ownership, lifecycle, migration and privacy. A model can enumerate states, but the team must decide which transitions are valid. The artefact makes the disagreement visible before code buries it.

Before a substantial change, I ask for a plan that identifies the current implementation, proposed boundaries, files that own the behaviour, alternatives, risks and verification. That makes the assistant show its reasoning at the level I need to review without requiring me to supervise every generated line.

I can then challenge the approach: Should this rule live in the shared domain layer or the iOS app? Is a database migration reversible? Does a retry preserve idempotency? Which compatibility constraint is real, and which is only habit? Once those decisions are settled, implementation becomes faster because the agent is not discovering the architecture by accident.

This is where experienced judgement has the highest leverage. I do not need to control every line of code. I need to control the solution, the interfaces, the failure behaviour and the feedback loop.

Repository skills turn repeated procedures into executable team knowledge. Instead of reminding an assistant how to investigate a bug, prepare a release or audit a feature every time, the project routes that task to a maintained workflow with the relevant checks and evidence requirements.

The debugging workflows teach the assistant to collect the right signal: logs for runtime sequence, view hierarchy for UI ownership and performance exports for measured bottlenecks. The core instruction is to ask when the evidence is missing rather than make a plausible guess.

Other workflows preserve coordination. An issue tracker records discoveries that do not belong in the current scope. A status document records what is complete, what is blocked and what remains. Audit skills remind the assistant to review the full change, not only the file it just edited. Research tasks can require reading multiple current sources, comparing them and writing a report before a recommendation changes the project.

This is training and memory for an AI-enabled team. It reduces repeated explanation, keeps important steps from being forgotten and lets a new agent enter the project with the same working agreement as the previous one.

On Mapify, AI assistance accelerated work across TypeScript, backend services, data migration and operations, but system design still determined the result. Search needed a user-transparent S3-to-PostgreSQL migration, speech-to-text needed explicit retry and provider boundaries, and summarisation needed one contract across browser, workers and backend. The agent could help implement and investigate; I still had to define the cut-over, fallback, observability and production evidence.

Henri was the deliberate proving ground. The product itself used AI to create knowledge trees, lessons, quizzes and images, while Claude Code helped build the product inside behavioural specifications, design tokens, component rules, plans and tests. That pairing was important: I was not only validating whether Henri could teach; I was validating whether an AI-assisted engineering process could carry a native app and cloud system to production without losing coherence.

AxIT made the workflow more distributed. Codex agents can compare iOS, Android, web and backend behaviour, work in isolated checkouts and run targeted verification in parallel. The surrounding rules preserve the distinction between code evidence, replay evidence, simulator behaviour, physical hardware, generated reports and release approval. Parallelism increases speed; the evidence model prevents that speed from becoming overconfidence.