The Case for Software Craftsmanship in the Era of Vibes

Summary

They tell me software developers will soon be replaced by autonomous agents. Yet every single day, I encounter bad software. When AGI comes, can its first assignment be to ship a decent calendar app? I'm not here to complain about bad software, at least not in this post. I'm here to make the case for quality software in an era where constraints on code production have been dramatically lifted. You can vibe code at a buttery-smooth 120fps in Zed and generate code 24 hours a day if you're so inclined. But in a world of abundance, the bar should be higher for quality. As software engineers, we should measure our contribution not in lines of code generated, but in reliable, well-designed systems that are easy to change and a pleasure to use. There's a lot of talk online about the 10x (or even the 100x!) engineer. Most people are talking about how AI can help us make software faster and help us make more software. As craftspeople, we should look at AI and ask, "How can this help me build better software?" If you've spent any time in a codebase that solves real problems, I'm sure you can relate to this sentiment: "I want this to be better, but I don't have time to fix it." The system is broken in ways that hobble our productivity and imagination, but we need to ship. There's always an incentive to achieve our goals by bending the existing system instead of revising it, even if that leaves the system "not quite right, but good enough." Our values at Zed of "Shipping & Craftsmanship" exist as a pair for a reason. We should feel urgency, but we shouldn't be using urgency as an excuse to cut corners. Short-term gains aren't worth the cost of suboptimal velocity for the lifetime of the company. This is even more true now that a gnarly code base hinders not only our own ability to work in it, but also the ability of AI tools to be effective in it. Recognizing this dynamic doesn't make it any easier to resolve. Since we're only learning about a system as we build it, we may not ...