Settled, for now
The spectrum of developer-LLM collaboration
TomLast changed December 18, 2025LLMs have fundamentally transformed how developers work, but not everyone uses them the same way. A clear spectrum has emerged; from quick code generation to full autonomous delegation; and where a developer falls on this spectrum determines which tools, workflows, and prompting strategies will serve them best. This analysis synthesizes perspectives from the field’s most prominent practitioners to create a diagnostic framework for understanding and optimizing developer-AI collaboration.
The key insight: this isn’t a progression where more autonomy is better. It’s a spectrum where different positions optimize for different goals, and the most effective developers consciously choose their position based on context.
A five-archetype taxonomy for developer-LLM collaboration
The spectrum from “LLMs just write code” to “LLMs do everything autonomously” can be captured in five distinct archetypes. Each represents a coherent philosophy with specific tools, workflows, and best practices.
Archetype 1: The Accelerated Traditionalist
Philosophy: AI as sophisticated autocomplete; useful for speed, never for decisions.
These developers use LLMs primarily for tab completion and syntax assistance while maintaining full control over architecture, logic, and code quality. They’re skeptical of extended AI reasoning and view autonomous agents as more trouble than they’re worth.
Characteristic workflow: Write code manually, accept tab completions for boilerplate, occasionally ask for syntax help in unfamiliar languages. Every line gets human review before commit.
Trust profile: Low trust in AI judgment, high trust in AI for mechanical tasks. The Stack Overflow 2025 survey found 72% of developers reject vibe coding in professional work; this archetype represents the silent majority.
Best tools: GitHub Copilot basic mode, Cursor Tab completion, IDE-integrated suggestions. These developers avoid agent modes entirely.
Archetype 2: The Fast Feedback Optimizer
Philosophy: Speed of iteration matters more than depth of AI reasoning; sequential fast beats parallel slow.
This archetype, best exemplified by Dax Raad (@thdxr), prioritizes tight feedback loops over extended AI “thinking.” The core insight: running multiple slow agents feels productive but often produces worse results than focused iteration with a faster model.
Dax’s critique cuts deep: “Opening eight agents and watching them all run at once feels incredible… But when he looks at who’s actually shipping useful stuff, it’s not these people. The productivity feeling is real. The productivity isn’t.”
Characteristic workflow: Single-threaded development with immediate LSP feedback. When the LLM makes a change, diagnostics run instantly. Errors go back to the model immediately. No elaborate planning phases; just rapid write-test-fix cycles.
Trust profile: Trusts AI execution speed, deeply skeptical of AI “reasoning” or extended thinking modes. Views benchmarks as essentially astrology.
Best tools: OpenCode (deliberately minimal Plan mode, built-in LSP feedback), Cursor with fast models, any tool that prioritizes responsiveness over capability. Dax explicitly designed OpenCode’s minimal Plan mode around this philosophy: planning should be quick analysis, not deep reasoning.
Archetype 3: The Deliberate Collaborator
Philosophy: AI as an over-confident pair programming partner that requires active management.
This middle-ground position treats LLMs as capable but unreliable collaborators. Simon Willison captures it perfectly: “My current favorite mental model is to think of them as an over-confident pair programming assistant who’s lightning fast at looking things up, can churn out relevant examples at a moment’s notice and can execute on tedious tasks without complaint.”
The key discipline is context management. As Willison emphasizes: “Most of the craft comes down to managing context”; knowing what’s going into the model and structuring conversations to maximize useful output.
Characteristic workflow: Provide rich context upfront. Use “authoritarian mode” for production code; dictate exact function signatures and specifications rather than asking open-ended questions. Test everything; “The one thing you absolutely cannot outsource to the machine is testing that the code actually works.”
Trust profile: Conditional trust based on task type. High trust for exploration and learning, low trust for production without verification. These developers maintain explicit awareness of model training cutoffs and deliberately choose “boring technology” that exists in training data.
Best tools: Claude Projects (persistent context), Cursor Chat mode, llm CLI with files-to-prompt for context injection. Tools that show exactly what’s going into context are preferred.
Archetype 4: The Autonomy Slider Operator
Philosophy: Match AI autonomy level to task stakes; the key skill is knowing when to dial up or down.
Andrej Karpathy articulated this framework most clearly with his “autonomy slider” concept, presented at YC AI Startup School: “You are in charge of the autonomy slider. Depending on the complexity of the task at hand, you can tune the amount of autonomy that you’re willing to give up.”
Karpathy’s own practice demonstrates the nuance. He coined “vibe coding” (“I ‘Accept All’ always, I don’t read the diffs anymore”) but explicitly frames it as appropriate only for “throwaway weekend projects.” For code he “actually and professionally cares about,” he uses a rigorous workflow: stuff context, describe single incremental changes, review approaches before coding, manually validate API usage.
Characteristic workflow: Layered tool usage based on task complexity. 75% of work is simple tab completion. Harder problems get escalating autonomy; Cmd+K for file-level changes, Cmd+I for multi-file features, and “nuclear option” top-tier models reserved for the hardest problems. The workflow for serious code: plan first, ask for options, pick an approach, then generate.
Trust profile: Trust is context-dependent and consciously managed. Weekend hack? Full autonomy. Production system? Careful review of every change.
Best tools: Cursor (explicit modes from Tab to Agent), Claude Code with flexible permission levels, multiple models for different complexity tiers. These developers often maintain several subscriptions and consciously choose models per task.
Archetype 5: The Full Delegation Maximalist
Philosophy: YOLO is the only way; give agents full system access and let them work.
Peter Steinberger (@steipete) represents the far end of the autonomy spectrum. His approach: run Claude Code with --dangerously-skip-permissions, operate 3-8 agents simultaneously in a terminal grid, and trust the model to execute with minimal oversight.
His philosophy is unapologetic: “Nothing bad ever happened. Just be smart about it. You don’t ask the model to delete stuff unless it’s a very simple thing… otherwise everything is in git, backups run every night… YOLO is the only way of running agents.”
Critically, Steinberger rejects elaborate tooling: “Don’t waste your time on stuff like RAG, subagents, Agents 2.0 or other things that are mostly just charade. Just talk to it. Play with it. Develop intuition.”
Characteristic workflow: Multiple parallel agents on main branch (not worktrees; “the whole work tree approach just slowed me down”). Short prompts (“Often it’s just 1-2 sentences + an image”). Tests written after features, not before. Living CLAUDE.md files maintained by the agents themselves. Uses “blast radius” mental model to scope agent work.
Trust profile: High trust in modern model capabilities, combined with robust safety nets (git, backups, isolated experiments in separate folders). The trust is in the system, not blind faith in any single output.
Best tools: Codex CLI (his current primary, valued for better codebase reading and message queuing), Claude Code with permissions bypassed, tmux for background processes. Explicitly avoids MCPs (“Almost all MCPs really should be CLIs… Use GitHub’s MCP and see 23k tokens gone”).
How the major tools map to the spectrum
Each tool embeds assumptions about where its users fall on the autonomy spectrum, and these design choices matter.
Cursor occupies the collaborative middle ground. Its explicit modes; Tab, Cmd+K, Cmd+L, Agent; map directly to Karpathy’s autonomy slider. The Composer feature enables multi-file work while maintaining human review, and the Shadow Workspace lets AI test code before suggesting changes. Cursor assumes developers want to stay in the driver’s seat with real-time feedback loops. Its philosophy, per founder Michael Truell: “Programmers should stay in the driver’s seat, using AI to amplify human creativity rather than replace it.”
Claude Code offers maximum flexibility through Unix philosophy design. It can operate anywhere on the spectrum; from careful single-command execution to --dangerously-skip-permissions full autonomy. The key insight: Claude Code is “intentionally low-level and unopinionated… this flexibility presents a learning curve for engineers new to agentic coding tools.” Extended thinking triggers (“think” < “think hard” < “think harder” < “ultrathink”) give explicit control over reasoning depth. Power users run multiple instances across git worktrees; casual users do codebase Q&A.
OpenAI Codex commits fully to the delegation model. It’s designed for asynchronous workflows where tasks take 1-30 minutes, not instant responses. From the Codex team: “The most successful users generate 10+ PRs daily, treating the agent as an independent teammate.” There’s no mid-task intervention; you submit, wait, and review the resulting PR. This is purpose-built for developers who want to delegate multiple tasks in parallel and review completed work, not pair-program in real time.
OpenCode deliberately optimizes for fast feedback over extended reasoning. Its Plan mode is intentionally minimal; read-only analysis without elaborate reasoning chains. The design reflects Dax’s belief that “the productivity feeling is real, the productivity isn’t” when running many parallel agents. OpenCode’s built-in LSP integration exemplifies the philosophy: when the LLM edits a file, diagnostics run immediately and errors feed back to the model, creating the tight loop Dax considers essential.
What determines where a developer falls on this spectrum
Five key variables predict a developer’s natural position on the autonomy spectrum, and understanding them enables more intentional choices.
Experience level and domain expertise create the foundation. Senior developers with deep domain knowledge can validate AI output effectively and catch subtle errors; they can safely operate at higher autonomy levels because they’ll notice when things go wrong. The Stack Overflow survey found experienced developers are actually the most skeptical of AI (only 2.6% express high trust), but this skepticism enables informed delegation rather than blind acceptance. Conversely, juniors using high-autonomy modes risk “never becoming good” as one framework puts it; they can’t verify what they can’t evaluate.
Type of work being done dramatically shifts appropriate autonomy levels. Prototyping and throwaway code tolerate high autonomy and fast iteration; Karpathy’s vibe coding is explicitly “not too bad for throwaway weekend projects.” Production code demands verification at every step. Greenfield development benefits from AI scaffolding; maintenance work requires the deep context that AI often lacks. The 2025 developer survey shows 76% won’t use AI for deployment/monitoring and 69% refuse AI for project planning; even heavy AI users maintain human control over high-stakes decisions.
Feedback loop speed preferences reflect cognitive style. Some developers thrive in the vibe coding flow state; rapid iteration, accept-all, fix-as-you-go. Others need the deliberate rhythm of plan-review-implement. Neither is wrong; they’re optimized for different outcomes. Dax Raad’s insight matters here: parallel slow agents feel more productive than sequential fast iteration, but often produce worse results. Self-awareness about what actually produces results versus what feels productive is crucial.
Trust calibration and control needs vary with personality and past experiences. Some developers, like Steinberger, have developed high trust through extensive successful delegation: “Nothing bad ever happened.” Others have been burned by “almost right” code; 66% of developers cite this as their top AI frustration; and maintain tighter control. The healthiest approach: trust is earned and context-dependent, not a fixed personality trait.
Risk tolerance and safety net strength enable higher autonomy when properly configured. Steinberger’s YOLO approach is undergirded by robust safety nets: everything in git, nightly backups, blast-radius thinking. Developers without such infrastructure rationally operate at lower autonomy levels. The Codex model; isolated containers with disabled internet; builds safety nets into the tool itself.
Best practices calibrated to each archetype
For fast code generation workflows
The key is maximizing iteration speed while accepting the need for eventual cleanup. Use the fastest available models rather than the most capable. Provide minimal context; OpenCode’s system prompt literally instructs “Aim for fewer than 3 lines of text output per response.” Run single-threaded rather than juggling multiple agents. Accept that AI-generated code is a starting point requiring refinement. Test after every change to catch issues while context is fresh.
When vibe coding, follow Karpathy’s example: recognize it’s for prototypes, not production. “Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away” is a valid strategy for weekend projects; it’s a disaster for systems that matter.
For planning and architecture assistance
Invert the typical approach: never start with code generation. Ask for multiple architectural options first, explicitly requesting tradeoffs and simplest-first ordering. Write specifications before prompting for implementation; the “vibe spec-ing” approach where AI helps create the spec collaboratively, then implements against it.
Use “authoritarian mode” as Simon Willison describes: provide exact function signatures, specify libraries and versions, constrain the solution space. “I find LLMs respond extremely well to function signatures… I get to act as the function designer, the LLM does the work of building the body.”
Leverage extended thinking when available (Claude Code’s “ultrathink” triggers) but recognize this is for understanding and planning, not for writing more code. The goal is better decisions, not more output.
For full autonomous agent workflows
The prerequisites are robust: strong git hygiene, backup systems, clear blast-radius thinking. Run agents on main branch rather than elaborate worktree setups; Steinberger found the merge conflict overhead exceeded the isolation benefit.
Prompts should be short and direct. Once you’ve developed intuition with a model, “1-2 sentences + an image” often suffices. Maintain living instruction files (CLAUDE.md, AGENTS.md) that agents themselves update with project-specific knowledge.
Queue work for long-running tasks: “If you do a bigger refactor, codex often stops with a mid-work reply. Queue up continue messages if you wanna go away and just see it done.”
Write tests after features, not before, in the same context where the feature was built. This produces better tests and catches implementation issues while context is fresh.
The meta-skill: conscious autonomy calibration
The deepest insight from this research: the most effective developers don’t occupy a fixed position on the spectrum. They consciously adjust their autonomy level based on task stakes, their expertise in the domain, time pressure, and available safety nets.
Karpathy demonstrates this when his own Nanochat project ends up “basically entirely hand-written” because “I tried to use Claude/Codex agents a few times but they just didn’t work well enough at all.” Even the person who coined vibe coding recognizes when to abandon it.
Steinberger shows the other direction; high autonomy as a default that can be dialed down when blast radius concerns warrant it.
The framework isn’t about finding your archetype and staying there. It’s about developing the judgment to know which mode serves each situation. The autonomy slider is always in your hands. The skill is learning when to move it.
Conclusion: A diagnostic framework
For developers seeking to optimize their LLM collaboration, the diagnostic questions are:
What is the blast radius of failure? Throwaway prototype versus production system determines baseline autonomy level. Most developers should operate at higher autonomy for exploration, lower for production; the 72% rejection rate of vibe coding in professional work reflects appropriate risk calibration.
Can you verify the output? High domain expertise enables high autonomy. If you can’t evaluate whether the code is correct, you need either more verification steps or lower autonomy. This is why senior developers can safely delegate more than juniors.
What’s your actual feedback loop speed? If parallel agents feel productive but aren’t producing results, switch to sequential fast iteration. Dax Raad’s insight; “the productivity feeling is real, the productivity isn’t”; deserves serious consideration.
What safety nets exist? Git discipline, backups, testing infrastructure, and isolated execution environments all enable higher autonomy by reducing downside risk.
The tools and techniques exist for every point on the spectrum. The competitive advantage comes from consciously choosing your position rather than defaulting to whatever feels comfortable or impressive.