For my side project where uptime doesn't really matter but the codebase is quite huge (gamedev of a multiplayer game with Bevy, so both server code, game code, content build pipeline, as well as a TON of editor and authoring code, probably 150k+ LoC), I've been moving towards just reviewing boundaries between modules, APIs, and schemas, and I'm pushing towards keeping things as modular as possible. If something ends up wrong, it going to be isolated and it doesn't infect the rest of the codebase. Every now and then I zoom into a module and tidy it up (or even rewrite it).

I wouldn't dare doing this "carelessly" for anything where people other than me actually depend on it, but you can move very fast while doing it and the risks with bad code is quite hedged. Different modules can mature at different rates when it becomes necessary.

Maybe not related to all of what you were saying, but I think this enables scaling without ending up with progress grinding down to a halt due to shitty code.

I have home projects like this too, and those techniques can make things well, it can also rabbit hole in ways that are less productive sometimes. I’m constantly trying to push my comfort level and find what I can delegate and what I need to specify, esp around structure and isolation.

My comment is more for the people in charge of or working on software teams on complicated products for customers - so many leaders quite a few engineers have utterly drank the koolaid and pushed maximizing AI use with zero regard for quality or even medium term effects. Many of them are getting promoted by other clueless management for it - when someone is handed a huge check for being optimistic, they tend not to second guess themselves.

This can easily lead you down a path of excessive modularity with each module being excessively complex though

In my experience, when that happens it's most likely because you drew the wrong boundaries. Iterating on the boundaries also becomes quite cheap when developing this way though, you should never expect to get them right the first time unless it's a very common problem you're solving _or_ you've done it before.

> path of excessive modularity with each module being excessively complex

its contradicting metrics. You either have modules being excessively complex and not enough modularity or vice versa

That honestly sounds like it's more about either the quality of the codebase, or the driver.

To be more concrete, the last two examples were that Fable added every time a function called utcnow in newly added Python modules, and it always ended up adding constants. I'm saying it takes a lot of effort to make sure Fable or other frontier models don't produce such marginal slop and to keep things concise.

I understand that to be the "emergent abilities" which are spoken about. There are correlations in the dataset that are strong enough for it to seem to have an understanding which wasn't obvious it would have from simply "predicting the next word".

>The coding agents got good in November.

Maybe irrelevant to your point, but I'd argue they were really good already in May if one used the right workflow (planning etc.). They've become better, but they're not saving me significantly more time now than they did 12 months ago.

Agreed, async function coloring makes for better structured code because it incentivizes keeping IO code near the edges while having a synchronous core.

I doubt it, the difference between someone slightly inefficient and someone extremely efficient isn't big enough to matter compared to how much they cost in salary.

That doesn't make it not true though. Markdown generally supports HTML (though oftentimes only a subset), and is typically styled using CSS. Using a web view makes complete sense to me.

> But are we really saying that the primary motivation for async/await is performance?

Of course - what else would it be? The whole async trend started because moving away from each http request spawning (or being bound to) an OS thread gave quite extreme improvements in requests/second metrics, didn't it?

I agree. Managing many http requests or responses was a motivating problem.

What I question is whether 1. Most programs resemble that, so that they make it an invasive feature of every general purpose language. 2. Whether programmers are making a conscious choice because they ruled out the perf overhead of the simpler model we have by default.

That is why we have the function colouring problem and a split ecosystem in the first place - if it were obviously better in all cases, we'd make async the default, and get rid of the split altogether (and there are languages, like Erlang, that fall on this side of the fence)

It was not for performance reasons, but for scaling up.

That's the same thing?

I haven't made a ESP32 design, but I recently learnt KiCad and PCB design enough to do a RP235x board with a non-reference design choice (1.8v VDDIO). I only used the official hardware guide + LLMs for questions, and had it work on the first try - it wasn't too hard!

I agree LLMs are exceptionally helpful on this.

But dependencies are part of a website? It literally says "Still here when the internet isn't." - but I can't go on there without an internet connection?

Service Workers can cough up this stuff even without a connection, provided you already visited the site once before. This is how sites like Twitter still load their bones even without a connection.