Agile is dead. Long live S2S.
Spec to Signal (S2S): Prioritizing signal over ceremony in an AI-native era
Spec to Signal (S2S)
Software is no longer scarce.
AI collapsed the cost of implementation. What used to take weeks now takes hours.
When execution became cheap, something subtle but profound happened. The constraint didn’t disappear, it moved. The friction shifted upstream. The hard part is no longer writing code or shipping features. It’s knowing what to build, why it matters, and how to tell, quickly and honestly, whether you’re headed in the right direction.
Clarity is now the bottleneck.
I run a software development agency that works with startups and Fortune 500 companies. We have an unusually strong team: senior developers with decades of experience, people who’ve built systems at massive scale, people who could easily lead most engineering organizations.
And yet, over the past few months, I built a social network entirely on my own, in my spare time.
No delegation.
No internal team.
No tasking my senior developers, despite having them.
That fact unsettled me.
Not because building something solo is impressive, it isn’t the goal, but because it forced a question I couldn’t ignore:
Why was it faster to do this alone than to involve a team I deeply respect?
The answer wasn’t ego.
And it wasn’t capability.
It was process.
The way we’ve learned to build software no longer fits the shape of the work.
So I began to work differently.
I started front-loading intent instead of tasks. Writing specifications as hypotheses rather than contracts. Letting AI collapse execution while I focused on judgment, direction, and learning. I stopped optimizing for delivery and started optimizing for signal.
I’ve come to think of this approach as S2S: Spec to Signal.
You move from clearly articulated intent directly into a live system, then listen carefully to what comes back. The specification expresses assumptions. The deployed product produces evidence. The work is closing the distance between the two.
S2S borrows what still works from Waterfall, the discipline of thinking deeply before moving fast, and what still works from Agile, the insistence on learning through iteration. But it drops the ceremony, the handoffs, and the process that existed to manage human execution costs that no longer dominate.
What remains is a quieter loop, one that only makes sense in a post-AI world.
When Process Becomes Drag
My team is currently staffed on a large fintech platform. We’ve been using a modified Agile process there for a long time. Given the regulatory constraints, the security requirements, the surface area, and the risk profile of that system, it works. It’s deliberate. It’s careful. It’s appropriate.
But this project was different.
I was moving at lightning speed. Ideas were turning into artifacts almost as fast as I could articulate them. I knew instinctively that introducing any traditional process, planning cycles, role handoffs, formal ceremonies, would immediately collapse velocity.
That doesn’t mean the goal is to build products alone. It isn’t. Parallelism still wins. Teams still matter.
The issue wasn’t headcount.
It was coordination.
When I told my team I was launching a social network I had built myself, the reaction was predictable: confusion, curiosity, a bit of head-scratching. Why weren’t they pulled in?
I explained it this way:
By the time I explain the intent, the goals, the brand, the timeline, the constraints, the assumptions, and the codebase — by the time we segment ownership, align on interfaces, and schedule ceremonies, I would already have tested several critical assumptions and gathered real signal from the world.
Achieving signal in hours instead of weeks or months.
That tradeoff is no longer defensible.
Ceremony Doesn’t Scale With Speed
Standups, sprint planning, backlogs, wikis, and retros, these were already fragile abstractions. With AI, they become actively counterproductive.
Agile assumes roughly uniform execution speed across a team. AI obliterates that assumption. Some people move an order of magnitude faster than others, not because they’re better engineers, but because they’re fluent in a new mode of work. The process cannot absorb that variance without becoming drag.
If your development cycles aren’t five to ten times faster than they were a few years ago, you’re already behind.
And the point of all this speed is not output.
It’s signal.
Signal is direction. Signal is correction. Signal is learning.
This has always been the intention of product development, but the intent gets lost in a sea of process. The goal quietly shifts from learning from the thing to building the thing.
Progress quietly gets redefined.
The velocity of building becomes the metric: story points completed, tickets closed, features shipped. Movement is visible. It feels like progress.
What disappears is insight.
How many assumptions did we test? What did we learn that changed our direction? How much uncertainty did we actually remove?
The work becomes building the thing, not learning from the thing.
Imagine being dropped into the middle of a vast field, blindfolded, spun around until you’re completely disoriented. Your goal is to reach a specific point one hundred meters away. Now imagine that with every step you take, you receive immediate feedback: right direction or wrong direction.
The algorithm becomes simple.
Take a step.
If it’s wrong, step back.
Adjust.
Repeat.
You won’t wander far. You won’t drift. You’ll converge.
That’s product development now. Not perfect planning, but relentless correction. The job is to maximize the frequency and clarity of feedback, qualitative and quantitative, so direction emerges faster than doubt.
When build cost collapses, the work shifts.
Product judgment becomes dominant.
Engineering supports velocity.
Design sharpens intent.
Roughly speaking, the skill mix begins to look something like this: 60% product judgment, 30% engineering, 10% design.
Not because engineering and design matter less, but because intent matters more.
This is especially true before product-market fit, when the primary job isn’t optimization or scale, but discovery. When every build is a hypothesis, and the real work is learning which direction is worth committing to at all.
Roles Are Converging Whether We Like It or Not
The clean separations we relied on for decades: product here, design there, and engineering over there, are eroding.
The emerging operator looks different.
They articulate intent with precision.
They work directly with AI to produce code and interfaces.
They understand systems, constraints, and tradeoffs.
And they own outcomes end to end.
This isn’t about job titles. It’s about ownership.
Methodologies built around handoffs and translation layers no longer fit the shape of the work.
What Survives From the Old World
At this point, the obvious question is: okay, so what replaces it?
The answer isn’t a clean break. S2S doesn’t discard the past, it keeps what worked and drops what no longer earns its keep.
What We Keep From Waterfall
Waterfall understood something Agile de-emphasized: breadth and depth of thinking matter before accelerating feedback on an under-formed idea.
S2S keeps:
Up-front clarity of vision and constraints
Explicit articulation of assumptions
Deliberate architecture decisions
Respect for downstream consequences
What changes is that these decisions are no longer frozen. They’re made visible, testable, and revisable.
What We Keep From Agile
Agile got learning right.
S2S keeps:
Incremental delivery
Continuous learning
Tight feedback loops
Adaptation based on evidence
What goes is the theater, the rituals that exist to justify motion rather than accelerate insight.
What S2S Actually Looks Like
S2S does not feel fast in the way chaos feels fast.
It feels quiet.
Work begins not with tickets or ceremonies, but with a sustained act of thinking.
Intent is articulated carefully, sometimes slowly, because clarity is still the rarest input. The problem is named. The boundaries are drawn. Assumptions are written down without embarrassment. Constraints are treated as part of the design rather than obstacles to be negotiated away.
At this point, nothing has been built, and yet much of the work has already been done.
From this intent, artifacts appear almost immediately. Specifications, diagrams, acceptance criteria, interface contracts. They are not labored over. They are summoned. Their fidelity depends on the quality of the thinking that precedes them, not on the time spent formatting them. Documentation is no longer a delayed explanation of what happened. It is a live expression of what is meant.
Building, once the dominant cost, recedes into the background. Code is generated, revised, discarded, regenerated. Interfaces take shape and are reshaped. Tests emerge alongside implementation, not after it. Design artifacts appear good enough, then better, then precise where precision matters. The human role here is not to produce, but to judge. To say yes, no, not yet. To notice when something feels correct and when it subtly violates the original intent.
What replaces standups is not silence but signal. Telemetry, usage, performance, error rates, friction. These are read not as dashboards to be reported upward, but as evidence to be interpreted. The system speaks continuously. The work is to listen without defensiveness.
Documentation evolves as a byproduct of this listening. When behavior changes, the description changes. When constraints tighten, the record tightens. Nothing is ceremonially updated. Nothing is “kept in sync.” Synchronization is automatic, or it is not trusted.
Roles blur, not because expertise disappears, but because translation becomes unnecessary. The same intent is legible to machines, to builders, and to those deciding what to do next. There is less communication, not because collaboration is avoided, but because fewer things need to be explained twice.
Progress is not measured in throughput. It is measured in reduced uncertainty.
A good week is one where assumptions were invalidated early, cheaply, and without drama. A good system is one where changing direction does not feel like failure, because direction was never confused with commitment.S2S is not anti-process. It is anti-theater.
It is not anti-planning. It is anti-pretense.
It assumes that thinking deserves time, that execution deserves rigor, and that reality deserves the final word.
Super insightful. There’s a question I keep asking myself - will software itself become obsolete? With code being written near real time, will it be needed?