158
Linux kernel czar says AI bug reports aren't slop anymore (www.theregister.com)
submitted 7 months ago by to c/technology@lemmy.world
99 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[+] -14 points 7 months ago* (10 children)

The variable you're missing is time. There was a big shift in quality by Christmas, and the latest models are much better programmers than models from one year ago. The quality is improving so fast, that most people still think of AI as a "slop generator", when it can actually write good code and find real bugs and secutity issues now.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 25 points 7 months ago (1 child)

    The other missing variable is actually knowing how to use the tools. Vibe coding still produces slop. Good AI-generated code requires understanding what you're trying to achieve and giving the AI clear context on what design paradigms to follow, what libraries to use and so on. Basically, if you know how to write good code without AI, it can help you to do so faster. If you don't, it'll help you to write slop faster. Garbage in, garbage out.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 9 points 7 months ago

    This is a good answer. AI tools won't make someone who has not yet developed programming skills into a good programmer. For someone who has a good grasp of implementation patterns and the toolkit for a given tech stack, they can speed things up by putting you into the role of a senior programmer reviewing code from multiple newbies.

    I'm finding that for it to work well, you have to split things up into very small pieces. You also have to really own your AI automation prompts and scripts. You can't just copy what some YouTuber did and expect it to work well in your environment.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 34 points 7 months ago (6 children)

    As someone who has to sift through other people's LLM code every day at my job I can confirm it has definitely not gotten better in the past three months

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 6 points 7 months ago* (last edited 7 months ago) (3 children)

    We require you to submit markdown plan before working on a feature, which must have full context, scope, implementation details. Also verification tests mardown file of happy path and critical failure modes that would affect customer, and how tests were performed. Must be checked in with the commit. More complex, large features require UML diagrams of architecture, sequences, etc. to be checked in too.

    If your plan or verification docs have wrong context, missing obvious implementation flaws, bad coupling, architecture, interfaces, boundary conditions, missing test cases, etc then PR rejected.

    Every developer's performance is judged as a systems engineer. Thoughtless features without systems docs and continued lack of improvement in your systems thinking gets you PIPed.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 10 points 7 months ago (2 children)

    That's the thing though. Even if the code is good, the plans are good, the outputs are good, etc, it still devolves into chaos after some time.

    If you use AI to generate a bunch of code you then don't internalize it as if you wrote it. You miss out on reuse patterns and implementation details which are harder to catch in review than they are in implementation. Additionally, you don't have anyone who knows the code like the back of their hand because (even if supervised) a person didn't write the code, they just looked over it for correctness, and maybe modified it a little bit.

    It's the same reason why sometimes handwritten notes can be better for learning than typed notes. Yeah one is faster, but the intentionality of slowing down and paying attention to little details goes a long way making code last longer.

    There's maybe something to be said about using LLMs as a sort of sanity check code reviewer to catch minor mistakes before passing it on to a real human for actual review, but I definitely see it as harmful for anything actually "generative"

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 7 months ago* (last edited 7 months ago)

    That's a good point. We've been using the UML diagrams as a tool to catch behavioral red flags, but the reuse and implementation details of that are left undefined.

    Maybe the answer lies in also explicitly spending a few passes focusing on code health, explainability, maintainability (while keeping brain on). This is something I go through at end and then retry verification tests, but not something we explicitly require in our process at the moment.

    But in the end you have to know what good looks like and be able to call bullshit. Hmm I guess strong first principles are still the foundation of being good at something, no matter how the tools change. And practice, feedback, and constraint exposure are what turn that into actual effectiveness.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 8 points 7 months ago

    I used to feel the same way, but I've come to realize it's slop that just looks better on the surface not slop that is actually better.

    At least it compiles most the time now. But it's never quite right... Everytime I have Claude write some section of code 6 more things spring up that need to be fixed in the new code. Never ending cycle. On the surface the code appears more readable but it's not

  • permalink
  • fedilink
  • source
  • parent