throwaway041207

Multiple times a week.

The Maverick is actually the size of an F150 from 1990. Similar to how the Colorado/Ranger today is the size of a full size truck in the 2000's

A 13th gen RCSB F-150 is only modestly larger than a 1990 RCSB by your definition here, but we know that's not practically true because you are only comparing very specific measurements. Anyone that's had an OBS and been around Mavericks would never say the Maverick is the actual size of an OBS F-150.

Trucks are bigger than ever, that's self evident, but saying an OBS and Maverick are the same size is a stretch.

This reductionism doesn't seem useful. The population of people who want to buy homes has not grown in any way that is proportional to the cost of a home.

In my neck of the woods (New England), home prices have doubled since March of 2020. I have yet to read a comprehensive overview of how this happened and how we get out of it. Of course, people went nuts offering over the asking price when interest rates were super low so I understand, to some degree, that baselines were reset.

But the current housing market doesn't feel sustainable. I don't understand how a proper middle class family could afford to buy in this environment, unless they are willing to put off any savings indefinitely.

I don't think the writing style has anything to do with AI, it's just a writer without an editor.

Zed is nice, but the project wide search (sidebar based) in VS Code and diff viewer in VS Code are still better IMO and unfortunately since I no longer code, those are my most used features of an editor. Still using it instead of VS Code but I sure wish it improved those views.

Small world.

Indeed. I lived there for 4-5 years and left right before they started tearing down Fry Street. At that time I could see Bill Callahan at Rubber Gloves for 5 dollars, then head to the square and get my fill. Leave my car and walk home. Wake up and do it again, but instead see The Black Angels in someones house. Saw many great shows at Dan's Silverleaf and saw a number of terrible art exhibitions from the students. I had moved to the east coast by the time they burned down the Flying Tomato and it seemed like a fitting end given what I saw of the place the last time I had visited in early 2007.

I'm very fond of that place at that time. I used to commute straight into the metroplex and back out to Denton. I'd get home and park my car and have most everything a dude in his early 20s needed in walking distance.

No, it was around but it was probably just Stroh's in the can at that point. I drank a ton of it at a dollar a can in the early 00's (RIP J&J's Pizza, Denton, TX). This would have been after the PBR buy out and it was probably whatever the Stroh's formula was.

I drank a bunch of these PBR owned zombie brands over the last 20 years, Black Label, Schlitz, Old Milwaukee, Lone Star, etc [1] and I've always wondered when I'm drinking one if it's the same flavor as one from previous years or even if the flavor is consistent across regions (assuming PBR was just slapping labels on contracted brewing).

[1] https://www.beeradvocate.com/beer/profile/447/

This is actually kind of validating. I work for a company that spends almost 1mm a year on GCP. We've never had an actual support contract with them because the numbers work out to, at a minimum, being 10% of our spend. We've yet to encounter a situation where we actually needed GCP support, so we've held off. In the moments where we'd like to get some support (mostly around datastore behavior) we've managed to work around it or figure it out ourselves. So it's good to know we haven't missed out on much. Beyond the offensive aspect of GCP offering no support if we aren't willing to cough up a non-trivial percentage of our spend, I'm pretty happy with it.

Assuming we are talking about Code/Codex are you on API billing or subscription? I have essentially unlimited API billing at my disposal and I haven't noticed any degradation of quality across Opus versions.

Yep, I timed the top of the market perfectly and cashed out 5 BTC at ~$80/BTC.

Parent didn't say Claude Code is best at anything?

If you are working with AI to define the purpose and goal of the change -- which is to say planning how the changes to the code should result in some sort of feature/bugfix/whatever, then planning phase should ask you to define clear success conditions for the code that it writes. These could be otel/datadog metrics, or some kind of funnel metric or some cessation of errors in your APM, whatern. In any case the outcome of the change is what I mean by validate/verify. Mediocre code can solve issues and we can tolerate mediocre code in that sense. The guardrails kick back failing "mediocre" code, it accepts working mediocre code.

And this could easily apply to every change we made by hand before AI, it was just a tedious process to layer these things into code when we were just fixing bugs and whatnot. In an AI writes all the code world adding this kind of stuff as table stakes for a changeset is zero cost, effort wise.

And yet you are citing some concrete report you aren't sharing. The problem with your original comment is you scoped it to subscribers (which I assume is how this unshared report was framed). API billing for enterprises will far surpass that number in individual users. Claude Code is available at my org to every person employed here and that's just shy of 2k people, and I can say with confidence we are not 3% of Anthropics customer base alone.

Stripe uses Sorbet which, in my experience, increases LOC.

Sorry I wasn't very clear about that part. I think success conditions are described by stakeholders, whoever that is, and then the implementation of monitoring them is probably created by the LLM. For engineering level stakeholders that's going to be metrics, performance, etc. Whereas for more business side stakeholders that'll be a mix of data metrics and product feature metrics, click-through rates, stuff like that

2. AI doesn't need to be perfect, just "good enough", whatever that means for a specific project. More failures while saving hundreds of thousands dollars each year might be acceptable, for example.

This I think is the unexplored aspect of what's happening right now. Guardrails around "good enough" systems is where the future value lies. In the future code will never be as good as when the artisans were writing it, but if you have an automated process to validate/verify mediocre code (and kick it back to AI for refinement when it fails) before it's fully productionized, then you have a pathway to scaling agentic coding.

Another point: Software Engineering always starts where tooling capabilities stop. You don't get a competitive advantage by building without engineers what anybody everybody else can build without engineers.

I'd note here that the long arc of software engineering has been commodifying the discipline into tooling. Ask any unix greybeard how shitty modern abstractions are and they'll give you all you can stomach and yet the wheel turns despite their treasured insights.

Just as "use code for contracts" failed for crypto currencies, "use AI output as prod" will fail for AI. Both is based on "just don't make catastrophic mistakes anymore".

What I think will happen is AI will write code and it will do the best it can to mitigate mistakes prior to rollout, but once rollout time occurs, rollout will be incremental and it will self monitor by defining success conditions at rollout time. The nature of the code will mitigate "catastrophe" to a small group at worst, but most likely initial rollout will just run new versions of the code in a simulated context (language design could benefit from this) and analyze potential outcomes without affecting current functionality.

But when the code goes live... it will be slowly scope changes progressively (think feature/experiment flags) and if it fails in the initial cohort, it will redirect. If success is positive, it will increase the rollout cohort.

This is a normal software engineering practice today, but it's labor and process intensive when driven by humans. But in a world where humans are less involved, this process is scalable.

more disciplined and enforce rigour

Eventually this will be automated as well. Discipline, rigor and correctness are not strictly human tasks.

I certainly think that is true of the current moment, but where I think this is going is towards a model where the cost of human labor collapses, feature delivery slows (relative to the churn that is happening now), but becomes more predictable and less error prone (in terms of final delivery). I think that is the model that we see in manufacturing, and I think it's probably going to replicate in software engineering. New code (that a human didn't even look at, tbh) will be stress tested for correctness, progressively introduced and final delivery will be easy to forecast and most of the time will be delivered on time.

FAs have very interesting schedules. As they work up seniority they have a ton of flexibility in how they space apart their required minimum number of shifts/overnights. Trading shifts and bidding for shifts is common. Additionally at some point in their seniority ladder they can start getting a regular set of shifts that get them back home to base daily, with occasional overnights.

I suspect this institutional flexibility is actually a natural consequence of the gendered nature of the role.

IMO, by the time todays juniors would have 5-10 years of expected experience, the entire field will be something different altogether. Language choice distribution will collapse (if not change altogether), whole new modalities of monitoring and progressive delivery guardrails will come into play, essentially creating a 24/7 incremental rollout of pure agentic code, correctness will be determined by a mix of language features and self-monitoring by models in production and automated testing against production snapshots in pre-production, and deep debugging will the be province of a select group of engineers and there will be a pathway to those roles for juniors, but those roles will be coveted and difficult to break into (and probably will require education and maybe even informal accreditation).

Very cool post. I don't fly much anymore, by choice. But I'm always impressed at the scale and complexity that it takes to operate an airline like Southwest. I appreciate you sharing. Sorry you didn't get to see the actual NOC!

Whether this is deployed via Helm charts or a native controller, there's almost certainly some overlay where you can override resource values, unless this is just a very crappy vendor.

And it doesn't even have to do with these tools in the end, this is a disaster recovery issue at its root. If you are a revenue generating business and using any provider other than AWS or GCP and you don't have an off prem/multi-cloud replica/daily backup of your database and object store, you should be working on that yesterday. Even if you are on one of the major cloud providers and trust regional availability, you should still have that unless it's just cost-prohibitive because of the size of the data.

GCP Cloud SQL has the same deletion protection feature, but it also has a feature where if you delete the database, it doesn't delete backups for a certain period of days. If someone is reading this and uses Cloud SQL, I highly suggest you go make sure that check box is checked.

Agree. For years I had developed my own preferred way of deploying Rails apps large and small on VMs: haproxy, nginx, supervisord, ufw, the actual deploy tooling (capistrano and other alternatives) and so on... and if those tools are old or defunct now it's because my knowledge of that world basically halted 8 years ago because I've never had to configure anything but k8s since then.

I've used it every day since then so I have the luxury of knowing it well. So the frustrations that the new or casual user may have are not the same for me.

Claude Code has essentially fixed this perpetual annoyance for me. Doesn't matter if it's a hacked up deploy.sh that mixes sed, envsubst and god knows what or a non-idiomatic Helm chart that was perpetually on my backlog to fix... today I just say "make this do this thing and also fix any bash bugs along the way" and it just does it. Its effectiveness for these thousand-little-cuts type DevOps tasks is underrated IMO.

Now the actual CI/CD/thing-doers tools that all suck... I'm still stuck with those.

If this stabilizes and gets networking support, there are definitely projects that I'll be able to use this for, and the buy-in will be easier than proposing Crystal.