Seedwork: A New Methodology for Building with AI

Why everything I learned about software development is both right and wrong

I'm old enough to remember when extreme programming, the predecessor to agile, was fringe, ground upon, and scorned in the corporation.

I started my career in waterfall. Thick specification documents. Change control boards. The belief that if you just thought hard enough upfront, you could anticipate well. Then I adopted Extreme Programming and it felt radical—and it felt right.

Agile won. The core advance was simple: requirements change, so embrace change. Stop pretending you can know everything upfront. Iterate, ship, learn.

That insight served us for twenty years. And now it needs to evolve again.

What Agile Got Right (And What It Assumed)

Agile solved the requirements problem. It acknowledged that users don't know what they want until they see it, that markets shift, that the world changes. It gave us tools for adapting: sprints, retrospectives, continuous delivery.

But agile assumed something that seemed obvious at the time: the software itself is deterministic. You write code, it runs the same way every time. The inputs and outputs are predictable. The system does precisely what you programmed it to do—no more, no less.

When you build with large language models, that assumption is broken.

What Breaks When the System Isn't Deterministic

A Large Language Model (LLM)-based system isn't likely to do exactly the same thing twice. Give it the same input, you should get slightly different outputs. That sounds like a bug. It's actually the core value.

I've spent the past year learning how we can build AI-native applications for mission-driven organizations. And I keep having the same experience: the most valuable thing the system does is something I didn't plan for.

Agile gave us user stories, acceptance criteria, definition of done. But what's the acceptance criterion when the system might do something different—and better—than you specified?

Traditional software engineering asks: "Does it meet the requirements?"
LLM-native development asks: "What else will it do?"

The shift is fundamental:

Martin Fowler wrote recently about discovering that his own AI coding assistant "thought about things in ways I hadn't considered." Kent Beck suggested that when the cost of trying something drops to near zero, the nature of development itself changes. They're pointing out that the way LLMs work is not a problem to solve—it's a capability to cultivate.

Seedwork: Cultivation Over Construction

The AI, Claude, named the methodology we need Seedwork.

A seed contains latent potential. You don't build a plant—you provide conditions for growth. You work with species that thrive in a particular environment. The gardener's job isn't to control growth, but to cultivate it.

We need a similar methodology when building with LLMs. Our work is cultivation: providing the right context, the right tools, the right connection to problems. We plant seeds, create conditions, and then—critically—pay attention to what grows.

The core values:

• Emergent capabilities over specified requirements
• Cultivation over construction
• Discovery through use over upfront design
• Native strengths over forced behaviors

The metaphor matters. "Software engineering" implies construction—blueprints, building, precise specifications. Seedwork implies something else: you're working with systems that have their own tendencies. The job is to notice what thrives and nurture it.

What This Means for Mission-Driven Organizations

I have spent my career working primarily with nonprofits and social enterprises. These organizations are asking: "Should we be investing in AI?"

In the past, applying AI required data science teams, infrastructure, expertise. It was enterprise-grade or nothing.

That's changed. The new tools—Claude, GPT-4, open-source models—have facilitated access to AI. A small team can now build things that would have required a department five years ago.

But here's what matters for mission-driven work: Seedwork favors organizations that know their problems deeply.

Traditional software development rewards specification precision. Can you write detailed requirements? Do you have a product manager who can think through edge cases?

Seedwork rewards something different: Can you recognize unexpected value when you see it?

Organizations with deep domain expertise are ideally positioned for Seedwork. You don't need to specify everything upfront. You need to recognize what's growing and know which aspects are valuable.

The Transition

I've lived through two of these transitions now. Waterfall to agile felt like a very exciting conversion. We had to unlearn the belief that more planning was always better. We had to trust iteration, trust the process of discovering requirements through building.

Agile to Seedwork feels similar but different. We still iterate. We still ship early and often and learn and adopt. But now we're also watching for emergence. We're asking not just "Does it work?" but "What else does it do?"

The skills transfer. Agile developers who learned to embrace changing requirements can learn to embrace emergent capabilities. The mindset of curiosity, of shipping to learn, of staying close to users—all of that remains valuable.

What's new is the relationship to the system. It's not a tool anymore. It's closer to a collaborator—one with latent capabilities you're still discovering.

Getting Started

If you're considering building something with AI, a few practical thoughts:

Start with a real problem you understand deeply. The best Seedwork happens when you can recognize unexpected value because you know the domain. Generic AI experiments rarely reveal much.

Ship early to real users. You cannot discover emergent capabilities in a sandbox. The magic happens when the system meets actual human needs in unpredictable ways.

Pay attention to surprises. When the system does something you didn't plan for, don't immediately "fix" it. Ask first: is this valuable? Some of your best features will be discovered, not designed.

Work with the grain. Notice what the AI naturally does well and lean into that. Don't fight the model's tendencies—cultivate the valuable ones.

Keep the scaffolding minimal. The intelligence is in the model. Your code connects it to context and action. Resist the urge to over-engineer.

The World Isn't Flat Anymore

Waterfall gave us discipline. Agile gave us adaptability. Seedwork gives us something new: a methodology for working with systems that surprise us. For cultivating emergence rather than controlling execution. For building software that might, if we pay attention, do something better than we imagined.

The seeds are planted. What grows next is up to us—and partly up to them.