Find the Verbs

Every system, no matter how complex, is just a collection of actions. Things that happen. Inputs that get transformed into outputs. Data that moves from one place to another. Strip away the UI, the infrastructure, the twelve-layer architecture diagram someone drew in Excalidraw--and what's left are verbs.

I've been building software for over twenty years, and the single most useful habit I've developed for specing out new systems is this: find the verbs first.

This was always a useful exercise. But with AI-assisted development, it's become something more fundamental. Verb extraction is how you give AI precise, actionable input instead of vague descriptions that produce vague output. It's the difference between a focused spec and a wish list.

What I Mean by Verbs

When I say "verbs," I don't mean use cases or user stories or formal methodology. I mean the irreducible actions that define what a system actually does.

Take Worktale, the developer journal I just shipped. Before I wrote a single line of code, I distilled the entire product down to two verbs:

extract  →  from git history
tell     →  the story

That's it. That's the whole product. Extract and tell. Everything else--the SQLite database, the TUI dashboard, the streak tracking, the Ollama integration--is in service of those two verbs. Every feature I considered got filtered through a simple question: does this help us extract better, or tell better? If the answer was neither, it didn't ship.

Two verbs gave me a spec. The spec gave me a product. The product shipped in weeks, not months.

The Noun Trap

Most people start with nouns. They think in entities. "We need a User model, and an Organization model, and a Project model, and a Task model..." Before anyone has written a line of code, there's an ER diagram with forty tables and a backlog that stretches to next quarter.

Nouns feel concrete. You can draw boxes around them, name their properties, debate their relationships. But nouns don't tell you what the system does. They tell you what it has. And what a system has is only interesting in the context of what it does with it.

Now--some systems have genuine complexity that lives in the domain model itself. Financial instruments, healthcare workflows, logistics networks. In those domains, the entities and their relationships are where the hard problems live, and verb extraction doesn't replace that kind of modeling. But even there, starting with "what does this thing do" before "what does this thing have" gives you a sharper entry point.

For most systems, though, verbs cut through the noise. When you start with actions, the nouns emerge naturally--and only the nouns you actually need. You don't design a User table because it feels right. You design one because the verb "authenticate" requires it.

Verb Extraction in Practice

Here's how I actually do this. Take any product idea--yours, a client's, something you're specing out on a whiteboard. Describe it in plain language. Then ruthlessly delete every noun, every adjective, every qualifier. What's left?

A few examples from things I've built:

Notice how few verbs you need to capture the essence. A focused tool might have two. A complex platform might have eight or ten. The number isn't the point--the reduction is. You're compressing a vague idea into precise actions that you can hand to an AI and say "build this."

The goal isn't to simplify for the sake of simplicity. It's to find the essential complexity--the irreducible core of what you're building--and separate it from the accidental complexity that accumulates around it. And critically, it's to produce input that AI can actually do something useful with.

Define, Then Execute

Once you have the verbs, the spec writes itself. Each verb becomes a boundary. What goes in? What comes out? What can go wrong? Answer those three questions for each verb and you have a technical spec that's concise, testable, and--most importantly--ready for AI to act on.

For Worktale's extract verb:

• In: A git repository path
• Out: Structured commit data in SQLite
• Fails when: Path isn't a repo, repo has no commits, database is locked

For Worktale's tell verb:

• In: Extracted commit data
• Out: Human-readable summaries, streaks, daily digests
• Fails when: No data extracted yet, AI engine unavailable (graceful fallback)

That's a spec. Not a comprehensive one--but a correct one. It captures what the system does at its most fundamental level. And more importantly, it's in a format that an AI can immediately act on. You've just translated a product idea into structured input. Everything from here is execution--and execution is what AI is good at.

The AI Force Multiplier

This is the real reason I'm writing this article. Verb extraction was always a useful mental model. But with AI-assisted development, it's become the single most important step in my workflow. It's the difference between AI that helps and AI that hallucinates a framework.

"Build me a project management tool" produces a generic CRUD app with every feature ever imagined. A set of verbs with clear boundaries produces something you can actually ship.

System: extract commit data from git repos into SQLite.
         tell the story via TUI dashboard, daily digests, streaks.

Extract: reads .git directory, parses commit log, stores structured
         records. No network calls. No code content--metadata only.

Tell:    reads SQLite, renders terminal UI with three views.
         Optional: generate natural language summaries via local LLM.

That prompt produces focused, buildable code. Not because the AI is smarter--but because the input is precise. Verbs with boundaries are basically function signatures. Function signatures are something AI understands natively.

The spec phase used to take days of whiteboarding and document writing. Now it takes an hour of verb extraction followed by a conversation with an AI that can validate boundaries, surface edge cases, and start scaffolding implementation. The feedback loop is minutes, not meetings.

The developers getting the most out of AI right now aren't the ones writing better prompts. They're the ones who've already done the hard thinking before the AI gets involved. AI is an execution engine. You still need to know what to execute.

The Framework

Every system I've seen ship fast and stay stable had the same origin: someone, early on, could articulate what it did in plain action terms. Here's how to get there:

Find the verbs. Define the boundaries. Hand it to AI. The hard part was never the code--it was knowing what to build.

I help teams spec and ship software faster. If you're working through a new system or stuck on an existing one, get in touch or check out my consulting services.