solatic

I'm not using this specifically (I'm targeting native apps, not web apps, so Playwright is irrelevant to my stack), but I'm building out (as part of a pre-existing and unrelated project) something very similar (for that project) - having Claude write the script that steps through product usage and captures a recording of it.

Having product videos on your marketing site that are missing everything new that you built in the last six months because, what, you can't be bothered to manually record them for every release, you wouldn't over-engineer things by writing a script for it because you have more important things to build... seems like a very 2025, pre-AI opinion.

There are two kinds of companies: those who know how to build low-level tools that serve as foundation and moat for business growth, and those whose middle managers wring their hands about what their people will be able to maintain and constantly chase off-the-shelf solutions to stitch together.

I know which company I'd rather pick as a vendor.

Let's put it this way - I don't think you could run a Fortune 500 company with 2-3 engineers. I do think there's still a role for "Non-Functional Software Engineers" who are hired to take a long-term perspective on systems maintenance for the golden geese that keep the company's revenues rolling in, handle vendor migrations, stuff like that, which is very different from the responsive, short-term perspective that Product needs. Companies will probably still benefit from people dedicated to their analytics / BI / data pipelines, as an internal product. Roles like Security, Legal, GRC will survive, not because AI can't replace them technically, but because someone still needs to be held accountable. Headcount will still rise with the number of products offered, and eventually you still need the systems and guardrails needed to keep that number of people aligned. All of that is complexity.

You're missing the point about how the industry is going to go through a great narrowing. In the past, you'd have one PM and 8-12 engineers. Now you only need 2-3 people with both product and engineering ("architecture", to quote the author) skillsets. You are absolutely correct that most engineers are not interested in the Product side - those are the engineers who are going to get cut in this great narrowing. Quoting the author:

> I grew up with the distinction of "tech guy" needs a "product guy". I am not dismissing it, I am just saying that the world is entering into a phase where both roles are eventually melting into a single function.

The whole reason why Engineering exists in organizations is to take Product's ideas and turn them into reality. When Product can realize its own ideas (through AI) then Engineering is no longer necessary as a political sub-organization. Making it happen requires engineers to learn Product skills and adopt a "Product" job title. We will likely call people with both skillsets Product Engineers. People who can't adapt to learning both skillsets are at risk of losing their jobs.

Ops is bifurcating in two:

* AI-resistant organizations led by graybeards who refuse to send telemetry off-prem (to either observability vendors or to inference providers) and will be dragged, kicking and screaming, into the future, over their cold, dead bodies. There's a lot of large, conservative organizations in this category like banks and governments, where budgets are rubber-stamped and Don't Break It If It Ain't Broken attitudes are tacitly approved of.

* AI-accepting organizations where Ops will go through the same great narrowing that Dev is going through now - build the dark factory and let it run. You do still need people who know what good architecture looks like and to shepherd changes to improve the overall system to make it more observable, scalable, and maintainable. You do still need Non-Functional Software Engineers who don't answer to Product, for the sheer political reason that you need people who have a long-term perspective, compared to Product that has a short-term perspective. The business will make decisions like "Vendor X is too expensive so we're migrating to Vendor Y" and you will need somebody to drive the agents to make that happen in a way that respects availability and compliance requirements. You probably don't need, in the long-term, a whole team of people to handle it, let alone a whole group or a whole division.

At the end of the day... focus on being a strong engineer. Somebody will always be needed to take care of the trees.

There are genuine, obvious benefits to having a larger screen. People are limited by the size of what can fit in their pants pockets, and the need to carry at least one device that they can hold up to their ear (i.e. with one hand) for phone calls. The market of people who are willing to carry one device is much larger than the market of people willing to carry multiple devices (i.e. a separate tablet).

The question isn't whether or not there's value to unlock in the foldables category, it's whether manufacturers can get the product right, and overcome durability concerns among a consumer base that is righteously conservative about durability concerns on high-cost devices that they depend on every day.

My current anecdotal example: if you're building cross-platform native apps, you need to run agents on macOS and Windows, because xcodebuild only runs on macOS and the Windows SDK is only available on Windows.

The mistake is believing that you can make no mistakes. Either you make a mistake by taking too long to polish everything to a blinding sheen, or you ship at a reasonable frequency and sometimes make mistakes in what you ship.

GCP got really, really good in the last few years. The cross-account story is now better on GCP than on AWS. BigQuery, Spanner, Pub/Sub, GKE are all best-in-class. AWS has its advantages too: CloudFront, Lambda, S3, DynamoDB, and IPv6 support are all best-in-class. It really just depends on what your product's actual architectural needs are, and whether you have access to nosebleed budget to pay for it all (these services are all staggeringly expensive).

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.