DevSpark: Change Must Start With a Real Need

The feature I built for myself

Early in my career, I built something I was proud of. It was clever, it used a technique I had been wanting to try, and I could not wait to show the client. They looked at it politely, asked a few questions, and moved on to the problem they had actually come to discuss.

The feature was not bad. It just was not theirs. I had built it for me.

That lesson took a few more rounds to settle, but it changed how I evaluated my own enthusiasm. The best work was rarely the most inventive thing in the room. It was the work aimed most exactly at a need someone had already expressed. Once I started asking what business problem a feature solved before getting excited about how to build it, the work landed differently. Clients did not merely accept it. They had been waiting for it.

I also began to recognize the opposite pattern before it cost me much: the particular excitement that comes from a feature being clever rather than needed. The tell is often simple. I am more eager to demo the feature than to explain the problem it solves.

I call that getting sidetracked by sizzle. The sizzle is only the symptom, though. The discipline underneath it is more useful: build in response to a need that can be shown to exist, not one I am guessing might be valuable.

DevSpark is that discipline written down tightly enough for an AI agent to follow it.

Change has to come from somewhere

Nothing in DevSpark should be built merely because it would be interesting to build. A real reason might be a business request, a user problem, a constraint discovered in production, or an assumption that stopped holding. The source matters because it gives the work something to answer to.

Software systems do not improve by changing at random. They change because their environment puts pressure on them. A market shifts. A user finds a painful edge case. A dependency becomes unsafe. A team learns that the original design does not survive contact with reality. Without that pressure, change can become motion mistaken for progress.

This is not a new product philosophy. It is agile development without the convenient fiction that every backlog item arrived with equal legitimacy. Discovery should be grounded in signal. The backlog should reflect actual priority rather than a collection of pet ideas. Refinement should settle both what is being built and how it will be verified. Execution should follow a plan that is clear enough to challenge.

The difference in DevSpark is not that it invents a new lifecycle. It makes an existing one legible enough for an agent to participate in it.

A human teammate picks up context by osmosis. They sit in a meeting, remember a decision from a previous sprint, notice a concern in someone’s tone, or ask a question because a requirement feels incomplete. An agent has none of that unless the context is recorded somewhere it can reach and interpret. If the process depends on invisible context, the agent will fill the gaps with plausible guesses. Plausible guesses are where sizzle finds room to grow.

Making the lifecycle explicit

DevSpark maps its commands to familiar product and engineering activities. The names are different enough to describe the framework, but the underlying discipline is recognizable.

Explore is discovery

Explore begins with pressure from outside the framework. It does not open a blank canvas and ask what might be fun to build. It starts with what is known: a request, a failure, a market change, a gap in the current system, or a question worth investigating.

This stage is deliberately collaborative. A person brings intent and context. An agent can inspect the existing repository, find related work, test assumptions, and expose questions that are easy to miss when the idea is still exciting. Sometimes more than one model is useful because different models notice different failure modes. The point is not to outsource judgment. It is to make the space around the decision easier to see.

Roadmap is the backlog

Exploration should converge. A roadmap turns the useful parts of discovery into a shortlist of features worth naming as work. That sounds administrative until a project has accumulated enough ideas that nobody can explain why the next item is next.

The roadmap is where interest meets pressure. A compelling technology may still belong in the backlog, but it does not get promoted simply because it is compelling. The question is what need it answers, who experiences that need, and what makes it worth addressing now.

Specify is refinement

Specification is the point where a feature stops being a conversation and becomes a commitment that can be examined. It describes the behavior, the boundaries, the acceptance conditions, and the constraints that implementation must respect.

For an agent, this explicitness is not ceremony. It is operating context. The specification has to remove the ambiguity that a human teammate might resolve through a quick conversation. That includes the technical shape of the work when the technical shape affects the outcome.

DevSpark’s prompt metadata extends this idea. Frontmatter can carry the authoritative constraints through the lifecycle, so downstream commands do not have to rediscover what the specification already decided. I explored that mechanism in Prompt Metadata: Enforcing the DevSpark Constitution.

Plan and critic are compressed sprint planning and review

Once the specification is ready, DevSpark’s planning commands work through implementation shape, task boundaries, risks, and evidence. Analysis and critique create places to question the plan before code makes the cost of changing it higher.

That is the part of the process most likely to look slow when everything is going well. It is also the part that keeps an agent from racing toward the first technically plausible solution. Fast execution is valuable after judgment has happened. Before that point, speed mostly increases the amount of confident work that may need to be undone.

Implement is sprint execution

Implementation is where a coding agent is most naturally useful. The work has a defined purpose, a known set of constraints, and tasks that can be checked against evidence. The agent can move quickly through repetitive code changes, tests, and local corrections while the human remains responsible for whether the work is actually the right work.

That division is important. The agent’s speed does not eliminate judgment; it makes the timing of judgment more consequential. If the earlier stages are vague, implementation turns ambiguity into code at machine speed.

Release is assimilation

The lifecycle does not end when the code compiles or the pull request merges. Release makes the change part of the business and the current state of the system. The feature is no longer a backlog item waiting to become real. It is now something the team can rely on, measure, maintain, and learn from.

That final step changes the next round of discovery. The knowledge base is richer. A previous decision, limitation, or result becomes part of what is currently true. The framework does not invent its own next pressure, but it can meet that pressure with better information than it had last time.

Why there is no DevSpark CLI

An earlier version of DevSpark had a standalone command-line executable. It was inherited from the framework’s original spec-kit-based port, and it was not being used by the actual workflow. Maintaining unused tooling is a liability even before the philosophical questions begin.

The deeper reason for retiring it is the same discipline the framework applies elsewhere: put judgment where judgment is needed, and keep deterministic execution in small scripts that do not need to reason about context.

A CLI harness is a fixed guardrail. That can be exactly right for repeatable operations such as generating files or validating a known structure. It is less useful as the place where a context-dependent product decision is made. Prompts give a capable agent room to inspect the situation, ask what is missing, and explain why a proposed change may not belong yet.

Removing DevSpark’s own CLI made the framework apply its principles to itself. The entry point should not be more elaborate than the problem requires. If a script can perform a deterministic task, use a script. If the work requires interpretation, put that interpretation in the agent-accessible process where it can be examined.

This is also why dogfooding matters. When the framework is used to refine itself, small inconsistencies become operational problems rather than theoretical concerns. I wrote about that experience in Dogfooding DevSpark: Building the Plane While Flying It.

A process that can resist its own enthusiasm

None of this is really about software process. It is the same instinct that has shaped much of my career: distrust excitement that is not tethered to a real need, and change something because the world outside gave you a reason to change it.

DevSpark did not invent that discipline. It gave me a way to write it down precisely enough for something other than a person to follow. That precision is useful even when no agent is involved. A process that can explain why a feature exists, what evidence would make it complete, and what changed after release is easier for a team to trust.

The real test is not whether a framework can generate more work. It is whether it can keep work connected to reality as the system, the people, and the pressure around it change. The clever feature will always be available. The harder achievement is knowing when it is not the feature that needs building.

Explore More

Related articles that extend the thinking:

• Dogfooding DevSpark: Building the Plane While Flying It — what happens when the framework becomes its own workbench.
• Prompt Metadata: Enforcing the DevSpark Constitution — how constraints travel through the specification lifecycle.
• The Folder That Became a Discipline — how a real audit request grew into a planning and drift-detection practice.
• Sidetracked by Sizzle: Staying Focused on True Value — the career lesson behind evaluating technology by outcomes rather than appeal.