I love the use of the term clanker. There is just no one there that can be offended by this.
Thoughts on slowing the fuck down
421–430 of 505 posts
Re: Thoughts on slowing the fuck down
#422Re: Thoughts on slowing the fuck down
#423articles like these make me think that coding with AI is a little bit like writing Perl code: if you know what you’re doing, you can do brilliant things very quickly, but if you don’t, you can make spaghetti very quickly.
That's a great analogy and is something I experience every second day. Once a week I do a full second pass of a manual review on the generate AI code. Very often I find myself in a situation were I do not really understand the recently AI generated code anymore or find it hard to read, so I either rewrite it manually or tell the LLM to make it more readable. And this is just one part. If you really would like to get a long-term maintainable software product, AI code suddenly isn't that much of a speed boost anymore. Maybe a little bit, but the initial wow effect is very ephemeral.
Re: Thoughts on slowing the fuck down
#424What 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.…
Oil market doesn't have an equivalent of open-source LLMs, self-hosting and cloud providers.
Re: Thoughts on slowing the fuck down
#425What 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.…
There is no such thing as agentic codebase. If humans don’t understand it, nothing really does. Agents give zero fuck about anything. If they burn 100 or million tokens to add a feature, they don’t care. It’s the developers responsibility to keep it under control.
100% this. With these new tools it's tempting to one-shot massive changesets crossing multiple concerns in preexisting, stable codebases.
The key is to keep any changes to code small enough to fit in your own "context window." Exceed that at your own risk. Constantly exceeding your capacity for understanding the changes being made leads to either burnout or indifference to the fires you're inevitably starting.
Be proactive with these tools w.r.t. risk mitigation, not reactive. Don't yolo out unverified shit at scales beyond basic human comprehension limits. Sure, you can now randomly generate entirely (unverified) new software into being, but 95% of the time that's a really, really bad idea. It is just gambling and likely some part of our lizard brains finds it enticing, but in order to prevent the slopification of everything, we need to apply some basic fucking discipline.
As you point out, it's our responsibility as human engineers to manage the risk reward tradeoffs with the output of these new tools. Anecdotally, I can tell you, we're doing a fucking bad job of it rn.
Re: Thoughts on slowing the fuck down
#426[flagged]
Re: Thoughts on slowing the fuck down
#427The cognitive surrender study from UPenn highlights the risks of agents producing all of the code - eventually you give up verifying the result. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6097646
There’s going to be a bottleneck on what is verified because over time we will realize how much tail risk we are creating by simply surrendering our own agency to the agents - https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6298838
Re: Thoughts on slowing the fuck down
#428Earlier 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...
Version control is useful but it has nothing to do with software engineering per se. Most software development is craft work which doesn't meet the definition of engineering (and that's usually fine). Conversely, it's possible to do real software engineering without having a modern version control system.
What is your definition of engineering, that "craft work" doesn't meet?
Re: Thoughts on slowing the fuck down
#429What 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.…
There is no such thing as agentic codebase. If humans don’t understand it, nothing really does. Agents give zero fuck about anything. If they burn 100 or million tokens to add a feature, they don’t care. It’s the developers responsibility to keep it under control.
The big AI projects I've seen at work are...
- A Kafka topic visualization dashboard
and
- A chrome extension the original "developer" can no longer work on cause the bots will wreck something else on every new feature he tries to add or bug he tries to fix
I think we're a ways out from truly complex code bases that only agents understand.
I've seen a bunch of hype video where people spend lord knows how much money in order to have a bunch of these things run around and I guess... use Facebook, and make reports to distribute amongst themselves, and then the human comes in and spends all their time tweaking this system. And then apparently one day it's going to produce _something_ but two years and counting and much like bitcoin, I've yet to see much of this _something_ materialize in the form of actual, working, quality software that I want to use.
My buddy made a thing that tells him how many people are at the gym by scraping their API and pushing it into a small app package... I guess that's kind of nice.
Re: Thoughts on slowing the fuck down
#430I 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…
> 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…
What you are describing sounds like a specific subset of professional engineering discipline, but I'd argue that "engineering" is much larger -- it isn't only "engineering" when you do it well and responsibly, after all.
I'd propose a definition of engineering that's more or less just "composing tools together to solve problems".