bccdee

Splitting one big codebase into 100 microservices always seems tempting, except that big codebases already exist in modules and that doesn't stop one module's concerns from polluting the other modules' code. What you've got now is 100 different repositories that all depend on each other, get deployed separately, and can only be tested with some awful docker-compose setup. Frankly, given the impedance of hopping back and forth between repos separated by APIs, I'd expect an LLM to do far worse in a microservice ecosystem than in an equivalent monolith.

> How many highway over passes have unique “chef quality” designs?

Have you ever built a highway overpass? That kind of engineering is complex and interdisciplinary. You need to carry out extensive traffic pattern analysis and soil composition testing to even know where it should go.

We're at a point where we've already automated all the simple stuff. If you want a website, you don't type out html tags. You use Squarespace or Wordpress or whatever. If you need a backend, you use Airtable. We already spend most of our time on the tricky stuff. Sure, it's nice that LLMs can smooth the rough edges of workflows that nobody's bothered to refine yet, but the software commodities of the world have already been commodified.

Ok but you understand that the fundamental nature of LLMs amplifies errors, right? A hallucination is, by definition, a series of tokens which is plausible enough to be indistinguishable from fact to the model. If you ask an LLM to explain its own hallucinations to you, it will gladly do so, and do it in a way that makes them seem utterly natural. If you ask an LLM to explain its motivations for having done something, it will extemporize whichever motivation feels the most plausible in the moment you're asking it.

LLMs can be handy, but they're not trustworthy. "Own and be responsible for the code you commit" is an impossible ideal to uphold if you never actually sit down and internalize the code in your code base. No "summaries," no "explanations."

What if you're calling an API? How do you test a tool that does a bunch of back-and-forth with another service without actually hitting that other service? Do you have to spin up your entire k8s ecosystem in a local cluster just to validate that the logic in one function is sound? Do you have to deliberately misconfigure it in order to test that your function handles errors properly?

More broadly, suppose foo() has an implementation that depends on Bar, but Bar is complicated to instantiate because it needs to know about 5 external services. Fortunately foo() only depends on a narrow sliver of Bar's functionality. Why not wrap Bar in a narrow interface—only the bits foo() depends on—and fake it?

I'm not a maximalist about test doubles. I prefer to factor out my I/O until it's high-level enough that it doesn't need unit tests. But that's not always an option, and I'd rather be flexible and use a test double than burden all my unit tests with the full weight of their production dependencies.

Martin Fowler draws a useful distinction between mocks, fakes, and stubs¹. Fakes contain some amount of internal logic, e.g. a remote key-value store can be faked with a hashmap. Stubs are a bit dumber—they have no internal logic & just return pre-defined values. Mocks, though, are rigged to assert that certain calls were made with certain parameters. You write something like `myMock.Expect("sum").Args(1, 2).Returns(3)`, and then when you call `myMock.AssertExpectations()`, the test fails unless you called `myMock.sum(1, 2)` somewhere.

People often use the word "mock" to describe all of these things interchangeably², and mocking frameworks can be useful for writing stubs or fakes. However, I think it's important to distinguish between them, because tests that use mocks (as distinct from stubs and fakes) are tightly coupled to implementation, which makes them very fragile. Stubs are fine, and fakes are fine when stubs aren't enough, but mocks are just a bad idea.

[1]: https://martinfowler.com/articles/mocksArentStubs.html

[2]: The generic term Fowler prefers is "test double."

There's no simple replacement for what Protobuf does. Forwards and backwards compatibility is well-specified across clients in all languages. I can write a v2 message with new fields and pass it to a service written in a different language based on the v1 message schema. That service can modify the message using only its v1 schema, but when it re-emits the modified message, its original v2 fields will be intact.

You may think, "I don't need that," but once you've got more than a couple microservices, you'd be surprised how many headaches this type of compatibility issue can cause. You may think, "I can do that with json," but can you do exactly the same version of it across 4 or 5 different languages while maintaining a single source of truth for each message type's schema? At that point, you're just rebuilding Protobuf.

Afaik the only other tool that does what Protobuf does is Avro, though I haven't used it. I have tried to use json-schema for this, but that's not what it was made for. The schema evolution story is worse, and the codegen isn't as good.

Sure I do. The integration looks like this:

  jmsg, _ := protojson.Marshal(msg)
  fmt.Println(jmsg)

That's negligible.

> For the negligible added CPU cost of deserialization, you completely lose human readability.

You could turn that around & say that, for the negligible human cost of using a tool to read the messages, your entire system becomes slower.

After all, as soon as you gzip your JSON, it ceases to be human-readable. Now you have to un-gzip it first. Piping a message through a command to read it is not actually such a big deal.

That's one thing I'll say for in-house "mini-frameworks": Real frameworks often try to present a smooth façade of abstraction which is hard to punch holes through. An in-house "mini-framework," though, is often just a hodgepodge of compostable abstractions which you can individually take or leave without too much hassle.

Of course, your hodgepodge ecosystem will eventually ends up a bit of a mess, but I'll take that over a flashy off-the-shelf framework that insists on handling everything itself.

Okay? The framework being proposed here is designed to enable universal communications surveillance. No combination of "details" would make that acceptable.

Why? "This was written badly" is a perfectly normal thing to say; "this was written badly because you didn't put in the effort of writing it yourself" doubly so.

> Nope. More apartments mean more _expensive_ rent. This is an ironclad law of real real estate.

I don't know how to explain to you that an increase in supply results in the price of a good decreasing.

> Yup. And the rent is high because...?

High demand, low supply. Obviously.

> check the average pay in areas that don't have direct access to the city cores and the average pay in Downtowns

Yeah, because downtown office space costs more & goes disproportionately to higher-paying finance jobs. That has nothing to do with density—that's just finance bros wanting to work in the fanciest skyscrapers.

> The average total expense for _new_ cars in the US is about $1000 per month

Your source refers to cars generally: "As of 2025, the average annual cost of owning a car in the U.S. has reached approximately $12,297, translating to about $1,025 per month." Even with your $500/month figure, transit is still much cheaper. And that $500 isn't just distributed among riders—drivers pay some of it too, as they should, since every person on the subway is person not driving on the road, reducing the need for road infrastructure maintenance & expansion.

> Just one mile of tunnel in Manhattan now costs more than 1500 miles of 6-lane freeway!

Again, Manhattan is unique. I don't know why you keep referring back to it as if its problems are easily generalizable. They put their trash on the street in bags because they don't have room for dumpsters. Also, yes, that's why LRTs are popular—no tunnel required.

> The TRUE cost of one month's pass is about $3000 (with capital cost).

Lol as if you can't just look up the transit commission's budget. (Annual budget) ÷ (average daily ridership × 12 months per year) = $180 per month per rider at most (since the pool of riders is larger than the daily average).

> Yes, and it is metastasizing into other neighborhoods.

Good. More apartments means cheaper rent.

> If density works so well, why is there a significant number of people too poor to buy groceries?

The cost of living is high because rent is expensive, obviously. I never said it was cheap to live in NYC. Focus on the actual subject of our discussion, please. Do you think rent in Manhattan would be cheaper if there were fewer apartments?

> Not anymore.

You're just saying stuff now. Only 40% of jobs are located downtown in my city, and compared to the other cities I saw when I was poking around for this data, that's high.

Oh wait, oh my god

> Three levels down and people have entirely forgotten what my post was.

I missed this reply entirely. Whoops.

That said, I do feel like you can do HTML templates on a tiny chip with 64 megs of memory. I've seen NASes with comparably tiny & terrible chips serve their web UIs this way: paper-thin html templates with <form>s for interactivity and <table>s for layout.

1. No, templating strings is actually quite cheap. I'm doubtful that you could benchmark any substantial difference between templating html and serializing json.

2. Who has a server with a weak, limited processor? HTML templates power Django, Rails, and PHP. This paradigm worked fine on the servers of 20 years ago, in the slowest languages we use. I could serve a Django app on my phone and see reasonable performance.

> It has to load HTML templates into memory and insert strings into them.

In practice, I doubt this is much slower than serializing JSON. Keeping a couple kilobytes of HTML templates in memory is nothing. Conversely, running a whole vdom on the frontend (typically more resource-constrained than the server) is a much bigger performance issue.

Well yeah, HTMX wouldn't be a good fit for micro-frontends, but I didn't think many people were actually using those. You have to write all your html in accordance with a single stylesheet, but that strikes me as the least of HTMX's impositions.

"What happened to Rust" is that it got a lot of coverage for being good, then a few people were annoying about how good it is, and now a large number of other people have become annoying in their complaints about how annoying the first group was. Meanwhile, Rust & its community remain unaffected; adoption continues to grow, and Rust now used in the kernel, Windows, Android, AWS infra, etc.

The problem you've encountered is that people are annoying. I'm afraid that's not specific to any one technology or community. Fortunately, annoying blog posts are easily ignored and would never stop a useful tool from being adopted anyway.

> None. You're losing money by not living in a cheaper place and overpaying for transit.

Oo, totally wrong! Fun guess though. The average monthly cost of car ownership is $1,300. The cost of a one-month transit pass is $150. I'm not gonna save $1,150 on rent by moving to a shitty suburb.

> So you're in Manhattan?

Nope.

> Wrong. Hint: Manhattan is one of the most expensive places in the US.

Yeah, because there's a shortage of apartments—that's what I said. Manhattan Island (being a rather small island) has physically run out of room for buildings, but that's not true of other areas.

> And recently elected a socialist who was promising state-run grocery stores.

Ok? So what? Maybe they'll expose private-sector price fixing & maybe they'll just be grocery stores.

> Because toxic urbanism strangled the democracy with bike lanes.

I'm honestly baffled. What makes you think bike lanes are undemocratic? Bikes are super cheap and take up very little space. Bike lanes really cut down on traffic.

> This in turn makes housing near Downtowns more expensive because workers have to live there in order to get a job.

Have you heard of industrial parks? It's pretty common for offices in big cities to be outside the city centre—far more common on the whole than downtown offices are.

The big advantage of downtown offices is that a city's downtown is the nexus of its public transit: If you work downtown, you can easily live a ways outside the city on cheaper land and then come in by train. So no, the point of a downtown is that you don't need to live there to work there.

Do you actually live in a city? I feel like you don't have a very strong understanding of how they're structured.

I live in a big city with decent transit. I'm in my late 20s. Neither I nor any of my (white-collar professional) peers own cars. Do you have any idea how much money we save?

And yeah, bike lanes are part of it too. They make it easy to get around quickly & cheaply. Our bike lanes are packed with bicycle couriers and the impact on traffic is practically zero. Bike lanes are popular because they work.

High rent is caused by low supply of high-density housing. Apartment blocks are cheap. It's bad zoning, NIMBYs, and a slow pace of construction due to disproportionate focus on luxury units that cause housing supply issues.

> The third option is to LIVE IN CHEAPER PLACES. The US has 1.1 housing units per household.

Yeah, you know why people don't live in those places? They're in exurbs of Arizona, a thousand miles from anything. During the housing bubble, we built a bunch of homes in unlivable areas and now we're dealing with the fact that they're functionally useless.

The market for labour is a monopsony (the limited number of buyers relative to sellers make it a buyer's market). Just as suppressing price in a monopolistic market is unlikely to drive down supply and can actually increase overall sales, recent minimum wage increases have been found to have a net positive effect on employment.

> We present the first causal analysis of recent large minimum wage increases, focusing on 47 large U.S. counties that reached $15 or more by 2022q1. [...] We then find significant and larger positive employment effects, as the monopsony model predicts. We go on to document the presence of monopsony in the restau- rant industry. [...] The fast food industry’s monopsony power allowed it to accommodate large minimum wage increases and raise employment.

Source: https://irle.berkeley.edu/wp-content/uploads/2023/09/Minimum...

I think that leans toward a mistaken veneration of productivity. You don't have to make something to enrich your life. It's also valuable to connect with the things other people make, or with the world around you.

True to an extent. But why would you want to create (e.g.) a movie if you don't think watching movies is worthwhile in and of itself? You're putting effort into creating something that you don't think is truly valuable. To a person with this mindset, the desire to create is cynical—they're only making movies in pursuit of extrinsic rewards such as money, fame, or success. If watching movies is thin to them, then making movies is also thin.

Conversely, an authentic filmmaker is someone who values movies in and of themselves; therefore, the authentic desire to create a movie must be downstream of a passion for watching movies. I don't think you'll find many artistically inclined filmmakers who would denigrate the act of watching movies as "thin." It's the thickness they feel in the experience of watching movies which inspired them to devote themselves to making movies in the first place.

Oh I really worry about that. AI code at least needs to pass unit tests, but there's no way to prove that the ideas in an AI document make sense until you try them and run into issues. Writing is thinking. If you let a robot do it, you aren't.

If you're making a proposal, I feel like an RFC carries a lot more weight than a slideshow or an email. If you really don't need feedback or approval from anyone, sure, go it alone. But if you do need or want to run it past someone, let the document you send them reflect the amount of thought you've put into it, and then maybe they'll hesitate before going off half-cocked & suggesting some idea you already considered.

> This leads to authors having to re-explain their thinking in detail

What I like about RFCs (or similar documents) is the ways they work to prevent this. Recently I was involved in planning an initiative without a document like this, and we had to keep explaining and re-explaining the motivation for our decisions to stakeholders and higher-ups. With a document (assuming everyone reads the document before giving feedback), most questions get pre-empted; the ones that don't only need to be addressed once, because the answers end up in the version of the doc which you show to the next person.

Certainly I think it's worth being selective about who you're soliciting comments from, to avoid a too-many-cooks situation, but rare is the project that doesn't need anyone's approval or feedback. Presenting a big fat document gives a sense for the amount of thought that has gone into the design, which quells the kind of off-the-cuff "why not X?" comment you might get in response to a boxes-and-arrows chart and a high-level summary.

Yeah but there are zero barriers to market. France can't sell its nuclear energy to Australia, but anyone anywhere can release software. If anyone is exploiting this, it should be visible to everyone.

Companies can release games with crap performance because nobody else is making the same game as them. The idea being put forth here is that, with AI, you can just clone someone's product for nothing. So why isn't that happening?

Ideas were never worth much. Implementing a quick prototype was always pretty simple. How easy is it, with modern tooling, to build a collaborative web editor? Just slap together prosemirror and automerge and you're already there. Still, nobody has displaced Google Docs.

The value proposition of SaaS is ultimately just that it's not a hack.

Most SaaS products could be replaced by a form + spreadsheet + email workflow, and the reason they aren't is that people don't want to be dealing with a hacky solution. Devs can hack together a nice little webapp instead of a network of spreadsheets, but it's still a hack. Factoring in AI assistance, perhaps SaaS is now competing with "something I hacked together in a week" as opposed to "something I hacked together in a month," but it's a hack either way.

I am absolutely going to pay for analytics and dashboards, because I don't want the operational concerns of my Elasticsearch analytics cluster getting in the way of the alarm that goes off when my primary database catches fire. Ops visibility is too important to be a hack, regardless of how quickly I could implement that hack.

> Why didn't they? Hint: it's not because it would have taken them longer without AI.

Yes it is. "How much will this cost us to build" is a key component of the build-vs-buy decision. If you build it yourself, you get something tailored to your needs; however, it also costs money to make & maintain.

If the cost of making & maintaining software went down, we'd see people choosing more frequently to build rather than buy. Are we seeing this? If not, then the price of producing reliable, production-ready software likely has not significantly diminished.

I see a lot of posts saying, "I vibe-coded this toy prototype in one week! Software is a commodity now," but I don't see any engineers saying, "here's how we vibe-coded this piece of production-quality software in one month, when it would have taken us a year to build it before." It seems to me like the only software whose production has been significantly accelerated is toy prototypes.

I assume it's a consequence of Amdahl's law:

> the overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used.

Toy prototypes proportionally contains a much higher amount of the type of rote greenfield scaffolding that agents are good at writing. The sticker problems of brownfield growth and robustification are absent.