solatic

Part of the problem I have with graphs like this is that they don't differentiate between paper wealth, being able to get a loan against the paper wealth, and hard assets (real estate, vehicles, cash).

Let's take a personal anecdote for an example: I joined a startup when it was early-stage, stayed for a few years, and exercised my stock options when I left. The startup is now "successful", but still private; my shares have also surely been heavily diluted. I have no idea when I'll be able to sell those shares or how much they're really worth. I have no way of turning those shares into quality-of-life improvements for any foreseeable future. Do they make me "wealthy"?

I don't think most Americans have a problem with rich people buying nice houses and nice cars, and using their wealth to pay for private staff. I think the real problem is how much of the wealth is allowed to stay off public markets. Cargill is worth more than $50 billion and its stock is not available on public markets. The growth in wealth of most AI companies - Anthropic, OpenAI - happened off of public markets, and so none of it trickled into the American middle class by their retirement accounts. Venture capital is keeping companies private for longer because, quite simply, none of the investors need the cash to pay for their cost of living, so they're quite happy to let paper gains continue to live on paper.

If your company has revenues of $X million a year or more, you should be forced to make public financial reports (effectively forcing you to list stock on a public market). Period. I think economists will naturally disagree on how much X should be, and that's fine, but I have little doubt that there should be a line like that, somewhere. Concerns about public markets forcing short-term thinking are a different problem, one addressed by mission-lock implements (Eric Ries's recent book Incorruptible is great here). Public markets ensure that gains in wealth are shared more broadly across the economy and increase tax collection by incentivizing more frequent buying and selling of the underlying stock, since those are taxable events.

The "Pro" in MacBook Pro has slowly degraded to "it comes with a fan so that the chip can keep chugging when it gets a hard workload, unlike the MacBook Air where the chip will throttle since there's no fan".

This 100%.

A Mac Mini is what I buy when I need a CI runner to run build, signature, and UI testing for macOS / iOS apps. I also have (one of) mine hooked up to a projector for home theater.

An iMac is what I buy my aging parents so that they can have an Internet terminal in the breakfast nook.

Totally different markets.

Your comment reminded me of the old Thinkpad foldable keyboard: https://www.youtube.com/watch?v=ChlD_ZfpPdw

It makes me think of a Bento-box laptop with a foldable keyboard and a tri-fold display, where both the display and the keyboard unfold when you open the computer. Extremely thick, but a very small footprint when closed.

I'm not sure whether that's amazing or something that'll bankrupt any company that tries to sell it with longer than a 3-day warranty.

This is an overgeneralization.

If your company is larger than Dunbar's number (150 employees), you have low-level employees making median wage and a fraction of a fraction of a percent equity, it's not impossible to have a high-engagement culture, but it would be close to exploitative and at least unhealthy for them.

But a founder accepting a fatalistic viewpoint on this would be signing their own death warrant. There's no room for fatalism in startups. Rather, good founders need to both bring boundless optimism and work to ensure that there is a means for expansion and reward for employees that continues as the company gets larger.

I sympathize with the author, but instead of intensity, I would describe it as externally-observable emotional engagement (though that is a mouthful by comparison). Success follows founders who care deeply about their mission, customers, product, and people, and who succeed in getting other people to care deeply as well.

It is such a stark contrast from corporate culture, where you survive and get promoted by learning to disengage from the mission, customers, and product, and focus on being quietly, not intensely, useful for your boss.

> 128 GB RAM

> $7k

heavy sigh

> when you start moving things away from LA to "save money"

Economic hubs work when there is more efficiency to be found in industrially-codependent resources being located close to each other, than there is in cheaper labor costs outside the hub. Hollywood's heyday was when there was enormous value to putting actors, agents, producers, cameras, sets, editors, VFX, writers all within close driving distance of each other, so that you could organize new movies and shows at the drop of a hat. In a day and age when teenagers are able to use cellphone cameras and pocketmoney to produce stories that are compelling enough to command attention and advertising dollars, the value of that geographic proximity has declined tremendously.

AI didn't build the coffin, but it's been putting nails in it.

I really don't understand how this is so hard for JetBrains.

Build a polyglot IDE that blends the agentic workflow (terminal chat sessions) with the power of an IDE. Index specs and code so that I can jump from specs to implementation and vice versa. Keep indexing all problems found in the project, with a simple "Ask agent to fix" dialog. Expose debuggers with Markdown output to agents via skills so that they stop trying to debug via logging. Keep the nice UI for build/debug/run configurations, which are still hugely important for reviewing PRs and acceptance testing what the agents are giving you. Upsell by charging to host JetBrains-cloud-isolated-agent-workspaces, like what it looks like Herdr is going to do, so that you're not limited by what you can develop solely on your machine, and development continues after you close the lid, and you can review the output with your teammates in multiplayer, like where Zed is going.

Is it really that hard?? It seems so obvious to me.

> anyone not in the US should realize that they need to trust CAs that are outside of their national borders

You say this, in 2026, when the EU is trying to move to an EU Sovereign Cloud Framework: https://commission.europa.eu/news-and-media/news/sovereign-c...

I have a deep problem with your usage of the word "need". EU citizens can make a free choice (or not) to trust US-based certificate authorities, and US citizens can make a free choice (or not) to trust EU-based certificate authorities. There are certainly many reasons why that should be the case. But in a world where we need to negotiate whether food safety standards in X economic block are sufficient for Y's citizens and vice versa, and this is literally the stuff of trade deals, the idea that US-based certificate authorities should be universally trusted because of little more than historical legacy is not the policy position of people who believe in free markets and free choices.

I'm personally happy to assume the risk of trusting Let's Encrypt in spite of the lack of legal recourse.

Trying to equivocate between Let's Encrypt and eMudhra is crazy, as is trying to argue that they should both be trusted globally by default by everybody. I trust LE because of their track record. I had never heard of eMudhra before this.

I can't believe sibling commenters. As a citizen of country X, it should be easy to sympathize with the desire to only do business with other citizens of country X or businesses registered in country X. Why? Because if they wrong me in some way, then I can sue them in a court of law in country X.

All cross-border business is fundamentally import/export and comes with the same risk - that when I am wronged by someone in another country, I have no legal recourse. The exceptions to this rule (like airlines) are such enormous exceptions that there are literally international treaties (e.g. Montreal Convention) to enable it.

Nothing fundamentally US-centric about that point of view.

"will sharpen focus on... trust services other than SSL/TLS"

Is there some reputation left to salvage here that I'm not aware of? Who would trust them?

But that's my point - throw the "background code review" stuff out of cache, or into object storage, or whatever, just something to draw upon to fill inference batches opportunistically.

I mean, at the end of the day, either inference providers are having difficulty filling batches, in which case there's opportunity on the table to somehow fill the batches with discounted, time-insensitive, "background review" style work, or they don't have that difficulty, in which case it's a moot point. Exact cache architectures are beside the point.

How many of these could be enforced with a linter?

"Prefer enum over bool in APIs: Use enum function parameters instead of bool in cases where the purpose of the parameter is not obvious. If you do use bool, consider using an inline comment to document the purpose of the bool in an argument list."

So.... build a linter that refuses boolean parameters, and if there's an exception, then it'll be in the comment that disables the linter for that particular parameter?

And if it's in a linter then you find out waaaaaay faster compared to rolling the dice on whether the human reviewer remembers the rule or not?

Cache is a huge component of "high priority" costs because it essentially forces the GPU to be idle (holding earlier prompt text in GPU memory) while waiting for newer input tokens. When an agentic session is active, this is of course much more preferable compared to loading in hundreds of thousands of input tokens again and again on different GPUs, but "walking away from the laptop" while waiting for the cache to expire is something that royally sucks today for inference providers. (Caveat: this is my layperson's understanding, I don't work in the space, I'm likely not up to date on best-practice caching practices)

"Low-priority" inference tasks like that, though, would never need to be cached. Again, who cares if it takes 12 hours? If you didn't initiate the prompt, then what do you care? You just randomly get notified when something is already ready for you to take a look at.

> workloads can be scheduled on low priority batches

I feel like there's enormous potential still uncovered in the coding agent space for such highly-discounted "spot" style capacity. Give me a way to have agents continuously crawl over my codebase looking for bugs, come up with test cases that prove the bug, open a PR. I don't care if it takes 12 hours to find something that would take 5 minutes if prompted with "on-demand" / "high-priority" requests, because I'm not prompting for it directly, I'm not aware of how much time it takes, all I see is continuous improvement.

But scripts written in PHP are themselves memory-safe. The problem here isn't in a particular PHP script, but rather in the underlying implementation of the PHP runtime, which was written in a memory-unsafe language.

If that's your standard, then Python isn't a memory-safe language either, since CPython is partially written in C. Same as many other memory-safe languages like Ruby, anything in the .NET ecosystem...

> we have built the whole world around an IT revolution that never really reached maturity and became secure

I don't disagree, but how does this relate to this incident, in practice? We're talking about a zero-day vulnerability here. What do you think should have happened - forbid any licensed IT practitioners from deploying PHP at all? No WordPress or Wikipedia?

You don't ask for advice to have someone else make your decisions for you, rather in the hope that you learn about options you didn't otherwise realize were open to you. You ask for advice to "get out of your head".

It may not be right for you, but you'll have made a better decision for having considered it.

> requiring physical access

This is the whole idea behind storing keys in the secure enclave. You can just as easily store the backup YubiKey in a safe as well.

Your backup key should also be in a secure enclave, just in a different secure enclave. Both keys should be accepted by the system.

The truly paranoid can multiple types of secure enclaves - TouchID for primary, a YubiKey for backup.

> If need be on paper

Your security is only as strong as its weakest link. Paper has a way of getting photographed, and the privacy of your key depends on your OCR software, unless you really want to painstakingly copy it in by hand, and even then, it turns into a file-based key on the filesystem, with all its attendant risks.

Yep, 1017 is available at the normal $0.15/$0.06 pricing: https://www.alibabacloud.com/help/en/model-studio/model-pric...

This is no different from AWS charging higher prices for hosting Kubernetes/MySQL/etc. versions that are end-of-life. Keep your stuff maintained and upgrade, to free up the resources.

> Somehow, people have been fighting off disease for eons without antibiotic assistance. Nothing about the emergence of antibiotics changes the fact that humans are more than capable of producing antibodies using just their mushy little white blood cells.

To quote the author:

> I would never actually ship any code anymore without using AI to review it

I can very much understand how the author can come off as calling people insane for not using AI to generate the code itself, but the impression I got is that he's calling people insane for not using AI at all in the coding process, i.e. for refusing to use AI even for code review.

And let's be fair: if you're not willing to let a completely local model (so as to put aside privacy concerns and API cost concerns), in a sandbox with read-only permissions, conduct code review for you in 2026, then yeah, I think you're doing the equivalent of refusing to take antibiotics. You can decide to reject the review results, or re-word the proposed fixes, but to refuse AI assistance at all as a matter of principle during the review stage is no longer a mainstream defensible position.

> Now nobody understands how things work

Well, the fancy calculators do. Yes, they still need guidance to keep from going off the rails. But, at least from personal anecdotal experience, I need to go spelunking into the codebase less and less over time. The agents and models really did just start to become that good.

Anthropic's recent blog post about how they replaced Git should be a massive wakeup call. A trillion-ish dollar company (exact number unimportant here), the vast majority of its value coming from its intellectual property, replacing the storage layer that is an essential part of its system of record for that intellectual property, written pretty much entirely with its in-house Kool-Aid.

Disturbingly little evidence? I would hardly call that "disturbingly little"...

It's not too dissimilar to life as a Principal level engineer pre-AI. You technically oversee the work of many engineers on their own systems, but you couldn't possibly review all the code yourself. You appreciate that human code review reduces, but does not eliminate, the number and severity of bugs shipped to production. You don't have the low-level details in your head, just the high-level ones. You design how all these engineers interact with each other, without stepping on any toes.

Time will tell whether we were right to move from a system where we trusted humans to understand the low-level system, to one where we trust fancy calculators. But so far, it's working.

> Product rarely uses their own product... nobody wants to eat their own dogfood

I somewhat agree with you, and think you're right at least part of the time. The main disagreements I have are (a) dogfooding is not a panacea; it can result in products that are built for the user who pays the least rather than for the wider market, and (b) too often, Product is simply not hired from the market. Product rarely works when the person coming into the role was a software engineer who got an MBA, unless the product is also used by software engineers. I can't imagine trying to lead Product for, say, Excel, without a background as an accountant or banker, who lived with the problem day-in-day-out and has strong opinions about what the solution looks like.

I (think I) agree with the author, but I want to point out that his core grievance has little to do with AI software factories.

> The product changes are primarily additive... I think the reasons for this is that it's lot easier to add new capabilities, than rethink existing capabilities.

This is perhaps the biggest difficulty in Product, and the core of the Innovator's Dilemma. Changes or removals, fundamentally, fuck with how somebody uses your product. It is very, very rare to ship a feature - something that inspired somebody in Product, got all the internal stakeholders to sign off, including getting leadership to fund it - and have nobody use it, so that it isn't controversial to remove it; even then, removing it competes with resources for adding something else, so it's still controversial to remove it. When somebody uses something that you fucked with, you risk them churning, that simple.

Coming up with good features to add is not hard. Everybody and their grandma has ideas. A simple spreadsheet can count which ones are most popular and are proposed most often. This should not, in and of itself, dictate what you build next, and bad Product leadership looks like following mass diktat.

Good Product leadership is not afraid of the consequences of fucking with the user. Good Product leadership has both the courage to reformulate the offering and gets the reformation right, because they intuitively understand the user, the domain, and where they sit in it, better than anyone else. They ship stuff that fucks with you because they understand the difference between the bad kind of being fucked with, and the good kind. And if you churn, then you churn. So be it. You can't actually make everyone happy all the time, so focus on making happy the people who get it, and accept losing the rest. That's also easier to say when you have $100k in ARR with $1k ACV, compared to $5m in ARR with $2.5m ACV.

Good Product leadership is rare because good leadership is rare. AI has nothing to do with it.