Production Kills the Vibe
0001-01-01
Creating a tool for yourself, or internal company use, is one thing. But there are a pile of complex requirements on production software. Whenever you hear someone falling into [[Maximalism of the Gaps]], it’s best to ask what exactly they’ve put in front of paying customers with it (this is a pretty good yardstick for any technology choice).
What generally happens is that agentic tools like Claude are really good at whipping up a webpage from scratch based on your prompt. You can trivially make things like editor extensions, file converters, visualization tools, or domain specific log parsers or calculators. This impresses someone new to LLMs, and it naturally invites them to imagine that it can do practically anything. Especially if they’re a manager, because [[Software Managers Have Dunning-Kruegar]].
In reality, the big value from LLMs comes from precisely this small-scale personalized use case - something you’d never take time to make yourself is suddenly one hour and a couple million tokens away. This is a huge benefit. But you can’t mistake it for being an omni-powerful tool.
Software engineering isn’t about features, it’s about managing system complexity
Here’s a partial list of things that software engineers have to do, which your agent won’t do out of the box;
- Metrics (gauge or counter? scraped or pushed?)
- Logs (format? frequency?)
- Alerting
- Dashboards
- Deployment
- Dockerfiles
- Build pipeline
- Dependency management
- Auth, (let me emphasize) auth
- Secret management
- Datastore scaling
- Architecture (queues? sparse-column? relational? redis?)
- Schema design / data migrations
- Error feedback (is there a standard error code format to relay to the caller?)
- Data governance (delete account data? export? what system notifies you? Do you coordinate with others?)
All these (and more) are things that every organization does differently, and there isn’t a single "correct" answer. The agent doesn’t know what your organization or the product needs with all of these, because [[Documentation is Always Wrong]]. This is what engineers are being paid to solve - the boring, frustrating, tedious, ever-changing, complex nature of production software.
Tech Debt is Not About Aesthetics
When we talk about tech debt, it’s usually imagined that we’re just autistic engineers bemoaning that our code doesn’t look as nice as it could. There is some tradeoff of "good enough to ship and forget about" that is acceptable. Sometimes, that’s all it is.
Most of the time, though, tech debt is a critical shortfall in functionality that means you’ve painted yourself deeply into a corner. Tech debt doesn’t just require development time to fix, it involves orchestration, data migrations, phased rollouts, careful legacy fallback behaviors, and possibly api breaks that hurt your customers.
Agents are incredibly good at creating tech debt. And very often, people who routinely use agentic stop reviewing what the agent did and just trust it, ignoring that [[Alignment is hard, actually]]. This alignment gap causes the agent to build unknown tech debt into the project. It won’t file a backlog jira, it won’t comment the struct to say it should probably unmarshal as X before Y, and it won’t estimate the migration and orchestration as part of the work when you ask it to make a new feature that conflicts with it. You have no idea what it did, and it doesn’t care.
It’s tempting to believe that there’s some way to specify every possible antipattern for every possible domain and company, so that agents would just avoid those mistakes. But of course, [[Userland is Not Enough]]. The model wants to make those mistakes.
