https://bugzilla.mozilla.org/2040074

RE: https://mastodon.social/@JMarkOckerbloom/116642253074554430
No, not you too đ
The day before feature freeze, the CPython team is busy reviewing last minute PRs, but today's latest #GitHub outage is eating review comments.
We are resorting to pasting screenshots of reviews around in PRs and DMs.
https://github.com/python/cpython/pull/148827/#issuecomment-4390256894
If you donât have the resources to write and understand the code yourself, you donât have the resources to maintain it either.
Any monkey with a keyboard can write code. Writing code has never been hard. People were churning out crappy code en masse way before generative AI and LLMs. I know because Iâve seen it, Iâve had to work with it, and I no doubt wrote (and continue to write) my share of it.
Whatâs never been easy, and what remains difficult, is figuring out the right problem to solve, solving it elegantly, and doing so in a way thatâs maintainable and sustainable given your means.
Code is not an artefact, code is a machine. Code is either a living thing or it is dead and decaying. You donât just write code and youâre done. Itâs a perpetual first draft that you constantly iterate on, and, depending on what it does and how much of that has to do with meeting the evolving needs of the people it serves, it may never be done. With occasional exceptions (perhaps? maybe?) for well-defined and narrowly-scoped tools, done code is dead code.
So much of what we call âwritingâ code is actually changing, iterating on, investigating issues with, fixing, and improving code. And to do that you must not only understand the problem youâre solving but also how youâre solving it (or how you thought you were solving it) through the code youâve already written and the code you still have to write.
So it should come as no surprise that one of the hardest things in development is understanding someone elseâs code, let alone fixing it when something doesnât work as it should. Because itâs not about knowing this programming language or that (learning a programming language is the easiest part of coding), or this framework or that, or even knowing this design pattern or that (although all of these are important prerequisites for comprehension) but understanding what was going on in someone elseâs head when they wrote the code the way they wrote it to solve a particular problem.
It frankly boggles my mind that some people are advocating for automating the easy part (writing code) by exponentially scaling the difficult part (understanding how exactly someone else â in this case, a junior dev who knows all the hows of things but none of the whys â decided to solve the problem). It is, to borrow a technical term, ass-backwards.
They might as well call vibe coding duct-tape-driven development or technical debt as a service.
đ€·ââïž
We have a shiny new roadmap site, and an equally shiny new blog post to tell our community all about it:
https://blog.thunderbird.net/2026/03/introducing-our-public-roadmaps/

At Thunderbird, we firmly believe in the strength of listening to our communityâs needs and wants, and balancing it with our resources and capabilities. While this has always been part of our ethos, we want to start 2026 by making our goals easier to read and comprehend at roadmaps.thunderbird.net, where you will find our roadmaps [âŠ]