rudiksz

"agents talking to each other"? Are you for real dude?

Claude is the Deepak Chopra of computer programming. Reviewing PR's created by it is 90% digesting the meaningless word salads in the comments, and the rest is figuring out that it has nothing to do with the code it is commenting.

AI easily generates PR's with thousands of lines. I my company there's even a directive for agents to split up their work into multiple PR's based on some arbitrary metric of files/lines changed. When one of my colleagues uses AI to "implement" something, the amount of code I need to review is much much more. If I were to do review as I am supposed to, then AI is absolutely increasing the time and effort I have to put into a change (as opposed to the person who just writes a prompts and calls it a huge productivity boost).

There's the meme in programming that goes something like this "Give a programmer two lines of code to review and he'll find 20 issues. Give a programmer 500 lines to review and he's say that it looks good". At some point you simply cannot keep pace with the amount of generated code as a human.

Claude isn't generating code that is "highly effective and usable code". I'm not your friend but I also reject your claims out of hand because I've also seen what Claude can and can't do.

AI code fixer.

"All the other work" being "fixing the code written by AI".

The whole "I can move faster" with a framework is also just an illusion that appears at the beginning of building an app. It will quickly disappear as more devs who do all have a different idea about how the framework should be used put their hands on it and as more complex code features are requested that the framework does not support.

It's mostly Go, some Python, and I'm not asking anything niche. I'm asking for basic utility functions that I could implement in 10-20 lines of code. There's something broken every single time and I spend more time debugging the generated code than actually writing it out.

I'm pretty sure everybody measures "failure rate" differently and grossly exaggerate the success rate. There's a lot of suggestions below about "tweaking", but if I have to "tweak" generated code in any way then that is a failure for me. So the failure rate of generated code is about 99%.

> "seasoned programmers are using LLMs better".

I do not remember a single instance when code provided to me by an LLM worked at all. Even if I ask something small that cand be done in 4-5 lines of code is always broken.

From a fellow "seasoned" programmer to another: how the hell do you write the prompts to get back correct working code?

As far as style is concerned:

1) try to use "for := range" loops instead of the traditional for

2) "var result [4]string" - really seems like this wants to be a struct with a couple of fields.

  type result struct {
    id    string
    name  string
    brand string
    price string
  }

Makes code more self documenting:

  result.id = product
  result.name = e.ChildText("h3 a")
  result.brand = " "
  result.price = e.ChildText("span.value")

3) you could introduce a "store" struct with fields like "separator", "name", "baseProductUrl", and a "Visit" method. This would entirely eliminate the need for lines 63-73, which are static code in a for loop and a performance/code smell.

3b) The "visitStore" method does a switch on "store", but it is in a hot loop. This is a good candidate for micro-optimisation-is-the-root-of-all-evil debates later down the road. It's better to avoid those, and there's a number of simple solutions here to prevent that "constant check" in the hot loop.

4) Using defer in for loops is always a red flag. While it is technically correct, it's very likely not what you want here. Imagine that you have 10k products to visit, for 10 stores. The file for the first store will be flushed and closed only after your main function exists (your entire program in this case). What you would want is to open a file, visit all products, flush the writes and close the file handle, and only then move on to the next store. In other words, the lines 76-98 (the body of your main for loop) should be a separate function so your "defer"s happen when a loop iteration terminates, and not when the "main" function exists.

Yes, a resourceful chess player could gain an upper hand over any opponent who might have a jeans fetish. And we can't have that, can we.

Half of the language is already non-nullable and is accomplished by allowing for zero values. Non pointer variables are guaranteed to be never nil.

What is missing is the ability to have pointer variables and have the compiler ensure that it will be never nil. I believe this was a design choice, not some technical limitation.

That's pretty much what they said. Most programmers don't work on "personal websites" at their workplace, as strange as that might sound.