We have a codebase at work that was "stuck." We've consistently done minor library upgrades, but no major upgrades in several years, and was recognized as a major piece of technical debt / minor disaster for almost two years, in that we urgently needed to dedicate an engineer to it for a month or more to bring it up to date. We also suspected that framework upgrades would improve performance enough to save us a little bit in operating costs. I got curious, created a branch, and threw Claude at it. Claude knocked it out in a couple of days while I mostly worked on other things. Then we dedicated several engineer days to doing extra manual testing. Done and deployed. Now we're ready to experiment with giving it less resources to see if the performance improvement holds up in practice.

This codebase was only about 200k lines of code, so probably smaller than yours. Really curious how it would go with a larger codebase.

EDIT: Claude may only have taken a couple of days because I was only checking in occasionally to give it further instructions. I don't know how fast it would have been with my complete attention.

When they aren't designed, how do you know how to test?

Over the weekend, I was directed to file a police report with a chatbot and could not complete it because it was asking for information that did not exist and did not apply to my case.

(I'm sure somebody is going to say that this can be solved by having LLMs role play as victims and have an LLM observe and decide what's a failing test case and what isn't.)

Nobody is happy about their property values going down long term. It exposes them to the risk of a big loss if they're forced to sell because of events in their life.

Domain bounds can be dangerous to rely on, but not always. For example, the number of U.S. states is unlikely to change significantly in the lifetime of your codebase.

First, awareness of the futility and selfishness of "growth elsewhere" as a solution is much higher in younger people — and by younger, I mean currently under fifty. Generational turnover in Austin had been eating away at the NIMBY majority, and conversations about housing in Austin have long been polarized more by age than by left/right political sentiment. There's a caricature, with a strong vein of truth, of the old Austin leftist who has Mao's little red book on their shelves and thinks apartment buildings are an abomination, and Austinites of that generation are experiencing mortality. At the same time, younger people are adopting more and more urbanist mindsets compared to their parents.

However, I think a much much bigger factor was the influx of younger people, especially young people with experience of larger cities, diluting the votes of the older NIMBYs. Austin has been shaped by growth for half a century, but its "discovery" in the 2000s and very brief status as a darling of coastal hipsters (remember that term?) has had a lasting effect on Austin's popularity and its demographics. It's been twenty years since it was the "it" place for Brooklynites to visit, but in that twenty years, it's had a lot of exposure for young urban dwellers, and some of them discovered they liked it and moved here, bringing their comfort with dense living and their appreciation that growth can bring a lot of positives.

Personally, every homeowner I know in Austin has seen their houses depreciate significantly this decade, and I don't think it changed a single person's mind about Austin's housing policy. People who opposed the reforms are bitter about the outcome, and people who supported the reforms say it sucks for us personally, but it's what we set out to accomplish, and we're glad that it worked.

For example, I've often heard "premature optimization is the root of all evil" invoked to support opposite sides of the same argument. Pike's rules are much clearer and harder to interpret creatively.

Also, it's amusing that you don't hear this anymore:

> Rule 5 is often shortened to "write stupid code that uses smart objects".

In context, this clearly means that if you invest enough mental work in designing your data structures, it's easy to write simple code to solve your problem. But interpreted through an OO mindset, this could be seen as encouraging one of the classic noob mistakes of the heyday of OO: believing that your code could be as complex as you wanted, without cost, as long as you hid the complicated bits inside member methods on your objects. I'm guessing that "write stupid code that uses smart objects" was a snappy bit of wisdom in the pre-OO days and was discarded as dangerous when the context of OO created a new and harmful way of interpreting it.

However, I think the most fascinating thing about Dijkstra is how wrong he turned out to be in his prediction that an empirical approach would not scale.

I suspect that approaching programming like Dijkstra might have paid off long-term, but it was rarely a good deal in the short term, both for bad reasons (the empirical approach is a quicker and cheaper way to create buggy software that we can sell and claim as achievements on our performance reviews) and valid reasons (the unreliability of humans and hardware ultimately forces us to approach real computer systems, which are always a composite of hardware, software, and humans, empirically anyway.)

So it might be a substantive decision that affects how everybody in the room will do their jobs going forward. Or it could be a random stream of words chosen because they sound impressive, which everyone will nod respectfully at and then ignore. And like an LLM, he might have made it into his current position without needing to know the difference.

If anything, it seems like it would have been comforting to finally have mathematical constructions of the real numbers. It had been disturbing that our previous attempts, the rational and algebraic numbers, were known to be insufficient. The construction of the reals finally succeeded where previous attempts had failed.

> This method created a new sort of infinity that mathematicians were unfamiliar with, and it was vastly larger

I understand that the construction of the reals paved the way for the later revolutionary (and possibly disturbing, for people with strongly held philosophical beliefs about infinity) discovery that one infinity could be larger than another. But in the narrative laid out by the article, that comes later, and to me it's clear (unless I misread it) that the part I quoted is about the construction of the reals, before they worked out ways to compare the cardinality of the reals to the cardinality of the integers and the rationals.

> Suddenly, the monstrosity of infinity, long feared by mathematicians, could no longer be relegated to some unreachable part of the number line. It hid within its every crevice.

I'm vaguely familiar with some of the mathematics, but I have no idea what this is trying to say. The infinity of the rational numbers had been known a thousand years prior by the Greeks, including by Zeno whom the article already mentioned. The Greeks also knew that some quantities could not be expressed as rational numbers.

I would assume the density of irrational numbers was already known as well? Give x < y, it's easy to construct x + (y-x)(sqrt(2))/2.

I don't get what "suddenly" became apparent.

Which makes sense. The reason I wanted to make this app is that there are two very popular paid apps in the same category that I use every day that don't quite feel the way I want them to. It'll be easy to fix the little annoyances and missing features, but there's a feeling that's missing from them as well. I don't think it's wrong to say that I'm put off by a lack of taste, at least according to my taste. I don't know if I can do better, but I'm looking forward to trying, and I love that Claude makes me fast enough that the project has finally tipped from "I'd love to tackle this, but I know it's too big for me" (which is what I've been thinking for the last 5-10 years) to "I can make a credible attempt at this."

That would mean dooming companies to lose the arms race against fraud and spam. If they don't use automation to suspend accounts, their platforms will drown in junk. There's no way human reviewers can keep up with bots that spam forums and marketplaces with fraudulent accounts.

Instead of dictating the means, we should hold companies accountable for everything they do, regardless of whether they use automation or not. Their responsibility shouldn't be diminished by the tools they use.