> I think there’s pretty clearly a divide in AI perception between executives and individual contributors (ICs).

Narrator: there is not

It's yet another "silver bullet". That's why management loves it and engineers are like "it's just a tool, we still need code review."

IC’s aren’t? Really?

Devs think it will save time and execs think it will save money.

But because time is money, I think all the benefits go to the dev. The exec still needs the dev regardless

Reads like an extended slop LinkedIn post. The author poses a question with an obvious answer yet answers with the most galaxy brain take possible while dropping in some academic concepts to make themselves sound like a thought leader despite probably only taking an intro class in college 10+ years ago.

AI has freed me from a vicious cycle that I had been corralled into as an explicit attrition tactic, and which almost ended with me being used non-consensually for reproductive purposes on at least one occasion.

It accomplished this not simply by eliminating my overpaid bullshit job as parasite attractor; but by putting an end to its pathetic semblance of a premise: building software to be used by, uh, someone? for, uh, something?

The various entities requesting the work (or, in later years, the layers of barely-sentient intermediaries between me and said entities) were hardly if ever clear on how exactly this was supposed to produce value; but now they're free, too! Free from having to even try to understand how answering that question is relevant, emdash - so in the end it worked out for them as well!

I am finally at liberty to do something worthwhile with my life, and while at this point I realize it'll take me some time to even remember what "worthwhile" even was (or whether such a thing still exists in your imaginary world of personalized sensory bubbles), I do sleep a rich REM sleep knowing society is now capable of digging its own grave without my assistance. Seriously, I was looking at my bank account and getting a little worried.

I am told that mine is a minority position: if you happen to be the kind of person who believes that more is better, no matter more of what, rest assured you and your eventual progeny will be quite safe - for a while, anyway - in your new role as AI trainer (or is it AI fodder, let's let the market decide!)

Well, turns out when we are all busy looking the part, it becomes impossible for anyone to actually play the part; but also nobody notices, so this is fine too!

Just one request on my part: if possible, do shut up while figuring out how to better turn yourself and our world into paperclips, alright? Besides the ones that you recognize as people, a whole bunch of other people do live on this here planetation - and I hear they find all the AI blather to be mighty annoying.

> individual contributors are evaluated by their execution on deterministic tasks.

Ha! Apparently the author hasn't been asked "how long will it take to code this?" yet... And isn't a common developer complaint that management does not know how to evaluate them, and substitutes things like how quickly a task gets completed, with the result that some guy looks amazing while his coworkers get stuck with all his technical debt?

I do think the difference is also dictated by how non-deterministic the job output of execs and ICs can be. For example, if exec will use slightly different words to communicate the thought, there won't be a critical error in understanding. While if IC will get the syntax wrong or deletes the wrong service accidentally, this service (or connected ones) might stop working entirely.

Because like everything else in technology, executive don’t understand it beyond a first order level and assign their own value system to it. It seems like magic TO THEM because they’ve never been able to orchestrate such capability without friction until now and that is the shadow of 20 years of search and semantic search stagnation mostly due to Google.

- You need something done

- You ask someone to do it

- You check their work and they made some mistakes, but it's good enough to use

- You ultimately don't know if they're doing the best at their job but you have regular performance check-ins to be safe

As ICs we can complain all we want about the quality of AI, but as far as your manager goes - you using AI is not that much different to them having an employee.

Because executives have been misinformed about it's reliability, or lack thereof, and are stupid? Just a guess.

e: typo

Because it’s a mythical silver bullet of increased output combined with reduced costs.

It makes me think of an executive I once reported to who “increased velocity” by changing the utilization rate on a spreadsheet from 75% to 80%.

It's part of the standard technology buzzword rotation:

embedded/cloud/IoT --> AI --> quantum…

When the company originally known as C3 Energy changes their name to C3.quantum, you'll know where on to the next buzzword.

Idk about you. But I know lots of well qualified ICs who are enamored with AI. They are also boring it to build and fix things that would take months, in just days.

> It doesn't help that the west has a clear bias wherein moving "up" is moving away from the work.

Curious how you verify this behavior would be unique to the West?

Because they don’t work with it. It’s a simple as that. I don’t trust people who don’t work with a terminal these days, the further they get from a terminal, the less grounded their views are. They rely on hearsay and CEO hype. To make matters worse, they say whatever they think will earn them a bonus/promotion, which leads to a cascade of BS down the chain.

I seriously doubt Satya Nadella is sitting down for hours a day to use Copilot to draft detailed documents. He's being fed fantastical stories by his lackeys telling him what he wants to hear.

Admit to having drank the koolaide, it is the first step. I wrote an entire system with tech I barely understand (duckdb), next.js etc, made 7 to 10 iterations per day, and multiple new functions and integrations in hours all while doing my main job. What does the code look like ???. It works, I do not care. Can the AI modify it in under 5 minutes, yes. New features that would take minimal a week, got done in 2 to 3 minutes. Did the AI ever complain, no it did not. Anyone who thinks they will be hand coding going forward is completely fooling themselves. The AI tests better than most engineers. When asked it builds flawless test harnesses and even suggests better solutions. Never going back.

Odd. In my industry every IC is using Ai (embedded software). Maybe we shouldn’t generalize?

Why would ICs be enamored with something quite literally designed to replace them?

Because the majority of executives think AI is a magical black box, I’d reckon.

Well I'm not looking forward to being out of a job and health insurance.

The implementation is harder than watching a few youtube videos on it

I think one reason for the excitement is that the “software crisis” is real, painful, and costly. Thus it’s tempting to grasp for a shiny new silver bullet that might have a chance of solving it.

I’m neither a developer nor an executive, but from my vantage point the software crisis has to do with the fact that software development presents an existential risk to any organization that engages in it. It seems to be utterly resilient to estimation, and projects can run late by months or even years with no good explanation except “it’s management’s fault.” This has been discussed at length. If I had a good answer, “I wouldn’t still be working here” as the saying goes. But half a century after The Mythical Man Month, it still reads like it was written yesterday, and “no silver bullets” seems to ring true.

In my view, the software crisis will be resilient. Throwing more code, or more code per day, at a late project will make it later. There will be a grace period while the pace of coding seems exciting, but then the reality will set in: “We haven’t shipped a product.” And it will be management’s fault.

What's an IC?

What? Doesn't this boil down to "people like people who reliably get results", e.g., we live in a complicated nondeterministic world but we try and make it as deterministic as possible, except for some reason you focus on the nondeterministic part for managers, and "deterministic" part for engineers?

Not even sure if determinism is a good axis to analyze this problem. Also smells extremely like concept creep - do you mean "moving up the abstraction stack" as "non determinism" too?

I liked the article but it misses one point. ICs take pride in some types of expertise they have accumulated over the years. AI kinda nullifies this. For instance, if I worked with Python/Django for ~5-10 years I might have become a sort of expert in Django. I know exactly the utility methods, conventions to use etc. But there's little need for such expertise with AI.

IC is a strange relabeling of a "worker".

When you analyze this as "Management loves AI" and "workers hate it" goes completely back to 'who owns the means of production?', and can be clearly seen within Marx's critique.

Is it really a mystery? A hot take?

Executives see this as way to replace labor.

The labor sees themselves being replaced.

This is a story as old as the hills.

ICs are too.

Because now you need less programmers. It is self explanatory.

But what’s your expectations here? Should companies pretend LLMs don’t exist and just continue as before, or do we need some way of acknowledging there’s a new technology that, when put to good use, can increase productivity?

> all the gains are captured by the executives.

No, they are captured disproportionately by the haut bourgeois capitalists. The two groups overlap to an extent (when major capitalist are nominally employed by a firm they invest in, it is usually as an executive), but executives qua executives (that is, in their role as top level managerial employees) are not the main beneficiaries of increased productivity.

Or unions

Software engineers tried to unionise in the late 90s and early 2000s and people like Steve Jobs illegally colluded with other tech leaders to kill the movement. They ended up paying out huge undisclosed sums to settle the lawsuits.

After that programmers fell into the situation you are describing - relatively high bargaining power and salaries. Hopefully now with the push for AI we will finally see another pro labor organisation effort !

> it’s the same as adding robots that enables workers to pack twice as many pallets per day.

It isn't this. This is the executive's misinterpretation.

It's not. Most developers are pretty bad at their job, and already can't review code very effectively.

They just create even more slop currently, which will be the case until someone realizes they aren't needed to produce slop at all.

If those devs can't operate without an LLM, they weren't worth their salt to begin with. I find that most competent devs are skeptical of the tech, because it doesn't help them. But even among those who embrace it, they would get by just fine if it was gone tomorrow.

What do you work on?

I find people tend to omit that on HN and folks dealing with different roles end up yelling at each other because those details are missing. Being an embedded sw engineer writing straight C/ASM is, for instance, quite different from being a frontend engineer. AI will perform quite differently in each case.

I can’t say who will win or lose. The value of a social network has as much to do with its userbase than its tech, so maybe Meta has a different path. Alphabet and Microsoft are who I really have in mind here.

I drive an EV and am a complete tool!

It remains to be seen whether LLMs actually increase productivity. The jury is far, FAR from delivering the verdict on this one. All I'm seeing out there is blind hope, hype and executive-level excitement about cutting staff.

Must be from the divide and conquer school of management.

The biggest differentiating factor today is engineers and/or decision maker willing to say no to a certain feature or implementation.

It's too easy to add bloat and complexity that can never go away, and with the tooling we now have a significant portion of engineers are now active risk to the projects they are working on.

I'm not talking about LLM, of course they save time.

I'm talking about adding code to a code base. After a certain size, it's mostly garbage. I subscribe to the old unix principle and I have yet to seen a reason how LLM has changed it, it in fact became much more important now as a coding agent would happily add any crap to any repository.

My experience is that it gets the syntax right but constantly hallucinates APIs and functions that don't exist but sound like they should. It also seems to be tricked by variable names that don't line up with their usage.

Right, but Carmack has always delivered. I need someone without Carmack’s ability to show me what value they can deliver with AI

Perhaps I should have gone for Sherlock Holmes doing morphine as an analogy. Mind you the '90s raver fits for some models or is it the prompter ...

> Your team's screwdriver usage is only 30% of the company's target. 80% of other teams at Taylor Manufacturing Co. are leveraging Screw Driving tools more often as a regular part of their daily work. If your team doesn't improve, we'll need to come up with a retraining plan.

> But we're the accounting team?

> Doesn't matter. This is a SD-Native company now. We believe everyone can be more productive with an SD-based workflow.

Classic kafka trap! The mere sign of resistance is a sign of a deeper psychological incompatibility that fundamentally needs to be worked through until you agree with the state.

How is it not? It reads to me as them saying that all these devs have deskilled from "barely competent" to "completely helpless". Or is your claim that they were actually really good devs, and the deskilling has been even more intense than I'm picturing?

Because that also sounds real bad!

It’s not a mystery… I can tell you what I do most days, and probably 80% of it is communication. An AI could do that. That communication is to learn what is going on up, down, and across the org. I mostly want to make sure we aren’t doing redundant work — though sometimes that is useful, and making sure timelines aren’t slipping. Oh, and dealing with conflicts.

The other 20% is writing: policies, SOPs, audits, grants, performance reviews, etc.

I could probably automate over half my job in n8n in a weekend… hmm… actually might try that.

I’m in a heavily-regulated sector, fully remote. If left alone, our junior exec:

- needs a digest of where chat activity is hottest. Maybe he lurks, occasionally he gets into conversations about what’s going on in another department.

- needs some warning if the Microsoft systems are under attack or strain. The Linux systems have not needed attention; the jargon is unfamiliar.

- occasionally brings up hypothetical radical changes in strategy. I think of these as multivariate tests. Maybe I reply, “Plenty of Kubenetes developers available right now” might communicate that some small team would be ahead of us on some solved problem.

I’m surprised that:

- he has no concern that competition even exists. No awareness that our competition demos at conferences; why they’d choose to spend time that way.

- no interest in the big accounts we don’t have. If it would take a big lift, what would engineering need? If it would take a small lift, what non-engineering is blocking? No interest.

- person-to-person networking is effective at all. I just can’t imagine any value in two execs meeting without hours of preparation.

I’ve seen BI tooling around each of these. I wonder if a daily “facts of our department” slide to begin each meeting, if that would replace/augment 51% of visible exec.

I do regularly read the code that Claude outputs. And about 25% of the time the tests it writes will reimplement the code under test in the test.

Another 25% of the time the tests are wrong in some other way. Usually mocking something in a way that doesn't match reality.

And maybe 5% of the time Claude does some testing that requires a database, it will find some other database lying around and try to use that instead of what it's supposed to be doing.

And even if Claude writes a correct test, it will general have it skip the test if a dependency isn't there--no matter how fervently I tell it not to.

If you're not looking the code at all, you're building a house of cards. If you not reading the tests you're not even building you're just covering the floor in a big sloppy pile of runny shit.

I'd understand not reading the code of the system under test, but you don't even read the tests? I'd do that if my architecture and design were very precise, but at this point I'd have spent too much time designing rather than implementing (and possibly uncovering unknown unknowns in the process).

> Me (and my friends similarly) inspect code indirectly now - telling agents to write reports about certain aspects of the code and architecture etc.

Doesn't this take longer than reading the code?

I can see how some of this is part of the future (I remember this article talking about python modules having a big docstring at the top fully describing the public functions, and the author describing how they just update this doc, then regenerate the code fully, never reading it, and I find this quite convincing), but in the end I just want the most concise language for what I'm trying to express. If I need an edge case covered, I'd rather have a very simple test making that explicit than more verbose forms. Until we have formal specifications everywhere I guess.

But maybe I'm just not picturing what you mean exactly by "reports".

I've seen the code these models produce without a human programmer going over the results with care. It's still slop. Better slop than in the past, but slop none the less. If you aren't at minimum reading the code yourself and you're shipping a significant amount of it, you're either effectively the first person to figure out the magic prompt to get the models to produce better code, or you're shipping slop. Personally, I wouldn't bet on the former.

If I were you I’d very worried about getting laid off. That kind of work isn’t going to keep earning a software engineer salary.

you're a slop maker

> How do you know whether the tests it’s spits out are bad if you don’t read the tests.

I do read the tests (quickly, I admit) and so does OP:

Architecture overview sure, and testing yes, but not reading the code directly any more.

Reading that again I may have misunderstood what they meant by "testing yes", though.

I read the tests, it also is really really good to have Claude verify that removing the changes in question break the tests. This brings the quality way way up for me.

I wonder if your background just has you fooled. I worked on a data science team and code was always a commodity. Most data scientists know how to code in a fairly trivial way, just enough to get their models built and served. Even data engineers largely know how to just take that and deploy to Spark. They don't really do much software engineering beyond that.

I'm not being precious here or protective of my "art" or whatever. But I do find it sort of hilarious and obvious that someone on a data science team might not understand the aesthetic value of code, and I suspect anyone else who has worked on such a team/ with such a team can probably laugh about the same thing - we've uh... we've seen your code. We know you don't value aesthetic code lol. Single variable names, `df1`, `df2`, `df3`.

I'm not particularly uncomfortable at the moment because understanding computers, understanding how to solve problems, understanding how to map between problems and solutions, what will or won't meet a customer's expectations, etc, is still core to the job as it always has been. Code quality is still critical as well - anyone who's vibe-coded >15KLOC projects will know that models simply can not handle that scale unless you're diligent about how it shoul dbe structured.

My job has barely changed semantically, despite rapid adoption of AI.

> their life’s work is now a commodity

Which parts of it exactly? I've considered for loops and if branches "commodities" for a while. The way you organize code, the design, is still pretty much open and not a solved problem, including by AI-based tools. Yes we can now deal with it at a higher level (e.g. in prompts, in English), but it's not something I can fully delegate to an agent and expect good results (although I keep trying, as tools improve).

LLM-based codegen in the hands of good engineers is a multiplier, but you still need a good engineer to begin with.

What I don't get is that there should now be focus on the actual engineering part of software development. I have arguments with people about code quality, styling, how "structured" some work is, when in reality, in an engineering discipline we should focus on whether we can improve the software by functional or non functional metrics.

Like what about performance optimization or security analysis? Shouldn't AI be the CAD of coding tools? Idk.

My problem is that c suite equates “vibe coding” and what you need is spec driven dev.

Spec driven dev is good software engineering practice. It’s been cast aside in the name of “agile” (which has nothing to do with not doing docs - but that’s another discussion).

My problem is writing good specs takes time. Reviewing code and coaxing the codegen to use specific methods (async, critical sections, rwlocks, etc) is based on previous dev experience. The general perception with c suite is that neither is important now since “vibing” is what’s in.

My problem with the code the agents produce has nothing to do with style or art. The clearest example of how bad it is was shown by Anthropic's experiements where agents failed to write a C compiler, which is not a very hard programming job to begin with if you know compilers, as the models do, but they failed even with a practically unrealistic level of assistance (a complete spec, thousands of human-written tests, and a reference implementation used as an oracle, not to mention that the models were trained on both the spec and reference implementation).

If you look at the evolution of agent-written code you see that it may start out fine, but as you add more and more features, things go horribly wrong. Let's say the model runs into a wall. Sometimes the right thing to do is go back into the architecture and put a door in that spot; other times the right thing to do is ask why you hit that wall in the first place, maybe you've taken a wrong turn. The models seem to pick one or the other almost at random, and sometimes they just blast a hole through the wall. After enough features, it's clear there's no convergence, just like what happened in Anthropic's experiment. The agents ultimately can't fix one problem without breaking something else.

You can also see how they shoot themselves in the foot by adding layers upon layers of defensive coding that get so think they themselves can't think through them. I once asked an agent to write a data structure that maintains an invariant in subroutine A and uses it in subroutine B. It wrote A fine, but B ignored the invariant and did a brute-force search over the data, the very thing the data structure was meant to avoid. As it was writing it the agent explained that it doesn't want to trust the invariant established in A because it might be buggy... Another thing you frequently see is that the code they write is so intent on success that it has a plan A, plan B, and plan C for everything. It tries to do something one way and adds contingencies for failure.

And so the code and the complexity compound until nothing and no one can save you. If you're lucky, your program is "finished" before that happens. My experience is mostly with gpt5.4 and 5.3-codex, although Anthropic's failed experiment shows that the Claude models suffer from similar problems. What does it say when a compiler expert that knows multiple compilers pretty much by heart, with access to thousands of tests, can't even write a C compiler? Most important software is more complex than a C compiler, isn't as well specified, and the models haven't trained on it.

I wish they could write working code; they just don't.[1] But man, can they debug (mostly because they're tenacious and tireless).

[1]: By which I don't mean they never do, but you really can't trust them to do it as you can a programmer. Knowing to code, like knowing to fly a plane, doesn't mean sometimes getting the right result. It means always getting the right result (within your capabilities that are usually known in advance in the case of humans).

> literally

You were either a very talented baby or we’re justified in questioning your ability to assess the correctness of nitpicky formalisms.

I have worked at many places and have seen the work of DEs and DSs that is borderline psychotic; but it got the job done, sorta. I have suffered through QA of 10000 lines that I ended up rewriting in less than 100.

So, yes; I understand where you’re coming from. But; that’s not what we do.