> As a software developer we should fear chasing "better" solutions, that path always lead to procrastination

What a bad take. This is a discipline problem. You can chase both and be careful with the new solution.

> If you're meticulously designing and engineering it really well from the start, sure functional languages represent it well without leaving much room for misinterpretation and thus bugs. But no one does that.

I find functional programming better at iterative development. You don't have to go full on on types but you always have the choice to make it good in the future. And from my experience the final refactoring is just better and let you built way more on top than imperative languages.

The reason imperative programming is so common is because of network effect. Unix won over lisp machines

> programming is primarily problem solving

It is more than that in the sense that I have a lot of obligations to understanding the code. The reason is that if I don't understand the code, I will not be able to answer questions that are asked to me. And those answers are generally very important for the future of the business.

Code is art in the sense that I need to arrange it such as I can actually make it maintainable, readable, easy to add new features and make it that I can answers questions very easily.

LLMs remove this ability because it doesn't let me the time to absorb the change as such that I can guaranties those 4 requirements. It just concentrate on adding new features without making sure it doesn't break the other 3 requirements.

To guaranties those for 4 points, I need a mental map of the code which llm generally remove. The more we use llms, the less of a mental map you have of the code

This is a very incomplete transcript : "The complete transcript of ONE autonomous Claude sub-agent, "E2", "

And for me, it has created a giant pile of unmaintainable code from my coworkers because of stupid management people that think they can code.

Refactoring was never a substantial amounts of time for me before llms. Before I could spot a potential refactor and refactor it in 20 minutes and less. Never abandon it. Just constant improvement to the point the previous tech startup that I was working for just drive from itself (I am still paid a a few hours per months for it)

I've never met a single developer saying refactors are easy. It's always a minefield.

In the only scenario where that could actually be true you wouldn't have coworkers creating unmaintainable code with LLMs now.

> In the only scenario where that could actually be true you wouldn't have coworkers creating unmaintainable code with LLMs now.

Bingo. My highly qualified team was disbanded because the company went bankrupt. Apparently, the CEO had embezzled a large sum of money. That team was disbanded just before LLMs caught up.

The one that create unmaintainable code is a new team and the reason they are able to create such a large amount of unmaintainable code is because of llms.

> I've never met a single developer saying refactors are easy. It's always a minefield.

Pleasure to meet to you. You now know one. In the land of functional programming, refactoring is quite enjoyable and quite easy.

If you were fortunate enough to be working in a project with very good test coverage, refactors were easier (maybe not easy) in the sense that you were at least fairly confident that nothing broke.

But I've personally never worked on code with test coverage that good. Refactors were always risky.

Does that code at least come with tests?

Gotta get IT to slip superpowers or at least the TDD skill into MDM/enterprise controls

Before llms : All tests + some type theory things After llms : Just slop without tests

> Not me! I'm 100x AI engineer who will certainly remain comfy an secure. LLMs are awesome! It's all those luddite doomer jerks who cling to their old ways of understanding how things work and manual coding that are going to be poor, and they deserve it.

We will see in 5 years ! I think you highly overestimate llms

Funnily enough, the parent made the point that people probably overestimate their position in the future pecking order, and did so sarcastically, which you seemed to have completely missed (probably due to being ESL), something even a current LLM would easily "understand", thus proving his point.

I see that the fantasy world of llms is still strong

I program very often in idris2 and I cannot agree more. LLMs tend to take the least effort possible to the point where most of the time, llms are just not useful to program with dependent types. At least, not yet

Have you tried giving them the types you want and then have them auto complete? They are pretty good at a auto completing abstractions

I do but I have no guarantee that the llms will make a sane implementation of the types

You still want to write/review/refine the types yourself.

I would say that the value of dependent types in software engineering isn't in proving all code correctness. As a user pointed out in the idris2 Zulip, most programs using dependent types don't have, and shouldn't have, proof of validity for the entire program. Instead, you simply get more correct code by construction, and I think that's the whole point.

I'm currently developing a unikernel in idris2, and the experience is very pleasant (unfortunately, I'm not quite ready to share it yet).

As if programming by hand was sooooooo inconvenient