Not everything is a nail
Most software engineers and Silicon Valley developers treat the world as a nail. Their hammer is Claude Code, CLIs, agent harnesses, and interfaces. They assume everyone needs these tools to solve work, so the world will adopt their application.
They are wrong.
Most people do not do software engineering. Most knowledge work is different. It lives in many heads at once. It requires coordination across disciplines, judgment under ambiguity, and novel solutions to problems no one has seen before. Software engineers rarely encounter this kind of work, so they systematically underestimate it.
When the hammer is a terminal
There is a familiar pattern in tech culture: replace a simple human action with a more “powerful” interface, then call it progress. Yesterday’s button becomes today’s slash command. The people in the room may still be learning the basics. The tooling has gotten denser, not clearer. Complexity is presented as sophistication.
That pattern works when the audience is other developers and the job is writing software. It fails when the job is architecture, law, medicine, construction, manufacturing, public service, or any field where expertise is tacit, contextual, and hard-won over years of practice. Those professions already have workflows. They already have tools. What they lack is not another CLI. What they lack is continuity of judgment across people, projects, and time.
Knowledge work is not a solo repo
Software engineering, at its best, has beautiful abstractions: version control, tests, deployable units, clear interfaces. A single engineer can often hold a large part of a system in their head, then encode it so machines and colleagues can reuse it.
Most knowledge work is not like that.
- It is distributed across people who never share a codebase.
- It is negotiated in conversations, not pull requests.
- It depends on relationships, regulations, physical constraints, and client politics that do not fit a type system.
- The “bug” is often an incomplete understanding of what success means, not a failing assertion.
When builders only know the world of tickets and terminals, they map every problem onto that world. The result is products that feel inevitable to their authors and alien to everyone else: more dashboards, more prompts, more agents that speak fluent confidence about work they have never done.
Consumer disruption is not the same as professional depth
Silicon Valley is excellent at building consumer products that disrupt entire industries. Search, social, marketplaces, media: markets where volume, network effects, and software distribution win. That excellence is real. It is also incomplete.
It is far less competent at professions that rest on deep, hard-won expertise. Those domains cannot be reduced to “a software problem” or “a startup opportunity.” You cannot A/B-test structural engineering the way you A/B-test a feed. You cannot ship a half-wrong legal judgment and patch it on Tuesday. You cannot replace apprenticeship with a chat window and call the risk acceptable.
When every profession looks like a nail, every solution looks like a hammer: another interface, another agent, another claim that “AI will do the work.” The work that actually matters is still human, still multi-person, still full of ambiguity.
What underestimation costs
Underestimating non-engineering work has practical consequences:
- Tools that ignore coordination. Real delivery happens between roles. Solo-productivity software treats the organization as a set of individuals typing faster.
- Capture of the wrong knowledge. Forms and tickets record what is easy to structure. They miss the half-sentence that would have prevented a failure.
- False confidence. Models and agents produce fluent artifacts. Fluency is not correctness, and it is not accountability.
- Erosion of craft. When tools push people toward the interface instead of the judgment, juniors learn the buttons and seniors lose the time to teach the “why.”
The fix is not to ban software. It is to stop pretending every domain is waiting for a developer’s favorite stack.
A better test for builders
Before declaring that the world needs your CLI, agent harness, or chat surface, ask harder questions:
- Does this work live in one person’s terminal, or in many heads at once?
- Is failure cheap and reversible, or expensive and irreversible?
- Is the scarce resource keystrokes, or judgment and trust?
- Would a respected practitioner in that field recognize their craft in your product, or only your craft?
If the answers point away from software engineering norms, your hammer is the wrong tool. The opportunity is still large, but it looks different: amplify human expertise, preserve institutional memory, support coordination, keep people in control of the knowledge that makes their work valuable.
Not everything is a nail. Treating it as one is how you ship “progress” that makes ordinary work harder to learn and easier to get wrong.
Memion is built for knowledge that lives across people: natural conversation, lasting organizational memory, and systems that respect expertise instead of flattening every job into a developer workflow. See how it works.