ironically, AI is also making us create a new whole new level of technical debt - where _no one_ has actual understanding of the code being written and we're just trusting the machine

▲

bemtevi an hour ago | parent | next [-]

Indeed, and it's just going to end up as a zero-sum game where the winner is the one who can most adeptly manipulate the machine to cause harm to the other.

▲

Izmaki an hour ago | parent [-]

This is exactly what has happened the past 50+ years, too, your toolbox was just different in the 90's than it is today.

▲

bemtevi an hour ago | parent [-]

So if it has happened, should we now proceed with even more powerful and dangerous tools, with a much tighter integration with society?

▲

Izmaki 39 minutes ago | parent [-]

Is a nuclear power plant dangerous? Or an airplane? Both are examples of an advanced form of what other entities in their category do.

Of course we should proceed with even more powerful tools. We also need even stronger governance of said tools. We don't want an AI-version of the Chernobyl incident but we do want the AI-version of the benefits that nuclear power gives.

	▲	lirolero 33 minutes ago \| parent [-]
		[dead]

▲

Izmaki an hour ago | parent | prev [-]

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.

▲

contravariant an hour ago | parent [-]

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

	▲	Izmaki 43 minutes 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 43 minutes 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