Item — HN Reader

This roughly mirrors my experience so far. Mind you I'm an extremely qualified engineer who has worked at FAANG.

Except I'd add that as one gets experience working with the AI I can only assume they'd get much better at making it go smoothly. For example, I wouldn't manually rewrite localhost, I'd tell the AI "Why is localhost everywhere? Will this worker if I deploy to a droplet?" and it will fix it for you.

Also I just paste error-messages directly into the AI and it usually knows how to fix them.

Sometimes it's net positive, sometimes it's net-negative due to creating a mess that's really hard to get out of or debug. But I imagine it's only a matter of time until the scopes in which it's cost-effective go up.

I don't like that AI is a threat of huge monopolistic and job-reducing potential, but I don't think downplaying it is a long-term strategy to combat that.

2 comments

> For example, I wouldn't manually rewrite localhost, I'd tell the AI "Why is localhost everywhere? Will this worker if I deploy to a droplet?" and it will fix it for you.

The solution is multi occur (emacs), quickfix list (vim), or any editors that have whole project find and replace.

Which will also be much faster because you don't have to worry about sanitizing your code before sending it to an LLM or that the LLM made a mistake somewhere along the way.

> I'm an extremely qualified engineer who has worked at FAANG.

> I just paste error-messages directly into the AI

...

I find it funny that commenters on HN actually think their having past or current experience working at a FAANG is some sort of signal for two reasons.

On HN especially, that’s really nothing novel, many of us have (including me) and the only thing that it takes to get into one as a software engineer is memorizing the solution to coding problems.

When I’m hiring - mostly for green field initiatives - coming from BigTech is usually a negative signal for me.

I'm not sure what your point is here...

Where the author went wrong in this post is that he tried to interpret an error ("I was asking claude to solve the wrong problem"), was wrong, and then wasted a lot of his own time.

I really think it's best practice when describing a problem to anybody that you start with what you observe and then if you want to hint your suspicions you call those out afterward as such. If you're very confident the LLM is going down a wrong path, you can ask it things like "How would I test the theory that environment variables aren't set in my docker container?"