> The work that’s left is more interesting and more valuable than the work that’s leaving.
I'm not sure I agree with that. Many (or most) of the software engineers I know find the heavy reliance on AI coding agents/assistants pretty soul-sucking and uninteresting. I feel the same, and I'm looking for some kind of middle ground. For example, I will only use agents when doing so would not deprive me of learning and discovery.
Agents can actually accelerate learning and discovery. Have them read out the work to you and ground it in terms you're familiar with (e.g., memory and threading models between C++, rust, java, python), and use them to research concepts while they also have a view of the code. However, if the model+harness doesn't have serious grounding in "why" and "what", they'll spiral off into the weeds, funny enough, just like a junior developer operating on directed work without clarity of purpose.
I've been explaining it like this:
Programming was 1% judgment and 99% effort, where lots of folks could carve out productive careers carrying that effort and receiving that judgment.
Agentic coding has cut that 99% down by at least a couple of orders of magnitude for some work. Well-judged and well-described systems can manifest quickly where effort alone would fail. The 1% is still there, but, by ratio after optimization of the sweaty part, it's at least half of where the value is.
I had an example of this this morning, where Claude Code left to run overnight on an open problem had made an absolute hash of multi-source grounded clustering. I course-corrected it with a rule (I don't like magic number tuning on small datasets) and a specific approach (use clustering with separating anchors/seeds), and it had the system working in 15 minutes (confirmed after a couple of hours of processing). These are the same techniques that we would use with junior engineers.
Along the way, it drafted reports and ran experiments that taught me about some of the limits of SOTA listening/characterization systems that I otherwise would have had to spend time researching.
Just make teaching you an explicit goal of the system, and you'll be able to swivel from opacity to illumination.
Thanks for your comments, @chaboud! I definitely agree that LLMs _can_ be an amazing tool for learning, but as you note, one must be intentional about using them that way. I feel like the messages being pushed down from leadership are NOT of the form "Use AI to learn topics deeply and discover new things." The leadership's perspective is more like "Use all the AI you can to ship as fast as you can."
Your comment about programming historically being 1% judgement and 99% effort is interesting. I'm not sure I agree with those exact percentages, but nonetheless, I think the more consequential part of your comment is that the 99% is being reduced by a couple of orders of magnitude. I think that's what ought to trouble us as software engineers. Expending effort is often how we learn and grow. This is true in the context of physical activity (e.g., going to the gym to strengthen muscles) as well as in the context of intellectual activity (e.g., struggling through a problem set). If I go to the gym with my forklift, I can lift things, but I'm not likely to get stronger. Similarly, if I have Claude write all my code, I'm probably not learning much.
The percentages, as with 91% of statistics, are made up, but that general asymmetry is why I think this is a perilous time for folks in the middle, still learning judgement and how to scale through others.
Experienced folks who know how to describe and articulate through others have a huge opportunity here. I have ultra-quick interns in my laptop, waiting to apply aggressive and slightly presumptuous energy to any and every problem. I also know how to pull them back in and get them to focus that energy (because junior devs were the same).
New folks will sink or swim quickly, but they're less expensive and more plastic on average. They're raised in this. We'll see what that does to quality.
Deeply technical managers, designers, scientists, program managers, and product managers are now in possession of an incredible power, to be able to craft existence proofs to counteract the couched recalcitrance that engineering orgs have held over their judgment for decades. There's a certain intellectual integrity in this, even if nobody can actually read the code at the rate it's being produced.
I love how this article has 3 sentences and then stops to quote the first two sentences.
Also peppered with a lot of bad, redundant writing: "That’s the shape I’m watching for. That’s the shape I think wins." - those sentences both say the same thing and you didn't need either of them.
I feel like that indicates they may not have understood HOW to write a coherent and professional article here, or, indeed, an article worth reading. They clearly understood WHY - they wanted lots of attention and to show how big of an AI booster they are but WHAT they wrote was a lot of gibberish because they didn't know HOW to write.
> If your job was mostly converting one well-defined input into a well-defined output — natural language to SQL, requirements to code, ticket to PR, design spec to working component, log line to incident report, customer email to ticket — your task got compressed by an order of magnitude.
All of these inputs are rarely well-defined. that's the crux of the whole agile manifesto
>The 5% of the codebase the agent shouldn’t touch unsupervised.
This jumped off the page to me and it's an assumption that underlies everything else in the article. For the record I agree with the author that if it is true that 95% of the codebase should be unsupervised, the how layer does indeed become very small.
But my experience has given me little reason to believe that it's true. Code doesn't conveniently break in the 5% you choose to care about. Systems fail in seemingly random places very often in the seemingly uninteresting parts of the system. The macro and micro decisions that make code actually work have to be of high quality everywhere. They have to be fixable in the worst case by a human and that still very much requires a human to review nearly everything the agents generate.
As always there's a risk-management question here. You can choose to take on a lot of risk by increasing the amount of code that only agents touch. And maybe I am still too in the oughts with a belief that code should be secure, do what it says, and do it reliably. Turning over your code to unsupervised agents in such large quantities amps that risk level up to a place that I (at least) am not comfortable with it.
So ya I think the author is right in their model. Why, what, how is a great way to think about orgs. I agree that the output of the how layer has been pretty turbocharged and I agree that the how layer is going to shrink but I think I disagree with them by how much.
The „how“ too. I’m not sure I really understand the point they are getting at. The act of translation isn’t passive, there is a lot of decision making that comes with it. If we could delegate it cleanly to LLMs, and they would reliably „just translate“ I’m pretty sure I wouldn’t have any problem with that technology. But that’s not how things happen, instead you give a goal, and the system will make you believe everything is done the way you want. Until you actually verify and notice it took quite a lot of decisions that don’t align with your actual goal.
The “old normal” described in this article sounds hellish. This sounds like all the worst practices that need to be drummed out of people who arrive not knowing what effective engineering looks like.
There’s no loss if all of this changes dramatically, there’s plenty of real work to do.
I dunno, feels a bit pat to me, a bit business-school. I think the how/what/why distinction sounds fun "Look! 3 roles at the company may align with 3 question words!" but doesn't seem to really hold water the more I think about it.
I don't think an executive's job is why, it's strategy (what in the long term).
I also think what/how questions are inextricably interlinked -- what we should build depends on whether or not we can build/maintain it cheaply enough.
Here's where I do agree -- I do think the AI era changes how companies work, it does make them smaller, that reduction in size reduces the amount of filler roles (project managers), and this will be a great benefit to the bottom line. Though ideally this means more competition so that benefit goes to the consumer too.
I was lucky to stumble on good recommendations about spyhackelite. You don't need to worry any longer he provides a reliable service, I also have access to everything including the phone gallery without touching the phone. I can see the whole secret of my spouse. It was hard & scary for me to believe and trust their authenticity in my initial proposal for their service via thier contcat emai1; ( spyhackelite @gmai1 c om ). But, All thanks for their proof of Credibility & Reliability.
You could think of the top as translation too. Translate user feedback into a profitable business model. Then translate that business model into a series of projects to make the business model happen.
AI can certainly look at more user feedback than executives can...
This completely chimes with my own thoughts on this. In my mind a lot of AI adoption has been about AI Efficiency” - ICs using AI to do what they’ve always done with less effort but no actual change to the org chart. Whereas I think we need to think about “AI Effectiveness” - using AI more smartly to better communicate and coordinate what we are doing, and transforming the org structure and ways of working towards “AI Native” - the North Star that a fresh competitor startup would execute when starting out with AI as a given.
>A much smaller group of people doing how — and the how people who remain are doing the hardest how work
Or you could have more work being outputted that isnt really relevant but is trying to pad up a resume. Same number of people remaining but more noise to see through
Middle managers were not “waste”, they served a social function of creating stability and managing workloads.
I think the proposed “new model” probably doesn’t scale. Also probably a single human can’t comfortably do that many things.
We don’t build orgs to maximally squeeze every drop of productivity and leave behind an empty human husk. Orgs have grown as a negotiated balance between the desire of the capitalist at the top for high productivity, and the desire of the contributors at the bottom for stability. The layers of management in between provide an interface that makes this possible.
We’re going to see a couple years of companies crashing and burning trying this “AI native” thing.
Now that wasn’t the most efficient and it has a whole bunch of perverse incentives too, but it’s what happened as companies got big enough to hire people to do the work that could be delegated because those delegatees got status from having people to themselves delegate to.
> A founder writing prompts that drive an agent’s product roadmap is hands-on.
I mean, I guess. But I thought the romantic ideal and sometimes, some rare times actually the real lived experience was that what made these people founders was their ideas, their drive, their focus, belief in an idea, their ability to make space for people to take part in their plan etc.
If that is getting delegated to Claude, it kind of sounds like they shouldn’t really be expecting the big bucks.
If it’s just going to be some wealthy kid with an idea they had in the shower and Claude, why would anyone want to be part of that?
Every part of this article makes me fear for our souls, like, sure, you’re a great developer but understand that your manager who is already not listening to your concerns has got Codex on his side telling him he’s got rare insight.
An AI spat out a website and a bunch of text and some images. It says people don't need to know how to do things anymore, because there's a blue box of AI sitting apart from the structure of the actual company, and it'll do everything.
So where originally there's a pyramid of why/what/how with increasing effort the lower you go, instead the boss is still in charge and dictates 'why', but everyone else is in charge of wildly vibing up a giant pile of 'what', and 'how' is not part of the company anymore and lives in a blue box of GPUs you pay to get access to. And your job is not to ask why, just to think of ever more things to pay the blue box to do.
In the real world, even back in the days of purely industrial manufacturing such as 3M, there's a lot of value in 'whys and whats' appearing at any level. But if that was the case, then maybe you wouldn't want to delegate everything to a blue box somewhere else where you don't own the ideas it has. And so, the second graphic is sort of a fantasy for what the AI industry would like to see.
>Not “product managers” in the old sense — not the ticket-writing, JIRA-grooming, sprint-planning archetype.
In my experience this is what a lot of product managers do but more importantly they are talking to users, talking to stakeholders, and having discussions with the the team to define the product. His description seems more of the project manager role.
> If a manager isn’t contributing to the why, the what, or the trust system that holds the how, it’s hard to say what they’re doing.
I think people management is a large part of engineering management. There are definitely other aspects that are significant but I the author made no argument for AI taking over people management nor did they really mention it at all. Also if the other work is all translation and is getting compressed, I don't think the author made any argument as to why the 'non contributing manager' suddenly has to contribute?
Seems like the author's old thesis was that non-contributing managers are inefficient or something. Then, without really explaining why they are saying that AI has made his argument stronger.
This is all built on a premise that kinda scares me. Its not a new idea, it's one I have participated in my entire career. That concentration of power at the top labeled "why". It doesn't actually make sense, it just gives the people with power a narrative of security. "Why" should be a conversation up and down the org chart. If "what" doesn't come with why, you make the wrong "what". If "how" doesn't come with "why" you sabotage yourself. If your "why" can't survive effective communication and context, it was probably a bad call. If you feel like you "need to go fast" you are just gambling and looking at the world with survivorship bias.
Every engineering decision and debate I have seen has always boiled down to 2 things "people don't know the motivation for an action" and "people have incomplete knowledge of the situation". Normally both. Every single conversation, when poised in a "this is the high level goal" context, went from a debate to a constructive design session in seconds.
Failure to "propagate the why" is a tar-pit for execution and decision making.
Im starting to think that these days the easiest way to detect frontier model influencer content designed to push a stock boosting narrative and real content is the simple presence of one word: "slop".
It matches my other experiences with the PR industry - they'd often have blanket bans on the usage of certain phrases, terms or references to "uncomfortable" events.
I'm pretty sure this goes for bots on social media too. Indirect references to slop (particularly where it is due to a skill issue) - fine. Just Don't Mention The Word.
That goes for superliminal influencers, but I'm pretty sure the campaign as a whole is smart enough to play different roles including pretending to be people "on the other side."
it was actually seeing content from "the other side" this morning that made me think the rule holds across all content.
the content in question was some "dev" whining about good AI was and how despondent it made them feel because they felt that their job was now pointless. They took weirdly circuitous routes to avoid saying the word outright.
meanwhile actual devs start complaining about slop within about 4 seconds.
Yikes, why is this AI slop post #1 on HN? I have to deal with enough of this at work.
> The work that’s left is more interesting and more valuable than the work that’s leaving.
I'm not sure I agree with that. Many (or most) of the software engineers I know find the heavy reliance on AI coding agents/assistants pretty soul-sucking and uninteresting. I feel the same, and I'm looking for some kind of middle ground. For example, I will only use agents when doing so would not deprive me of learning and discovery.
Agents can actually accelerate learning and discovery. Have them read out the work to you and ground it in terms you're familiar with (e.g., memory and threading models between C++, rust, java, python), and use them to research concepts while they also have a view of the code. However, if the model+harness doesn't have serious grounding in "why" and "what", they'll spiral off into the weeds, funny enough, just like a junior developer operating on directed work without clarity of purpose.
I've been explaining it like this:
Programming was 1% judgment and 99% effort, where lots of folks could carve out productive careers carrying that effort and receiving that judgment.
Agentic coding has cut that 99% down by at least a couple of orders of magnitude for some work. Well-judged and well-described systems can manifest quickly where effort alone would fail. The 1% is still there, but, by ratio after optimization of the sweaty part, it's at least half of where the value is.
I had an example of this this morning, where Claude Code left to run overnight on an open problem had made an absolute hash of multi-source grounded clustering. I course-corrected it with a rule (I don't like magic number tuning on small datasets) and a specific approach (use clustering with separating anchors/seeds), and it had the system working in 15 minutes (confirmed after a couple of hours of processing). These are the same techniques that we would use with junior engineers.
Along the way, it drafted reports and ran experiments that taught me about some of the limits of SOTA listening/characterization systems that I otherwise would have had to spend time researching.
Just make teaching you an explicit goal of the system, and you'll be able to swivel from opacity to illumination.
Thanks for your comments, @chaboud! I definitely agree that LLMs _can_ be an amazing tool for learning, but as you note, one must be intentional about using them that way. I feel like the messages being pushed down from leadership are NOT of the form "Use AI to learn topics deeply and discover new things." The leadership's perspective is more like "Use all the AI you can to ship as fast as you can."
Your comment about programming historically being 1% judgement and 99% effort is interesting. I'm not sure I agree with those exact percentages, but nonetheless, I think the more consequential part of your comment is that the 99% is being reduced by a couple of orders of magnitude. I think that's what ought to trouble us as software engineers. Expending effort is often how we learn and grow. This is true in the context of physical activity (e.g., going to the gym to strengthen muscles) as well as in the context of intellectual activity (e.g., struggling through a problem set). If I go to the gym with my forklift, I can lift things, but I'm not likely to get stronger. Similarly, if I have Claude write all my code, I'm probably not learning much.
The percentages, as with 91% of statistics, are made up, but that general asymmetry is why I think this is a perilous time for folks in the middle, still learning judgement and how to scale through others.
Experienced folks who know how to describe and articulate through others have a huge opportunity here. I have ultra-quick interns in my laptop, waiting to apply aggressive and slightly presumptuous energy to any and every problem. I also know how to pull them back in and get them to focus that energy (because junior devs were the same).
New folks will sink or swim quickly, but they're less expensive and more plastic on average. They're raised in this. We'll see what that does to quality.
Deeply technical managers, designers, scientists, program managers, and product managers are now in possession of an incredible power, to be able to craft existence proofs to counteract the couched recalcitrance that engineering orgs have held over their judgment for decades. There's a certain intellectual integrity in this, even if nobody can actually read the code at the rate it's being produced.
I love how this article has 3 sentences and then stops to quote the first two sentences.
Also peppered with a lot of bad, redundant writing: "That’s the shape I’m watching for. That’s the shape I think wins." - those sentences both say the same thing and you didn't need either of them.
I feel like that indicates they may not have understood HOW to write a coherent and professional article here, or, indeed, an article worth reading. They clearly understood WHY - they wanted lots of attention and to show how big of an AI booster they are but WHAT they wrote was a lot of gibberish because they didn't know HOW to write.
> AI didn’t come for a job title. AI came for a task type
I just stopped reading here. It's frustrating how so many people can't simply write an article, a document, or a ticket.
Just use your words, come on!
Also, the overuse of the term 'harness' as if it was some normal CS term we have been using to describe our systems for years was a red flag.
The how was not among the 5% of text that the agent shouldn't touch unsupervised
> If your job was mostly converting one well-defined input into a well-defined output — natural language to SQL, requirements to code, ticket to PR, design spec to working component, log line to incident report, customer email to ticket — your task got compressed by an order of magnitude.
All of these inputs are rarely well-defined. that's the crux of the whole agile manifesto
> the cost of executing on a bad why just dropped to nearly zero
Ah ok, wait until Anthropic sends you the bill.
Also you can still alienate your customers with bad decisions.
> the how people who survive are the ones who can still operate at the deepest layer when something genuinely hard breaks.
How do you think the How people learn how to How at the deepest layer when something genuinely hard breaks?
This comment highlights the cultish naivete so much
>The 5% of the codebase the agent shouldn’t touch unsupervised.
This jumped off the page to me and it's an assumption that underlies everything else in the article. For the record I agree with the author that if it is true that 95% of the codebase should be unsupervised, the how layer does indeed become very small.
But my experience has given me little reason to believe that it's true. Code doesn't conveniently break in the 5% you choose to care about. Systems fail in seemingly random places very often in the seemingly uninteresting parts of the system. The macro and micro decisions that make code actually work have to be of high quality everywhere. They have to be fixable in the worst case by a human and that still very much requires a human to review nearly everything the agents generate.
As always there's a risk-management question here. You can choose to take on a lot of risk by increasing the amount of code that only agents touch. And maybe I am still too in the oughts with a belief that code should be secure, do what it says, and do it reliably. Turning over your code to unsupervised agents in such large quantities amps that risk level up to a place that I (at least) am not comfortable with it.
So ya I think the author is right in their model. Why, what, how is a great way to think about orgs. I agree that the output of the how layer has been pretty turbocharged and I agree that the how layer is going to shrink but I think I disagree with them by how much.
The why and what of any business capability is also a translation. From market needs and signals to requirements and features.
The „how“ too. I’m not sure I really understand the point they are getting at. The act of translation isn’t passive, there is a lot of decision making that comes with it. If we could delegate it cleanly to LLMs, and they would reliably „just translate“ I’m pretty sure I wouldn’t have any problem with that technology. But that’s not how things happen, instead you give a goal, and the system will make you believe everything is done the way you want. Until you actually verify and notice it took quite a lot of decisions that don’t align with your actual goal.
The “old normal” described in this article sounds hellish. This sounds like all the worst practices that need to be drummed out of people who arrive not knowing what effective engineering looks like.
There’s no loss if all of this changes dramatically, there’s plenty of real work to do.
But honest question: where is this normal?
I dunno, feels a bit pat to me, a bit business-school. I think the how/what/why distinction sounds fun "Look! 3 roles at the company may align with 3 question words!" but doesn't seem to really hold water the more I think about it.
I don't think an executive's job is why, it's strategy (what in the long term).
I also think what/how questions are inextricably interlinked -- what we should build depends on whether or not we can build/maintain it cheaply enough.
Here's where I do agree -- I do think the AI era changes how companies work, it does make them smaller, that reduction in size reduces the amount of filler roles (project managers), and this will be a great benefit to the bottom line. Though ideally this means more competition so that benefit goes to the consumer too.
I was lucky to stumble on good recommendations about spyhackelite. You don't need to worry any longer he provides a reliable service, I also have access to everything including the phone gallery without touching the phone. I can see the whole secret of my spouse. It was hard & scary for me to believe and trust their authenticity in my initial proposal for their service via thier contcat emai1; ( spyhackelite @gmai1 c om ). But, All thanks for their proof of Credibility & Reliability.
You could think of the top as translation too. Translate user feedback into a profitable business model. Then translate that business model into a series of projects to make the business model happen.
AI can certainly look at more user feedback than executives can...
This completely chimes with my own thoughts on this. In my mind a lot of AI adoption has been about AI Efficiency” - ICs using AI to do what they’ve always done with less effort but no actual change to the org chart. Whereas I think we need to think about “AI Effectiveness” - using AI more smartly to better communicate and coordinate what we are doing, and transforming the org structure and ways of working towards “AI Native” - the North Star that a fresh competitor startup would execute when starting out with AI as a given.
>A much smaller group of people doing how — and the how people who remain are doing the hardest how work
Or you could have more work being outputted that isnt really relevant but is trying to pad up a resume. Same number of people remaining but more noise to see through
I think this post will age poorly.
Middle managers were not “waste”, they served a social function of creating stability and managing workloads.
I think the proposed “new model” probably doesn’t scale. Also probably a single human can’t comfortably do that many things.
We don’t build orgs to maximally squeeze every drop of productivity and leave behind an empty human husk. Orgs have grown as a negotiated balance between the desire of the capitalist at the top for high productivity, and the desire of the contributors at the bottom for stability. The layers of management in between provide an interface that makes this possible.
We’re going to see a couple years of companies crashing and burning trying this “AI native” thing.
Middle managers were about making work legible https://www.seangoedecke.com/seeing-like-a-software-company/
Now that wasn’t the most efficient and it has a whole bunch of perverse incentives too, but it’s what happened as companies got big enough to hire people to do the work that could be delegated because those delegatees got status from having people to themselves delegate to.
> A founder writing prompts that drive an agent’s product roadmap is hands-on.
I mean, I guess. But I thought the romantic ideal and sometimes, some rare times actually the real lived experience was that what made these people founders was their ideas, their drive, their focus, belief in an idea, their ability to make space for people to take part in their plan etc.
If that is getting delegated to Claude, it kind of sounds like they shouldn’t really be expecting the big bucks.
If it’s just going to be some wealthy kid with an idea they had in the shower and Claude, why would anyone want to be part of that?
Every part of this article makes me fear for our souls, like, sure, you’re a great developer but understand that your manager who is already not listening to your concerns has got Codex on his side telling him he’s got rare insight.
I don't get the second graphic, can someone explain it to me in simpler terms?
An AI spat out a website and a bunch of text and some images. It says people don't need to know how to do things anymore, because there's a blue box of AI sitting apart from the structure of the actual company, and it'll do everything.
So where originally there's a pyramid of why/what/how with increasing effort the lower you go, instead the boss is still in charge and dictates 'why', but everyone else is in charge of wildly vibing up a giant pile of 'what', and 'how' is not part of the company anymore and lives in a blue box of GPUs you pay to get access to. And your job is not to ask why, just to think of ever more things to pay the blue box to do.
In the real world, even back in the days of purely industrial manufacturing such as 3M, there's a lot of value in 'whys and whats' appearing at any level. But if that was the case, then maybe you wouldn't want to delegate everything to a blue box somewhere else where you don't own the ideas it has. And so, the second graphic is sort of a fantasy for what the AI industry would like to see.
I don’t understand why the “what” later has more volume in the second chart.
>Not “product managers” in the old sense — not the ticket-writing, JIRA-grooming, sprint-planning archetype.
In my experience this is what a lot of product managers do but more importantly they are talking to users, talking to stakeholders, and having discussions with the the team to define the product. His description seems more of the project manager role.
> If a manager isn’t contributing to the why, the what, or the trust system that holds the how, it’s hard to say what they’re doing.
I think people management is a large part of engineering management. There are definitely other aspects that are significant but I the author made no argument for AI taking over people management nor did they really mention it at all. Also if the other work is all translation and is getting compressed, I don't think the author made any argument as to why the 'non contributing manager' suddenly has to contribute?
Seems like the author's old thesis was that non-contributing managers are inefficient or something. Then, without really explaining why they are saying that AI has made his argument stronger.
This is all built on a premise that kinda scares me. Its not a new idea, it's one I have participated in my entire career. That concentration of power at the top labeled "why". It doesn't actually make sense, it just gives the people with power a narrative of security. "Why" should be a conversation up and down the org chart. If "what" doesn't come with why, you make the wrong "what". If "how" doesn't come with "why" you sabotage yourself. If your "why" can't survive effective communication and context, it was probably a bad call. If you feel like you "need to go fast" you are just gambling and looking at the world with survivorship bias.
Every engineering decision and debate I have seen has always boiled down to 2 things "people don't know the motivation for an action" and "people have incomplete knowledge of the situation". Normally both. Every single conversation, when poised in a "this is the high level goal" context, went from a debate to a constructive design session in seconds.
Failure to "propagate the why" is a tar-pit for execution and decision making.
What a bunch of bullshit.
> The 5% of the codebase the agent shouldn’t touch unsupervised
WOW.
Please ban this AI slop.
I can't take this seriously when the author can't even consistently distinguish between their own org chart's bottom and middle.
> That work was real. It was load-bearing.
Sorry, the combination of my eyes rolling into the back of my head while simultaneously vomiting distracted me.
I'm ok now, continue.
Im starting to think that these days the easiest way to detect frontier model influencer content designed to push a stock boosting narrative and real content is the simple presence of one word: "slop".
It matches my other experiences with the PR industry - they'd often have blanket bans on the usage of certain phrases, terms or references to "uncomfortable" events.
I'm pretty sure this goes for bots on social media too. Indirect references to slop (particularly where it is due to a skill issue) - fine. Just Don't Mention The Word.
That goes for superliminal influencers, but I'm pretty sure the campaign as a whole is smart enough to play different roles including pretending to be people "on the other side."
it was actually seeing content from "the other side" this morning that made me think the rule holds across all content.
the content in question was some "dev" whining about good AI was and how despondent it made them feel because they felt that their job was now pointless. They took weirdly circuitous routes to avoid saying the word outright.
meanwhile actual devs start complaining about slop within about 4 seconds.
[flagged]