~/wiki

Autonomous Code Modules

Confiance : high
code-architecturemodularitydependency-managementself-contained-systemssoftware-designproduction-handoverarchitecture-migrationlegacy-archivalmaintainabilityclean-architecturezero-dependenciesinternalized-componentscomponent-internalizationcodebase-simplificationproduction-ready-designhandover-optimization

Software architecture pattern where modules are completely self-contained with zero external dependencies on other project code. Enables independent deployment, testing, and maintenance while reducing complexity for new developers. Critical for production handover scenarios where code needs to be maximally exploitable by subsequent engineers.

Core Principles

Zero External Dependencies

  • No imports from other project modules
  • Internalized utilities instead of shared dependencies
  • Self-contained configuration and resource management
  • Independent data access patterns

Component Internalization

Rather than sharing code through imports, autonomous modules internalize only the functionality they need:

# Instead of: from src.shared.embedder import FallbackEmbedder
# Internalize: src/module/embedder.py with only needed functionality

class SimplifiedEmbedder:
    """Internalized embedding logic - only what this module needs."""
    def __init__(self, model_config):
        self.albert_embedder = AlbertEmbedder(model_config.albert)
        self.scaleway_embedder = ScalewayEmbedder(model_config.scaleway)
    
    def embed_texts(self, texts: List[str]) -> List[List[float]]:
        try:
            return self.albert_embedder.embed_texts(texts)
        except Exception:
            return self.scaleway_embedder.embed_texts(texts)

Simplified Architecture

  • Single responsibility per module
  • Clear interfaces between components
  • Minimal complexity for easier understanding
  • Production-ready design from start

Implementation Strategy

From Shared to Internalized

  1. Identify dependencies on other project modules
  2. Extract essential functionality (not full complexity)
  3. Internalize simplified versions into autonomous module
  4. Remove external import statements
  5. Test module isolation independently

Component Sizing

  • Simplify shared utilities to only needed functionality
  • Merge related concerns when logical (e.g., config + prompts)
  • Split large components along clear boundaries
  • Target 100-300 lines per focused module

Benefits for Handover

Maximum Exploitability

  • New engineers can understand modules independently
  • No hunting through complex dependency trees
  • Clear boundaries between system components
  • Reduced onboarding time for domain-specific knowledge

Maintenance Advantages

  • Isolated changes don't cascade across modules
  • Independent testing and validation
  • Clear ownership of functionality
  • Simplified debugging when issues arise

Production Readiness

  • Deployment simplicity with self-contained modules
  • Reduced failure modes from broken dependencies
  • Clear operational boundaries for monitoring
  • Easy rollback to previous versions

Case Study: Assistant-RH V3 Clean

The assistant-rh project demonstrated this pattern during its V3 Clean migration:

Original Complexity

  • 3 RAG versions with complex cross-dependencies
  • Shared utilities imported across 20+ files
  • 5700 lines of interconnected code
  • Multiple failure points from dependency chains

Autonomous Transformation

src/rag_v3_clean/  # Completely self-contained
├── embedder.py          # Internalized from src/rag/embedder.py (425→200 lines)
├── reranker.py          # Simplified from src/rag/reranker.py (450→120 lines)  
├── query_processor.py   # Merged intent+reformulation (879→300 lines)
├── llm_client.py        # Unified LLM interface with fallback
├── config.py            # Pipeline+runtime config unified
└── [other modules...]   # All self-contained

Results

  • 53% code reduction (5700 → 2700 lines)
  • Zero dependencies on legacy src/rag* modules
  • Independent deployment capability
  • Simplified handover for next engineer

Design Patterns

Configuration Internalization

# Instead of importing shared config
from .config import RAGConfig, SystemPrompts, ModelConfig

class AutonomousModule:
    def __init__(self):
        self.config = RAGConfig()  # All config internalized
        self.prompts = SystemPrompts()
        self.models = ModelConfig()

Utility Simplification

# Internalize only needed functionality
class AutonomousAcronymExpander:
    """Simplified acronym expansion - only core logic."""
    
    def __init__(self):
        # Load only essential acronyms, not full dictionary
        self.acronyms = self._load_essential_acronyms()
    
    def expand_query(self, query: str) -> str:
        # Core expansion logic only
        pass

Interface Boundaries

# Clear, minimal interfaces between autonomous modules
class RetrievalResult:
    """Clean interface for passing data between modules."""
    chunks: List[Dict]
    metadata: Dict
    source_counts: Dict[str, int]

class AutonomousRetriever:
    def retrieve(self, query: str) -> RetrievalResult:
        # Self-contained retrieval logic
        pass

Anti-Patterns to Avoid

Pseudo-Autonomy

  • Hidden dependencies through configuration files
  • Implicit coupling through shared databases
  • Runtime dependencies on external services

Over-Internalization

  • Duplicating complex logic unnecessarily
  • Reinventing standard libraries
  • Creating monolithic modules that should be split

Fragmentation

  • Too many tiny modules with unclear boundaries
  • Excessive interfaces between simple components
  • Lost coherence of overall system design

When to Apply

Ideal Scenarios

  • Production handover to new teams
  • Legacy system migration and simplification
  • Microservice extraction from monoliths
  • Independent deployment requirements

Consider Alternatives When

  • Significant code duplication would result
  • Complex shared state is essential
  • Performance overhead from internalization is prohibitive
  • Team is stable and dependency management is working well

Autonomous code modules represent a powerful pattern for creating maintainable, hand-offable systems, particularly valuable in production environments where simplicity and reliability are paramount over code reuse optimization.

See also