It jumps to the newest story on the frontpage. And when I click the bookmarklet again (or press "n") it jumps to the next. So I just click it until I land on a story I have already seen and know I have seen them all.
If you want to use it, you can convert the code into a bookmarklet with my bookmarklet editor:
My expectation is that AI will give us a way to nicely quantify how productivity is impacted by choice of language. Because we can rerun the same request as often as we like and compare the results.
And I expect that it will turn out Python is the most productive. As it is most easy to reason about. It allows for the most elegant expression of the idea behind a program.
The first tests I have seen seem to confirm this. One recent example:
It is unclear to me though how much of your expectation might be set by the training dataset.
For example, Python and Typescript have the most amount of codebases and training being done on. So I feel as if that plays a part into the overall thing.
Languages which are more niche have genuinely hard times (Try arturo lang for example), so it depends on a lot of things/nuance, or well that has been my experience trying something recently.
My personal opinion is that if each language has the same amount of training. Golang comes close but the first might be Elixir. I have seen Elixir language perform really well with LLM's with magnitudes less training dataset. There have been some studies which had Elixir as the number one language for such tests iirc.
Gleam is a new addition as well and I feel as if it could be good and its another interesting option as well with more type-safety and an interesting language overall.
I've been in elixir for nigh a decade now and the one thing that you can try to pry from my cold dead hands is the BEAM. Elixir and Gleam are my go to languages right now and damn are they fun to write and reason in, but the part that has left me never wanting to leave the ecosystem is BEAM + OTP.
- BEAM makes monoliths sexy. You don't have to worry about a bunch of microservices, just focus on using proper process division for modeling your problem.
- Debugging on the BEAM is first class. Drop into an interactive shell, pull up telemetry, or recon and hammer down on where your live app is slowing down if your metrics have a blindspot.
I could go on and on. I'm constantly blown away every day by the amount of time and effort and all of the sage learnings in distributed computing problems that came out of Ericsson that became the foundation of erlang + OTP + BEAM and in turn elixir + Gleam.
Never tried Elixir myself but came here to say the same thing. Tencent put out this study showing that Elixir seems to reign supreme: https://autocodebench.github.io/
Purely anecdotal, but my experience has been that LLMs generate low quality python code. It's spaghetti code on par with what I've seen when companies I worked at tried offshoring development. It's basically what you get when you give bad or incomplete specs to a team of inexperienced programmers with poor development practices. It's usually good in small chunks, but it gets extremely sloppy as the scope of work increases and more decisions are introduced. Interestingly, I've seen LLMs generate good clojure code.
My guess is it comes down the the training data more than anything else, although I suspect functional languages will fare a little better. At least that's been my experience. There's undoubtedly a ton of python code in the training corpus and portions of it are of dubious quality. Niche functional languages likely have a smaller training corpus where a larger portion of it is better quality.
Python is great as a dynamic language, but I find very few things about are easy to reason conclusively about because the state of the running program can be so crazy (has pros and cons). But it probably depends at what level you are working in python and how deeply you understand it. Type checking and linting help a lot to keep the truly crazy contained, but it's just fundamentally a very difficult system to trust. Not to mention working around the GIL is fairly inefficient.
I think it's far from being this simple. What you're describing is productivity on a greenfield project, but what's really interesting is productivity when working on an existing large codebase, with existing conventions, architecture decisions (or lack of)... How easy is it to do a product pivot, to rearchitect for performance, etc etc etc.
It is actually pretty easy to keep alive URLs if there is a will to do so. Just have tests in place so you can't mess them up accidentally. And convert things that are not changing anymore to static html.
One of my first web projects involved a music forum and I have been keeping the URLs alive for 24 years now:
It's not easy. Part of the instructions would need to contain things like "how to convince your boss to not just delete the old thing" and "what to do when the startup you worked for went bankrupt" among others. Most URLs don't disappear by mistake.
Well, and pay registrar and hosting fees for 100 years, and then just hope the hosting company doesn't fold in the interim after your passing. The problem isn't "can you make sure it stays up while you're alive", the problem is, after you're gone, you're no longer there to keep the flame alive and there are no guarantees anyone else picks up the torch.
Does this suggest a subscription(ish) business where you pay the hosting company for N years and then they ensure your website stays up and unchanged for N years after you die? Quality control issue?
Given how many things want me to pay a subscription while I'm alive, surely somebody will start charging me when I'm dead. It is the logical conclusion of SaaS. I wanted to create an acronym for this, but death as a service didn't seem like the best choice.
Flattening old things down to plain HTML is underrated and important here. Old apps don’t need to be updated or upgraded or maintained or even deployed. It’s way simpler to argue to keep old stuff around if it’s essentially a domain pointing to a static bucket.
> It is actually pretty easy to keep alive URLs if there is a will to do so. Just have tests in place
"Just".
Maintaining and keeping these tests (and the oriinal link) running is also probably easy. "Just" keep maintaining them over changes in technology, hosting providers, DNS registrars...
Because a single autonomous vehicle operating in a shared
fleet can replace multiple privately owned cars, the
widespread adoption of this technology can’t help but
reduce new-car sales volumes.
The old "Thing will become more useful so we'll make less of it" argument. No mention of Jevons Paradox?
If we can travel and send stuff around from point A to point B cheaply and instantly by dropping ourselves or an item into an ocean of cars roaming our streets autonomously, there is a lot more demand for rides.
Also comfortably traveling longer distances might alter where we live. If we can walk out the door, sit down in a comfortable robotaxi right away and exit in the city center 10 minutes later, we might not have to live right in the city center anymore. Another driver for more demand.
I doubt that here. Cars are already near saturation, at least in the US.
Essentially everyone has a car. The car is mostly idle. If car availability starts to approach instant then people don't need personal vehicles that are idle 95% of the time. Car quantity overall goes down unless you can 20x current utilization, which is a lot of trips and fuel.
Not to mention that if anything resembling current quantity of extant cars becomes the current quantity of cars using roadways at a given moment, most cities will gridlock.
If the thesis is "cars will approach 50% or greater utilization" then car numbers must drop barring a massive increase in road capacity for which the land does not exist.
Cars that are idle 95% of the time are replaced less than once in a decade.
Cabs are replaced something like 3x more often than privately owned cars. And when they run 24/7 because of self-driving, that factor will even increase.
> If the thesis is "cars will approach 50% or greater utilization" then car numbers must drop barring a massive increase in road capacity for which the land does not exist.
You can build stacked roads a few levels up. Capacity doubles or triples without any significant land use.
Amsterdam is very dense because historic reasons. Streets are narrow and houses are the same.
Los Angeles on the other hand was built on virtually unlimited land and could expand a lot. I could say LA County is bigger than the whole of the Netherlands.
Both have their charm, but LA is so much better than Amsterdam.
Yeah, the 405 might suck, but at least the weather is better.
> Also comfortably traveling longer distances might alter where we live.
You mean like last time? More cars being the answer to problems created by creating too many cars and reasons to use them is like more people buying guns to counter the gun problem, and I can't think of better "tragedy of the commons" applicable situations.
As I start to get older and I spend less and less of my time in the deep suburbs, I'm starting to be more aware now of the phenomenon for people to get less social and less trusting the further away from a core area (or, arguably also the ground in the case of skyscrapers, but much less so) they live. I don't think it would be a net win to hypothetically encourage further dispersement from one another.
I wish HN commenters would stop bringing up Jevon's Paradox:
1. We see it mentioned all the time now, i.e. When AI makes producing software essentially free, there'll be more jobs. As HN has maybe 75% of the frontpage filled with AI stories, it means we see it almost every single day!
2. It essentially describes outliers. Driving food costs down to a fraction of the peak price (basically down by 90% over the last 200 years) did not result in correspondingly higher food consumption.
3. It only applies when the market is not yet saturated. Making cars more fuel efficient (by going EV) in the last 5 years did not result in correspondingly more miles being driven.
Any time you feel compelled to bring up Jevon's Paradox, ask yourself "Are we talking about energy here?" and if the answer is "No" then it probably doesn't apply.
Keep in mind that even if Jevon's Paradox applies, it does not mean that the society actually benefits. If you drive the value of all human labour to almost zero, you can't use Jevon's Paradox as an argument that the increased efficiency means that we're all living a life of leisure.
We don't need fleets of autonomous vehicles, each carrying two tons of metal for transporting a person or two and clogging up cities. We just need a train network that doesn't suck.
One of the most important ways to make a train network that doesn't suck is to aggressively police the sorts of antisocial behavior on public transit committed by the most marginalized people in society. There are a lot of political barriers to actually doing this, not the least of which is that it necessarily involves incarcerating more marginalized people, using more police violence against marginalized people, and inevitably having the police kill more marginalized people.
If you're reaction to Daniel Penny's killing of Jordan Neely on the New York City Subway isn't "Daniel Penny was a hero, Jordan Neely should have been incarcerated rather than allowed to freely exist on the train, and everyone involved in Penny's prosecution should be thrown out of positions of power", then you can't actually make the train network not suck.
Well if we did that we'd only save 40,000 lives and ~$1T in transit costs a year. Such savings and improvements in quality of life are unthinkable in the US! \s
I'd rather just have a tax based on the size of the company. Little Larry's Amazing Electric Toothbrush Inc. can pay $5 and Apple can pay $500 billion.
Considerations about what goes on in agents internally will probably not be part of software development for long.
Personally, I already see LLMs and agents as blackboxes. I give each feature request to multiple LLMs and then compare the results. I don't manually use "sessions" at all. I just look at the outcome. When I dislike it, I "git reset --hard", change my prompts and restart the feature request.
To have an ongoing sense of which agents perform best, I keep a log and calculate an ELO score of which agents meet my demands best. This score is imporant to me, not so much how the agent achieves it.
Unless we do our own benchmarks, we have to take all the marketing fluff from the frontier labs at face value, and all public benchmarks degrade eventually as labs optimize towards them. OP’s approach is wasteful because it is brute force, but post says that an ELO is kept, so this is also an experiment, and I don‘t see what‘s wrong with that. You learn which model performs well in which settings which may save resources later. It‘s also wasteful to keep working with the wrong model/harness/tools for too long.
In an interactive session, adding "Fine, but make the button red" after the model generated a first solution more than doubles the tokens used. As the model now not only gets the original code and the feature request but also the updated code plus the change request as input tokens.
Sending a feature request to an LLM and then sending the feature request again with "The button shall be red" only doubles the tokens used.
I wrote my own agent, and it sends data to LLMs in this order: "General Prompts (How to write good code)" + "The Code" + "The Feature Request". This means the KV cache will be used even when the feature request changes.
And output tokens are usually way less than the input tokens.
So I think that my approach is very lightweight on token usage compared to an interactive session.
It would be interesting to measure it for the other agents out there. Sending a feature request two times vs an interactive session.
That’s usually not true due to caching. It may be true if you leave a large gap in between, but if you send “make it red” right after, then it’s purely incremental
The cost is nothing compared to the outcome and time savings. What I see is that people with no money want to jump into this pool but they aren't having a good time. That is generally the case when you are poor.
you will be surrounded by an ecosystem of
devices, none of which stand alone, but are
more like portals to interact with your agents
I would be really happy with my phone + headphones as the device I use most. But only if I could use Gemini (or ChatGPT or Grok or any other chat agent) in voice mode and say "SSH into my GitHub Codespace soandso and implement feature soandso.". And it replies "Did it. I told copilot (or codex or whatever coding agent lives on that VM) to implement the feature".
And then a minute later I could ask it "Is copilot done yet?" and it replies "No, looks like it is still working on it". And then a minute later I ask again. It replies "Yes, it finished. It changed chart.py and styles.css. Do you want me to tell you what specific changes it made to the files?".
But it looks like none of the chat agents with voice interface have such a connector at the moment? An SSH connector would be the most useful. But a "GitHub Codespace connector" or something like that would also do.
I wonder if that will be a missing piece for long. If so, I would build an agent with voice mode and ssh connector myself. But I guess it should come out from the big guys any moment now?
> Yes, it finished. It changed chart.py and styles.css. Do you want me to tell you what specific changes it made to the files?"
A verbal diff sounds practically useless. Does it first read out the entire left-hand base, and then read out the entire right-hand target? Does it say loudly "REMOVING ... ADDING ... "? How would it read out something like Struct->Field? This seems lower fidelity than a visual confirmation, and I just don't think that voice commands make sense with this kind of work.
It would tell me about the changes like a human would.
"It changed the plot function so it takes another parameter called linewidth. It also added an input field in the stylecontrols section where the user can ...".
How would you detect the presence of bugs in this scenario? How would you make sure the LLM isn't adding yet another useless, redundant function to the code base? Even if there isn't a bug in this PR, do you not want to be familiar with the actual shape of the code in case you need to dig through it while bug hunting later?
Every time I try to take a hands-off approach to the code like this, I come to regret it later. The code ends up bloated and labyrinthine. When I let it grow unabated, it becomes gradually more difficult for the LLM to understand the intended structure as the project becomes too big for the model to keep the whole thing in its context.
How would you detect the
presence of bugs in this
scenario?
I would ask AI. "Did the last commit introduce any bugs or unintended consequences?". In fact I already use this prompt after every change I make manually.
How would you make sure the LLM
isn't adding yet another
useless, redundant function to
the code base?
By asking AI. In fact, I already run a long "Can you refactor anything in this codebase to reduce redundancy, improve readability, performance or maintainability" pretty regularly.
Are you ever reading the code? What do you do when the LLM can't fix a bug? Do you not wish you had a more intimate first-hand knowledge of the code when fixing things yourself?
Please don't tell me that never happens-- I've had one just in the last week and I use both OpenAI and Anthropic foundation models.
In fact, I usually let multiple LLMs implement the same feature, and then I compare them. I even run my own arena in which I calculate Elo scores for LLMs from my perspective of which one implemented features better.
Having the ability to control code agents via voice would not take away my ability to do that. But I think in the future, that will become less and less necessary. If we look back at this conversation in five years, it will look very archaic, and we will be used to having superhuman AI do everything for us. In 10 years, it will sound like a strange idea that humans were once fiddling with code to improve the quality.
Something something wasting machine cycles with a compiler.
Something something taking the crafts and the man out of craftsmanship to just get it out the door as quickly as possible.
All jest aside I mostly agree with you but I'd tack on another 20 years for a total of 30.
Though in this technological jump I don't think people are as excited (understandably) as when the teletype came on scene. I too like the potential but dislike the whole discourse around it, the ethics involved and the way it's deployed. Such is life I suppose.
I like how people think that if LLMs get to the point where they write code you can ship without reviewing it, that humans will still be in the loop "sshing into a code space" and "implementing features". Do you really think you'll even know what files are in that repo? Or that you'll be a necessary part of the process whatsoever?
I can tick files in Vim, those get concatenated into a prompt. Along with a feature request. Plus an instructions file that tells the LLM how to reply. Plus my general "rules for good code" file, plus one "rules for good code" file per language involved, plus a project specific overview file. The LLM then answers with a list of changes it wants to make to the code. My tooling then applies those changes and I look at them via "git diff". If I like it, I commit. If not, I change one of the prompts and start the process again.
Instead of replying with code changes, the LLM can also decide to request more files. I wrote a little DSL for that.
I described the beginnings of this workflow last July:
Why not offer a simple form that humans and AI can use alike?