Gardening with AI, Farming with Engineers: Why Software Still Needs Experts
There's a difference between growing a tomato and feeding a village
It's now impossible to scroll through tech news or social media without encountering "vibe coding" or some variation—vibe marketing, vibe design, vibe everything. The concept is simple: in the words of Andrej Karpathy, you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." Just describe what you want in plain English, and AI handles the technical implementation.
The results speak for themselves. Companies like Cursor, built around these AI coding tools, have reached $100 million in annual revenue in just 12 months. Google reports that 25% of their new code is now AI-generated. The New York Times runs articles about non-programmers building their own software tools. With each new headline comes the growing sentiment that traditional software engineering might become obsolete—why spend years mastering programming languages when anyone can now describe what they want and have functioning software materialize?
This narrative is compelling and contains truth. The barrier to creating simple software has indeed lowered. But this black-and-white view—that AI makes coding so easy that engineering expertise becomes irrelevant—misses a more complicated picture.
Are You Gardening or Farming Software?
When I think about the different ways we create software, I find myself returning to my favorite analogy - gardening versus farming.
Let me explain. I've occasionally tried my hand at gardening. I've grown tomato plants that have delivered pretty good results, and there's a certain satisfaction in watching something grow. But my tending a small garden plot is simple. The stakes are low. If I succeed, I get to claim the salsa tastes better because the tomatoes are home-grown. If I fail, I buy tomatoes at the store. And if you think my green thumb is going to feed my street, then strap in and be prepared to go hungry.
Until recently, this type of software development—gardening your own script or app—still required a fair amount of knowledge. You had to learn the syntax of a programming language and navigate the frustrating maze of debugging. But AI programming agents have transformed this landscape. Fire up Cursor, describe what you want, and you'll get functional code with impressive results. It's personal, immediate, and incredibly gratifying—just like harvesting that first homegrown tomato.
There's a fundamental difference between growing a tomato plant to feed yourself every now and then—it's not mission-critical—versus growing tomatoes season after season to feed a village. The latter requires deep understanding of soil science, pest management, irrigation systems, and logistics. Similarly, writing code for a small project versus architecting software for scalability, security, and maintainability are entirely different beasts. Just like getting your farming processes wrong could deliver E. coli along with the produce and induce a health crisis, poorly written software can topple the organizations that depend on it.
I've been fortunate to witness firsthand how software "farming" operates at industrial scale with much higher stakes. I've worked on teams writing software that provisioned cable modems and configured network stacks to connect millions to high-speed internet. I've managed transitions of systems serving millions of users where downtime wasn't measured in inconvenience but in significant business impact. These systems must be reliable, secure, and maintainable over long periods, just like commercial farming that feeds entire communities year after year.
The growth of vibe-coding isn't going to end professional software development any more than saying because gardening gets easier, farming goes away. Both will continue to serve different but equally important purposes in our digital ecosystem.
While both approaches have their place, the danger emerges when we confuse the two—when the tools and mindset suited for a personal garden plot are applied to mission-critical farms. The temptation to use the simpler, faster 'gardening' method for 'farming'-scale problems is powerful, and it has deep roots in the history of business software.
Excel: The Original "Gardening Tool" That Changed Business
This tension between accessible tools and complex systems isn't new to the software world. We've seen it play out before with spreadsheets, particularly Microsoft Excel.
Excel transformed business by putting computational power in the hands of non-programmers. Suddenly, anyone could create financial models, analyze data, and automate calculations without writing traditional code. It democratized a form of programming, wrapped in an accessible interface that prioritized immediate results over software engineering principles.
And it worked brilliantly—for gardening-scale problems. Individuals could track personal finances, small teams could manage projects, departments could analyze their metrics. Excel became a powerful software gardening tool, allowing people to grow their own solutions without specialized training.
But as with any powerful tool, Excel's very accessibility led to its overextension. What started as personal productivity tools gradually evolved into business-critical systems. Financial models that determined billion-dollar investment decisions, risk management systems for global banks, supply chain management for multinational corporations—all built in a tool designed for individual productivity rather than industrial-scale reliability.
When a Spreadsheet Costs $6 Billion
In 2012, JPMorgan Chase lost over $6 billion in the infamous "London Whale" trading disaster. While multiple factors contributed to this failure, one critical element was a Value at Risk (VaR) model built in Excel that contained significant errors.
The model, which was supposed to measure trading risk, contained formula errors introduced during manual data copying between spreadsheets. These errors caused the system to severely underestimate risk, contributing to the massive loss. A Senate investigation later revealed that risk managers were copying and pasting data between spreadsheets and using manual calculations rather than automated systems with proper controls.
This wasn't an isolated incident. TransAlta, a Canadian power company, lost $24 million due to copy-paste errors in Excel. Researchers have found that nearly 90% of spreadsheets contain errors, yet they continue to be used for critical business functions.
These cases illustrate what happens when gardening tools are applied to farming problems. Excel is an excellent tool for personal productivity and small-scale analysis. But when used for mission-critical systems without proper engineering controls, it introduces significant risks. The very features that make it accessible—flexibility, ease of modification, lack of rigid structure—become liabilities at scale.
AI: Enhancing Both Garden and Farm
The rise of AI coding assistants is clearly empowering more people to become software "gardeners," creating their own tools and solutions. This is a positive shift, bringing more innovation and problem-solving capabilities directly to those who need them.
However, these AI tools offer benefits to software "farmers" as well. Far from just enabling simpler tasks, AI is becoming a powerful co-pilot for engineers tackling complex systems. It can accelerate the generation of unit tests, draft documentation, suggest refactoring improvements for maintainability, and even identify potential security vulnerabilities—all tasks essential for robust "farming" but often time-consuming. AI can help ensure the large-scale digital crops are healthier and more resilient.
So, the narrative shouldn't be about AI replacing engineers, but about how it enhances both "gardening" and "farming." So next time, you read a black-and-white narrative about the end of software development profession, remember the future will have gardeners and farmers.
Related
