My issue with these kind of numbers is that they never contrasted them with a NO_LLM practice while keeping everything the same. It's always perfectly fine to YOLO generated code straight into prod, but if you handwrite it, you need to fill several forms in triplicate to even make it to the review phase. Then someone claims they are 10X-ing their productivity with AI.

> you can just ship the feature and be experimenting with customers much faster.

That's basically what I said. Instead of shipping something that have some value to the customer/user from the get go, which may takes one or two months, you spend one or two weeks on it, ship it, then frustrate your customers/users when things aren't working or keep shifting around.

For all of AI being touted as the best thing since sliced bread, there's been little to no value for humanity as a whole.

What's the current delivery rates? From my past experience, any feature can take several weeks from idea to be in a somewhat usable shape for production. While the actual coding is often less than a few days. A lot of time is spent on gathering requirements and resolving conflicts between them.

I believe most current improvement in speed is just moving from idea to demo in a few days, then spend several months fighting bugs. While the customer can't really use said feature.

Compared to the other parts. If you can do the problem solving part and the design part,code is easy. If you can't write code, I strongly doubt your ability to do the first two.

People talking good game always try to keep it high level and full of jargon. Once you ask them to explain part of the design, you'll see the inconsistency and holes of what they are saying very easily.

I've never really seen that. What I've seen is the much pragmatic take of marking the source code with a few comments to highlight the problematic areas and then goes on with the implementation. Refactoring can always be done later when the first batch of value has been extracted.

There's always tradeoffs to balance and perfection is something you inch towards, not something you get done in one go.

A good engineer, without LLM assistance, will still produce great stuff.

  select l.id, l.name 
    from locations as l 
    where l.type = 'amusement_park'
      and exists (
         select id from locations as l2
            where l2.type = 'rv_parking'
             and distance(l2.geo, l.geo) < $nearby_distance
      )

The hard job is collecting the data.

Once you start doing that, you move a ladder up in problem solving, where you solve class of problems instead of specific instances.

There can be also a configurable wait time for refreshing the screen (like top) instead of assuming 60hz

At the core, both involve the same formal thinking, but it’s easier with higher level concepts to have tangible results (it helps with the rote learning) than purely abstract ones.

I’ve met a lot of programmers where those concepts where only words and not something they have understood. A snippet of code is either something they have to learn or copy, it’s not something they can fluently manipulate. It’s the difference between having to use a dictionary and sample phrases and speaking the language fluently. The former is a chore, while you don’t even notice the latter.

The essential complexity can be easily resolved by talking to domain experts. You will get a nice requirements document afterwards. That’s when the engineering and management concerns appear.

We have even observed that the most effective LLM usage is when paired with an expert in charge of the goals. Dark factory and other automated harnesses (specs engineering and what not) seem to be a dead end. The most impactful approach to this date is an interactive conversation as a succession of small and verifiable tasks.

Strongly doubt that. Did they even share the prompt?