Forem: Thiago Pacheco

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.

What I’m Doing to Not Become Irrelevant

Thiago Pacheco — Mon, 02 Feb 2026 16:46:15 +0000

I wrote recently about the developer identity crisis. The weird feeling of watching AI do the work we spent years learning to do ourselves.

But naming the problem isn’t enough. I’ve been thinking about what to actually do about it. What habits keep us sharp. What makes a developer valuable when the execution layer is being automated.

I don’t have all the answers. But I’ve been experimenting. Here’s what I’m trying.

I Still Write Code By Hand

There’s a real risk in the AI-assisted workflow: you stop coding.

I noticed it happening to me. Language features I used to know cold got fuzzy. I was slower without the AI. Rustier. Looking up things that used to be automatic.

So I started doing LeetCode again. Not because I’m interviewing anywhere. Just to keep the muscle memory alive.

It feels a bit like practicing flatground tricks at an empty parking lot. Nobody’s filming you do kickflips for Instagram there. But if you stop drilling the basics, your whole game falls apart when it actually matters.

I’m not trying to compete with AI on speed. I gave up on that. But I need to keep my judgment sharp enough to evaluate what the AI produces. And that requires actually understanding code at a level you can only maintain by writing it.

I’m Learning to Be Visible

This one feels uncomfortable to write about. I’m not naturally someone who promotes their work. I always figured good work speaks for itself.

It doesn’t. Not anymore.

When AI can theoretically do what you do, you need to show that you’re the one making things happen. Not in a braggy way. Just… clearly. Document your decisions. Share your thinking in PRs and meetings. Write about what you’re learning.

If your work is invisible, people will assume AI could replace you. Maybe not consciously. But when cuts happen, the people nobody notices are the first to go.

I’m still figuring out how to do this without feeling gross about it. But I’ve accepted that it’s part of the job now.

Every Developer Is Becoming a Team Lead

Here’s a weird realization I had: the skills for leading AI agents are the same skills for leading people.

Breaking down ambiguous problems into clear tasks. Providing enough context so others can execute well. Reviewing work and course-correcting. Unblocking progress. Communicating status.

That’s management. That’s tech leading. And now that’s also… prompting?

If you’re orchestrating a bunch of AI agents, you’re basically running a team. A very fast, very literal team that does exactly what you say. Which means you better say the right things.

The upside is that you have more resources than ever. You can be bolder with what you take on because you have the capacity to actually execute it. But only if you know how to lead.

Communication skills, leadership skills. These were always important. Now they’re the whole job.

I Keep a Dev Journal

This is maybe the simplest habit, and it makes all the others easier.

Every day I write down what I worked on. What I accomplished. What went wrong. What decisions I made and why.

It sounds basic. But when AI does the implementation, it’s easy to lose track of your own contributions. The journal anchors it.

It also makes 1:1s with my manager way easier. Performance reviews too. Instead of scrambling to remember what I did six months ago, I just look it up. I have receipts.

And there’s something about writing things down that creates clarity. I notice patterns. I see when I’m spinning my wheels. I catch myself before I waste a week on something that doesn’t matter.

I Automated My Morning Planning

This is the meta move: using AI to help me stay relevant in the AI era.

I set up an automation with OpenClaw that runs every morning. It gathers context from my work. What’s in progress, what’s blocked, what the priorities are. Then it suggests where I should focus, how I can help unblock others, and how to communicate my impact without being annoying about it.

The output is a day plan broken into pomodoros. I know exactly what I’m doing and when.

Before this, I’d start my day scattered. Check Slack. Check email. Context-switch for an hour before doing anything useful. Now I start with clarity.

It’s not about working harder. It’s about not wasting time figuring out what to work on.

I Do Things That Aren’t Work

I almost didn’t include this one because it sounds like generic self-help advice. But it’s been more important than I expected.

The temptation when everything is changing is to grind harder. Learn more. Stay online longer. Keep up with every new tool, every new technique, every new AI model drop.

That’s a trap.

I skate. Have for years. And I’ve noticed something: the days I get on my board, I’m better at my job. Not despite the time away from the screen. Because of it.

There’s something about skateboarding that clears my head in a way nothing else does. You can’t think about work when you’re trying to land a trick. You can’t worry about AI taking your job when you’re focused on not eating concrete. It forces presence.

And when I come back to work, I think more clearly. I make better decisions. I’m less reactive, less anxious about all the change happening around us.

I’ve noticed the opposite too. When I skip skating for a few weeks, when I’m just grinding at the computer every day, I get worse. Not better. My thinking gets foggy. I burn out on things I used to enjoy. I make dumber calls.

If your whole identity is “developer,” and that identity feels threatened, you’re going to spiral. Having something else gives you stability. A sport, a hobby, anything that pulls you out of your head. A foundation that doesn’t shake every time a new model drops.

Take care of yourself. The developers who burn out won’t be around to see what happens next.

The Common Thread

All of this requires being intentional. That’s the actual habit underneath the habits.

The developers who fall behind will be the ones who just let things happen to them. Who assume their skills stay relevant automatically. Who keep doing what they’ve always done because it worked before.

The job changed. We have to change with it. Not by panicking, but by building habits that keep us sharp, visible, and grounded.

I don’t know if I’m doing it right. But I’m trying.

The post What I’m Doing to Not Become Irrelevant appeared first on sudoish.

The Developer Identity Crisis

Thiago Pacheco — Sun, 01 Feb 2026 18:41:21 +0000

I keep seeing variations of this pitch everywhere:

“A bug report hits Jira at 3 AM? Your autonomous agent wakes up, reproduces it, writes the fix, and opens the PR before your alarm goes off.”

That’s from Zencoder’s marketing site. But it’s not just marketing anymore, developers are actually doing this. They’re using tools like Zencoder, Claude code, Openclaw, and others to delegate entire features or bug fixes to AI agents that run autonomously while they sleep.

The workflow is straightforward: assign a GitHub issue to the agent, let it work overnight in a sandboxed environment, wake up to a pull request with passing tests, review the diff, merge it.

The tests pass. The code works. They ship it.

And here’s the part that keeps me up at night: many of them admit they don’t fully understand every implementation detail. They review for correctness and patterns, but not line-by-line comprehension. And they’re shipping faster because of it.

I’ve been thinking about this for weeks. Because I can’t do that. Not yet.

My Workflow Isn’t There Yet

I use AI constantly. Claude Code and orchestrators like OpenClaw, they’ve transformed how I work. I can spin up features that would have taken days in a fraction of the time. The productivity gains are real.

But I still review everything. I still read the diffs. I still make sure I understand what went into the codebase before I approve it. I don’t merge code I haven’t checked.

And here’s the uncomfortable part: I’m starting to wonder if that makes me slow.

Because I’m watching people who don’t review everything. They’re shipping faster. They’re building more. And their code… works. Their products ship. Their companies grow.

The question that keeps me up at night isn’t “can AI code?” anymore. It’s: how much can I trust it before my caution becomes a liability?

The Job Changed Underneath Us

If you’ve been coding for more than a few years, you’ve felt it. The ground shifted. What we do day-to-day looks fundamentally different than it did even 18 months ago.

We used to write code. Now we orchestrate AI agents that write code.

We used to debug line by line. Now we describe the bug and let the agent fix it.

We used to refactor carefully. Now we prompt for a rewrite and evaluate the output.

The transformation isn’t subtle anymore. AI agent tools crossed some threshold. They’re not assistants anymore, they’re doing the actual work.

And here’s what nobody wants to say out loud: they’re often better at it than we are. Faster, definitely. More thorough in edge cases. Less prone to the lazy shortcuts we take when we’re tired.

The role of “software developer” didn’t disappear. It just became something else entirely. We’re now:

Task organizers — Breaking down requirements into agent-friendly chunks
Configuration engineers — Building rules, skills, and context for AI systems
Quality evaluators — Reviewing output for correctness, not writing it ourselves
Visibility champions — Advocating for our work because “just coding” is invisible now

If you’re a developer who just wants to code in peace, I have bad news for you: that job is disappearing.

The Pioneers Are Already There

I’m not imagining this shift. Some of the sharpest minds in our industry are actively building for a future where human code review might be optional and their work reveals just how far the transformation has already gone.

Steve Yegge’s Gas Town: The Industrial Coding Factory

Steve Yegge—the legendary blogger who gave us classics like “Stevey’s Google Platforms Rant”—recently launched Gas Town, what he calls “a new take on the IDE for 2026.” It’s not an IDE in any traditional sense. It’s an orchestrator for running dozens of Claude Code instances simultaneously.

In his words: “Gas Town is an industrialized coding factory manned by superintelligent robot chimps.”

He describes an 8-stage evolution of the AI-assisted developer, from basic code completions all the way to running 10+ agents at once. If you’re not at stage 6 or 7? “You will not be able to use Gas Town. You aren’t ready yet.”

Yegge also created Beads, a persistent memory system for coding agents. Because when you’re running that many agents, you need infrastructure just to keep track of what they know. He’s literally building Kubernetes for AI coders.

The pattern he describes: Prompt → Sleep → Evaluate → Keep or Toss. Work becomes “an uncountable substance that you sling around freely, like slopping shiny fish into wooden barrels at the docks.”

That’s not coding as we knew it. That’s something else entirely. And Yegge’s doing it right now.

ThePrimeagen’s 99: The Neovim Purist’s Answer

On the other end of the spectrum, ThePrimeagen, known for his Neovim evangelism, launched 99, which he describes as “the AI agent that Neovim deserves.”

His philosophy is different from the full-orchestration approach. 99 is built for developers “who don’t have skill issues”, those people who want AI integrated into their existing workflow, not replacing it. It’s about restricted AI interactions: fill in a function, handle a visual selection, stop when you want.

The interesting part? Even ThePrimeagen, arguably one of the most skilled traditional developers in the content space, is building AI tooling. He’s not fighting the wave; he’s figuring out how to ride it on his own terms.

These aren’t fringe experiments. These are serious developers building serious tools because they see what’s coming.

Caught in the Middle

So where does that leave people like me?

I see where this is going. I believe the future probably shifts heavily toward these “prompt and trust” workflows. The economics are too compelling. The speed advantages are too real. Companies will gravitate toward developers who ship faster, and right now, that means developers who trust AI more.

But I’m not there yet. And I’m honestly not sure if my reluctance is:

Wisdom: A healthy caution born from experience with software that breaks in subtle ways
Ego: An attachment to feeling like a “real programmer” who understands their code
Fear: Discomfort with a world where my hard-won skills matter less

Maybe it’s all three.

The honest truth is: I don’t fully trust AI-generated code yet. Not because I’ve seen it fail catastrophically. But because the few times I have caught issues, they were subtle. The kind of bugs that pass tests but cause problems in production. The kind that make you question everything you didn’t review carefully.

And yet… those catches are getting rarer. The AI is getting better. Every month the code quality improves, the edge cases get handled more gracefully, the architecture decisions get more sensible.

At what point does my reviewing become theater? At what point am I just going through the motions because it feels wrong not to, even though I’m not actually catching anything?

I don’t have an answer.

The Uncomfortable Truths We’re Not Talking About

Whether you’re in the “trust fully” camp or the “review everything” camp, some things are happening to all of us.

Skill Atrophy is Real

I’ve noticed it in myself. There are language features I used to know cold that I now… don’t. Not because I forgot them entirely, but because I haven’t actually typed them as often. The AI does it.

When I do need to write code without AI assistance, I’m slower. Rustier. More likely to look things up that used to be automatic.

Is this a problem? I don’t know. Maybe these skills don’t matter anymore. Maybe they do. But either way, they’re fading.

The Carelessness Creep

Even when I review code, I’ve caught myself being less thorough than I used to be. When the AI can regenerate something in seconds, the stakes for any individual piece feel lower. Made a mistake? Trash it and re-prompt.

This creeping carelessness scares me. Not because every line needs to be perfect, but because I’ve noticed myself letting things slide that I wouldn’t have before. Small things. Subtle things. The kind of issues that compound.

Code Review Culture is Fragmenting

Here’s where it gets really weird: people are using AI to review code too.

On one hand, this is powerful. AI can catch patterns and issues that humans miss. But on the other hand… we’re now in a loop where AI writes code and AI reviews code and humans just glance at both and click approve.

What happens when we stop deeply understanding the systems we’re building? When code becomes something we orchestrate but don’t really know?

The Disposable Code Question

Maybe code quality just doesn’t matter the way it used to.

If AI can rewrite a module in 30 seconds, why spend hours making it elegant? Why obsess over structure, readability, maintainability? Just make it work. When it breaks or needs to change, throw it away and regenerate it.

This feels wrong to me. But I can’t articulate exactly why. Maybe I’m just attached to an old way of working. Maybe “good code” was always just a means to an end, and now there’s a faster means.

Maybe code doesn’t need to be human-readable anymore. Maybe it just needs to be AI-readable. And maybe that’s fine.

I genuinely don’t know.

The Paradox: Embrace or Fall Behind

Here’s the impossible choice: embrace AI coding fully and potentially lose something essential, or maintain your review discipline and risk becoming irrelevant.

If you don’t use these tools you’re objectively slower than colleagues who trust more and verify less. You deliver less. You look less productive. In a world where companies are cutting costs and measuring output, that’s not sustainable.

But if you do embrace them fully, you risk becoming dependent. Losing skills. Becoming someone who can’t actually code anymore, just prompt.

I’m trying to find a middle path. Use AI heavily for generation, but maintain understanding. Trust but verify. It’s uncomfortable. It might not be sustainable. But it’s where I am right now.

And here’s the kicker: the job now requires something that coding alone never did: visibility.

It’s not enough to do good work. You have to be seen doing it. You have to advocate. Document. Communicate impact. Build relationships. The IC who just crushes code tickets in silence? That person is becoming a liability, because from the outside, it’s unclear what AI could or couldn’t do in their place.

What Even Is a Developer Anymore?

Here’s where I diverge from the panic.

A lot of developers are having an identity crisis because “AI can code now.” But honestly? I always thought being a developer was about more than writing code.

The job was never just about typing syntax. It was always about:

Knowing what to build (strategic thinking)
Knowing how to break it down (task decomposition)
Knowing how to evaluate quality (critical judgment)
Knowing how to communicate impact (visibility)

Coding was just the tool we used to execute on those skills. A really important tool, sure.

What’s happening now is that the tool is changing. The execution layer is being automated. But the thinking, the judgment, the strategy? That’s still ours.

If anything, AI is forcing the industry to acknowledge what good developers have always known: the hard part was never the syntax. It was figuring out what to build, why it matters, and whether it actually works.

The developers freaking out about “AI replacing us” are often the ones who built their identity entirely around code execution. And I get it, that was the most visible, most measurable part of the job. It’s what we practiced, what we got good at, what differentiated us.

But it was never the whole job. And now we’re being forced to reckon with that.

We’re the Canary in the Coal Mine

Software developers are experiencing this transformation first not because we’re special, but because we’re closest to the technology. We use AI to automate our own work. Of course it’s impacting us fastest.

But every profession is next.

The writer using AI to draft articles. The designer using AI to generate concepts. The analyst using AI to build models. The lawyer using AI to review contracts.

Everyone is about to face their own version of this identity crisis: “What is my job when AI can do the execution better than I can?”

We don’t have answers yet. We’re navigating in real-time, making it up as we go.

Navigating the Blur

I don’t have a clean conclusion here. No five-step framework for staying relevant. No confident prediction about where this goes.

What I do know:

The technology won’t slow down. We can’t wish our way back to a simpler time.

Skills still matter, but which ones is shifting. Deep technical knowledge isn’t obsolete, but it might not be sufficient anymore.

Intentionality is everything. We can drift into AI dependency without thinking, or we can engage with these tools critically, keeping what works, discarding what doesn’t, staying honest about trade-offs.

Trust isn’t binary. I’m somewhere on the spectrum between “review every line” and “ship without looking.” That’s probably where most of us are. And that’s okay, we’re all calibrating in real-time.

We’re figuring this out together. Nobody has it solved. The developers who seem most confident are probably just better at hiding their uncertainty.

The job is changing. Our identity as developers is changing with it. The only way through is acknowledging the discomfort and navigating it intentionally.

I still check the code. I still review the diffs. Maybe that makes me slow. Maybe that makes me careful. Maybe it’s just how I’m wired.

But I’m watching the people who don’t. And I’m taking notes.

We’re in uncharted territory.

And honestly? That’s both terrifying and kind of exciting.

What’s your experience with this shift? Are you in the “trust fully” camp, the “review everything” camp, or somewhere in between like me? I’d genuinely love to hear how other developers are navigating this.

The post The Developer Identity Crisis appeared first on sudoish.

How I Built an AI-Powered Development Workflow That Actually Works (And Increased My Productivity by 300%)

Thiago Pacheco — Tue, 17 Jun 2025 15:27:23 +0000

The Wake-Up Call: An On-Call Experience to Remember

A few months ago, I had my first on-call shift in a company I had recently started, and that changed the way I approach development forever. Alerts were firing in Sentry, and our monitoring dashboard was a sea of red. Despite having spent nearly 6 months at my company, I realized I only truly understood the small portion of the codebase I worked on daily. The rest felt like a vast, uncharted territory.

This experience was a stark reminder of the cognitive load that comes with modern software development. We often juggle countless services, databases, and deployment environments, and it can quickly become overwhelming. This on-call shift made me realize that I needed a faster approach to quickly fill the gaps that I was still missing, one that could help me manage this complexity without feeling lost.

A Mindset Shift: From Custom Configs to AI-Powered Productivity

As someone who has always been passionate about developer productivity, I've spent years fine-tuning my development environment. From crafting the perfect NeoVim config to creating scripts that automated my workflow, I was always on the lookout for ways to work smarter. But even with all these optimizations, it felt like there was still room for improvement—especially as AI tools started to emerge and revolutionize the way developers work.

When I first explored AI-powered editors and tools, it felt like stepping into a new world. I tried out editors like Cursor and Zed to see what AI could do, but ultimately, I wanted to bring that power back into my terminal-centric workflow. The turning point came with the introduction of Claude Code, which allowed me to seamlessly integrate AI into my existing setup, combining the best of both worlds.

Integrating AI: The Journey Back to a Smarter Terminal

Claude Code introduced an AI memory system that allowed me to store and retrieve context about my projects effortlessly. Each project directory had its own Claude markdown file, which acted as a living repository of knowledge, capturing everything from debugging breadcrumbs to service startup sequences.

With AI integrated into my terminal, my workflow transformed. Instead of juggling multiple tools and tabs, I had a single, cohesive environment where AI provided real-time assistance, whether it was pulling information from Sentry, retrieving a relevant Linear ticket, or referencing past debugging sessions.

The Tangible Benefits: From Overwhelm to Efficiency (with a Human-in-the-Loop Approach)

Integrating AI into my development workflow wasn't just about convenience; it led to measurable improvements in productivity and confidence. One of the most significant benefits was the drastic reduction in the time it took to diagnose and resolve issues.

However, it’s important to note that while AI can be a powerful assistant, it isn’t a silver bullet—especially when dealing with legacy codebases or complex architectural quirks. Sometimes, AI suggestions might not be the most optimal or might regurgitate outdated patterns. That’s where the human-in-the-loop approach truly shines.

By keeping yourself in the driver’s seat, you can leverage AI for what it does best—providing quick insights, surfacing patterns, and reducing cognitive load—while you ensure that the final implementation is sound and aligns with best practices.

Conclusion: Embracing AI, One Step at a Time

My journey into the world of AI-powered development has been transformative. By integrating AI thoughtfully, I’ve been able to boost productivity, reduce cognitive load, and keep my focus on what truly matters: solving interesting problems and writing great code.

In the next post, we’ll dive into the technical side of things: how to set up your own AI-powered development environment, integrate tools like Claude Code, and make the most of this exciting technology.

Forem: Thiago Pacheco

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

Week 20: Performance Crisis

Week 24: The Audit

The Breaking Point

What Went Wrong?

“But This Is Just a Communication Problem”

What Should Have Happened in Week 1

The Pattern You’ve Seen Before

Then AI Showed Up and Made Everything 10x Worse

AI Replicates. It Doesn’t Invent.

The Speed and Scale Just Exploded

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

The Old Advice Is Now Dangerous

But Here’s the Good News

What’s Next

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

The Promise vs The Reality

The High Expectations Problem

The Estimation Trap

The Hidden Costs Nobody’s Talking About

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

You Say Yes to Everything

The Quality-Speed Death Spiral

What This Actually Feels Like

The Team Lead’s Nightmare

What I’m Trying (Not Prescribing)

The `.ai/` Structure: Context as Code