Things that helped me get out of the AI 10x engineer imposter syndrome • Hacker News Board

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

#211

Post by necovek » Tue, Aug 05, 2025, 3:43 PM UTC

AdrianB1 wrote: post #181

Glyptodon wrote: post #143

I don't consider myself a 10x engineer. The number one thing that I've realized makes me more productive than other engineers at my company is thinking through system design and business needs with patterns that don't take badly written product tickets literally. 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. A…

I don't consider myself a 2x engineer; my company tells me that by not paying me 2x vs my colleagues, even if I know (and others believe that too) I deliver more than 2x their output. Using AI will change nothing in this context.

The first red flag there is "2x their output". You can find many an anecdote where a good engineer produced better solution in fewer lines of code (or sometimes, by removing code — the holy grail).

So always aim for outcomes, not output :)

At my company, we did promote people quickly enough that they are now close to double their salaries when they started a year or so ago, due to their added value as engineers in the team. It gets tougher as they get into senior roles, but even there, there's quite a bit of room for differentiation.

Additionally, since this is a market, you should not even expect to be paid twice for 2x value provided — then it makes no difference to a company if they get two 1x engineers instead, and you are really not that special if you are double the cost. So really, the "fair" value is somewhere in between: 1.5x to equally reward both parties, or leaning one way or the other :)

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

#212

Post by alliancedamages » Tue, Aug 05, 2025, 3:43 PM UTC

dowager_dan99 wrote: post #167

I am a dinosaur but still feel strongly enough to post this PSA: please go back and read "No Silver Bullet" (and his follow up) again. You should probably schedule a re-read every 2-5 years, just to keep your sanity in these crazy, exhausting times. 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-magn…

Agreed. Here's one of many HN posts on "No Silver Bullet": https://news.ycombinator.com/item?id=32423356

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

#213

Post by j45 » Tue, Aug 05, 2025, 3:44 PM UTC

AI is making experineced developers with architecture experience quite a bit faster.

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.

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

#214

Post by j45 » Tue, Aug 05, 2025, 3:45 PM UTC

bluefirebrand wrote: post #192

mgfist wrote: post #145

Earlier quoted context omitted.

My biggest takeaway from using AI is that (1) for my day job, it doesn't make me super productive with creation, but it does help with discovery, learning, getting myself unstuck, and writing tedious code. (2) however, the biggest unlock is it makes working on side projects __immensely__ easier. Before AI I was always too tired to spend significant time on side projects. Now, I can see my ideas come to life (albeit w…

> (1) for my day job, it doesn't make me super productive with creation, but it does help with discovery, learning, getting myself unstuck, and writing tedious code I hear this take a lot but does it really make that much of an improvement over what we already had with search engines, online documentation and online Q&A sites?

Yes, it can.

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

#215

Post by simonw » Tue, Aug 05, 2025, 3:45 PM UTC

ffsm8 wrote: post #166

mavamaarten wrote: post #101

Earlier quoted context omitted.

Yeah. I just need to babysit it too much. Take copilot, it gives good suggestions and blows me away sometimes with a block of code which is exactly what I'd type. But actively letting it code (at least with gpt4.1 or gpt4o) just doesn't work well enough for me. Half of the time it doesn't even compile, and after fixing that it's just not really correctly working either. I'd expect it to work like a very junior progra…

To date, I've not been able to effectively use Copilot in any projects. The suggestions were always unusably bad. The /fix were always obviously and straight up false unless it was a super silly issue. Claude Code with Opus model on the other hand was mind-blowing to me and made me change my mind on almost everything wrt my opinion of LLMs for coding. You still need to grow the skill of how to build the context and f…

> You should expect most companies to let people go at staggering numbers, with only small amounts of highly skilled people left to administer the agents

I don't buy that. The linked article makes a solid argument for why that's not likely to happen: agentic loop coding tools like Claude Code can speed up the "writing code and getting it working" piece, but the software development lifecycle has so much other work before you get to the "and now we let Claude Code go brrrrrrr" phase.

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

#216

Post by paulhodge » Tue, Aug 05, 2025, 3:46 PM UTC

I've had days where it really does feel like 5x or 10x...

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.

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

#217

Post by bcrosby95 » Tue, Aug 05, 2025, 3:46 PM UTC

mavamaarten wrote: post #101

simonw wrote: post #77

I found myself agreeing with quite a lot of this article. 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 artic…

Yeah. I just need to babysit it too much. Take copilot, it gives good suggestions and blows me away sometimes with a block of code which is exactly what I'd type. But actively letting it code (at least with gpt4.1 or gpt4o) just doesn't work well enough for me. Half of the time it doesn't even compile, and after fixing that it's just not really correctly working either. I'd expect it to work like a very junior progra…

It codes like a junior, has the design sense of a mid, while being a savant at algorithms.

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

#218

Post by tptacek » Tue, Aug 05, 2025, 3:47 PM UTC

simonw wrote: post #209

coltonv wrote: post #124

Earlier quoted context omitted.

Perhaps that's my fault for making the title almost clickbaity. My goal was to get people who felt anxious about AI turning them into dinosaurs not feel like they are missing some secret sauce, so hopefully the reach this is getting contributes that. Again, appreciate your thoughts, I have a huge amount of respect for your work. I hope you have a good one!

If you hadn't made the title clickbaity you probably wouldn't have hit the homepage!

The term "10x" occurs 25 times in this article, including in a subhed deep into the piece.

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

#219

Post by simonw » Tue, Aug 05, 2025, 3:47 PM UTC

bluefirebrand wrote: post #192

mgfist wrote: post #145

Earlier quoted context omitted.

My biggest takeaway from using AI is that (1) for my day job, it doesn't make me super productive with creation, but it does help with discovery, learning, getting myself unstuck, and writing tedious code. (2) however, the biggest unlock is it makes working on side projects __immensely__ easier. Before AI I was always too tired to spend significant time on side projects. Now, I can see my ideas come to life (albeit w…

> (1) for my day job, it doesn't make me super productive with creation, but it does help with discovery, learning, getting myself unstuck, and writing tedious code I hear this take a lot but does it really make that much of an improvement over what we already had with search engines, online documentation and online Q&A sites?

Those things don't really help with getting unstuck, especially if the reason you are struck is that there tedious code that you anticipate writing and don't want to deal with.

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

#220

Post by j45 » Tue, Aug 05, 2025, 3:47 PM UTC

Scarblac wrote: post #85

generalizations wrote: post #66

In many ways this feels like average software engineers telling on themselves. If you know the tech you're building, and you're good at splitting up your work, then you know ahead of time where the complexity is and you can tell the AI what level of granularity to build at. AI isn't magic; there is an upper limit to the complexity of a program that e.g. Sonnet 4 can write at once. If you can grok that limit, and you…

But the hard part is figuring out the more complex parts. Getting that right is what takes the time, not typing in the more trivial parts.

It can be, but if you're familiar with what you're working with and have experience with other systems that have transferrable knowledge, again, it can be an advantage.

I was surprised with claude code I was able to get a few complex things done that I had anticipated to be a few weeks to uncover, stitch together and get moving.

Instead I pushed Claude to consistently present the correct udnerstanding of the problem, strucutre, approach to solving things, and only after that was OK, was it allowed to propose changes.

True to it's shiny things corpus, it will over complicate things because it hasn't learned that less is more. Maybe that reflects the corpus of the average code.

Looking at how folks are setting up their claude.md and agents can go a long way if you haven't had a chance yet.