Building Software with AI
From vibe coding to spec-driven development - the eight practices that separate teams getting real leverage from AI from teams shipping slop.
AI changed how software gets written before it changed anything else. The tools arrived faster than the practices, which is why two teams with identical subscriptions get opposite results: one compounds real leverage, the other ships slop at unprecedented speed. The difference is practice, not product - and NewStack.ai's AI Coding section maps those practices as an encyclopedia. Here is the tour.
A Spectrum, Not a Switch
The first mistake teams make is treating "coding with AI" as one activity. It is a spectrum of rigor, and the entries name its ends:
- Vibe coding: describe intent, accept code you judge by behavior rather than by reading it. Maximum speed, zero comprehension.
- AI pair programming: a human reviews each AI-generated change as it lands. Slower, but understanding survives.
- Spec-driven development: a detailed specification guides both the AI's implementation and the review of what came back. The spec is the contract.
None of these is "the right way." The right way is matching rigor to stakes - vibe code your weekend prototype, spec-drive your billing system, and never confuse the two.
The Entry Point: Coding Agents
The recommended starting entry is the AI coding agent - software that executes multi-step tasks with minimal human supervision. Not autocomplete, not a chat window: an agent plans, writes, tests, and iterates across your codebase and presents finished work. That leap from suggestion to execution is what makes everything else on this page matter. An autocomplete cannot ship slop at scale. An agent can - which is why the practices around agents, not the agents themselves, decide the outcome.
Teach the Agent Your Repo
An agent without instructions codes like a talented stranger: plausible, generic, and wrong about everything your team decided last year. The fix is AGENTS.md - a markdown file in the repository carrying project-specific instructions: architecture decisions, naming conventions, build commands, hard constraints. I run this practice across my own repos, and the effect is mechanical: every convention you write down is a correction you stop making by hand, on every task, forever. It is the cheapest leverage in the entire stack - a text file that upgrades every future session.
Context Is the Constraint
Agents do not fail randomly; they degrade as their working context bloats. Context management - keeping context relevant and compact through compaction and delegation - is the unglamorous entry that explains most "the agent got dumber" complaints. Compaction summarizes what no longer needs full detail; delegation hands subtasks to fresh agents carrying only what they need. Teams that manage context get agents that stay sharp across long tasks. Teams that do not get an agent that forgets the architecture it agreed to an hour ago.
Review Scales With Generation
When generation speeds up, review either scales with it or becomes the bottleneck - and AI code review is part of the answer: AI identifying bugs, security issues, and style problems in changes before a human ever looks. The pattern that works is layered: AI review catches the mechanical problems at machine speed, and human review spends its scarce attention on judgment - does this belong here, does it match the architecture, do the tests assert behavior. Machines check what machines wrote; humans decide whether it should exist.
The App-Builder Shortcut
At the far end of the spectrum sits the AI app builder - platforms that convert a natural-language description into a deployable application. They are genuinely useful for validating an idea before investing engineering time, and genuinely risky as a foundation, for the same reason vibe coding is: the moment the generated app becomes the product, somebody has to understand it. Use them as sketchpads, not architecture.
The Skills That Still Matter
The uncomfortable question under all of this: if agents write the code, what do engineers still need to be good at? The practices above answer it precisely. Specification - saying what must be true, completely enough to diff against - is now the highest-paid writing skill in software. Architecture matters more, not less, because an agent will cheerfully extend whatever structure exists, good or rotten, at ten times the old speed. Reading code overtakes writing it; the engineer who can absorb a 400-line diff and spot the wrong assumption is the scarce resource. And debugging code you did not write stops being an occasional chore and becomes the daily job description. None of these are new skills - they are the senior skills, arriving earlier in every career. The engineers who thrive are not the ones who prompt best; they are the ones who judge best, because judgment is the one input the toolchain still cannot generate.
Leverage or Slop: The Dividing Line
Put together, the practices sort teams cleanly. Leverage looks like: specs before generation, AGENTS.md in every repo, context managed deliberately, review layered and matched to stakes, and a human who can explain every merged change. Slop looks like: prompts straight to production, no instructions file, hundred-thousand-token contexts, and review theater over code nobody read. Same tools, opposite outcomes - the subscription is not the strategy.
Start Here
To move your team toward the leverage end this month:
- Write AGENTS.md for your main repo - one page of conventions and constraints beats a wiki nobody reads.
- Declare your rigor levels: what may be vibe coded, what requires pairing, what demands a spec. Write the list down.
- Add AI review as the first gate on every PR, and redirect saved human attention to architecture and behavior.
- Start every agent task with a written spec, even three sentences - intent you can diff against is intent you can enforce.
AI did not lower the bar for building software. It raised the throughput at whatever bar you already hold. Set the bar deliberately, teach it to the agent, and the leverage is yours.
Frequently Asked Questions
About the Author
RJ Lindelof is a technology executive with 35+ years of experience spanning Fortune 500 companies to startups. He does don't just talk about AI; he implement's it to solve real-world business problems. RJ's approach has led to significant improvements in team velocity, code quality, and time-to-market.