Maybe IT Was Never About the Technology? Code Is Cheap, 'Why' Is Getting Expensive
Conversations about AI in the team revolve around tools: Claude or Codex, which model, which plugin. It’s all secondary. Code is being written today faster than anyone can read it, so the bottleneck is no longer the speed of delivery.
The real problem is losing the connection to the question “why”. A change lands in the repo, but nobody remembers what problem it was solving, who approved it, or whether anyone should have at all.
How the “why” gets lost #
I see it more and more in code review. Developers are increasingly willing to write code that changes business logic. I read such an MR and ask myself: did anyone actually decide that this logic should change? And if not, who could have? Often I don’t know the answer.
Producing code is no longer the bottleneck. The new bottleneck is decisions. This is not a model problem: the “why” gets lost in three places, regardless of the tool:
- Nobody knows everything. Knowledge is scattered across repositories: one has a README with the rules, another keeps them in one person’s head, a third has none. The author of a change often doesn’t have the full information to make it.
- It’s unclear who decides. If anyone can merge, and disputes are settled by whoever clicks first, then the decision is made by accident.
- The decision has no path. An agreement from a conversation, a note, or a session with an agent has no process that turns it into a change. After a few days, nobody knows where it ended up.
AI doesn’t create these gaps, it just accelerates them. It produces more changes, and each one falls into the same void.
Where to put the control points #
Since not everyone has the full information, you need to know where a person with context has to look at the change. Not everywhere, because then the process kills the pace. In three points: at the “why” description, at the review by the area owner, and at release.
The answer has been in open source for a long time #
Open source projects have always lived with an oversupply of ideas: hundreds of contributors, a few maintainers, constant debate about direction. Languages, frameworks and tools have changed in them many times. What survived is something else: the way these projects decide what and why goes into the code.
Maybe that’s the answer to the question in the title. The greatest value our industry has produced is not any technology, but processes and standards. And they are ready to take:
| Where the “why” gets lost | Open source policy | Where it comes from |
|---|---|---|
| Business logic change without the owner’s decision | Small changes + mandatory “why” description; for direction changes: description first, then code | Rust RFC, Kubernetes KEP, ADR |
| Unclear who knows the area and who decides | List of area owners and a decision model (one leader or an explicit council) | Linux MAINTAINERS, GitLab CODEOWNERS, Python (PEP 13) |
| The decision lives in a note or a local patch | Upstream first: a change is accepted only when it lands in the main repo | Fedora, Android |
| Agents and automations flood the repo with minor changes | Grouping changes into one review per cycle | Renovate, Dependabot |
None of these policies depend on the tool. They worked before AI appeared, and they will work when we switch models for the fifth time. Technologies get replaced, good processes are inherited.
Conclusion: SDLC is infrastructure too #
The key to success for tech companies today is shipping new features as fast as possible, and AI undoubtedly enables that. But the winners won’t be the companies with the best model, only those with well-described processes. It’s easiest to adopt AI point by point in them: in a specific step, with a clear owner and a clear “why”.
This brings us back to the SDLC, which for a long time may have seemed a non-critical part of our “infrastructure”. Except that a process cannot live in prompts or in an agent’s configuration. People have to know it, because only they know why a change is being made.
Then even when AI kneels down — and it will one day — we will watch over it. And instead of inventing governance from scratch, take it from those who have been managing a crowd of enthusiasts with repo access for decades.
Final recommendation. If all this “why” sounds familiar, it’s no coincidence. Simon Sinek, author of the book Start with Why: How Great Leaders Inspire Action, in his TEDx talk “Start with Why” argues that people follow why you do something, not what you do. I have a feeling it’s exactly the same with changes in code.
References #
- Rust RFC process: https://github.com/rust-lang/rfcs
- Michael Nygard, Documenting Architecture Decisions: https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
- Linux kernel, MAINTAINERS: https://www.kernel.org/doc/html/latest/process/maintainers.html
- GitLab, Code Owners: https://docs.gitlab.com/user/project/codeowners/
- PEP 13, Python Language Governance: https://peps.python.org/pep-0013/
- Fedora, Staying close to upstream: https://docs.fedoraproject.org/en-US/package-maintainers/Staying_Close_to_Upstream_Projects/
- Renovate, groupName: https://docs.renovatebot.com/configuration-options/#groupname
- Simon Sinek, Start with why: how great leaders inspire action (TEDxPugetSound): https://www.youtube.com/watch?v=u4ZoJKF_VuA
- Simon Sinek, Start with Why (book): https://simonsinek.com/books/start-with-why