cross-posted from: https://lemmy.bestiver.se/post/1018360

Comments

Here's what I keep seeing: the specification-driven development (SDD) conversation has exploded. The internet is overflowing with people saying you should write a spec before prompting. Describe the behavior you want. Define the constraints. Give the agent guardrails. Good advice. I often follow it myself.

But almost nobody takes the next step. Encoding those specifications into automated tests that actually enforce the contract.

You’re paying for the AI to write code, so surely the expensive part is what it produces, right? I would have guessed something like 60/40 or maybe 70/30 skewed towards output. The reality is nothing like that. Real-world data from OpenRouter’s programming category shows 93.4% input tokens, 2.5% reasoning tokens, and just 4.0% output tokens. It’s almost entirely input.

It turns out Claude Opus 4.6 and GPT-5.4 are both very competent at SwiftUI—and a full SwiftUI app can fit in a single text file, which means I can use them to spin something up without even opening Xcode.

The biggest risk in AI adoption isn’t moving too slowly. It’s mandating too hard, watching it backfire, and oscillating between full commitment and full retreat. The organizations that found their footing got better at paying attention, not better at writing policy.

AI conversations are ephemeral by design — decisions made early fade as sessions lengthen, and nothing survives the session boundary. Developers hold on to long conversations not because long sessions are productive, but because the context lives nowhere else. I propose externalizing decision context into a living document — external memory that persists what the context window cannot, turning transient alignment into durable shared understanding.

My efforts rewriting machina and postal over 13 days — not to mention the ~8 other libraries I’ve written in the last year — have served as proof that stranded expertise is much cheaper to rescue than ever.

It’s like a Trojan Horse of craft: guidelines you might never agree to explicitly are guiding LLM outputs, which means you are agreeing to them implicitly.

A recent piece, Grief and the AI Split, made me ask myself what exactly it is that I like about building software.

Comprehension debt is the hidden cost to human intelligence and memory resulting from excessive reliance on AI and automation. For engineers, it applies most to agentic engineering.

After building Curling IO Version 3 in Gleam alongside AI coding agents, I'm convinced Gleam is the best language for this workflow. Agents don't write better Gleam - there's less training data. But Gleam's compiler lets agents self-correct without waiting for a human.

TL;DR: AI-assisted coding is revealing a split among developers that was always there but invisible when we all worked the same way. I've felt the grief too—but mine resolved differently than I expected, and I think that says something about what kind of developer I've been all along.

AI doesn’t fix your bottlenecks. It amplifies them. DORA’s report on AI-assisted software development confirmed that AI amplifies existing flow and exposes brittle processes and frictions. If your flow is good, AI makes it better. But if you have a lot of painful bottlenecks and frictions, AI makes the pain worse.

Right now, every Claude Code user is running without LSP. That means every time you ask "where is processPayment defined?", Claude Code does what you'd do with a terminal. It greps. It searches text patterns across your entire codebase, reads through dozens of files, and tries to figure out which match is the actual definition.