29 articles
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.
A recent discussion on how AI was used effectively made me wonder what "effective" or "better" meant, because there's no way to test the alternative any more to compare. I still don't know how to characterize my own results, but I think it makes me better because it gives me a chance to work out who I am and what I mean to say, but not really how to say it.
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.
There's no standard for marking AI contribution, and there can't be, because contribution isn't a scalar. What readers actually want is attestation, and that's what a byline always was. The question was never whether a machine touched the text. It's whether anyone was behind the controls.
Baldur Bjarnason argues that development tools win by making developers replaceable. The JVM ran that experiment three times, against Visual Basic's precedent, through EJB's committee, and into Spring's reversal, and the results say his theory is exactly half of a whole.
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.
Ray Myers wrote up the Bun rewrite and the fight around it. It's emotional in places, but there's real signal in it about how agentic work is sold versus how it's done, and one review technique worth stealing.
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.
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.
Bun was ported from Zig to Rust by an LLM and passed nearly all its tests - while shipping more than ten thousand unsafe blocks. Memory safety is the main reason you'd pick Rust. So what did the rewrite actually accomplish?
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.
This is a working example of using red/green testing to fix a bug - one that starts in the issue description and lives in the code. You can fix the issue, but the bug remains because it's part of an unexamined specification. Testing - and caring - are the fix.
AI code is not the enemy. Ideas used to be valued against the weeks we'd spend building them, and most got shelved before we ever found out if they were any good. Now we get to find out in an afternoon.
Alexander Hanff has documented two AI-vendor stealth installs in two weeks: Claude Desktop registering Native Messaging bridges across seven Chromium browsers, and Chrome writing 4GB of Gemini Nano weights to disk on every eligible device.
Simon Willison wrote up a summary of Zig's policy on LLM contribution this morning, suggesting that Zig can afford it because it has PR oversupply and downstream users wealthy enough to fork the project at need. Yet: most communities adopting the same policy don't share those conditions.
JetBrains just published a survey on why AI adoption lags in CI/CD. Their read is that teams are being appropriately cautious; the harder read is that pipelines have no feedback loop for evaluating AI and no outer validator for catching it when it errs. The survey's own numbers quietly confirm this: among teams using AI in CI/CD at all, most aren't delegating. The real split isn't AI versus no-AI. It's passive versus active.
The "10x engineer" may be a real phenomenon, in that some people really do vastly outperform their peers along certain metrics, but "10x output" is the wrong thing to optimize for: you want to find the people who create exponential output for the whole team. AI makes this kind of optimization urgent, because these people not only help their team members, but curtail the worst aspects of AI aid, too.
JetBrains' Koog agent framework now integrates directly with Spring AI, layering agent orchestration - multi-step workflows, fault-tolerant checkpointing, history compression - on top of your existing Spring AI setup without replacing it.
John Loeber wants idiomatic design back, and he's right - but the loss of idiom wasn't laziness, it was physics. IBM's Common User Access standard worked because the OS enforced it and the hardware was fixed; move to the browser, then mobile, then AR, and the contract doesn't bend, it voids. We're not in a period of design failure; we're in the same chaotic pre-standardization phase that preceded CUA in the first place. The question isn't how to restore what we had - it's how to recognize the improvised patterns that are already winning, and hold the line when we find them.