This is my thinking as well. Although the 'never do full rewrites' rule is canon for most of the software world, I have led rewrites of two large front-end applications to great success - replacing an app that 'worked' but took an order of magnitude more time to iterate on than the codebase that replaced it.
That said, it's probably more dependent on what a 'full' rewrite actually is - I would be much more reluctant for a full-stack rewrite, particularly of a mature codebase with a lot of accumulated business logic. At least on the front end you can always push to move business logic upstream where it belongs.
It sounds like two factors are at work - reducing personal time-tracking AND doing more AI-assisted work, both of which can reduce our ability to focus. In the case of AI, it also arguably reduces the need to focus for some kinds of productivity, so the net effect of increased output is expected.
If it helps, you can get AI to do the admin task of time tracking automatically, at least for anything that it is involved with.
The benchmark tables in the Google announcement include Opus 4.7, and the numbers are very impressive. Caveat emptor, but it's not unreasonable to compare a new Flash to a current-gen Opus, even if some of the results confirm expectations
As a project that started with a lot of idealism about how software _should_ be built, I would totally expect Bun to have an llms.txt file even if Claude wasn't using it. It's a project that is motivated in part by leading by example.
To be fair, history also demonstrates the deadly consequences of groups claiming moral absolutes that drive moral imperatives to destroy others. You can adopt moral absolutes, but they will likely conflict with someone else's.
but as mlinsey suggests, what if it's influenced in small, indirect ways by 1000 different people, kind of like the way every 'original' idea from trained professionals is? There's a spectrum, and it's inaccurate to claim that Claude's responses are comparable to adapting one individual's work for another use case - that's not how LLMs operate on open-ended tasks, although they can be instructed to do that and produce reasonable-looking output.
Programmers are not expected to add an addendum to every file listing all the books, articles, and conversations they've had that have influenced the particular code solution. LLMs are trained on far more sources that influence their code suggestions, but it seems like we actually want a higher standard of attribution because they (arguably) are incapable of original thought.
I start all my UI projects with this principle, but it's extremely difficult to maintain as screens evolve. I want typography-driven interfaces with structure communicated through headings and spatial grouping, but I usually end up with far more borders and nested padding than I think is "right" as I run into the limits of whitespace as an organizing structure, particularly when the audience has a limited attention span or time to engage.
From experience, borders/cards help communicate conceptual boundaries, while whitespace helps communicate information hierarchy - Gestalt principles don't really address that distinction. For product or data-driven UI where a lot of loosely-related information/topics are shown in discrete parts of the page, cards are effective at high-level grouping. For content-driven UI, whitespace can be sufficient, and I think the article makes this clear.
Other than 'The Ultimate Developer Toolkit' (where type size is more of an issue than the card layout), I actually think the card-based version of each example layout is more compelling - easier to scan, and easier to 'chunk' - despite wanting the typography-and-whitespace alternative to be sufficient.
The automatic ci/cd suggestion sounds appealing, but at least in the NPM ecosystem, the depth of those dependencies would mean the top-level dependencies would constantly be incrementing. On the app developer side, it would take a lot of attention to figure when it's important to update top-level dependencies and when it's not.
I'm skeptical that we would need determinism in a supervisor in order for it to be useful. I realize it's not exactly analogous, but the current human parallel, with senior/principal/architect-level SWEs reviewing code from less experienced devs (or even similarly-/more-experienced devs) is far from deterministic, but certainly improves quality
Think about how differently a current agent behaves when you say "here is the spec, implement a solution" vs "here is the spec, here is my solution, make refinements" - you get very different output, and I would argue that the 'check my work' approach tends to have better results.
The linked article from Steve Yegge (https://sourcegraph.com/blog/revenge-of-the-junior-developer) provides a 'solution', which he thinks is also imminent - supervisor AI agents, where you might have 100+ coding agents creating PRs, but then a layer of supervisors that are specialized on evaluating quality, and the only PRs that a human being would see would be the 'best', as determined by the supervisor agent layer.
From my experience with AI agents, this feels intuitively possible - current agents seem to be ok (thought not yet 'great') at critiquing solutions, and such supervisor agents could help keep the broader system in alignment.
You're kind of making his point - the second and third paragraphs are explicitly about the fact that he is not an Ivy League professor. Be the change you want to see in the world by doing the reading first.
To be fair, "30 years of experience" likely opens more doors than any particular skill listed on your CV - that doesn't reflect the way that a majority of junior/mid-level devs need to present their abilities, where pattern-matching is an unfortunate norm, particularly when there are orders of magnitude more applicants than open roles.
I'm sure I could dig into the details, but the Solid protocol seems to have similar high-level objects to AT Protocol, but a quick search doesn't reveal many sources that refer to both - are these communities ignoring each other, competing with each other, or just too new to find common ground?
Was that kind of control well-received by your teams? Out of context, it sounds like it would be pretty rough to be an engineer on a team where your manager had sole control over what tools you could use - I suppose it might make sense for junior devs or a very small codebase, but I would caution against taking that stance in a team where you want to facilitate mutual trust
But that take is too narrow - many of the 'great' painters had extensive training in the work of previous masters, frequently copying their works repeatedly in order to develop technique and more deeply engage with what came before. After developing that base skill and understanding, they had a better toolset to express their own originality.
That said, it's probably more dependent on what a 'full' rewrite actually is - I would be much more reluctant for a full-stack rewrite, particularly of a mature codebase with a lot of accumulated business logic. At least on the front end you can always push to move business logic upstream where it belongs.