New post: Building with AI Without Drowning in Technical Debt. How to keep speed without locking in bad design—guardrails, a lightweight checklist, and team habits that scale with AI.
#AI #TechnicalDebt #SoftwareEngineering #Architecture #LLM #CodeQuality #DevEx
Honest note: my responses to PRs/issues were sluggish, especially during the pandemic. Sorry, and thanks for sticking with rsyslog.
What changes now:
- Quick maintainer look within 3 business days
- AI review runs instantly (90%+ useful)
- Full review after CI green + AI items addressed
- No mass-closing old issues; we revisit with AI assist
Full post:
https://rainer.gerhards.net/2025/08/sluggish-responses-and-how-we-plan-to-do-better.html
We don't need more. We need less.
Every week:
A new framework.
A new "layer".
A new AI wrapper.
A new YAML format to abstract what used to be a shell script.
And then we wonder:
"Why is our software hard to debug?"
"Why do our builds break randomly?"
"Why is onboarding a 6-month journey through tribal folklore?"
I once said I write bug-free software that can be finished.
People laughed, especially product people.
Not because it's wrong.
But because they’ve forgotten it's possible.
We build complexity on top of confusion:
A + B becomes C.
C + D becomes E.
Now, E is broken, and we would create a new layer, but nobody knows how A or B worked in the first place. For example HTML/JavaScript, we leave it there and just add layers around it.
Take XML.
Everyone says it's ugly.
But you could validate it automatically, generate diagrams, enforce structure.
Now we're parsing YAML with 7 linters and still can't tell if a space is a bug.
Take Gradle.
You can define catalogues, versioning, and settings, but can't update a dependency without reading 3 blogs and sacrificing a goat.
This is called "developer experience" now?
Take Spring Boot.
I wouldn't trust a Spring Boot or any java Framework powered airplane.
Too many CVEs. Too much magic. Too little control.
We don't need "smarter" tools.
We need dumber, boring, reliable defaults.
Start boring.
Start small.
Then only change the 1% that needs to be fast, clever, or shiny.
You'll rarely even reach that point.
Like everyone says, "Y is more performant and faster than X", but no one reached the limit of X. Why should I care? Meanwhile, we use performant AI.
Real engineering is not chasing hype.
It's understanding the system so deeply that you no longer need most of it.
We've replaced curiosity with cargo cults.
We've replaced learning with LLM prompting.
And somehow, we're surprised when AI loses to a 1980s Atari in a chess game.
At least the Atari understood its own memory.
Simplicity = less maintenance = fewer bugs = happier teams.
We need less. Not more.
#devex #simplicity #softwareengineering #nocodependency#stopthehype #bugfree #springboot #gradle #xml #yamlhell #boringisgood #minimalism #AIhype #infrastructure #cleancode #pragmatism #java #NanoNative
Interesting dive into the “AI makes folk less productive survey”
TLDR; As with any tool, you need to know how to use it, and what to use it on, to get the best benefit.
https://newsletter.pragmaticengineer.com/p/cursor-makes-developers-less-effective
Flying out soon to hit Tech In Gov Canberra.
If you happen to be there come to stand s3 for some insight into modern delivery practices and play with some demo stuff.
Alternatively I’ll be speaking at the pitch fest on day two.
Looking forward to seeing some friendly faces and talking GitOps, devex, and golden path automation.
Am I imagining a `git commit --fixup` helper tool that, given a staged change in a hunk of a file present in a previous commit, will automatically find that commit and `--fixup` that commit?
I'm fed up of noticing a problem, then `git log --oneline` and then copypasta a SHA and then `git rebase -i`, and then I notice another thing that's bad and the process starts over.
Platform Engineering success can't be coded. At #InfoQDevSummit Munich 2025 (Oct 15-16), Max Körbächer will share how a product mindset helps you build platforms developers choose to use, not are forced to adopt.
Is friction affecting your team's productivity?
At #QConSF 2025 (Nov 17-21), Nicole Forsgren @microsoft shares a proven blueprint for great DevEx, removing friction, and scaling productivity in an AI world.
https://bit.ly/3UIjhaU
#DevEx #Productivity #SoftwareEngineering #QConAI
Platform as a Product is rapidly becoming essential!
Last year's #InfoQDevSummit Munich explored its growing impact, showcasing how teams apply product principles to internal dev platforms for great results. Discover the next evolution!
Join us Oct 15-16, 2025.
Watch: https://bit.ly/44UJWHL #PlatformEngineering #DevEx #ProductMindset
I've added Baseline status to the CSS property documentation tooltips I previously implemented in DevTools.
Also, I've updated the vscode/web-custom-data package version that is used under the hood in DevTools.
So DevTools now displays info for all the new CSS properties that have come out in the last 3 years!
Available now in @Chrome Canary. 
TECHNICAL DEBT is like a ROTTING ROOF
On rainy days, it's too wet to fix it.
On sunny days, there's no leak… so you ignore it.
Then one day, boom, ceiling caves in, buckets everywhere, and you're duct taping production at 2am.
That's technical debt.
Not just messy code. Not just bad practices.
It's what you chose not to fix when you could have.
The missing tests.
The config you hardcoded "just for now".
The abstraction you skipped because "it works".
The one extra iteration after the ticket was marked as "done".
And now it's slowing you down.
It's holding your future hostage.
You're spending engineering cycles bailing water, not shipping value.
We love to say we're "building", but half the time we're just… leak managers.
You can't scale rot.
So next time the sun's out, fix the roof.
Because when the rain hits, it's too late.
Tired of jumping between interfaces? 
Used the editor inside the AWS console and left wanting more.
Now you can launch into Visual Studio Code directly from the AWS Console.
A poor #userexperience can make or break a product. Most companies are not Microsoft and likely wouldn’t have withstood a fiasco like Vista. An opposite example is Docker, the engine that popularized containers, lightweight packages of code and all its dependencies that can run on any operating system with Docker installed. (...)In short, attention to the user or developer experience (#DevEx) is no longer a nice to have. Instead, it’s a critical aspect of any product including internal platforms
The full paper [PDF] is here:
https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf
Developers *thought* they were 20% more productive using AI, but were actually measured to be 20% *slower*. 
Docker State of App Dev: Dev Ex & Productivity
#Company #Developers #Devex #Docker
https://www.docker.com/blog/docker-state-of-app-dev-dev-ex-productivity/
sttp client is an open-source HTTP client for Scala, supporting various approaches to writing Scala code. Recently, sttp client received a major release, and version 4 is now available! 
Discover the Scala HTTP client you always wanted: https://github.com/softwaremill/sttp
We are involved in many open source projects, as we want to support the community and improve ours and other developers' experience.
Shape the future of .NET tooling by spending just 10 minutes on JetBrains .NET development market research. Fill out the survey and enter the prize draw!
Start now https://surveys.jetbrains.com/s3/dotnet-development-survey-jbcc
Shape the future of .NET tooling by spending just 10 minutes on JetBrains .NET development market research. Fill out the survey and enter the prize draw! Start now surveys.jetbrains.com/s3/dotnet-de... #devlife #devex #dotnet #csharp #programming
Today I deployed an #AI backed code review system as part of the @snappautomotive #monorepo PR review checks.
Is it going to replace coders? No. Is it throwing up amazing insights? No.
Is it going to catch small things before PRs get opened for human review? Probably.... and that's where I see value. The more things an automated system catches, the fewer things humans have to spend time looking at.
Microservices integration testing messy? Po Linn (Fo) Chia from @Classpass shares her solution at #InfoQDevSummit Boston: ephemeral containers via CI for reliable & cost-effective testing.
Learn more: https://bit.ly/4doATkX
#Microservices #IntegrationTesting #DevEx
