Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

colton.dev

Post reply on HN
Print view View original

311–320 of 675 posts

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

#311

Post by v3xro »

jcelerier wrote: post #286
Uehreka wrote: post #273

Earlier quoted context omitted.

Totally disagree. The current state of coding AIs is “a level 2 product manager who is a world class biker balancing on a unicycle trying to explain a concept in French to a Spanish genius who is only 4 years old.” I’m not going to explain what I mean, but if you’ve used Qwen Code you understand.

Qwen Code is really not representative of the state of the art though. With the right prompt I have no problem getting Claude to output me a complete codebase (e.g. a non trivial library interfacing with multiple hardware devices) with the specs I want, in modern c++ that builds, runs, has documentation and unit tests sourced from data sheets and manufacturer specs from the go

Probably the saddest comment I've read all day. Crafting software line-by-line is the best part of programming (maybe when dealing with hardware devices you can instead rely on auto-generated code from the register/memory region descriptions).

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

#312

Post by claytongulick »

kasey_junk wrote: post #257
claytongulick wrote: post #237

Earlier quoted context omitted.

> But I’ll stand by my impression that a developer using ai tools will generate code at a perceptibly faster pace than one who isn’t. And this is the problem. Masterful developers are the ones you pay to reduce lines of code, not create them.

Every. Single. Time. You say you get productivity gains from ai tools on the internet someone will tell you that you weren’t good at your job before the ai tooling. Perhaps, start from the assumption that I have in fact spent a fair bit of time doing this job at a high level. Where does that mental exercise take you with regard to your own position on ai tools. In fact, you don’t have to assume I’m qualified to speak…

It's a commentary on one of the things I perceive as a flaw with LLMs, not you.

One of the most valuable qualities of humans is laziness.

We're constantly seeking efficiency gains, because who wants to carry buckets of water, or take laundry down to the river?

Skilled developers excel at this. They are "lazy" when they code - they plan for the future, they construct code in a way that will make their life better, and easier.

LLMs don't have this motivation. They will gleefully spit out 1000 lines of code when 10 will do.

It's a fundamental flaw.

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

#313

Post by nxpnsv »

TrackerFF wrote: post #298

Say you want to create a web app, but you don't know any web dev. You spend a couple of months reading front-end and back-end dev, incrementally create something, and after half a year you've made a web app you like. Say you spent 4 hours a day, 5 days a week, for 6 weeks, going from zero to a functional web app. So you spent 120 hours in total. Now let's say you use Claude code, or whatever, and you're able to creat…

However, in the first case you learned something which probably is useful when you want to change said app in any way or make another project...

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

#314

Post by Uehreka »

jcelerier wrote: post #286
Uehreka wrote: post #273

Earlier quoted context omitted.

Totally disagree. The current state of coding AIs is “a level 2 product manager who is a world class biker balancing on a unicycle trying to explain a concept in French to a Spanish genius who is only 4 years old.” I’m not going to explain what I mean, but if you’ve used Qwen Code you understand.

Qwen Code is really not representative of the state of the art though. With the right prompt I have no problem getting Claude to output me a complete codebase (e.g. a non trivial library interfacing with multiple hardware devices) with the specs I want, in modern c++ that builds, runs, has documentation and unit tests sourced from data sheets and manufacturer specs from the go

I was joking! Claude Code is still the best afaik, though I’d compare it more to “sending a 1440p HDR fax of your user story to a 4-armed mime whose mind is then read by a Aztec psychic who has taken just the right amount of NyQuil.”

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

#315

Post by SpaceNoodled »

oceanplexian wrote: post #241
__loam wrote: post #196

Earlier quoted context omitted.

Even saying it has a dozen PhDs belies the reality that these things have no relationship with the truth

I find statements like this kind of funny. If an AI assistant was the equivalent of “a dozen PhDs” at any of the places I’ve worked you would see an 80-95% productivity reduction by using it.

Yeah, we're only seeing a 20% reduction in productivity.

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

#316

Post by SpaceNoodled »

briangriffinfan wrote: post #221
__loam wrote: post #196

Earlier quoted context omitted.

Even saying it has a dozen PhDs belies the reality that these things have no relationship with the truth

Yes yes yes we're all aware that these are word predictors and don't actually know anything or reason. But these random dice are somehow able to give reasonably seemingly well-educated answers a majority of the time and the fact that these programs don't technically know anything isn't going to slow the train down any.

"Majority" may be a bit generous, and would highly depend on the context and application.

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

#317

Post by throwawaymaths »

__loam wrote: post #196
edm0nd wrote: post #175

Earlier quoted context omitted.

>I'd expect it to work like a very junior programmer, but it works like a very drunk senior programmer that isn't listening to you very well at all. This seems to be the current consensus. A very similar quote from another recent AI article: One host compares AI chatbots to “a very smart assistant who has a dozen Ph.D.s but is also high on ketamine like 30 percent of the time.” https://lithub.com/what-happened-when-i…

Even saying it has a dozen PhDs belies the reality that these things have no relationship with the truth

yes, you are overestimating phds.

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

#319

Post by RobKohr »

bilsbie wrote: post #129

I’m actually infinity more productive because I wouldn’t start projects without AI. (Just lazy and burned out from the tedium of codin g) but I’m enjoying it if the AI does a lot of the tedium.

Yep, I feel you. Let me just explain what I want in detail and one little piece at a time, and AI, make my words become code and I will watch you do it to make sure you don't mess up.

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

#320

Post by gspencley »

lordnacho wrote: post #236

I'm getting a lot of side-quest productivity out of AI. There's always a bunch of things I could do, but they are tedious. Yet they are still things I wish I could get done. Those kinds of things AI is fantastic at. Building a mock, making tests, abstracting a few things into libraries, documentation. So it's not like I'm delivering features in one day that would have taken two weeks. But I am delivering features in…

> making tests

What I'm about to discuss is about me, not you. I have no idea what kind of systems you build, what your codebase looks like, use case, business requirements etc. etc. etc. So it is possible writing tests is a great application for LLMs for you.

In my day to day work... I wish that developers where I work would stop using LLMs to write tests.

The most typical problem with LLM-generated tests on the codebase where I work is that the test code is almost extremely tightly coupled to the implementation code. Heavy use of test spies is a common anti-pattern. The result is a test suite that is testing implementation details, rather than "user-facing" behaviour (user could be a code-level consumer of the thing you are testing).

The problem with that type of a test is that is a fragile test. One of the key benefits of automated tests is that they give you a safety net to refactor implementation to your heart's content without fear of having broken something. If you change an implementation detail, and the "user-facing" behaviour does not change, your tests should pass. When tests are tightly coupled to implementation, they will fail and now your tests, in the worst of cases, might actually be creating negative value for you ... since you every code change now requires you to keep tests up to date even when what you actually care about testing "is this thing working correctly?" hasn't changed.

The root of this problem isn't even the LLM, it's just that the LLM makes it a million times worse. Developers often feel like writing tests are a menial chore that needs to be done after the fact to satisfy code coverage policy. Few developers, at many organizations, have ever truly worked TDD or learned testing best practices, how to write easy to test implementation code etc.

Post reply on HN