solatic

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.

Kubernetes is a decent example of vendor-supplied and/or mainstream community effort, but that's beside the point that (a) Kubernetes is the exception, not the rule, and (b) Helm is popular for other reasons that belie non-string wire options, like: value overlays (how would you overlay binary-serialized CBOR again?), type safety for the stringly-typed JSON/YAML passed over the wire powered by validating admission webhooks, remote-executed-on-the-cluster hooks for pre-/post- installs/upgrades/uninstalls (big help for database migrations, for example, which cannot be connected to from the machine running Helm), etc.

> just use up-to-date dependencies

Yeah, sure, I'll file that away with the NPM "tens of thousands of tiny dependencies is OK" thinking. Constant dependency upgrades is a nightmare. There's a reason why shell + Helm is popular - they're stable.

> The python code `my_pod = nignx_pod()` will never throw a syntax error because the result has too many/too few spaces

Yes, but it might throw errors because the client library you're using is too old and attempts to define fields that no longer exist in your newer infrastructure API. You do not find these errors at compile-time, but rather at runtime, and only after both serialization and API request execution finish and you get an error from the API, in the best case, or a silent failure misconfiguring your infrastructure, at worst.

The only time an infra engineer would trust the types is if the vendor themself supplied them, or there's a mainstream community effort to keep them up to date, or they're maintained in-house with procedures to try to keep them up-to-date with new releases. At the end of the day, the API takes a string, not some protobuf or CORBA or God knows what binary serialized monster dujour...

> basic CRUD application with a basic SQL database

The whole problem on the infrastructure side is that the APIs are slow and you don't have exclusive access. Building the CRUD app would be a million times harder if SQL calls took 100x longer to execute and other people could randomly reach into the database and change the schema and data at will - can your basic CRUD app gracefully handle somebody shoving newlines at the end of usernames? Odds are that the first time, no, not until you put a trim() call. And then you cry in pain at needing to put trim() calls everywhere. And then you gnash your teeth at people reporting performance problems because of all the defensive checks you put in because all trust has been thrown out. And then you find out that trim() was deprecated and will now be replaced by strim() that handles Unicode a little differently, and you need to port your code before End of Life to stay compliant.

A basic CRUD application with a basic SQL database doesn't solve the problem, because you don't seem to appreciate that there already is a database - however your vendor stores configuration - and it's your job to deal with it. Adding another database on top of it would make the problem worse.

> How you behave, how you relate to others, how you approach problems and the energy you bring to a team matter as much as your technical ability, and often more.

As much as I agree with this, I don't think that the whole rest of the post (about how best to examine LLM usage in an interview loop) coheres with this.

You cannot conclusively test for common decency in either interviews or recommendations. People are on their best behavior in interviews, and it's rare for someone to pass along a recommendation that will criticize them (or their behavior). Length of tenure at prior organizations is not proof, since too many will tolerate poor behavior. Accept that this is a risk involved with any hire, have clear, written business conduct policy, and be willing to show the door to people who cannot control their behavior after written warnings.

Asking how people approach problems with LLMs need not be more than a conversation. Architectural interviews need little more than a whiteboard. If you wouldn't hover over the shoulder of an employee while they work, why do you feel the need to do so in an interview?

I get it - bad hires are expensive in more ways than one. But screen-to-offer should not take longer than two weeks in small companies. Interviews help you derisk, but do not ever fool yourself into thinking that an interview process will ever reduce your hiring risk to zero. Getting a handful of dates before a shotgun wedding will always be risky. Accept it and learn to be more comfortable with risk.

> the energy you bring to a team matter

This is all the more true for hiring managers. Bad management will take strong, high-energy, high-ownership performers and handcuff them. Good management can, sometimes, take people with weaker skills, train them, set them up for success, and inspire them into becoming great performers. Someone who is interviewing, who might accept your job offer, is also taking a risk on whether you are the bad kind or the good kind of manager. The only difference is that job seekers often have more appetite for that risk than job offerers.

But there are definitely issues with your armadillo SVG?

1. the pedestrian traffic light's hand and "wait, citizen" text are not inside the light itself

2. The armadillo's nose is outside of the astronaut helmet

Isn't that just proof that the pelican has been benchmaxxed?

There's just one problem - culture eats strategy for breakfast. You cannot govern culture or improve culture with metrics.

In large companies (Fortune 1000 etc.), you don't have much of a choice, the culture was eroded long ago, and corporate governance by metrics is a lesser of evils. But thankfully, not all companies are there yet.

There's a very, very big difference between controlling employees working on company laptops during company working hours earning a company salary, and controlling private citizens. Do whatever you like on your private devices on your own time.

Enterprise browsers are not like MDM that take over the entire machine. A contractor on BYOD can install a consumer browser and an enterprise browser side-by-side on his machine, using the enterprise browser (with its controls) for the contracting project and the consumer browser (free and open) for personal ends.

Yep, I see container support is marked coming soon: https://github.com/aws/aws-lambda-roadmap/issues/103 This is your killer feature!

Folks here don't understand how big of a market this is. Island just raised a $400 million Series F at $6.4 billion valuation: https://www.island.io/press/island-announces-400-million-ser...

Mozilla is also very, very far behind in this race. But the potential is real. Enterprises have both the budget and the motivation to care about DLP (including preventing employees from copy/pasting sensitive data into AI chat apps), VPN-less access to private intranet apps (including to contractors on BYOD), preventing access to sites that distract employees and have zero business value (pornography, gambling, etc.)...

If you care about an open web browser, you should care about it having a sustainable revenue model. Enterprise browsers are exactly that revenue model. The question is not whether this is a good idea; the question is whether Mozilla can catch up.

Disappointed by the NodeJS-only requirement and the 128 req/env/sec ceiling.

NodeJS-only feels very pre-AI. Let me tell my agent to write my web service in Rust/C++/C/Go/Zig, and ship a statically-linked single binary that fits within a maximum binary size ceiling. I'd get much better performance, and make much more of the premium CPU/RAM pricing that I'm being asked to pay in exchange for scale-to-zero and fast autoscaling.

The rest is amazing. First-class support as a CloudFront origin. Easy multi-region and gradual deployment. Clearly, finally, a great response to Cloudflare. Just.... so close, and yet, so far. No way am I going back to Node as a web backend for greenfield projects in 2026.

Eagerly awaited, particularly the sections on AI infrastructure.

Stuff that was lacking from the first edition, that it doesn't seem like it will make it into the second edition:

Financial justification and cost optimization, in particular for observability: it's easy to extoll the virtues of collecting metrics, logs, traces, and profiles, but it gets very expensive, very quickly. Conversations about observability quickly throw out the baby with the bath water, rather than laying out clear best practice approaches on when, along the lifecycle of system maturity, additional return on investment can be proven. But FinOps perspectives in general are lacking as well.

Security-focused SRE: rolling out secrets management, permissions management, certificate management, firewall/network management, adapting SIEMs, whether or not traditional SOC work should be integrated with SRE roles and given the same "solve toil like a software engineer" treatment.

I don't know if I'm really suggesting that the book should be twice as long; perhaps there should be multiple volumes: uptime reliability engineering, financial reliability engineering, security reliability engineering, for lack of better phrasing off the top of my head.

> going from 50M of <thing> per day to 2B <thing> per day will break pretty much any system anyone has ever built here

This is likely a pricing failure. Systems breaking due to over-usage is like going to the store and finding that they're sold out. You're much less likely to sell out if you charge more. Meanwhile, GitHub not only didn't raise prices, they cut them at the beginning of the year: https://github.com/resources/insights/2026-pricing-changes-f...

And this is beside them cutting the Pro tier from $7/seat/month to $4/seat/month back in 2020 and not touching the price since: https://docs.github.com/en/get-started/learning-about-github...

Bear in mind as well that the Pro tier includes 3,000 minutes/month and the Enterprise tier ($21/seat/month, and no published minimum seat floors) includes 50,000 minutes/month. $21/50,000 minutes/month for a solopreneur is practically giving away the farm.

GitHub needs to drastically increase pricing, at least for Actions; their current pricing is practically a WTO dumping violation.

GitLab CI, BuildKite, Semaphore, Concourse (development started up again, last release was two weeks ago)...

GitHub Actions is only OK for relatively simple CI needs, or if your project is open-source and you enjoy having free CI. No major professional/enterprise CI need should depend on it.

100% this, but also - linting, fuzzing, and test harnesses. Agents can help build out huge deterministic simulators and fuzzers that were simply too expensive / not feasible a year ago to build for most software - and then happily bind themselves to the results moving forward.

Agents just won't build it out by default - you have to ask for it.