11 articles
Nolan Lawson explores why developers often build custom solutions instead of using native APIs, largely looking at JavaScript, but it's something that shows up in most languages and environments, for good reason.
Alex Martsinovich argues that agentic coding causes four unavoidable harms - slop, alienation, deskilling, and team breakdown — but these aren't technological inevitabilities, they're the results of specific choices about how to use AI coding tools.
Kerry Ivan Kurian's 'Exponential Failure' says AI agents multiply parts faster than they improve them, so projects fail by arithmetic. He's right about the math and wrong about the fix: the answer isn't fewer parts, it's parts you can describe.
Sunil Pai's “senior engineer death spiral” describes what happens when engineers start managing perception instead of reporting reality. The deeper problem may not be individual pride or fear, but organizations that make uncomfortable information too expensive.
Andrew Oram asked why programming languages rise and fall, and quoted the answer without noticing. Programming is a vocation, an art, and a job. Make any of those harder than they need to be, and your language survives exactly as long as it can't be replaced.
Sean Goedecke argues that domain expertise is the real prompting skill. He's describing two quantities as one: a floor, available to anyone who can describe what acceptance looks like, and a gain that multiplies whatever you bring.
Reader Hideki Idoru argues that AI is a decent information distiller and a bad tool for nearly everything else in software, because no one can cheaply verify that generated code is correct. The deeper claim is that most programming was already trivial, unabstracted busywork, and AI has only torn the mask off. It's worth reading and thinking about.
A Reddit user on r/SaaS is looking forward to the consulting rates he'll command once the wave of projects trying to dig out from under AI slop hits. He's not wrong, but he's dated the pattern to 2010 offshoring when it's older than that, and the lesson never sticks: coding was never typing.
Christian Rackerseder argues that the real axis for testing decisions isn't integration versus end-to-end, it's control: whether a team can make a dependency predictable enough for a given test and actually act when it fails.
Sven Reinck wants dependency diagrams that nudge you toward clean architecture by looking wrong when the code is wrong. The instinct is sound, the history is unkind, and the difference between expressing complexity and measuring it is where the whole idea lives or dies.
Christian Ekrem's 'The Tacit Dimension' carries Polanyi's 'we can know more than we can tell' into software engineering. He's right that experience works that way. Knowledge doesn't, and the essay never separates the two.