> I wish i could just opt out of social security and invest the money myself.
I'd like to emphasize that SS/OASDI is not an investment program in the first place, it is an insurance program. The two kinds cannot be directly compared, and have very different mechanics and features. You might already have known that, but the misconception is distressingly common in America--which I blame on misinformation from big-bank lobbyists.
> You inherit all risk. But you opt out of the taxes. You must prove retirements assets are being contributed to.
Is inheriting all the risk even possible? Suppose someone signs some dark legal contract in blood, like: "I refuse all public assistance, let me die in a ditch because I shall make my own fate."
What happens if they commit crime (perhaps out of desperation) and are sentenced to time in jail? Now there are three outcomes which all suck differently:
1. The government caves and supports them anyway with taxpayers funding their jail-food and jail-shelter. This distorts the original incentives, and recidivism is going to be a bitch.
2. They are let go, to commit more crimes? Locals won't stand for that.
3. They are indirectly executed by being forcibly exiled to a walled-off isolated place with no food and no shelter, as their families (quite reasonably) cry about the brutality on TV.
Then there's the issue of dependents, and mechanisms for fraud, and both of those are much bigger cans of worms than I want to open in this edit...
The first key is that it isn't defined-benefits, in the sense that there is no account labeled "Bob Smith's Accumulated Retirement." Don't be disheartened though, because many Americans have the wrong idea too. [0 - See rant in footnote.]
In addition, the US has no constitutional barrier to protect it, the federal legislature can pass a regular law which completely rewrites the benefits however they like. It could be very unpopular, though.
> Can someone explain the legal structures [...]
It has grown a lot of bells and whistles over time, but at the core its formal original name of "Old-Age, Survivors, and Disability Insurance" is very informative.
* The premiums for coverage are collected as a tax on the working.
* Payout conditions broadly involve being alive and not able to earn enough to stay that way.
* If you pay in and then die young and healthy, you don't get anything. This is normal and intended, the same way that home fire insurance doesn't pay if your house is swept away by a tsunami.
* The program's surplus funds (from planned-for demographic shifts) is invested in bonds with the US government, meaning that there's an intra-governmental credit/debt going on, where OASDI/SS is the creditor and government-in-general is the debtor.
> [...] that make Social Security "run out"?
Most of the "run out" talk refers to a period of time where the invested surplus dwindles due to yet-more demographic shift, and cannot cover the difference between inflow and outflow. At that point one or both of these will have to happen:
(A) Congress passes a law increasing premiums/taxes on current workers
(B) Congress passes a law saying it's OK to pay less than the program did before.
Congress has been procrastinating on this for many decades.
__________
[0] I blame this on deliberate tactics by big-banks, and political groups ideologically opposed to the program. Private banks are unable to make big bucks offering a competing insurance plan, so instead they promote a false comparison. It goes like this:
1. They falsely assert that X% of the current surplus is somehow already exclusively "yours."
2. They claim that "your" money exists in a boring lame government retirement account which only invests in bonds. (Only half-true, in that the surplus is in bonds.)
3. They ask if you'd rather have the option of moving the money to a new account run by Big Bank, who is so much cooler will help you (for a modest fee) invest in stocks which go up much faster so "your" money will be zillions by the time you retire.
There's definitely a lot of room for weasel-wording there, where the metric really being used isn't the mathematical mean, but punishes people just the same.
My first-impression is that this site is vaporware generated by someone prompting an LLM to babble about how an LLM could be secured.
At best, perhaps it's an overengineered way to force humans to rigorously validate every action... which the humans are all very hostile to doing.
> [Architecture page] Reasoning is Read-Only: Input=Data, not Instructions
This doesn't make make sense unless the "reasoning" is regular executable code, and then someone still needs to audit the code whenever it changes. The core LLM algorithms simply don't have room for the distinction.
> Complex workflows broken down into encrypted graph segments
Grandiosity++, where does "the architecture" actually end?
Read enough of EGreg’s posts and you’ll immediately recognize that this site is definitely his but at least LLMs stopped him posting about qbix all the time, a sweet mercy
go back through all of your comments from the last decade, group them by comments that promote/mention one of your projects and comments that do not. I’d ballpark 95% of your comments have been self-aggrandizing self-promotion, it is exhausting to read. I guess today was the day I said something when I saw someone else suffering through another one of your comments. You might want to create healthier technology but you have contributed nothing to HN in almost 20 years, almost impressive enough to be an achievement unto itself. I’d eat my hat if I could find a substantive comment you’ve ever written that wasn’t self-promotion.
Pretty sure there is nothing about “complex workflows broken down into encrypted graph segments”. Did you just make that up to add some oomph?
The actual point of the article was: recursive self improvement is scary and upredictable, you can get 99% of the benefit by doing the reliable and predictable thing instead. Did you even read the actual article? I didn’t see anything in your comment about that main thesis which is woven through — well — every paragraph.
Update: oh, I went through your recent comment history and apparently most of it is just snarky criticisms of surface level things. Okay :)
> Pretty sure there is nothing about “complex workflows broken down into encrypted graph segments”.
In the quotes I noted [Architecture Page], which is the extremely prominent blue button/link on the SafeBots homepage. (To a PDF.)
It's on the slide "Scalability: Distributed Reasoning & Encrypted DAGs", number 11 with a black background.
> Did you just make that up
I choose to take this false-accusation as a positive sign that we feel the same way.
You read the text I quoted and (just like me) felt it somehow didn't make much sense... and you felt that very so strongly that you could not believe it even existed!
> at a competitive disadvantage, and cooler heads will prevail
I don't think this a safe assumption at all, given the the last few years of government policy where the "cooler heads" very much failed to stop such things. Either by partisan choice, or because they were silenced/fired for telling the Emperor that his clothes weren't there.
In particular, consider the tariff-taxes [0] against on US importers, and the ensuing breakdown between America and its oldest allies and trading-partners. Also relevant would be the President's recent pet-project war [1], which has shut down a major part of international shipping.
_______
[0] Unilaterally imposed by fiat, with idiotic "failed economics 101" math for the rates... and the majority in Congress still actively tried to keep it going, until the Supreme Court ruled it illegal.
[1] Simultaneously a war and not a war, both already-won and ongoing, depending on which lies need to be told today to harvest applause and grab cash. Just this week the White House submitted documents to Congress claiming what's going on is a completely separate and new, second war with Iran...
> they (or any intermediary) could change tomorrow.
Adding to this, my understanding (IANAL) is that any promises to delete or limit sharing of your data could be swept-aside by a bankruptcy judge, putting priority on liquidating the company and its assets for the maximum amount of money for creditors.
If well-intentioned operators erase your data before the company falls into the hands of the trustee or creditors, an unsympathetic legal-system could end up charging them with crimes for it.
That's somewhat alien to me, I suppose because over the years I just never stopped using regex in search/replace tools, which is daily exposure regardless of what code needs to be written.
Sometimes the patterns are dirt-simple, like `/\bfoo/` to find things that start with foo, or a `/foo.?bar/i` to try to find multiple variations of FooBar and fooBar and foo-bar and FOO_BAR. Other contexts outside an IDE include browser dev-tools, exploratory SQL queries on the database, searching centralized logs, and occasionally turning lines of text into spreadsheets via CSV.
None of that guarantees deep expertise of the weirder tricks, but it absolutely keeps the general knowledge "warm."
Unfortunately the incremental approach doesn't help when it comes to the review step by another user, they've still gotta take it as a lump and apply fresh eyes on it.
not if you break your work into a stack of PRs, which is the standard practice for my team at work. you just keep adding PRs to the top of the stack while the reviewer proceeds from the bottom. if something changes you propagate the change up the stack, which LLMs are also pretty good at doing.
I'm all in favor of stacking PR's to break reviews into chunks, but if they're being used to explain the reasoning or correctness of the final code to a reviewer, then that's a process-smell. It's like "teaching to the test", a shortcut that will hurt in the long run.
We want to end up with code that makes sense generally, to whomever is editing or or debugging it in the future. That next-person usually won't (or shouldn't need to) mine the git history to understand the current project in front of them.
i'm not sure i understand your objection. here's a concrete example of what i'm talking about:say i want to add a new feature to my code analyser, exception-aware code analysis. it ends up being 2000 lines worth of diffs, touching a bunch of files, and definitely too much to review in one go. so what i do is, first i write a doc file describing the feature, to show what i'm working towards. then i write a small commit, "add a new `exception_handlers` member to the context struct, and a small class containing its datatype", and upload it for review. why is this new member needed? see the plan doc pointed to by the commit message! now i needn't wait for it to be reviewed, i can stack another commit on top of it, "populate the exception_handlers info by walking the AST". it depends on the exception_handlers member being in the struct, but, crucially, it doesn't depend on that code being merged in, because it's there in the stack below this commit. i can keep adding things like "inherit exception_handlers when analysing function calls", "validate that all explicitly raised exceptions are caught by an exception handler in the current scope", etc - there are a lot of moving parts to analyse exception handling, but each commit is fairly small, does one precise thing, and is therefore relatively easy to review.
when the stack is complete and all the commits are uploaded to wherever (we use phabricator but i'm sure github has an equivalent) for review i just need to sit back (or work on something else) while my reviewer(s) go through each commit and validate that it looks like it does what it says on the tin. as soon as the bottom of the stack gets approved i can merge it in, or i can wait for everything to be reviewed. if there are any changes i do them and rebase the rest of the stack on top of the changed commit, fixing merge conflicts if needed. (it really helps if your tooling supports this workflow, of course!). and when it's all reviewed and merged, the effect is exactly the same as if i'd just sent in a 2000 line combined commit and merged it in - there's no need to go look through the git history for anything, the code will hopefully make sense as part of the codebase.
> I felt that one in my bones. I was up until nearly 2am recently, prompting, because I was so close to getting a plan right. Or so I thought. [...] And it's addictive in a way that makes the isolation worse.
Right, it's more like pulling the lever on slot machine. Oooh, 677, bad luck, do a ritual and try again, and maybe this time...
Sure, regular programming also has a feedback loop, but normal errors are--as much as possible and by design--things that happen consistently for reasons, reasons that force you to engage you mind to discern them and then eliminate them (hopefully) forever. Experienced developers don't just try something random, hope it works, and if it works you just dismiss it as unknowable.
> But the bottleneck was never the code. It was always the human attention, the engineering judgment, the ability to hold a coherent vision for a system. We just didn't notice because writing code felt like the hard part.
Unless, perhaps, you were already fatigued trying to deal with many stakeholders who can't agree what the system even is. :p
I remember when I was just learning how to code and making some web app, I had to do a lot more blind guessing and running. "Ok let me try this... Will that work now?" I remember staying up really late, feeling stuck to the computer in that slot machine mode.
Then when I learned more I got less and less of that guessing feeling. I understood what I was building and what would work, I began using typed languages and could keep on track with the compiler/LSP. This brought me more into a satisfying flow state, and I had less of that addicting "wait let me see if this will work" magic.
It seems like coding with Claude etc is a lot like a trip back to the guesswork stage, and I don't want to go back there.
(Sometimes, when I'm doing some dev-opsy type stuff of stringing a bunch of messy components together or working with a pile of complex APIs, I can feel myself back in the blind guessing territory, and incidentally this is where I find a chat with an LLM most helpful.)
Sadly, I've met too many professional software developers in the industry, who never progressed beyond "Try something, see if it works, then try something else." AI is great for these programmers, since it's somewhat better than what they've done as a career for decades.
It's a trip back to a guesswork stage because most of the training data looks like the process you described your beginnings have been like.
Now you know how to do things first shot. When you write the code, your inner voice reminds you ahead of time to do it like this and that. And that "this and that" is what your prompt needs to have to avoid the trip to guesswork. Working with agents is like working with juniors. If you don't give them the direction and explain how, they'll be as lost as the LLM. The difference is, your brain finds guardrails as you solve the problem, the LLM doesn't have this context, you have to give it upfront. Like, you know, a good manager would.
> The difference is, your brain finds guardrails as you solve the problem, the LLM doesn't have this context, you have to give it upfront. Like, you know, a good manager would
Not really the same feeling. It’s more like speaking a foreign language. At the beginning, you’re always guessing at words, and what’s the correct structure/expression. After a few years, you can go direct from idea to sentences.
Today, my brain is familiar with “computer speak”. More often than not, it goes straight from ideas to algorithms and data structures. My time is mostly spent on checking assumptions (what’s the data type returned by this call,…) and verifying results (debugger, tests, printf,…).
Using LLM is like hiring an unreliable translator when I already know the language. Yes, it may speak faster than me, but I do not a faster pace of conversation.
Yes, and now they don't have to agree, they ask an LLM, and we get half baked plans and quarterly goals and are left to figure it out ourselves. So the stakeholders have some ideas, some half assed designs get put together by an LLM, stories are generated by an LLM, technical details are filled in by an LLM, the implementation and code review are LLM. I can already notice the lack of critical thinking and scrutiny in the whole process, we're offloading all thinking and just creating these artifacts, designs, documentation, code, to what purpose I'm not sure. I'm having trouble even keeping up with everything going on. Of course, plans are more likely to change at any minute and we'll just rewrite everything on a whim.
I'd like to emphasize that SS/OASDI is not an investment program in the first place, it is an insurance program. The two kinds cannot be directly compared, and have very different mechanics and features. You might already have known that, but the misconception is distressingly common in America--which I blame on misinformation from big-bank lobbyists.
> You inherit all risk. But you opt out of the taxes. You must prove retirements assets are being contributed to.
Is inheriting all the risk even possible? Suppose someone signs some dark legal contract in blood, like: "I refuse all public assistance, let me die in a ditch because I shall make my own fate."
What happens if they commit crime (perhaps out of desperation) and are sentenced to time in jail? Now there are three outcomes which all suck differently:
1. The government caves and supports them anyway with taxpayers funding their jail-food and jail-shelter. This distorts the original incentives, and recidivism is going to be a bitch.
2. They are let go, to commit more crimes? Locals won't stand for that.
3. They are indirectly executed by being forcibly exiled to a walled-off isolated place with no food and no shelter, as their families (quite reasonably) cry about the brutality on TV.
Then there's the issue of dependents, and mechanisms for fraud, and both of those are much bigger cans of worms than I want to open in this edit...
reply