agreed. views are very similar to my talk https://youtu.be/X7vf7koPxKg

There's a lot of 'business logic / business decisions' that an AI would need to understand in order to achieve the goal of the process. I'm currently going through a deconstruction of a complex topic for which there is minimal documentation about how it should work, and so AI-help is limited to explaining what it does do.

If the information doesn't exist, then AI can't create it for you, but it can help identify the areas in which to be asking the questions; where exist the vagaries and assumptions?

This aligns with my thoughts on a recent post here about code being "clay" now (as opposed to stone, which must be chiseled with great effort, skill, and time expenditure. Clay is much easier to work with and mold to our desired shape.

My point was, you still didn't build infrastructure out of great lumps of clay. You don't slap down some clay in the middle of a stream and vibe-build a bridge. Infrastructure was still built of stone. Or, if clay, out of individual bricks.

Similarly, LLM-generated code should be used to build discrete bricks of code that can be read, tested, and most importantly, understood. Then you take those bricks and architect and engineer your application with them. This is how you build a platform that can survive actual use.

You can make a model of a bridge with the clay...but the actual bridge is an entirely different pursuit. This is a discipline we need to develop as engineers, since LLM-generated code won't go away. It can be used to make bricks faster but we have to make the engineering decisions that create reliable, secure applications.

"Programming as Theory Building" still relevant on the AI age.

https://news.ycombinator.com/item?id=10833278