4 ms·
> I think the entire definition of technical debt has changed. I’ve been sceptical of these tools and still approach their output with caution. This very well
by phil21 4mo ago
> I think the entire definition of technical debt has changed. I’ve been sceptical of these tools and still approach their output with caution.
This very well summarizes my current thinking on the subject as well. And most of my career has been playing the role of technical debt nazi. Much to the detriment of my earning potential.
Does AI make incredibly inefficient code most of the time? Yup. But it does it at lightspeed with minimal effort.
I think many software engineers forget they exist to get real things done (in many cases at least) and they are a cost center for most businesses. If your end product is not selling software, very few people actually Doing the Thing(tm) will give a single solitary care about code quality or maintainability when they can just spend 30 minutes and $15 worth of tokens to fix it.
It won't take over everything, but I've already seen otherwise very intelligent go-getter type folks who are not technical or know how to code made extremely useful things for themselves and their small little enterprises. And this will seemingly only get better and more efficient.
For someone who really does love the idea of well architected and future-proof code this is just icky to even say or consider. But I'm coming around to this is the future for the majority of software for most places. And it may have the ability to seriously even the playing field for small enterprises in some industries.
I'm currently using it to implement a zillion side projects at home I've been "meaning to get to" for years. It makes incredibly silly unmaintainable code most of the time - but I learned to not care, and just tell the AI bot to fix it/add to it as I go along. Worst-case I spend a single night deleting it all and starting from zero to "refactor" an entire thing.
- prmoustache 4mo ago> I think many software engineers forget they exist to get real things done (in many cases at least) and they are a cost center for most businesses. If your end product is not selling software, very few people actually Doing the Thing(tm) will give a single solitary care about code quality or maintainability when they can just spend 30 minutes and $15 worth of tokens to fix it. I am suprised to hear people so naive they expect their token usage to stay flat if code quality and maintainability starts falling exponentially? What if to fix 2 bugs your LLM starts adding 50 new ones? Will you tell your customers in supports channel "sorry software is finished, if we try fixing anything, everything else might break, not worth it". Or "we can probably fix it, but our AI usage will raise so much we need to up the subscription 3 fold, you choose". The speed at which LLM codes is only comparable to the speed at which they add garbage to your repo. If you stop caring about maintainability, you also stops caring about your AI/LLM related bills and the viability of your project past the PoC stage.
- varjag 4mo agoThe GP explicitly mentioned "end product is not selling software". But even then, bugfixes introducing new bugs are not unheard of before. Most code used to be mediocre quality so there's not a sea of change with AI. Perhaps it even becomes better on average. Another thing though is selling software in the first place will soon become tough proposition outside of a few niches.
- senordevnyc 4mo agoI am suprised to hear people so naive they expect their token usage to stay flat if code quality and maintainability starts falling exponentially? There's no reason to think that quality and maintainability will start falling exponentially. On the contrary, these models get better every couple months, and 99% of software isn't actually that complicated. There's just no reason for the fear-mongering that fixing 2 bugs will cause the LLM to add 50 new ones.
- queenkjuul 4mo agoExcept that i witness it create new bugs while fixing existing ones? Not 50:1 but it does happen
- locknitpicker 4mo ago> Does AI make incredibly inefficient code most of the time? Yup. But it does it at lightspeed with minimal effort. This hits the nail in the head. Detractors often hang on to examples of coding assistants making mistakes or output subpar code, but they somehow miss the fact that coding assistants can also be prompted again and refactor whole swaths of code just as fast as they introduce oopsies. This means that the worst case scenario implies fast convergence to an acceptable outcome, and from there also fast iteration to improve upon that.
- eithed 4mo agoDon't forget that you can adjust your requirements (either via plan or skill) to ensure the mistakes do not happen. The problem is that neither LLMs, nor humans (that don't work with the domain) will know they made these mistakes. Even coders don't think about everything all the time
- brazzy 4mo ago> Don't forget that you can adjust your requirements (either via plan or skill) to ensure the mistakes do not happen. No, you can't. Adjusting prompts ensures absolutely nothing.
- eithed 4mo agoI disagree. What I should have added is that with agents (as well as humans) you do need to have tests that verify what was done.
- brazzy 4mo agoThat assumes you can write automated tests that reliably identify the mistakes over an entire codebase. Nice idea in theory. If it were actually possible, we would long since have generalized libraries of tests to catch every significant security and performance gotcha. What we have are static code analysis tools, fuzzers, etc. None of which have come close to eliminating security and performance problems. I don't see how AI somehome changes that.
- senordevnyc 4mo agoI think many software engineers forget they exist to get real things done One billion percent. I think the vast majority of the anti-AI sentiments I hear from software engineers comes down to them caring more about playing with their tools than actually solving the problem.
- Anamon 4mo agoMany software engineers have to get things done not just once, but ensure they keep getting done, reliably. That's what 100% of vibe coders don't understand when they brag about their one-shot toy projects. The tools we "play" with, we developed and refined over decades, and we did so for good reason. They all emerged out of real problems that needed solving in the real world. Many are born out of experiences where things went terribly wrong. AI bros and execs drinking the kool aid are gleefully dismissing the warning signs of millions of experienced developers, and don't think that maybe, just maybe, their billions of hours of experience may mean they know some things they don't. The landing will be brutal, and I have my popcorn ready.