If we could get that sort of mindset into the AI-maximalists, particularly in the executive suite, we'd be so much better off.

Use the tools that are APPROPRIATE FOR THE SPECIFIC TASK. Even if that means we're not always using the shiny toy you're desperate to get metrics up on. You'd look like a putz going into a machine shop and yelling at the guy working a lathe "but we just bought this laser engraver, go use it now!" Why is it different for programmers or other creatives?

Maybe the AI vendors need to start broadening their products too-- sell a better lathe to go with the laser engraver.

There are a lot of problems where the developer knows roughly what they want in terms of code already. The labour savings is mostly "not having to type in 500 lines of code" and it's wasted if they instead have to spend the same amount of time trying to craft prompts and babysit the LLM. I think there's a lot of potential in the "spicy autocomplete" flow for that use case-- start with a few key lines and let the system use pattern recognition and templates to quickly infer the other 450, all within the workflow they're already productive in.

True, but then it begs the question: if I am a very specialized programmer, how can AI help?

AI just helps me with scaffolding and fast scripts. It does not help me at building better solutions.

It just does a better job when I do not know enough about the topic and sometimes I found it drives me the worst path.

For example, the other day I asked for "the fastest way to get a docker container with gcc15". It offered me Ubuntu + build the source via a checkout. So I suggested that it would be slow to wait to compile it (plus the problems if you do not compile with the right flags, etc.). So I suggested GUIX. I had some problems with GUIX daemon and channels, etc.

I ended up asking, after some fighting with GUIX. Maybe there is a container with gcc15? And it did exist.

So I wasted more time than if I had just found a gcc15 container myself...

There were also multiple things that could be improved, like I had to proactively ask for a non-root container, which did not give me.

So if you do not know what you want exactly, it kind of sucks and can do much better more often than not, but when you know what you are doing, just drive it a bit to scaffold but keep correcting.

All in all: I do not see how a tool like this can replace an expert that is fitting all stuff into a system that needs integration, whose software needs long-term maintenance, etc. It is not as good as advertised and anyway, when you ask something complex, it can seem to be working at first, but there is a point where it starts to make mistakes and lose additional context. Now you have a bunch of code where you understand a small part of it and have to maintain it.

I am not sure if this is good for software development at all in the sense that you are going to pay the bills in different phases of the project. It is not like you cannot do anything: it is just that the whole discipline must take into account context, maintenance and the human cognitive part (bc the human must keep understand what she is doing to be able to remain effective).

I also saw it spitting a lot, I mean, a lot of additional unnecessary code at times that just adds a ton of noise and that a professional programmer would make it much simpler (and hence, maintainable).

I still use it every day for things it does well: a bit of scaffolding here and there, an algorithm that is typical and I could clean up (depending of what I am doing), or to ask why something does not work to spot a bug or one-off scripts. To give me full solutions.... no, it actually sucks at that in a way that is not that obvious to people that did not work at it for some time and know the potential problems you will find down the road if you abuse it.

It is also quite ok at code reviews for pieces of code.