I like to think of it as a new abstraction layer on top of something we've been comfortable with for years. The developers of the past had to trust that human-readable code would compile to the machine-level bytecode they were used to write, and that even though it wasn't as efficient as they could make it, one day the benefits would outweigh the negatives. Today most developers don't understand compilers well enough to even begin questioning if the code doesn't work because the compiler has a bug or because their code has a bug. They have to trust the abstraction layer beneath their current domain, and they have to find ways to prove that their work is correct in that domain (e.g., writing a sufficient number of unit- and integration tests, compiling with different compilers to different targets, etc.).

We, too, have to adjust to this change, this new abstraction layer, because whether we like it or not, the code an LLM will produce in no more than five years will arguably be much, much better than the code any 10x developer could produce even if given months of time and an infinite supply of caffeine.

We "just" need to find a way to confirm that our work in this new abstraction layer - primarily prompt engineering - results in the code functionality that we had in mind, not necessarily the code implementation that we had in mind.

▲

Gareth321 29 minutes ago | parent | next [-]

I note you're downvoted but I strongly agree. Forcing humans to speak machine language is inherently inefficient. Having them speak a language we're already comfortable with is an obvious evolution in abstraction and control. I suspect you've ruffled some feathers because speaking machine language has been a knowledge and skill gate which is rapidly becoming redundant. It doesn't feel good when one's career and skillset become much less valuable. Never-the-less, this technology is not going anywhere. Opus 5.5 already codes better than most of my developers at about 100x the speed. Architecture is still valuable, but I have no doubt that this is also going to be done better by AI soon.

	▲	tremon 11 minutes ago \| parent [-]
		Human speech is inherently inefficient and ambiguous. Humans rely on non-verbal clues and context to distill the exact meaning of phrases, and even then the potential for miscommunication is non-negligible. It is a huge leap to assume that artificial intelligence can succeed in flawlessly divining intent from regular human speech to the point where it can generate debt-free code. And if your solution to that is to say "no, you need to issue specific instructions to guide the machine to the correct solution" then you have not removed the skill requirement, you have merely redefined the skillset.

▲

contravariant 2 hours ago | parent | prev [-]

I'm still unsure if we won't figure out that the right abstraction level to describe what code means is, well, code.

	▲	Izmaki an hour ago \| parent \| next [-]
		I've spend the past month-or-two on developing a platform scroller game for smartphones using nothing but AI. It has created everything given my instructions, to my liking, from the way the game is played to graphical assets to sound effects. It looks and feels like any other typical studio-developed game you could find in the store, the difference is that I didn't have a studio of professionals working fulltime for months or years with various levels of project management and what not. It's just me. Me and my agentic coding subscription. Vibe coding originally meant giving an LLM an instruction, having it regurgitate something potentially wholesome, testing it and feeding back the errors for it to fix it. What I've done in the past couple of months is so, so much more than that. I'm a puppet master and my coding agent is my puppet. I don't need to understand the code when I can describe the problem I want solved and it will do it 100x faster than I ever could. I didn't use code to describe this level of abstration. I used English prose - and a heck of a lot of software engineering theory, mind you. If you know the solution requires a quad-tree and binary search because in this case, that is the best option, then that's an instruction, not a block of code.
	▲	jimnotgym an hour ago \| parent \| prev [-]
		Is it a challenge to Agile methodologies? I mean is most software today designed at all? If we want a pm to be able to write half baked feature ideas and expect the devs to sort it out, rather than just paste the ticket into Claude, don't we make this chaos inevitable. Maybe there is a missing formal engineering layer missing between feature request and prompt. Llms seem to do much better when they are told exactly what to do, vs when they are given room to...express themselves