> 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.
> 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.
My PM isn't thinking about if our interface is compliant to all the standards required. They also aren't thinking about scalability.
They aren't thinking about all the platforms we deploy to, and the quirks. They aren't thinking about the cloud costs, or any other costs we might employ. They aren't thinking about if the amount of network traffic their prototype is generating could be a problem for the services it talks to.
and to be fair to my pm, if I asked the LLM for what I wanted to use, it probably would be a niche product, and certainly not incorporate what the sales team needs to sell the latvian government on the next big deal.
You need specialists. "Taste" exists in the domain of technical decisions as well.
Some people think we will escape this with a massive long prompt telling an agent to call a bunch of subagents to think about all of this, and it will be instant and remember it all perfectly. That you can have a "dark factory" software company run entirely by agents (or more specifically, a company run entirely by agents apart from whatever their own job role is because of course they will be necessary unlike all the other people doing presumably very easy jobs I wont check)
Maybe it will, maybe it won't. Such things certainly don't work right now. They just can't contain enough context at once to do this (and much of the context is not digitalised in a high enough quality way i.e. without contradictions and errors). If we have a revolution where we get 100x context window or something we can come back to this conversation
> In 99% of software it does not matter
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.
> 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.
My PM isn't thinking about if our interface is compliant to all the standards required. They also aren't thinking about scalability.
They aren't thinking about all the platforms we deploy to, and the quirks. They aren't thinking about the cloud costs, or any other costs we might employ. They aren't thinking about if the amount of network traffic their prototype is generating could be a problem for the services it talks to.
and to be fair to my pm, if I asked the LLM for what I wanted to use, it probably would be a niche product, and certainly not incorporate what the sales team needs to sell the latvian government on the next big deal.
You need specialists. "Taste" exists in the domain of technical decisions as well.
Some people think we will escape this with a massive long prompt telling an agent to call a bunch of subagents to think about all of this, and it will be instant and remember it all perfectly. That you can have a "dark factory" software company run entirely by agents (or more specifically, a company run entirely by agents apart from whatever their own job role is because of course they will be necessary unlike all the other people doing presumably very easy jobs I wont check)
Maybe it will, maybe it won't. Such things certainly don't work right now. They just can't contain enough context at once to do this (and much of the context is not digitalised in a high enough quality way i.e. without contradictions and errors). If we have a revolution where we get 100x context window or something we can come back to this conversation