Chapter 3: The Jetty Method Philosophy

The most important thing you'll create isn't code. It's the specification of what the code should do.

Before any code exists, you write down exactly what the software should do in plain English. Not as a vague document for humans to interpret, but as a contract the AI will implement and the tests will verify. This is what Behavior-Driven Development (BDD) achieves. It structured scenarios like "Given I'm logged in, when I click delete, then the item should be removed."

You can read that. You can argue about whether it captures what you want. You can add scenarios for situations you forgot. And you can do all of this before anyone writes a line of code.

This matters more for non-engineers than anyone else. You can't read code well enough to verify it's correct. But you can read these scenarios. They're your contract with the AI, and they're your proof that what got built matches what you asked for.

The scenarios become documentation that never goes stale. If the software's behavior changes, either the scenarios change with it (intentionally) or the tests fail (catching an accident). The documentation and reality stay synchronized because they're the same thing.

Not all software needs the same level of care. A prototype for five friends doesn't need the same error handling as a payment system processing real money.

The Jetty Method addresses this through mode progression, the details of which we’ll get into later. Speed mode answers: does it work at all? You implement the feature assuming everything goes right. No error handling, no validation, no edge cases. Just the core functionality, proven to work when conditions are ideal. Stable mode adds error handling, input validation, and edge case coverage. Production mode adds security hardening, performance optimization, and monitoring.

Each step is manageable. Each step builds on verified work from the previous step. And you don't always need every step. Internal tools might stop at stable mode. The method tracks your project's state and adjusts expectations accordingly.

This progression only works if changes can't corrupt what's already working. So you never work directly on the main codebase. Instead, you work in isolated copies called worktrees where you can experiment freely. Your changes only merge back when they're verified. If something goes wrong, you haven't corrupted the foundation.

The combination of incremental modes and isolated workspaces prevents the fragile tower from Chapter 1. You're building layer by layer, but each layer is solid before the next one begins.

Knowing what to do next is often harder than doing it.

Engineers spend years developing instincts for sequencing work correctly. You don't have those instincts. And the AI doesn't inherently know the right sequence either. It can write code, but it doesn't know whether you should be writing code right now or planning first.

The Jetty Method solves this two ways. First, every piece of work gets classified before you start. A bug is different from a feature which is different from a refactor. Each type routes to a workflow designed for that type of work. This prevents treating complex work as simple (leading to fragile implementations) or simple work as complex (wasting time).

Second, each workflow defines a sequence of steps. What questions to ask. What to build in what order. What to verify before moving on. The workflows encode expertise that would normally take years to develop. Follow them, and you're protected from the chaos of vibe coding.

This might sound restrictive. But these workflows were designed through extensive trial and error. They represent sequences that actually work. You can deviate when you have good reason, but if you're new to this, following the guidance will serve you better than blazing your own trail.