Stop Using Outdated AI Coding Habits: 8 Agentic Development Practices That Are Already Obsolete

A YouTube creator recently had one-on-one conversations with around 50 indie developers and founders, observing how they build projects with AI. The conclusion was blunt: if you're still doing agentic programming the way people did it back in March or April of this year, you're seriously hemorrhaging productivity and falling behind.

The core premise here is that AI models have iterated to a new generation (the video references models like Astra and Opus 5.5), while many people's workflows are still stuck in the old-model era — a time when AI was genuinely unreliable, and developers invented all sorts of patch-like tricks to compensate. The problem is those tricks have now become dead weight.

It's worth noting the clear scope of this framework: it's aimed at indie developers and early-stage founders, not engineers working at Google, Microsoft, or on medical software. The creator repeatedly emphasizes that agentic programming for enterprise medical software is a completely different workflow from writing code to validate a side project idea.

Patches from the Old Model Era Are Now a Burden

The first widespread problem the creator identifies is that people still treat AI like they did with that previous generation of models. Back then, agents would pretend to understand your intent, say "got it," and then go off and do a bunch of things you never asked for. To combat this, developers stuffed their agents.md or cloud.md files with negative directives like "never do X" and "under no circumstances do Y."

His advice is direct: delete those files and start from scratch. With the latest generation of models, only add rules to the file when you actually observe behavior you don't like. In his own practice, his agents.md has almost no negative directives — just positive conventions like "commit your changes after each request."

The second common mistake is building complex "factory systems": an orchestrator agent commanding a dozen sub-tabs, communicating through a message bus, backed by a full suite of scripts. These were clever solutions invented in 2025 to make bad AI actually get work done — a kind of anthropomorphic architecture. His take is equally blunt: tear it all down. These fancy hacks are slowing you down.

Agentic programming refers to a paradigm where an AI model acts as an autonomous "agent" executing multi-step tasks continuously, distinct from traditional single-turn code completion. In this mode, the agent reads the codebase, calls tools, makes decisions, and commits changes — all without the developer intervening at each step. The orchestrator architecture was a common design pattern in early agentic programming: a central agent (the orchestrator) breaks down tasks and delegates them to multiple sub-agents, which collaborate via a message bus — similar to an assembly line. When model capabilities were limited, this architecture constrained AI behavior and reduced error propagation, but at the cost of extreme system complexity, difficult debugging, and enormous engineering effort spent "managing the AI" rather than building the product. As models' own reasoning and instruction-following abilities have improved dramatically, the necessity of such scaffolding architectures has dropped significantly.

Stop Treating Context as Sacred

The most pervasive problem is that people treat context as something precious.

One typical manifestation: having an agent write notes after every change, committing markdown files to the repo so subsequent agents can understand what happened before. The creator thinks this is entirely unnecessary — the code itself is the notes; the code is the spec. To an agent, English, code, and pixels are all tokens — there's no difference. By artificially creating two sources of truth, you're slowing down both yourself and the agent.

Another manifestation is spec-driven development: handing an agent a sentence or two, having it generate a detailed document first, then passing that to another agent to execute. The creator considers this unnecessary overhead — the same agent capable of turning a sentence into a full document is the same agent that can turn that sentence directly into code. In 2025, you genuinely needed long, detailed specs, otherwise agents would go rogue and the cost was high. But now, models can make reasonable default choices on their own.

A third related misconception is treating conversations as sacred. Many people maintain a few "super threads" with hundreds of replies because they feel all that accumulated context is too valuable to abandon. The creator does the exact opposite: open a new conversation for every feature. Hit "+", write a few sentences, send it, and when it's done, close it like it never existed. What's sacred is the codebase — not the English conversation you had with the agent.

In how large language models work, the context window is all the information a model can "see" during a single inference — conversation history, code files, instruction documents, and so on. Early models had small context windows (typically 8K to 32K tokens); beyond that limit, the model would "forget" earlier content, so developers had to carefully design external note and summary mechanisms to compensate. Current next-generation models have context windows expanded to hundreds of thousands or even millions of tokens, capable of reading an entire codebase directly. The argument that "code is documentation" is built squarely on this capability leap. Spec-driven development refers to first having AI generate a detailed specification document, then having another AI implement based on that document. Under old models, this reduced ambiguity and hallucination rates, but with new models having stronger default reasoning, this intermediate layer often just adds latency.

The Obsession with To-Do Lists and Code Quality

The sixth observation targets indie developers who fill up an entire month's Kanban board before they've validated a single idea. For a side project where market demand hasn't been validated, the creator argues that to-do lists themselves are an anti-pattern.

His alternative: when you get the urge to "add a feature," don't write it down — open an agent, type the idea, send it, and let it get done on the spot. That's faster than recording it, coming back to it, and re-prioritizing. And if an idea "isn't worth doing right now, it isn't worth doing later either." Worried about forgetting? Let it go — what truly matters will naturally resurface. He warns that many people are addicted to productivity porn, disappearing into a bunker for 30 or 60 days of heads-down building, while never getting the product in front of early users for real feedback.

The seventh obsession is code quality. The creator mentions people with non-technical backgrounds pausing projects over code quality concerns, and he pushes back: if you haven't even validated the idea yet, why worry about code quality? He draws a parallel to what people did around 2016 — to validate an idea, you'd have some 20-year-old hack together a proof of concept overnight, with terrible code. That was entirely normal for "fail fast" mode. He'd even bet that Astra's output is higher quality than pre-MVP startup code from 2016.

He's not saying code quality doesn't matter — he's emphasizing that during the market validation stage, the codebase will change in a thousand ways before you hit your first 100 customers. Investing too early is waste.

Replace Back-and-Forth with Workshopping

The creator showcases a highlight of the new workflow: having Astra "workshop" several design directions first. It presents four UX options at once, and you just say "build O2" (pick the second one), and it implements what you saw with close to 100% fidelity.

The value here is avoiding the endless bickering. The old way was to have the agent build something directly, then keep saying "I don't like this, I don't like that, make it more prominent" — getting stuck in a loop. Changing things at the workshop stage is cheap, because the agent knows those files are throwaway.

The creator offers an important diagnostic: if you're repeatedly arguing with an agent, something has gone wrong. You've probably given it too many directives, too many guardrails, too many system constraints — locking it into a single lane instead of simply telling it the task and the acceptance criteria and letting it find the solution. Or your agents.md may be too strict, or you're requiring the agent to read all your documentation before it starts. He admits that when building a product called Shape, he created a "bible of everything" and required the agent to read through it before every change — which was also a nightmare.

Ditch Branches and Worktrees

The eighth point is perhaps the most controversial: stop using git worktrees and feature branches.

The creator admits this will make many people "want to burn him at the stake." His logic: from 2025 through early 2026, you genuinely needed worktrees and branches because agents would overwrite each other's changes, delete each other's work, and create total chaos. But after switching to Astra High, he's been able to run six tasks simultaneously on the main branch without a single incident. Across the entire lifecycle of two projects — Ship Academy and Enjoy — he never used a single worktree or feature branch. Everything went to main.

He does apply a bit of "mental filtering": when running six parallel tasks, he makes sure their scopes are roughly isolated — he'd never have three tasks all touching the same hero section of a website. His core mechanism is a simple instruction: commit after every change. Each agent commits its own piece of work. If one messes up, roll it back. When everything's done, there are no lingering unstaged files. The agents will even proactively flag "my work was overwritten by another agent."

Git worktree is a Git feature that lets a single repository check out multiple working directories on the filesystem simultaneously, each on a different branch, without interfering with each other. When multiple AI agents are modifying code in parallel, worktrees physically isolate each agent's workspace to avoid file conflicts. Feature branches are standard practice in workflows like Git Flow — creating a separate branch for each new feature and merging it back to the main trunk when done, keeping the main branch always in a releasable state. The creator's recommendation to abandon both rests on the premise that new-generation models have stronger conflict awareness and self-coordination, plus the convention of "commit every change immediately" provides fine-grained rollback points — making parallel work on the main branch manageable as long as task scopes are well isolated. This recommendation does not apply to team collaboration or scenarios requiring rigorous code review.

Model Selection and Overall Philosophy

On tooling, the creator's advice is to stop using "funky" models like Gemini — if you're building something you want to make money from, don't go below Opus at minimum; Opus is a great daily driver. On Codex, don't go below Astra. For new features involving architecture or changes across many files, default to setting the effort level to high. He also mentions new models like Sol, Terra, and Six that just came out, but says Astra is still hard to beat for now.

He also offers a mental model for moving faster: if you're doing one thing at a time and just waiting for it to finish, everything feels slow. But if you can manage four conversations and four things at once, something is always moving forward, and the overall pace feels blazing fast.

The philosophy running through everything comes down to one principle: start with the most naive, simplest approach possible — one branch, the shortest description you can write, then only adjust your workflow when the current model actually fails. Throw out your 2025 workflows entirely, pretend you're encountering agentic programming for the first time with zero preconceptions, and course-correct as you go.