Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on slowing the fuck down

mariozechner.at

Post reply on HN
Print view View original

221–230 of 505 posts

Re: Thoughts on slowing the fuck down

#221

Post by bdangubic »

pixl97 wrote: post #174
bdangubic wrote: post #164

Earlier quoted context omitted.

> 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.

I wholeheartedly agree. I just don't agree with:

> We live in a world where every line of code written by a human should be reviewed by another human. We can't even do that! Nothing should go straight to prod ever, ever ever, ever

Things should 100% go to prod whenever they need to go to prod. While this in theory makes sense, there is insane amount of ceremony in large number of places I have seen personally where it takes an act of congress to deploy to production all the while it is just ceremony, people are hunting other people with links to PR sent to various slack channels "hey anyone available to take a look at this" and then someone is like "I know nothing about that service/system but I'll look at approve." I would wager a high wager that this "we must review every line of code" - where actually implemented - is largely a ceremony. Today I deployed three services to production without anyone looking at what I did. Deploying to production should absolutely be a non-event in places that are ran well and where right people are doing their jobs.

Re: Thoughts on slowing the fuck down

#222

Post by aerhardt »

I'm capturing videos of all the bugs I am seeing as of late. The folder is filling fast. I'll write a compilation post but I'm thinking a techno remix video could be fitting too.

If there are any common apps which are unhinged please do share your experiences. LinkedIn was never great quality but it's off the charts. Also catching some on Spotify.

Re: Thoughts on slowing the fuck down

#223

Post by lejalv »

ryandrake wrote: post #160
perrygeo wrote: post #145

Earlier quoted context omitted.

> What are you building? This x1000. The last 10 years in the software industry in particular seems full of meta-work. New frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. Ultimately so we can build... what exactly? Are these necessary to build what we actually need? Or are they necessary to prop up an unsustainable industry by inventing new jobs? Hard to sha…

> The last 10 years in the software industry in particular seems full of meta-work. Building new frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. All to build... what exactly? Don't forget App Stores. Everyone's still trying to build app stores, even if they have nothing to sell in them. It's almost as if every major company's actual product is their stock pr…

> It's almost as if every major company's actual product is their stock price.

It's almost as if we lived under capitalism.

What other thing would they do? They are literally setting the Earth on fire to raise the stock price. No hostages taken.

The true alignment problem behind the ploy AGI alignment problem for prêt-à-penser SF philosophers. Or prestidigitators.

Re: Thoughts on slowing the fuck down

#224

Post by mememememememo »

markus_zhang wrote: post #13

If there is anyone who absolutely should slow down, it's the folks who are actively integrating company data with an agent -- you are literally helping removing as many jobs as possible, from your colleagues, and from yourselves, not in the long term, but in the short term. Integration is the key to the agents. Individual usages don't help AI much because it is confined within the domain of that individual.

We reduce jobs every time we e.g. fix a bug. Where do you stop?

Re: Thoughts on slowing the fuck down

#225

Post by jimbokun »

apsurd wrote: post #217
jimbokun wrote: post #204

Earlier quoted context omitted.

When it comes time to debug would you rather ask questions about and dig through code in a popular open source library, or dig through code generated by an LLM specifically for your project?

If the LLM doing it, it doesn't matter, isn't that the point? Not saying I personally believe in this scenario, but everything I've heard supports the idea that code is no longer for humans to consume.

You are going to allow a product from a company you have no reason to trust write important software for you and put it into production without checking the code to see what it does?

Re: Thoughts on slowing the fuck down

#226

Post by 6510 »

I keep returning to this thought: Assuming our abstraction architecture is missing something fundamental, what is it?

My gut says something simple is missing that makes all of the difference.

One thought I had was that our problem lives between all the things taking something in and spitting something out. Perhaps 90% of the work writing a "function" should be to formally register it as taking in data type foo 1.54.32 and bar 4.5.2 then returning baz 42.0 The register will then tell you all the things you can make from baz 42.0 and the other data you have. A comment(?) above the function has a checksum that prevents anyone from changing it.

But perhaps the solution is something entirely different. Maybe we just need a good set of opcodes and have abstractions represent small groups of instructions that can be combined into larger groups until you have decent higher languages. With the only difference being that one can read what the abstraction actually does. The compiler can figure lots of things out but it wont do architecture.

Re: Thoughts on slowing the fuck down

#227

Post by methodical »

Aurornis wrote: post #215
Towaway69 wrote: post #124

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.…

> the prices will start rising. After all, these loss making AI companies will eventually need to recoup on their investments. I would bet a lot of money that the price of LLM assistance will go down, not up, as the hardware and software advance. Every genre-defining startup seems to go through this same cycle where the naysayers tell us that it's all going to collapse once the investment money runs out. This was def…

While I fundamentally agree with the basis of compute getting cheaper by the year, I think a missed consideration here is the fact that these models are also requiring exponentially more compute with each iteration to train, in a way that arguably has outscaled the advances in compute.

Whether a generalized and broadly usable model will be able to trained within some N multiple of our current compute availability allowing the price to come down with iterative compute advances is yet to be seen. With the current race to the top in terms of SOTA models and increasingly iteratively smaller improvements on previous generations, I have a feeling the scaling need for compute will outpace the improvements in our hardware architecture, and that's if Moore's law even holds as we start to reach the bounds of physics and not engineering.

However as it stands today, essentially none of these providers are profitable so it's really a question of whether that disconnect will come within their current runway or not and they'll be required to increase their price point to stay alive and/or raise more capital. It's pure conjecture either way.

Re: Thoughts on slowing the fuck down

#228

Post by Fr0styMatt88 »

Aurornis wrote: post #191
perrygeo wrote: post #145

Earlier quoted context omitted.

> What are you building? This x1000. The last 10 years in the software industry in particular seems full of meta-work. New frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. Ultimately so we can build... what exactly? Are these necessary to build what we actually need? Or are they necessary to prop up an unsustainable industry by inventing new jobs? Hard to sha…

> The last 10 years in the software industry in particular seems full of meta-work. New frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. Ultimately so we can build... what exactly? Are these necessary to build what we actually need? Or are they necessary to prop up an unsustainable industry by inventing new jobs? The overwhelming majority of real jobs are not…

There’s a whole world out there that doesn’t seem to be addressed by the original comment. On one end of that scale you have things like bespoke software for small businesses, some niche inventory management solution that just sits quietly in the corner for years. On the other end, there’s the whole world of embedded software, game dev, design software, bespoke art pipeline tools…

It can seem that the majority of software in the world is about generating clicks and optimising engagement, but that’s just the very loud minority.

Re: Thoughts on slowing the fuck down

#229

Post by Munksgaard »

andai wrote: post #182

It occurred to me on my walk today that a program is not the only output of programming. The other, arguably far more important output, is the programmer. The mental model that you, the programmer, build by writing the program. And -- here's the million dollar question -- can we get away with removing our hands from the equation? You may know that knowledge lives deeper than "thought-level" -- much of it lives in mus…

Peter Naur had that realization back in 1985: https://pages.cs.wisc.edu/~remzi/Naur.pdf

Re: Thoughts on slowing the fuck down

#230

Post by apsurd »

jimbokun wrote: post #225
apsurd wrote: post #217

Earlier quoted context omitted.

If the LLM doing it, it doesn't matter, isn't that the point? Not saying I personally believe in this scenario, but everything I've heard supports the idea that code is no longer for humans to consume.

You are going to allow a product from a company you have no reason to trust write important software for you and put it into production without checking the code to see what it does?

I agree with you, which makes me seem like the laggard at work. Devil's advocate is that AI-native development will use AI to ask these questions and such. So whether it's a framework or standard lib, def agree knowing your stuff is what matters, but the tools to demonstrate this knowledge is fast in flux.

Again, I am on the slow train. But this seems to be all I hear. "code optimized for humans" is marked for death.

Post reply on HN