Summarizer

> The first is when novices in a field are able to produce work that resembles what their seniors produce [...]. > The second is when people generate artifacts in disciplines they were never trained in. There is a third shape. Experts who have become so reliant / accustomed to AI that it dilutes their previously sharp judgment and, importantly, taste . I am seeing more and more work produced by experts which seems strangely out of character. A needlessly verbose text written by someone who was previously allergic to verbosity. An over-engineered solution (complete with CLI, storage backend, documentation, unit tests) for a trivial problem which that person would've solved by an elegant bash one-liner only 3 years ago. The work itself is always completely immune to any rational criticism, as it checks all the boxes: extensive documentation, scalable, high test coverage, perfect code style, and for texts perfect grammar, non-offensive, seemingly objective. But, for lack of a better word, it simply lacks taste.

Perhaps the experts have decided that, for this specific instance, the thing we need to do is ad-hoc and throwaway, and is simply not worth paying the extra cost to make it tasteful.

What expert would build a cli tool to avoid writing a bash one-liner?

Sure, then there's a point where the extra taste isn't worth its cost. I just don't like the fictional straw man where an expert has somehow been brainwashed by AI into forgetting everything they ever knew.

Perhaps the ones that were experts before letting their brain rotten by AI.

I agree, so you should ask yourself "why would the expert do this?" I decided to go for the charitable interpretation of "the alternatives are close enough in functionality that writing by hand is not worth it", instead of the uncharitable interpretation of "these examples are completely made up".

Because the expert has forgotten. Skills that we don't use are forgotten, and there's nothing new in that. Except for the proverbial bicycle.

Ok, if you think the expert has forgotten that a problem can be solved by a bash one-liner and instead think they need a whole extensive CLI with documentation, our viewpoints are too far apart for fruitful discussion.

The bash one-liner might be hyperbolic but with the advent of AI everything is artificially longer, stuffier, more complex and convoluted for no reason other than because the AI allows this increase in volume with little to no extra effort. It used to be the proverbial one-liner with zero documentation because that was the best ratio of effort to results. Now the effort is on the AI and the results look more impressive. Today that will still impress a lot of people, bosses, colleagues. Very soon everyone will see through it and anything overly stuffy will have the opposite effect of looking low-effort.

I think it likely performed well in A/B preference tests with chat users. I've noticed Claude does far fewer listicles than ChatGPT. I suspect that they don't blindly follow supervised learning feedback from chats as much as ChatGPT. I get Apple vs Google design approach from those two companies, in that Apple tends not to obsess over interaction data, instead using design principles, while Google just tests everything and has very little "taste." In general I feel like the data approach really blinds people to the obvious problem that "a little" of something can be preferable while "a lot" of the same is not. I don't mind some bullet points here and there but when literally everything is in bullet points or pull quotes it's very annoying. I prefer Claude's paragraph style. I suppose the downside is that using "taste" like Apple does can potentially lead a product design far, far away from what people want (macOS 26), more so than a data approach, whereas a data approach will not get it so drastically wrong but will never feel great.

Yeah and for much of the HN crowd, we aspire to have better tastes than the average. So if the supervised learning uses average human trainers it will most likely be seen as having poor taste for much of HN.

This is literally losing the whole process to a stochastic parrot.

There’s people who use AI to solve problems, and then there’s people who have completely offloaded all of their thinking to LLMs. I have a manager who when asked a question won’t think even for a moment about it and will just paste paragraphs of AI generated text back.

What is described here closely resembles my experience too. My company is full of managers who haven't written code in years. They hired an architect 18 months ago who used AI to architect everything. To the senior devs it was obvious - everything was massively over engineered, yet because he used all the proper terminology he sounded more competent to upper management than the other senior managers who didn't. When called out, he would result to personal attacks. After about 6 months, several people left and the ones who stayed went all in on AI. They've been building agentic workflows for the past 12 months in an effort to plug the gap from the competent members of staff leaving. The result, nothing of value has been released in the past 18 months. The business is cutting costs after wasting massive amounts on cloud compute on poorly designed solutions, making up for it by freezing hiring.

Without getting into AI-for-work good or bad, > update 42 if statements in 32 different files is a silly behavior for a programmer or an AI to have to do more than twice. We have tools that very effectively remove the need for things like that: programming languages that allow modular and reusable code, good design, etc.

Ideally. But that requires the correct abstraction, requires keeping it up to date.... that's basically an unachievable ideal. You either have overabstraction/overengineering (most codebases) or you have repetition. Repetition is actually more preferable in the LLM-world because you have to keep less stuff in your head. And the LLM's head too. Even if something does look copypasted, it might actually be semantically distinct enough that if you couple them, you'll create a brittle mess. Additionally, there's always going to be global changes (update the code style, document things, refactor into a new pattern, add new functionality to callers, etc.). The question isn't whether you use your lanuage's tools or you do it by hand, the question is whether you use an LLM or do it by hand :P

Totally fair, but 42 if-statements across 32 files isn't something you need to fix with like ... a grand refactor or hexagonal architecture or event sourcing or whatever the overengineering pattern du jour is. You can fix that with a utility function or three, and a file/class/module/whatever that owns the code relating to some of those conditions. I'm not some DRY zealot, but I've been in the "this system needs really similar changes to a ton of geographically distant code for simple changes" salt mines a lot. The people who say that kind of spaghetti is unavoidable are just as wrong as the ones who say it can only be fixed with a grand rearchitecture by a rockstar.

Such repetitions can regularly be deterministically automated, like find -exec sed and similar medium level tools. If you spend a lot of time performing monotonic tasks, then your organisation needs to delete and refactor for a while until change in 'hot' areas of the code base are easy to make. Reaching for some code synthesis SaaS to paper it over will worsen the problem and should result in excommunication from the guild.

Does your work primarily consist of updating 42 if statements in 32 different files? We all do that occasionally, but if you're doing it constantly, is it possible that a different system design would make your work much easier?

My company hired a lead architect and he stayed with us for less than a year. He introduced some overengineered shit we are still recovering from. How those people get to where they are and get hired for that kind of position is beyond me.

I think this may be a consequence of hiring for a position with the word “architect” in it. It implies the need for complexity vs. Getting a gaggle of senior devs together and letting them sort out CI/CD and patterns as they are needed. In a lot of cases, an architect is not needed but must justify themselves.

Have you not seen the principals and seniors being offered the door or buyouts?

Even generating a first-pass of the eventual production code that you can step back and review is useful to get ideas, so long as you guard yourself against laziness of going with the first answer it provides

It's a small family run company that turns over multi million on bespoke stone pieces. AI is rotting away at the core of the business from leadership to customer service. I was passionate before the rot, but I've got a new job starting in 5 weeks and I can't wait. Perhaps you are self projecting a little, these people got employed on good wages and have the skills the just don't use them anymore. I hate the future.

> The cost of producing a document has fallen to nearly zero; the cost of reading one has not, and is in fact rising, because the reader must now sift the synthetic context for whatever the document was originally about. Each individual decision to elongate seems rational, and each is independently rewarded — readers are more confident in longer AI-generated explanations whether or not the explanations are correct [5]. The collective effect is that the signal in any given workplace is harder to find than it was before any of this began. The checkpoints have been hidden, drowned in their own paperwork, even when the people drowning them were genuinely trying to “be brief” I just finished working with a client that is producing documents as described in this quote. The first time I recognized it was when someone sent me a 13-page doc about a process and vendor when I needed a paragraph at most. In an instant, my trust in that person dropped to almost zero. It was hard to move past a blatant asymmetry in how we perceived each other’s time and desire to think and then write concise words.

I spent most of yesterday, deleting and replacing a bunch of code that was generated by an LLM. For the most part, the LLM's assistance has been great. For the most part. In this case, it decided to give me a whole bunch of crazy threaded code, and, for the first time, in many years, my app started crashing. My apps don't crash. They may have lots of other problems, but crashing isn't one of them. I'm anal. Sue me. For my own rule of thumb, I almost never dispatch to new threads. I will often let the OS SDK do it, and honor its choice, but there's very few places that I find spawning a worker, myself, actually buys me anything more than debugging misery. I know that doesn't apply to many types of applications, but it does apply to the ones I write. The LLM loves threads. I realized that this is probably because it got most of its training code from overenthusiastic folks, enamored with shiny tech. Anyway, after I gutted the screen, and added my own code, the performance increased markedly, and the crashes stopped. Lesson learned: Caveat Emptor .

As everyone is an expert now[1] on paper I think it is unfortunately time for a shift again. For years I was big proponent of asynchronous remote work. But it seems like the only reasonable way forward is to discuss things face to face. I still prefer to prepare things async, but then discuss them in person to understand if people actually understand what they are talking about. So far I also have a good time with really being frank and honest with colleagues if something is clearly AI expertise and not that persons expertise. 1: https://www.dev-log.me/everyone_is_an_expert_now/

Those are often also people who are in the company for a long time already, not only newly hired. I think AI makes it just so easy to be lazy. I guess my hope with the face to face is that people take the feedback and learn to do the actual work again. Right now it feels like a lot of this kind of collaboration and what is okay and what no has to be figured out.

As I am continually amazed at how well Claude 4.7 deals with highly complicated C++ code, I am also becoming painfully aware of the developing situation mentioned in this article: I no longer completely understand the code it is editing, not because I'm incapable of doing it, but because I have not authored the changes. I am trading throughput for understanding, and, eventually, judgment.

nail on the head. the loss in understanding, learning and context is often not worth the increase in volume of output

That’s entirely on you. You can take the time to understand it before moving on to the next task. I say this with sympathy and understanding.

Excellent article! Aptly describes what I have been feeling and thinking about the claims many AI optimists make. --- > He produced a great deal of code, [...] He could not, when asked, explain how any of it actually worked. [...] When opinions were voiced even as high as a V.P., he fought back. AI has democratized coding, but people have yet to understand that it takes expertise to actually design a system that can handle scale. Of course, you can build a PoC in a few hours with Claude code, but that wouldn't generate value. The reason why we see such examples in the workplace is because of the false marketing done by CEOs and wrapper companies. It just gives people a false hope that "they can just build things" when they can only build demos. Another reason is that the incentives in almost every company have shifted to favour a person using AI. It's like the companies are purposefully forcing us to use AI, to show demand for AI, so that they can get a green signal to build more data centers. --- > So you have overconfident, novices able to improve their individual productivity in an area of expertise they are unable to review for correctness. What could go wrong? This is one much-needed point to raise. I have many people around me saying that people my age are using AI to get 10x or 100x better at doing stuff. How are you evaluating them to check if the person actually improved that much? I have experienced this excessively on twitter since last few months. It is like a cult. Someone with a good following builds something with AI, and people go mad and perceive that person as some kind of god. I clearly don't understand that. Just as an example, after Karpathy open-sourced autoresearch, you might have seen a variety of different flavors that employ the same idea across various domains, but I think a Meta researcher pointed out that it is a type of search method, just like Optuna does with hyperparameter searching. Basically, people should think from first principles. But the current state of tech Twitter is pathetic; any lame idea + genAI gets viral, without even the slightest thought of whether genAI actually helps solve the problem or improve the existing solution. (Side note: I saw a blog from someone from a top USA uni writing about OpenClaw x AutoResearch, I was like WTF?! - because as we all know, OpenClaw was just a hype that aged like milk) --- > The slowness was not a tax on the real work; the slowness was the real work. Well Said! People should understand that learning things takes time, building things takes time, and understanding things deeply takes time. Someone building a web app using AI in 10 mins is not ahead but behind the person who is actually going one or two levels of abstractions deeper to understand how HTML/JS/Next.js works. I strongly believe that the tech industry will realise this sooner or later that AI doesn't make people learn faster, it just speeds up the repetitive manual tasks. And people should use the AI in that regard only. The (real) cognitive task to actually learn is still in the hands of humans, and it is slow, which is not a bottleneck, but that's just how we humans are, and it should be respected.