Summarizer

> Professional formatting, length, and clear prose are no longer indicators of care and work quality (they never were, but in the past, if someone drafts up a twelve page spec, at least you know they care enough to spend a lot of time on it). I feel the loss of this signal acutely. It’s an adjustment to react to 10-30 page “spec” choc-a-block with formatting and ascii figures as if it were a verbal spitball … because these days it likely is.

Imagine how much work that all took... carefully colourizing your CLI.... and now it just gets spat out

I like them. It tells very clearly how much effort went into someone's work. I like them even more on code comments. It tells _precisely_ how much effort went into the pull request, so I don't spend time reviewing lazy work.

It does not at all indicate the effort that went into doing the thing. Clearly not. I propose that what you enjoy is having a token of the appearance of effort, easily constructed and easily observed and easily suitable for low-effort handling of these proxy objects for actual work.

I think you’re missing the sarcasm in their comment. They’re saying that the emoji usage is telling them that very little effort was put into the PR and that they’ll treat it accordingly.

Lazy or efficient? A dev could spend an hour on something or 10 mins, if the outcome is the same what's does it matter?

To be fair, a lot of those people were stochastically parroting by themselves for years already. They are just capable to stochastically parrot more. These companies have enough market power that they can afford to be ineffective. So they were. And they are ineffective in novel way.

Even that is pretty useless because we have no idea what context "your Claude instance" has. All you're doing is dressing up some bullshit to look authoritative. When I started my PhD I was already really good at typesetting with LaTeX. I started to bring in fully typeset works in progress for my supervisor to read through. These proofs often had fatal flaws. He asked me to stop typesetting until after the work had been verified because it looked too convincingly correct due to being typeset. That was about 15 years ago but I've never forgotten it. Drafts should look like drafts. Scrappy work and proofs of concept should look as such. Stop fucking with people by making your bullshit, scrappy ideas look legit. Progress is a cooperative effort. It's not about trying to make people say yes.

Can confirm. I saw some fresh out of college colleagues do this in text docs. Al nice markup, but the text content was very drafty. I always sent them back to keep the format concept-y if you are tuning the text first.

The OP has an amusing side point - LLMs have automated sucking up to management. There is a large market for that. His main point, though, is this: I have a colleague ... who spent two months earlier this year building a system that should have been designed by someone with formal training in data architecture. He used the tools well, by the standards by which use of the tools is currently measured. He produced a great deal of code, a great deal of documentation, a great deal of what looked, to anyone who did not know what to look for, like progress. He could not, when asked, explain how any of it actually worked. The work was wrong from the first day. The schemas, and more importantly the objectives, were wrong in a way that would have been obvious to anyone with two years in the field. I've been reading many rants like that lately. If they came with examples, they would be more helpful. The author does not elaborate on "the schemas, and more importantly the objectives, were wrong". The LLM's schema vs. a "good" schema should have been in the next paragraph. That would change the article from a rant to a bug report. We don't know what went wrong here. It's not clear whether the trouble is that the schema can't represent the business problem, or that the database performance is terrible because the schema is inefficient. If you have the schema and the objectives, that's close to a specification. Given a specification, LLMs can potentially do a decent job. If the LLM generates the spec itself, then it needs a lot of context which it probably doesn't have. This isn't necessarily an LLM problem. Large teams producing in-house business process systems tend to fall into the same hole. This is almost the classic way large in-house systems fail.

So far, when Claude pops out a schema it's pretty spot on, iff you've described the problem correctly. What the article's author seems to be hinting at is that the problem was described incorrectly from day one, and the LLM picked the wrong schema from day one. Because the person making it is not technically literate enough to describe the problem in a way an LLM interpreted correctly. The hidden BA work a developer usually does was missing from the process.

There’s no need to defend LLMs. The article is making the point that a colleague who shouldn’t have been anywhere near specifying work for LLMs to do, was able to fake it and get rewarded for it.

The details might bury his point rather than illustrate it. The driving theme throughout seems to be that a tool tuned for correct syntax, with deep understanding of semantics will look like a Dunning-Kruger machine. The specific errors that the author's colleague was oblivious to don't add any weight to that general point, they only explain one specific instance. It's classic omega-consistency.

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.

> I agree with everything you've said, but don't you think quite a lot of things have also been like this before, just to a lesser degree? That’s exactly the reason LLMs and friends are so dangerous to companies, and it’s so hard for them to resist using them in useless/counter-productive ways. They’re excellent at faking signs of effort and work that companies can hardly help but reward, absent any actual way to measure manager effectiveness (and approximately nobody knows how to measure that, in the wild). This takes the form of gilding and padding on a lot of communication, none of which adds actual value but it does cost money directly and indirectly (time wasted sorting out which parts of a document are intentional and meaningful, and which are plausible but irrelevant LLM inventions, for instance)

A lot of people have already noticed that it's becoming cheaper to create bespoke software, as an alternative to paying a SaaS or purchasing off-the-shelf. An example is that instead of buying a cookie-cutter "MacMansion" like in the last century even individuals can afford a unique house designed by a professional architect. It may not be an award winning artistic design, but it won't be the same copy-paste design as every neighbour up and down the street. I'm seeing more comments online that developers are now expected to do more in the sense that what used to be a CLI script may now be a semi-vibe-coded application with a Web UI, a dashboard, and Open Telemetry integration because... why not? As an example, I got a bunch of boxes of random Lego for my kid and I wanted to figure out what sets the pieces came from. I got Codex to vibe-code a full SPA web UI and a matching API app that pulls Rebrickable database CSVs, parses them, puts them into SQLite, and then runs a fairly complex integer optimisation solution on top of that collected data to figure out the best match. I did that in an hour while sitting in on an online meeting! There is no way I'd have the mental energy to do a project like that otherwise. I'm too busy with housework, actual work, etc... Maybe when I was younger I could blow a few weeks of effort on something like this, but now? No way. That cost-benefit arithmetic has dramatically shifted thanks to AI developer agents. Suddenly, many fiddly tasks are no longer fiddly, or even trivial, so there's no excuse not to do them any more. Going back to the architect or mechanical engineering example: Significant corrections to designs used to be expensive because all the blueprints (on paper!) had to be redrawn and distributed. Now, a change to CAD design in 3D can be converted to arbitrary 2D views, cross-sections, or whatever in seconds. The software just projects whatever view you want out of the master design file. Creating the paper blueprints similarly takes a minute or two at most on an industrial large-format printer. It just spits it out.

The more difficult it is to trace one’s labour to output.. expect more theatrics ;)

But do you expect to pay top dollar to have someone pretend they know how to fix a car? That's the point here. Granted, the trades is a bad example because it's chock full of fakers too.

> I think for a lot of companies, AI is a destabilizing force that their managerial structure is unable to compensate for. From the article: > because the competence the work reflects is not the novice’s competence at all The core of the problem is that AI allows engineers who were previously inexperienced or downright mediocre, pretend that they are talented, and a lot of management isn’t equipped to evaluate that. It’s like tourists looking at a grocery store in North Korea from their tour bus. It looks like a fully functioning grocery store from the outside, but it is mostly cutouts and plastic fruit.

I've personally witnessed this: 1. My own manager now gives "expert advice and suggestions" using Claude based on his/her incomplete understanding of the domain. 2. Multiple non-technical people within the company are developing internal software tools to be deployed org wide. Hoping such demos will get them their recognition and incentives that they deserve. Management as expected are impressed and approving such POCs. 3. Hyperactive colleagues showcasing expert looking demos that leadership buys. All the while has zero understanding of what's happening underneath. I didn't know how to articulate this problem well, but this article does a great job!

Software Engineering seems to be quite unique to enable this due to few factors: * Many software engineers didn't do real engineering work during their entire careers. In large companies it's even harder - you arrive as a small gear and are inserted into a large mechanism. You learn some configuration language some smart-ass invented to get a promo, "learn" the product by cleaning tons of those configs, refactoring them, "fixing" results in another bespoke framework by adjusting some knobs in the config language you are now expert in. Five years pass and you are still doing that. * There are many near-engineering positions in the industry. The guy who always told how he liked to work with people and that's why stopped coding, another lady who always was fascinated by the product and working with users. They all fill in the space in small and large companies as .*M * The train is slow moving, especially in large companies. Commit to prod can easily span months, with six months being a norm. For some large, critical systems, Agentic code still didn't reach the production as of today. Considering above, AI is replacing some BS jobs, people who were near-code but above it suddenly enjoy vibe-coding, their shit still didn't hit the fan in slow moving companies. But oh man, it looks like a productivity boom.

FWIW I was watching an interview with the founder of Claude Code and he claims that at Anthropic, no code is written by hand anymore. https://www.youtube.com/watch?v=SlGRN8jh2RI&pp=0gcJCQMLAYcqI...

the most productive teams will be the ones that treat code as compiler output (which we never read) legacy manual codebases which require human review will be the new "maintaining a FORTRAN mainframe". they'll stick around for longer than you'd expect (because they still work) , at legacy stagnant engineering companies

Did this recently to a junior engineer myself, who sent me an AI slop chart in response to simple questions about what he thought about my senior direction about vercel-shipping something fast over AWS-architecting something over thought and over engineered. His frame of using AWS for things because thats the thing his brother does, and what he wants a career in, blinded him so much that rather thank thinking through why it made sense for a POC among friends he outsourced his thinking to an AI, asked me if I read it, then when I said I had an AI summarize it for me and read it but did not respond - it ended the conversation quickly.

I've noticed early into AI adoption in the workplace that some colleagues took advantage of the technology by appearing to be hyper-proactive; New TODs weekly, fresh new refactoring ideas, novel ways to solve age-old problems with shiny new algorithms. Fast-forward to today, and this is occurring two-fold. Not only are they trying to appear more proactive, combining this with the fear of AI layoffs, they're creating solutions to problems before the problem has even been fully defined. For example, I was tasked to look into a company-wide solution for a particular architectural problem. I thought delivering a sound solution would give me some kudos, alas, I wasn't fast enough. An intern had already figured it out and wrote a TOD. I find myself too tired to compete.

is it a net-win for the company? Are the AI-TOD any good?

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/

After reading this article, I can definitely feel how productivity rises inside organizations. More precisely, this feels like a person who would be loved by management. The article almost reads like a practical manual for increasing perceived productivity inside a company. The argument is repetitive: 1. AI generates convincing-looking artifacts without corresponding judgment. 2. Organizations mistake those artifacts for progress. 3. Managers mistake volume for competence. The article explains this same structure several times. In fact, the three main themes are mostly variations of the same claim: AI allows people to produce output without having the competence to evaluate it. The problem is that the article is criticizing a context in which one-page documents become twelve-page documents, while containing the same problem in its own form. The references also do not seem to carry much real argumentative weight. They mostly decorate an already intuitive workplace complaint with academic authority. This is something I often observe in organizations: find a topic management already wants to hear about, repeat the central thesis, and cite a large number of studies that lean in the same direction. There is also an irony here. The article criticizes a certain kind of workplace artifact, but gradually becomes very close to that artifact itself. This kind of failrue criticizing a pattern while reproducing it seems almost like a recurring custom in the programming industry. Personally, I almost regret that this person is not in the same profession as me. If someone like this had been a freelancer, perhaps the human rights of freelancers would have improved considerably.

Someone i know found a Wonderful word for this: Inkompetenzkompensierungskompetenz This is German and basically just means that someone has the competency to compensate for their own incompetency's, just that AI now does that for us and we slowly notice how important that even is in the day to day life.

"Output-competence decoupling" is my new favorite keyword.

The new meaning of OCD

I brought this up during our AI workshops, but I called it the “confident idiot” Seeing the idea explored in such depth is great, I really am concerned about this.

Worse: it’s the confident prolific idiot, the most dangerous kind.

AI can be (and often is) a confident incompetence amplifier.

> He produced a great deal of code, a great deal of documentation, a great deal of what looked, to anyone who did not know what to look for, like progress. He could not, when asked, explain how any of it actually worked. Solution: managers need to ask 'how does $THING_YOU_MADE actually work?'. Pre-AI, it could be taken for granted that if someone was skilled enough to write complex code/documentation then they have a sound understanding of how it works. But that's no longer true. It only takes 5 minutes of questioning to figure out if they know their stuff or not. It's just that managers aren't asking (or perhaps aren't skilled enough to judge the answers). On the issue of over-enthusiasm from upper management, this may be only temporary since it makes sense to try lots of new ideas (even the crazy ones) at the start of a technological revolution. After a while it will become clearer where the gains are and the wasteful ideas will be nixed.

The article presents a pretty good rundown on the state of affairs. "A growing body of work calls this output-competence decoupling" Given that I don't think he meant that there's a thing called "output competence," I think he meant "output/competence decoupling."

It's not ai that scary it's people using its field they don't know and then defending wrong outputs like they built it themselves

Imagine you hire an Engineer in your team. You find out he can't code. Yout have 4 major projects due this quarter. Are you going to become his 1-1 tutor from zero to 10 yoe hero coder in 3 months. Because he doesn't need help, he needs a time machine. (slop intended)

The cope-ism in this blog post is palpable. The author is genuinely offended that someone who doesn't know how to code is daring to invade his turf. It's pretty sad that this is how he is reacting. I, for one, welcome the new paradigm shift of vibe coders entering the field. I still think I have a competitive advantage with my 30+ years of coding experience, but I don't think it's wrong for vibe coders to enter my turf. I think value of code is rapidly asymptotically to ZERO. Code has no value anymore. It doesn't matter if it's slop as long as it works. If you are one of the ones that believes that all code written by humans is sacred and infallible, you probably don't have a lot of experience working in many companies. Most human code is garbage anyway. If it's AI-generated, at least it's based on better best principles and if it's really bad you just need to reprompt it or wait for a newer version of the AI and it will automatically get better. THIS IS THE NEW PARADIGM. THINKING YOU HAVE ANY POWER TO SWAY THE FUTURE AWAY FROM THIS PATH IS FOOLISH. I'm currently running a migration program at work and it turns out there's a 10 MB limit to the number of entries I can batch over at one time. At first I asked AI to copy 10 rows per batch but that was too slow. Then I asked it to change the code to do 400 rows per batch but sometimes it failed because it exceeded the 10 MB limit. Then I said just collect the number of rows until you get 10 MB and then send it off. This is working perfectly and now I'm running it without any hitches so far. Then I asked it to add an estimate to how long it would take to finish after every batch, including end time. I really love this new world we're living in with AI coding. Sure this could have been done by someone without experience, but at least for right now the ideas I can come up with are much better than those without any experience, and that's hopefully the edge that keeps me employed. But whatever the new normal is, I'm ready to adapt.

So essentially, AI is exacerbating the Dunning-Kruger effect in society.

I find it astounding how otherwise intelligent people fall for such obvious theatre. One really does need a particular mindset to filter this out, and that is almost entirely absent from typical management. As usual, if you don't have an actual reliable signal, or acquiring that signal takes too long - you'll fall back to relying on cheap proxy signals. Confidence over competence, etc. And those that are best at self-promotion and politics win. I've got recent experience in exactly this - someone who is completely out of their depth, mis-representing their actual capabilities. Their reliance on AI is so strong because of this lack of depth - to such a degree that they never learn anything. Lately they've been creating drama and endless discussions about dumb things to a) try to appear like they have strong opinions, and b) to filabust the time so they don't have to talk about important things related to their work output.

Agreed. I mean, to me, it seems that the management tier level of people like what you described, are the people funding and marketing AI to the world. They want to maintain their status and position in the world, while lowering the value of the actual experts in the world and like this article says, feel confident in their impersonations of them.