How **WE** Use AI In Software Development

AI-assisted coding is most useful when it’s treated like a limited collaborator—good for accelerating well-bounded tasks and prototypes, but risky as a default driver for long-term, pattern-heavy codebases. Across the discussion, the biggest practical theme wasn’t whether LLMs can generate code; it was how teams decide when to delegate, how to manage quality, and what kinds of work actually benefit.

Dax describes using AI agents as a way to push productivity while still keeping humans in control. His workflow often splits a coding task into a “dumber” portion and a more complex portion: the AI handles the routine work, then he checks results before continuing. He avoids AI in early codebase stages, arguing that LLMs struggle when there’s not yet consistency in abstractions and patterns. For Open Code—his model-independent command-line agent—he says the project was largely rewritten manually to establish those patterns first. Even when AI-generated code gets discarded, he values the learning: it can surface ideas and reveal pitfalls faster than slow, manual discovery.

Casey’s stance is far more skeptical, rooted less in model capability and more in what programming is supposed to be. He argues that AI-generated web code often becomes “stacking another piece of failure” on top of already-fragile systems—especially when the underlying web platform and abstractions are poorly designed. His critique extends to maintainability, security, and performance, warning that large-scale projects can accumulate messy, hard-to-audit code. He also points to the ephemerality of web development: APIs change, deployment environments shift, and knowledge can become obsolete quickly—making AI-generated scaffolding feel like a short-lived convenience rather than durable engineering.

TJ lands in the middle, treating AI as a tool for specific productivity wins rather than a replacement for engineering judgment. He cites practical areas where LLM help is immediately valuable: clearing repetitive backlog items, adding tests, improving CI-driven workflows, and reducing manual chores like logging boilerplate or error-handling scaffolding. He also supports “vibe coding” for low-stakes, fast-moving goals—like quick prototypes or short-lived promotional sites—where throwing code away is acceptable. His estimate ranges widely (roughly 25% to 100%) depending on whether the work is exploratory or tied to long-term maintenance.

PrimeTime’s perspective emphasizes a similar split: lean into AI when the goal is to get something working quickly, but recognize an inflection point where deeper complexity demands human understanding. He describes improving his vibe-coding process by forcing the AI to propose a plan first, then iterating through corrections before code generation. He also argues that AI is best at the “weather in 10 minutes” stage—useful for near-term outcomes—while longer-horizon predictions become unreliable.

The group ultimately converges on a shared reality: marketing often overfocuses on “zero to one” demos, but most engineering effort is iterative work on existing systems. AI can still change the day-to-day by making prototypes cheaper and by helping teams burn down repetitive tasks—yet it doesn’t eliminate the need for strong fundamentals, careful review, and thoughtful architecture. The conversation ends with a promise to dig into what it actually takes to build a real agent, beyond simple API calls that route questions to a model.