What Difference Does the Coding-Agent Method Make?

I have been building with coding agents using different development approaches.

Sometimes the agent gets a relatively direct instruction. Sometimes I use /goal. Sometimes the work is structured through Agent Skills. I have also used Superpowers, primarily with Claude Code, and Spec Kit / Spec-Driven Development for more structured changes.

Initially, I was trying to answer a relatively simple question:

Which approach produces the best resul?

After a while working through a number of implementations, the more interesting question became:

What actually changes when we put different forms of control between human intent and agent implementation?

That shift in perspective is probably the most useful insight from this experiment.

The question changed

The different approaches are not necessarily competing implementations of the same thing.

They intervene at different points in the SDLC process.

THE QUESTION CHANGED

   Initially                                Now

┌───────────────────────┐          ┌──────────────────────────────┐
│ Which coding-agent    │          │ What does each layer of      │
│ toolkit is best?      │    →     │ development discipline       │
│                       │          │ actually change?             │
└───────────────────────┘          └──────────────────────────────┘
       "Who wins?"                       "What changes?"

That distinction matters because /goal, Agent Skills, Superpowers and Spec Kit are solving different control problems.

Comparing them as if they were interchangeable products risks missing the more important architectural question: which form of control is needed for which kind of change?

What I actually tried

Across the work I have been doing with Ideas-to-Life, I have encountered several different mechanisms.

Spec Kit has been the most explicit example of Spec-Driven Development. For ambiguous or potentially consequential changes, the workflow can move through specification, clarification, planning, task breakdown, analysis, implementation and converge.

Agent Skills have provided reusable workflow and repository context. Rather than repeatedly explaining how work should be done, the relevant behaviour and institutional knowledge can be made available to the agent at the point of execution.

Superpowers introduced a more opinionated development methodology. In my experience, this was primarily used with Claude Code and included practices such as brainstorming, writing plans, test-driven development, systematic debugging and code review.

/goal introduced a different dimension: execution persistence and autonomy. It can allow an agent to pursue a defined objective over a longer-running execution rather than treating every interaction as an isolated instruction.

These are different mechanisms that became increasingly clear as I used them.

Different mechanisms, different controls

A useful model emerging from the experiments looks something like this:

Different mechanisms, different controls

┌─────────────┐
│ Human Intent│
└──────┬──────┘
       │
       ▼
┌─────────────────────┐
│ Direct instruction  │  What do I want done?
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ /goal               │  How long / autonomously?
│ Execution model     │
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ Agent Skills        │  How should the agent work?
│ Workflow + context  │
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ Superpowers         │  What development methodology
│ Development method  │  should it follow?
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ Spec Kit / SDD      │  What must become true?
│ Change contract     │
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ Repository context  │  What constrains the change?
│ Rules + knowledge   │
└──────────┬──────────┘
           ▼
┌─────────────────────┐
│ Validation          │  How do we know it worked?
│ Evidence            │
└──────────┬──────────┘
           ▼
      Implementation

These mechanisms are complementary, not necessarily competing alternatives.

This is not a maturity ladder.

A project does not necessarily become “better” by moving from one mechanism to another.

Instead, each mechanism adds a different kind of constraint or capability.

What the evidence suggests

The clearest observation so far is that specification and agent behaviour are complementary controls.

Spec-Driven Development constrains the change.

Agent Skills constrain how the agent approaches the work while making the change.

That distinction became particularly useful in the CAS work.

A specification can establish requirements, success criteria and the intended outcome. But it does not automatically guarantee that an agent will discover the repository context correctly, follow local conventions, apply the appropriate workflow or validate the resulting implementation thoroughly.

Conversely, a highly disciplined development workflow cannot compensate for an unclear change contract.

The two controls address different sources of uncertainty.

                  HUMAN INTENT
                       │
                       ▼
              ┌────────────────┐
              │ Specification  │
              │ What must be   │
              │ true?          │
              └───────┬────────┘
                      │
                      ▼
              ┌────────────────┐
              │ Agent workflow │
              │ How should the │
              │ work happen?   │
              └───────┬────────┘
                      │
                      ▼
              ┌────────────────┐
              │ Repository     │
              │ What constrains│
              │ the change?    │
              └───────┬────────┘
                      │
                      ▼
              ┌────────────────┐
              │ Implementation │
              └───────┬────────┘
                      │
                      ▼
              ┌────────────────┐
              │ Evidence       │
              │ Did it actually│
              │ work?          │
              └────────────────┘

Another important observation is that specification completeness is not implementation correctness.

I have seen specifications become internally consistent, complete and well-structured while implementation still required further discovery, testing and correction.

In one case, regression testing exposed a missing content-selection requirement. The appropriate response was not simply to add another agent or blindly continue implementation. The new evidence resulted in refinement of the requirements.

That was an important reminder:

Testing is not only a verification mechanism. It can also generate new architectural knowledge.

What `/goal` changes

/goal is particularly interesting because it operates at a different layer.

It does not replace a specification.

It does not inherently define requirements.

Instead, it changes the execution model: how persistently and autonomously the agent can pursue an objective.

That distinction is important.

A long-running autonomous agent with an ambiguous objective can simply execute ambiguity for longer.

The value of autonomy therefore depends heavily on the quality of the objective, the available context and the validation mechanisms around it.

This reinforces something I have increasingly seen across the work:

More autonomy does not automatically mean more control.

Sometimes the opposite is true.

Autonomy becomes useful when the surrounding system makes the boundaries of acceptable execution sufficiently explicit.

What I still cannot claim

The experiments are useful, but they are not a controlled benchmark.

I have deliberately resisted turning the experience into a ranking such as:

Spec Kit is better than Superpowers, which is better than Agent Skills.

The evidence does not support that conclusion.

The approaches were used on different changes, repositories and problem types. Some sessions combined multiple mechanisms. Superpowers, in particular, was primarily explored with Claude Code rather than as a clean isolated experiment within the Antigravity CLI.

There is also no clean no-SDD control group in the evidence I have collected so far.

So I cannot honestly claim that one methodology produces a quantified improvement in productivity, correctness or quality.

What I can say is that the experiments have made the control surfaces much clearer.

The emerging model

I am increasingly thinking about coding-agent development less as choosing a single methodology and more as composing the controls required by the change.

                         ┌─────────────────────┐
                         │    HUMAN INTENT     │
                         └──────────┬──────────┘
                                    │
                         ┌──────────▼──────────┐
                         │   CHANGE CONTRACT   │
                         │  Specification /    │
                         │       SDD           │
                         └──────────┬──────────┘
                                    │
                 ┌──────────────────┼──────────────────┐
                 │                  │                  │
        ┌────────▼───────┐ ┌────────▼────────┐ ┌──────▼─────────┐
        │ Agent workflow │ │ Repository      │ │ Execution      │
        │ Skills /       │ │ context /       │ │ autonomy /     │
        │ methodology    │ │ constraints     │ │ /goal          │
        └────────┬───────┘ └────────┬────────┘ └──────┬─────────┘
                 │                  │                 │
                 └──────────────────┼─────────────────┘
                                    │
                         ┌──────────▼──────────┐
                         │   IMPLEMENTATION    │
                         └──────────┬──────────┘
                                    │
                         ┌──────────▼──────────┐
                         │     VALIDATION      │
                         │ Tests + review +    │
                         │ runtime + alignment │
                         └─────────────────────┘

The implication is subtle but important.

The question is no longer:

Which agent methodology should I standardise on?

It is becoming:

Which controls does this change need?

A small, well-understood change may need very little structure.

An ambiguous brownfield architectural change may need explicit discovery, specification, repository context, a disciplined workflow, human approval and multiple validation gates.

The amount of structure should therefore be proportionate to uncertainty and consequence.

What I want to test next

The obvious next step is to make the comparison more rigorous.

Rather than continuing to accumulate anecdotal experience across unrelated changes, I want to deliberately test the same or equivalent classes of change using different levels of structure.

In particular:

a relatively direct implementation baseline;
an agent using execution autonomy such as /goal;
Agent Skills providing workflow and institutional context;
a methodology such as Superpowers;
Spec Kit / SDD providing an explicit change contract;
and combinations of these controls.

The interesting measurements would not simply be “did the code work?”

I would want to look at things such as:

clarification required;
rework;
regressions;
missed requirements;
architectural drift;
validation failures;
human intervention;
time to a satisfactory result;
and confidence in the resulting change.

That would move the experiment from observational learning towards something closer to an empirical comparison.

For now, however, the more valuable discovery is conceptual.

I started by looking for the best coding-agent method.

I am ending up with a model of governed agentic execution, where specification, workflow, context, autonomy and validation each provide a different form of control.

Key Lessons Learned

Different agent-development mechanisms solve different problems. /goal, Agent Skills, Superpowers and Spec Kit should not automatically be treated as competing alternatives.
Specification and agent behaviour are complementary controls. SDD constrains what must become true; Skills and development methodologies constrain how the agent works towards it.
Autonomy is not the same as control. /goal can increase execution persistence, but the quality of the objective, context and validation still determines the quality of the outcome.
Specification completeness does not prove implementation correctness. Testing, runtime behaviour, repository state and governance alignment remain necessary evidence.
Testing can generate architectural knowledge. A failed or incomplete validation can reveal a missing requirement rather than merely an implementation defect.
The right question may be “which controls does this change need?” rather than “which toolkit is best?”

Where This Leaves Me

The coding agent is becoming less interesting to me as an isolated implementation tool.

What is becoming more interesting is the system around it.

If a general-purpose agent can implement increasingly complex changes, then the differentiator may not simply be the intelligence of the agent.

It may be the quality of the contracts, context, constraints and evidence surrounding that intelligence.

That takes me back to the broader Ideas-to-Life work.

The emerging architecture is not just about getting an agent to write code.

It is about creating a system in which human intent can be progressively transformed into something an agent can execute, and then into evidence that the resulting change is actually what was intended.

That is a much more interesting problem to keep experimenting with.

How I made it

I did not start by asking an AI to tell me which development method was better.

Instead, I went back to the actual coding-agent sessions and treated them as evidence. I selected eight sessions that contained meaningful examples of Spec Kit, Agent Skills, Superpowers or /goal, then examined what was actually invoked, what workflow followed, where clarification or refinement occurred, and what happened during implementation and validation.

This gave me a much more grounded basis for separating what I had actually observed from what I was merely assuming.

                 CODING-AGENT EXPERIENCE
                          │
                          ▼
                ┌──────────────────┐
                │ Select relevant  │
                │ sessions         │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ Read the actual  │
                │ session history  │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ Identify the     │
                │ method / control │
                │ actually used    │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ Compare workflow │
                │ and behaviour    │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ Extract observed │
                │ outcomes &       │
                │ tensions         │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ Separate         │
                │ evidence from    │
                │ interpretation   │
                └────────┬─────────┘
                         │
                         ▼
                ┌──────────────────┐
                │ Form the         │
                │ architectural    │
                │ hypothesis       │
                └──────────────────┘

That process also exposed an important limitation: the sessions were not controlled experiments. Different projects, changes and combinations of techniques were involved, and some approaches were not represented as clean isolated baselines.

So the result is not a benchmark.

It is a structured synthesis of observed practice, which is enough to change the question and formulate a better experiment.

Note:

This Weekly Learning was produced using the Ideas to Life Weekly Learning system map.