Comment by what

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

1 comment

what

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