Fine to read a fellow countryman on HN :) "Dere!"
I have disabled my coding agent by default. I first try to think, plan, code something myself and only when I get stuck or the code gets repetitive, only then I tell him to do the stuff.
But I get what you are saying, and I agree ... I am clearly pro human on this debate, and the low bloat trash everywhere is annoying. I have come to the conclusion - if you find docs on something, and it is plain HTML - it will be probably of high quality. If you find docs with a flashy, dynamic, effectful and unnecessary 100mb js booboo, then you what you are about to read ...
Thoughts on slowing the fuck down
201–210 of 505 posts
Re: Thoughts on slowing the fuck down
#202I 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…
> 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…
In my lifetime software has given us:
* the ability to find essentially any information ever created by anyone anywhere at anytime,
* the ability to communicate with anyone on Earth over any distance instantaneously in audio, video, or text,
* the ability to order any product made anywhere and have it delivered to our door in a day or two,
* the ability to work with anyone across the world on shared tasks and projects, with no need for centralized offices for most knowledge work.
That was a massive undertaking with many permutations requiring lots of software written by lots of people.
But it's largely done now. Software consumes a significant fraction of all waking hours of almost everyone on Earth. New software mainly just competes with existing software to replace attention. There's not much room left to expand the market.
So it's difficult to see the value of LLMs that can generate even more software even faster. What value is left to provide for users?
LLMs themselves have the potential to offering staggering economic value, but only at huge social cost: replacing human labor on scales never seen before.
All of that to say, maybe this is the reason so much time is being spent on meta-work today than on actual software engineering.
Re: Thoughts on slowing the fuck down
#203Earlier 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.
> The argument is correct, or it isn't, no matter who said it.
Yes, but we all have insufficient intelligence and knowledge to fully evaluate all arguments in a reasonable timeframe.
Argument from authority is, indeed, a logical fallacy.
But that is not what is happening here. There is a huge difference between someone saying "Trust me, I'm an expert" and a third party saying "Oh, by the way, that guy has a metric shitton of relevant experience."
The former is used in lieu of a valid argument. The latter is used as a sanity check on all the things that you don't have time to verify yourself.
Re: Thoughts on slowing the fuck down
#204Earlier 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…
This is a good point. I've seen people with really complex AI setups (multiple agents collaborating for hours). But what are they building? Are they building a react app with an express backend? A next js app? Which itself is a layer on top of an abstraction? I haven't tried this myself but I'm curious if an LLM could build a scalable, maintainable app that doesn't use a framework or external libraries. Could be dang…
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?
Re: Thoughts on slowing the fuck down
#205Earlier 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.
Someone making an argument needs relevant experience/context to substantiate their argument. Just because the end opinion is "correct", doesn't mean they arrived there in a reasonable way.
Re: Thoughts on slowing the fuck down
#206Earlier 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.
They are pretty much legally obligated to act in this manner.
Re: Thoughts on slowing the fuck down
#207Earlier quoted context omitted.
> I'm not even sure building software is an engineering discipline at this point. Maybe it never was. If I engineer a bridge I know the load the bridge is designed to carry. Then I add a factor of safety. When I build a website can anyone on the product side actually predict traffic? When building a bridge I can consult a book of materials and understand how much a material deforms under load, what is breaking point…
Software and bridges are entirely different. If I need a bridge, and there's a perfectly beautiful bridge one town over that spans the same distance - that's useless to me. Because I need my own bridge. Bridges are partly a design problem but mainly a build problem. In software, if I find a library that does exactly what I need, then my task is done. I just use that library. Software is purely a design problem. With…
> Bridges are partly a design problem but mainly a build problem.
I think this vastly underestimates how much of the build problem is actually a design problem.
If you want to build a bridge, the fact one already exists nearby covering a similar span is almost meaningless. Engineering is about designing things while using the minimal amount of raw resources possible (because cost of design is lower than the cost of materials). Which means that bridge in the other town is designed only within its local context. What are the properties of the ground it's built on? What local building materials exist? Where local can be as small as only a few miles, because moving vast quantities of material of long distances is really expensive. What specific traffic patterns and loadings it is built for? What time and access constraints existed when it was built?
If you just copied the design of a bridge from a different town, even one only a few miles up the road, you would more than likely end up with a design that either won't stand up in your local context, or simply can't be built. Maybe the other town had plenty of space next to the location of the bridge, making it trivial to bring in heavy equipment and use cranes to move huge pre-fabbed blocks of concrete, but your town doesn't. Or maybe the local ground conditions aren't as stable, and the other towns design has the wrong type of foundation resulting in your new bridge collapsing after a few years.
Engineering in other disciplines don't have the luxury of building for a very uniform, tightly controlled target environment where it's safe to make assumptions that common building blocks will "just work" without issue. As a result engineering is entirely a design problem, i.e. how do you design something that can actually be built? The building part is easy, there's a reason construction contractors get paid comparatively little compared to the engineers and architects that design what they're building.
Re: Thoughts on slowing the fuck down
#208> it sure feels like software has become a brittle mess, with 98% uptime becoming the norm instead of the exception, including for big services As somebody who has been running systems like these for two decades: the software has not changed. What's changed is that before, nobody trusted anything, so a human had to manually do everything. That slowed down the process, which made flaws happen less frequently. But it w…
> One way to deal with this in DevOps/Lean/TPS is the Andon cord.
Many years ago, I started working for chip companies. It was like a breath of fresh air. Successful chip companies know the costs (both direct money and opportuity) of a failed tapeout, so the metaphorical equivalent of this cord was there.
Find a bug the morning of tapeout? It will be carefully considered and triaged, and maybe delay tapeout. And, as you point out, the cultural aspect is incredibly important, which means that the messenger won't be shot.
Re: Thoughts on slowing the fuck down
#209Earlier 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…
The better processes and tools made larger project possible.
Re: Thoughts on slowing the fuck down
#210Earlier quoted context omitted.
> Name a single time doomers were right about anything. - NFTs - Surveillance schizos - Global Pedophile Cabal schizos - Anyone who didn’t believe we were a year out from Star Trek living when LLMs first started picking up steam - People who predicted the flood of people entering Software via bootcamps, etc. would never cause any problems because their god of software is consuming the world too quickly for supply and…
> People who predicted the flood of people entering Software via bootcamps, etc. would never cause any problems because their god of software is consuming the world too quickly for supply and demand to ever be a real concern. How was this group vindicated? It absolutely has caused problems at orgs and in the industry. Just look at all the linkedin/twitter/youtube garbage of influencers trying to post boot camp tier a…
> How was this group vindicated? It absolutely has caused problems at orgs and in the industry.
I think you misread. In fairness, I arranged the sentence awkwardly, as I do often. I think my mind was conjuring the various dooms and then trying to rephrase the doom into the doomer.
What I mean is the people who warned against it were vindicated.
Of course vindicated may not the best word to use. If I say the world blows up tomorrow and you say it can never, and then it blown up, perhaps I’m not necessarily vindicated. But I certainly get a brief moment of schadenfreude