So I'm clear: as long as our jobs don't devolve to 100 hours a week in a sweat shop or tilling the earth for the lord of our fiefdom, we should just sit back and be happy?
Is that what I should take away from your comment?
Sure but context matters and given this is Hacker News, a lot of discussion centers around tech as a profession (and that's doubly true for AI adoption). You can forgive folks for jumping to natural conclusions. :D
It's coming from a place of objecting to burnout/overwork culture.
Recently I witnessed a CTO mention in a public channel that with Claude remote control people can now work while getting a coffee or other breaks during the day.
Tech is actively moving in a direction of destroying all the gains from the labour movement in service of enriching capital out of a combination of FOMO or fear of being replaced.
So yeah, when folks say "hey look now I can even work during leisure activities!" yeah, the reaction is negative.
> Like...you're a programmer? And you don't like to read? I assumed that people who enjoy software would be into intellectual stimulation but I've learned that this is wrong.
The rise of vibecoding and the disdain many in the industry hold for the skill of software development should fully disabuse you of any vestiges of this notion...
Every single day, here, on "Hacker" news I see folks describe coding as just a means to an end, and that things like code quality, architecture, etc, don't matter.
Welcome to late stage capitalism, where if you can't immediately monetize it its not worth doing (consider how this might explain the rise of gambling as recreation).
But that's not the problem being highlighted in that quote you clipped out and responded to.
The problem that quote (and this entire post and the folks that produced it) is putting a finger on is that vibecoding makes it very easy to build large piles of brittle, entangled code where all those early velocity gains are paid back as evolving the codebase takes more and more time (and, crucially, tokens).
No amount of <insert methodology here> replaces good judgement about architecture/design that ultimately leads to more maintainable, extensible code. That was true before AI and it remains true today.
Now eventually AI may get to the point where it's autonomously generating code that's structurally as good or better than what any experienced human would create.
So far, IME, that is not yet this case and nothing can yet substitute for an experienced human in the loop to steer AI toward better decision-making.
And before it's said, yes, that also means humans made ugly balls of mud in the before time. That term obviously came from somewhere.
But that only proves that AI is as good as prior humans that did a bad job, which on the one hand is impressive, and on the other hand is deeply alarming when you know there's folks out there letting these things loose without any supervision.
Of course if all one is doing is tossing off and walking away from greenfield projects, man, vibecoding is magical. I suspect a lot of the "we never look at code anymore" claims come from this world.
Eh it's nothing new. Outsourcing comes from the same spirit.
Perversely I find myself increasingly blaming the growth of product management divorced from engineering as the source of some of this.
Everyone wants to be the next Jobs, but somehow they missed that it was the marriage of high quality design and high quality engineering that got Apple where they are today.
Rather, the lesson they learned is that PMF and UX and yadda yadda yadda are all that matter and coding is just a means to an end.
It'll be interesting to see how many companies discover that you can't achieve those ends if you build on a broken foundation.
> Our conclusion was that we should not be concerned what search or queuing algorithm or data structure is being used.
Not to be too snide, but if that's your reductionist view of the work of software development, I'm not surprised you're comfortable vibecoding without a human in the loop.
> A SmartBear study of a Cisco Systems programming team revealed that developers should review no more than 200 to 400 lines of code (LOC) at a time. The brain can only effectively process so much information at a time; beyond 400 LOC, the ability to find defects diminishes.
...
> SmartBear research shows a significant drop in defect density at rates faster than 500 LOC per hour. Code reviews in reasonable quantity, at a slower pace for a limited amount of time results in the most effective code review.
> I am trying to give some rational perspective of the balance of power between them and us
That should *not be a thing*.
You bought the device.
You own it.
It should be yours to do with as you see fit.
That applies to phones or appliances or cars unless your individual right to modify your devices begins to interfere with the rights of others (think: safety, tragedy of the commons scenarios, etc).
This is how we end up with cars we can't repair, phones we can't upcycle, TVs that advertise to us without our consent.
I actually ended an extended career break around this time last year and landed two different jobs since then (first didn't work out, second is going okay minus the AI psychosis) purely through networking.
I'm not saying it's easy out there. But simply being talented is a small part of finding a job, especially given the post-COVID shifts in the labour market.
All that being said, I think anyone quitting should only do so with either another job lined up or at least a 12 month runway.
> 1) side loading or however it's called is used less than 1-2% of global Android users (they can't be more than 50million). Google made us a favor leaving it open after an only 24h delay. It could be much worsa and is nothing in our eternal tinkering with developer options. Thank you from me Google
It's wild how far we've come, from IBM trying to lock down the PC to truly open hardware, to you now thanking Google for only mostly restricting what you can do with a device that you bought and own...
The rest of your content is just other forms of Google apologia.
This is honestly deeply disheartening... And on "hacker" news of all places...
Unfortunately I think we're entering (have entered?) a period of insanity.
The trouble is AI is being sold as an individual engineering accelerant. I suspect at the most AI pilled orgs you'll then see a commensurate push that starts off with measuring usage (tokens), then measuring output (PRs, code reviews), and then a lot of talk about impact while everyone quietly admits that remains as impossible now as it was fifty years ago.
Why? Because leadership is looking to (and selling, both internally and to the market) AI as the solution to all of their problems, which means they have to prove outcomes that justify their sky high AI budgets.
Higher level metrics at the org/division/product/project level aren't satisfying and flashy enough as they're slow moving and attenuated.
And squishy individual or team level assessments that rely on strong management won't show well on a cost-benefit comparison chart to the board.
At bottom I suspect AI pilled leadership wants to turn software into an assembly line and measure accordingly. Your post perfectly captures why it's still not that easy, and that the real problems in software remains the same and are unsolved by AI: building the right thing, at the right time, and then later figuring out what went well, what didn't, and trying to make those successes more repeatable and failures less likely.
Companies generally fail because either their product doesn't meet a market need, or the market doesn't exist in the first place (possible because of bad timing), and not because they simply outran their competitors.
These aren't things fixed by using a frontier model to vibe code faster in lieu of one 5 months behind.
So I assume the bar is set at being the subject of early European colonialism.