DEV Community: Thiago Pacheco

The Most Important Skill in Tech Is Too Expensive to Learn

Thiago Pacheco — Sun, 19 Apr 2026 16:11:39 +0000

I spent last weekend trying to build a feature with an open-source model running locally. Qwen, 32 billion parameters. I gave it the same task I’d done with Claude the week before — a well-scoped feature, clear spec, defined constraints. The kind of work where I know exactly what good output looks like.

It took me four attempts to get something that compiled. Not something that worked well — something that compiled. The model kept losing context halfway through, hallucinating imports that didn’t exist, and confidently generating patterns that contradicted what I’d specified three prompts earlier. I spent more time correcting its output than it would’ve taken me to write the thing from scratch.

The same task with Claude Opus 4.6 in Claude Code? One pass. Clean implementation. Twenty minutes.

And before you say “just use a better open-source model” — I know. The strongest open-source models today are genuinely capable. But running them at full quality locally requires serious hardware. We’re talking high-end GPUs, machines that cost thousands of dollars. If you don’t have that, your alternative is a provider like OpenRouter — more accessible, but sustained agentic sessions still add up fast. You can quantize the models to fit smaller hardware, but you’re trading quality for affordability, which is the whole problem.

Either way you’re paying. Local hardware or API costs. And the people who most need access to this technology are the ones least able to afford either option.

The Skill That Runs Everything Now

Using AI effectively is becoming the most important skill in the industry. And I don’t mean prompting — that’s the surface-level version of the conversation that keeps people stuck.

There are actually two layers to this skill, and both of them have an access problem.

The first layer is the judgment. It’s knowing how to scope a problem so the model can handle it. It’s developing the instinct for when the model is right and when it’s subtly wrong in ways that won’t show up until production. It’s understanding how to work with the model’s strengths and around its weaknesses. This is the soft skill side — the part that requires reps with models that are good enough to teach you something. If the model you’re working with fails in ways that have nothing to do with your approach — losing context, ignoring constraints, hallucinating — you’re not developing the skill. You’re just debugging a bad tool.

The second layer is the one that doesn’t get talked about enough: the practical configuration.

Look at what’s happening with Claude Code right now. There’s an entire ecosystem forming around it — CLAUDE.md files that teach the agent your project’s conventions, subagent configurations that break complex work into orchestrated pieces, hooks that enforce guardrails automatically, skills and plugins that extend what the agent can do. People are building and sharing these configurations the way they used to share dotfiles or ESLint configs. It’s becoming its own discipline.

And it matters. A well-configured Claude Code setup with proper project memory, clear guidelines that evolve with the codebase, and hooks that catch mistakes before they compound — that’s not a nice-to-have anymore. That’s the difference between the agent producing useful work and producing junk. Learning how to structure that configuration, how to set up subagents for different tasks, how to write project guidelines that actually steer the model’s behavior — these are real, practical, in-demand skills.

But here’s the problem: all of that knowledge is being built on top of Claude Code specifically. The skills, the hooks, the configuration patterns, the community sharing best practices — it’s all deeply tied to a $100-200/month tool running the most expensive models available. The more sophisticated the ecosystem gets, the deeper the lock-in. And the deeper the lock-in, the more expensive it becomes to develop the skills that actually matter.

It’s not just “learn to use AI.” It’s “learn to configure and orchestrate AI agents at a level of sophistication that requires sustained access to premium tools.” And that’s a much harder problem to solve with free tiers and quantized local models.

Both layers of this skill are becoming as foundational as knowing Git or being able to navigate a codebase. Except they’re evolving faster than any of those did, and the cost of staying current is real money.

The Model Is the Bottleneck

People talk about harnesses — Claude Code vs Cursor vs Codex vs whatever dropped this week. And yeah, the tooling matters. But you can run Claude Code with a local model if you know the tricks. You can plug open-source models into most of these harnesses.

It doesn’t fix the problem.

Because the output is limited by the model itself. A great harness with a mediocre model produces mediocre results with better formatting. The agent can manage files, run commands, iterate on errors — but if the model behind it can’t hold context or reason through the nuance of what you’re building, the loop just generates more mistakes faster.

The top-tier models — Claude Opus 4.6, GPT-5.4 — are meaningfully better at the things that matter for real development work. They hold context longer. They understand relationships between components. They catch their own mistakes more often. They produce code that requires less intervention. These aren’t marginal benchmark differences. These are differences you feel in every single session.

And every one of those models costs money. Claude Pro is $20/month and you’ll hit rate limits in a day doing serious work. The Max plan that actually lets you use Claude Code without interruption is $100-200/month — and that only covers Claude Code, not other harnesses. Cursor Pro, Copilot Pro — more subscriptions stacking up. If you want the workflow that actually builds the skill the market is demanding, you’re spending real money every month.

Who Gets Left Behind

Think about three people.

The junior developer, fresh out of school. They’ve heard AI is important. Maybe they’ve used ChatGPT for homework. But the landscape of AI coding tools is an overwhelming mess — Copilot, Cursor, Claude Code, Codex, Windsurf, and a dozen others, each with different pricing, different paradigms, different ecosystems. They don’t know which one matters. They don’t know which one to invest in. And the ones that would actually teach them the most important patterns cost money they don’t have. Sure, there are free tiers — Copilot gives you 2,000 completions and 50 chat requests a month, and OpenRouter has free models with rate limits. But those tiers are built for tasting, not for training. You can’t develop real fluency in 50 requests a month.

The experienced developer who got laid off. Yesterday they had Claude Pro through their company, API access for experiments, maybe a Cursor license on the company card. Today they have none of it. The skill they were building — the one that was making them genuinely more effective — just got cut off overnight. And the market they’re re-entering expects AI proficiency as a baseline. They know what they’re missing because they’ve felt the difference. That might be worse than never having had it at all.

The career switcher. Someone coming from another field, trying to break into tech. They’re already learning to code, which is hard enough. Now they need to learn to work with AI too, but the models that would give them meaningful reps are priced for people with engineering salaries. They’re trying to build a skill they can’t afford to practice.

Each of these people has a slightly different version of the same problem: the skill the market values most is developing behind a price tag most people can’t justify.

Some companies are subsidizing tools for their employees now. That’s real, and it’s good. But it only helps people who already have jobs. It does nothing for the people trying to get in. And even for employed developers, there’s a difference between using a company-provided tool in a company-specific workflow and building genuine AI fluency that transfers. Getting good at your team’s setup isn’t the same as understanding the patterns deeply enough to adapt when everything changes in six months. Which it will.

What I’m Actually Doing About It

I’d feel dishonest writing this without being transparent about where I am personally.

I’ve been deliberately pushing open-source and cheaper models harder in my own workflow. Running local models on my machine, using cheaper options through OpenRouter, trying to find the ceiling of what’s accessible today. Not because I think they’re better — I just spent several paragraphs telling you they’re not. But because I think there’s real value in mapping out what’s possible without the premium price tag.

Here’s what I’ve found so far, honestly.

Local models on the modest hardware I have today are very behind. It’s not close. The gap between what I get locally and what Claude Opus 4.6 or GPT-5.4 produce isn’t a minor quality difference — it’s a fundamentally different experience. The local models lose context, miss nuance, and require constant hand-holding that defeats the purpose of the workflow.

The cheaper models through OpenRouter are better — you can get genuinely good responses. But there’s a catch: you have to constrain the work to small, well-defined tasks to get consistent output. You can’t be vague. You can’t be high-level. You can’t describe what you want broadly and trust the model to figure out the details the way you can with the top-tier models. Every task needs to be broken down, specified precisely, and scoped tightly.

And that creates its own problem. Because sometimes, by the time you’ve broken the work down small enough and specified it precisely enough for the cheaper model to handle it reliably, you’ve already done most of the thinking. At that point, it’s genuinely faster to just write the code yourself than to spend the time guiding the model through it.

That’s the real gap. It’s not just quality of output — it’s how much of your own effort is required to get there. The top-tier models let you think at a higher level of abstraction. The accessible ones force you back down into the details, which is exactly where AI was supposed to save you time.

I haven’t tested Gemma 4 deeply yet — I have high hopes for it given what the benchmarks are showing. But I’m not going to claim results I haven’t experienced. For now, I keep pushing because I believe the trajectory is real. But the honest answer is that nothing I’ve tried on the accessible side comes close to what the premium models deliver.

The Industry Problem We’re Building

It takes years to develop a senior engineer. I’ve written about the pipeline problem — how cutting junior hiring today creates a senior shortage in 7-10 years. But this is a different angle on the same structural failure.

Even the developers who do break in — if they can’t afford to develop AI fluency early, they’re starting with a deficit that compounds over time. The developers who had access to top-tier models from day one are building intuitions, workflows, and judgment that the others can’t match. Not because of talent. Because of access.

We’re building a two-tier system. People who learned to work with AI at the highest level because they could afford to, and people who picked up what they could from free tiers and rate-limited demos. The gap between those two isn’t trivial — it’s the difference between building the instinct for what works and just knowing it exists in theory.

For decades, the software industry had a genuine claim to accessibility in at least one respect: the tools were free. You could learn to code with free software, contribute to open-source projects, build a portfolio, and land a job without spending a dollar on tooling. The playing field wasn’t level — it never is — but the tools didn’t gatekeep you.

AI is changing that equation. Not because the models are secret — many are open-weight. But because the models that are good enough to build the skills that matter require compute that costs real money. And nobody seems to be treating this as the urgent problem it is.

The Bet

I don’t have a clean answer for this. If I did, I’d be building a company, not writing a blog post.

But I’m not betting blind either. The trajectory is real.

Google just released Gemma 4 under Apache 2.0 — a family of models designed to run on consumer hardware, with coding benchmarks that show massive jumps over the previous generation. DeepSeek keeps pushing the boundaries of what’s possible at low cost, with their next model aiming for frontier performance under an open license. Qwen continues to improve. The open-source community is moving fast, and the gap between these models and the proprietary ones is genuinely narrowing.

But narrowing isn’t closed. And the people who need access most can’t wait for the trajectory to finish.

I’m betting that how accessible these tools become in the next two years will shape the entire next generation of professionals. The people entering the industry right now, the people trying to transition, the ones who got pushed out and are fighting their way back — they’re being shaped by what they can and can’t access today. If the most important skill of their era is only learnable at premium prices, we’re not just failing them individually. We’re hollowing out the pipeline the entire industry depends on.

What we call “software developer” is becoming something else. AI engineer, maybe. Whatever it gets called, the core competency is shifting — less about writing code, more about orchestrating intelligence. Making judgment calls about what to build and how to specify it. That competency needs to be learnable at every price point. Not just the premium tier.

For now, I’m going to keep pushing open-source models in my workflow. Keep documenting what works and where the walls are. Keep being honest about the gap while working to close it, even in my own small corner.

Because if the most important skill in tech is too expensive to learn, we have a bigger problem than any model can solve.

References

Google Gemma 4 announcement — Apache 2.0 open models designed for consumer hardware, with native agentic and coding capabilities
DeepSeek V4 specs and benchmarks — ~1T parameter MoE model, 37B active per token, targeting frontier performance under open license
Qwen 3.5 local hardware guide — Running large open-source models on consumer devices with quantization
Gemma 4 coding benchmarks — LiveCodeBench scores jumping from 29.1 to 80.0 between Gemma 3 and Gemma 4
GitHub Copilot plans — Free tier: 2,000 completions, 50 chat requests/month
Claude Code pricing breakdown — Max plan at $100-200/month for sustained use
OpenRouter free models — 29 free models with rate limits (20 req/min, 200 req/day)
AI divide at work — ETS report — Regular AI users feel more secure; others are falling behind
Open vs closed AI models — Epoch AI — Tracking the gap between open-weight and proprietary models over time

The post The Most Important Skill in Tech Is Too Expensive to Learn appeared first on sudoish.

No Developer Feels AI Literate Right Now — Not Even the Ones Building It

Thiago Pacheco — Sun, 19 Apr 2026 16:11:18 +0000

There’s a specific kind of anxiety that hits at 11 PM when you’re scrolling through someone’s thread about the AI workflow that supposedly changed everything. You were productive today. You shipped code. But now you’re wondering if the way you shipped it is already obsolete.

That feeling? It’s not going away. And I say that as someone who builds AI features every day at my job — user-facing products, developer tools, infrastructure — and uses AI to build them too. I’ve been deep in this flow for a while, and I still don’t feel AI literate. Nobody does.

That’s the whole thesis.

The Illusion of AI Fluency

There’s a dangerous gap forming right now — the distance between “I can get AI to produce code” and “I understand what’s happening well enough to make consistent, reliable decisions.”

It’s like ordering coffee in another language and thinking you’re fluent. The demo works. But what happens when the context window fills up and the model starts hallucinating? When the tool you’ve been relying on ships a breaking change to how it handles context, and your entire workflow stops working?

That’s where actual literacy lives. Not in the output — in understanding the mechanics well enough to troubleshoot, adapt, and make real decisions.

The Arc: Convergence to Divergence

Here’s a pattern worth naming, because it explains why everything feels so chaotic.

For the past couple of years, AI coding tools followed roughly the same trajectory. First the conversational phase — chat with a model, get code back. Then the agentic phase — let the model execute actions, read files, run commands. Then context management became the bottleneck — RAG, context windows, retrieval strategies. Then skills and MCPs emerged as ways to extend what agents could do.

Every major tool went through these same stages. Claude Code, Cursor, Copilot, Codex — the patterns were recognizable across all of them. If you learned one, the mental models transferred.

That’s no longer true.

The tools are diverging. Fast. Claude Code now has hooks, subagents, trust modes, and a growing ecosystem of skills. Cursor has its own rules system with a fundamentally different interaction model. Codex has AGENTS.md. Amp, OpenCode, and a dozen others are carving their own paths.

Each tool is developing its own opinion about how development should work. And those opinions are starting to meaningfully diverge.

This is React vs Angular vs Vue all over again — except the stakes are higher. That was about which UI library renders faster. This is about how you think, plan, and build software at a fundamental level.

The Best Practice Treadmill

A few weeks ago, the developer community was buzzing about skills replacing MCPs. Skills were simpler, lighter, didn’t require running separate processes. The consensus was forming: skills are the future, MCPs are the past.

Then optimizations changed the calculus on MCP context consumption. Suddenly MCPs were more viable again. The narrative flipped.

Now? People use a mix of both. Some skills actually wrap MCPs internally. Nobody’s sure if that’s a good pattern or an anti-pattern.

This all happened in the span of a few weeks. And it’s the new normal — the “right way” to structure your AI workflow has a half-life measured in weeks, not months.

So What Does This Mean for Your Career?

If senior engineers with years of pattern recognition and deep technical foundations feel lost — what does this mean for someone finishing college right now? Or someone transitioning into tech?

I’ll be direct: it’s harder than ever to get a job as a software engineer. You don’t just need to know how to code anymore. You need to know how to code, how to work with AI, which AI tools to invest in, and how to recognize when current practices expire. Most bootcamps and university programs haven’t even begun to address this. And companies don’t know what to test for either — interview loops are still measuring skills from two years ago while the actual job involves orchestrating agents and making architectural decisions AI can’t make for you.

So the question people are asking — “Is it even worth learning software engineering right now?” — is genuine.

Here’s what I think: the answer is yes. But the approach has to change.

The demand for engineers isn’t dying — job openings have surged this year, and companies that replaced senior engineers with juniors-plus-AI are already course-correcting. Human judgment, architectural thinking, and the ability to make sense of complex systems still matter. But you can’t just learn to code and expect that to be enough anymore.

Pick One Tool. Get Dangerously Good at It.

Stop trying to learn every coding harness. Don’t split your attention between Claude Code, Codex, Amp, OpenCode, and whatever drops next week. Pick one. Commit to it. Go deep.

There’s research backing this up. BCG found that productivity increases with one or two AI tools, peaks around three, and actively drops when you add a fourth. They’re calling it “AI brain fry” — more tools means more context switching, more cognitive load, worse outcomes. Mastering one tool isn’t just a preference. It’s the strategy that actually works.

I’ll tell you what I use: Claude Code. It has the richest set of capabilities right now — hooks, skills, subagents, MCP integrations, trust modes — and Anthropic’s models consistently deliver. The community around it is the most active I’ve seen. That could change in six months. But the point isn’t really the specific tool.

When you deeply learn one tool — when you understand how it manages context, how its agentic loop works, how to structure your projects for it — you develop transferable mental models. You learn what “good context management” means, not just how one tool implements it. You learn why hooks exist, why skills exist, why MCPs exist. Those patterns survive the churn.

If the tools diverge to the point where switching becomes necessary, you’ll transition from a place of strength — deep literacy in one ecosystem — rather than shallow familiarity with five.

Build Something That Felt Impossible

Theory doesn’t stick without practice.

Think of a project you’ve always wanted to build but never had the time. Something slightly out of reach — too many moving parts, too much boilerplate, too many unknowns. Now try to build it with your AI coding tool of choice.

Here’s my example. I’d been wanting to rebuild my blog with a custom WordPress theme for months. I knew exactly what I wanted — the design, the deployment pipeline, the git integration. What I didn’t have was the time to write it all out.

So I started prompting my agent harness while at the gym. Between sets, between exercises — describing what I needed, reviewing what came back, steering it. Within about three days of gym sessions and prompting, the new blog was live.

That was a genuine wow moment. Not the viral demo kind — the personal kind. It didn’t come for free. I knew what to ask for, which tools to use, how to set up the deployment. But I never had to remember WordPress internals or look at a single line of code.

Don’t aim for perfection. Just try to get it done and pay attention to how it feels. You’re going to land in one of two places.

You build the thing faster than you ever could have alone. Maybe the code isn’t pristine. Maybe you restarted a couple of times. But it works, and you built it in hours instead of weeks. That wow moment is fuel — it motivates you to refine your prompts, learn the next layer, keep pushing.

Or you struggle. The agent loops. It misunderstands your intent. You feel like you’d be faster doing it yourself.

If you land here, don’t get discouraged. And don’t become someone who dismisses AI as useless based on a bad first experience.

What almost certainly happened is that your scope was too broad. You gave the agent a vague, ambitious prompt and expected it to figure out the details. That’s the most common mistake starting out.

The fix: shrink the scope. Way down. Pick the smallest piece — a single endpoint, one component, a basic data model — and try again. Get one small thing working. Feel what it’s like when the tool actually helps. That’s your baseline. From there, you gradually expand — bigger scope, better context, more trust in the loop.

The Uncomfortable Truth

Nobody has this figured out. Not the senior engineers. Not the tool makers. Not the influencers who post their workflows like they’ve cracked the code.

The developers who are going to thrive aren’t the ones who memorize every feature of every tool — they’re the ones who build a learning rhythm they can sustain. Context management, agentic workflows, prompt design, scope control. These patterns are more stable than the specific implementations, and they’re what make you dangerous regardless of which tool you’re holding.

Pick one tool. Build one thing. Learn one lesson at a time.

References

The impact of AI on software engineers in 2026 — Pragmatic Engineer survey (900+ engineers on AI tool usage, costs, and uneven effects across experience levels)
BCG: AI Brain Fry study — Productivity peaks at 2-3 AI tools and drops at 4+
Software engineer job listings up 30% in 2026 — 67,000+ openings per TrueUp
Why companies are quietly rehiring software engineers — The “boomerang effect”: ~35% of new hires are former employees
Redefining the future of software engineering — MIT Tech Review on agentic AI as the “third shift”
JetBrains: Which AI coding tools do developers use at work? — 74% of developers adopted AI tools; Claude Code and Cursor tied at 18%

The post No Developer Feels AI Literate Right Now — Not Even the Ones Building It appeared first on sudoish.

Spec-Driven Development Isn’t Waterfall — But It Keeps Ending Up There

Thiago Pacheco — Fri, 17 Apr 2026 22:05:14 +0000

Spec-driven development isn’t supposed to be waterfall. But without clear workflows and better tooling, it’s easy to end up there.

I recently went deep on spec-driven development. The idea was straightforward: before writing any code, define everything. The full vision, the context, the trade-offs, where the feature fits in the existing architecture, the references. Hand it all to the AI agent with crystal-clear guidance so it can build with minimal supervision.

It looked promising. For about two days.

What I ended up with was thousands of lines of specification documents. Documents that were incredibly hard to review — not because they were poorly structured, but because most of them were generated by the AI itself, correlating the existing architecture, docs, and my guidance into something that looked authoritative. Clear explanations. Perfect formatting. Confident reasoning about every decision.

And that’s exactly where it got scary.

The Confidence Problem Nobody Mentions

Here’s the thing about AI-generated specs that the SDD evangelists aren’t talking about: the AI makes everything look correct.

When a spec is well-formatted, internally consistent, and confidently explained, your brain wants to trust it. It reads like something a senior architect wrote after careful deliberation. But it’s not. It’s a language model pattern-matching against your inputs, producing the most plausible-sounding output it can.

And here’s the trap within the trap: if you push back on something that feels off, the AI doesn’t defend its reasoning. It folds. It assumes you’re right, tries to course correct, and often makes the output worse. Hallucination risk actually goes up when you question it, because now it’s reconciling your objection with a position it never truly held. It’s not reasoning. It’s pleasing.

So you’re stuck. Trust the spec and risk building on wrong assumptions. Question the spec and risk destabilizing it further. Either way, you’ve generated thousands of lines of documentation that are incredibly hard to confidently validate.

After spending far too long trying to get those specs to a place I trusted, it hit me — this felt familiar.

The Intent vs. the Reality

Here’s where I want to be fair: spec-driven development isn’t supposed to be big design upfront.

Marc Brooker, the person building Kiro at AWS, explicitly says “you don’t need to, and probably shouldn’t, develop the entire specification upfront.” Kiro’s own workflow is feature-scoped — requirements, design, and tasks for a single story, not a whole system. GitHub’s Spec-Kit runs in a loop: specify, plan, tasks, repeat per change request. OpenSpec literally states “specs are not frozen contracts; update them when reality changes.”

The vision of SDD is iterative. Living documents. Feature-level scope. Incremental refinement.

But the vision and the practice aren’t the same thing yet.

Birgitta Böckeler, writing on Martin Fowler’s site, tried to untangle what SDD actually means right now and found the definition “still in flux.” She identified three levels — spec-first, spec-anchored, and spec-as-source — and noted that most tools are only spec-first. They help you write a spec before coding, but don’t have clear strategies for maintaining or evolving that spec over time. Even GitHub Spec-Kit’s own community is confused about whether a spec is supposed to live beyond a single change request.

The methodology is ahead of the tooling. SDD can absolutely work — but right now, the tools and workflows don’t do enough to keep you on the iterative path. Without clear guardrails for when to stop specifying and start building, teams default to the thing that feels most natural: writing everything down upfront, as thoroughly as possible, before anyone touches code.

That’s what happened to me. Not because I didn’t know better. Because nothing in the workflow guided me toward “that’s enough, go build and come back.”

The Waterfall Gravity

There’s a reason teams keep falling into this pattern. It has gravitational pull.

When you tell an AI agent to help you write a spec, it wants to be comprehensive. It will map out every component, every edge case, every integration point — because that’s what “thorough” looks like in its training data. And as a developer, you want to feel like you’ve thought of everything before handing off to an autonomous agent. The combination of an AI that defaults to exhaustive and a human who defaults to cautious creates thousands of lines of documentation almost by accident.

This is the same dynamic that made waterfall feel so appealing in the first place. The Agile Manifesto exists because planning everything upfront didn’t work:

Responding to change over following a plan.

SDD proponents will rightly say “that’s not what we’re advocating.” And they’re right. But the tooling needs to actively enforce iterative scope — otherwise that gravity keeps pulling teams toward specifying everything before building anything. The intent is agile. The default behavior, without better rails, is waterfall.

Of course, agile itself got convoluted over the years. Certifications, rituals, dogma that drifted far from the original insight. But the core idea never stopped being true: you learn more from building than from planning.

Thoughtworks — the company whose chief scientist co-authored the Agile Manifesto — just released Technology Radar v34 this week, warning that as AI accelerates code generation, “established practices that ensure discipline become more vital.” They’re not pushing SDD. They’re pushing fundamentals. Iteration. Feedback loops.

What SDD Gets Right

I don’t want to dismiss the methodology. There are real benefits when it works.

Agents need constraints. Without scope boundaries, they expand. Tell an agent to build auth and it’ll add OAuth, SSO, and MFA because that’s what “auth” means in its training data. A spec that says “OAuth is out of scope” genuinely saves time.

Context improves quality. An agent with the full picture makes fewer locally-right-but-globally-wrong decisions. The spec gives it a map, not just turn-by-turn directions.

Team alignment. Multiple people or agents working on the same system need a shared reference point. Specs provide that.

The problem was never “should we spec?” It’s “how do we make sure we spec iteratively instead of falling into the trap of specifying everything at once?”

Thinking in Graphs

Here’s where I’ve landed — and maybe this is just how my brain works, but I think it applies broadly.

I think about projects as graphs, not documents.

At the top, there’s a direction. A north star. What we’re building and why. High-level, intentional, human-defined. It doesn’t need to specify every data model or API contract. It needs to be clear about the destination.

From that direction, you break down into milestones. Each milestone is a meaningful checkpoint — something you can ship, test, or validate. Not a document section. A real deliverable.

Each milestone has its own tasks. And here’s the critical part: the depth of planning for each task happens when you start working on it, not months before. You plan the first milestone in detail. You sketch milestone three at a high level. When you finish milestone one, you know things you didn’t know before — and that knowledge shapes how you plan milestone two.

The direction flows down from the north star. Discovery happens at every node.

Say you’re building a new integration. The north star says: “Users can sync data between System A and System B in real time.” Milestone one might be a basic one-way sync — and when you build it, you discover the API rate limits aren’t what the docs claimed. That changes everything about milestone two. If you’d fully specced bidirectional sync upfront, you’d be rewriting specs instead of shipping software.

This works for humans because it provides structure without drowning you in premature detail. It works for AI agents for the same reason — they need guidance and constraints, but they also need room to discover things during implementation that no spec could have predicted.

Full upfront specification tries to flatten the graph into a document. Every node defined, every edge mapped, before you’ve traversed any of them. That’s not engineering. That’s prophecy.

What This Looks Like in Practice

I’m still figuring this out. There is no perfect workflow yet — that’s kind of the point. But here’s the pattern that’s working:

Thin specs, not thick ones. One page for the current milestone, not twenty pages for the whole system. Define the outcome, the constraints, what’s out of scope. Leave room for what you don’t know yet.

Iterate the spec, not just the code. The spec changes every cycle. Decisions made, assumptions validated or invalidated, things learned by building. A living document, not a contract. This is what SDD’s proponents advocate — we just need clearer workflows and tooling to make this the default path instead of something you have to consciously enforce.

Use agents for exploration, not just execution. Code is cheap now. Build a quick prototype to test an architectural assumption. Throw it away if it’s wrong. A throwaway prototype costs you nothing. Specifying the wrong architecture upfront costs you everything.

Keep the loop tight. In traditional agile, the sprint was two weeks. With agents, the feedback loop can be hours. Specify, build, test, learn, adjust. But only if you keep the scope small enough to actually iterate.

The Gap That Needs Filling

The industry is living through a real-time methodology shift:

Vibe coding — prompt and pray. Fast, chaotic, doesn’t scale.
Spec-driven development — specify, then execute. Sound in theory, but easy to fall into big design upfront without clear process guardrails.
What comes next — the iterative spec workflow that SDD envisions, supported by tooling and processes that actively keep teams on that path. Thin specs. Fast execution. Continuous refinement. Direction without prophecy.

This is the same arc software development has followed before. Waterfall promised control through upfront planning. Agile recognized that the plan always changes. We’re at that inflection point again — the insight of iterative development needs to be baked into the tools and workflows, not just the blog posts and documentation.

A project with a clear direction, meaningful milestones, and task-level depth that’s earned at execution time — not guessed at months before — works for both humans and AI agents. Structure without rigidity. Guidance without false certainty.

The agents are fast. The models are capable. But the bottleneck was never the code.

It was knowing what to build. And you only learn that by building.

Spec-driven development’s vision is right: specs should be living, iterative, and at the center of how we build software with AI. What we need now is better tooling and clearer processes to make that vision the default — so teams stay on the iterative path instead of drifting into the upfront-planning trap that agile was invented to escape. The Agile Manifesto didn’t expire. It just got a new executor — and that executor needs better guardrails.

The post Spec-Driven Development Isn’t Waterfall — But It Keeps Ending Up There appeared first on sudoish.

Clean Code Is Dead (And I Hate That I Agree)

Thiago Pacheco — Sun, 12 Apr 2026 10:53:52 +0000

I’ve spent my career fighting for clean code. In code reviews, in architecture meetings, in those long debates about naming conventions that everyone pretends to hate but secretly cares about. Readable code. Well-structured code. Code that respects the next person who has to touch it.

I’m starting to realize that none of that might matter anymore.

Clean Code Was Always a Human Interface

Every clean code practice we follow was invented to solve a human problem.

Descriptive variable names? So a human can read it. Separation of concerns? So a human can navigate it. Consistent formatting, small functions, clear abstractions? All of it — designed to make code convenient for people to write and to read.

The entire philosophy assumes that humans are the primary audience of source code.

But what happens when they’re not?

AI Doesn’t Need Your Clean Code

The more we rely on AI to write, review, and maintain code, the less we actually know the implementation details. And I don’t mean that in a lazy way — I mean structurally. The workflow is changing. You describe what you want, AI generates it, you review the output at a high level, and you move on.

AI doesn’t care about your variable names. It doesn’t need elegant abstractions to understand what’s happening. It processes the entire codebase — messy or clean — with the same indifference. It doesn’t get confused by a 500-line function. It doesn’t lose context the way a human does after scrolling through too many files.

I had a moment recently that made this click. I was reviewing AI-generated code and caught myself leaving comments about naming and structure — the same feedback I’d give a junior dev. Then I paused. Who was I writing these comments for? The AI would regenerate the whole thing from scratch on the next prompt anyway. I was applying human code review instincts to a process that doesn’t have a human on the receiving end (sort of). Old habits addressing a problem that no longer exists.

The practices we built specifically for human readability and human convenience are becoming overhead. In some cases, they’re becoming a bottleneck — extra layers of abstraction that add complexity without benefiting the thing that’s actually doing the reading.

This isn’t a thought experiment. This is already happening in how teams ship software.

The Highest Level Language Is English Now

If readability stops being the priority, what takes its place? Performance.

If AI can handle the complexity regardless, why optimize for human readability when you can optimize for raw execution speed? The ideal language for AI-driven development might not be Python or TypeScript. It might be C. It might be Rust. It might be something even lower level where AI has fine-grained control over memory, threading, and every implementation detail — things that are painful for humans but trivial for a model that doesn’t get frustrated.

We’ve always talked about “high level” and “low level” languages. High level meant closer to human thinking, low level meant closer to the machine. But now there’s a level above all of them.

English. Portuguese. Mandarin. Whatever you speak.

Natural language is the highest level language now. LLMs are remarkable polyglots — they work fluently in all of them. And code? Code is just the compilation target.

We went from writing machine instructions, to writing human-readable code, to just… describing what we want in plain words. Each step abstracted away more control. Each step moved us further from the metal.

We’re Losing Control at Every Layer

It’s not just that AI writes the code. People use AI to plan the work, brainstorm the architecture, make decisions about what to build and how to build it. The entire pipeline — from idea to implementation — is being routed through language models.

And LLMs are dangerously convincing. Their reasoning is well-structured even when the underlying data is fabricated or slightly off. I’ve caught myself reading an AI-generated explanation, thinking “yeah, that makes sense,” only to realize later that a key detail was subtly wrong. Or worse — never realizing it at all. The convincing tone becomes a trap.

You could argue that humans were never perfectly accurate either. Fair. We’ve always built software on incomplete knowledge and best guesses. But there was something grounding about having a person in the loop who had intuition, experience, and skin in the game. Someone who could smell when something was off, even if they couldn’t articulate why.

The more we delegate — not just the coding, but the thinking — the more that instinct fades. And I’m not sure we’re paying enough attention to what we’re losing.

Maybe I’m Too Attached to the Craft

Maybe I’m romanticizing this. Maybe code was always just a means to an end and I turned it into something more than it needed to be. I built part of my identity around writing good code, caring about architecture, treating the codebase as a product in itself. It’s hard to watch that become irrelevant and not take it personally.

Maybe I’m onto something. Maybe the people who cared about the craft will be the ones who notice when the quality starts slipping in ways that AI can’t detect. Or maybe that’s just what I tell myself to feel relevant.

I genuinely don’t know.

And I can’t be a hypocrite about it. This very piece — I’m using AI to help me review it, refine the structure, make sure it reads well. I’m literally writing about the death of human craft while using the thing that’s killing it to help me write better.

But the ideas are mine. The opinions are mine. The discomfort is mine. AI didn’t tell me to feel this way — I felt it, and then I used a tool to articulate it more clearly. There’s a difference between using AI as a tool and being used by it. At least I think there is.

The Mental Model Shift

I don’t have a solution. But I’ve been rethinking how I relate to the work, and that’s helped more than any specific tool or workflow.

The shift is this: if code is becoming the compilation target, then what you’re really building isn’t the code — it’s the system of decisions that produces it. Your taste. Your standards. Your judgment about what good looks like. That’s the actual product now.

And that’s something you can teach to AI.

I’ve been experimenting with this — taking the patterns I’ve developed over years of writing software and encoding them into the tools I work with. Not just “generate a function that does X” but “here’s how I think about error handling, here’s my preference on abstraction depth, here’s what I consider acceptable tradeoffs.” The more specific you get about your own engineering philosophy, the more the output starts to feel like yours instead of generic AI slop.

This isn’t complicated or expensive. The tooling to build your own AI workflows — agents that understand how you work — is accessible today in a way that would’ve been unthinkable two years ago. You don’t need a team or a platform. You need clarity about your own standards and the willingness to invest time in teaching them.

If you’ve spent years developing engineering taste, that taste is now leverage. You can apply it at a scale that was never possible when you had to write every line yourself. More ambitious projects. More complex systems. Things that would’ve required a team, handled by one person with clear vision and the right tools.

It only works if you stay in the driver’s seat though. If you’re the one making the calls about what ships and what gets thrown away. Not a consumer of whatever AI generates, but the lead. The final authority.

And right now, I’m watching a lot of people quietly stop being that.

I Don’t Have a Clean Answer

If language models keep evolving at even half the pace we’ve seen over the last couple of years, the industry in five years looks nothing like it does today. The way we think about programming, about code quality, about what it means to be a software engineer — all of it is up for renegotiation.

I don’t have a neat conclusion. I have a tension I’m sitting with, and I think a lot of developers feel it too even if they haven’t put words to it yet.

Clean code might be dead. The practices, the principles, the carefully named variables and thoughtfully extracted functions — they might genuinely become artifacts of an era when humans needed to read what humans wrote.

But the intention behind clean code? Caring about what you build. Taking pride in the craft. Giving a damn about quality even when no one is looking?

That can’t die. Unless we let it.

The post Clean Code Is Dead (And I Hate That I Agree) appeared first on sudoish.

You Think, AI Executes: The Skills That Actually Matter

Thiago Pacheco — Mon, 06 Apr 2026 02:58:16 +0000

The most valuable developer skill right now isn't writing more code faster. It's learning unfamiliar codebases, building context that guides decisions, planning strategic approaches to problems, and shipping production code with confidence.

I recently added .env file support to xc, a Markdown-based task runner written in Go. The codebase was completely unfamiliar. I'm not a Go expert. But in 2.5 hours, I went from zero knowledge to a production-ready pull request with 84% test coverage and zero bugs in manual testing.

Here's what's different: I didn't write a single line of code. Not one. AI wrote everything—tests, implementation, integration, documentation. My role was entirely different: I questioned, I planned, I directed, I reviewed. I read the code, but I didn't write it.

This isn't another "I asked ChatGPT to build an app" story. This is about the skills that separate developers who use AI as a force multiplier from those who just ask it to generate code. It's about onboarding fast, documenting strategically, planning thoroughly, directing execution, and reviewing confidently. The code writing? That's handled.

Complete .ai/ folder in the working fork:

github.com/sudoish/xc/tree/ai-context/.ai

Production-ready PR:

github.com/joerdav/xc/pull/167

The .ai/ folder lives in a separate ai-context branch so it doesn't clutter the main codebase but remains available for reference and iteration.

Why This Matters

Most AI coding demos show you the magic: "I asked ChatGPT to build X and it worked!" They skip the parts that actually matter for professional development: How do you onboard to a codebase you've never seen? How do you make architectural decisions when you don't understand the patterns yet? How do you ensure your code is production-ready when AI helped write it?

These are the skills that matter now. Code generation is table stakes. What matters is context building, strategic planning, and confident execution.

Here's the project: xc, a task runner that reads tasks from Markdown files. About 5,000 lines of Go. Completely unfamiliar to me. The feature request was straightforward: add .env file support (Issue #162). In 2.5 hours, using free AI models and a structured approach, I went from knowing nothing about the codebase to a merged pull request.

The difference wasn't better prompts. It was better process.

The Actual Workflow: What I Did vs What AI Did

Here's the honest breakdown of who did what. I didn't write a single line of code myself. That's not the valuable work anymore.

What I did:

Explored the codebase with AI — Asked questions, challenged its understanding, verified explanations against the actual code
Built the .ai/ structure — Wrote context docs, ADRs, rules, and implementation specs based on my growing understanding
Questioned the strategy — Evaluated alternatives, captured trade-offs, made architectural decisions
Directed the implementation — "Follow the spec. Implement test 1. Now test 2." Each step validated before moving forward
Reviewed iteratively — Asked AI to review the code, digested its findings, confirmed issues, asked it to fix them. Repeated multiple times
Final deep review — Read through the entire PR on GitHub, verified everything made sense, marked ready for review

What AI did:

Answered my questions — Explained architecture, pointed me to relevant files, clarified patterns
Wrote all the code — Tests, implementation, integration, everything
Found its own bugs — Self-review caught 5 issues before I even looked at the code
Fixed the issues — Applied fixes based on its own review findings
Followed the plan — Implemented exactly what the spec described, in the order specified

What we did together:

Built understanding through conversation
Validated each step before proceeding
Caught subtle bugs through TDD
Created production-ready code with high confidence

The key insight: I never typed code. I read it, reviewed it, directed changes to it. But I didn't write it. My value was in understanding, planning, and judgment. AI's value was in execution and self-checking. This is the new division of labor.

The Four Skills

This walkthrough demonstrates four skills that matter more than code generation:

Skill 1: Rapid Onboarding. Learning an unfamiliar codebase fast by building structured context instead of reading every file. The .ai/ folder captures architecture, patterns, and limitations in a way both humans and AI can reference.

Skill 2: Strategic Documentation. Building documentation that guides development, not just records it. Architecture Decision Records (ADRs) capture the "why" behind choices, evaluate alternatives, and create a shared understanding before code is written.

Skill 3: Systematic Planning. Breaking down problems into testable steps. Each test defines expected behavior. Each implementation proves the behavior works. Each commit tells part of the story. No guessing, no hoping.

Skill 4: Confident Execution. Shipping code you trust because you've tested it thoroughly, reviewed it critically, and validated it works in real scenarios. AI can help write code, but you own the quality.

These skills work regardless of the AI tool you use. They work with free models. They work on unfamiliar codebases.

The Feature Request

First, a quick primer on how xc works: it's a task runner that reads tasks directly from your README.md (or any markdown file). Tasks are defined as markdown headings with code blocks. When you run xc test, it finds the ## test heading in your README and executes the code block beneath it. The genius is that your documentation is your task runner, so they never get out of sync.

A user opened Issue #162 asking for .env file support. They wanted to use the same set of tasks for different environments without cluttering the Markdown with environment variables.

Before the feature, you'd have to write this in your README.md:

## deploy

Deploy to production.

Env: DATABASE_URL=postgres://prod/db, API_KEY=secret123, ENV=production

kubectl apply -f deployment.yaml

Then run with xc deploy.

After the feature, your README stays clean:

## deploy

Deploy to production.

kubectl apply -f deployment.yaml

The environment variables live in a separate .env file:

DATABASE_URL=postgres://prod/db
API_KEY=secret123
ENV=production

You still run the same command, but now the credentials are managed in .env instead of cluttering your documentation.

Simple ask, but the implementation requires real decisions. When do you load the files? What about overrides? How do you handle security? What about backward compatibility?

The `.ai/` Structure: Context as Code

Before writing any code, I created a structured context folder. This turned out to be the key to working with AI effectively. It's not about better prompts, it's about better structure.

Full .ai/ folder: github.com/sudoish/xc/tree/ai-context/.ai

The folder looks like this:

.ai/
├── agents.md # Who's working on what
├── context.md # Project overview, architecture
├── architecture/
│ ├── decisions.md # Current design patterns
│ └── adrs/
│ └── 001-dotenv-support.md # Design decisions for this feature
├── rules/
│ ├── code-style.md # Go conventions
│ ├── testing.md # TDD workflow
│ └── commits.md # Commit message format
└── tasks/
    └── 001-dotenv-implementation.md # Step-by-step plan

Important: This structure is an investment, not overhead you repeat for every feature. You build it once during your first feature, then leverage it for every feature after. The context.md, architecture/decisions.md, and rules/ files rarely change. Each new feature just adds a new ADR (like 002-api-caching.md) and a new task spec (like 002-api-caching-implementation.md).

Think of it like setting up your development environment. The initial setup takes time, but every feature after that is faster because the foundation exists.

Each file serves a specific purpose. The context.md file becomes AI's memory. It explains what xc does, how it's architected with its cmd/, models/, run/, and parser/ packages, what key behaviors exist like dependencies and environment handling, and what current limitations we're working around. Every time I ask AI a question, this context gets included automatically.

The rules/testing.md file defines the TDD workflow we follow: write a failing test first (red), write minimal code to make it pass (green), clean up without changing behavior (refactor), then commit. This keeps both me and AI honest. No skipping tests. No shortcuts.

The real gem is adrs/001-dotenv-support.md, the Architecture Decision Record. This is where design happens. It's not "build me a feature," it's "here's why we chose this approach." We decided to load .env files at application startup rather than per-task, to support .env.local overrides, to skip world-readable files for security, and to add CLI flags like --env-file and --no-env. We considered alternatives like per-task loading (rejected as too complex) and requiring an explicit flag (rejected as too much friction). This ADR becomes the source of truth. When AI suggests something different, I can just say "check the ADR."

The living documentation principle: As the codebase evolves, so does the .ai/ folder. When you add a new feature, you write a new ADR (002, 003, etc.). When architecture changes, you update architecture/decisions.md or add a new ADR explaining the change. When patterns emerge, you document them. The folder grows with the project, but the structure stays the same. Each feature builds on the understanding captured before it.

This means the second feature is faster than the first. The third is faster than the second. The documentation compounds.

The Task Spec: Planning Before Coding

Before writing any code, I created tasks/001-dotenv-implementation.md, a step-by-step plan for implementing the feature. This isn't a project management document. It's a development spec that breaks the feature into TDD cycles.

The spec listed each test I needed to write, what behavior it should verify, and the expected implementation. Test for file not found. Test for loading valid env. Test for .env.local overrides. Test for security checks. Each one became a TDD cycle.

This is what makes AI effective. Without the spec, I'd be asking AI "what should I do next?" every five minutes. With the spec, I'm asking "implement the next test according to the plan." The spec keeps development focused and systematic. It's the difference between wandering and following a map.

For your second feature, you write a new spec. For your third, another one. The format is consistent, but each spec is tailored to its feature. This is the work that makes development fast and confident.

The TDD Flow: Red → Green → Refactor → Commit

Here's where the real work happens. Each test defines acceptance criteria for exactly what needs to be built.

Cycle 1: Valid .env should load variables

First behavior: if a .env file exists and contains KEY=value pairs, those should be loaded into the environment. Test written, test failed (red)—no loader existed yet. Implementation added using the godotenv library (green). Test passed. Committed with "load env vars from dotenv file".

Cycle 2: .env.local should override .env

Expected behavior: if both .env and .env.local exist, and both define the same variable, the .env.local value wins. This is crucial for local development where you want to override defaults without modifying the base file. Test written, test failed initially because I was using the wrong function, fixed the implementation, test passed. Committed.

Cycle 3: World-readable files should be skipped

Security requirement: if a .env file has permissions that allow other users to read it (like chmod 644), skip loading it and warn the user. This prevents accidentally exposing secrets. Test created, test failed (secrets were being loaded), added permission check, test passed. Committed.

This rhythm of define → test → implement → verify → commit creates a clean history. When I looked at the final commit log, I could see exactly how the feature evolved: add godotenv dependency, load env vars from dotenv file, support dotenv local overrides, add security check for world readable files, integrate dotenv loading into main, add env file cli flags. Thirteen commits total, each one atomic and meaningful. Each commit is a story about one specific behavior being added.

The Review Process

After the implementation was done, I did a deep review of my own code. I found five issues that needed fixing.

Issue 1: Test Isolation (Critical)

Tests were modifying the global environment without properly restoring it. If a test set TEST_KEY=value, the cleanup would delete it, but what if that key already existed before the test ran? The cleanup wasn't restoring the original value, just removing the key. This breaks parallel test execution because tests can interfere with each other.

The fix: create a helper function that saves the current state of environment variables before the test runs, then restores that exact state (including whether the variable existed at all) when the test completes. Now tests are safe to run in parallel. Committed with "add test environment isolation helper".

Issue 2: Windows Test Bug (Critical)

One test needed to skip execution on Windows because file permission models are different. I had written the check incorrectly, reading from an environment variable instead of the language's built-in constant. This would break Windows CI. Small mistake, but important. Fixed and committed with "fix windows test skip to use runtime goos".

Issue 3: Early Exit Timing

The .env loading was happening even for commands like --help and --version, which meant users could see security warnings when just checking the version. Moved the loading to happen after those early exits. Performance optimization and better user experience. Committed.

Issue 4: Error Context

When file operations failed, errors didn't indicate which file caused the problem. Added context wrapping so errors show the specific file path. Makes debugging much easier. Committed.

Issue 5: Test Coverage

One helper function didn't have its own test. Added coverage to bring the total to 84%. Committed.

Each issue got its own fix, its own verification, its own commit. The same disciplined process for fixes that I used for features.

The Manual Testing

Code works in tests, but does it work for real users? I installed my version and created a test project to verify everything worked end-to-end.

I created a .env file with some variables, created a .env.local file that overrode some of them, and made sure the permissions were correct with chmod 600. Then I added a task to my README.md to verify the variables were loaded:

In README.md:

## check-env

Check loaded environment variables.

echo "Environment: $ENV"
echo "Database: $DATABASE_URL"
echo "API Key: ${API_KEY:0:8}..."

When I ran xc check-env, I saw exactly what I expected. The xc command read the task from the README and executed it with the environment variables from .env and .env.local. The environment was set to "development" from the base .env, but the database URL and API key were overridden by .env.local. Perfect.

I ran eight manual test scenarios: default .env loading, .env.local overrides, the –no-env flag skipping loading, –env-file loading a custom path, security warnings for world-readable files, task-level Env statements still working, –help not loading .env (avoiding unnecessary warnings), and a real-world multi-variable scenario. All eight passed.

The PR

I submitted everything as PR #167. The changes included thirteen commits (eight for the feature, five for fixes), about 200 lines of code including tests, four unit tests plus six integration tests, 84% code coverage, and zero bugs found in manual testing.

The documentation was complete with a README section showing examples, a .env.example template file, the load order documented clearly, and security best practices explained. Most importantly, everything was backward compatible. Existing task-level Env: statements still work exactly as before.

What I Learned

The .ai/ folder was the game-changer. Instead of writing long prompts like "Build me a .env loader with security checks and…", I could just say "Implement the loader per ADR-001". The ADR contains all the decisions. AI just implements them.

I used free models throughout. No expensive API calls. The key wasn't the model, it was the context. Clear architecture docs, explicit ADRs, and well-defined tests gave AI everything it needed to generate good code.

TDD kept everything honest. Every cycle followed the same pattern: write a test that defines the behavior, let AI suggest an implementation, let the test validate it works, then commit. No guessing. No "it probably works." The test proves it.

Thirteen commits might seem like a lot for 200 lines of code, but each commit serves a purpose. Each one is reviewable on its own. Each one tells part of the story. Each one is revertible if needed. Git bisect works perfectly with this kind of history.

The .env.local override issue shows the workflow clearly. AI suggested the wrong approach first, using Load() instead of Overload(). But the test caught it. That's how it should work: AI suggests, test validates, human decides.

The Real Value

This isn't about "AI wrote code for me." It's about process, collaboration, and documentation.

The process matters. Structured context in the .ai/ folder. Design decisions captured in ADRs. TDD discipline with tests written first. Small commits with one change at a time. This is how you ship production code.

The collaboration matters. AI acts as a pair programmer, not a magic wand. Tests validate AI suggestions. Human makes the design decisions. Both contribute to better code.

The documentation matters. Future contributors now have context about the project, the architecture, and why decisions were made the way they were. The implementation plan is explicit. The tests document the expected behavior. Six months from now, none of this is lost.

The compounding matters most. You build the foundation once. Every feature after that leverages it. The second feature doesn't need new context.md or rules/ files, just a new ADR and task spec. The third feature is even faster. The documentation evolves as the codebase evolves. New ADRs when architecture changes. Updates to context.md when understanding deepens. Updates to rules/ when patterns emerge. The investment pays dividends forever.

Try It Yourself

Want to replicate this process? Pick a project and create the .ai/ structure right in your working directory:

mkdir -p .ai/{architecture/adrs,rules,tasks}

Use the template structure as a guide. Build the foundation files once (context.md, architecture/decisions.md, rules/), then for each feature add a new ADR and task spec. The .ai/ folder lives alongside your code and evolves with it—commit it with your changes so it stays in sync.

Direct AI through TDD: "Implement test 1 from the spec." AI writes the test and implementation. "Run it." Test passes. "Commit." Repeat. When done, have AI review its own work, confirm findings, direct fixes. Then do your final review for strategic correctness.

Each feature adds a new ADR and task spec to the .ai/ folder. The foundation files rarely change. The documentation compounds.

The Full Timeline

I spent about 45 minutes on documentation upfront: exploring the codebase with AI, questioning its understanding, writing the ADRs, rules, and context. This sounds like a lot, but it's a one-time investment. The context.md, architecture/decisions.md, and rules/ files I wrote for this first feature will be reused for every future feature. I'll only spend 10-15 minutes on feature-specific docs (ADR + task spec) for the next feature.

The implementation took 40 minutes: directing AI through TDD cycles, one test at a time, validating each step. Integration of CLI flags and wiring into main.go took 15 minutes of the same directed approach. Documentation like README updates and examples took another 15 minutes. Manual testing took 15 minutes: I installed the binary and ran real scenarios. The review process took 30 minutes: first AI reviewed its own code (found 5 issues), then I reviewed the fixes, then I did a final deep review on GitHub.

Important: AI wrote 100% of the code. I wrote 100% of the strategy, asked 100% of the questions, and made 100% of the decisions. I reviewed every line, but I didn't type any of them. Total time from fork to production-ready PR was about 2.5 hours.

If I added a second feature tomorrow, it would take less time. By the third feature even faster. The documentation compounds.

Resources

The complete .ai/ structure and documentation is at github.com/sudoish/xc/tree/ai-context/.ai. The pull request with all code and tests is at github.com/joerdav/xc/pull/167. The working fork is at github.com/sudoish/xc. The original issue is joerdav/xc#162.

Note: The .ai/ folder lives in a separate branch in this example only because I wanted to reference it for this article without including it in the PR to the upstream project. In your own work, keep the .ai/ folder in your main working branch and commit it with your changes—it should evolve alongside your code, not separately.

The Skills That Actually Matter

AI wrote every line of code. I read every line, but I didn't write any of them. The feature is production-ready because I focused on what actually matters.

The four skills transformed from framework to practice: rapid onboarding through questioning AI and building structured context, strategic documentation through ADRs written before code, systematic planning through testable specs, and iterative review through AI self-checks followed by strategic verification.

The .ai/ folder, the ADRs, the task specs, the review cycles—they all worked exactly as planned. The result: 84% coverage, zero bugs, 2.5 hours from fork to production-ready PR.

These skills work with free models. They work on unfamiliar codebases. They separate developers who use AI effectively from those who just generate code and hope it works.

The magic isn't in the AI. It's in the process. And the process is this: you think, you plan, you direct, you review. AI executes.

What This Means for Your Career

The developer who can onboard to unfamiliar codebases fast, document decisions strategically, plan systematically, and execute with confidence is far more valuable than the developer who can write code quickly. Because here's the reality: code writing is no longer the bottleneck, it never was. AI just made this a lot more evident

I shipped a production-ready feature to an unfamiliar codebase in 2.5 hours without writing a single line of code. The bottleneck wasn't typing. It was understanding, planning, and judging. Those are the skills that matter.

AI tools are getting better at code generation every month. They're not getting better at understanding your codebase's architecture, making strategic trade-offs, or ensuring production quality. Those skills are still yours. Those skills are what companies pay for.

The question isn't "Will AI replace developers?" It's "Which developers will thrive when everyone has access to AI?" The answer is the ones who master onboarding, documentation, planning, and review. The ones who understand that their job is no longer to write code—it's to think clearly, plan thoroughly, and judge correctly.

This is the junior dev role being redefined. It's not about writing boilerplate anymore. That work is done. It's about learning systems fast, making good decisions, directing execution, and ensuring quality. If you can do that, you're not competing with AI. You're orchestrating it.

Writing code is optional. Reading it, understanding it, and judging it—those aren't.

This post documents a real open source contribution made using AI as a pair programmer. All code, tests, documentation, and the complete .ai/ folder structure are publicly available in the sudoish/xc fork for anyone who wants to replicate this approach.

The post You Think, AI Executes: The Skills That Actually Matter appeared first on sudoish.

How We Made It Nearly Impossible to Become a Developer

Thiago Pacheco — Sun, 29 Mar 2026 16:47:08 +0000

I once interviewed a senior software engineer. Almost 10 years of experience. Proven track record of delivery. Solid industry knowledge. The kind of person you’d want on your team without a second thought.

They completed the technical challenge. Not flawlessly — there were considerations, trade-offs they made that weren’t all correct. But when we reviewed their decisions together, the reasoning was sound. They showed commitment to their choices and could articulate why they went the direction they did. Some answers were vague in spots, some mistakes were real, but nothing that wouldn’t get corrected in the first week on the job with actual codebase context. The kind of gaps that disappear when you’re working on real problems instead of performing in a vacuum.

We didn’t hire them.

Not because I didn’t want to. I did. But the compounded small mistakes added up under the scoring rubric, and the final grade wasn’t strong enough to sell to the hiring managers. The rules of the process made a good engineer look like a bad candidate.

And I get it — those rules exist to keep the bar high, to ensure we only hire top talent. At least, that’s what every company believes. But what I’ve seen throughout my career, on both sides of the table, is that the process doesn’t filter for the best engineers. It filters for the best interviewers. And we lose great colleagues — dedicated, talented people — because they didn’t fit the rule book.

That was a senior engineer with a decade of experience. Now imagine you’re a junior with none.

The software industry has a hiring problem. Not the kind where we can’t find people — the kind where we’ve made it nearly impossible for new people to get in.

Entry-level developer hiring has collapsed — some reports show drops of 60% or more in the past year, with actual hires into junior roles falling as much as 73%. CS graduates are sitting at 6.1% unemployment according to the Federal Reserve Bank of New York — more than double the overall national rate. And the majority of tech leaders say they plan to reduce entry-level hiring even further while increasing AI investment.

But the pipeline didn’t break overnight. It’s been cracking for years. AI just kicked the door in.

The Interview Problem Nobody Wants to Fix

The interview process was broken long before AI showed up. And I’ll say what a lot of people in the industry think but won’t say out loud: the standard software engineering interview process is unrealistic, unnecessarily demanding, and a terrible predictor of on-the-job performance.

Think about what we ask candidates to do. Solve algorithmic puzzles on a whiteboard or shared screen. Explain their thought process in real time while simultaneously figuring out the solution. Design systems on the spot for problems they’ve never encountered in that specific framing. All while someone watches and judges every hesitation.

Here’s the thing — that’s not how software development works. Not even close.

Real engineering is focused, deep work. It’s sitting alone with a problem for hours, researching approaches, trying things, breaking things, iterating. It’s the exact opposite of performing under observation with a timer running. Most developers do their best work when they’re left alone to think. Asking them to showcase and explain how they’d deliver features while they’re still processing the problem doesn’t test their engineering ability. It tests their ability to perform under artificial pressure.

And yet, this is how we gatekeep an entire profession.

When Even a Principal Engineer Can’t Pass

I have a close friend who’s a principal engineer. He’s delivered massive projects — systems that required intense complexity, heavy reliability, and serious scalability. The kind of work that keeps companies running. I’ve watched him turn down offers from companies that couldn’t skip the whiteboard stage. His track record speaks for itself, but he knows the process doesn’t.

He straight up refuses to do technical interviews. Hates the process. Never performed well in them.

But that wasn’t always the case. Early in his career, he had no choice. He went through the motions, sat through the whiteboard sessions, stumbled through the live coding exercises. And that’s exactly how he learned he was terrible at it. Not terrible at engineering — terrible at the performance.

If a principal engineer with years of proven delivery struggles with this process, what does that tell us? It tells us we’re measuring the wrong thing.

Culture fit, communication, problem-solving mindset, willingness to learn — these should carry far more weight than whether someone can implement a binary tree traversal from memory while a stranger watches. But the industry has standardized around LeetCode-style assessments like they’re some universal truth, and we’ve collectively decided that this is just how it works.

It’s not. It’s a choice. And it’s a bad one.

The Wrong Skills at the Worst Time

Here’s where it gets really damaging for juniors specifically.

When you’re just starting your career, you have limited time, limited money, and unlimited pressure. The message the industry sends you is clear: grind LeetCode. Master data structures and algorithms. Practice system design for systems you’ve never built. Get good at performing.

So that’s what people do. They spend months — sometimes six months or more — focused entirely on interview preparation instead of actually building things, learning real-world patterns, or developing the engineering intuition that makes someone genuinely valuable.

We’re literally telling the next generation of developers to optimize for the wrong skills from day one. And then we wonder why new hires can’t navigate a real codebase.

The industry has created a perverse incentive: becoming good at getting hired and becoming good at the job are two completely different skill paths. And for juniors who are just figuring out what software engineering even is, being forced down the interview prep path first is actively harmful to their development.

Now Add AI to the Mix

As if the interview gauntlet wasn’t enough, the industry just added a new requirement: you need to be proficient with AI tools.

On the surface, this makes sense. AI-assisted development is becoming standard practice. Companies want developers who can leverage these tools effectively. Fair enough.

But think about what we’re actually asking.

Yes, some AI coding tools have free tiers now. GitHub Copilot has one. Cursor has a free plan. But if you’re just starting out — fresh from school, finishing a bootcamp, or self-teaching — do you even know that? The AI tooling landscape is an overwhelming mess of options, hype, and conflicting advice. Experienced developers struggle to keep up with what’s worth using. How is someone who’s still learning what a REST API is supposed to navigate that?

And the free tiers only get you so far. The tools that companies actually expect proficiency in — Copilot Pro, Cursor Pro, Claude Pro — cost $10 to $20 per month each. If you want a serious AI-assisted workflow, you’re looking at $30-50/month minimum. That might not sound like much to someone employed, but when you’re unemployed, every dollar matters. Asking someone without income to pay for premium AI tools so they can develop the skills needed to get a job is a catch-22.

There are too many unknowns when you’re starting out. Every conversation about AI in development assumes a baseline of knowledge and context that juniors simply don’t have yet. And instead of helping them build that foundation, we’re adding it to the list of things they need to figure out on their own before we’ll even consider hiring them.

The Senior Shortage Nobody Sees Coming

Here’s the part that should terrify every tech leader who’s currently celebrating their AI-powered lean engineering team: you’re eating your seed corn.

It takes roughly 7 to 10 years to develop a senior engineer. Not just someone with “senior” in their title — someone who can architect systems, mentor teams, make judgment calls under uncertainty, and understand the business context of technical decisions. That kind of expertise doesn’t come from tutorials or AI tools. It comes from years of making mistakes, shipping real products, debugging production incidents at 2 AM, and slowly building the intuition that separates an engineer from someone who writes code.

If we’re not hiring juniors now, we won’t have mid-level engineers in 3-5 years. And we won’t have seniors in 7-10 years.

The Stanford Digital Economy Lab data already shows it: employment for software developers aged 22-25 has dropped roughly 20% since late 2022, while developers over 26 remain stable. The two groups tracked perfectly until ChatGPT launched, then diverged sharply. We’re watching the pipeline dry up in real time.

And here’s the irony that makes it worse: companies are cutting juniors because they believe AI replaces what juniors did. But the data tells a different story. Google’s DORA 2024 report found that a 25% increase in AI adoption translated to just a 2% productivity gain — while executives at those same companies were telling their boards that AI had boosted output by 25%. The gap between measured reality and executive perception is staggering, and companies are making structural hiring decisions based on that perception, not the data.

Juniors were never just “cheap labor” who wrote boilerplate. They stress-tested documentation. They exposed hidden assumptions in systems. They forced seniors to articulate knowledge that would otherwise stay implicit. They built institutional memory.

A senior with Copilot can write code faster, sure — but faster code was never the bottleneck.

The Squeeze

So let’s put it all together. If you’re a junior developer in 2026, here’s your reality:

There are barely any jobs for you. Entry-level hiring has collapsed. Companies want seniors only.
The jobs that exist demand more than ever. The few junior roles left aren’t really junior anymore — they want 2-3 years of experience, AI proficiency, and system design knowledge.
The interview process is designed against you. Months of LeetCode prep that teaches you nothing about real engineering.
You need tools you might not know exist or can’t afford. AI proficiency is expected, but the landscape is overwhelming and the good stuff costs money you don’t have.
The anxiety is crushing. The pressure to be the best, to stand out in a market with fewer openings and more candidates, is driving people out before they even start.

And the result? People are giving up. Not because they can’t code. Not because they’re not smart enough. Because the path from “I want to be a software developer” to actually being one has become so hostile, so expensive, and so demoralizing that it’s not worth it anymore.

Can you blame them?

What Actually Needs to Change

I don’t have a clean five-point solution. Anyone who does is selling something. But I know what direction we should be moving.

Rethink interviews from the ground up. Pair programming sessions, take-home projects with reasonable time limits, portfolio reviews, trial periods — there are better ways to assess ability than making people perform algorithms under pressure. If your interview process can’t distinguish between a great engineer who interviews poorly and a mediocre one who interviews well, the process is broken. Not the candidate.

Invest in juniors as a strategic decision, not charity. The companies that hire and develop juniors now will have the experienced engineers everyone else is desperate for in 2030. A handful of companies are already doubling down on junior hiring. They’re not being generous — they’re playing the long game while everyone else optimizes for this quarter.

Stop pretending AI replaced the junior role. It replaced the boilerplate. The questions juniors ask, the assumptions they challenge, the documentation they stress-test — that’s not automatable. If your team stopped growing because you thought Copilot could replace a curious 23-year-old, you’re going to feel that decision in five years.

The Real Question

The software industry has spent the last two decades complaining about a talent shortage. And now, faced with the largest pool of motivated CS graduates and career switchers in history, we’ve decided the best strategy is to lock the door and let AI handle it.

If senior engineers can’t pass technical interviews, if junior roles demand senior skills, if the tools you need are buried in a landscape designed for people who already know what they’re doing, and if the entire process optimizes for performance over competence — then the pipeline isn’t just broken. We broke it. Deliberately, through a thousand small decisions that each seemed reasonable in isolation but collectively created a system that’s eating its own future.

The question isn’t whether this will catch up with us. It’s whether we’ll have anyone left in the pipeline to fix it when it does.

The post How We Made It Nearly Impossible to Become a Developer appeared first on sudoish.

The AI Productivity Lie Nobody Wants to Admit

Thiago Pacheco — Sat, 28 Mar 2026 12:37:32 +0000

I’ve been producing bad code. And it’s not because I forgot how to code.

I’ve tried every workflow. Terminal agents, IDE copilots, full vibe coding, augmented coding. I keep exploring because that’s what I do — evaluate, keep what works, move on from what doesn’t.

But here’s where I am right now: most of the time, it’s still more reliable for me to write the code myself than to let the agent do it.

When the AI writes it, yes — it’s faster sometimes. But then I review it. I find things. I correct things. And suddenly I’m in a loop where I’m either spending more time than if I just did it myself, or the same time doing a more tedious version of the work. I’m not writing code anymore. I’m auditing code I didn’t write and don’t fully trust.

And I’m starting to wonder what that’s doing to my engineering skills. Not because AI replaced them. Because the constant pressure to delegate everything is pulling me away from the deep thinking that built those skills in the first place.

The Pressure Nobody Talks About

The expectation to be dramatically more productive with AI is real. It’s coming from management, from Twitter, from inside your own head. Every demo makes it look like everyone else figured it out and you’re falling behind.

And yeah — AI can be a huge boost. But only if you have perfect project structure, perfect product context, perfect documentation.

That doesn’t exist. Not in any real codebase I’ve ever worked on.

You know what exists? Legacy code. Tech debt. Patterns that were “temporary” three years ago. Business logic that lives in someone’s head and nowhere else.

When you point an AI agent at that, it doesn’t fix the problems. It copies them. It amplifies them. It confidently reproduces your worst patterns at scale.

So now you’re not just dealing with tech debt. You’re dealing with AI-generated tech debt that looks clean because the agent formatted it nicely.

The Data That Should Make You Uncomfortable

Here’s what made me feel less crazy about all of this. And each study hits harder than the last.

You’re Not Even Faster

METR, a nonprofit research organization, ran what might be the most rigorous study on this topic to date. They took 16 experienced open-source developers — people who maintain large repositories, averaging 22,000+ stars and over a million lines of code — and had them work on real issues in their own codebases. Real bugs, real features, real refactors. Not toy problems.

Half the time they could use AI. Half the time they couldn’t.

The result? When developers used AI tools, they took 19% longer to complete their tasks.

Not faster. Slower.

But here’s the part that should genuinely unsettle you: before the study, these developers predicted AI would make them 24% faster. After using it — after actually experiencing the slowdown — they still believed AI had made them 20% faster.

19% slower. Felt 20% faster. A 40 percentage point gap between perception and reality.

This is what I call the speed mirage. You feel like you’re flying. The data says you’re walking backwards. And you can’t even tell.

You Understand Less of What You Ship

Anthropic, the company that makes Claude, ran a randomized controlled trial on their own tool. Developers using AI assistance scored 17% lower on comprehension tests compared to developers who coded manually. The AI group finished slightly faster, but that speed difference wasn’t even statistically significant.

Marginal speed gain. Real understanding loss.

It gets worse. The developers who delegated code generation to AI scored below 40% on comprehension. The ones who used AI for conceptual questions — asking “why” and “how does this work” — scored above 65%.

Same tool. Completely different outcomes depending on how you used it. And the biggest gap was in debugging — the skill you need most when things break in production.

The Industry Already Knows

Stack Overflow’s 2025 Developer Survey: 84% of developers use or plan to use AI tools, but only 33% trust the output. Down from 43% the year before.

Adoption up. Trust down.

So we’re not faster. We understand less. And we don’t even trust what we ship. But we keep using it because everyone else seems to have figured it out.

Throughput vs. Confidence

Let me name the thing clearly.

The industry is optimizing for throughput when it should be optimizing for confidence.

Throughput is lines of code generated. PRs opened. Features “shipped.” It’s the metric that looks good on a dashboard and falls apart in production.

Confidence is different. Do I understand what this code does? Do I trust it handles the edge cases? Can I debug it at 2 AM when something breaks?

Vibe coding optimizes for throughput. You get a dopamine spike. You feel productive. And then you spend the rest of the day cleaning up after the machine.

I’m not anti-AI. I use it every day. It’s incredible for researching tradeoffs, validating ideas, catching things I missed in review. When I use AI as a thinking partner, it genuinely makes me better.

But when I use it as a coding replacement, it makes my output worse. And that’s the gap the industry isn’t willing to talk about.

The Confidence Boundary

So where does this leave us?

I don’t have the perfect workflow. I’m not going to pretend I do. But I’ve been paying attention to what actually works, and the pattern is consistent.

The developers getting the best results from AI aren’t the ones who figured out the perfect prompt. They’re the ones who figured out what to delegate and what to keep.

I’ve been calling this the confidence boundary.

Here’s a real example. I had a feature to build recently. Instead of just opening the terminal and prompting the agent to do it, I stopped. I wrote the spec first. A clear, detailed explanation of what needed to be accomplished. The edge cases that the implementation had to survive. The constraints. The things I explicitly didn’t want.

Then I handed that to the agent and let it implement against my spec.

Because I did the thinking upfront, reviewing the output took minutes instead of hours. I knew exactly what should be there and what shouldn’t.

But here’s the thing nobody tells you — and this is where it gets uncomfortable.

To get a good result from the agent, you have to be very specific. You’re writing a detailed spec, thinking through edge cases, defining constraints. And at some point you realize: for certain features, you’ve already done most of the hard work. The thinking is the work.

At that point, it’s genuinely faster to just write the code yourself and use the agent as a pair reviewer to make sure you’re on the right track.

Other times — boilerplate, scaffolding, repetitive patterns, implementations where the spec is clear and the risk is low — full delegation is absolutely the move. Hand the agent the guidance and let it run.

The real skill isn’t prompting. It’s learning what to delegate and what to keep. And that judgment comes from understanding your codebase, the complexity of the task, and honestly — how much you trust the output for that specific context.

The messier your codebase — legacy code, real tech debt, patterns with history the agent will never know — the more that judgment matters. The tooling is irrelevant. Neovim, Cursor, whatever. The bottleneck is you. Whether you know where your confidence boundary is and whether you’re honest about it.

The Bet I’m Making

If you feel like AI is making you more productive but less confident in what you ship — you’re not falling behind. You’re paying attention.

If your engineering skills feel soft because you keep delegating instead of thinking — that’s not paranoia. The research says it’s real.

The speed mirage is powerful. It feels like progress. The dashboards say it’s progress. But if you can’t explain what you shipped, debug it when it breaks, or trust it handles the edge cases — that’s not progress. That’s debt with a nice commit message.

I’m not quitting AI. I’m quitting the lie that it makes everything faster.

The developers who are going to thrive aren’t the ones who ship more code. They’re the ones who learned what to keep and what to let go. Who built the judgment for when to delegate and when to do the work themselves.

Confidence over throughput. That’s the bet I’m making.

Sources

The post The AI Productivity Lie Nobody Wants to Admit appeared first on sudoish.

A Tale of Accidental Architecture: How 50 Lines Became A Black Friday Disaster

Thiago Pacheco — Fri, 27 Feb 2026 04:26:03 +0000

Let me tell you about Sarah.

This is a fictional story. But I bet you’ll recognize it.

I’ve seen this pattern play out across different companies, different teams, different tech stacks. The details change. The progression doesn’t.

Week 1: The Perfect Start

Sarah’s building a notification system for an e-commerce platform.

First requirement: send an email when someone places an order.

Simple. She writes one function. Webhook comes in, format the email, hit SMTP, done.

The whole thing is maybe 50 lines. It works perfectly. Code review approves it. It ships.

Sarah’s thinking: “It’s just one notification type. I’ll add proper abstraction when we actually need it.”

You’ve thought this too. So have I.

Nothing wrong with it. Week 1, this is the right call.

Week 3: The First Copy-Paste

Product team loves the email notifications. Now they want SMS for order shipments.

Mike picks up the ticket.

He opens Sarah’s code. Sees the pattern. Makes sense. He follows it.

New handler. Receives the shipment webhook. Formats the SMS message. Connects to Twilio. Sends it.

He copies some of Sarah’s email formatting logic because customers should see consistent information. Has to adjust it for the 160-character SMS limit, but the core logic is the same.

Mike’s thinking: “There’s some duplication with the email code, but SMS is different enough that abstracting it would be premature. It’s only two notification types.”

Deadline is tomorrow. This ships.

Still nothing catastrophically wrong here. Two types, small duplication, it’s manageable.

Right?

Week 5: User Preferences

Customers start complaining.

“I don’t want SMS notifications.”

“Why am I getting emails for every status change?”

Sarah adds user preferences. Creates a database table. Updates her email handler to check if the user wants that particular notification before sending.

The handler triples in size.

Query the database. Check multiple preference flags. Handle the case where preferences don’t exist yet. Default values. Edge cases.

Sarah’s thinking: “This is getting messy, but the deadline is tomorrow and this works. I’ll refactor it next sprint.”

I cannot tell you how many times I’ve heard “next sprint.”

(Spoiler: next sprint never comes.)

Week 7: Two Ways to Do Everything

Mike needs to add notifications for order cancellations and delivery confirmations.

He realizes hardcoding email bodies isn’t going to scale.

So he builds a template system. Creates a templates directory. Writes a simple renderer. Updates his handlers to load templates, populate data, send.

It’s actually pretty clean.

Meanwhile, Sarah’s handlers still use string formatting. She doesn’t know Mike built a template system. Mike didn’t announce it in Slack. It just… exists now.

The codebase now has two different ways of generating notification content.

Sarah finds out later. Thinks: “I should probably switch to Mike’s templates… but my code is working and I’m slammed with other features.”

And she is. Three new features this sprint. No time to refactor working code.

Week 9: The Third Approach

Emma joins the team.

First task: add Slack notifications for the support team when high-value orders come in.

She opens the notification code. Finds Sarah’s inline approach. Finds Mike’s templates. Neither makes sense for Slack.

Slack needs structured JSON payloads, not formatted text.

So Emma does what any good engineer would do: she creates a “proper solution”.

Notification service class. Methods for each notification type. Handles destination-specific formatting internally. Clean. Testable. Well-designed.

She shows it to the team in standup.

Mike: “That’s nice, but I don’t have time to refactor my SMS code right now. Maybe later.”

Sarah: “I like it, but my code has been running in production for months. If it ain’t broke…”

Emma’s service class gets used for Slack notifications. Nothing else changes.

Now there are three ways to send notifications.

Week 12: The Chaos Compounds

Product wants:

Push notifications for the mobile app
Digest emails (daily order summaries)
Ability to snooze notifications

Three developers. Three features. Same week.

Each one discovers the existing fragmentation. Each one makes their own call.

Developer A tries to extend Sarah’s inline approach. Adds push notification logic directly in the handler.

Developer B uses Mike’s templates but creates a new template format because the existing one doesn’t support digest layouts.

Developer C tries to use Emma’s service class but realizes it doesn’t handle scheduling or snoozing. So they add that logic directly in their handler instead.

The notification preferences table is now being updated by five different code paths.

Each developer added their own columns because they didn’t realize others had added similar fields. One stores preferences as JSON. Another uses boolean columns. Another created a separate preferences table with foreign keys.

I’ve seen this code review happen. Every PR gets approved. Every piece of code works.

Nobody did anything wrong.

And yet.

“Every PR got approved. Every piece of code worked. Nobody did anything wrong. And yet.”

Week 15: Customer Complaints

Support tickets start flooding in.

“I’m getting duplicate notifications.”

“I disabled email but I’m still getting them.”

“I’m not getting notifications at all for important orders.”

Sarah investigates. Opens the codebase.

Six different code paths handle notifications. Some check preferences before sending. Some check during sending. Some don’t check at all because the developer assumed another layer was handling it.

She finds the bug. It’s in her original email handler. The preference check is wrong.

She fixes it. Deploys.

Three other notification types break. They were relying on her buggy behavior.

The team estimate to fix it properly: “We need to stop and refactor everything first, or we’ll just make it worse.”

Management: “We don’t have time for a refactor. Just fix the bugs.”

Week 17: The Template Nightmare

Marketing wants to update email designs. New brand guidelines.

The developer assigned to this opens the codebase.

Templates are everywhere.

Some in a /templates directory. Some hardcoded as strings. Some in the database. Some fetched from an external CMS that one developer integrated without telling anyone.

There’s no single source of truth.

Worse: the data passed to templates is completely inconsistent.

Email templates expect order objects with certain fields. SMS templates expect a flattened structure. Push notifications expect a completely different format.

One design change requires touching dozens of files.

The developer estimates: “Two weeks, maybe three.”

Marketing: “It’s just a design update. How is that two weeks?”

Week 20: Performance Crisis

Black Friday.

The system crashes.

Investigation reveals: notification handlers are opening new database connections for every single notification sent.

Some handlers properly close connections. Some don’t.

Connection pools exhausted. Some handlers retry failed sends immediately and indefinitely, amplifying the problem during the outage. One handler spawns a goroutine for each notification but never limits concurrency.

The server runs out of memory processing a batch of 10,000 order confirmations.

Different developers made different assumptions about error handling.

Some silently swallow errors and log them. Some retry with exponential backoff. Some fail fast. Some store failed notifications in one database table for retry. Others use a different table. One developer integrated a third-party queue system that nobody else knew existed.

Notifications are getting lost between these systems.

I’ve been on calls where the CTO asks: “How many notification systems do we have?”

Nobody can answer.

Week 24: The Audit

Compliance team asks a simple question:

“Can you show us a record of all notifications sent to customer X in the past 90 days?”

The team cannot answer this.

Notification logs are scattered everywhere.

Some handlers log to stdout. Some to files. Some to a database table. Some don’t log at all.

The log formats are completely different. Some include the full message content. Some just log “notification sent” without details. There’s no correlation between the notification and the triggering event.

The auditor asks: “How do you ensure notifications contain required legal disclosures?”

Each template was created independently. Some include required legal text. Some don’t. There’s no centralized enforcement.

I’ve seen this audit happen. Teams spend weeks reconstructing logs manually.

The Breaking Point

VP of Engineering asks for a simple feature:

“Add an unsubscribe link to all emails.”

The team estimates: Three weeks.

The VP is shocked.

“It’s just adding a link. How is that three weeks of work?”

The tech lead explains:

“We have seven different code paths that send emails. Each uses a different templating system. Some render templates on the server. Some fetch them from external systems. Some are hardcoded strings. We need to update each one individually, ensure the unsubscribe logic is consistent across all of them, add tracking for unsubscribe events, update the preferences system to handle unsubscribes properly, and test everything thoroughly because there’s no centralized testing strategy.”

Three weeks. For a link.

The VP asks the obvious question: “How did it get this bad?”

What Went Wrong?

Here’s the thing that kills me about this story.

Nobody made a catastrophically bad decision.

Sarah’s Week 1 implementation was appropriate. Mike’s template system was a reasonable improvement. Emma’s service class was a genuine attempt to bring order.

Every single developer was trying to do good work under deadline pressure.

The problem wasn’t the individual decisions.

It was the absence of a shared architectural vision.

Without clear boundaries and layers, each developer made reasonable local optimizations that created global chaos.

The “I’ll refactor it later” moments never came because there was never a good time to stop feature development.

The “let’s standardize this” conversations happened but never resulted in action because no one had time to migrate existing code.

The codebase evolved organically.

And organic growth without structure doesn’t produce a garden. It produces a weed-infested lot.

“But This Is Just a Communication Problem”

You might be thinking: the real issue was that developers didn’t communicate.

If Sarah and Mike had talked, they wouldn’t have built two different templating systems. If Emma had socialized her service class better, others would have adopted it.

Better standups. Better code reviews. Better documentation. That’s what was missing, not architecture.

This is seductive because it’s partially true.

But here’s why it misses the point: architecture IS communication.

“Architecture IS communication. It’s the most important form of communication for technical decisions.”

It’s the most important form of communication for technical decisions.

Think about what actually happened in the story.

The team DID communicate. Mike showed his template system in code review. Emma presented her service class and got positive feedback. They had a meeting in Week 11 trying to align on standards.

The communication happened.

What didn’t happen was turning those conversations into durable, enforceable decisions.

This is the key difference:

Conversation says “we should probably do X.”

Architecture says “X is how we do things here, and here’s where it lives.”

“Conversation is ephemeral. Architecture is the artifact that persists after the meeting ends.”

When a new developer joins and asks “where should notification logic go?”, the answer shouldn’t require scheduling a meeting or hunting through Slack history.

It should be obvious from looking at the codebase.

Communication without architecture leads to the problem Emma faced. She built something good. People agreed it was good. And then… nothing changed.

Without architectural decisions being explicitly made (“from now on, all notifications go through NotificationService”), the good idea just becomes another option in an increasingly fragmented codebase.

Good communication can prevent chaos. But it can’t survive bad processes.

When developers are under deadline pressure, working on different features, joining the team at different times, communication will have gaps.

Architecture is the safety net for when communication fails.

It’s the shared context that makes it possible to work somewhat independently without creating complete divergence.

So yes, the team in our story could have communicated better.

But the solution isn’t “communicate more.”

It’s “communicate the architecture and make it stick.”

Document where things belong. Make architectural decisions explicit. Enforce them in code review. Build structure that persists beyond any individual conversation.

Because at the end of the day, you can have all the Slack channels and standups and retros you want.

Without a shared architectural foundation, you’re just having the same conversations over and over while the codebase continues to fragment.

What Should Have Happened in Week 1

Sarah should have spent 30 minutes writing this:

# Notification System Architecture

## Where Things Live
- All notification logic → services/notification_service.py
- Templates → templates/ directory (Jinja2 format)
- Preference checks → services/preference_service.py
- Delivery logging → notification_log table

## How to Add a New Notification Type
1. Add template to templates/
2. Add method to NotificationService
3. Log delivery attempt (success or failure)
4. Add tests to test_notification_service.py

## Error Handling
- Retries: 3 attempts with exponential backoff (1s, 2s, 4s)
- Failed sends → dead_letter_queue table
- All errors logged with correlation ID

## Preferences
- Check preferences BEFORE sending (not during)
- Default: all notifications enabled
- Unsubscribe → set all preferences to false

That’s it. 30 minutes of work. Would have saved months of chaos.

When Mike added SMS in Week 3, he would have known where to put it. When Emma added Slack in Week 9, she would have followed the existing pattern. When three developers worked simultaneously in Week 12, they would have made consistent decisions.

Not because they communicated better. Because the architecture communicated for them.

The Pattern You’ve Seen Before

I’ve seen this exact pattern play out at least a dozen times.

Different companies. Different tech stacks. Different teams. Different features.

The pattern is always the same.

Week 1: Clean, working code.

Week 3: Small duplication appears.

Week 7: Multiple approaches emerge.

Week 12: Chaos compounds.

Month 6: Simple changes take weeks.

The timeline varies. Sometimes it happens faster (AI accelerates it). Sometimes slower (disciplined team delays it). But without architecture, the destination is always the same.

Then AI Showed Up and Made Everything 10x Worse

Everything I just described? It’s been happening for decades.

Slow burn. Predictable. Manageable if you catch it early.

Then 2024 happened.

AI coding assistants arrived. And they turned architectural decay from a slow burn into a wildfire.

AI Replicates. It Doesn’t Invent.

Here’s what changed.

When Mike needed to add SMS in Week 3, he opened Sarah’s code. Looked at it. Made a decision. Maybe he copied the pattern. Maybe he tried something different.

But he thought about it.

Now imagine Mike has Cursor. Or Copilot. Or Claude Code.

He types: // Add SMS notification for shipments

The AI looks at the codebase. Sees Sarah’s pattern. Instantly replicates it.

Code appears. Mike reviews it. Looks good. Ships.

He never even saw the architectural decision being made.

The AI made it for him. Based on what already existed.

“AI doesn’t just copy your code. It copies your architecture. Even the accidental parts.”

The Speed and Scale Just Exploded

Remember Week 12? Three developers, three features, three different approaches emerging over a week?

With AI, that’s Tuesday.

Developer A asks AI for push notifications. AI sees Sarah’s inline handler. Copies it.

Developer B asks AI for digest emails. AI sees Mike’s templates. Copies those.

Developer C asks AI for snoozing. AI sees Emma’s service class. Copies that.

All three features ship the same day.

But it’s not just faster. It’s bigger.

Pre-AI: 50-200 lines of code per day.

With AI: 500-2000 lines in the same time.

That’s 5-10x more code implementing patterns, creating variations, spreading duplication.

You have two ways of checking preferences? AI propagates both. Three error handling approaches? AI replicates all three. Every inconsistency becomes a seed that AI plants everywhere.

The notification system that took Sarah’s team 20 weeks to become unmaintainable?

With AI, you can get there in 4.

AI Can’t See What You Didn’t Write Down

Here’s the fundamental problem.

AI is incredible at implementation. It can write clean, working code. It follows patterns. It handles edge cases.

But it cannot architect.

It can’t look at your codebase and think: “Wait, this is getting fragmented. We should consolidate these patterns.”

It can’t say: “I see three different approaches here. Which one should I follow?”

It just… picks one. Based on similarity to what you’re asking for.

If your architecture is accidental, AI accelerates the accident.

The Old Advice Is Now Dangerous

The advice used to be: “Don’t over-architect small projects. Start simple. Refactor when you need to.”

That advice just became dangerous.

With AI, “small projects” don’t stay small. They explode.

By the time you realize you need to refactor, you have 10x more code to untangle.

The window between “clean start” and “architectural debt crisis” collapsed.

Week 1 decisions matter more than ever.

You can’t afford to defer architecture anymore.

But Here’s the Good News

The same force that amplifies chaos can amplify order.

AI replicates good patterns just as enthusiastically as bad ones.

If you write that architecture document in Week 1. If you establish clear boundaries. If you make the “right way” obvious.

AI will follow it.

Consistently. Every single time. Across every feature.

It will use your NotificationService. It will follow your template structure. It will implement your error handling exactly as specified.

At scale. At speed. Without deviation.

The chaos multiplier becomes a consistency multiplier.

But only if you give it something consistent to multiply.

“AI doesn’t make architecture optional. It makes it mandatory.”

This is why the next post matters even more now.

I’ll show you how to set up that architectural foundation before you start generating code with AI.

How to make the right patterns so obvious that AI can’t help but follow them.

How to turn AI from an architectural time bomb into an architectural enforcement mechanism.

What’s Next

In the next post, I’ll show you how to build that architectural foundation.

Not some enterprise framework. Not over-engineered complexity.

The simple, practical structure that prevents this chaos.

We’ll rebuild this exact notification system with clear boundaries, testable code, and patterns that guide developers toward consistency instead of fragmentation.

You’ll see:

Where things live (and why)
How to test without infrastructure
How to make architectural decisions stick
How AI helps instead of amplifying chaos

Until then, look at your codebase.

What week are you on?

Have you lived through this story? I’d love to hear about it. Find me on Twitter or LinkedIn.

The post A Tale of Accidental Architecture: How 50 Lines Became A Black Friday Disaster appeared first on sudoish.

Nobody Knows How to Estimate Software Anymore (And It’s Not Your Fault)

Thiago Pacheco — Sun, 15 Feb 2026 16:12:00 +0000

Here’s a pattern I keep seeing (and living):

A feature that would have taken 2-3 weeks gets estimated at “2 days with AI.”

It ships in 4. Sometimes 5.

Not because the AI was slow. Because there are three other “2-day AI projects” running simultaneously. Each one spiraling into bugs, edge cases, and integration issues nobody saw coming. Context-switching between half-finished features, fighting fires, somehow falling behind on all of them.

The AI writes code faster than any human could.

But we’re not shipping faster. We’re drowning.

And here’s the uncomfortable part: we’re doing this to ourselves.

The Promise vs The Reality

You’ve seen the headlines. AI coding tools boost productivity by 39%. Developers are shipping faster than ever. The future is here.

What they don’t tell you is what happens next.

Your manager sees those numbers too. And if AI makes you 39% more productive, why can’t you handle 60% more work? Why are estimates still slipping? Why are bugs still happening?

The math doesn’t add up. And you’re stuck in the middle trying to explain why “AI writes the code” doesn’t mean “features appear instantly.”

Here’s what the data actually shows:

A UC Berkeley study found that AI doesn’t reduce work, it intensifies it. One developer they interviewed said it perfectly: “You thought maybe you’d work less with AI. But you don’t work less. You just work the same amount or even more.”

TechCrunch reported last week: teams adopting AI workflows saw expectations triple, stress triple, but actual productivity only go up by maybe 10%.

And here’s the kicker: a METR study found developers expected AI to speed them up by 24%. In reality? It slowed them down. But they still believed it made them 20% faster.

The gap between perception and reality is dangerous. And most of us are living in it.

The High Expectations Problem

This isn’t just coming from management.

Yes, leadership hears “AI can write massive amounts of code” and expects you to prompt your way through multiple features in no time. First try, maybe second. They don’t understand how AI actually works.

But here’s the honest truth: we don’t either.

I thought I did. I thought “AI writes the code, I review it, we ship it” was the workflow. But that’s not what happens.

What happens is: AI writes the code. I start reviewing it. I find issues. I ask the AI to fix them. It creates new issues. I start another feature while waiting. That one has issues too. Now I’m juggling three half-finished features, each with its own set of AI-generated bugs I’m trying to understand and fix.

The promise was velocity. The reality is fragmentation.

And I keep saying yes to more because “it’s just AI, how hard can it be?” But the cognitive load of reviewing, validating, debugging, and integrating AI code across multiple parallel tracks is crushing.

Every feature looks 80% done. None of them actually ship.

The Estimation Trap

Here’s the confession I don’t want to make: I have no idea how to estimate tasks anymore.

Developers have always struggled with estimation. We underestimate until we get burned enough times to realize “add a simple feature” is never simple when there’s an existing codebase involved.

But AI broke our calibration completely.

A task that used to take 3 days now takes… 2 hours? 4 days? Both? Neither? It depends on:

How well I can describe what I want
How many edge cases the AI misses
How much integration complexity exists
Whether the AI understands the existing patterns
How many iterations it takes to get it right

So now I swing between two extremes:

Under-estimating because “AI will handle it” — then spending 3 days debugging what the AI generated in 20 minutes.

Over-estimating because “who knows what AI will break” — then looking slow when it actually works the first time.

The old rules don’t apply. New ones haven’t emerged. And this isn’t just an academic problem:

Sprint planning becomes guesswork. Roadmaps turn into fiction. Technical debt compounds faster than we can track it. Trust erodes when commitments slip repeatedly.

When someone asks “how long will this take?” the honest answer is often “I don’t know anymore.”

The Hidden Costs Nobody’s Talking About

The expectation problem is obvious once you see it. But there are other traps hiding underneath:

You’re Not Writing Code Anymore. You’re Validating It.

One researcher described it perfectly: “A senior developer with Copilot doesn’t become a code-writing machine. They become a code-validation machine.”

When AI generates 40% more code, you have 40% more code to review. But reviewing AI code is different than reviewing human code. Humans make predictable mistakes. AI makes plausible-sounding nonsense that looks right until you run it.

Context switching between your work and reviewing AI output costs 20-30% of your focus per switch. When you’re juggling multiple AI-started features, you’re switching constantly.

You’re not more productive. You’re just more exhausted.

You Say Yes to Everything

AI makes tasks that used to be “too expensive” feel trivial. So you say yes to things you would have declined or delegated.

“Can you add that dashboard feature?”

“Sure, AI can knock that out.”

“Can you refactor that module?”

“Yeah, should be quick with AI.”

“Can you investigate that performance issue?”

“I’ll have AI profile it.”

Harvard Business Review calls this work intensification : AI doesn’t reduce your workload, it makes you take on more.

You’re not automating your way to free time. You’re automating your way to more commitments.

The Quality-Speed Death Spiral

Here’s how it compounds:

AI gives you an initial productivity surge
That surge creates expectations for speed
Speed pressure leads to cutting corners on review
Lower quality creates more bugs
More bugs mean more debugging and rework
Debugging takes longer because you didn’t write the code
You fall behind, pressure increases, quality drops further

The Berkeley researchers warned: “The productivity surge enjoyed at the beginning can give way to lower quality work, turnover, and other problems.”

This is happening right now across teams. Features ship that “work,” but the developers don’t fully understand how. When they break, debugging becomes an archaeology project through code nobody wrote and barely reviewed. That’s not faster. That’s deferred pain.

What This Actually Feels Like

A software engineer named Siddhant Khare wrote about “AI fatigue” last week. It resonated with me immediately because it’s real and nobody talks about it.

AI-era burnout doesn’t look like working 80-hour weeks. It looks like:

Decision fatigue from validating endless AI outputs. Every line might be wrong. Every function might have a subtle bug. You can’t just skim.

Cognitive load from juggling multiple AI-started initiatives. Each one 80% done. None actually shipping.

Imposter syndrome when you can’t tell if you’re productive or just busy. You wrote 3,000 lines this week. Zero features shipped. Are you slow? Or is the process broken?

Anxiety from commitments you can’t estimate. You said 2 days. It’s been 4. The AI generated the code in 20 minutes and you’ve been debugging it ever since.

Guilt for not keeping up. Everyone else seems to be shipping faster with AI. Why aren’t you?

The research shows that some developers see burnout risk drop 17% with AI — but only if their workload doesn’t increase to fill the gap.

In practice? Workload always increases.

The Team Lead’s Nightmare

If estimating one AI-assisted task is this chaotic, imagine coordinating an entire team.

You’re trying to plan a sprint. Every developer gives you an estimate. Half of them are wildly optimistic because “AI will handle it.” The other half are padding heavily because they’ve been burned.

You don’t know which estimates to trust. You don’t know how to aggregate them into a roadmap. You don’t know how to explain to stakeholders why the team that just adopted “productivity-boosting AI tools” is still missing deadlines.

And when the sprint ends? Half the stories are “80% done.” A quarter shipped but with bugs. The rest are stuck in AI-generated complexity no one fully understands.

Tech leads are stuck in the middle. Can’t estimate their own AI-assisted work. Somehow supposed to help the team estimate theirs.

Sprint planning feels like collective guessing. Retrospectives turn into “we don’t know what went wrong, the AI just… took longer than expected.”

The only solution I’ve found is the boring one: go back to basics.

Estimate anyway. Even if it’s totally wrong.

Run retrospectives. Understand what actually happened.

Repeat every cycle. Gather data.

Adjust future estimates based on reality, not hope.

It’s unglamorous. It’s slow. But it’s the only path I see to understanding our true capacity with AI.

You can’t optimize what you don’t measure. And right now, most teams aren’t measuring anything except “we’re using AI, we should be faster.”

After enough cycles, patterns emerge:

AI features that touch legacy code take 3x longer than expected
Net-new features hit estimates more reliably
Code review adds 40% to any AI-heavy story
Integration work still takes the same time regardless of AI

None of this is in the “AI boosts productivity 39%” headline. But it’s the reality of coordinating a team in the AI era.

The boring strategies we’ve always used — estimate, measure, learn, adjust — they still work. They’re just slower to calibrate now because the variables changed.

What I’m Trying (Not Prescribing)

I don’t have this figured out. Nobody does yet. But here’s what’s helping in my experience:

The One-Thing Rule

Stop saying yes to multiple simultaneous AI features. One thing from start to shipped before starting the next.

Does it feel slower? Yes.

Do you actually ship more? Also yes.

Multiple AI-started initiatives feel like progress until nothing’s actually done. Finishing one thing beats starting five.

Honest Estimates

When someone asks “how long will this take?” stop giving the optimistic AI-boosted number.

Instead: “AI might generate it in an hour. Integration and debugging might take 3 days. Estimate 4 days to be safe.”

It feels slow. But estimates stop slipping constantly. And trust improves.

The Validation Budget

Timebox AI code review. If you can’t fully understand and validate what the AI built in the time it would have taken to write it yourself, don’t use the AI code.

Sounds counterintuitive. But reviewing 800 lines of AI code you don’t understand for 6 hours defeats the purpose. Sometimes writing 200 lines yourself in 4 hours is actually faster.

Measuring What Matters

Stop tracking lines of code or features started. Track instead:

Features actually in production
Bugs introduced per feature
Time from “start” to “shipped” (not “AI generated code”)
Team stress level (are people sleeping okay?)

The numbers are uncomfortable. But they’re honest.

Using Speed for Quality, Not Quantity

When AI genuinely saves time, spend that time on:

Better tests
Clearer documentation
Paying down technical debt
Deeper thinking on architecture

Not just “more features.”

The productivity gain is real. The question is: who captures it? If it all goes to “more output for the same salary,” you’re on a treadmill. If some goes to making work better and more sustainable, everyone might actually benefit.

At the Team Level: The Data Discipline

For tech leads and managers, the same boring-but-effective cycle applies:

Estimate — Even when it feels like guessing. Get the team’s best guess on record.

Measure — Track actual time, not AI generation time. Start to shipped, not start to “AI wrote code.”

Retrospect — What took longer than expected? What patterns are emerging?

Adjust — Use the data. If AI stories touching legacy code are consistently 3x estimates, factor that in next sprint.

After 4-5 cycles, you start seeing your team’s actual capacity with AI. Not the theoretical 39% boost. The real number.

It’s slower than anyone wants. But it’s the only path to honest planning.

The Uncomfortable Question

Here’s what I keep coming back to:

The 39% productivity gain might be real. But who’s capturing it?

Your company captures it as more output for the same salary.

Your manager captures it as more ambitious roadmaps.

The market captures it as higher expectations.

You capture… what? More stress? More context-switching? More debugging code you didn’t write?

Unless you actively defend your boundaries, AI productivity tools become productivity traps — a treadmill that speeds up but never lets you off.

I don’t want to sound cynical. AI is genuinely powerful. I use it every day. But the default path is work intensification, not work reduction. And if you don’t choose differently, the default will choose for you.

A Different Path

What if AI augmentation wasn’t about doing more? What if it was about doing better?

What if productivity gains went toward:

Deeper thinking on hard problems
Mentoring junior developers
Paying down technical debt
Building more resilient systems
Actually shipping polished features instead of half-finished experiments
Sustainable pace instead of constant sprinting

The technology is powerful. The question is: who decides what that power is for?

Right now, the default answer is “more output.” But you can choose differently.

You can say no to the fifth simultaneous initiative.

You can give honest estimates instead of optimistic ones.

You can spend AI-gained time on quality instead of quantity.

You can protect your boundaries instead of filling every efficiency gain with new commitments.

The 39% productivity trap is only a trap if you don’t see it coming.

Now you do.

What’s Next

This is still being figured out across the industry. Some weeks teams ship fast and feel great. Other weeks they’re drowning in half-finished AI features and wondering what went wrong.

But patterns are emerging. Data is being gathered. Teams are learning to say no more often. And slowly, the industry is learning to use AI as a tool for better work, not just more work.

If you’re feeling this too — the expectations, the estimation chaos, the validation treadmill — you’re not slow. You’re not behind. The system is broken, and you’re just the first to notice.

The question is: what are you going to do about it?

If this resonated with you, I’d love to hear your experience. Are you in the productivity trap too? What are you trying? Find me on LinkedIn.

Further Reading:

TechCrunch: “The first signs of burnout are coming from the people who embrace AI the most” (Feb 2026)
Harvard Business Review: “AI Doesn’t Reduce Work—It Intensifies It” (Feb 2026)
Fortune: “AI is having the opposite effect it was supposed to” (Feb 2026)
METR: “Measuring the Impact of Early-2025 AI on Developer Productivity”
Business Insider: “AI fatigue is real and nobody talks about it” (Feb 2026)

The post Nobody Knows How to Estimate Software Anymore (And It’s Not Your Fault) appeared first on sudoish.

The Review Bottleneck: Why AI Explanations Are Making Us Trust Less, Not More

Thiago Pacheco — Fri, 13 Feb 2026 14:07:52 +0000

Last week I spent 3 hours reviewing code that took 20 minutes to write.

The AI was faster. The review wasn’t.

And I’m starting to realize: that’s the problem.

“Less coding, more engineering.”

I keep hearing this phrase everywhere. The idea is simple: AI handles the coding, so developers focus on the higher-level work. The engineering. The architecture. The review.

But here’s what nobody’s talking about: AI isn’t just writing the code anymore. It’s reviewing it too.

And the paradox is obvious once you see it: AI generates code faster, but reviewing it takes longer than ever.

Here’s what those 3 hours looked like:

I read through 300 lines of code carefully. Checked the tests. Verified the logic flow. Examined edge cases.

But that was only the first hour.

The next two hours? Reading AI-generated explanations. Reviewing the AI code reviewer’s feedback. Cross-referencing the AI’s architectural justifications with the actual implementation. Trying to reconcile conflicting suggestions from different AI systems.

By the end, I understood the code. But I’d spent more time processing AI commentary than reviewing actual logic.

And here’s what bothered me: I see people in the industry are approving similar PRs in 20 minutes.

Are they reading all of this? Or are they skimming the AI explanations and trusting by default?

I’m pretty sure it’s the second one.

This isn’t about being thorough versus lazy. It’s a recognition of something shifting.

300 lines of actual code
1,200 words of AI-generated explanation
800 words of AI code review feedback
15 inline comments from the AI about trade-offs and alternatives

I had more documentation to review than code.

300 lines of actual implementation
2,000+ words of AI-generated commentary

The code was the easy part. The cognitive load came from synthesizing multiple AI perspectives, each confident, each reasonable-sounding, some subtly contradicting each other.

The tests passed. The linting passed. The AI explanations sounded reasonable. The AI reviewer’s concerns seemed addressed.

So I trusted the process and moved on.

And that’s becoming the norm.

I’m not alone.

At Anthropic—the company building Claude—engineers are generating 2,000 to 3,000 line pull requests regularly. Mike Krieger, their Chief Product Officer, openly admits: “pretty much 100%” of their code is now AI-generated.

And they’re using Claude to review it too.

Boris Cherny, head of Anthropic’s Claude Code team, hasn’t written a single line of code in over two months. He shipped 22 pull requests in one day, 27 the next.

“Each one 100% written by Claude.”

This isn’t the future. It’s happening right now, at the companies building the AI tools we’re all using.

The Confidence Trap

Code reviews were already hard. They required skill, domain knowledge, and patience.

Now multiply that by the sheer volume AI generates.

But volume isn’t even the real issue.

The real issue is that AI writes confident code. It comes with detailed explanations. Trade-off analysis. References. Architecture justifications.

Enough well-articulated reasoning to make everything sound sensible.

When you look at a 500-line PR with a 2,000-word explanation of why every decision was made, the cognitive load is enormous.

You can dig in and verify every claim.

Or you can trust that the explanation sounds reasonable and move on.

Most developers are choosing “move on.”

Here’s where we are:

Claude Code and Codex are generating code at unprecedented scale. 46% of developers’ code is now AI-written across major tools like Claude Code, Codex, and GitHub Copilot.

84% of developers use AI coding tools regularly.

And here’s the kicker: while AI generates nearly half our code, only 30% of AI-suggested code actually gets accepted.

The rest gets rejected during review—or should get rejected.

Then We Added AI Code Review

So teams did the obvious thing: bring in AI code review tools.

Now every PR has:

The AI-generated code (500 lines)
The AI’s explanation of what it built and why (2,000 words)
The AI reviewer’s analysis (another 1,500 words)
Sometimes multiple AI reviewers, each with their own opinions

You’re staring at 4,000+ words of confident, reasonable-sounding explanations from multiple AI systems.

All of it well-structured. All of it articulate. Much of it contradicting itself in subtle ways.

And you’re supposed to synthesize all of this, make a judgment call, and approve or reject.

What actually happens?

You skim the AI’s explanation. You skim the AI reviewer’s comments. If they roughly agree and the tests pass, you approve it.

The AI’s confidence became your confidence by default.

Research confirms what we all feel: AI-generated code creates 1.7x more issues than human-written code.

Unclear naming. Mismatched terminology. Generic identifiers everywhere.

All of it increasing cognitive load for reviewers.

And here’s the kicker: all of it explained so confidently you don’t question it.

This is what researchers call “automation bias”—our tendency to accept answers from automated systems, even when we encounter contradictory information.

We’re not carefully evaluating the code. We’re trusting that the volume of explanation equals correctness.

More Explanation ≠ More Understanding

The paradox is obvious once you see it:

Adding AI code reviewers didn’t make reviews better. It made them worse.

Not because the AI reviewers are bad. But because the sheer volume of explanation—from the writer AI, from the reviewer AI, sometimes from multiple reviewer AIs—has become impossible to actually process.

We traded one problem (not enough context) for another (too much confident noise).

And the human reviewer, the supposed quality gate, is now just the person who clicks “Approve” after skimming thousands of words they don’t have time to verify.

The bottleneck isn’t writing code anymore.

It’s not even reviewing code.

It’s trusting code we don’t fully understand because we’re drowning in explanations that sound reasonable but are too expensive to verify.

Even OpenAI acknowledges this in their Codex documentation: “It still remains essential for users to manually review and validate all agent-generated code.”

But are we actually doing that?

The evidence suggests no.

Wait. See What Just Happened?

I need to be honest with you.

I almost did the exact same thing to you.

I almost buried this post in citations.

16 footnotes. Statistics every other paragraph. Research from Anthropic, OpenAI, arXiv, CodeRabbit, Qodo. All credible. All well-sourced. All making the same point.

And if you’re like most readers, you would have skimmed them. Trusted that they said what I claimed. Moved on.

That’s exactly what we’re doing with code reviews.

The volume of explanation—even when accurate—becomes its own problem. Too many words. Too much confidence. Not enough time to verify.

So we trust by default.

What I’m Trying

I don’t have this solved. But here’s what’s working for me:

The 30-minute rule – If I can’t understand the PR in 30 minutes of focused review, it’s too big. Send it back or break it down.

No AI reviewer without human review – AI review is a supplement, not a replacement. I still need to read the actual code, not just the summary.

The explain-it test – If I can’t explain the core logic to someone else, I don’t approve it. Knowing “the tests passed” isn’t good enough.

Does this slow me down? Yes.

Does it help? I think so.

But I’m also watching my team ship faster by trusting more. And I don’t know if I’m being careful or just stubborn.

Where This Leaves Us

I’m caught in the same trap.

I want to ship faster. But I also want to understand what I’m shipping.

And the current tools make both feel impossible at the same time.

Some days I slow down and review everything carefully. Other days I skim and trust.

And I’m not sure which approach is right anymore.

Anthropic’s Dario Amodei predicts the industry may be “just six to twelve months away from AI handling most or all of software engineering work from start to finish.”

25% of Google’s code is already AI-assisted.

30% of Microsoft’s code is AI-generated.

These aren’t small experiments. This is how we’re building software now.

But here’s what we’re not saying out loud:

We’ve replaced code we wrote and didn’t fully understand with code AI wrote and we definitely don’t understand.

We’re not talking about this problem honestly enough.

The “less coding, more engineering” narrative assumes we’re still doing the review work.

We’re not.

We’re skimming AI-generated justifications and hoping for the best.

Maybe that’s fine. Maybe the tests are good enough. Maybe AI review plus AI generation actually works.

But we should stop pretending we’re still doing the review work.

Because “less coding, more engineering” sounds great until you realize:

We’re not doing more engineering.

We’re doing more trusting.

So here’s my question:

Are you actually reviewing AI code? Or are you just hoping the explanation is right?

Because if it’s the second one—and the data suggests it is—we need to start talking about what comes next.

The quality gate we automated away isn’t coming back. We need to figure out what replaces it.

Next up: I’m going to share how I’m breaking down AI-generated features into bite-sized review sessions that force comprehension instead of trust. It’s slower. It’s deliberate. And it might be the only way to stay honest about what we’re shipping.

References & Further Reading

Key Sources:

Fortune: “Top engineers at Anthropic, OpenAI say AI now writes 100% of their code” – Mike Krieger and Boris Cherny interviews, January 2026
GitHub Copilot Statistics 2026 – 46% of code AI-generated
CodeRabbit: “AI code creates 1.7x more issues” – Cognitive load study, 2025
Index.dev: Developer Productivity Statistics 2026 – 84% adoption, 30% acceptance rate
OpenAI: Using Codex with ChatGPT – Manual review guidance
Springer: Automation bias in human–AI collaboration – AI & Society, July 2025

The post The Review Bottleneck: Why AI Explanations Are Making Us Trust Less, Not More appeared first on sudoish.

Working Twice as Hard to Be Seen as Average: Life as a Latino Developer

Thiago Pacheco — Wed, 11 Feb 2026 02:04:07 +0000

I walked into the conference room with my laptop to set up the infrastructure demo. Before I could connect to the projector, someone asked me to refill the coffee first.

I had a computer science degree. I was working in infra and support. But they saw a Latino face and assumed “service staff,” not “software engineer.”

This was in Brazil. My own country.

If the bias is this strong at home, imagine what it’s like abroad.

When I Moved Abroad

That coffee moment in Brazil taught me the bias runs deep, so deep it exists even at home.

But when I moved abroad? I learned what intensity means.

No one asked me to refill coffee anymore. The bias evolved. Got sophisticated.

I exceeded all expectations. Top performer. Multiple successful projects. When my first promotion came up, leadership hesitated.

Not because of my work, that was undeniable. But because something about me didn’t fit their mental model of what “senior” looks like.

It wasn’t just that moment. It was every single day.

Every code review scrutinized harder. Every meeting where I had to prove my point twice. Every technical decision questioned just a bit more. Every accomplishment met with surprise instead of recognition.

The weight isn’t in one coffee incident or one delayed promotion.

The weight is in living it every day , in ways so subtle that calling them out feels like paranoia—until the pattern becomes undeniable.

You’re Not Imagining It

If you’re a Latino developer, you’ve felt it. That sense that you need to work twice as hard to prove half as much. That your accent makes people second-guess your skills. That your degree from a Latin American university is worth less.

Here’s the data: You’re not imagining it.

Latinos are 19% of the US population but only 5.9-8% of the tech workforce
At Google in 2020, despite a $150M diversity commitment, Latinos made up just 5.9% of employees
In core computer/math roles, only 8.3% are Latino

Research on imposter syndrome shows it’s “especially prevalent in underrepresented racial and ethnic minorities” (NIH). Forbes notes that “minorities face bias that makes it harder for them to be promoted or selected for certain roles.”

This isn’t personal failure. This is structural exclusion.

The Google Interview

Ten years of experience. Proven delivery. Strong references.

I made it through all the Google interview rounds. The feedback was good.

Then: rejected. No clear explanation.

I kept replaying the system design interview. I knew my architecture was sound. But did I explain it the way they expected? Did my phrasing sound uncertain when I was being thoughtful? Did my accent make them doubt my competence?

I’ll never know.

But I know this: technical competence wasn’t the only thing being evaluated.

Research on technical interviews confirms it. interviewing.io found that “implicit biases sneak in and people aren’t even aware of them.” Non-native speakers face an inherent disadvantage in interviews where “effective communication is key to success.”

Here’s the nuance: You might be fluent in English, but cultural differences in how you convey ideas still come across as weakness.

Brazilian communication style is more relationship-focused, context-aware. North American style is more direct, transactional. Neither is wrong , but one gets judged as “unprofessional.”

The Hidden Barriers

These aren’t isolated incidents. They’re patterns.

The Name Effect

Resumes with Latino/Hispanic names get fewer callbacks. Even before the interview, the name creates bias. Some developers anglicize their names to get past this filter.

The Cultural Fit Trap

“Cultural fit” is often code for “thinks and communicates like us.” When you express ideas differently—even if technically sound—it gets labeled as not fitting in.

Timezone as Invisible Labor

Working from Brazil/LATAM for North American companies? Early morning or late night calls are YOUR problem to solve. You adjust. They don’t. This invisible labor never counts in performance reviews.

The Credential Discount

Your degree from a top Brazilian university isn’t seen as equal to a North American degree, regardless of actual education quality.

The Promotion Ceiling

High-performing Latino mid-level developers get held back from senior roles. The bar for “leadership presence” or “communication skills” becomes a convenient filter.

The Paradox

Here’s the weird part: this structural imposter syndrome (the one society applies to us and we apply to ourselves) makes us work 10x harder to achieve what others achieve easily.

Which makes us excellent engineers. But also exhausted humans who never feel like we’ve done enough.

This isn’t just personal. It’s social, structural, cultural. We do it to ourselves, AND the world does it to us.

The same trait that drives us to over-deliver also prevents us from recognizing our own value. We minimize our contributions. We overestimate North American tech. We stay silent in meetings. We accept lower salaries.

What We Bring

Flip the narrative. What do Latino developers bring that North American tech culture often lacks?

Work ethic – We’re willing to go further, learn more, prove ourselves repeatedly.

Resourcefulness – Building with constraints makes better engineers. We know how to do more with less.

Cultural intelligence – Navigating multiple cultures IS a technical skill. We understand global markets beyond the Silicon Valley bubble.

Relationship-building – Brazilian emphasis on personal connections creates stronger, more cohesive teams.

Multilingual abilities – Our “accent” is proof we’re multilingual. That’s a skill, not a weakness.

These are competitive advantages. But only if companies recognize them.

What To Do About It

For Latino Developers:

Document everything – Bias thrives in ambiguity. Keep records of your work and wins.

Build in public – Blog, contribute to open source, give talks. Create undeniable proof of competence.

Find the right companies – Look for Latino leadership or strong D&I track records. Culture starts at the top.

Practice technical communication explicitly – Mock interviews with native speakers help.

Leverage networks – Connect with groups like SHPE (Society of Hispanic Professional Engineers).

Own your accent – Reframe it as proof of multilingual ability, not a deficit.

For Allies and Managers:

Question your assumptions in code review – Am I judging the code or the communicator?

Separate technical competence from communication style – Different doesn’t mean worse.

Audit promotion decisions for bias – Are Latinos hitting a ceiling in your org?

Value multilingual abilities as a skill – Not just a neutral trait.

Champion Latino developers actively – Advocate for them in senior roles when they’re ready.

Not Just a Brazil Story

I wrote this from the perspective of a Brazilian software engineer. But these patterns aren’t unique to Brazil or Latin America. They’re not unique to tech.

This is what happens when you’re perceived as “other” in spaces built by and for one dominant culture.

The coffee. The furniture. The Google rejection.

These moments happen to Latinos across industries. To Africans in European companies. To Asians in Western firms. The details change. The pattern doesn’t.

The Honest Truth

Some days I feel confident. I know I’m good at what I do. I see the systems I’ve built, the people I’ve mentored, the problems I’ve solved.

Other days, the imposter syndrome wins. I wonder if I’ll ever be “enough.” I replay conversations, second-guessing how I phrased things. I see another rejection and wonder if it was my accent.

That’s okay.

Naming the reality doesn’t make it go away. But it does make it visible. And once it’s visible, we can change it.

If you’re a Latino developer: You’re not imagining it. You’re not alone. Your work is valuable. Your perspective matters. Keep pushing forward.

If you’re an ally: Look around your team. Who’s missing? Whose ideas get dismissed? Who has to work twice as hard to get half the credit?

Now you know. What will you do about it?

References

Per Scholas: Latino Representation in Tech
SQ Magazine: Diversity in Tech Statistics 2026
NIH: Imposter Phenomenon in Racially/Ethnically Minoritized Groups
BairesDev: Breaking Barriers – Tackling Imposter Syndrome Among Minorities in Tech
Forbes: How To Navigate Imposter Syndrome – A Hispanic Perspective
ACM: Fairness and Bias in Algorithmic Hiring
interviewing.io: Unconscious Bias in Technical Interviews

The post Working Twice as Hard to Be Seen as Average: Life as a Latino Developer appeared first on sudoish.

Are We Still Developers? The Hidden Cost of Vibe Coding

Thiago Pacheco — Fri, 06 Feb 2026 03:34:05 +0000

I generated 847 lines of production code in 12 minutes.

Not pseudocode. Not a prototype. Real, working Python with tests, error handling, API integration, and it works well. I described what I wanted to an AI agent, went to grab coffee, came back, and it was done.

It felt incredible. Like unlocking god mode. Why would I ever go back to writing code line by line?

The Promise & The Reality

This is the promise of AI-centric development tools like Zencoder, vibe-kanban, and even parts of Cursor. Steve Yegge calls it “vibe coding”: stop micromanaging, trust the AI, let it scaffold entire features while you focus on the big picture. And when you see it work, it’s intoxicating.

But here’s what happened next.

I had to review those 847 lines. Every function. Every edge case. Every assumption the AI made about my requirements. Did it handle validation correctly? Is this maintainable? Did it miss something subtle about the business logic?

The review took longer than writing it would have.

And I still wasn’t confident. So I asked a different AI to review the first AI’s code. It found some issues. I fixed them. But now I’m reviewing AI-generated fixes to AI-generated code, and I’m three layers deep in a review process that feels more like managing a team of junior developers than writing software.

Then comes the PR. Do I ask my teammates to review 847 lines of AI code? They’ll either spend hours on it (and resent me) or run it through AI themselves (and we’re all just trusting machines at that point).

The Identity Question

So I have to ask: what does this make us as developers?

If AI writes the code and AI reviews the code, and we’re just approving diffs we don’t fully understand… are we developers anymore? Or are we product managers for code we didn’t write?

Maybe that’s fine. Maybe AI is good enough now that we should embrace it.

But I don’t think it is. Not yet. I find issues constantly: bugs the AI missed, patterns it didn’t understand, edge cases it overlooked. And the “big bang” feature implementations don’t feel right to me. I still value ensuring the AI is building the right thing according to my understanding of the problem. And the only way to do that is to review in detail, stay close to the code, and actually understand what’s being built.

My Journey Through the Landscape

I’ve been a Vim user for years. Not the “I use Vim btw” meme kind. The “my fingers know hjkl better than WASD” kind. The muscle memory runs deep. So when AI coding assistants exploded onto the scene, I had a choice: migrate to VS Code like everyone else, or figure out how to make AI work in my world.

Let’s be clear: I didn’t stick with Vim out of stubbornness. I explored the alternatives. I keep exploring them.

Cursor: Too Distant

I’ve tried Cursor. It’s impressive: genuinely AI-first, with inline suggestions and chat that feels magical. But here’s the problem: it makes you too distant from the code. You’re directing an AI that’s directing the editor. There’s a layer of abstraction I don’t trust yet. I want my hands closer to the metal.

Zed: Doesn’t Fit My Workflow

I tried Zed. Better balance. It’s code-centric with AI tools bolted on the side: you choose when to invoke them. I liked that. But Zed expects you to work on one project at a time. That breaks my workflow immediately. I live in tmux with 3-4 projects open, constantly switching contexts, piping output from one terminal to another. Zed doesn’t fit that reality.

Zencoder & vibe-kanban: Even More Distant

Then I went to the other extreme: full AI-centric tools like vibe-kanban and Zencoder. I was motivated to try this route after reading Steve Yegge’s writings on vibe coding. The idea is compelling: stop micromanaging the AI, trust the vibes, let it scaffold entire features while you focus on the big picture. So I gave it an honest shot.

These tools are wild. You describe what you want, and they scaffold entire features, write tests, integrate APIs. It feels like having a senior dev in a box. Zencoder especially caught my attention. You feel powerful. You ship fast.

But here’s the catch: you’re absurdly distant from the code.

AI writes it. AI organizes it. You review diffs like a manager reviewing PRs. And I don’t trust AI that much yet. Every line it writes, I have to re-review. Does it meet standards? Is it maintainable? Did it miss an edge case? The review overhead is real.

What I realized: I still need to review code in detail and ensure features are going in the right direction. The “trust the vibes” approach sounds liberating, but in practice, I’m doing more cognitive work reviewing after the fact than I would have supervising during development.

The Solution: Bite-Sized Pair Programming

So I found a middle ground: bite-sized pair programming with AI. The AI does most of the coding. I supervise and keep it on track. I course-correct in real time instead of reviewing a massive diff later. And the best way I’ve found to do that is still Neovim + tmux : AI in one pane, code in another, constant back-and-forth.

I don’t write code the same way I used to. I used to open a file, think through the problem, and type. Now? I spin up a worktree, open an AI in a terminal pane, and direct the solution instead of typing it character by character. But I stay close. I supervise. I course-correct in real time.

The AI does the heavy lifting. I do the thinking. It’s not full vibe coding. It’s not solo coding either. It’s collaborative , with me staying close enough to catch problems early. The tools are different. The medium is the same: the terminal.

AI in the Terminal: Multiple Tools, One Workflow

The real shift wasn’t about finding one perfect plugin. It was about building a workflow that lets me use whatever AI tool fits the task without leaving the terminal.

For a while, I experimented with different approaches: Claude Code in a split buffer, Codex in a tmux pane, jumping between terminal windows to manage different tools manually. I wasn’t married to any particular setup.

More recently, I’ve found somewhat of a sweet spot: I use sidekick.nvim as my interface layer. It gives me the flexibility to switch between different AI agents when I want to. But in practice? I mostly default to Claude Code. Its rules and configuration are pretty robust right now, plus my company pays for it, so why not use it?

That’s the real advantage of the terminal workflow: the flexibility is there when you need it. Want to test a new model? Swap it in. Want a second opinion on code? Switch agents mid-task. But you’re not forced to constantly context-switch. You can settle into what works and only switch when it makes sense.

And here’s a workflow trick I’ve been using: implement a feature with one AI tool, then review or test it with a different one. You get a less biased second opinion. If Model A wrote the code and Model B flags the same issues you’re concerned about, you know it’s real. If Model B says “looks good,” you have more confidence. It’s like pair programming, but the second programmer is a completely different intelligence.

The “best” AI model changes constantly. Claude Code dominates today, but that changes by the hour. Being locked into one tool means you’re always playing catch-up. In the terminal, switching is trivial.

Why the Terminal Wins

Neovim scored 83% in StackOverflow’s 2024 Developer Survey as the most admired IDE, even though VS Code is the most used at 59%. That gap tells you something. People who use Vim don’t just tolerate it. They love it. And it’s not Stockholm syndrome.

Here’s what keeps me here.

Hands on the Keyboard

When my hands never leave the keyboard, I stay in flow. Every time I reach for the mouse, there’s a micro-decision: where’s the cursor? What am I clicking? Did I miss? Those interruptions compound. Not just in seconds, but in mental overhead.

Want to find a file? sf brings up Telescope. Search across everything? sg for live grep. Navigate between Vim splits, tmux panes, or even tmux windows? Ctrl+h/j/k/l handles it all seamlessly. Start a new task with a worktree and AI ready? at. Toggle a floating terminal? ;.

No mouse. No sidebars. No menu hunting. Just muscle memory.

The AI tools I use (Claude Code, Codex, OpenCode) fit into this. I don’t context-switch to a browser or separate app. I invoke them in a split pane with a keybind. Everything stays in one place.

Speed isn’t about typing fast. It’s about never stopping.

The Terminal is a Toolkit

The terminal isn’t one tool. It’s composable. Want to process JSON from an API? Pipe it to jq. Transform file paths? sed or awk. Run a command on 50 files? find | xargs. Monitor logs while coding? tmux split with tail -f.

When you add AI to this composability, things get wild.

I can prompt Claude Code in one pane, watch it write code in another, pipe the output through a test runner, grep the results, and feed errors back into the AI. All without leaving the terminal. All scriptable. All reproducible.

Cursor can’t do that. You can’t pipe Cursor’s output through grep. You can’t script it to run in a loop. It’s a black box. The terminal is Lego blocks, and AI is just another piece.

Performance You Actually Feel

VS Code and Cursor are Electron apps. They’re running a full Chromium browser under the hood. Neovim is written in C. It opens instantly, uses around 50MB of RAM, and never lags.

When I spin up 10 tmux tabs with Neovim and AI tools, my system barely blinks. Try opening 10 VS Code windows and listen to your fan scream.

I juggle 5 to 10 worktrees at any given time. Each one is a separate environment. If each took 500MB of RAM and 3 seconds to load, my workflow would fall apart. Neovim and tmux? Instant, lightweight, snappy.

My Setup is Code

My entire development environment is 600 lines of dotfiles in a git repo. New machine? Clone it, run a script, and I’m back up in two minutes. Same keybinds, same plugins, same aliases, same AI integrations.

GUI tools let you sync settings, but you’re at the mercy of their config systems. With terminal tools, the setup is code. You can version it, diff it, review it, share it. I can recreate my entire workflow on a fresh VM faster than VS Code can install.

These Tools Have Staying Power

Vim came out in 1991. Neovim in 2014. tmux in 2007. They’ve outlived programming languages, frameworks, companies. They’ll outlive Cursor. They’ll outlive Zed. They might outlive JavaScript.

The muscle memory I’m building, the keybinds, the workflow patterns: they’ll be relevant in 10 years. Will Cursor? Maybe. Probably not. Learning Vim is an investment that compounds. GUI tools are a bet on a company staying solvent.

The Control Gradient

Here’s how I think about the spectrum:

Full Control (Traditional Vim)

You write every character. You think through every problem. Slow, but you know exactly what’s happening.

AI-Assisted (My Current Setup)

You direct the solution. AI accelerates execution. You stay close to the code. You review as it’s built, not after. You can do manual trivial actions where pertinent instead of asking everything to the agent.

AI-First (Cursor, Zed)

AI suggests, you accept/reject. Fast, but you’re reacting more than creating.

AI-Centric (Zencoder, vibe-kanban)

AI builds, you review diffs. Fastest, but you’re a product manager for code you didn’t write.

Right now, AI-assisted is the sweet spot. I get speed without losing control. I stay in my flow. I trust the output because I was there while it was written.

But I’ll be honest: this might not last.

AI is getting scary good at both writing and reviewing code. It’s catching bugs I miss. It’s flagging patterns I overlook. If AI review becomes as reliable as human review, the argument for staying hands-on gets weaker.

We might be transitioning to AI-centric whether we like it or not. The question is: how long do I have before “staying close to the code” becomes nostalgia instead of pragmatism?

For now, I’m staying in the terminal. But I’m watching.

The Honest Uncertainty

This workflow makes me feel in control. I know where my code is, how it got there, and what’s happening at every step. I’m not watching an AI build something in the background and hoping it got it right. I’m directing it, reviewing as it goes, staying close to the work.

That control matters. For now.

But I’d be lying if I said I’m confident this is the future. AI is getting better at an absurd pace. It’s already catching bugs I miss. It’s writing code that would take me hours in minutes. It’s reviewing my work and finding patterns I overlooked.

At some point, the argument for staying hands-on stops being pragmatic and starts being nostalgic. Maybe we’re already there and I just don’t want to admit it.

I keep testing the AI-first tools. Zencoder, vibe-kanban, Cursor. Not because I think they’re worse, but because I want to know when the terminal workflow stops being the smart choice and starts being stubbornness.

Maybe that happens next week. Maybe it already happened and I’m just slow to see it. AI-centric development might not be a distant future. It might be now, and I’m still clinging to a workflow that makes me comfortable.

For today, I’m staying in the terminal. It’s faster for me. It fits how I think. It keeps me close to the code in a way that feels right.

But tomorrow? Who knows.

The terminal-centric workflow wins for me right now. But I’m watching the gap close. And when it does, I’ll probably switch. Not because I want to, but because it’ll be the obvious move.

Until then, I’ll keep hitting at and letting the AI do the heavy lifting while I stay at the wheel.

The post Are We Still Developers? The Hidden Cost of Vibe Coding appeared first on sudoish.

DEV Community: Thiago Pacheco

The Most Important Skill in Tech Is Too Expensive to Learn

The Skill That Runs Everything Now

The Model Is the Bottleneck

Who Gets Left Behind

What I’m Actually Doing About It

The Industry Problem We’re Building

The Bet

References

No Developer Feels AI Literate Right Now — Not Even the Ones Building It

The Illusion of AI Fluency

The Arc: Convergence to Divergence

The Best Practice Treadmill

So What Does This Mean for Your Career?

Pick One Tool. Get Dangerously Good at It.

Build Something That Felt Impossible

The Uncomfortable Truth

References

Spec-Driven Development Isn’t Waterfall — But It Keeps Ending Up There

The Confidence Problem Nobody Mentions

The Intent vs. the Reality

The Waterfall Gravity

What SDD Gets Right

Thinking in Graphs

What This Looks Like in Practice

The Gap That Needs Filling

Clean Code Is Dead (And I Hate That I Agree)

Clean Code Was Always a Human Interface

AI Doesn’t Need Your Clean Code

The Highest Level Language Is English Now

We’re Losing Control at Every Layer

Maybe I’m Too Attached to the Craft

The Mental Model Shift

I Don’t Have a Clean Answer

You Think, AI Executes: The Skills That Actually Matter

Why This Matters

The Actual Workflow: What I Did vs What AI Did

The Four Skills

The Feature Request

The .ai/ Structure: Context as Code

The Task Spec: Planning Before Coding

The TDD Flow: Red → Green → Refactor → Commit

The Review Process

The Manual Testing

The PR

What I Learned

The Real Value

Try It Yourself

The Full Timeline

Resources

The Skills That Actually Matter

What This Means for Your Career

How We Made It Nearly Impossible to Become a Developer

The Interview Problem Nobody Wants to Fix

When Even a Principal Engineer Can’t Pass

The Wrong Skills at the Worst Time

Now Add AI to the Mix

The Senior Shortage Nobody Sees Coming

The Squeeze

What Actually Needs to Change

The Real Question

The AI Productivity Lie Nobody Wants to Admit

The Pressure Nobody Talks About

The Data That Should Make You Uncomfortable

You’re Not Even Faster

You Understand Less of What You Ship

The Industry Already Knows

Throughput vs. Confidence

The Confidence Boundary

The Bet I’m Making

Sources

A Tale of Accidental Architecture: How 50 Lines Became A Black Friday Disaster

Week 1: The Perfect Start

Week 3: The First Copy-Paste

Week 5: User Preferences

Week 7: Two Ways to Do Everything

Week 9: The Third Approach

Week 12: The Chaos Compounds

Week 15: Customer Complaints

Week 17: The Template Nightmare

The `.ai/` Structure: Context as Code