Live data from Hacker News

Thoughts on slowing the fuck down

mariozechner.at

171–180 of 505 posts

Re: Thoughts on slowing the fuck down

#171

Earlier quoted context omitted.

That's a great shout because I'm sure a lot of people would otherwise just discredit this take as just another anti-ai skeptic. But he probably has more experience working with LLM's and agents than most of us on this site, so his opinion holds more weight than most.

If you were going to dismiss an argument because of who it comes from rather than its content, that is a flaw in your thinking. The argument is correct, or it isn't, no matter who said it.

That doesn't work for me. Knowing who is making the argument is important for understanding how credible the parts of their argument that derive from their personal experience are.

If someone anonymous says "Using coding agents carelessly produces junk results over time" that's a whole lot less interesting to me than someone with a proven track record of designing and implementing coding agents that other people extensively use.

Re: Thoughts on slowing the fuck down

#173
post #59

Earlier quoted context omitted.

> I'm not even sure building software is an engineering discipline at this point. Maybe it never was. It isn't. Show me the licensing requirements to be a "software engineer." There are none. A 12 year old can call himself a software engineer and there are probably some who have managed to get remote work on major projects.

In Europe they are. Call yourself an Engineer without a degree and your company and you will be sued with a big fine, because here you must be legally accountable on disasters and ofc there are hard constraints .

No, that's plain wrong (I am from Czech Republic). You can even get an "engineering degree" (Ing.) by studying economics.

Re: Thoughts on slowing the fuck down

#174
post #157

Earlier quoted context omitted.

There's a lot of software in between Air Traffic Controller and Facebook. And honestly would Meta be okay with Instagram or Facebook going down even for just a few minutes? I'd think at this point that'd be considered a fairly severe incident. Even if we ignore criticality, things just get really messy and confusing if you push a bunch of broken stuff and only try to start understanding what's actually going on after…

> And honestly would Meta be okay with Instagram or Facebook going down even for just a few minutes? sure, they coined the term “move fast and break things” and not every “bug” brings the system down, there is bugs after bugs after bugs in both facebook and insta being pushed to production daily, it is fine… it is (almost) always fine. if you are at a place where “deploying to production” is a “thing” you better be a…

> there is bugs after bugs after bugs

These are the bugs after bugs after bugs after bugs after bugs.

Simply put they are going through dev, QA, and UAT first before they are the bugs that we see. When you're running an organization using software of any size writing bugs that takes the software down is extremely easy, data corruption even easier.

Re: Thoughts on slowing the fuck down

#175

Earlier quoted context omitted.

People don't realize how much software engineering has improved. I remember when most teams didn't use version control, and if we did have it, it was crappy. Go through the Joel Test [1] and think about what it was like at companies where the answers to most of those questions was "no." [1] https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

At the same time, systems have become far more complex. Back when version control was crap, there weren't a thousand APIs to integrate and a million software package dependencies to manage. Sure everything seems to have gotten better and that's why we now need AIs to understand our code bases - that we created with our great version control tooling. Fundamentally we're still monkeys at keyboards just that now there a…

> that's why we now need AIs to understand our code bases

I don't need an AI to understand my code base, and neither do you. You're smarter then you give yourself credit for.

Re: Thoughts on slowing the fuck down

#176

What the article doesn't touch on is the vendor lock-in that is currently underway. Many corps are now moving to an AI-based development process that is reliant on the big AI providers. Once the codebase has become fully agentic, i.e., only agents fundamentally understand it and can modify it, the prices will start rising. After all, these loss making AI companies will eventually need to recoup on their investments.…

This is a great point, and I routinely use it as an argument for why seasoned professionals should work hard to keep their skills and why new professionals should build them in the first place. I would never be comfortable leasing my ability to perform detailed knowledge work from one of these companies.

Sometimes the argument lands, very often it doesn't. As you said, a common refrain is, "but prices won't go up, cost to serve is the highest it will ever be." Or, "inference is already massively profitable and will become more so in the future--I read so on a news site."

And that remark, for me, is unfortunately a discussion-ender. I just haven't ever had a productive conversation with somebody about this after they make these remarks. Somebody saying these things has placed their bets already and are about to throw the dice.

Re: Thoughts on slowing the fuck down

#178
post #104

Earlier quoted context omitted.

> A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature…

One would as sensibly dismiss the concept of an assembly line as "how to build a car if you cannot." Dijkstra was a mathematician. It is a necessary discipline. If it alone were sufficient, then the "program correctness" fans would have simply and inarguably outdone everyone else forty years ago at the peak of their efforts, instead of having resorted to eloquently whiny, but still whiny, thinkpieces (such as the 198…

I think the real tragedy here is that we can spend *all* of our time trying to improve the quality of our output, but it simply doesn't matter, because as long as the button is where the boss wants it to be and is the right color, all is right with the world.

Literally nothing else matters, and we (or at least I) have wasted a ton of time getting good at writing software.

Re: Thoughts on slowing the fuck down

#179

I suppose everyone on HN reaches a certain point with these kind of thought pieces and I just reached mine. What are you building? Does the tool help or hurt? People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era. After five or six cycles it does become a bit fatiguing. Use the tool sanely. Work at a pace where your understand…

Engineering is two things: 1. Applied physics - Software is immediately disqualified. Symbols have no physics. 2. Ethics - Lives and livelihoods depend on you getting it right. Software people want to be disqualified because that stuff is so boring, but this is becoming a more serious issue with every passing day.

That might vary by countries but in France with have an official "engineering degree" (diplome d'ingénieur) which is also a master's degree, and most software developers have this.

So most software developers in France are absolutely software engineers.

Re: Thoughts on slowing the fuck down

#180
post #60

Nature will handle this in time. Just expect to see a "Bear Stearns moment" in the software world if this spirals completely out of control (and companies don't take a hint from recent outages).

I’m worried we end up with an AIG moment, and we all end up on the hook.

That's a valid fear imo.
Post reply on HN