Insights — Notes on AI, software, and getting work done — from the Sterling team.
Software engineers shouldn't be writing code anymore. That ship has sailed. But they're still the bottleneck. We run 5–6 AI agents in parallel at Sterling. Code is effectively free. And yet: the speed at which we can create code has completely outpaced the speed at which we can prove it works. Every impressive autonomous coding experiment — Anthropic's C compiler, Cursor's browser — succeeded because they had a strict test suite to build against. Nobody's done it for a real application without a human in the loop. The bottleneck moved. It used to be writing code. Now it's proving the code works.
If your first move with AI is "add a chatbot," you're bolting the technology onto the surface of your product instead of rethinking what it can do. This post digs into what marshmallowiness actually is — rigid inputs, rigid outputs, and a soft judgemental middle — and why the best use of LLMs might be one your users never even notice.
The genuinely new thing LLMs bring to software isn’t intelligence or automation. It’s marshmallowiness. LLMs are soft, squishy, language-first. They’re great at interpreting intent, filling in gaps, and explaining things like a human would. That changes how you should build. But leaning into marshmallowy also forces a rethink: how you guide humans without boxing them in, how you give agents freedom without trusting them and, where softness helps — and where hard edges are non-negotiable. We’ve learned you’re always designing for two audiences at once: humans and agents. Miss either, and the system falls apart. I wrote up how we think about this — what marshmallowy enables, where it breaks, and the guardrails that make it work in practice.