This post is the piece those two were circling around: what happens to the bottom of the chart, and whose job it is to fix it. Spoiler — it’s yours, senior engineer. It’s mine. And most of us are about to get it wrong in a very specific, very tempting way.

BS. Most good seniors I know would love to hire more juniors, feel badly for the mass of recent college grads who are unemployed, and enjoy mentoring new engineers without needing a wall of AI slop to tell them to do so. When you give us control over the hiring budget and let us hire juniors again, you can blame us for the future senior engineer shortage. Until then, blame the people actually at fault (management, executives, the investor class), not us.

I’m far from a slop advocate, so this is more of a devil’s advocate point: plenty of code writing is not enjoyable.

If I’m working on my own project, to my own standards, writing exactly what I want to write I’m usually going to get enjoyment out of it. That’s pretty commonly not the case when writing code for an employer. Maybe the tech stack sucks, the product is inane or worse, you think the feature is a dumb idea but have to do it anyway, you’re bending over backwards to work around tech debt that you’re not allowed by management to fix, or you have to appease incompetent/out of touch architects or tech leads who presume to tell you how to do your job. I personally don’t enjoy writing that code very much. At a certain point it’s almost like nails on a chalkboard if you genuinely enjoy programming for its own sake: you know what good would look like, you know how far away what you’re working on is from good, and you feel sad at all the organizational inertia you’d need to overcome to get to good or, choosing not to do that, at compromising your standards. That bugs me, at least, and at a certain point makes it hard to even start certain work projects.

LLMs can make this at least bearable. Rather than spending hours looking into the change yourself, writing all of the code, fighting the shitty test framework and swearing at the past engineers who made it so bad, you let the robot figure it out and review its work. The result may still suck, but it was going to suck if you wrote it by hand too, for reasons largely out of your control. You can’t be fully hands off, and you still have to deal with the things you don’t like to get a good result, but you put yourself a step away from what bothers you and by doing so make it a little more pleasant. And, when you find work that’s actually fun, interesting, or rewarding, you just cherry pick that for yourself. I’ve grown to appreciate them for this reason. I have a lot less dread for the nails on a chalkboard work than I used to, anyway.

driven by our mission to create meaningful connections between brands and their audiences

Oh fuck off with this.

Having used these at my day job I can understand the policy against them. Ours is fairly well tuned by the people who operate it, adapted to our codebase, and its comments are usually on point, but its false positive rate for my own PRs is still in the low double digit percent range (feedback that’s factually wrong, not relevant to the PR, not scoped appropriately, etc). Before all that tuning, back when we first started using it, I probably went days or weeks without seeing a well-founded suggestion from the tool. Incorrect comments still create work for the PR author (investigating, double checking, etc), they create noise for human reviewers, and ambiguity about whether a change is ready to be merged. I read that policy as being against random people pointing their own review tools at PRs for this project, which I assume would be more on the high false positive/high noise end of the spectrum (i.e., not being tuned for this specific project). I can totally see why already busy maintainers would want to spare themselves from a bunch of poorly calibrated noise.

One nice thing about them compared to human reviewers is that you can just tell them to (professionally) fuck off if they’re wrong without hurting their feelings or having an HR conversation.

A couple observations on reading this (as someone who heavily uses agentic coding at work and is mostly OK with it):

• Maybe I’m weird, but I don’t find “we always plan the implementation and make decisions first, and only then do we write the code” to describe my work style that well. If I don’t know how I want something to look, I will frequently just start writing whatever code comes to mind about that something. Most of the code will suck, and I’ll probably throw much of it away, but I find that it’s often a much more efficient way to get to a design that I like than sitting and debating tradeoffs in the abstract. Me writing the code might be slower than an agent writing the code, but that misses the point of the exercise: me writing the code is a way for me to build my own understanding of the problem.
• The text translation analogy at the beginning is illustrative, I think. A piece of writing has information, but also elements of the author’s wit, humor, tone, their assumptions about us as readers, and the cultural frame they write within. Good writing combines all of those things in an appealing way. At some basic level translation is about translating words correctly, but “correctly” there does a lot of work. It can be very hard to translate a work from one language to another without losing those less obvious characteristics (wit, tone, etc) that make it appealing, especially if you’re translating (e.g.) idioms or slang that don’t have a clear counterpart in your destination language. This is probably familiar to folks who read authors who’ve been translated outside of their native language: the right (or wrong) translator can have a huge impact on what you experience while reading. That’s not a bar we hold for all text (we’ve all seen very poorly translated manuals for cheap consumer electronics that are nonetheless fine because we can figure out what they’re trying to say), and similarly isn’t a bar that holds for all code, but there is some code where the nuances that automatic translation misses are actually important, and where a human touch is useful.

I guess it isn’t that surprising. I bet the developers who write the software included in this distribution would love some of those millions, but being a guy with a brand and opinions is apparently more valuable to the investor class. Consistent with how they think about the workforce at their own companies, anyway.

(I normally read things like this as people paying tribute to the guy running the company getting the money, or wanting to be perceived as in favor of that company’s viewpoints. I don’t understand why anyone would want to pay tribute to DHH. Ignoring the ick, he’s not that important or powerful. There are a lot of SWEs who don’t know who he is, let alone the general public)

There are also enough engineers looking for jobs that companies can be picky and only hire the ones who seem agreeable and inoffensive, which reinforces the dynamic. “Idealistic” folks accumulate employment gaps that they have to explain or which cause AI ATS systems to auto reject their application before a human ever sees it, meanwhile management and hiring panels become increasingly corporate and less tolerant of difference because that’s who gets hired.

I don’t disagree with a lot of the advice here as a practical thing (e.g., having a scrubbed public image online, assuming that someone evaluating your job application will research you), but I also remember a time when you didn’t have to do that to work in the industry. A lot of the smartest, most creative folks in my CS program were also outspoken on (e.g.) privacy or civil rights in ways that could be tied to their real name, and it makes me kind of sad to think that they’d probably have to hide that today if they wanted to get hired as a new grad.