The operating cost starts after the demo | Hacker News Reader

The operating cost starts after the demo

twoheads.net

57 pointshellokfk46 comments

Writing about the operating cost of AI tools while the whole article is a complete AI slop. :)

Whether written with AI or not, I don't necessarily agree with the sentiment that it's AI slop. We too often only categorize between no AI used and AI slop.

Does them using AI to write the article invalidate the points stated in any way? I personally don't think so. I too am weary of constant bombardment with AI but at the same time being against something just because AI was in the loop isn't much better, if at all.

I see no issues in articles where AI was in the loop or made the article better than it otherwise would have been. Why not?

But if 100% is generated by AI - and you just prompted it - then I would like to avoid that piece. Personally.

Thats a fair take. I think it still holds some value because an opinion does not lose validity simple because its being presented poorly, but I also understand that the importance an opinion has for you, should inform the amount of effort you spend, to share it with others.

> We too often only categorize between no AI used and AI slop

We do not. You might have not noticed but we don't discuss the use of AI when nobody notices that AI was used.

Yeah of course not. When nobody notices, then there is nothing to discuss. Otherwise it would just be conjecuture. And by that logic anything where AI is noticable would be categorizable as AI slop. Which is exactly what I'm criticizing

don't post slop then. If AI is noticeable, it is AI slop.

I think there's a difference. Sometimes you'll see some random LLM tells like load-bearing if looking, but you don't notice on a first pass. Those are fine. Slop is slop

If it wasn't worth writing for the author, it won't be worth reading for you and I. If you have a point to make, putting it into words is part of how you structure and understand it yourself. I would much rather read a point imperfectly made by a person, than a bunch of algo-noise around the fuzzy outline of a point that nobody has thought through.

If you value your finite human time and attention you have to somehow sift through the deluge of slop and the simplest, most effective filter is to immediately ditch anything that fails the slop sniff test. You are not owed readers.

> slop sniff test

An unexpected challenge being that our sense of smell requires continual readjustment: Heavy use of em-dashes was formerly a "tell", but the AI-masters retrained them, and now they do the opposite. Indeed, there's a general scarcity of any punctuation other than the period.

It's continually evolving, but a gold standard tell is being very punchy and listy without any semantic content whatsoever. I don't think you can really fix that without heavier human involvement, which undercuts a lot of the slop use-cases. You have to know what you want to say, or the robot will just spin its wheels - and having something to say and a way to say it is kind of the part that requires the most work, so that's not attractive if you're running a bot farm.

People have always judged ideas on their communication. if u rite lk this bro - I'm probably not going to pay much attention. Conversely if you write in a really formal way for a young audience you probably won't get far either. It's a shortcut of importance; if it's not important to you to communicate your message well, then it's probably not that important a message.

And this article is such Ai slop. You see the sentences? All short. All 'punchy'. All with repetition. All for maximum 'impact'. Constant unrelenting impact.

And the lists! The lists, the rolls, the lineup, the rows, the enumeration, the catalogue of examples that goes on too long for comfort, logic, joy, readability or attention.

I'd love to know how many people actually read all of this. I suspect most started skimming as it's just awkward to read, the pacing is just so Ai-y it's exhausting.

I'm never really sure the author reads things like this - I think they wrote something, asked a Ai to punch it up then skimmed it and said 'lgtm'. If you care so little why should anyone else?

I agree with your points, I just struggle with the stance that something is bad simply because AI was in the mix (which tbf is not what you are saying). The writing style is a little too much for my taste as well. At the same time, many of the stylistic choises that LLMs make are not far from how someone who can write well, would express their opinions.

Genuinely curious: How do you know?

So many easy tells, AI, particularly Claude, has a characteristic writing style (Can be alleviated by using smaller/local models).

Your comment would've been more valuable if you actually included at least one actual example of evidence.

The most obvious ones to me are the sentences that aren't actually sentences but just lists of stuff (and sometimes not even proper sentences). It starts at the third sentence and there's one in the majority of paragraphs. LLMs love writing like this but humans don't do this.

"Support tickets, lead follow-ups, reports, internal updates, research, data entry, task assignment, status checks."

"Real work has missing data, unclear requests, old records, broken integrations, private context, bad formatting, vague instructions, and exceptions nobody wrote down."

"They still need ownership. They need monitoring, logs, fallbacks, permissions, updates, and someone who understands both the business and the software."

"People are busy tuning prompts, adjusting workflows, adding tools, joining calls about the automation, reviewing outputs, and fixing strange mistakes."

"It can speed up writing, coding, research, support, operations, and internal tools."

"It can fail, drift, break, make bad assumptions, and produce bad output with confidence. It can depend on tools that change, APIs that fail, and data that gets messy."

"It has to be designed, shipped, watched, fixed, and improved when the business changes."

"The part where the system meets real users, real data, real edge cases, real failures, and real Mondays."

Thanks for the examples. I actually kinda like it, as almost being a form of spoken word poetry; but yes, these lists do seem unusual on a second read-through.

My pattern recognition is a lot less costly to me than your request for proof

I'm pretty sure this comment/article is AI...

Says HN a thousand times on articles that are older than LLMs. I'm not saying this article is or isn't AI, what I am saying is that randos on HN saying something is AI with any definitive certainty hasn't been a great bet. All you do it does is add noise to the conversation.

Agreed, a lot of noise, but for actual data, all of the research into stylometry is also available to LLM vendors, and chasing that target is a major issue in academia and publishing.

So the pushback on the pushback on slop is also noise.

The promise is AI slop, the reality is HN front page!

Yes, but I hear devs cannot live without Claude!

The irony.

More AI written slop...

Just skip it.

Not worth reading.

Came here to figure out why this Ad has 30 upvotes…

Flag it

Why didn't I think of this sooner? You are completely right, there needs to be a a way to punish slop. If anything, it should lower the rating for website in the future as well.

> But a demo is not a system. A demo is controlled. The input is clean, the edge cases are removed, and the happy path is selected in advance. Real work has missing data, unclear requests, old records, broken integrations, private context, bad formatting, vague instructions, and exceptions nobody wrote down.

This has been the case for decades. LLMs are just magnifying it.

That's why I feel that an important part of any engineer's development, should be working on shipping product; where they can have firsthand experience with its use "in the wild."

It can be sobering; sometimes, downright depressing.

But it's a great lesson.

Nothing teaches you like maintaining something for a decade

This is definitely the case with ERP/accounting systems. AI can make the demo look better, but someone inside the company still has to own each process.

I’ve found that no matter what systems companies implement, behind the scenes they usually still run on spreadsheets. Moving people away from that is where the pushback starts.

Typically when I ship anything that is going to be customer facing I am a nervous wreck. Although I'm only 4 years into my career. Does it get better with time?

Not in my experience.

But it is really rewarding, to see my work, actually in use.

You get better at proactively setting up feedback loops and the ability to respond quicker.

Saying "im sorry this is broken it will take us a few weeks to fix it" feels infinitely worse than "im sorry this is broken give us a few hours and we'll get it fixed"

After three decades slinging code, my stress response to high pressure tends to be inversely proportional to the size and competency of the org/team. Suitably sized and capable team? Not going to sweat too much about it. The smaller or less experienced the team, the more other factors come into play.

Lately, I have been working solo, so my stress tracks more closely with development cadence and deadlines. When seeing (or anticipating) the pinch here, I push back with “you can have features or deadlines, but not both”. If you do not push back, you will find yourself being tasked with writing fixes or features for an impossible deadline, and you are not going to have a good time.

Beyond that, your nerves should diminish over time, as you gain more confidence in your ability to produce production quality code. Use language servers and linters, run static and runtime analysis tools, enable every warning, treat warnings as errors, write tests, and so on. Warn the powers that be of the consequences of skipping such steps; once you have clearly warned of possible outcomes from such action (e.g. shipping bugs, slipped deadlines, dropped features), you should not need to carry the burden on your own shoulders.

Good engineering requires constant trade offs, and you should look for a new job if management does not understand and respect such principles. Good organizations should not be stressful places to work.

If you've heard the phrase "it doesn't get easier, you just get stronger" in regards to the gym, I think it's similar for shipping products. I don't feel less nervous about shipping now than I did 15 years ago, but 1) I'm at least marginally better at this than I was then, and most importantly 2) I don't take feedback as personally as I did then.

Feedback is either positive or negative, constructive or not. If it's positive, great. Maybe that gives you some insight into how your work is positively affecting people. If it's negative and constructive, great! Someone is taking time out of their day to tell you how to make your product better, for free. Print the feedback out and hang it on the wall. If it's negative and not constructive, who cares?

That's a good way of putting it.

I still get nervous, but I'm nervous about much more ambitious stuff, these days.

I think negative feedback -even nasty negative feedback- is much more useful than positive fluff.

It's nice to get attaboys, but cursing and kvetching is more likely to improve the product.

Well put, and I think the problem extends beyond agentic systems to regular software. Someone in an organisation whips up a useful product, publishes it and is now on the hook for bug fixes, feature requests and operations. The maintenance cost is often much larger than the cost of building it now that producing an MVP is so easy.

It actually extends to all automation, even before computers. Replacing oxen with tractors? Now you have to keep the tractors running.

If I were working in marketing and I wanted to increase utilization of the nuclear power plant next door, I would wipe 50 years of computer science and introduce "agent programming" and pretend it's the future. What are the odds people would buy it? Hit send.

There's a lot that could be said against agentic programming, but I don't understand how it wipes away anyway about CS - everything about this is a massive tower built on top of (and effectively utilizing) everything that we've learned about CS fundamentals and engineering over these decades.

>but I don't understand how it wipes away anyway about CS

Because transformers is a mathematician's take on programming. Not your CS graduate.

I'm not sure what you mean. I can't find a single prominent contributor to transformers who doesn't have a CS background. The closest I found is Jared Kaplan (math and theoretical physics), who came and contributed with mathematical analysis after the architecture was already well-defined.

Reply on news.ycombinator.com