real-life effects of LLMs in tech workplaces
real-life effects of LLMs in tech workplaces
The Real Problem With Technical Debt (and How to Actually Fix It), by @kevlin:
A term to remember:
Cognitive debt, a condition in which repeated reliance on external systems like LLMs replaces the effortful cognitive processes required for independent thinking.
We shouldn't worry only of the technical debt, but also cognitive debt when over-relying on the LLMs.
#technicaldebt
#cognitivedebt
The only solution to tech debt is to go fix all of it right away.
Read more here:
https://www.devleader.ca/2023/10/20/how-to-balance-technical-debt-tackle-it-before-it-tackles-you/
33 years after Ward Cunningham coined “#TechnicalDebt,” the metaphor is collapsing. Pablo Bouzada asks: What if the real risk isn’t debt, but fragility? This piece reshapes the way you talk about code, cost, & credibility.
Take the red pill: https://javapro.io/2025/06/18/should-we-stop-discussing-about-technical-debt-with-top-management/
Aaron Grothe, CISSP presents 'What About C/C++' July 24th at Nebraska.Code().
Is “#TechnicalDebt” still useful—or just a fancy way to say “not our fault”? Pablo Bouzada takes the metaphor apart, story by story, & shows how it fails where it should connect: with the people who sign the checks.
Read before your next roadmap meeting: https://javapro.io/2025/06/18/should-we-stop-discussing-about-technical-debt-with-top-management/
Brandon Suponchick presents 'Technically....Is That Even Technical Debt?' July 25th at Nebraska.Code().
Does Your Team Produce ‘Bugs’?
Do your stakeholders think you produce 'Bugs'?
"A problem found in the production environment that prevents software from functioning as we encoded it."
I recommend #bugs are different than #defects, and #technicaldebt.
New video on my YouTube channel!
Technical Debt - The Project Killer
#technicaldebt #development
Trvalo mi to 2 dny, ale konečně jsem vyhodil vše, co souviselo s Flaskem. Nejsložitější bylo převést do nového systému stránky s inzeráty na konkrétní lokaci důležité kvůli SEO, třeba https://junior.guru/jobs/brno/
Pak jsem ještě zoptimalizoval MkDocs. Webovku trvalo složit skoro 10s. Pomocí ChatGPT jsem udělal profiling skript, pomocí ChatGPT jsem interpretoval výsledky, našel viníky, předělal to, a teď to trvá 4s. Sám bych to nedokázal, nebo by mi to trvalo týden.
Sexual references on JAVA
DORA metrics show increased deployment rollbacks in 2024. GitClear data shows more code duplication with AI. Coincidence? My article examines AI's role in technical debt and offers 5 questions to ensure your AI usage builds resilience, not fragility. https://agilepainrelief.com/blog/is-ai-making-your-organization-fragile-or-more-resilient/ #TechnicalDebt #AIImplementation
Assumption Debt: Die unsichtbare Falle im Systems Engineering
Assumption Debt bedeutet, dass Annahmen nicht sauber festgehalten und verfolgt werden. Das kann zu Problemen führen.
https://www.se-trends.de/assumption-debt/
#Anforderungen #Wissen #AssumptionDebt #Kontext #Reifegrad #Systemkontext #TechnicalDebt
Moving into the future is not without hurdles with 10 years of #TechnicalDebt. A couple of shiny new #AlmaLinux9 installations at a time is a much anticipated goal going from #CentOS7, but old apps, headaches and firefighting since last Wednesday's #ServiceWindow, whilst certainly keeping you on your toes have their towes on you as well, racing past deadlines and other obligations like wind in a tube #PainfullyExhausted
#React is the JAVA of modern times.
Join us online on Wednesday, May 14, for "Ratcheting to Zero: How Incremental Constraints Eliminate Technical Debt." In this practical session, David Mosher draws from 20+ years as a specialized generalist to address one of Agile’s most persistent blind spots: the implementation gap between acknowledging technical debt and effectively eliminating it.
Read more and RSVP now: https://www.agilealliance.org/event/ratcheting-to-zero-how-incremental-constraints-eliminate-technical-debt/
When I hear about AI-based programming, I think back several decades to a time when I was dealing with a hairy set of data, and I wrote a pretty complex bit of code generating an even more complex bit of SQL. I don't remember now if it ended up proving useful or not, though I think it did. But that's not the point.
The point was when I came back to it after a few months ... I couldn't figure it out at all. Neither the generator, nor the generated code.
And I HAD WRITTEN IT. Myself, from scratch, sorting out what I wanted and how to get there.
There's a principle in programming that debugging and maintenance are far harder than coding. Which means you should never write code that you are too stupid to debug and maintain. Which is precisely what I'd failed in my anecdote.
And of course, Management, in its infinite wisdom, typically puts far greater emphasis on new development than on testing, or Heavens Forefend!!! maintenance. So all the brightest talent (or so perceived, at any rate) goes to New Development.
(There's a great essay from about a decade ago, "In Praise of Maintenance, which you, and by "you" I mean "I", should really (re)read: http://freakonomics.com/podcast/in-praise-of-maintenance-rebroadcast/).
With AI-based code generation, presuming it works at all, we get code that's like computer-chess or computer-Go (the game, not the lang). It might work, but there's no explanation or clarity to it. Grandmasters are not only stumped but utterly dispirited because they can't grok the strategy.
I can't count the number of times I've heard AI referred to as search or solution without explanation, an idea I'd first twigged to in the late 2010s. That is, if scientific knowledge tells us about causes of things, AI ML GD LLM simply tells us the answer without being able to show its work. Or worse: even if it could show work, that wouldn't tell us anything meaningful.
(This ... may not be entirely accurate, I'm not working in the field. But the point's been iterated enough times from enough different people at least some of whom should know that I tend to believe it.)
A major cause of technical debt is loss of institutional knowledge over how code works and what parts do what. I've worked enough maintenance jobs that I've seen this in all size and manner of organisations. At another gig, I'd cut the amount of code roughly in half just so I could run it in the interactive environment which made debugging more viable. I never really fully understood what all of that program did (though I could fix bugs, make changes, and even anticipate some problems which later emerged). Funny thing was when one of the prior Hired Guns who'd worked on the same project before my time there turned up on my front door some years later ... big laughs from both of us...
But this AI-generated code? It's going to be hairballs on hairballs on hairballs. And at some point it's gonna break.
Which leaves us with two possible situations:
Though my bet's on the first case.