Chapter 3: The Jetty Method Philosophy

For many professional engineers, tests used to be a chore. It was a relatively tedious activity that pre-empted the exciting stuff.

AI changed that. Writing tests used to require the same engineering skill as writing the software itself. Now an AI assistant can generate and maintain tests from plain English descriptions. The barrier that made testing an engineering only activity has largely disappeared. What remains is the most valuable part: deciding what the software should do.

That's where Behavior-Driven Development comes in. BDD lets you write scenarios like "Given I'm logged in, when I click delete, then the item should be removed." Plain English. No code. You can read it, argue about whether it captures what you actually want, and add scenarios for situations you forgot. And this all happens before anyone writes a line of code.

These scenarios serve three roles simultaneously. They're your specification, telling the AI exactly what to build. They're your tests, automatically verifying the software does what you described. And they're your documentation, always reflecting what the software actually does because they are what the software is measured against.

That last point matters more than it might seem. Traditional documentation drifts from reality the moment someone changes code and forgets to update the docs. With BDD scenarios, drift is impossible. If behavior changes, either the scenarios change with it (intentionally) or the tests fail (catching an accident). Documentation and reality stay synchronized because they're the same thing.

For non-engineers, this is especially powerful. 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. Tests aren't just a safety net anymore.

"

They're the primary way you communicate requirements, verify results, and maintain control over software you didn't write yourself.

The Jetty Method puts BDD scenarios at the center of everything. Not because testing matters in the old sense of catching bugs. Because in a world where AI writes the code, the plain English description of what it should do is the most important artifact you'll create.

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.