> It’s all just physics and chemistry, and those are well understood.
Not really. We cannot model physics and chemistry to a level which allows us to accurately predict a humans action (even a tiny time-step into the future)
This is vastly different to an LLM, where the model is the model (for a lack of better phrasing).
We can model physics and chemistry pretty well, just not beyond small scales, because the computational effort blows up.
You could just as easily say that if you can write a python interpreter that you can understand every program written in python. Ok, now what if the program is two terabytes?
A frontier LLM is nothing but a 2 terabyte program written in a weird programming language. Just because you can understand the interpreter does not mean you understand the program in a meaningful way.
To be fair, we can't model human language well enough to accurately predict what an actual human will say either. Our ability to accurately model physics is similar to our ability to accurately model human language. And we make immense use of both kinds of model, despite their flaws, inaccuracies, and inability to ever be perfect.
There's definitely trade-offs. I actually prefer a proper SPA to pure HTML when on a slow connection and interacting with a site a lot.
Especially when trying to buy something. I much prefer to have a longer initial load and then have everything just work instead of waiting as I navigate between pages, the multi stage checkout, confirmation etc.
But yeah, if I'm just trying read a single article on a blog, preloading everything is pointless. A hybrid site with the initial page being server side rendered + progressive enhancement afterwards is theoretically optimal in my opinion.
These people definitely have an overly rosy view of the past. The sites that are dog slow shit ux now still would be with server rendered html and jquery spaghetti, just like they were in the past.
Ever submit some giant form to get some random error and then lose the entire state of it? Used to be extremely common, even though it shouldn’t have been.
Losing the entire state happens on SPA. Plus a random error not providing any feedback is a typical SPA experience. You can poorly execute on any technology. It's just much easier to do things wrong using this-year-trendy-SPA-framework.
Use the appropriate technology, everything doesn't have to be a SPA.
And yet it used to be much more common. SPA or not doesn't change how your team executes, what kind of management you're working under, or any other externality that makes you end up with a shit website.
You typically still have to wait for API calls between interactions, but error handling and number of requests (linked to experience on slow connection) tend to be worse.
If that's a connection-less interaction or something small that stays on the same page, sure it makes sense to keep it in the browser. You don't need to build your whole site as a bloated SPA just for few limited use-cases.
I use it for all my non-professional work and I find it works well enough for me.
Mostly for things that I know are possible and have a vague idea of how I would do it, but it would take me longer. Some examples in no particular order:
* Made my wife's travel blog/site
* Chrome extension for Crunchyroll to allow multisubs + local translation for unsupported languages (so my wife and I can watch and she doesn't need to focus extra hard reading English)
* Same as above for Netflix
* Setup multi subs with mpv (some Lua plugin shenanigans)
* Setup proton for warcraft 3 + wc3 champions (unofficial ladder) on Linux
* Setup a bunch of xrandr aliases for my different monitor uses (I'm still on x11)
If you need a custom chrome/firefox extension or to create some bespoke Linux QoL stuff, it works great. This was all Gemini Flash 3.5-3.7 (been using it for a while). I suspect pretty much anything would succeed at these tasks, but I just stick with antigravity because it works for me(and I'm on some discounted plan).
I hate that I have to change the way I write to avoid AI-isms. I loved using "load bearing" to describe weird code that you think you can delete but is actually holding everything together.
Now people think I'm just parroting what Claude said. It sucks. I want my catch phrases back, I guess this is how em dash users felt
I used to use em-dashes for explanatory clauses--like this one, for example--when using commas would make the sentence difficult to parse due to other nearby commas.
They're only a LinkedIn-ism when used to create an unduly dramatic juxtaposition for an otherwise mundane idea. But now they set off people's AI radar when used for any reason at all.
Perhaps I am biased because I find the use of em-dashes without spaces (as is common in English typesetting) to be inherently ugly so I'm not too unhappy to see their use discouraged.
Yeah, the YAMLification of everything kinda killed my ability to understand "everything". Previously, if you knew the Linux userland well, I felt like you could figure anything out with enough digging.
Take CI for example, it was Jenkins and it ran a csh/bash/zsh whatever script and captured the output. Nice and simple (even if the scripts sometimes got insane).
GitHub actions is nothing like that. Weird home grown extensions to YAML with their own idiosyncrasies and dynamically pulling in plugins from god knows where. You can't just take a workflow and execute it locally like you could with a bash script.
And worse: GitHub Actions not a full-fledged programming environment by itself either, so you're inevitably going to have to deal with nontrivial shell scripts on top of all the YAML mess.
Yeah. It makes sense when you're standing right next to it, but you take a step back and go "that doesn't look right". GitHub actions is the faster horse instead of a car.
The things done in yaml today would've been obscure bash oneliners had YAML not existed.
Jenkins still exists and it's no less complicated than Github Actions. The complexity gets hidden in obscure script files, obscure tabbed UI, and remote services for doing things Jenkins itself can't do. Defaulting to system tooling makes it almost impossible to predict what a job will do unless you know exactly how paths and tooling are set up (and what versions they're running).
None of my personal experiences with Jenkins had scripts that ran locally, they all relied on pre-installed software on the server because that was the thing people would do before the great YAMLification. You could copy-paste the Jenkins job, but unless you have Jabberwocky v2018.3 installed in /home/JabberWock/RELEASE, the script will fail.
The entire software development flow has been made incredibly complex by hooking up automations into every nook and cranny.
All of these complications need to be enabled manually, though. If your flow is complicated, you can cut it down to manageable size by doing a few more processes manually.
Luckily, all of the simplication and reproduction steps for Github also apply to Jenkins. Github YAML files are just scripts with different syntax, after all. Just like you can run bash locally, you can run act and reproduce whatever Github trigger you need. From there, you can simplify pipelines, stop curl2bashing "plugins", and so on.
Except that YAML in almost every devops or CI workflow is YAML plus obscure bash oneliners.
Or it's an obscure bash oneliner hidden in another repository as a package that you can depend on, which is either wrapped by another YAML config or maybe some JS.
I don't think the criticisms of Jenkins compare because Jenkins is really much more than a CI layer, predates the concept of devops and our modern understanding of CI/CD, and it has a lot of complexity to make that work. That was back when you'd have IT teams provisioning your servers for you and shit.
But that's the core of the problem, isn't it? People setting up devops environments are the reason these flows are so complicated. You can set up the same flows by having Jenkins call out to Jenkins to trigger chains of jobs that can conditionally fail.
People generally don't do it, because there are better alternatives out there for when you want those types of pipelines (which includes Github Actions and their counterparts). Setting up a four-step build+test+scan+tag+push+deploy pipeline in Jenkins is just as hard as it is with Github, if not harder. [Jenkinsfile](https://www.jenkins.io/doc/book/pipeline/jenkinsfile/) is just YAML with extra parentheses.
The modern YAML files are a simplification of the manual steps required to do it all in tools that predated the YAML files. There's nothing stopping you from having a Github runner configuration that's just a call to a single Docker image containing all the bash/perl/Makefile/Kotlinscript/Go/Ruby/etc. files you want to execute. Or you can forego the Docker part and run code directly inside of the repository, with all the security risks that come with it (not dissimilar to having a fully open Jenkins server).
Complicated YAML is a symptom. It's no better or worse than Bash or TOML or Makefile when you start adding conditional automation and multi-step CI/CD flows.
You are not wrong, Jenkins had many problems. But I would argue that the solutions were always grounded in the Linux userland.
And I also agree that you could use GitHub actions in a similar way to how I talk about Jenkins. I also think you could use Jenkins in a way that is similar to GitHub actions with an extremely convoluted Jenkins file that relies on Jenkins plugins etc.
But nowhere I worked did that with Jenkins, whereas everywhere I worked with GitHub actions does create extremely complex pipelines relying on 3rd party actions (with many being vendor supplied). I'm sure(hope?) the DevOps folks looked at what each action actually does by going to wherever it's pulled from and read it (and the actions it pulls in).
I'm not necessarily arguing that things are worse now. Just that you don't get a "free" understanding anymore by just having a good familiarity of the Linux userland. When there's a problem, I stick my head in the sand and let the DevOps people handle it.
I also haven't worked anywhere that uses Jenkins in 10+ years, so maybe if I went back, it would be the same as Github.
Lack of a local runner is my biggest peeve. Any novel GHA workflow creation results in a PR with 100 commits, until you can finally sort out all the non-obvious idiosyncrasies. For any modestly complex workflow, I move everything to a bash or TS file and call that, and then you can use _coding tools_ and a _local_ dev/eval loop.
How funny that GitHub Actions' lack of tools forces you to make a bunch of billed cloud runs with GitHub for workflow edits. I'm sure their PMs are very concerned about this trend.
A local runner would certainly help, but only to some extend. When you need to support multiple OS (Windows, Linux, macOS) and architecture (x64, arm64), not everything can be tested locally.
Try writing a regression test for your Github Action.. I'll wait.
It's a pretty ridiculously half-baked feature. But a lot of these devtools are--it's arguably even worse in the observability vertical. You have all these metrics and dashboards you're using to make critical business and operational decisions yet no way to actually ensure they're telling you what you think they are. Clown shit.
Surely it ends with alternative clients? Seems much easier and more efficient. Facebook UI is crap anyway, just have something scrape the data and present it in a format that's not optimized for whatever KPI FB cares about and without ads.
The problem is extracting the data from Facebook. They do a lot of work to obfuscate their markup. You'd probably be best loading the whole thing in a headless browser, taking screenshots, running that through an LLM and getting the data.
Yeah, I was very skeptical and now I've drank the kool-aid. Got multiple parallel cloud agents with independent loops making PRs and me reviewing them. AI is also reviewing PRs and sometimes even catches useful things.
LLMs in 2023, from what I remember, were slightly better auto complete. It's pretty different now.
I'm using AI in many ways but I'm not ignoring that it has some real costs. The code AI writes is too voluminous to fully review. I'm quite disconnected from it, and probably won't be able to maintain it myself. The more we use AI to code, the more our real skills atrophy (already feeling that). And when AI pricing finally catches up with the astronomical spending going into it, people are going to have a rude awakening. Nothing good is coming from any of this, unless you're able to cash in before the economy collapses when this bubble finally bursts.
I guess it depends, but what are you doing with all your time if you aren't reviewing the code and trying to make it maintainable?
The time I previously spent writing code is now spent reviewing code and giving feedback so that it gets written differently if don't like it.
The skills required have changed completely imo. You need to be able to context switch efficiently and review "better". Also identify which tasks require lots of supervision of what the AI generates and which don't.
I think AI is here to stay. Open models keep the costs at a certain level. If hosted solutions get too expensive, people will selfhost. Even if models never improve beyond today, the open ones are good enough at this point to provide immense value.
>what are you doing with all your time if you aren't reviewing the code and trying to make it maintainable?
I was told I'm not supposed to read pull requests at my job anymore (we all do agentic coding now), I'm just supposed to click "approve" on PRs because for some stupid reason it still requires several humans to approve the PR. Instead of reading PRs, we're all telling the AI to do more work to create even more PRs. It's not a good way forward, and I'm looking for another job.
>If hosted solutions get too expensive, people will selfhost.
To self-host a frontier-adjacent model at speed comparable to a commercial API, you're looking at roughly $250k-500k to buy or $20-35k/month to rent the GPUs. And that's only enough to operate at current "frontier" model capability, and buying also doesn't include the massive amounts of electricity it will cost every month to run that hardware. Admittedly I used AI to come up with those figures, so take it with a grain of salt, but judging from how much these AI companies are spending, it tracks that they are consuming massive amounts of money on a per-user basis just to gain market share. I've tried to self-host AI and it sucks. I wouldn't use it for coding.
>I think AI is here to stay.
Sure it is, but it may not cost what you think it should cost.
> I was told I'm not supposed to read pull requests at my job anymore (we all do agentic coding now), I'm just supposed to click "approve" on PRs because for some stupid reason it still requires several humans to approve the PR.
That sucks, may as well auto approve with a script.
> Sure it is, but it may not cost what you think it should cost.
You can go on open router and see what 3rd parties are hosting open models for. There are some pretty capable models (not frontier, but probably opus 4.5 level) for pretty cheap.
Those companies have no incentive to lose money. They are nameless, they are making a profit just providing the service, and it's cheaper than the frontier models of today.
So I think we have a pretty good idea about what the price can be, even without VC subsidizing.
AI pricing finally catching up? What do you mean? Every few months prices are going down by 5x. Your price correction will not happen and it’s time to accept it.
Yes I agree with this - models today are better than they were a year ago. But not sure if I can "do for $1 what used to cost $25" across the board (meaning two times occurred 5x price reduction). But it's maybe not that simple to compare as there are some simple things also that just were not feasibly possible at all some time ago.
Seems like you are keeping your head in the sand about how much the AI companies are spending vs. how much they are bringing in. These companies are following the Uber model of pricing, trying to beat the competition and drive them out of the market. Uber is very expensive now, because they have to pay for all the many billions of dollars they spent being unprofitable, trying to drive out competition. It didn't really work, Lyft is still a thing, and both of them are way more expensive now than when they first started, an order of magnitude more expensive, and it isn't just inflation, it's all the debt they incurred that needs to be paid back. I used to take Uber all the time, and now it's only if I really, really have to, because it's just too expensive.
The AI companies are doing the exact same thing - operating at massive losses (far more than Uber ever did, to an extreme extent), trying to "win" the AI arms race, playing a game of chicken with their competitors.
This matches what Gwern wrote years ago [0]. It does unequivocally make you stronger though. So if you're training anyway, may as well take it and hope it makes you smarter as well (just believing might be enough for that sweet placebo effect).
Today I learned about the Bortle scale. I was completely ignorant about it.
> If you've never seen truly dark skies, do yourself a favour and go see what they look like during true night
I think I went from only ever experiencing Bortle 5-6 to Bortle 1 when I visited Merzouga and Erg Chebbi. Blew my mind, made me really appreciate the extent of light pollution almost everywhere else I've been.
When I first learned about the "clouds are noticeably brighter than the sky" part of Bortle 5, it was like it flipped a switch in my brain. I can't avoid noticing it now.
> The worst part IMO for both is that they prioritize mobile apps over their PC software so if you want to edit on a computer like a normal reasonable person you lose features compared to idiotically doing things on a phone.
This is my biggest issue as well. It's actually the one "real" thing I use the iPad for. It still gets the mobile app interface whilst being on a bigger screen and being almost usable.
Not really. We cannot model physics and chemistry to a level which allows us to accurately predict a humans action (even a tiny time-step into the future)
This is vastly different to an LLM, where the model is the model (for a lack of better phrasing).
reply