90% of software engineering is knowing what not to write
It's clear that software engineering is changing. Gone are the days of code output being the core bottleneck for most projects. In any medium to large company, the plan-code-test cycle is the most efficient way to write software going forward. If you're still in denial, you're falling behind.
However, that is not what defines a software engineer or engineering in general. The following is the first line defining engineering in wikipedia:
Engineering is the practice of using natural science, mathematics, and the engineering design process to solve problems within technology, increase efficiency and productivity, and improve systems.
Notice how it consists of two broad active verbs, practice and solve. But there's a third word hiding in plain sight: design. Design is inherently about tradeoffs — what to include and what to exclude.
We're seeing an inflection point in the solution part. Just like punch cards were made obsolete by handcrafting assembly, followed by ever higher level languages ever since; I expect the same thing will happen on a larger scale with LLMs. We're no longer constrained by code output anymore. And as these technologies improve, they will only allow for better integration and output patterns.
So, what is left for an engineer to do? Ironically, a lot more. Pre-AI/Agentic coding, planning and coding constrained the delivery funnel for most "funded" engineering projects. With the coding part getting ever cheaper, you might think the funnel is now constrained by just planning.
I believe you're wrong to assume that!
See, the funnel didn't automatically get thinner in the middle just because code was inexpensive. In fact, the planning part of the funnel got wider and with higher stakes.
Inexpensive code means harder decisions #
When code is nearly free to produce, more things can be built. And when more things can be built, there are more decisions about what should be built. The bottleneck shifts from "can we build this?" to "should we build this?", which almost always is a much harder decision.
The real value of an experienced engineer is increasingly in knowing what not to write.
- Knowing which features to say no to, even when they're easy to build. It's harder to reduce code than it is to add.
- Knowing when a third-party service or library is better than building in-house, including knowing when including it will cause debt which can only be known if you have the general tacit world knowledge only humans can possess
- Recognizing when a "simple" feature has hidden complexity — edge cases, operational burden, security surface area. LLMs are constrained by their context window, their model, and the narrow window of an execution decision tree they're operating in.
An AI-implemented solution leans heavily towards one path or the other in most circumstances. It will indiscriminately build a custom rate limiting solution and then suggest using redis for caching in another solution, not knowing that the problem domains are compatible across requests and sessions.
Creation is inexpensive, ownership is not #
Ownership is the crux of the difference between vibe/slop-coding apps and a real SaaS provider. Vibe coding begets vibe coding. As you don't develop the global context for your own project, a 2am page will be a nightmare for any complex app. Without understanding the internals of the system you're building, you will never realise that your picture-perfect custom auth solution is breaking because provider X did not implement the OAuth2 refresh tokenizing in the exact same way as all the other providers.
Vibe coding begets vibe coding
This is where "knowing what not to write" becomes critical. The engineer who generates reams of code per day cannot truly compete with an engineer who glanced at the problem and said, yes, we should not roll our own auth.
Most real customers, willing to pay you money, expect uptime, responsiveness, and a clean roadmap of features. This is not possible if your system grows like a jungle as you smash out another prompt. The only way this is possible is by knowing the real world constraints you're operating in and deeply understanding your codebase before opening your next claude code session or cursor tab.
Judgment wins #
What separates senior engineers has always been judgment. But for a long time, that judgment was masked by the coding bottleneck. When writing code was slow and expensive, raw output was a reasonable proxy for contribution. Now that bottleneck is gone, and judgment is laid bare.
Engineers who were primarily valued for code output are exposed. Those valued for architectural thinking and the ability to say "no" are more important than ever. The skill isn't typing faster or prompting better — it's pattern recognition built over years of seeing what works, what breaks, and what quietly becomes a liability.
Practice makes the engineer #
This brings us back to the engineering definition. The word practice implies accumulated judgment, pattern recognition, and a deep understanding of what works and what doesn't. That part doesn't get automated away. It only amplifies with age and experience. An engineer with strong judgment and AI tools is dramatically more effective than either alone.
This has been said in other online circles before, but the AI multiplication factor isn't linear. It sort of goes like:
- An engineer with poor pattern recognition and low world knowledge: Maybe 2x faster with coding agents and tools
- An engineer with years of honed pattern recognition and broad world knowledge: At least 10x faster with coding agents and tools
The second lot is the engineer that can guide the company and the product to a sustainable cadence of delivering customer value, not marred by outages and tech debt.
The future of software engineering isn't about writing more code. It's about writing less of it, more deliberately, with a clearer understanding of why each piece exists and what it costs to keep it alive.
↑ Top