Charlie Holtz, CEO and co-founder of Conductor (YC-backed), recently walked through his entire AI coding workflow on Y Combinator's Full Stack video series. I watched it twice. Not because it was flashy. Because it confirmed something I've been feeling for months about my own AI coding workflow in 2026: the tools are incredible, but the job got harder, not easier. The easy 80% of software engineering — boilerplate, CRUD, configs, standard tests — is gone. AI ate it. What's left is the hard 20%: architecture decisions, tradeoff analysis, debugging edge cases nobody predicted. And if your workflow doesn't reflect that reality, you're going to drown.
Here's the full walkthrough of Charlie Holtz's YC demo:
[YOUTUBE:fQmlML9Lay4|Conductor CEO Charlie Holtz Walks Us Through His AI Coding Setup]
After watching that video and spending the last several months iterating on my own setup, I want to break down what an AI-first dev workflow actually looks like day-to-day. The tools, the strategies, and the honest tradeoffs nobody puts in their Twitter threads.
Praveen Rajamani, a software engineer and Dev.to contributor, wrote a post in May 2026 titled "AI Didn't Make Software Engineering Easier. It Made the Hard Parts Harder" that hit a nerve with thousands of developers (92 reactions, 74 comments). His core argument: tools like Claude Code, Cursor, and GitHub Copilot are excellent at the execution layer. Boilerplate? Gone. Standard CRUD endpoints? Done in seconds. Repetitive tests? Generated before you finish your coffee.
But here's the thing nobody's saying about this: the 20% that required sustained, deep focus is now the entire job. Engineers are expected to live there permanently. And as Rajamani puts it, "the human brain was not built for that."
I've felt this firsthand. After shipping several features using agentic coding tools over the past year, the output velocity is insane. But the cognitive load shifted. I spend less time typing and more time thinking about system boundaries, data flow, and failure modes. The boring recovery time — writing boilerplate, configuring environments — used to give your brain a break between hard problems. That break is gone.
This realization is what drove me to completely rethink my workflow. Speed without structure just means you produce bugs faster. If you're already exploring how AI agents are reshaping how we think about code, this is the operational side of that shift.
The first question everyone asks: Claude Code or Cursor? The answer is both. But for different things.
Claude Code is Anthropic's agentic coding environment. It's not a chatbot. It reads your files, runs commands, makes changes, and autonomously works through problems while you watch, redirect, or step away entirely. It's available across terminal CLI, VS Code extension, desktop app, browser, and JetBrains IDEs. According to Anthropic's official documentation, it operates in a three-phase agentic loop: gather context, take action, verify results — chaining dozens of actions and course-correcting along the way.
I use Claude Code for anything that requires deep, autonomous exploration of a codebase. Bug hunts. Refactoring passes. Writing comprehensive test suites. It's the best tool I've found for the "go figure this out" class of tasks.
Cursor fills a different niche. The Cursor team describes their own internal usage across three categories: background bug fixes triggered from Slack, small todos delegated during commutes via cursor.com/agents, and complex features where they iterate on a plan locally then hand off to a cloud agent for implementation. Michael Truell, co-founder and CEO of Cursor, has described their long-term vision as "self-driving codebases, where agents merge PRs, manage rollouts, and monitor production."
I use Cursor when I want tight IDE integration and fast iteration cycles. Plan mode is excellent for complex features: sketch the architecture locally, get the plan right, then let a cloud agent implement it while you move to the next problem.
If you're weighing the tradeoffs between these tools in more detail, I've done a deeper comparison of Cursor vs Claude Code that covers the IDE-vs-CLI decision specifically.
Here's the single most important thing I've learned about AI coding workflows in 2026: context management is everything. The core constraint of Claude Code is that its context window fills up fast and performance degrades as it fills. Every best practice in the ecosystem — CLAUDE.md files, subagents, /compact
, checkpoints, worktrees — exists to manage this one constraint.
CLAUDE.md files are your primary persistent memory mechanism. These are instructions you write at project-level (repo root), directory-level, or user-level (~/.claude/CLAUDE.md
) that get loaded at the start of every session. They can import other files with @path
syntax. You can scope rules to specific file types using the .claude/rules/
directory. For teams, organization-wide CLAUDE.md files can be deployed.
The complementary system is auto memory — notes Claude writes itself based on your corrections and preferences. Together, they create a persistent project brain that survives between sessions.
Having built services that handle significant traffic, the CLAUDE.md file is where I encode the hard-won architectural decisions that no amount of code reading will surface. Things like: "We use eventual consistency for user preferences because strong consistency caused P99 spikes above 500ms during the Q4 migration." Or: "Never add a new microservice without updating the dependency graph in /docs/architecture.md."
The more specific and concise your instructions, the more consistently Claude follows them.
— Anthropic, Claude Code Memory Documentation
Mark Dominus, the software engineer and longtime author of The Universe of Discourse blog, wrote a piece titled "Programmers Will Document for Claude, But Not for Each Other" that went trending on Hacker News. His insight: developers are writing better documentation specifically because Claude reads and uses it — creating a positive feedback loop. Writing good context for the AI forces clearer thinking about your own system. Dominus now asks Claude to write structured overviews at the end of each project and commits them to the repo. Not running notes. A detailed, high-level explanation of what problem was solved and what changed.
This is one of those things where the boring answer is actually the right one. Write a good CLAUDE.md. Update it regularly. It'll make your AI sessions dramatically better and your codebase more understandable to humans. Two wins for the price of one.
The biggest fear with agentic coding: what happens when it goes off the rails? I've had Claude confidently refactor a service boundary in a way that passed all tests but silently broke an integration contract. Without a safety net, you're debugging a problem you didn't create and don't fully understand.
Checkpoints solve this. In Claude Code, checkpoints are git snapshots taken automatically before risky file operations. One-click undo if an agentic run produces garbage. This is your primary safety net for autonomous multi-file edits. I treat it as non-negotiable.
Here's how my workflow actually looks:
Plan before editing. I ask Claude to create a plan and review it before any files are touched. Anthropic's own docs recommend the "explore first, then plan, then code" three-phase pattern. I've found skipping the explore phase is where most people go wrong.
Checkpoint before anything risky. Especially before refactors that touch more than three files. I learned this the hard way after losing an afternoon to an ambitious rename-and-restructure that touched 14 files and broke in ways that were painful to untangle.
Run parallel sessions with git worktrees. This is the underrated power move. Worktrees let you run concurrent Claude sessions on different branches without file collisions. I'll have one session working on a feature while another writes tests for a different module.
Use subagents for research. When I need Claude to investigate something — a library's API surface, a dependency's behavior — I delegate to a subagent. Keeps the main session's context window clean for actual implementation work.
Use /compact aggressively. When context gets long, summarize and compress. Don't let performance degrade silently.
The worktree pattern changed how I think about parallelism. I've shipped enough features to know that context-switching between tasks is a productivity killer. Worktrees let me keep multiple AI sessions running without the mental overhead of switching contexts myself. The AI does the context-switching. I just review outputs.
Maxim Saplin, a developer and Dev.to contributor, ran a fascinating experiment: he deliberately debloated an AI-grown Flutter app and achieved a 31.7% reduction in total lines of code (19,772 → 13,509 lines) with all 335 tests still green and two latent bugs fixed along the way.
His description of the "AI smell" is painfully accurate: verbose READMEs lacking clarity, weird abstraction layers, half-fixes, old ideas still wired through the system, abstractions introduced for problems that no longer exist. Saplin admits he deliberately avoided reading the code during development — accumulating what he calls "cognitive debt."
I've seen this exact pattern in my own projects. AI-generated code is locally competent but globally incoherent. Each function looks reasonable. The system-level architecture drifts toward entropy. This is why I now build explicit debloating passes into my workflow. Every two weeks, I do a dedicated session where I ask Claude to audit for dead code, redundant abstractions, and inconsistent patterns. Think of it like garbage collection for your codebase.
This connects directly to the broader crisis of AI-generated code quality that's been building across the industry. The velocity is real. But velocity without periodic cleanup is just tech debt accumulation at 10x speed.
Here's my actual daily workflow, stripped of the hype:
Morning (30 min): Review overnight cloud agent outputs from Cursor. Merge anything clean. Kick back anything that needs rework with more specific instructions. Most mornings, maybe 60% of what ran overnight is merge-ready. The rest needs a nudge.
Deep work blocks (2-3 hours): This is where the real engineering happens. I pick the hardest architectural problem on my plate and work through it with Claude Code in the terminal. CLAUDE.md is loaded. Checkpoints are on. I think, Claude implements, I review. The ratio is roughly 60% thinking, 40% reviewing AI output. If you told me two years ago that "senior engineer" would mean "person who thinks really hard and reviews robot code" I'd have laughed. But here we are.
Parallel tasks: While I'm in a deep work block on one thing, I'll have 1-2 Cursor cloud agents working on smaller, well-defined tasks in separate worktrees. Bug fixes, test coverage improvements, documentation updates.
Debloat pass (biweekly): A full audit session. No new features. Just cleanup. This is the part most teams skip, and it's the part that saves you six months later.
Context hygiene: I update CLAUDE.md whenever I make an architectural decision that future sessions need to know about. Takes five minutes. Saves hours of confused AI output later.
The key insight from watching Charlie Holtz's YC walkthrough — and from living this workflow myself — is that the human's job has fundamentally shifted. You're not writing code. You're making decisions, setting constraints, reviewing output, and maintaining the system-level coherence that no AI can yet hold in its context window.
Here's my prediction: within 12 months, every serious engineering team will have a formal "AI workflow spec" the same way they have coding standards today. Not just which tools to use, but how to structure context, when to checkpoint, how to parallelize, and how often to debloat.
The teams that figure this out first will ship 5x faster with cleaner codebases. The teams that don't will drown in AI-generated entropy — locally correct code that's globally incoherent, growing faster than anyone can review.
If you're building with AI coding tools today, stop optimizing for speed. Start optimizing for clarity. Write the CLAUDE.md. Set up the checkpoints. Schedule the debloat passes. The boring infrastructure of an AI coding workflow in 2026 is what separates the teams shipping production systems from the teams shipping demos. The easy parts of engineering are gone. The hard parts are all that's left. Build your workflow accordingly.
The most effective AI coding workflow in 2026 combines Claude Code for deep autonomous tasks (refactoring, bug hunts, test writing) with Cursor for IDE-integrated work and cloud agent delegation. The key is layering in context management via CLAUDE.md files, automatic checkpoints before risky edits, and parallel sessions using git worktrees.
They solve different problems. Claude Code excels at deep, autonomous exploration of a codebase — it reads files, runs commands, and course-corrects independently. Cursor is stronger for tight IDE integration, fast iteration, and cloud agent delegation for parallel tasks. Most productive developers use both.
Schedule regular debloating passes — every two weeks works well. AI-generated code tends to be locally competent but globally incoherent, accumulating dead abstractions and redundant patterns. One real experiment showed a 31.7% code reduction on an AI-grown app with all tests still passing and latent bugs fixed.
CLAUDE.md is a persistent instruction file for Claude Code that loads at the start of every session. You place it at your project root, in specific directories, or at the user level. It tells Claude your architectural decisions, coding conventions, and project constraints — dramatically improving output quality across sessions.
Git worktrees let you run multiple Claude Code or Cursor sessions simultaneously on different branches without file collisions. This means you can have one AI session building a feature while another writes tests for a different module — true parallelism without context-switching overhead.
AI eliminated the easy parts of engineering — boilerplate, CRUD endpoints, config files — leaving developers to permanently inhabit the hard parts: architecture, system design, tradeoff analysis, and edge-case debugging. The total cognitive load hasn't decreased; it's shifted entirely to the highest-difficulty work.
Originally published on kunalganglani.com