Things that helped me get out of the AI 10x engineer imposter syndrome

I think this is a strawman argument that is conflating uses for AI. I posted a video not long ago where Andrew Ng makes the claim to the AI Startup school that in testing they are seeing ~10x improvement for greenfield prototypes and 30%-50% improvement in existing production code bases.

So two groups are talking past one another. Someone has a completely new idea, starts with nothing and vibe codes a barely working MVP. They claim they were able to go from 0 to MVP ~10x faster than if they had written the code themselves.

Then some seasoned programmer hears that claim, scoffs and takes the agent into a legacy code base. They run `/init` and make 0 changes to the auto-generated CLAUDE.md. They add no additional context files or rules about the project. They ask completely unstructured questions and prompt the first thing that comes into their minds. After 1 or 2 days of getting terrible results they don't change their usage or try to find a better way, they instead write a long blog post claiming AI hype is unfounded.

What they ignore is that even the maximalists are stating: 30%-50% improvement on legacy code bases. And that is if you use the tool well.

This author gets terrible results and then says: "Dark warnings that if I didn't start using AI now I'd be hopelessly behind proved unfounded. Using AI to code is not hard to learn." How sure is the author that they actually learned to use it? "A competent engineer will figure this stuff out in less than a week of moderate AI usage." One of the most interesting things about learning are those things that are easy to learn and hard to master. You can teach a child chess, it is easy to learn but it is hard to master.

The other day I asked chatgpt (o3) to help me compare a bunch of task orchestration systems and arrange them according to some variables I care about (popularity, feature richness, durability, whether can be self-hosted, etc.). I ended up using https://www.inngest.com/ -- which was new to me -- and that single tool sped up my particular task by at least 10x for the week. That was a one-off project, so it won't generalize in a clean way, but I keep finding individual cases where the particular strengths of LLMs can save me a whole bunch of time. (another example: creating and evaluating responses to technical interview questions). I don't expect that these are easy to quantify, but they are significant.

This is not to disagree with the OP, but to point out that, even for engineers, the speedups might not appear where you expect. [EDIT I see like 4 other comments making the same point :)]

That's not a rigorously measured number.

The 5% is an increase in straight-ahead code speed. I spend a small fraction of my time typing code. Smaller than I'd like.

And it very well might be an economically rational subscription. For me personally, I'm subscription averse based on the overhead of remembering that I have a subscription and managing it.

hopefully we all remember Amdahl's law and reflect on how much time a software engineer actually spends on the "typing code" part of the job of "delivering software that solves some business need".

No one said anything about lines of code. I would assume output here means features completed, tickets knocked out, tasks completed etc.