#technical-debt — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #technical-debt, aggregated by home.social.
-
"Brace for Patch Tsunami" -- AI used in the hands of "skilled and knowledgable" people is supposedly going to surface a vast pool or latent bugs (technical debt .. be very afraid). Reports here and elsewhere ndicate that like most AI claims, it's mostly slop. Apparently AI is not being used by "skilled and knowledgable individuals" willing to actually verify that AI found anything real or is just wrong.
#technicaldebt #bugs #defects #ai
https://www.theregister.com/2026/05/02/ncsc_brace_for_patch_tsunami/ -
Anthropic identified three product bugs behind weeks of Claude Code quality complaints: a reasoning-effort downgrade, a caching bug that cleared context every turn, and a verbosity prompt that cut eval scores 3%. Shows how product-layer changes can mask as model regressions. All fixes shipped April 20, limits reset for subscribers. #AI #ProductEngineering #TechnicalDebt
-
What's the best way to approach technical debt?
Read more here:
https://bgh.st/4spa4k -
Martin Fowler: Technical, Cognitive, and Intent Debt
https://martinfowler.com/fragments/2026-04-14.html
#HackerNews #MartinFowler #TechnicalDebt #CognitiveDebt #IntentDebt #SoftwareEngineering
-
Graph Construction Complete: 21 nodes, 12 edges.
Primary Drivers: ['CVE-2025-40739', 'CVE-2025-40740', 'CVE-2025-3508'] -
#TIL about this good #IBM video explaining clearly and didactically what #AI technical debt means, its causes and impact:
-
What do we call the specific kind of technical debt caused by LLM-slop? Slop debt or is there another term?
-
In der SW-Entwicklung sprechen wir oft von "technischen Schulden".
Sollten wir diese nicht eher als "technische Schäden" bezeichnen?
"Schäden" passieren, wenn wir eine Fähigkeit nicht beherrschen, oder wenn wir unaufmerksam sind, oder wenn uns etwas egal ist. Die Folgen sind zumeist überraschend, unvorhersehbar, und nicht kalkulierbar.
"Schulden" sind zumeist das Ergebnis einer bewußten Entscheidung nach trefflicher Überlegung, mit einem Plan zur Rückzahlung.
------
In software development, we often talk about ‘technical debt’.
Shouldn’t we rather call this ‘technical damage’?
‘Damage’ occurs when we lack the necessary skills, or when we are inattentive, or when we simply don’t care. The consequences are usually unexpected, unpredictable, and impossible to quantify.
‘Debt’ is usually the result of a conscious decision made after careful consideration, with a plan for repayment.
-
AI Is Creating a New Kind of Tech Debt—and Nobody Is Talking About It, by @harsh70117.bsky.social:
https://dev.to/harsh2644/ai-is-creating-a-new-kind-of-tech-debt-and-nobody-is-talking-about-it-3pm6
-
I was curious how effective Claude Code would be at tackling technical debt, so I asked it to find technical debt in a project. Not only did it do a thorough job of documenting it, it also suggested the fixes. #ClaudeCode #AICoding #technicalDebt
-
#databases #sqlserver #technicalDebt #entityFramework
So... At work, our product has many data grids, and uses Entity Framework, most of the grids are paged.
Paging is done viaawait orderedQuery. Skip((page-1)*pageSize). Take(pageSize).TolistAsync()
Page 2 loads had always been slow. EF "optimises" the generated query to use one parameter for the second page because page 2 is... .Skip((1-1)*pageSize).Take(pageSize) ...
Both resolve to the same value. EF says "same value, same parameter!" Find whatever.
Except... SQL server builds and uses a different (and more costly) plan for the resultingOFFSET \@p ROWS LIMIT \@pthat is consistently worse than it they had didn't values that producesOFFSET \@p1 ROWS LIMIT \@p2Apparently it's been a known problem for a long time.
Until someone as dumb as me asks... Why not Skip as much as normal and Take one extra then don't use it the extra.
(await orderedQuery. Skip((page-1)*pageSize). Take(pageSize+1).TolistAsync()).Take(pageSize)/1
-
"The complexity of software is an essential property, not an accidental one."
-
I deleted 500 lines of working code today. Well-structured, well-tested, doing exactly what it was designed to do. Replaced it with 60 lines. The system got better.
When you're technically capable, you default to building. That's the dangerous part, not asking whether it should exist.
https://www.paulwelty.com/the-smartest-code-youll-ever-delete/
-
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/
