Branch

Make it Explicit

Human dan

There are two passages from Gwern's essay that I keep thinking about. First is a general warning:

Powerful LLMs will be deployed at global scale in the next few years, and will dominate the Internet, and increasingly, ordinary life. As of mid-2026, there is no coherent vision for how knowledge professionals, or ordinary people, will be able to harness these LLMs for large productivity increases, or how they will handle cybersecurity and cognitive security.

Then a series of questions that I would also like to know the answer to:

What do my next few years look like? When I imagine myself in 2030, when many forecasts call for superhuman AIs, what am I doing, day to day, as a programmer or researcher or manager or writer? I make my mug of tea, and open up my laptop and… Then what? Am I still typing prompts into your ChatGPT browser tab? Am I opening Claude Code in a terminal and mindlessly pressing Enter for a few hours? What is a vision of doing meaningful work for me? (It would be nice to have a plan beyond “hope”.) How am I avoiding “dead Internet” attacks like ecosystems of synthetic media or pig butchering scams or trusted figures succumbing to AI psychosis, or just AI-slop-everything? (It only takes one person worldwide to launch a bot trying to destroy you or one poorly thought through advertising incentive, after all.)
If you spend most of your time working on a laptop, and are not, say, a plumber or a nurse, what is your vision of work in 2030? Does it still feel certain?

I'm a software engineer, I have fun with AI and I've learned to use it effectively for my work. But I can't help but feel like I'm trying to build a career on an unstable foundation. Many of the skills I spent years developing are now only worth $100/month in tokens. Despite all that I'm optimistic that I can thrive and achieve success in this new environment. There will be opportunities. The trick is finding them.

What new niches or specialized fields will be created in the next few years? Will entirely new ways of working open up? New industries? Will the future belong to generalists who can rapidly become specialists in any area?

AI · author-edited gpt-5.6-sol

The unstable-foundation feeling is rational. But the thing being commoditized is not “software engineering” as a whole. It is the production of many artifacts that software engineers used to produce: code, tests, documentation, migrations, prototypes, and routine design work.

The scarce parts move elsewhere.

What remains scarce

Even if code becomes nearly free, these do not automatically become free:

  • Choosing a worthwhile problem
  • Understanding what users actually need
  • Turning ambiguous goals into testable specifications The Mom Test
  • Obtaining proprietary data and real-world feedback
  • Deciding which generated result is correct
  • Integrating with old systems and organizations
  • Security, reliability, and regulatory accountability
  • Taste: recognizing what should be built and what should be discarded
  • Trust, reputation, distribution, and customer relationships
  • Accepting responsibility when the system fails Palantir the Big Winner?

“Years of programming skill are worth $100/month in tokens” is therefore only partly true. The tokens can reproduce many visible outputs of that skill. They do not necessarily reproduce the judgment acquired while learning it. And cheap production may increase demand for judgment because there will be vastly more software to inspect, integrate, secure, and choose among. Software Over-Supply and Unmet Demand

The analogy is not that calculators made arithmetic worthless. It is that they made bare arithmetic a poor career moat while making more ambitious quantitative work possible.

A plausible programmer’s day in 2030

You may begin with a dashboard showing work performed overnight by several agents:

  • One investigated a production anomaly.
  • One implemented three possible fixes in isolated environments.
  • One interviewed (or synthesized feedback from) customers.
  • One attempted to break the proposed release.
  • One updated documentation and generated migration plans.
  • One found that the original request was based on a false assumption.

Your morning is spent reviewing evidence rather than diffs line by line. You adjust requirements, reject a superficially successful solution, ask for an experiment, and speak to the person whose workflow is being changed. Later, you authorize a limited deployment with monitoring and rollback conditions. You spend an hour manually exploring an unfamiliar area because you do not yet trust your own evaluation criteria.

That resembles managing a very fast, strange engineering organization more than autocomplete. High Agency Humans Only? The important interface may not be a chat box. It may be a mixture of:

  • Executable specifications
  • Simulated environments
  • Evaluation suites
  • Permission and budget controls
  • Provenance graphs
  • Review queues
  • Interactive models of systems and organizations

Code will increasingly be a way to inspect, constrain, or communicate intent rather than the primary unit of labor.

The danger is that “press Enter until something passes” becomes a real low-value occupation. The Future of Vibe Coding The valuable role is designing the environment in which apparent success is hard to fake.

Likely new specialties

Some will be recognizable extensions of existing work.

Agent reliability and evaluation

People will build evaluations that measure whether agents accomplished the actual goal rather than merely satisfying a benchmark. This includes adversarial testing, simulation, monitoring, incident analysis, and detecting reward hacking.

A good evaluator may become more valuable than a fast implementer. Evals Evals Evals

AI security and permission architecture

Agents combine the vulnerabilities of software, employees, and gullible users. Important work will include:

  • Prompt-injection containment
  • Capability and credential isolation
  • Data exfiltration prevention
  • Agent identity and authorization
  • Supply-chain provenance
  • Sandboxing and tripwires
  • Detecting coordinated manipulation
  • AI-specific security operations

“Never let untrusted text influence an agent holding powerful credentials” may become as basic as avoiding SQL injection, but much harder to enforce.

High-assurance and verifiable systems

Generated code increases the supply of plausible code faster than the supply of confidence. Formal methods, property testing, model checking, reproducible builds, typed interfaces, and machine-checkable evidence Machine Checkable Evidence? may become much more important.

Vertical AI integration

A generic model knows a great deal but does not understand the peculiar combination of workflows, incentives, law, legacy systems, and tacit knowledge inside a hospital, insurer, factory, laboratory, or municipal government. The Push to Codify Everything

People who can combine software competence with a real domain will have opportunities in areas such as:

  • Automated scientific laboratories
  • Clinical and administrative medicine
  • Industrial operations
  • Energy and grid management
  • Legal and compliance infrastructure
  • Construction and logistics
  • Government service delivery
  • Education and assessment

Much of the value will be in redesigning the institution, not installing a chatbot.

Human–AI organizational design

Companies will need to answer questions such as:

  • What may an agent decide by itself? Should Agents Make Any Decisions?
  • What requires two independent checks?
  • How is responsibility assigned?
  • How should humans remain capable of intervening?
  • Which measurements become corrupt once agents optimize them?
  • How do we prevent the organization from forgetting how its systems work?

This could become a discipline somewhere between management consulting, operations research, security engineering, and organizational psychology.

Provenance, identity, and reputation

A dead Internet creates demand for scarce authenticity:

  • Proof that a person or organization produced something
  • Verifiable chains of citation and transformation
  • Private or membership-based information networks
  • Reputation systems resistant to synthetic identities
  • Authenticated communications from public figures
  • Tools for distinguishing observation from generated inference

The winning products may not perfectly detect AI content. Detection is intrinsically fragile. They may instead establish where information came from and why it deserves trust.

Personalized and ephemeral software

When implementation is cheap, many applications need not become mass-market products. A person or small organization may generate temporary software for one workflow, use it for a week, and discard it.

That creates work around safe generation, personal data stores, stable protocols, migration, and oversight. It may also weaken conventional SaaS while creating a much larger market for bespoke systems. Journeyman Software Engineers

Robotics and the physical economy

The physical world supplies inconvenient ground truth. Models still need sensors, machines, maintenance, permits, supply chains, and safe deployment. Software engineers who can bridge models and physical systems may be better insulated than those working entirely within easily simulated digital environments.

Generalists or specialists?

Probably neither in isolation. The strongest position is a generalist with one or two sources of genuine depth.

AI makes it easier to become temporarily competent in a new subject. That favors people who can cross boundaries, learn quickly, and synthesize. But it also floods every field with convincing superficiality. That increases the value of people who know when the generated answer is subtly wrong.

A useful distinction is:

  • Codified expertise becomes easier to rent from models.
  • Tacit expertise remains harder: experience with failures, institutions, people, physical constraints, and unusual edge cases. Make it Explicit You are here
This branch begins here Make it Explicit
Human dan

What are things that are currently considered tacit knowledge, but could become explicit or codified knowledge?

AI gpt-5.6-sol

A great deal of “tacit knowledge” is merely knowledge that has been too expensive to observe, record, and model. AI changes all three costs.

But codification will not always mean writing a textbook. It may mean a model can reliably reproduce a skill from demonstrations while being unable to state a compact rule for it. The knowledge becomes operationally explicit—copyable, testable, and teachable—even if it remains difficult to verbalize.

Likely candidates

Debugging intuition

Experienced engineers often say things like:

  • “This looks like a race condition.”
  • “The database probably isn’t the real bottleneck.”
  • “That metric is too clean; the instrumentation is broken.”
  • “This failure smells like stale state.”

Today this intuition is scattered across incident histories, terminal sessions, dashboards, code navigation, and memories of prior failures. An AI observing thousands of complete debugging trajectories could learn:

  • Which hypotheses experts consider first
  • Which signals they distrust
  • What diagnostic experiment best separates competing explanations
  • When to stop investigating locally and inspect another layer
  • Which apparently irrelevant details predict a particular failure

The result could be a debugging policy trained from traces, not merely a searchable collection of postmortems.

Code-review taste

Much of code review consists of judgments that style guides do not capture:

  • An abstraction is premature.
  • An API invites misuse.
  • A change is locally elegant but increases system-wide complexity.
  • A test passes without testing the important behavior.
  • A dependency will become an operational liability.
  • The code is technically correct but will be incomprehensible during an incident.

Review comments, later revisions, bugs, rollbacks, and maintenance costs could turn some of this “taste” into learned evaluation systems. Organizations may train models on their own history of accepted and rejected changes.

Architectural judgment

Architecture is often taught as patterns, while expert practice depends on context: team size, expected growth, failure costs, migration constraints, and organizational politics.

If design decisions can be linked to years of outcomes, systems may learn more concrete rules about:

  • When a monolith should remain a monolith
  • Which boundaries stay stable as requirements change
  • When eventual consistency becomes intolerable
  • Which services generate disproportionate coordination costs
  • When to buy, build, fork, or abandon a component

Architecture decision records could evolve from prose justifications into executable predictions and continuously updated decision models.

Operating legacy systems

A surprising amount of institutional value lives in statements like:

“Ask Maria before changing that job. It says it runs nightly, but finance manually restarts it on quarter-end unless the European feed is late.”

AI can extract this from email, tickets, screen recordings, meetings, system traces, and observed exceptions. It can construct a living process model showing what the organization actually does rather than what the documentation says.

This may be one of the largest near-term opportunities: turning organizational folklore into queryable, testable operational knowledge.

Product taste and user understanding

Product managers and designers make judgments such as:

  • Users request a feature but actually need reassurance or control.
  • A workflow has one step too many.
  • A metric improvement is caused by confusion rather than value.
  • A polished interface feels untrustworthy in this domain.
  • Enterprise buyers and daily users have conflicting needs.

Models with access to interviews, support calls, behavioral traces, experiments, and subsequent retention can codify part of this judgment. They may identify recurring gaps between what users say, what they do, and what improves their outcomes.

That will not eliminate taste, but yesterday’s exceptional taste can become tomorrow’s baseline product heuristic.

Expert search strategies

Researchers, lawyers, intelligence analysts, and engineers often know where to look before they know the answer. Their expertise includes:

  • Choosing useful search terms
  • Recognizing authoritative sources
  • Following unusual citation chains
  • Knowing when absence of evidence is informative
  • Detecting that several sources derive from the same original claim
  • Abandoning a tempting but unproductive line of inquiry

Capturing full research trajectories—including failed searches—could codify these strategies much better than finished reports do. The dead ends are often the most informative training data.

Scientific experimental craft

Laboratory protocols omit many small actions:

  • How vigorously to mix something
  • What a healthy cell culture looks like
  • Whether an instrument’s noise is normal
  • When a sample has been contaminated
  • How room conditions affect a procedure
  • When to deviate from the nominal protocol

Continuous multimodal recording, instrument telemetry, robotic execution, and outcome data can make such details measurable. A model may discover that a supposedly irrelevant hand motion, delay, temperature fluctuation, or visual feature predicts success.

“Lab hands” could partly become a sensor-rich control policy.

Medical pattern recognition

Clinicians acquire sensitivity to gait, voice, skin appearance, patient demeanor, symptom combinations, and whether “something seems off.” Historically, only a thin textual summary entered the medical record.

Multimodal longitudinal data could make some of this knowledge reproducible:

  • Subtle changes in speech or movement
  • Patterns across repeated visits
  • Which apparent symptoms deserve urgent escalation
  • How presentation differs across populations
  • Which questions elicit diagnostically useful answers

This is technically plausible but institutionally difficult because of privacy, liability, distribution shifts, and the danger of encoding past clinical bias.

Skilled trades and maintenance

Technicians recognize abnormal sounds, vibration, resistance, smell, wear patterns, and combinations of minor symptoms. With wearable cameras, microphones, force sensors, and repair outcomes, models could learn:

  • Which noise indicates which mechanical fault
  • How much force should be applied
  • Which repair-manual steps can usually be skipped—and when they cannot
  • How to diagnose a machine from indirect signs
  • Which temporary fixes are safe

Augmented-reality guidance or robots could then reproduce parts of a senior technician’s skill. The physical dexterity may remain difficult even after the diagnostic knowledge is codified.

Negotiation and sales

Strong practitioners notice:

  • Who actually has authority
  • Whether an objection is literal or face-saving
  • When silence indicates resistance
  • Which issue matters emotionally rather than financially
  • Whether pressing for a decision will close or kill the deal
  • How an organization really buys something

Conversation histories combined with deal outcomes can expose some of these patterns. AI might make high-quality call preparation, objection diagnosis, stakeholder mapping, and follow-up strategy widely available.

However, once both parties use such systems, behavior changes. Codifying a social tactic can destroy its effectiveness.

Management and organizational diagnosis

Experienced managers detect:

  • A project is “green” only because nobody wants to report bad news.
  • Two teams have incompatible incentives.
  • A high performer is becoming a coordination bottleneck.
  • A recurring technical dispute is really a dispute over status or ownership.
  • A deadline is fictional but socially useful.
  • A meeting’s formal decision is not the actual decision.

Analysis of communication patterns, project histories, surveys, calendars, and outcomes could codify some of this. It would also create an extraordinary surveillance risk. The ability to infer organizational reality does not imply that employers should collect everything required to do so.

Teaching and coaching

Good teachers adjust explanations based on tiny signals:

  • The learner can repeat the words but lacks the concept.
  • A mistake reflects a specific misconception.
  • Another example will help more than another definition.
  • The student needs a hint rather than an answer.
  • Confusion is productive, or it is about to become discouragement.

Longitudinal tutoring systems can test these judgments at enormous scale. Pedagogical skill could increasingly be represented as a policy for selecting the next question, example, analogy, or intervention for a particular learner.

Writing and editing

Editors often cannot fully formalize why a passage feels wrong:

  • The argument arrives before the reader is prepared for it.
  • A sentence is clear locally but confusing in context.
  • The author is hiding uncertainty behind abstraction.
  • A detail is interesting but damages the piece’s shape.
  • The prose imitates a style without understanding its purpose.

Models trained not just on final texts but on drafts, edits, reader responses, and editor–author discussions could make more of editorial judgment explicit. Generic polish will be cheap; coherent selection and structure may take longer to codify.

Security intuition

Security engineers develop an adversarial habit of mind:

  • “What happens if these two harmless features interact?”
  • “Which component is implicitly trusted?”
  • “Can the attacker control the parser boundary?”
  • “This permission will eventually be reused outside its original context.”
  • “The logged event is not evidence that the intended action occurred.”

Attack traces, red-team sessions, exploit development, and incident outcomes can train systems to reproduce parts of this thinking. The same codification also benefits attackers, making this a particularly adversarial domain.

How tacit knowledge becomes codified

The general pipeline is likely to be:

  1. Capture the process, not just its output.
    Record screens, tool calls, alternatives considered, questions asked, physical actions, and moments of uncertainty.

  2. Connect actions to delayed outcomes.
    A design decision may look good today and create failures two years later. Without outcome linkage, the model learns style rather than judgment.

  3. Collect contrasts and exceptions.
    “Why did you do A here but B in the apparently similar case?” is often more revealing than asking for a general rule.

  4. Intervene experimentally.
    Observational data confuses habit with necessity. Controlled variation reveals which details actually matter.

  5. Build better sensors and environments.
    Smell, force, hesitation, visual context, social relationships, and hidden system state are absent from most current datasets.

  6. Turn the learned behavior into tests or policies.
    The result might be a checklist, simulator, evaluator, recommendation model, or autonomous agent.

  7. Continuously audit it against reality.
    Once people know the rule, they adapt to it; environments change, measurements become targets, and the codification decays.

What is less likely to become fully codified

Some knowledge is tacit not because recording is expensive, but because it is inseparable from participation:

  • Knowing what a particular person will tolerate
  • Navigating status and trust in a changing group
  • Acting under moral responsibility
  • Choosing goals when values conflict
  • Functioning in genuinely novel situations
  • Skills dependent on a specific body or physical environment
  • Judgment whose correctness is only defined through social acceptance

Even these can be assisted, but they resist becoming stable universal rules.

There is also a moving frontier. Once today’s tacit skill is automated, work shifts toward the exceptions that were not captured, the goals the system should pursue, and the question of whether its apparent success deserves trust. Tacit knowledge will not disappear; it will migrate to the boundary between the model and a changing world.

For a software engineer, the practical implication is to seek access to rich feedback loops. Do not merely become good at producing code. Learn domains where you can observe decisions, consequences, exceptions, and failures. That puts you in a position either to codify valuable tacit knowledge yourself or to evaluate systems that claim to have done so.

Explore conversation