Live data from Hacker News

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

colton.dev

631–640 of 675 posts

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

#631

There’s something ironic here. For decades, we dreamed of semi-automating software development. CASE tools, UML, and IDEs all promised higher-level abstractions that would "let us focus on the real logic." 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 challe…

I think if you're paying any attention to the state of the world, you can see labor is getting destroyed by capital - bad wages, worse working conditions including more surveillance, metrics everywhere, immoral companies, short contracts and unstable companies/career paths, increasing monopolization and consolidation of power. We were so insulated from this for so long that it's easy to not really grasp how bad thing…

omg not everything is late stage capitalism

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

#632
post #152

Earlier quoted context omitted.

It's not magic. The techniques are well established and widely shared.

Yeah there's so many now it's hard to settle on one. YouTube is littered with them. Agent OS, amp.code, BMAD. I'm probably trying BMAD in earnest next ...

Each of the "tools" does things slightly differently but the techniques to use them effectively are largely the same now (rules, planning, context management, good prompting).

You know like when the loom came out there were probably quite a few models but using it was similar. Like cars are now.

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

#633

Earlier quoted context omitted.

Would I be crazy to say that the difference between reasoning and computation is sentience? This is an impulse with no justification but it rings true to me.

Taking a pragmatic approach, I would say that if the AI accomplishes something that, for humans, requires reasoning, then we should say that the AI is reasoning. That way we can have rational discussions about what the AI can actually do, without diverting into endless discussions about philosophy.

Eh...

Suppose A solves a problem and writes the solution down. B reads the answer and repeats it. Is B reasoning, when asked the same question? What about one that sounds similar?

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

#634

Earlier quoted context omitted.

I don't think the junior developer comparison holds up too well ... 1) The junior developer is able to learn from experience and feedback, and has a whole brain to use for this purpose. You may have to provide multiple pointers, and it may take them a while to settle into the team and get productive, but sooner or later they will get it, and at least provide a workable solution if not what you may have come up with y…

Valid points but one could argue OPUS learned by going from 4 to 4.1 today.

Yes, but pre-training of any sort is no substitute for being able to learn how to act from your own experience, such as learning on the job.

An LLM is an auto-regressive model - it is trying to predict continuations of training samples purely based on the training samples. It has no idea what were the real-world circumstances of the human who wrote a training sample when they wrote it, or what the real-world consequences were, if any, of them writing it.

For an AI to learn on the job, it would need to learn to predict it's own actions in any specific circumstance (e.g. circumstance = "I'm seeing/experiencing X, and I want to do Y"), based on it's own history of success and failure in similar circumstances... what actions led to a step towards the goal Y? It'd get feedback from the real world, same as we do, and therefore be able to update it's prediction for next time (in effect "that didn't work as expected, so next time I'll try something different", or "cool, that worked, I'll remember that for next time").

Even if a pre-trained LLM/AI did have access to what was in the mind of someone when they wrote a training sample, and what the result of this writing action was, it would not help, since the AI needs to learn how to act based on what is in it's own (ever changing) "mind", which is all it has to go on when selecting an action to take.

The feedback loop is also critical - it's no good just learning what action to take/predict (i.e what actions others took in the training set), unless you also have the feedback loop of what the outcome of that action was, and whether that matches what you predicted to happen. No amount of pre-training can remove the need for continual learning for the AI to correct it's own on-the-job mistakes, and learn from it's own experience.

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

#635
post #65

Earlier quoted context omitted.

You have misinterpreted GP's "better than what I would do" as "better than what I could do".

That would be a more plaussible explanation. Not sure if that disambiguation can be inferred from the comment though.

It’s clear from the original comment that’s what they mean. (Literally that’s what the comment says)

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

#636

Earlier quoted context omitted.

I've only used Copilot, but this is just about exactly right. (I've only used it for Python.) If I'm writing a series of very similar test cases, it's great for spamming them out quickly, but I still need to make sure they're actually right. This is easier to spot errors because I didn't type them out. It's also decent for writing various bits of boilerplate for list / dict comprehensions, log messages (although they…

things backed by Claude Sonnet can get a little further out than Copilot can, and when it’s in agent mode _sometimes_ it will do things like read the library source code to understand the API, or google for the docs but the principle is the same: if the human isn’t doing theory-building, then no one is

Exactly. I'm in a situation right now where I've inherited a bunch of systems without enough documentation, and nobody knows how some things work. Sure, we've got features to build - but one of the most important things I can possibly do is make sure someone knows how stuff works, and write it down.

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

#637

Earlier quoted context omitted.

So what happens when someone calls in and the "AI" answers (because the receptionist has been fired and replaced by "AI"), and the caller asks to access some company record that should be private? Will the LLM always deny the request? Hint: no, not always. There are so many flaws in your plan, I have no doubt that "AI" will ruin some companies that try to replace humans with a "tin can". LLMs are being inserted loose…

> Will the LLM always deny the request? Hint: no, not always. And you are confident that the human receptionist will never fall for social engineering? I don't think data protection is even close to the biggest problem with replacing all/most employees with bots.

The human receptionist can use critical thinking, and self preservation to prevent a bad outcome. The LLM can not. When a person causes a problem, they can be fired, and learn from the event. The LLM will not learn from it. And who is responsible then? The company providing the LLM? The more LLM use becomes pervasive, the taller the house of cards gets.

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

#638

Earlier quoted context omitted.

Again, as you've acknowledged, there's a whole meme structure in the industry about what a "10x" programmer is. I did not claim that LLMs turn programmers into "10x programmers", because I do not believe in "10x" programmers to begin with. I'm not being defensive, I'm rebutting a (false) factual claim. It's very clearly false; you can just read the piece and see for yourself.

> I'm not being defensive, I'm rebutting a (false) factual claim. You're rebutting a claim about your rant that -if it ever did exist- has been backed away from and disowned several times. From [0] > > Wait, now you're saying I set the 10x bar? No, I did not. > > I distinctly did not say that. I said your article was one of the ones that made me feel anxious. And it's one of the ones that spurred me to write this art…

Thanks for this. The guy really wants to pin me on the 10x thing coming from him but I keep saying it's not and he keeps ignoring me. The claims of his article are extremely plain and clear: AI-loving engineers are going "rocket fuel" fast, AI skeptical engineers are crazy (literally the title!) and are sitting still.

My post is about how those types of claims are unfounded and make people feel anxious unnecessarily. He just doesn't want to confront that he wrote an article that directly says these words and that those words have an effect. He wants to use strong language without any consequences. So he's trying to nitpick the things I say and ignore my requests for further information. It's kinda sad to watch, honestly.

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

#639
I recently experimented with Gemini on Colab for building a discrete simulation in Python—initially started with ChatGPT, then moved platforms due to free-tier limits. Gemini was responsive in analyzing graph outputs and made quick progress with rapid prototyping. However, when I shifted focus to refactoring and improving code structure, e.g., extracting classes and encapsulating behavior, it defaulted to a weird hybrid class/functional approach, often placing logic outside domain objects rather than applying polymorphism. Even after I explicitly mentioned principles like "Tell, don’t ask," I had to insist before it adjusted its design choices accordingly. I asked why those principles are NOT there by default, and it said basically most coders don't use them and it seeks direct solutions.

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.

Post reply on HN