This is unfortunately a feeling I share. It wasn't until LLMs have become nearly ubiquitous at this point, and there has been zero realistic technological response to the dangers they present. Not to mention I suspect there may be some psychological element to being exposed to interactions with AI models and their nonsense for hours a day. Not all of it is nonsense....but you won't ever know for sure.
Academically, is it a bad thing companies are selling phones preinstalled with grapheneos?
I mean in the long run, it should be a good thing to separate out the hardware phone market from the OS it comes with IMO. And for large scale adoption, it's extremely useful to have the most non-technical people using your OS, because they will complain and bugs will get reported (maybe not through the preferred channels, though).
No notes on the markup though. Infuriating there's no negotiating ability to say "you can't sell this OS on a cheap phone for 600% margins".
Most of the people I've encountered that use Java are working on enterprise codebases that are a couple decades old at this point. And I'm totally unfamiliar, but I thought Kotlin was vaguely "Java for Android" - other than existing packages, are there other reasons to choose languages focused on the JVM?
Modern Java is definitely pretty good. But indeed, Java has solidified a lot around "old" style code: making your 50 years old CTO start using collectors and typing `var` instead of MyObject object = new MyObject(); can be a difficult thing. Modern Java is truly quite pleasant.
Kotlin is a fully JVM compatible language. Java is catching up to it in some points (Project Loom has made multithreading in Java almost as pleasant as coroutines in Kotlin), but the experience in writing DSLs, code with lambdas, the brevity afforded by Kotlin makes it more pleasant than java. It's also the default recommended language for Spring/Spring Boot now, that is probably the largest JVM API backend project that ends up being used by default.
The benefits you get are:
* Probably the most stable platform you're ever going to get: the JVM is rock solid and does not require tuning honestly, unless you're trying to get a free few percents of performance. Your shitty SaaS startup doesn't need to do that.
* Probably the most performant JIT in the world. Python isn't nearly close, and Go is, well, not jitted, but offers similar-ish performance. Except that you get a good GC with the JVM. Or rather multiple GCs depending on what you really want: throughput/low pauses/etc.
* The packages are truly a massive thing. The APIs aren't always perfect, but behind python & js, it's probably the most fully fledged option.
* Publishing modules doesn't suck.
* Having to carry a jar around does suck a bit, but fat jars solve the problem, and if you're serious in your work, you can just GraalVM it and you have an AOT compiled executable that works great.
Negatives:
* It's java, man. It's still the same verbose beast. Doing low allocation work is a bit hard. Kotlin makes it better. Kotlin also has kotlin multiplatform with a large and growing API surface, and is probably one of the most pleasant multiplatform options, allowing you to delegate to any platform code you want.
* You're never getting a tiny 5MB executable. If startup time is an issue, work hard on GraalVM.
Interesting! I am curious to ask someone who has been working on no-code tools for so long: I've been reading about no code platforms from the 1990s, and how all of those ended up failing. The reason I've seen cited most is that the tools/platforms did not allow for enough variability to do the jobs that people wanted (without becoming a full programming language themselves). What do you think about that in the context of the past ten years, pre- and post-LLMs?
And what do you think about coding agents in the next few years? Will we see a variation in agent capabilities? E.g. a company makes and distributes a specialized coding agent for CSS, or even serving up a kind of library that's language-agnostic, since they seem to be best at translation rather than creation?
"company makes and distributes a specialized coding agent for CSS" - weird that you think this is a path because I think this is not as appreciated as it should be.
No-code has been in a poor state for many reasons. I agree that people want more generic software to be built and the platforms did not allow for enough variability. This is what being better enabled with LLMs.
I think coding agents, particularly Claude Code, makes people think that models are the key. Some people disagree. I disagree as well. I think small models with lots of deterministic code is the way. But this will not fill Anthropic's or OpenAI's pockets.
Using an LSP, for example is recent in coding agents. But if you think about it, we should have started with that. Most agents expect LLMs to know too broadly. I would instead create 40 (random number) agents - one for each language and part of the stack. This is why your CSS example is interesting. I create just an agent for the ORM related code in a Rust/Diesel based coding agent. It worked with a 4B parameter model!
People will fight over "worked" but basically what I did was create deterministic code generator for the ORM layer - schema, model and model accessor or mutator functions and then asked the tiny model to fill in the code with lots of code example straight from the official docs. It played well for many different kinds of prompts - all focused only on model related changes.
What if we create many layers of this - a higher level agent breaks human prompts into an intermediate language and then tech-stack focused agents write the code within deterministic tooling. Agents cannot read or write any file they want - they are specific to that part of the stack, linter, compiler, etc. kick in automatically.
I read that as him beginning the healing stages. Acknowledging his flaws as soon as he could even if he couldn't change what he already said - because that post did blow up, if he had taken the whole thing down it may have just exacerbated things.
I don't understand this, if I'm honest. WebAssembly is the compilation target. It's a Scheme compiler for wasm, right? Why is it pretending to be a way to rewrite websites? Wouldn't that be a job for literally any possible language compiled to WebAssembly?
I read the "Why Scheme?" page and it looked entirely AI generated, inasmuch as the reasoning presented confused me, because it didn't make sense. It references homoiconicity as pretty much the only reason to do this, mentions Lisp once or twice, and then just sort of talks about AI not understanding HTML because it doesn't understand compiling.
But putting it under the prompt of "must pass compiler" makes an AI exactly as capable at the task of making websites as it is capable at the task of making correct programs in any language - which is to say that it can't be guaranteed. Which in turn puts into the question the whole purpose of this project, and particularly, why Scheme chosen at all? Why not Lisp? Why not C? Or Erlang? Or Clojure?
Scheme language is very well-suited for producing websites, I've been doing that for several months with decent results. But unless I missed information, I think you're right that has nothing to do with WebAssembly. However I know Scheme->wasm compilers exist if unsure of their status.
Of course many languages can be used to create or serve websites. If language doesn't matter, then why not Scheme? It's at least as capable as the languages mentioned. OTOH much less is written about Scheme vs. more "mainstream" languages. Maybe that does make a difference.
I see this get mentioned a lot but I still am skeptical that AI can generate tests we can trust more than any other code we know we cannot trust.
Yes tests are conceptually isolated and that helps, but I've personally seen unit tests get generated that are semantically incorrect - that is, they test the structure of the code (e.g. they can check function output types and values), but they can't know _why_ the unit tests need to be there, so the really really helpful tests never get generated. Not to mention the obvious issues with generated tests only testing is x = x, or needless redundant tests for the same thing, or them essentially testing basic features of the language.
You have to iterate on the tests, review and validate them, just like any other code, and if you generate a whole project's tests all at once the quality is abysmal, of course. I've been using a lot of old school data-driven testing techniques, where the harness is just code I review, and the data itself is e.g. json files and drives the system.
I actually have a public (AGPL) example here: https://github.com/pgdogdev/pgdog/tree/main/integration/sql - pgdog is particularly testable since it is trying for complete transparency, so you have a perfect oracle in hand via base postgresql, but it demonstrates the concept at least.
Then this falls into the exact same pit the OP mentioned, either you need to blindly trust that the LLM is generating tests that actually work, or you need extensive test coverage for your tests to ensure that your tests are actually testing.
It turns out that you don't actually need tests for your tests, because the code provides a baseline truth for the tests. You do, at some point, have to be epistemically sound enough to actually look for correctness in either the code, behavior, or tests. We unfortunately haven't fully unlocked completely solipsistic value generation yet.
This is also part of why I like end to end tests that use actual UI flow, so I can watch it go by in slow mode before letting it loose fully automated.
Maybe it's because I haven't had my coffee yet, but I cannot understand what you are saying.
What do you mean by "be epistemically sound enough"?
You are using it as if to say "if your code is grounded in sound abstractions, you'll be fine and tests will therefore generate successfully" but preface that claim with "the code provides a baseline truth for the tests". The latter does not follow from the former, and it also does not lift the burden of responsibility away from the programmer - which is where my doubts on test generation stem from in the first place.
Additionally, what is "completely solipsistic value generation"?
You reference it like a perk in a skill tree, but to my ears "generating completely solipsistic values" seems like a way of describing AGI with a philosophical wording instead of just saying AGI.
I mean that your code has to accomplish something in the real world that is verifiable on a human level. It has to let customers get something done, or trade resources via a market, or something. That requires that it have some basis in reality that provides a ground truth about whether the system is working or not, and that's what gives you feedback that drives your tests and design.
You:
>>> You want comprehensive tests at every level, far more than is reasonable for a human to build or maintain
Also you:
> You have to iterate on the tests, review and validate them
Yes, "maintain" is not quite the same as "review", but the line is veeery fine. I find it really tiring to review masses of tests that an agent spews out.
Especially because I know what it has a tendency to write irrelevant/vacuous/useless tests. It's insane the amount of times I have told Codex to "write a test that reproduces the reported bug, SEE THE TEST FAIL, then implement a fix", only for it to guess an irrelevant test, not run it to see it fail, and implement a code change that has nothing to do with either the test or the actual bug.
Which is why test generation has to be carefully guided as well, and this is something at which I've incidentally been fast. Ultimately it's a constant battle between LLM handholding and doing things yourself.
I don't even care about tests being correct as you can still verify them even when tedious. What I care is that, more often than not, the shape of the solution is not fixed. Having unit tests for those can be extremely costly as when the changes happens, you have to change all the tests.
I've been burned by this in my honeymoon period with unit testing (pretty much the reason it ended). These days, I prefer broader scope of testing, especially user-facing part. The users may be other developers or end users. I only do unit testing for tricky algorithms or math formulae.
I want all the layers of the pyramid, eventually, but the top layers matter the most. I can't count the number of times my paranoid "make sure that customers can successfully pay us" end to end test suite has prevented the money faucet from being shut off. I install one perennially at any company I work at and they always pay for themselves surprisingly quickly.
I’ve been involved in B2B (so no payment flow). But it’s basically the same with an handful of integration tests for common workflows. They run fast and mostly serve a canary to ensure that we are not crippling some use cases. When a bug hits us, a test case is added/modified for it.
They’re mostly a reflection of the current requirement of the project.
AI shouldn't write tests. At least not all of them. Definitely not e2e's. The tests should be guardrails to constrain agents. This way, the author of code matters less.
I made it through because the content was interesting, but I am definitely not going to read more from this author because the AI-wordsmithing is so grating (I read loads of it at work, don't need to read any more of it).
FWIW, on your own blog, the most recent post also reads as at least AI helped "Navigator Theory". This sentence in particular sticks out: "They affect what the person notices, what they dismiss, what they measure, what they trust, and what they do when reality pushes back."
The one earlier post I read does not ("toxicity of ideas").
And fwiw, online detectors seems to agree with my own judgement here.
> Hesiod felt it. Plato theorized it. Polybius mechanized it. Sallust prosecuted it (while guilty). Ibn Khaldun put it on a timer. Five civilizations, twenty-one centuries, one diagnosis. The only thing missing was proof.
> For most of history, “too many assholes ruin everything” remained a vibe. A well-documented, five-civilization vibe, but a vibe. Then, in the twentieth century, it became math.
> Sallust, it turns out, was doing game theory in a toga. He just didn’t have the notation.
> That’s not my characterization — it’s the title of the paper. And the researchers defined the term with clinical precision
> That single belief turns out to be a genetic marker. Everything else travels with it.
^^ that one in particular is a VERY strong Claude-ism
> Now, the finding inside the finding
> The study is not a catalog of monsters [...] It’s a measurement [...] with polling-grade precision
> Political violence wasn’t rhetorical; it was a body count
The trend that bothers me the most is excessive use of the em dash accompanied by awkward use of semicolons.
> Cooperators who are scattered among cheaters get eaten alive — the lone honest man in a crooked ward is not noble, mathematically speaking; he’s lunch.
There's also the not-quite-right logical link between clauses (I see this a lot in Opus output):
> Parasites are a constant; every era grows them to maximum greed, because that’s what parasites do.
("era grows them" doesn't fit with "that's what parasites do." If the era grows them, the parasites aren't doing their own growth.)
Yeah, I've changed my evaluation. The lists didn't do it for me, because they don't follow the usual rule-of-three, but the "genetic marker ... travels" line seems egregious. And the "not X, but Y".
More recent Claude models tend to do these new longer lists. I think they've trained it on more varied sentence structures to give it a less monotonous feeling when reading, which worked, but now it has this tendency to go for "punchy" in a way that becomes grating.
> A thing. Another thing. More thing. But this thing. Four things, one common thread through time.
Every one of those is also an example of how people have written and spoken since before AI existed. But then, I don't 'Claude', so I'm not sensitised by exposure.
Sure, LLMs learned them from somewhere, but when you use it a lot you see that it has very specific, very repetitive writing patterns. This article makes little effort to adapt the writing away from those patterns.
It is like a code smell, when you see it, it is obvious.
I also got strong AI vibes, but I enjoyed the content. I thought it was a interesting summary of topics I've read many times before and even if the content was AI-assisted, does it matter? It seems there was a strong guiding hand in presenting a popular topic in a new way.
It matters because I don't like the style. I wouldn't like it if a human wrote it. I don't like the style so much that I won't read things written with it.
So maybe she had something interesting to say, but it was not communicated to me because I bounced.
Are you saying everyone knows it was designed to be addictive and thus no proof that it was is needed PLUS people actually got addicted to it (similar to drugs)?
If so, what is your definition of addictive because it seems to differ from mine.
reply