It’s just so they can get dependencies out in the wild and then they add malicious code. This is why we should all learn to code… simply so we can stop being lazy and write our own is_even functions.

That's weird. I did some digging and can't find its name, ip, or hosting company servrex.com on any block list. I checked HaGezi on github based on your post.

Literally why. Just do what the diesel rust crate does with their macros.

(Insert LLM) creates this new library...

Brother you want feedback for an entirely llm-coded project? The first commit is 25k LoC.

Boring you say? https://youtube.com/@engineeringfun

https://youtube.com/@engineeringfun

This is just another layer of abstraction.

But it's a little different. Rigorous thinking was required to produce anything at the previous layers. This one is different. One can now produce copious amounts of slop without thinking at all.

In that way, I'd argue, slop coding is solved.

Mate, I'm watching my director and architect slack each other epics of slop trying to get our harness to accept the specs for a feature. I could've built the whole thing by now, but they don't want that, they want reproducibility and predictability. If they could just be happy with 25% productivity gains, we'd make a killing with our services contracts.

Here's the thing: these morons are never going to get what they want describing it in vague, natural language terms. The reason you're having success with AI is because you know the fundamentals of coding and you know the practicalities. You can describe in specific terms exactly what you want and how to build it. People who can't do that are never going to replace those who can.

Coding may be solved in the sense that AI has instant access to things we haven't done before or haven't touched in years. Maybe I used to do something by hand but 9 months ago spring added some annotation or library and now it's solved without those side effects or quirks our homegrown solution has.

But you still have to know what to do. You have to add this hook so you can troubleshoot issues in the future. This needs to be an interface because you know it's going to have different case implementations. This can be an enum, but that needs to be freeform text. This database needs to be normalized for cross-referencing, but that one needs to be denormalized for performance.

People who understand code can't be replaced by those who can't. This is just another layer of abstraction.

This is just playing around with word definitions. We all know what "coding is largely solved" means intuitively. No compilers and DSLs did not do that.

Coding is unfortunately largely solved. Unfortunate for my career prospects anyway. It's awesome that I can just create pretty much any tool I want in a few days. Also I'm finishing so many unfinished side projects!

But yeah, I'm pretty anxious about my job.

"This is great, this is ok, this is great." is an amazing tool. People will always focus on the negative, so presenting a negative as a positive, but juxtaposed with even better positives, shifts the scale. It makes people think about it, without being too hard on themselves. I call it the compliment sandwich.

Another tip that has served me well is the tick of approval, followed by the question "With this part, what would you do differently next time?". It frames it as self improvement feedback.

That being said, I'm not part of a traditional code review process, so this could all be totally misguided advice.

You're not going to be good at it, at first. It probably takes a good 6-12 months to do it all correctly and most developers don't actually learn how to do it all properly.

But here's my cheatsheet if you actually want to spend the time to get really good at code review. Save this comment so you can keep coming back to it.

First, you need to relearn the programming side, making code in a specific way that has the capacity to be reviewed correctly. Don't think about code made to accomplish a goal because you should already be able to do that. Instead make sure you understand what makes code easy to review by someone else.

Why: You may have been stuck in an environment where someone else was either fixing your mistakes for you (depriving you of your opportunity to get better at writing reviewable code), or you may have been in an environment where you were getting the wrong feedback.

How: Read this link: https://mtlynch.io/code-review-love, then read it again next week, and again the following week. Once you intuitively can make reviewable code, it'll be easier for you to teach others how to make reviewable code (which makes your reviews easier to perform correctly).

Second: Learn how to actually give feedback in a way that gets things fixed.

How: Read this: https://mtlynch.io/human-code-reviews-1/.

Third: Don't try to write or correct documentation before you understand the "Grand unified theory of documentation" Link: https://docs.divio.com/documentation-system/. TL;DR: Most programmers don't understand that there's actually four different types of documentation and assume that the kind that they right is what's actually needed.

That goes into technical writing, which is another skill you need to develop but makes projects better as a whole, which makes it easier to review code.

Fourth (bonus reading material): antirez (the guy who made redis) went through his whole project and did a kind of census/retrospective on all the comments inside. It sort of accidentally turned into a good practical advisory on writing comments that actually mean something. Link here: https://antirez.com/news/124

Wake me once Goofle has paid the fine and decides to stop giving AI summaries in Germany

On a single hooker on a drunken night.

They aren't in jail yet. Let's not pio the champagne early.

Looking for anti patterns and other code smells is a big part of it. One of the most overlooked pieces I see from new code reviewers is missing new code that allows documentation to go stale. Any changes to code that do not update corresponding documentation is by far one of the easiest way to cause confusion for new team members spinning up. Also, when looking at those documentation updates, verifying the code changes fit in those.

Fortunately we use formatters so I don’t have to be too Ruff with the white space lol

Wow scary fix, I'm guessing we're going to be seeing a few new patches really soon fixing bugs created by this latest version

Thanks, makes sense!

Nitpick copyright dates and white space.

Be sure to be extra shitty about it.

It's not a quick or easy fix. The patch is a 10000 line nightmare. No really it's actually 10k. A lot of that is test code, but there are also significant changes to deep engine internals.

PHP did really really bad memory limit handling. Now it's only really bad.

holy fuck

70% of websites are running PHP?

are they sure?

Am I going to find a php binary in a node_modules directory

Most of my experience with PHP is from pen testing so most of my orders look something like <?$_GET[0]?>

The type of bias described in the article (more code vulnerabilities if the prompt mentions the code is for groups not aligned with the Chinese government) does not seem like it should be so complicated to avoid.

Masochism?

Fair point. Glazed over because I didn't recognise the name. If you don't mind me asking, work or pleasure?