But SOTA models used liberally at API pricing is a lot more than $10/hour.
You can probably burn $100+/hour with just a single agent, and probably thousands when running agents programmatically, e.g. workflows.
I’m writing a lot of React code and find that the cheaper models are pretty terrible.
Maybe I’m holding it wrong but the experience that the cheaper model is usually enough just track with my experience.
Worse, I find predicting the difficulty of tasks exceedingly difficult. More often than not using the initially cheaper models requires me to reroll with a more expensive one or waste a lot of times and tokens cleaning up the subpar results.
With OpenAI and Anthropic still subsiding tokens, not using the best models still seems like a tough ask.
Makes me wonder, as people grow to trust the AI more and more, not reading the code and barely skimming the implementation plans and simply rerolling if something doesn't work, will the value of these chats erode?
Thinking back 1-1.5 years I was closely monitoring what these agents did and steering them quite aggressively. These days not so much.
Where will RL signals come from when it approaches humans capabilities ever closer?
How well does self play work for coding work?
What about multistep tasks where it isn't just about being good at a single task, but evolving a codebase over time in the face of changing requirements?
Getting users to open a message isn’t a terribly high bar.
As a user I would not find it acceptable if needed to be careful with which message I open.
We tried putting the responsibility on the user with email attachments and I think it’s fair to say it’s been a disaster.
Malicious attachments are probably the most important distribution vector for malware.
Of course you don't NEED the better models, but figuring out what model you need can waste a lot of time and effort.
Even when a cheap model is capable of a task it needs a lot more guidance than a more expensive one.
They are also less reliable. You can waste a lot of time cleaning up after them.
Judging whether something is good enough is hard work and rerolling with a more expensive model is painful.
Judging the difficulty of a task ahead of time is very hard. Judging how good a model is for a given task even harder, especially when models and harnesses keep changing all the time.
The real productivity boost LLMs provide is already modest and when you start tinkering with models it can easily evaporate.
1. They heavily subsidized their plans vs. paying for API.
2. They allowed me to use the subscription in every tool I wanted.
3. It covered both Anthropic and OpenAI.
Yes, please!
But browsers need to make it easier for things to exist in user space.
That means reviving CSS Houdini, particularly reviving the animation and layout worklets. (It got abandoned because browser vendors (Chrome in particular) found them too difficult to implement. They would need to rearchitect a good chunk of their rendering pipeline. Instead we got a bunch of very limited but easier to implement features like scroll animation timelines)
I tried to use <dialog> and found it to be a pain.
I wanted to close it when clicking outside, but Safari doesn't support closedBy.
Some Safari versions on iOS broke when trying to style my backdrop with tailwind.
The tailwind CSS reset didn't include <dialog>.
I get the allure of just using a position: fixed;
I think cutting the legacy and doing things with the benefit of hindsight would make for a much nicer platform.
For example something like CSS Houdini (making CSS extensible) might have actually happened if browsers where designed for it and would make Web Apps a lot nicer.
1. I think it's pretty clear that the frameworks sold themselves, because it's possible to see the DX benefits with anything beyond a hello world. You don't need Meta's scale. It came from the big companies because they needed it most, not because they are the only ones who benefit.
2. I agree that the frontend-backend split caused a lot of harm and it seems most places are moving on, but it
3. It's a fair assessment that many people don't understand JS well. But it's also a super quirky language with many features that probably should be considered "do-not-use". Things like messing with the prototype chain, purposefully using == instead of === etc.
CSS is even worse. The defaults are weird, which is why everyone uses some form of CSS reset, many things have surprising names and refactoring in a codebase with complex usage of selectors and cascading is a nightmare.
But I wouldn't call people trapped in frameworks. It's pretty easy to switch between React, Svelte, Angular and co.
A) The gone by days of Java Applet's and Flash weren't so snappy either. Our websites also do much more. A tab of Google docs isn't slower or use more memory than a Word instance.
B) No group is ever immune to arrogance. But sure, if you write vanilla JS instead of TS, I'd think that's an odd choice. I'm not saying you can't make good things with Vanilla JS, but I don't see how that makes the Web more "sane".
LLM: When it comes to coding tools LLMs are not so different from humans in what helps them. They benefit just as much from the cleaner control flow of reactive frameworks (compared to jQuery), colocation of JSX and tailwind and typechecking of TS as us humans.
Mess: Has the Web really been such a mess lately? I think most of the messiness is far behind us. JS+HTML5 winning out against Flash and Java, standardization across browsers, XML or HTML.
Was it worse than Microsoft reinventing their Windows UI framework every couple of years?
There are proposals with some traction that would enable webbrowsers to parse TS, but simply ignore the types.
I think it's a bad idea, because tooling handles that perfectly well and I think browsers should generally avoid building functionality that could be equally well provided outside it, but I guess enough people have been asking for it, so it might happen.
I think it's totally fair, but I would assume that most Spring projects make significant DX tradeoffs compared to a full JS stack or serve an API rather than html.
1. Spring + Handlebars: You can either write the html template in a string loosing syntax highlighting and other LSP stuff, load it from a file loosing colocation.
2. Handlebars + webcomponents. They simply bundle all the web components into a single file, which breaks down when they get large and you don't need every component on every route.
3. Tailwind: Looking online you can get it working with spring boot, but the route chosen here is a script to run the cli, which again means every route ships every tailwind class used anywhere.
The article lists, things like transpilers, polyfills, tree shaking, minification, CSS transformation, then declares that this is all super complex and that we need to start over.
To me as a dev these are elements that have started to work transparently a long time ago. It just isn't something I worry about in my day to day frontend work, the same way a Spring + HTMX user doesn't care about the Java -> JVM -> Assembly pipeline.
The most complex things I deal with as a frontend dev is
1. Browser issues
2. Server client communication.
Part of what makes a good user experience is is working nicely with the users hardware and software stack and that's much easier on the client.
The user would like the website to have native scroll physics, respect their system preferences, react to changing window sizes and with different input methods, screen readers and so on.
If the key to a good user experience was server side control, than the hallmark of a good website would be being an RDP stream and prefers-color-scheme wouldn't be a CSS feature but a HTTP header.
Yes, but it's not the fault of these frameworks.
If people wanted to they could ship source maps on purpose and not just accidentally.
Not exposing source code was one of the early drivers for tooling.