Hacker News Reader

Comment by antonvs | Hacker News Reader

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.

View on HN

> 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.

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.

> 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.

What exactly is supposed to be impressive about that fragment? That it correctly used the API of some other library? I’m really not sure why this is supposed to be an example of “good” code that it produces.

As I said, that code illustrates the point I made in the other comment about being a functional pipeline, which composes pure functions. That snippet is part of a function that's only a little bigger - here's the start of it:

    fn spatial_context_cmd() -> impl Parser<char, Statement, Error = Simple<char>> + Clone {
        let group = ctx_or_expr()
            .then_ignore(just(',').padded_by(ws()))
            .then(
                spatial_expr()
                    .separated_by(just(',').padded_by(ws()))
                    .at_least(1),
            )
            .map(|(target, exprs)| SpatialGroup { target, exprs });

Combine that with the first snippet and you have the whole function. There's not a lot of room for "slop" here. A big part of that is the constraints imposed by (1) good libraries that follow functional principles, (2) a good type system, (3) a good language.

If you start removing those factors, the quality of generated programs is going to suffer as a consequence: mutable data is more difficult to reason about, and weak or nonexistent types make it harder to recover semantics from source code and easier for runtime errors to occur. A good type system forces a model to get things right before the program will even compile.

I've seen this because, working in ML, I'm forced to generate Python sometimes, and you can definitely see the difference.

You can even generate a diagram from this code. The code above produces this diagram: https://pxdrop.online/i/dbjcbkq81qec73aqu5fg

All the points I've mentioned make it easy to review and to be sure that the code is correct - along with our existing tests, and new tests written by the model.

> What exactly is supposed to be impressive

I didn't say it was "impressive". I said "...pretty high quality. [...] Most functions were pretty short and well factored." The above is certainly an example of that. In my initial review I didn't see anything that I would qualify as "slop" - quite the contrary.

But it actually is impressive that models are capable of this. It's certainly above average code when compared to average human developers.

I'll close with a quote from Ghost in the Shell:

> "All things change in a dynamic environment. Your effort to remain what you are is what limits you."

It's of course very subjective, but I find that code terrible to read. But you would hate what I would turn it into just as much and more (I would get rid of all the chaining and indent conditionals, cmd_kw should be command_keyword, ws() would be constant or a really long function name, etc.)

Reply on news.ycombinator.com