← Back to context

Comment by antonvs

11 hours ago

You want them to make code more simple and elegant by themselves, no other direction? "Make this code simple and elegant, no mistakes, no hallucinations"? I don't think that's realistic at the moment.

But with suitable direction, they can definitely improve codebases - especially a typical enterprise codebase, which, if you don't like LLM code, you would hate with a passion. (I can only assume you've never seen such code otherwise your perspective would be different.)

> Fully leaning into LLM doing as much of the coding and understanding as can be handed off to them seems insane to me, I don't mean this to offend though.

I essentially agree, but there's a huge spectrum before you get to that point, and lots of ways to use it effectively that doesn't create tech debt.

3 comments

antonvs

Reply
skydhash  9 hours ago

> You want them to make code more simple and elegant by themselves, no other direction?

No, he wants a project where AI is used as a major help, but the result tend towards good code, i.e readable and well abstracted. Even if the cost is high, just an example where you can extract the best practices of using AI coding.

  • what  7 hours ago

    You are responding to someone that just today generated thousands of lines of code, claims to have reviewed it all, thought it was good and only wanted one minor change. Surely they have an example of the good code it produces.

    • antonvs  2 hours ago

      > claims to have reviewed it all

      I specifically wrote an "initial review".

      The code in question was split into modules, the largest of which was about 500 lines. Overall, the quality was higher than a lot of unaided human code that I've reviewed.

      That code is greenfield code, so doesn't fit what was being requested above. But here's an example that illustrates the point I mentioned about functional pipelines:

          cmd_kw("spatial_context")
        .or(cmd_kw("spatial"))
        .padded_by(ws())
        .then_ignore(just('(').padded_by(ws()))
        .then(group.separated_by(just('|').padded_by(ws())).at_least(1))
        .then_ignore(just(')').padded_by(ws()))
        .map(|((), groups)| Statement::SpatialContext(groups))
        .labelled("spatial_context command")
        .boxed()

      This particular fragment is parsing input using the Chumsky parser combinator library. That imposes a structure that has to be followed. It's all heavily type-driven, which means that it's naturally structured as type cases, where each case handler is pretty small. The longest one in this code is around 20 lines, but most are more like 5 lines or so.

      As a result, the modules, functions, and case handlers naturally follow the single responsibility principle. This makes it easy to review. Again, this goes to the points I made in my other comment - if you give a model a good type schema, have it use good libraries in a good language, so that it has a well-structured framework in which to operate, you're likely to get good results.

      Perhaps a simpler way to describe it is the old saying, "garbage in, garbage out". If you're vibe coding, say, PHP you're much less likely to get the same quality results.