I actually think it would go entirely different way, since more and more 'ordinary' users would delegate whatever they need to use app for to 'their' agent instead of using app directly.
Agents have infinite patience, and they would go churn through most horrible buggy UIs out there to eventually achieve the goal, which is even more ironic, given that those UIs would be done by same agents in the first place.
I think AX is just as important in that case though, as even a patient agent will make mistakes and will have a lot more trouble getting things done right when using a buggy app.
There's an opportunity here to bend things towards quality and efficiency moreso than mere volume of code. The agent has to be able to effectively repair and maintain what it has been building though.
Here is my crazy list of ideas for less buggy web apps:
1) care
2) understanding why a change is made/needed before making it
3) deleting code
4) simplifying and removing unneeded features
These are harder to do than ask for, because everyone's "why" for a change is different, and everyone's "unneeded features" differ, and every time a feature is added it lowers the marginal cost of continuing to work on the software - making it more likely the creators will hit the lottery of making that magic feature you love.
Now it's easier than ever to make and maintain your own software, so that might be a better road.
Nothing about intent. A lot of bugs are correctly implemented but do the wrong thing. Actually in my experience these far outweigh the classic code bugs when it comes to web apps.
I think that is the interesting problem to solve (and would have the highest user impact)
What sort of bugs do you have in mind? From our perspective there are many kinds of bugs that inhibit UX (and AX) but they can be subtle issues like poorly designed flows. It's hard for an agent to notice or understand these but they are serious problems and we're trying to surface these more readily.
OK thanks, agents definitely like partial implementations like that. When this impacts users we need to be able to observe that and see the bug, then track it back to its source. Weird logic bugs like this benefit from having a good debugger to untangle things and get to the root of the problem, especially when there is tons of code.
At the risk of getting pedantic, should those really be considered bugs?
I think it's important to distinguish between "good design implemented poorly" (bugs) and "bad design implemented well" (design flaws) because the fixes are vastly different. I'm well aware that in a user's head, "it doesn't do what I want" gets filed under "bug," but those of us building the thing can benefit from being more precise.
Makes me smile, seems ai written too. Agents will never fix this mess, it's upon us. But not in the way you're thinking. Asking agents to fix the mess they've been trained on, that they work on and they're made of it's just blindness utopia. We "just" need to part ways with current platforms(talking to you web) and build better abstractions and paradigms. The web plarform as is can't be saved anymore especially from us. It says a lot that many people get excited for a damn dialog html feature that we needed 20 years ago and it's also uncomplete
AI can fix a bug just from a description and logs. I have never seen replication to be an issue. Replication was more important for human bug fixing as you needed to be able to tinker with it.
Is this just a promotion post for their "Replay QA™" feature?
It boils down to "other products find the issue and leave the root cause + fix to your agent, our product finds the issue + root cause and leaves the fix to your agent".
Who says I want your agent to root cause? Other products already give me the repro steps, video, trace, network logs, etc, and my agent is in a much better position in terms of context and setup to find the root cause and proper fix.
If you're happy with your agent's performance using surface level o11y to track down issues then that's fine. This is what pretty much the entire industry is doing and it does usually work! QA focuses on root causes because it can look through the app's entire execution and provide evidence so your agent doesn't need to guess when figuring out what the fix is. That guesswork is what we're trying to eliminate, for when the surface level stuff doesn't clearly point at the problem.
Maybe so, but it’s been something Ive only noticed lately. The same idea has been around since approximately forever, though. It’s not a new thing even in the last few years - things like monitoring dashboards pre-date the WWW.
In fact, dashboards giving feedback about opaque automated systems goes back to early automobiles putting gauges on the dashboard, which previously was just a board to block mud, rocks, etc. from kicking up in horse drawn buggies, presumably when the horse dashed.
Actual developer: Hm, download button's not working. What's the href/onclick doing? Oh, there isn't one. Fixed.
Whatever this shit is: Thing not work, need more AI
31 comments
[ 4.7 ms ] story [ 7.2 ms ] threadLLMs can create working software as they are RF-ed with a compiler and tests. Not with bugs, they appear out of nowhere.
Agents have infinite patience, and they would go churn through most horrible buggy UIs out there to eventually achieve the goal, which is even more ironic, given that those UIs would be done by same agents in the first place.
For humans UX is already dead.
There's an opportunity here to bend things towards quality and efficiency moreso than mere volume of code. The agent has to be able to effectively repair and maintain what it has been building though.
Now it's easier than ever to make and maintain your own software, so that might be a better road.
def start_of_week() do "Monday" end
I think it's important to distinguish between "good design implemented poorly" (bugs) and "bad design implemented well" (design flaws) because the fixes are vastly different. I'm well aware that in a user's head, "it doesn't do what I want" gets filed under "bug," but those of us building the thing can benefit from being more precise.
It boils down to "other products find the issue and leave the root cause + fix to your agent, our product finds the issue + root cause and leaves the fix to your agent".
Who says I want your agent to root cause? Other products already give me the repro steps, video, trace, network logs, etc, and my agent is in a much better position in terms of context and setup to find the root cause and proper fix.
The "AI Bugfixer Extraordinaire"..
Sigh, do us all a favor and go back into whatever crack you crawled out of.