Nobody willingly reads docs. Docs don't exist for the reader, they exist for the writer(s) - because it saves them having to explain the same thing over and over again. Having docs is nice for continuity and for the people who take initiative to seek them out instead of just asking others, but their real value is turning daily (or hourly) 30 minute explanation into a link and a "let me know if you have any questions". The doc pays for itself the second time someone asks you about it.
If they can tell it is written with AI, then the docs are slop. If you're writing something lots of people will use, don't skimp on model or reasoning level, and front load with style guides and examples.
The new key for documentation is that it doesn't need to be was by humans. Good docs are just as valuable whether people read them, or just ask an LLM and the LLM RAGs the information from your docs. The main difference you have to focus on nowadays is ensuring your documentation, even internal documentation, has good "SEO" that it gets looked up.
> Closing social security off to new workers doesn't help, because current workers pay the bulk of current benefits
You don't have to reduce the taxes. Just phase out the concept that you are paying into a retirement account and call a tax a tax. That means you don't calculate how much an individual receives based on the amount they input.
In Australia, we started a sovereign wealth fund[1] to cover the future liabilities from existing workers eligible for government defined-benefits pensions and closed them to new members. I guess that wouldn't make a lot of sense in the US though given the amount of government debt the US has.
Nowdays in Australia people just have accumulation accounts (super) and the backstop of the universal aged pension.
This is the confusing thing, the way it is described is like a hybrid of government welfare and a defined-benefit pension.
How can you simultaneously be "paying into" social security but also have describe it as current workers paying for current retirees?
The only way you really find out which one it is is what happens when it runs out of money - if the government backs it up to give you the full "entitlement" you paid into it, then you were in-fact "paying into it". But if they don't, or change the rules then it sounds like you were just being taxed.
The beauty of cat is that streams are the universal interface.
Program A might accept a file as the last positional arg. Program B might accept it as a named arg, where the name/flag could be anything from --input or -f or --file etc.
But a program will read from STDIN, which all good unix programs do, then piping cat into it works every time. I can write the cat foo.txt part before I even know what command I'm piping it into.
Can someone explain the legal structures in place in the US that make Social Security "run out"? Because it just sounds like deliberate indirection put in place by the government to cut funding for pensions?
In Australia, we have a universal, means-tested pension funded through consolidated revenue (i.e taxes). The pension can't "run out", because it is just a law that says that the government will pay you $X after you turn a particular age, if your assets are below a threshold. But if X were too high the Government would need to raise taxes, borrow money or print money to fund it, like all government spending.
Separately, we have superannuation - which I think is similar to 401k except compulsory for employers to pay 12% of your salary into, which are personal retirement savings held in trust to be released at your retirement, but generally these are account-based and in addition to the pension if you are eligible (i.e what you put in is what you get out).
There are older "defined benefits" superannuation funds where payouts aren't account-based (I think based on years of service in government roles or something like that) but they have been phased out to avoid the moral hazard of something government-adjacent having pension liabilities they cannot meet with their member's funds.
So what exactly is Social Security if it can run out? It sounds like a defined-benefits fund that is run by the government - in which case why has nobody closed it off to new members like Australia did when the writing was on the wall?
Perhaps a quirk of the implementation - maybe the site doesn't server-side render links that lead to these items (though many bots run a full browser now), maybe they only track usage client-side or only in their mobile app.
There is such a dissonance between all this talk of safety and the tendency for models to, without any prompting, do very dodgy things to achieve their goal when presented with barriers.
Luckily in my experience it usually ends up only doing it to achieve the task set to it as opposed to anything "malicious", but boy it is scary reading back at how quickly the chain-of-thought pivots to attempts at privilege escalation or searching your disk for secrets when a tool doesn't work.
I don't know if it's the same in the US, but every job in Australia generally comes with a 3-6 month probationary period where employment can be terminated for basically any (non-protected) reason with little notice. I've observed that the option to do so is seldom used - probably because there is not usually much incentives for managers to decrease their number of reports unless there's serious problems.
Most places still interview. Because hiring someone for 3-6 months is still an expense. For large companies, onboarding can take many weeks before you're even thinking about being productive. Interviews don't need to be 100% accurate. They need to be time-efficient and an ok filter to prevent hiring the worst people.
I don't see how a bad job market is going to make skilled people be willing to intern in order to get employment. Employment is a market, if demand goes down, then the reaction will be that price goes down.
The reason students are willing to intern is because the supply is so high and demand so low that you can effectively hire them for nothing (or next to nothing). The interns know that on completion the internship will upgrade them to a new category with new supply/demand. It's the same reason they are willing to pay large amounts for a university degree.
So interviewing will stay the same. If demand collapses, we will see wages drop, and I imagine the supply of software people will react through early retirement, career switching and reduction of people choosing it as a career before we see an upheaval of hiring methods.
Well... in normal times they would be entering at the bottom of the index due to the company beginning to grow, the purchase of which is being funded by a firm exiting the index due to shrinking, so assuming you have bought and held units in the fund, most of the time an index fund is buying low and selling low.
And then when you sell your units, hopefully in aggregate the index is worth more than it was when you entered...
First sigmoid was transformers allow us to rapidly scale to our already abundant data until we tapped it out, the second is/was reasoning, allowing us to scale to our available compute (and compute manufacturing capacity). Correct me if I'm wrong but we don't have candidate for the third sigmoid, and scaling inference is hitting real-world supply chain constraints - electricity and chips.
Short of a third sigmoid appearing in the ML CompSci space, perhaps in the form of ongoing, repeated step-optimisations which will also have diminishing returns, intelligence growth is now limited a few scaling problems that have already been worked on for a very long time.
Transistors, which have been doubling for almost a century now, but Moores Law has already plateaued and reached limits on energy efficiency, and simply building new fabs is not something that we can do exponentially. And the other growth limiter is electricity - there is no exponential supply of fossil fuels or power plants. Although manufacturing has scaled, PV tech improvements are also plateauing - and while storage is getting cheaper, it's still not economical vs fossil fuels (meaning: when we have to switch to it, the growth slows down further) and we are unlikely to see battery efficiency sigmoid enough to maintain the AI sigmoid.
I don't mean to be bearish here. There's so much money sloshing around that we can afford to put the smartest people, using unlimited tokens, on the task of finding small, incremental gains on the CompSci side of things that will have large monetary payoffs - hopefully allowing further scaling and increased emergent abilities of LLMs. Maybe we can squeeze the algos for quite a while.
But I don't see that maintaining the same level of exponential as unlocking unlimited data or maxxing out the world's energy/fab capacity for long.
And I don't see why this is a massive issue except for the people who want to have some god-like super AI? Frontier LLMs are genuinely magic. Not "won't delete your production database" magic, but definitely a massive productivity gain for competent knowledge workers.
But I'm sure the scanning operations will start scouring the earth even harder for any books unaffected by slop containing niche knowledge and text in order for their models to have an edge over the ones trained only on pirate collections and the Internet.
I wonder if secondhand bookshops and deceased estates are seeing bulk buyers of their stock suddenly appearing. Maybe broke governments/municipalities will start selling them entire libraries and archives to ingest.
> I find it hard to believe that the knowledge to manage a bunch of dedicated servers is that arcane that people wouldn't choose it for this kind of gigantic saving.
Managing servers is fine. Managing servers well is hard for the average person. Many hand-rolled hosting setups I've encountered includes fun gems such as:
- undocumented config drift.
- one unit of availability (downtime required for offline upgrades, resizing or maintenance)
- very out of date OS/libraries (usually due to the first two issues)
- generally awful security configurations. The easiest configuration being open ports for SSH and/or database connections, which probably have passwords (if they didn't you'd immediately be pwned)
Cloud architecture might be annoying and complex for many use-cases, but if you've ever been the person who had to pick up someone else's "pet" and start making changes or just maintaining it you'll know why the it can be nice to have cloud arch put some of their constraints on how infra is provisioned and be willing to pay for it.
I cannot reconcile that growth for non-technical users is going to explode, when most utility from agents is via the ability to execute arbitrary code, generally in yolo mode, with the fact that almost all corporate IT departments do not give users the ability to install anything on their machine, let alone arbitrary code. Even developers at many companies are subject to this despite the productivity impacts.
The culture of corporate IT would need to change to allow it, and I just don't see it happening.
Someone correct me if I'm wrong, but an LLM does not interpret structured content like JSON. Everything is fed into the machine as tokens, even JSON. So your structure that says "human says foo" and "computer says bar" is not deterministically interpreted by the LLM as logical statements but as a sequence of tokens. And when the context contains a LOT of those sequences, especially further "back" in the window then that is where this "confusion" occurs.
I don't think the problem here is about a bug in Claude Code. It's an inherit property of LLMs that context further back in the window has less impact on future tokens.
Like all the other undesirable aspects of LLMs, maybe this gets "fixed" in CC by trying to get the LLM to RAG their own conversation history instead of relying on it recalling who said what from context. But you can never "fix" LLMs being a next token generator... because that is what they are.
My favourite library from these folks is gum (https://github.com/charmbracelet/gum). The basic premise is simple - instead of using hardcoded variables or in addition/instead of using CLI flags, call gum and capture the STDOUT to get the selected input value(s). Great for turning a bash script into a TUI, uses these libraries under the hood.
I find the pattern of showing interactive TUI if required options/flags are omitted much nicer than showing an error/help output.
Future models know it now, assuming they suck in mastodon and/or hacker news.
Although I don't think they actually "know" it. This particular trick question will be in the bank just like the seahorse emoji or how many Rs in strawberry. Did they start reasoning and generalising better or did the publishing of the "trick" and the discourse around it paper over the gap?
I wonder if in the future we will trade these AI tells like 0days, keeping them secret so they don't get patched out at the next model update.
Yes. But that is not what OP comment is asking for. They want one-click. And request based pricing. I was explaining why request based pricing is infeasible and one-click install would price people out (because it would imply a VPS per service).
And I said the same thing at the end of my comment about the way people would host things using docker on a VPS or home server.
> Thing is, almost every self hosted app supports docker now and so if you like, install portainer on a VPS or NUC or raspberry pi and you’ll be able to set up most self hosted apps easily without touching the command line.
Because that’s not one-click setup or priced per request, which was the comment I was responding to was seeking.
And I did say at the end of my comment:
> Thing is, almost every self hosted app supports docker now and so if you like, install portainer on a VPS or NUC or raspberry pi and you’ll be able to set up most self hosted apps easily without touching the command line.
The problem is that self hosted apps are rarely designed to be run serverless (why would they be?) and giving each app it’a own VPS or hosted container is going to price out the self-hosted crowd, to the point where you might as well be paying for some cloud software.
In particular, self hosted apps usually are using relational databases or SQLite which need persistent disk so can’t run serverless. They also sometimes require writing to physical disk instead of object storage like S3. Writing or rewriting apps to support serverless when they have no technical need to when self hosting would make things more complicated. Most CRUD frameworks used to write self-hosted apps do not work with NoSQL out of the box.
Thing is, almost every self hosted app supports docker now and so if you like, install portainer on a VPS or NUC or raspberry pi and you’ll be able to set up most self hosted apps easily without touching the command line.
If they can tell it is written with AI, then the docs are slop. If you're writing something lots of people will use, don't skimp on model or reasoning level, and front load with style guides and examples.
The new key for documentation is that it doesn't need to be was by humans. Good docs are just as valuable whether people read them, or just ask an LLM and the LLM RAGs the information from your docs. The main difference you have to focus on nowadays is ensuring your documentation, even internal documentation, has good "SEO" that it gets looked up.