> Most bugs won’t be “coding” bugs. They’ll be “you asked for the wrong thing” bugs.
that was pretty much what coding bugs were already. Type systems and compilers sorted the other kind already. Unit tests and code review the rest
> Tokens are the new computing paradigm. Everything will be re-made on top of it.
what?
> In 99% of software it does not matter that you could’ve written a faster algorithm
a 0.5 second delay makes a huge difference. So does 0.1. Try setting animation speed to slow on your phone... You'll be tearing your hair out immediately.
you speak as though performance can be sorted out after you have users. Performance is extremely often a huge barrier to getting any in the first place. Jim from hyderabad doesnt care that it works on your iphone 18, hes using your software over a 3g internet connection.
Sure if you specifically prompt agents about such concerns, and specifically tell them that they need to make before and after timing tests, they will do things. Maybe even passable things. But my PM isn't going to do that.
This goes for a bunch of what coding is, professionally. My PM isn't going to ask if the fact the robot chose to use http in their prototype is a problem. They'll just deploy it right to prod.
> Models will become so fast that UI will be generated on the fly
Tells me this author is a bit, uh, disconnected from the real world. Your time to UI being populated and the UI's familiarity are the product.
I'm working on a huge vibe coded app in Rust rn, but it's entire purpose in existence is to be way, way faster to open and use than the software it competes with. The difference in feeling of something that opens and is usable within ~10ms (so under 1 frame at 60Hz) compared to one that's 100ms or 1s is HUGE. Getting it to be fast, good UI isn't a single prompt, it's a huge amount of refinement, over many weeks.
The difference between software with very straight forward keyboard shortcuts and intuitive UI, guided and crafted for a human, is huge.
Right now, models particularly struggle to make good UI, because it's a human problem. It doesn't care how big text is, because it's reading HTML, not visually looking at the page. Even if you feedback loop it image processing, it's a long ways from making good UI, especially good UI 1-shot. Even if you assume this makes leaps and bounds AND that "frameworks" that make the UI share common design language across on-the-fly prompts AND that it caches UI's that the user likes, etc. etc. I think this is incredibly far off base.
Then there's the missing points of software not being all basic tools that the end goal is to make a SAAS for. Embeded software exists. We're a long way from it being smart enough to figure out when something is a hardware issue. Hardware harness that connect it every test point are ungodly expensive, and so will continue to need a human in the loop for the foreseeable future.
Or, to pick on different points
> Code review will die. [...] Unit tests might die too
Alright, but then you're first up to use the AI vibe-coded pacemaker, or large machinery, or medical diagnostic hardware, or car.
To quote Doctorow,
> There are no cars, only computers we sit in. There are no hearing aids, only computers we put in our ears. There are no 3D printers, only computers that drive peripherals.
I do think AI will change software development, but not everything, not universally, and not without consequence to quality that we'll have to learn the hard way.
2 comments
[ 0.37 ms ] story [ 15.7 ms ] threadthat was pretty much what coding bugs were already. Type systems and compilers sorted the other kind already. Unit tests and code review the rest
> Tokens are the new computing paradigm. Everything will be re-made on top of it.
what?
> In 99% of software it does not matter that you could’ve written a faster algorithm
a 0.5 second delay makes a huge difference. So does 0.1. Try setting animation speed to slow on your phone... You'll be tearing your hair out immediately.
you speak as though performance can be sorted out after you have users. Performance is extremely often a huge barrier to getting any in the first place. Jim from hyderabad doesnt care that it works on your iphone 18, hes using your software over a 3g internet connection.
Sure if you specifically prompt agents about such concerns, and specifically tell them that they need to make before and after timing tests, they will do things. Maybe even passable things. But my PM isn't going to do that.
This goes for a bunch of what coding is, professionally. My PM isn't going to ask if the fact the robot chose to use http in their prototype is a problem. They'll just deploy it right to prod.
and
> Models will become so fast that UI will be generated on the fly
Tells me this author is a bit, uh, disconnected from the real world. Your time to UI being populated and the UI's familiarity are the product.
I'm working on a huge vibe coded app in Rust rn, but it's entire purpose in existence is to be way, way faster to open and use than the software it competes with. The difference in feeling of something that opens and is usable within ~10ms (so under 1 frame at 60Hz) compared to one that's 100ms or 1s is HUGE. Getting it to be fast, good UI isn't a single prompt, it's a huge amount of refinement, over many weeks.
The difference between software with very straight forward keyboard shortcuts and intuitive UI, guided and crafted for a human, is huge.
Right now, models particularly struggle to make good UI, because it's a human problem. It doesn't care how big text is, because it's reading HTML, not visually looking at the page. Even if you feedback loop it image processing, it's a long ways from making good UI, especially good UI 1-shot. Even if you assume this makes leaps and bounds AND that "frameworks" that make the UI share common design language across on-the-fly prompts AND that it caches UI's that the user likes, etc. etc. I think this is incredibly far off base.
Then there's the missing points of software not being all basic tools that the end goal is to make a SAAS for. Embeded software exists. We're a long way from it being smart enough to figure out when something is a hardware issue. Hardware harness that connect it every test point are ungodly expensive, and so will continue to need a human in the loop for the foreseeable future.
Or, to pick on different points
> Code review will die. [...] Unit tests might die too
Alright, but then you're first up to use the AI vibe-coded pacemaker, or large machinery, or medical diagnostic hardware, or car.
To quote Doctorow,
> There are no cars, only computers we sit in. There are no hearing aids, only computers we put in our ears. There are no 3D printers, only computers that drive peripherals.
I do think AI will change software development, but not everything, not universally, and not without consequence to quality that we'll have to learn the hard way.