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

I'm a pretty huge proponent for AI-assisted development, but I've never found those 10x claims convincing. I've estimated that LLMs make me 2-5x more productive on the parts of my job which involve typing code into a computer, which is itself a small portion of that I do as a software engineer.

That's not too far from this article's assumptions. From the article:

> I wouldn't be surprised to learn AI helps many engineers do certain tasks 20-50% faster, but the nature of software bottlenecks mean this doesn't translate to a 20% productivity increase and certainly not a 10x increase.

I think that's an under-estimation - I suspect engineers that really know how to use this stuff effectively will get more than a 0.2x increase - but I do think all of the other stuff involved in building software makes the 10x thing unrealistic in most cases.

Now that LLMs have actually fulfilled that dream — albeit by totally different means — many devs feel anxious, even threatened. Why? Because LLMs don’t just autocomplete. They generate. And in doing so, they challenge our identity, not just our workflows.

I think Colton’s article nails the emotional side of this: imposter syndrome isn’t about the actual 10x productivity (which mostly isn't real), it’s about the perception that you’re falling behind. Meanwhile, this perception is fueled by a shift in what “software engineering” looks like.

LLMs are effectively the ultimate CASE tools — but they arrived faster, messier, and more disruptively than expected. They don’t require formal models or diagrams. They leap straight from natural language to executable code. That’s exciting and unnerving. It collapses the old rites of passage. It gives power to people who don’t speak the “sacred language” of software. And it forces a lot of engineers to ask: What am I actually doing now?

One thing that AI has helped me with is finding pesky bugs. I mainly work on numerical simulations. At one point I was stuck for almost a week trying to figure out why my simulation was acting so strange. Finally I pulled up chatgpt, put some of my files into the context and wrote a prompt explaining the strange behavior and what I thought might be happening. In a few seconds it figured out that I had improperly scaled one of my equations. It came down to a couple missing parentheses, and once I fixed it the simulation ran perfectly.

This has happened a few times where AI was easily able to see something I was overlooking. Am I a 10x developer now that I use AI? No... but when used well, AI can have a hugely positive impact on what I am able to get done.

What I've seen with AI is that it does not save my coworkers from the pain of overcomplicating simple things that they don't really think through clearly. AI does not seem to solve this.

Most of the AI productivity stories I hear sound like they're optimizing for the wrong metric. Writing code faster doesn't necessarily mean shipping better products faster. In my experience, the bottleneck is rarely "how quickly can we type characters into an editor" - it's usually clarity around requirements, decision-making overhead, or technical debt from the last time someone optimized for speed over maintainability.

The author mentions that real 10x engineers prevent unnecessary work rather than just code faster. That rings true to me. I've seen more productivity gains from saying "no" to features or talking teams out of premature microservices(or adopting Kafka :D) than from any coding tool.

What worries me more is the team dynamic this creates. When half your engineers feel like they're supposed to be 10x more productive and aren't, that's a morale problem that compounds. The engineers who are getting solid 20-30% gains from AI (which seems realistic) start questioning if they're doing it wrong.

Has anyone actually measured this stuff properly in a production environment with consistent teams over 6+ months? Most of the data I see is either anecdotal or from artificial coding challenges.

That aside: I still think complaining about "hallucination" is a pretty big "tell".

Plus there are use-cases for LLMs that go beyond augmenting your ability to produce code, especially for learning new technologies. The yield depends on the distribution of tasks you have in your role. For example, if you are in lots of meetings, or have lots of administrative overhead to push code, LLMs will help less. (Although I think applying LLMs to pull request workflow, commit cleanup and reordering, will come soon).

So it's not like I'm delivering features in one day that would have taken two weeks. But I am delivering features in two weeks that have a bunch of extra niceties attached to them. Reality being what it is, we often release things before they are perfect. Now things are a bit closer to perfect when they are released.

I hope some of that extra work that's done reduces future bug-finding sessions.

Now let's say you use Claude code, or whatever, and you're able to create the same web app over a weekend. You spend 6 hours a day on Saturday and Sunday, in total 12 hours.

That's 10x increase in productivity right there. Did it make you a 10x better programmer? Nope, probably not. But your productivity went up by a tenfold.

And at least to me, that's sort of how it has worked. Things I didn't have motivation or energy to get into before, I can get into over a weekend.

Overall it feels negligible too me in its current state.

It's not a ground-breaking app, its CRUD and background jobs and CSV/XLSX exports and reporting, but I found that I was able to "wireframe" with real code and thus come up with unanswered questions, new requirements, etc. extremely early in the project.

Does that make me a 10x engineer? Idk. If I wasn't confident working with CC, I would have pushed back on the project in the first place unless management was willing to devote significant resources to this. I.e. "is this really a P1 project or just a nice to have?" If these tools didn't exist I would have written spec's and excalidraw or Sketch/Figma wireframes that would have taken me at least the same amount of time or more, but there'd be less functional code for my team to use as a resource.

1. googling stuff about how APIs work 2. writing boilerplate 3. typing syntax correctly

These three things combined make up a huge amount of programming. But when real cognition is required I find I'm still thinking just as hard in basically the same ways I've always thought about programming: identifying appropriate abstractions, minimizing dependencies between things, pulling pieces together towards a long term goal. As far as I can tell, AI still isn't really capable of helping much with this. It can even get in the way, because writing a lot of code before key abstractions are clearly understood can be counterproductive and AI tends to have a monolithic rather than decoupled understanding of how to program. But if you use it right it can make certain tasks less boring and maybe a little faster.

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 :)]

It's like discussing in a gaming guild how to reach the next level. It isn't real.

What makes an excellent engineer is risk mitigation and designing systems under a variety of possible constraints. This design is performed using models of the domains involved and understanding when and where these models hold and where they break down. There's no "10x". There is just being accountable for designing excellent systems to perform as desired.

If there were a "10x" software engineer, such an engineer would prevent data breaches from occurring, which is a common failure mode in software to the detriment of society. I want to see 10x less of that.

1. Tech Company's should be able to accelerate and supplant the FAANGs of this world. Like even if 10x was discounted to 5x. It would mean that 10 human years of work would be shrunk down to 2 to make multi-billion dollar companies. This is not happening right now. If this does not start happening with the current series of model, murphy's law (e.g. interest rate spike at some point) or just damn show me the money brutal questions would tell people if it is "working".

2. I think Anthropic's honcho did a back of the envelope number of 600$ for every human in the US(I think just it was just the US) was necessary to justify Nvidia's market Cap. This should play out by the end of this year or in Q3 report.

Then it came time to make a change to one of the charts. Team members were asking me questions about it. "How can we make this axis display only for existing data rather than range?" I'm scrolling through code in a screenshare that I absolutely reviewed, I remember doing it, I remember clicking the green arrow in Cursor, but I'm panicking because this doesn't look like code I've ever seen, and I'm seeing gaping mistakes and stupid patterns and a ton of duplicated code. Yeah I reviewed it, but bit by bit, never really all at once. I'd never grocked the entire file. They're asking me questions to which I don't have answers, for code "I'd just written." Man it was embarrassing!

And then to make the change, the AI completely failed at it. Plotly.js's type definitions are super out of date and the Python library is more fleshed out, so the AI started hallucinating things that exist on Python and not in JS - so now I gotta head to the docs anyway. I had to get much more manual, and the autocomplete of cursor was nice while doing so, but sometimes I'd spend more time tab/backspacing after realizing the thing it recommended was actually wrong, than I'd have spent just quickly typing the entire whatever thing.

And just like a hit, now I'm chasing the dragon. I'd love to get that feeling back of entering a new era of programming, where I'm hugely augmented. I'm trying out all the different AI tools, and desperately wishing there was an autocomplete as fast and multi-line and as good as jumping around as Cursor, available in nvim. But they all let me down. Now that I'm paying more attention, I'm realizing the code really isn't good at all. I think it's still very useful to have Claude generate a lot of boilerplate, or come in and make some tedious changes for me, or just write all my tests, but beyond that, I don't know. I think it's improved my productivity maybe 20%, all things considered. Still amazing! I just wish it was good as I thought it was when I first tried it.

So true, a lot of value and gains are had when tech leads can effectively negotiate and creatively offer less costly solutions to all aspects of a feature.

With enough rules and good prompting this is not true. The code I generate is usually better than what I'd do by hand.

The reason the code is better all the extra polish and gold plating is essentially free.

Everything I generate comes out commented great error handling, logging, SOLID, and united tested using established patterns in the code base.

I believe his original thesis remains true: "There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity."

Over the years this has been misrepresented or misinterpreted to suggest it's false but it sure feels like "Agentic Coding" is a single development promising a massive multiplier in improvement that once again is, another accidental tool that can be helpful but is definitely not a silver bullet.

Here's what the 5x to 10x flow looks like:

1. Plan out the tasks (maybe with the help of AI)

2. Open a Git worktree, launch Claude Code in the worktree, give it the task, let it work. It gets instructions to push to a Github pull request when it's done. Claude gets to work. It has access to a whole bunch of local tools, test suites, and lots of documentation.

3. While that terminal is running, I go start more tasks. Ideally there are 3 to 5 tasks running at a time.

4. Periodically check on the tabs to make sure they're not stuck or lost their minds.

5. Finally, review the finished pull requests and merge them when they are ready. If they have issues then go back to the related chat and tell it to work on it some more.

With that flow it's reasonable to merge 10 to 20 pull requests every day. I'm sure someone will respond "oh just because there are a lot of pull requests, doesn't mean you are productive!" I don't know how to prove to you that the PRs are productive other than just say that they are each basically equivalent to what one human does in one small PR.

A few notes about the flow:

- For the AI to work independently, it really needs tasks that are easy to medium difficulty. There are definitely 'hard' tasks that need a lot of human attention in order to get done successfully.

- This does take a lot of initial investment in tooling and documentation. Basically every "best practice" or code pattern that you want to use use in the project must be written down. And the tests must be as extensive as possible.

Anyway the linked article talks about the time it takes to review pull requests. I don't think it needs to take that long, because you can automate a lot..

- Code style issues are fully automated by the linter.

- Other checks like unit test coverage can be checked in the PR as well.

- When you have a ton of automated tests that are checked in the PR, that also reduces how much you need to worry about as a code reviewer.

With all those checks in place, I think it can pretty fast to review a PR. As the human you just need to scan for really bad code patterns, and maybe zoom in on highly critical areas, but most of the code can be eyeballed pretty quickly.

In some cases, LLMs can be a real speed boost. Most of the time, that has to do with writing boilerplate and prototyping a new "thing" I want to try out.

Inevitably, if I like the prototype, I end up re-writing large swaths of it to make it even half way productizable. Fundamentally, LLMs are bad at keeping an end goal in mind while working on a specific feature and it's terrible at holding enough context to avoid code duplication and spaghetti.

I'd like to see them get better and better, but they really are limited to whatever code they can ingest on the internet. A LOT of important code is just not open for consumption in sufficient quantities for it to learn. For this reason, I suspect LLMs will really never be all that good for non-web based engineering. Wheres all the training data gonna come from?

A lot of senior engineers in the big tech companies spend most of their time in meetings. They're still brilliant. For instance, they read papers and map out the core ideas, but they haven't been in the weeds for a long time. They don't necessarily know all the day-to-day stuff anymore.

Things like: which config service is standard now? What's the right Terraform template to use? How do I write that gnarly PromQL query? How do I spin up a new service that talks to 20 different systems? Or in general, how do I map my idea to deployable and testable code in the company's environment?

They used to have to grab a junior engineer to handle all that boilerplate and operational work. Now, they can just use an AI to bridge that gap and build it themselves.

Consider a fully loaded cost of 200k for an engineer or $16,666 per month. They only have to be >1.012x engineer for the "AI" to be worth it. Of course that $200 dollars per month is probably VC subsidized right now but there is lots of money on the table for <2x improvement.

https://arxiv.org/abs/2507.09089

Obviously it depends on what you are using the AI to do, and how good a job you do of creating/providing all the context to give it the best chance of being successful in what you are asking.

Maybe a bit like someone using a leaf blower to blow a couple of leaves back and forth across the driveway for 30 sec rather than just bending down to pick them up.... It seems people find LLMs interesting, and want to report success in using them, so they'll spend a ton of time trying over and over to tweak the context and fix up what the AI generated, then report how great it was, even though it'd have been quicker to do it themselves.

I think agentic AI may also lead to this illusion of, or reported, AI productivity ... you task an agent to do something and it goes off and 30 min later creates what you could have done in 20 min while you are chilling and talking to your workmates about how amazing this new AI is ...

What about just noticing that coworkers are repeatedly doing something that could easily be automated?

* if my Github actions ran 10x faster, so I don't start reading about "ai" on hackernews while waiting to test my deployment and not noticing the workflow was done an hour ago

* if the Google cloud console deployment page had 1 instead of 10 vertical scroll bars and wasn't so slow and janky in Firefox

* if people started answering my peculiar but well-researched stackoverflow questions instead of nitpicking and discussing whether they belong on superuser vs unix vs ubuntu vs hermeneutics vs serverfault

* if MS Teams died

anyway, nice to see others having the same feeling about llm's

Linear was a very early-stage product I tested a few months after their launch where I was genuinely blown away by the polish and experience relative to their team size. That was in 2020, pre-LLMs.

I have yet to see an equally polished and impressive early-stage product in the past few years, despite claims of 10x productivity.

While Gemini performed well in tweaking visualizations (it even understood the output of matplotlib) and responding to direct prompts, it struggled with debugging and multi-step refactorings, occasionally failing with generic error messages. My takeaway is that these tools are incredibly productive for greenfield coding with minimal constraints, but when it comes to making code reusable or architecturally sound, they still require significant human guidance. The AI doesn’t prioritize long-term code quality unless you actively steer it in that direction.

The credit lies with a more functional style of C++ and typescript (the languages i use for hobbies and work, respectively), but claude has sort of taken me out of the bubble I was brought up in and introduced new ideas to me.

However, I've also noticed that LLM products also tend to reinforce your biases. If you dont ask it to critique you or push back, it often tells you what a great job you did and how incredible your code is. You see this with people who have gotten into a kind of psychotic feedback loop with ChatGPT and who now believe they can escape the matrix.

I think LLMs are powerful, but only for a handful of use cases. I think the majority of what theyre marketed for right now is techno-solutionism and theres an impending collapse in VC funding for companies that are plugging in chatgpt APIs for everything from insurance claims to medical advice

For Terraform, specifically, Claude 4 can get thrown into infinite recursive loops trying to solve certain issues within the bounds of the language. Claude still tries to add completely invalid procedures into things like templates.

It does seem to work a bit better for standard application programming tasks.

Context: EACL is an embedded ReBAC authorization library based on SpiceDB-compatible*, built in Clojure and backed by Datomic.

[^1]: https://github.com/theronic/eacl

- solo projects

- startups with few engineers doing very little intense code review if any at all

- people who don't know how to code themselves.

Nobody else is realistically able to get 10x multipliers. But that doesn't mean you can't get a 1.5-2x multiplier. I'd say even myself at a large company that moves slow have been able to realize this type of multiplier on my work using cursor/claude code. But as mentioned in the article the real bottleneck becomes processes and reviews. These have not gotten any faster - so in real terms time to ship/deliver isn't much different than before.

The only attempt that we should make at minimizing review times is by making them higher priority than development itself. Technically this should already be the case but in my experience almost no engineer outside of really disciplined companies and not in FAANG actually makes reviews a high priority, because unfortunately code reviews are not usually part of someones performance review and slows down your own projects. And usually your project manager couldn't give two shits about someone elses work being slow.

Processes are where we can make the biggest dent. Most companies as they get large have processes that get in the way of forward velocity. AI first companies will minimize anything that slows time to ship. Companies simply utilizing AI and expecting 10x engineers without actually putting in the work to rally around AI as a first class citizen will fall behind.

Now for senior developers, AI has been tremendous. Example: I'm building a project where I hit the backend in liveview, and internally I have to make N requests to different APIs in parallel and present the results back. My initial version to test the idea had no loading state, waiting for all requests to finish before sending back.

I knew that I could use Phoenix Channels, and Elixir Tasks, and websockets to push the results as they came in. But I didn't want to write all that code. I could already taste it and explain it. Why couldn't I just snap my fingers?

Well AI did just that. I wrote what I wanted in depth, and bada bing, the solution I would have written is there.

Vibe coders are not gonna make it.

Engineers are having the time of their lives. It's freeing!

Also, one underestimated aspect is that LLMs don’t get writer’s block or get tired (so long as you can pay to keep the tokens flowing).

Also, one of the more useful benefits of coding with LLMs is that you are explicitly defining the requirements/specs in English before coding. This effectively means LLM-first code is likely written via Behavior Driven Development, so it is easier to review, troubleshoot, upgrade. This leads to lower total cost of ownership compared to code which is just cowboyed/YOLOed into existence.

Internally we expected 15%-25%. A big-3 consultancy told senior leadership "35%-50%" (and then tried to upsell an AI Adoption project). And indeed we are seeing 15%-35% depending on which part of the org you look and how you measure the gains.

https://www.businessinsider.com/ai-coding-tools-may-decrease...

Where I see major productivity gains are on small, tech debt like tasks, that I could not justify before. Things that I can start with an async agent, let sit until I’ve got some downtime on my main tasks (the ones that involve all that coordination). Then I can take the time to clean them up and shepherd them through.

The very best case of these are things where I can move a class of problem from manually verified to automatically verified as that kick starts a virtuous cycle that makes the ai system more productive.

But many of them are boring refactors that are just beyond what a traditional refactoring tool can do.

If your organization is routinely spending 3 months on a code review, it sounds like there's probably a 10 to 100x improvement you can extract from fixing your process before you even start using AI.

Basically, the ability to order my thoughts into a task list long & clear enough for the LLM to follow that I can be working on 3 or so of these in parallel, and maybe email. Any individual run may be faster or slower than I can do it manually, but critically, they take less total human time / attention. No individual technique is fundamentally tricky here, but it is still a real skill.

If you read the article, the author is simply not there, and sees what they know as only 1 weeks worth of knowledge. So for their learning rate .. maybe they need 3x longer of learning & experience?

Now I don't want to sound like a doomsayer but it appears to me that application programming and corresponding software companies are likely to disappear within the next 10 years or so. We're now in a transitional phase were companies who can afford enough AI compute time have an advantage. However, this phase won't last long.

Unless there is a principal block to further enhance AI programming, not just simple functions but whole apps can be created with a prompt. However, this is not where it is going to stop. Soon, there will be no need for apps in the traditional sense. End users will use AI to manipulate and visualize data and operating systems will integrate the AI services needed for this. "Apps" can be created on the fly and are constantly adjusted to the users' needs.

Creating apps will not remain a profitable business. If there is an app X someone likes, they can prompt their AI to create an app with the same features, but perhaps with these or those small changes, and the AI will create it for them, including thorough tests and quality assurance.

Right now, in the transitional phase, senior engineers might feel they are safe because someone has to monitor and check the AI output. But there is no reason why humans would be needed for that step in the long run. It's cheaper to have 3 AIs quality test and improve the outputs of one generating AI. I'm sure many companies are already experimenting with this, and at some point the output of such iterative design procedures will have far less bugs than any code produced by humans. Only safety critical essential features such as operating systems and banking will continue to be supervised by humans, though perhaps mostly for legal reasons.

Although I hope it's not but to me the end of software development seems a logical long-term consequence of current AI development. Perhaps I've missed something, I'd be interested in hearing from people who disagree.

It's ironic because in my great wisdom I chose to quit my day job in academia recently to fulfill my lifelong dream of bootstrapping a software company. I'll see if I can find a niche, maybe some people appreciate hand-crafted software in the future for its quirks and originality...

The key isn't how much you can speed up the scalable/parallelizable portions, it's how limited you are by the non-scalable/parallelizable aspects.

Ingesting legacy code, understanding it, looking at potential ways to rework it, and then putting in place the axioms to first work with it yourself, and then for others to join in has been able to get down from months to weeks and days.

Developing green field from scratch, statically typed languages seem to work a bit better than not.

Putting enough information around the requirements and how to structure undertake them is critical or it can turn into cowboy coding pretty easily, or default AI is leaning towards the average of it's corpus, not the best. That's where the developer comes in.

Even when you do write code, you often only care about specific aspects—you just want to automate the rest.

This is hard to reconcile with modern business models. If you tell someone that a software engineer can also design, they’ll just fire the designer and pile more work on the engineer. But it doesn’t change the underlying truth: a single engineer who can touch many parts of the software with low cognitive friction is simply a better kind of engineer.

Not my experience.

You can instruct Claude Code to respect standards and practices of your codebase.

In fact I noticed that Claude Code has forced me to make few genuinely important things like documenting more, writing more E2E tests and tracking architectural and style changes.

Not only I am forcing myself to a consistent (and well thought styling), but I also need it later to feed it to the AI itself.

Seriously, I don't want to offend no one, but if you believe that AI doesn't make you more productive you've got skill issues in adopting and using new tools at what they are good at.

I find that getting from zero to 80-90% functionality on just about anything software these days is exceedingly easy. So, I wonder if AI just rides that wave. Software development is maturing now such that making software with or without AI feels 10-100x faster. I suspect it is partially due to the profound leap that has been made with collaborative tools, compilers, languages, and open source methodology, etc..

It makes everyone “produce more code” but your worst dev producing 10X the code is not 10X more productive.

There’s also a bit of a dunning Kruger effect where the most careless people are the most likely to YOLO thousands of lines of vibecode into prod. While a more meticulous engineer might take a lot more time to read the changes, figure out where the AI is wrong, and remove unnecessary code. But the second engineer would be seen as much much less productive than the first in this case

Perfectly put. I've been using a lot of AI for shell scripting. Granted I should probably have better knowledge of shell but frankly I think it's a terrible language and only use it because it enjoys wide system support and is important for pipelining. I prefer TS (and will try to write scripts and such in it if I can) and for that I don't use AI almost at all.

Totally agree, IMO there's a lot of potential for these tools to help with code understanding and not just generation. Shameless plug for a code understanding tool we've been working on that helps with this: https://github.com/sourcebot-dev/sourcebot

Any tool can be shown to increase performance in closed conditions and within specific environments, but when you try to generalize things do not behave consistently.

Regardless, I would always argue that trying new tech / tools / workflows is always better than being stiff in your ways, regardless of the productivity results. I do like holding up on new things until things mature down a bit before trying though.

Much of production software engineering is writing boiler plate, building out test matrices and harnesses, scaffolding structure. And often, it’s for very similarly shaped problems at their core regardless of the company, organization, or product.

AI lets me get a lot of that out of the way and focus on more interesting work.

One might argue that’s a failure of tools or even my own technique. That might be true, but it doesn’t change the fact that I’m less bored than I used to be.

AI's so far haven't been able to beat that.

However I have found AI's to be great when working with unfamiliar tools. Where the effort involve in reading the docs etc. far outweigh the benefits. In my case using AI's to generate JasperReports .jrxml files made me more productive.

Actually writing software was only like 15-20% of my time though so the efficiency wins from having an LLM write the code is somewhat limited. It’s still another tool that makes me more productive but I’ve not figured out a way to really multiplicatively increase my productivity.

Exactly. I spend less than 20% of my time writing code. If LLMs 1,000,000,000-x'd my code writing, it would make me 1.25x as efficient overall, not 10x as efficient. It's all influencer hype nonsense, just like pair programming and microservices and no-code companies and blockchain.

This assumes the acceleration happens on all tasks. Amdahl's law states that the overall acceleration is constrained by the portion of the accelerated work. Probably it's just unclear if the "engineer" or "productivity" means the programming part or the overall process.

- vibe coding is fun, but not production-ready software engineering

- LLMs like CC today moderately boost your performance. A lot of attention is still needed.

- some TDD style is needed for the AI tool to converge

- based on the growth of the last few months, it is quite likely that these tools will increase IC productivity substantially

- fully autonomous agentic coding will take more time as the error rate needs to decline significantly

  The amount of product ideation, story point negotiation, bugfixing, code 
  review, waiting for deployments, testing, and QA in that go into what was 
  traditionally 3 months of work is now getting done in 7 work days? For that 
  to happen each and every one of these bottlenecks has to also seen have 10x 
  productivity gains.

The problem is...

1. there is an enormous investment in $$$ produces a too big to fail scenario where extravagant claims will be made regardless

2. leadership has made big promises around productivity and velocity for eng

the end result of this is going to be a lot of squinting at the problem, ignoring reality and declaring victory. These AI tools are very useful in automating chore and grunt tasks.

Ironically, when I listen to vinyl instead of streaming, I listen to less music.

If I'm in the zone, I will often go minutes between flipping the record or choosing another one; even though my record player is right next to me.

Or the data showing something else... possibly, a company starts telling engineers to use AI, then RIFs a huge portion, and expects the remaining engineers to pick up the slack. They now claim "we're more efficient!" when they've just asked their employees to work more weekends.

In addition to the article, I'd like to add that most DEV jobs I have been in had me coding only 50% of my time at most. The rest of the time was spent in meetings, gathering requirements and investigating Prod issues.

It is not making us 10x productive. It is making it 10x easier.

But if your system records internal state in english and generates code while handling requests, complex systems can become much simpler. You can build things that were impossible before

Any codebase that's difficult for me to read would be way too large to use an LLM on.

Interesting observation. I am inclined to agree with this myself. I'm more of a 10^0 kind of developer though.

When I use Claude Code on my personal projects, it's like it can read my mind. As if my project is coding itself. It's very succinct and consistent. I just write my prompt and then I'm just tapping the enter key; yes, yes, yes, yes.

I also used Claude Code on someone else's code and it was not the same experience. It kept trying to implement dirty hacks to fix stuff but couldn't get very far with that approach. I had to keep reminding it "Please address the root cause" or "No hacks" or "Please take a step back and think harder about this problem." There was a lot of back-and-forth where I had to ask it to undo stuff and I had to step in and manually make certain changes.

I think part of the issue is that LLMs are better at adding complexity than at removing it. When I was working on the bad codebase, the times I had to manually intervene, the solution usually involved deleting some code or CSS. Sometimes the solution was really simple and just a matter of deleting a couple of lines of CSS but it couldn't figure it out no matter how I wrote the prompt or even if I hinted at the solution; it kept trying to solve problems by adding more code on top.

LLMs make writing code quick, that's it. There's nothing more to this. LLMs aren't solutioning nor are they smart. If you know what you want to build, you can build quick. Not good, quick.

That said, if managers don't care about code quality (because customer's don't care either) then who am I to judge them. I don't care.

I'm on the edge of just blacklisting the word AI from my feed.

Because AI gets you to the next constraint even faster :)

The full year is just the more of the above.

When you're not sure if what someone says makes sense， trust common sense, your own experience, and your thinking.

You have to change the organization.

- no peer code review, u review the AI output and that’s enough

- devs need authority to change code anywhere in the company. No more team A owns service A and team B owns service B

- every dev and ops person needs to be colocated, no more waiting for timezones

- PMs and engineers are the same role now

Will it work for every company? No , if you are building a pacemaker , don’t use AI . Will things break? Yes sometimes but you can roll back.

Will things be somewhat chaotic? Yes somewhat but what did you think going 10x would feel like?

The part I disagree about: I've never worked at a company that has a 3 month cycle from code-written to code-review-complete. That sounds insane and dysfunctional. AI won't fix an organization like that

If I can write blue sky / green field, code. Brand new code in a new repo, no rules just write code, I can write tons of code. What bogs me down are things like tests. It can take more time to write tests than the code itself in my actual work project. Of course I know the tests are important and maybe the LLM can help here. I'm just saying that they slow me down. Waiting for code reviews slows me down. Again, they're super useful but coming from a place where the first 20-25 years of my career I didn't have them they are a drag on my performance. Another is just the size of the project I'm on. > 500 programmers on my current large project. Assume it's an OS. It's just hard to make progress on such a large project compared to a small one. And yet another which is part of the first, other people's code. If I write the whole thing or most of it, then I know exactly what to change. I've written features in code I know in days that someone who was not familiar with the code I believe would have taken months. But, me editing someone else's code without the entire state of the code base in my head is 10x slower.

That's a long way of saying, many 10xers might just be in the right circumstance to provide 10x. You're then compared against them but you're not in the same circumstance so you get different results.

My use case is not for a 10x engineer but instead for *cognitive load sharing*. I use AI in a "non-linear" fashion. Do you? Here is what that means:

1. Brainstorm an idea and write down detailed enough plan. Like tell me how I might implement something or here is what I am thinking can you critique and compare it with other approaches. Then I quickly meet with 2 more devs and make a design decision for which one to use.

2. Start manual coding and let AI "fill the gaps": Write these test for my code or follow this already existing API and create the routes from this new spec. This is non-linear because I would complete 50-75% of the feature and let the rest be completed by AI.

3. I am tired and about to end my shift and there is this last bug, I go read the docs but I also ask AI to read my screen and come up with some hypothesis to come up with. I decide which hypothesis are most promising after some reading and then ask the AI to just test that(not fix it on auto mode).

4. Voice mode: I have a shortcut that triggers claude code and uses it like a quick "lookup/search" in my code base. This avoids context switching.

For newer languages, packages, and hardware-specific code, I have yet to use a single frontier model that has not slowed me down by 50%. It is clear to me that LLMs are regurgitating machines, and no amount of thinking will save the fact that the transformer architecture (all ML really) poorly extrapolates beyond what is in the training canon.

However, on zero-to-one projects that are unconstrained by my mag-seven employer, I am absolutely 10x faster. I can churn through boilerplate code, have faster iterations across system design, and generally move extremely fast. I don't use agentic coding tools as I have had bad experiences in how the complexity scales, but it is clear to me that startups will be able to move at lightning pace relative to the large tech behemoths.

Where CC has excelled:

- New well-defined feature built upon existing conventions (10x+ boost)

- Performing similar mid-level changes across multiple files (10x+ boost)

- Quickly performing large refactors or architecture changes (10x+ boost)

- Performing analysis of existing codebases to help build my personal understanding (x10+ boost)

- Correctly configuring UI layouts (makes sense: this is still pattern-matching, but the required patterns can get more complex than a lot of humans can quickly intuit)

Where CC has floundered or wasted time:

- Anything involving temporal glitches in UI or logic. The feedback loop just can't be accomplished yet with normal tooling.

- Fixing state issues in general. Again, the feedback loop is too immature for CC to even understand what to fix unless your tooling or descriptive ability is stellar.

- Solving classes of smallish problems that require a lot of trial-and-error, aren't covered by automated tests, or require a steady flow of subjective feedback. Sometimes it's just not worth setting up the context for CC to succeed.

- Adhering to unusual or poorly-documented coding/architecture conventions. It's going to fight you the whole way, because it's been trained on conventional approaches.

Productivity hacks:

- These agents are automated, meaning you can literally have work being performed in parallel. Actual multitasking. This is actually more mentally exhausting, but I've seen my perceived productivity gains increase due to having 2+ projects going at once. CC may not beat a single engineer for many tasks, but it can literally do multiple things at once. I think this is where the real potential comes into play. Monitoring multiple projects and maintaining your own human mental context for each? That's a real challenge. - Invest in good context documents as early as possible, and don't hesitate to ask CC to insert new info and insights in its documents as you go. This is how you can help CC "learn" from its mistakes: document the right way and the wrong way when a mistake occurs.

Background: I'm a 16yoe senior fullstack engineer at a startup, working with React/Remix, native iOS (UIKit), native Android (Jetpack Compose), backends in TypeScript/Node, and lots of GraphQL and Postgres. I've also had success using Claude Code to generate Elixir code for my personal projects.

But is a 10x going to 100x?

> It tends to struggle with languages like Terraform

The language is called HCL (HashiCorp Configuration Language).

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.

Maybe LLMs make you 10x faster at using boilerplate-heavy things like Shadcn/ui or Tanstack.

...which is still only about half as fast as using a sane ecosystem.

IMO this is why there's so many diverging opinions about the productivity of AI tools.

but every company is going to enshittify everything they can to pidgeonhole ai use to justify the grifters costs

i look forward to years out when these companies trying to save money at any cost have to pay senior developers to rip all this garbage out

Not really? That's defining productivity as latency, but it's at least as valid to define productivity as throughput.

And then all the examples that are just about time spent waiting become irrelevant. When blocked waiting on something external, you just work on other things.

    There is no secret herbal medicine that prevents all disease sitting out in the
    open if you just follow the right Facebook groups. There is no AI coding
    revolution available if you just start vibing. You are not missing anything.
    Trust yourself. You are enough.

    Oh, and don't scroll LinkedIn. Or Twitter. Ever.

This is all you have to takeaway from this article. Social media is a cesspool of engagement farmers dropping BS takes to get you to engage out of FOMO or anger. Every time I'm on there, I am instantly reminded why I quit going there. It's not genuine and it's designed to capture your attention away from more important things.

I've been using LLMs on my own for the past few years and we just recently started our own first party model that we can now use for work. I'm starting to get into agentic actions where I can integrate with confluence, github, jira, etc. It's a learning curve for sure but I can see where it will lead to some productivity gains but the road blocks are still real, especially when working with other teams. Whether you're waiting for feedback or a ticket to be worked on, the LLM might speed run you to a solution but you better be ready with the next thing and the next thing while you're waiting.