Well the central post that the commenter made about the army’s iq requirement is trivially fact checked to be untrue. The army doesn’t administer iq tests as part of screening. They do asvab which tests _knowledge_ which you can study for. They have correlated outcomes in that a high IQ usually means a high asvab but they aren’t identical (you can for instance top out an asvab test and practice shows meaningful improvement whereas there is no top iq and if you can practice for it the test is flawed.)
The vast majority of public shareholders don't vote their shares. A VC is much more likely to apply unwanted pressure to the board/management than the general public is.
IMO, the best reason to avoid an IPO is to stay out of the media.
The VC likely already has ownership, and a board seat - public companies are susceptible to activist-investors and hostile bids: outsiders who hold little/no stake, but an outsized influence.
Neither of which would be relevant in the Stripe case, because if Stripe IPO's they'll release a negligible number of shares. It'd be impossible for either group to amass a substantial number of shares.
A low liquidity IPO would likely result in a massive share price increase: the number of interested buyers would vastly outnumber the number of shares available.
Harder for activist investors to get into a private company than a public one imho. Keeps out those who would squeeze the business and bail, and potentially kick out the founders. With sufficient cashflow (which Stripe most certainly has), you can buy out existing investors without going public.
(not ex-Stripe, but own startup equity and have no problem with them never going public if that is the choice; optimize for the enterprise and existing stakeholders, not the public market mechanics broadly speaking)
You'd need to amass 50% of the shares to kick out the founders. That'd be impossible for a hostile party to do if Stripe IPO's because they wouldn't release anywhere close to that number of shares.
The only way to kick out the Collison's would be for the VC's to do it. They currently own 80%. It's easier for the VC's to do that if Stripe stays private than if Stripe IPO's.
Not sure I understand the joke but to be clear it’s a Spanish soccer (football) league blocking the ips not an American football (football egg) league.
> Otherwise it’s the same as just leaving the illegal tax in effect.
The SCOTUS didn't say that in their decision. No matter how you call it, the tariffs were found in breach with simple law passed by Congress - that is, the undoing of tariffs can be legislated by Congress and it can take any shape they like - it will be legal. Anyway, fine-tuning this is a waste of time, the big problems are elsewhere.
They don't have to say it in their decision. Their only remit was to determine whether the tax was legal or not. It is not. Lower courts will then hear cases about disbursement of the illegitimate takings; those cases will almost certainly not make it up to the Supreme Court.
The money is getting "returned", at least in some fashion. The parent commenter is right.
I regularly run the same prompts twice and through different models. Particularly, when making changes to agent metadata like agent files or skills.
At least weekly I run a set of prompts to compare codex/claude against each other. This is quite easy the prompt sessions are just text files that are saved.
The problem is doing it enough for statistical significance and judging the output as better or not.
Sweeps and obo accounts are the bone simple answer to this that every mainline treasury has used for this problem for at least 30 years.
Further the banking ecosystem in the US is predicated on the idea that depositors, especially large ones, are doing their own diligence on the health of the bank.
The person they are responding with dictated an authoritative framing that isn’t true.
I know people have emotional responses to this, but if you think people aren’t effectively using agents to ship code in lots of domains, including existing legacy code bases, you are incorrect.
Do we know exactly how to do that well, of course not, we still fruitlessly argue about how humans should write software. But there is a growing body of techniques on how to do agent first development, and a lot of those techniques are naturally converging because they work.
The views I see often shared here are typical of those in the trenches of the tech industry: conservative.
I get it; I do. It's rapidly challenging the paradigm that we've setup over the years in a way that it's incredibly jarring, but this is going to be our new reality or you're going to be left behind in MOST industries; highly regulated industries are a different beast.
So; instead of just out-of-hand dismissing this, figure out the best ways to integrate agents into your and your teams'/companies' workstreams. It will accelerate the work and change your role from what it is today to something different; something that takes time and experience to work with.
> I get it; I do. It's rapidly challenging the paradigm that we've setup over the years in a way that it's incredibly jarring,
But it's not the argument. The argument is that these tools provide lower-quality output and checking this output often takes more time than doing this work oneself. It's not that "we're conservative and afraid of changes", heck, you're talking to a crowd that used to celebrate a new JS framework every week!
There is a push to accept lower quality and to treat it as a new normal, and people who appreciate high-quality architecture and code express their concern.
"Find any inconsistencies that should be addressed in this codebase according to DRY and related best practices"
This doesn't hurt to try and will give valuable and detailed feedback much more quickly than even an experienced developer seeing the project for the first time.
These kinds of instructions are the main added value of LLMs and I use them every day. Even though 30%-60% the output is wrong/irrelevant, the rest is helpful enough. After the human reviews it, the overall quality of the codebase increases, not decreases. This is on the opposite end of the spectrum when compared to agentic coding, though.
I tend to have between 4-15 agent sessions going at once, but importantly I’m counting agents that are awaiting inputs from me.
My agent orchestration system is a bespoke python program that I vibed just for me. It is one of thousands of systems that combines git worktrees and devcontainers. But I’ve customized it for my quirks and workflows. The big win is I can decide on a repo by repo basis what level of permissions to give an agent from yolo mode to very limited permissions.
In that agent count there are usually 3-5 sessions that are my main tasks mixed between research, planning,coding and code review. The balance of the sessions are sessions for other tasks, improving tests, adding new kinds of guard rails, projects that are ancillary etc.
reply