But his example doesn’t demonstrate anyone earning $1b. It just demonstrates a very high growth rate at $1-2m.

You will note that PG does not provide such a mechanism for how a $100m company grows into a $10b company (thus producing $b wealth for founders).

Just to be clear. I am not saying at the object level that such growth is impossible. I am saying that at the meta/causal level, PG did not adequately characterize it it.

IOW its a coordination problem. You need most of the other parents in your social group to also implement those controls.

It’s very possible that a policy like this could give everyone a new Schelling point to coordinate around, and thus change the default behavior.

We will see! I certainly agree this policy won’t prevent the kids that really want to use an app.

The actual comparison would be to look at all the startups with billionaire founders (so likely $10B companies) and then analyze the market dynamics that enable them to keep growing so fast.

But the meat of the point is: if the economy is growing at 2.5%, how do you sustain 15% over 5 years?

Look, I’m a startup guy, I buy into the premise that it’s an intensely value-creating activity. But I think it’s self-defeating to pretend like the monopoly and regulatory arbitrage problems don’t exist.

I get that PG and his customers need to be able to cash out, but also, the monopoly rentiers make it more difficult for startups to compete by buying up competitors early and offering crazy salaries that make startups uncompetitive.

All that said, the subtext here is that PG is providing politicians with stories they can tell, nobody in this conversation is trying to describe reality in the most precise or honest way.

There is a middle way; the policy space also includes government regulating both access and monopoly.

I’m opposed to monopolies of this tech, but I hope the risks of giving everyone jailbroken AGI/ASI are clear.

As a toy example you could imagine a Universal Basic AI where government subcontracts to (n_quorum) labs, everyone gets a token budget, but operating the APIs comes with the safety controls.

If everyone does get to run their own jailbroken AGI, then the only stable societal norm I see is A LOT of surveillance to make sure nobody is building CBRNE threats. This doesn’t seem like a clear win from a civil liberty perspective, though I could see the argument.

Now we are getting reactive, arbitrary and capricious enforcement; rules rushed out the door; classified evals. The worst of both worlds.

Don’t sell yourself short! Taste is not promptable, I suspect good taste is AGI-complete.

Especially in domains like fintech, there is a lot of accumulated wisdom, and that is what you’ll be handsomely paid for (for at least the next couple years :/ )

For example, architectural patterns, when you need bitemporality, immutable logs, CQRS, all these good patterns that can only be learned by owning years of system architecture - none of these feedback loops are in the training set.

And from a product design side, agents will just miss key concepts and you need a few words to prompt a fix - but that might represent a massive tree search optimization, or the agent on many cases would just fail to identify the requirement. These small steers feel small, but by evaporation our work has distilled down to just the extremely high value insights.

METR task time is still at weeks, doubling every 7 months; it’s years (assuming we keep riding this crazy exponential) until you hit multi-year tasks. I don’t see wisdom / Métis being solved in 2027.

All this said - I think it’s important to extrapolate forwards, if the trend continues, this will may all be true in 3-5 years. Now is the time to pre-register what metrics would make you worried, so that you can define your red lines. There will be a rapid consolidation of power and wealth if these tools continue on their existing growth trajectory.

There is of course another sense in which the output quality is the only thing that matters. “Can I use agents to build a 1m line codebase that I want to maintain going forward.”

I take this as being exclusively a tech demo of the former. Quality (feature velocity, bugs, scalability) is not demonstrated.

Having a support agent likely made it easier to enumerate the vuln, and certainly made it easier to scale out exploitation once it was discovered.

- scope is important: true, but isn’t that derivable from the commit contents? An important sanity check on a diff is to look at the paths touched. (A “test” diff should not modify prod auth code.) but if you want to see this from —oneline, sure, I think feat(auth): is better than feat:

- wrong audience: I don’t agree. feat commits _should_ actually describe the product-facing changes. You _should_ curate a nice stack with your no-op refactor changes first, then your small new feature change atop. This is the most helpful thing to include in a diff comment. You should put anything technical in comments so they are not lost, “why I chose algorithm X” belongs in a comment or DECISIONS.md. These are all tedious things that only psychos bother doing in a commit history at a fast moving company, but on OSS projects I think it’s much more important to stash context in the commit messages.