Specs on Aguilera Engineeringhttps://aguilera.ee/blog/tags/specs/Recent content in Specs on Aguilera EngineeringHugo -- gohugo.ioen-USeduardo@aguilera.ee (Eduardo Aguilera)eduardo@aguilera.ee (Eduardo Aguilera)Eduardo AguileraMon, 20 Apr 2026 00:00:00 +0000The ticket is the spechttps://aguilera.ee/blog/plan-mode/Mon, 20 Apr 2026 00:00:00 +0000eduardo@aguilera.ee (Eduardo Aguilera)https://aguilera.ee/blog/plan-mode/<p>I spend more time writing ticket descriptions than writing code.</p> <p>Examples of what success looks like, plus references to similar past work, let Claude ship a feature in 20 minutes. The ticket becomes the spec.</p> <p>I use Claude Code&rsquo;s plan mode. It explores the codebase, interviews me to clarify the requirements, and lays out a multi-step plan. I just say &ldquo;implement ticket XX.&rdquo; Activate it with Shift+Tab in the CLI.</p>I spend more time writing ticket descriptions than writing code.

Examples of what success looks like, plus references to similar past work, let Claude ship a feature in 20 minutes. The ticket becomes the spec.

I use Claude Code’s plan mode. It explores the codebase, interviews me to clarify the requirements, and lays out a multi-step plan. I just say “implement ticket XX.” Activate it with Shift+Tab in the CLI.

]]>A SPEC.md is the differencehttps://aguilera.ee/blog/spec-file/Wed, 18 Feb 2026 00:00:00 +0000eduardo@aguilera.ee (Eduardo Aguilera)https://aguilera.ee/blog/spec-file/<p>A SPEC.md file is the difference between vibe coding and software engineering.</p> <p>For a complex feature I write a spec and hand it to the agent to turn into an implementation plan. What goes in it:</p> <ul> <li><strong>Introduction.</strong> &ldquo;You are building a dashboard to change settings on a security platform.&rdquo;</li> <li><strong>Problem.</strong> If it knows why, it finds solutions I didn&rsquo;t think of.</li> <li><strong>Scope.</strong> Keeps it focused on what I want.</li> <li><strong>Out of scope.</strong> Paradoxically, this sharpens the scope.</li> <li><strong>Functional requirements.</strong> The list of tasks to complete.</li> <li><strong>Non-functional requirements.</strong> Respects my architectural decisions.</li> <li><strong>References and glossary.</strong> Points it at the knowledge it should read.</li> </ul> <p>The spec is where the thinking happens. The code is the easy part.</p>A SPEC.md file is the difference between vibe coding and software engineering.

For a complex feature I write a spec and hand it to the agent to turn into an implementation plan. What goes in it:

  • Introduction. “You are building a dashboard to change settings on a security platform.”
  • Problem. If it knows why, it finds solutions I didn’t think of.
  • Scope. Keeps it focused on what I want.
  • Out of scope. Paradoxically, this sharpens the scope.
  • Functional requirements. The list of tasks to complete.
  • Non-functional requirements. Respects my architectural decisions.
  • References and glossary. Points it at the knowledge it should read.

The spec is where the thinking happens. The code is the easy part.

]]>