The Software 3.0

The post argues that teams using the same LLM can achieve very different results because individual knowledge of context engineering varies widely. Claude Code’s plugins and marketplace could help turn personal LLM techniques into shared, executable team workflows, raising the organization’s productivity floor. The author presents this as a forward-looking hypothesis rather than a proven success story.

The Frictionless Harness

• LLM adoption loses effectiveness when developers must switch between terminals, browsers, and chat tools.
• Claude Code’s terminal-based TUI reduces context switching by combining natural-language instructions and code in the developer’s existing environment.
• This low-friction experience makes it easier to distribute standardized workflows across a team.

Executable Single Source of Truth

• Wikis and Notion pages become outdated because they are designed primarily for human reading.
• Claude Code plugins can serve as “executable SSOT”:
  • Humans can read them as guidelines and manuals.
  • LLMs can interpret them as precise system instructions.
• Updating a plugin can immediately change how team agents behave, keeping operational knowledge aligned with current practices.

Raising the Team’s Productivity Floor

• Teams have significant differences in LLM literacy, independent of coding ability.
• Generic open-source plugins can provide shared best practices, but they lack company- and domain-specific context.
• Each domain needs its own rules for:
  • Tasks the AI can perform autonomously.
  • Tasks requiring human approval through HITL processes.
• The goal is to minimize human intervention while preserving approval at critical points.

Extending Platform Engineering into Software 3.0

• AI workflows resemble traditional internal platform components such as authentication, logging, and payment libraries.
• The analogy is:
  • Common software modules → AI workflow plugins
  • Library distribution → Marketplace publishing
• The implementation changes from traditional code to prompts and agent logic.
• AI workflows should receive the same quality practices as software modules, including review, optimization, and feedback on token usage and failure cases.
• Marketplace-based collaboration could turn individual prompting techniques into shared organizational intelligence.

Why Use a Marketplace Instead of Only RAG?

• RAG systems can make it difficult to predict which context will be retrieved due to search, reranking, and indexing behavior.
• Plugins provide more explicit and controllable instructions and code.
• Developers can modify and test workflows locally in the TUI without deploying a server.
• With the Claude Agent SDK, workflows validated locally could also run in server environments, improving development-production parity.
• The marketplace could become the shared source of truth between experimentation and production.

Marketplace as a Workflow Distribution Platform

• Teams could package coding conventions, Git strategies, lint rules, and testing policies into private plugins or registries.
• Hooks could actively correct behavior rather than merely reject violations—for example, preventing commits on main and creating a feature/ branch instead.
• Slash commands could distribute the best engineer’s workflow to everyone:
  • /new-feature gathers requirements.
  • Creates a Jira issue and branch.
  • Produces an implementation plan for approval.
  • Implements the feature and opens a pull request.
• This allows less experienced users to follow a reliable, high-quality process without reproducing it manually.

Layered Context Architecture

The author proposes separating plugin knowledge into three layers:

• Global layer: Organization-wide security rules and coding standards.
• Domain layer: Business-specific knowledge for areas such as payments, settlement, or membership.
• Local layer: Repository-specific implementation details and conventions.

This structure avoids overwhelming the LLM with irrelevant information and creates a “living knowledge base” made of maintainable prompts and code rather than static documents.

The Data Flywheel Hypothesis

• Standardized plugins could generate high-quality instruction-tuning data.
• Accumulated workflow data might eventually support domain-specific model fine-tuning.
• Existing workflows could also provide evaluation criteria for those models.
• Success would require sustained data collection, quality controls, and long-term organizational investment.
• The proposed flywheel is: more usage creates more data, better data improves models, and better models encourage further usage.

The practical recommendation is to treat LLM expertise as an organizational system rather than an individual skill. Teams should begin packaging their implicit knowledge, approval rules, and proven workflows into versioned, domain-aware plugins that can be tested, reviewed, and distributed through a marketplace or private registry.