A year ago I came back to blogging after a 20-year silence. The early posts were small, curious, and mostly me finding my voice again. One was a quiet admission that I had missed having a public voice. I closed it with three words: Welcome back, old friend.
I had no plan. I had a backlog of thoughts. By that first weekend, I was writing about running a 20-billion-parameter language model entirely offline on a Mac. By fall, I was writing about agents, platforms, specifications, leadership, and the uneasy bargain underneath all of it.
Nearly 50 posts later, I have an argument, and this essay is my attempt to name it.
The argument, in one sentence
The bottleneck is never the stack. It is the clarity of intent, encoded in durable artifacts, enforced by systems rather than willpower. The leaders and builders who win this cycle are the ones who industrialize craft and bargain honestly with the humans whose careers it reshapes.
I didn't invent that sentence in May 2026. I arrived at it by writing the same thing in different rooms for 12 months. "Specs beat vibes." "The code is exhaust, the spec is the product." "Discipline does not scale; automation does." "Trust compounds faster than velocity." "The bottleneck is never the stack." Those lines were all reaching for the same idea.
For the rest of this essay, I want to lay it out fully, then tell you where I am still uncertain.
Why this matters now
Two things are true at the same time. AI may be the next great technology wave after the internet and mobile, but this one is arriving on a compressed timeline. At the same time, many enterprise conversations about it are theater built on inherited frames nobody stopped to question.
The doomer narrative says AI is coming for your jobs. The hype narrative says AI is the productivity flywheel that will 10x your engineers. Both narratives are incomplete, and both are useful to someone's balance sheet.
When I wrote Strip the Assumptions in March, I tried to name what was happening underneath. Generative AI reduces the marginal cost of specific cognitive outputs. That is a meaningfully different claim from the one either narrative is making.
It changes what an engineering leader should be asking. Which artifacts become cheap, which become valuable, and what kind of work moves to the top of the priority list?
After a year of writing, I keep arriving at the same answer. The artifact that becomes valuable is the spec. The work that moves to the top is the work of defining intent clearly, enforcing standards with automation, and bargaining honestly with the people whose careers are reshaped along the way.
That is the argument. Three pillars hold it up.
Pillar one. The spec is the product.
I've written about this in pieces all year. In August, I called it spec mode over vibe mode. In September, I called it coaching the LLM with software craftsmanship principles. In November, I called it the journey from vibe coding to spec-driven development. By April, I was writing about specs, standards, and specialists as the working loop underneath everything I build. Then in May, I landed on the formulation that captures it best: the code is exhaust, the spec is the product.
For most of the last 30 years, software organizations have measured the wrong thing. Commit counts passed for velocity, coverage numbers passed for quality, and the engineers we called senior were the ones with the most code behind them. Team size was a forecast of how many lines we expected.
That structure rested on a quiet assumption. Turning intent into working software was the hard part, so the typing was the bottleneck and the senior engineer was whoever typed the right things faster. That assumption is breaking. Every senior engineer I know has felt it quietly, usually around 11 p.m., the week an agent finished a job they had budgeted three hours for.
With agentic coding tools, turning a clear, bounded specification into working code is becoming dramatically cheaper. What stayed hard, and what becomes more visible every day, is everything upstream: knowing what to build, what good looks like, and which edge cases will break in production. Someone still has to read the generated artifact and judge whether it meets the intent.
When generated code comes back wrong, the defect usually started earlier than the code itself, in a vague spec, a verification step nobody wrote, a standard nobody enforced, or a review that skimmed. That reframe rearranges almost every engineering practice we built in the last 20 years.
Spec review is becoming the new code review, and seniority now shows up in clarity of thinking rather than speed at the keyboard. The apprenticeship pipeline, the thing that produced our seniors out of our juniors, has to move from pairing on code to pairing on specs and reviews.
It also changes what we should measure. Story points, pull requests, and lines of code measure activity. The numbers I want are accepted specifications, review latency, spec-to-verified-delivery time, and rework rate when reality contradicts the spec.
That last one matters most. Rework is where the illusion breaks. It tells you whether the original intent was clear enough, whether the standards were strong enough, and whether the review process caught the right failures before production did.
The durable artifact your organization produces, the thing that survives leadership transitions, tool migrations, and model upgrades, is the specification layer. The repository becomes a fossil record. The spec becomes the strategy.
Pillar two. From toil to judgment.
If pillar one is about what becomes valuable, pillar two is about what humans still own. AI agents are a lever against the gravity of operational drudgery. In the same way that cloud freed us from racking servers and patching disks, AI agents can free us from babysitting dashboards, chasing cost anomalies, and reading the same triage runbook for the hundredth time. That is a redistribution of human attention.
When I wrote about my FinOps agent in September, I framed it this way: the future of work will be defined by how effectively we use agents to reduce toil and reclaim human judgment. I haven't found a better way to say it since.
The scarce skills become problem framing, system design, judgment, and taste. The scarce organizational capability becomes evaluation capacity, which is the ability to read a generated output and confidently say whether it is trustworthy.
Most leadership discussions about AI argue about model capability. The bottleneck is the organization's ability to evaluate whether outputs are correct.
You need fewer generators and more evaluators, close enough to the work to correct it in real time. Augmented humans catch errors as they happen, and automated errors compound.
There is a humanist version of the same idea that I keep returning to. AI is reminding us what we're here for.
The keyboard work was never the meaningful part of being an engineer or a leader. The judgment was, and the taste, and the willingness to engage with messy details long enough to make better decisions. The tooling is finally catching up to the part of the job that always mattered.
Pillar three. Principles outlast personalities.
The third pillar is the leadership claim, and it's the one I feel most strongly about because I have watched the alternative break good organizations.
In Yesterday's Feature Is Today's Bug, I wrote that if your IT strategy cannot survive a leadership transition, it was someone's aesthetic preference rather than a strategy. A personality expressed as architecture. The revolving door of leadership is a test of good strategy.
This pillar shows up in different language across the year. In Building Cloud From Zero, I called it the discipline of making the right thing the default before anyone builds workarounds. Platforms only work when the defaults are inherited.
In Pipeline-First Is Not a DevOps Initiative, I called it trust-scaling, the move from individualized heroics to systemic delivery. In When Winning Teams Lose, I called it accountability flowing upward, because if you publicly criticize your team while protecting yourself, you create the culture problem you're complaining about. One phrase ties the pillar together: principles, not personalities.
The leaders who matter 10 years from now are the ones whose work keeps getting better after they've moved on. That is the entire point.
This is also where the AI story and the platform story meet. A platform is an opinionated system of defaults that helps people make better decisions without asking every person to rediscover the same lesson alone.
The same is true for AI-assisted engineering. A good operating model shouldn't depend on one brilliant engineer knowing the perfect prompt, one staff engineer catching every bad diff, or one leader personally reinforcing the same principle in every meeting. That doesn't scale. Worse, it creates fragility disguised as excellence.
The work has to move into artifacts, defaults, standards, and feedback loops. Human judgment goes into designing them, so the system can help more people make better decisions more often. That is how principles outlast personalities.
The bargain underneath
The fourth thread arrived later, and it's the one I am still learning how to say well. It came from watching the politics around AI harden, from executive optimism on one side to public anger on the other. Alignment that stops at the technology just means a worse outcome arrives well engineered.
Builders set the language for our own technology. If the words I use in an investor meeting are the same words I use with someone whose work has just been displaced, I've earned the reaction I get.
Truth and audience are two different problems, and we keep solving only the first one. Workforce optimization is a bloodless phrase for a human cost. We are using AI so a smaller team can do harder work and get paid better for it is at least a plan someone can interrogate. It makes the bargain visible.
The trust deficit is on the builders. Pick the version of the bargain you can live with, then own it plainly enough that the people affected by it can argue with the real thing.
I don't think technical leaders can opt out of this conversation. Talk only about productivity and we miss the human consequences; talk only about fear and we miss the chance to build better systems. The work is to hold both truths without hiding behind either one. That is uncomfortable. Good.
Where I am less sure
I have shipped this synthesis with three confident pillars and one developing one. Here is where I am still working things out.
I am most confident in the spec pillar. I have written it five different ways with five different examples, and every example has held up.
I am moderately confident in the toil-to-judgment pillar. It is well-developed, but it sometimes blurs into the spec pillar. They may be two faces of the same belief. The clarity question is whether evaluation capacity is a separate scarce resource from specification clarity, or whether they are the same skill at different elevations.
I am increasingly confident in the leadership pillar, but I am still working on the cleanest language. "Build for after you are gone" gets at the humility of it. "Principles outlast personalities" gets at the system design. "Design for succession" gets at the operating model. I suspect the real idea needs all three.
I am least certain about the builder's bargain, not because I doubt its importance, but because I am still learning how to reach beyond the audience that already agrees with me. The people building AI understand the promise. The people being asked to absorb the consequences often hear something else. The work there is not done.
That uncertainty matters. It keeps the argument honest.
What I want this to do
I wrote this because the people who read me at vinny.dev deserve more than a chronological list of posts. They deserve the argument underneath them.
The people I lead deserve the same thing. When technology moves this quickly, silence becomes its own kind of message.
After 30 years in this craft, the advantage I would bet on is clearer intent, stronger systems, better judgment, and more honest conversations about the work we are changing. The bottleneck, after all, is never the stack.
If you think I have one of these wrong, write to me at vin@vinny.dev. Good points of view get sharper when they meet other points of view.
