Writing software is an act of learning. Don’t automate it.

> Learning what though? When I wrote software I learn the domain, the problem space, the architecture, the requirements, etc

You don't learn these things by writing code? This is genuinely interesting to me because it seems that different groups of people have dramatically different ways of approaching software development

For me, the act of writing code reveals places where the problem statement was underspecifed or places where the architecture runs into a serious snag, or corner cases in the requirements. I can understand a problem space at a high level based on problem statements and UML diagrams, but I can only truly grok it by writing code.

Writing the code is like writing an essay—maybe you have some ideas in your head, but the act of writing them down forces you to interrogate and organize them into something cohesive. Without that process, those ideas remain an amorphous cloud, that as far as you’re concerned, are perfect. The process of forcing those thoughts into a linear stream is what exposes the missing pieces and errors in the logic.

I use llm to generate a lot of code but a large part of what i use it for is orchestration, testing, validation. that's not always 'learning', and by the way, i learn by watching the llm decide and execute, as it draws from knowledge pools faster than me.

Does the editorialized title contradict with the article?

Spoken like a true CEO. LLMs makes everyone feel like CEOs. Imagine a world where everyone thinks they're CEOs.

> There are parts of software development, which requires understanding purpose and code and making good decisions or having in depth understanding to ootikize. And there are parts where it's just boring ceremony for using a library or doing some refactorings.

I feel like maybe I'm preaching to the choir by saying this on HN, but this is what Paul Graham means when he says that languages should be as concise as possible, in terms of number of elements required. He means that the only thing the language should require you to write is what's strictly necessary to describe what you want.

The most critical skill in the coming era, assuming that AI follows its current trajectory and there are no research breakthroughs for e.g. continual learning is going to be delegation.

The art of knowing what work to keep, what work to toss to the bot, and how to verify it has actually completed the task to a satisfactory level.

It'll be different than delegating to a human; as the technology currently sits, there is no point giving out "learning tasks". I also imagine it'll be a good idea to keep enough tasks to keep your own skills sharp, so if anything kinda the reverse.

It was drag and drop before we decided websites should work on different screen sizes. And that it should adapt to every size more elegantly than a word document randomly changing layout when things move.

HTML is a good enough way of representing a superset of different layout types. It seems display: grid does most of the 2d constraint things that people always used to talk about. I don't know the state of the art for drag-drop grid layout builders, but it seems possible that one could be built.

I mostly agree. I think it isn't drag and drop because it's surprisingly hard to make a GUI builder interface that doesn't suck balls. Some manage it though, like QtCreator.

I guess there is stuff like SquareSpace. No idea how good it is though. And FrontPage back in the day but that sucked.

I often hear this, and to an extent I don't disagree. There is an absurd amount of complexity that goes behind CSS/JS/HTML to make it function how it does. Browsers are true monstrosities.

But what alternatives are really left behind here that you view as superior?

To me, it is obvious the entire world sees a very high value in how much power can be delivered in a tiny payload via networked JS powering an HTML/CSS app. Are there really other things that can be viewed as equally powerful to HTML which are also able to pack such an information dense punch?

The problem with drag drop frontend is the code generators that support that end up tightly coupling the document with the code, which doesn't lead to good testability and scalability. I'm optimistic that LLMs could accomplish a visual design paradigm while still designing the code in good taste, but so far I'm not holding my breath.

> I think I get what Mr. Fowler is saying

Martin Fowler isn't the author, though. The author is Unmesh Joshi.

Tech bros here could see that their tech is being used to round up people for camps or blow up children and somehow tell themselves they are doing the right thing.