Lorsque les systèmes commencent à réécrire leur propre code

Note: Inspiré par l’idée d’extensions à la plupartlucid.mockllmapi et du matériel pour le (never to be released but I like to think about it.

L'étape terrifiante

Nous avons vu que des règles simples créent un comportement complexe.

Maintenant, nous prenons le pas qui me rend profondément inconfortable:

Que se passerait-il si le système pouvait réécrire ses propres règles?

Que se passerait-il si les agents pouvaient

• Inspecter leur propre rendement
• Modifier leur propre logique de décision
• Créer de nouveaux spécialistes dynamiquement
• Voies de prune inefficaces
• Créer une mémoire partagée de ce qui fonctionne

Ce n’est pas seulement une optimisation, mais c’est auto-modification.

Et une fois que vous donnez à un système la capacité d’améliorer lui-même... où se termine-t-il?

La métaphore de l'évolution

L’évolution est le système d’optimisation ultime.

1. Variation - Les mutations aléatoires créent différentes stratégies
2. Sélection - Les stratégies réussies survivent et se reproduisent
3. Inhérence - Des traits réussis passent à la prochaine génération
4. Iteration - Répéter pour des milliards de générations

Aucun concepteur intelligent.0 Aucun plan.1 Un algorithme simple qui, avec suffisamment de temps.3 crée tout, depuis les bactéries jusqu’aux humains.4

Imaginez maintenant ce même modèle, mais avec des agents AI au lieu d’organismes.

Les outils et l’essai de la réalité

Avant d’aller plus loin, laissez-nous dire à l’éléphant de la salle : Comment éviter que ce ne soit une hallucination pure de LLM?

La réponse: Outils. Exécution du codeM SK1 Essai contre la réalité.

Voici l’architecture qui en fait une pratique.

Architecture des nodes (Nous n'avons besoin d'une ferme GPU!)

Your Server(s):
  ┌─────────────────────────────────────┐
  │  Node 1: Routing Agent              │
  │  - Lightweight code (Node.js/Python)│
  │  - Makes decisions                  │
  │  - Calls LLM APIs when needed       │
  │  - Executes code to test ideas      │
  └─────────────────────────────────────┘

  ┌─────────────────────────────────────┐
  │  Node 2: Validation Agent           │
  │  - Runs tests against real data     │
  │  - Executes validation code         │
  │  - Calls LLM for complex checks     │
  └─────────────────────────────────────┘

  ┌─────────────────────────────────────┐
  │  Node 3: Specialist Agent           │
  │  - Domain-specific logic            │
  │  - Code execution for that domain   │
  │  - Calls specialized LLM prompts    │
  └─────────────────────────────────────┘

All nodes call → [OpenAI API / Anthropic API / Local LLM API]
                 (This is where the cost is: API credits, not hardware)

Perspectives clés: Vous n’avez pas besoin de GPU farm.

Outils: La vérification de la réalité

Lorsque l’agent génère un code ou prend une décision, il peut le TESTer.

class Agent:
    def solve_problem(self, problem):
        # Agent asks LLM to generate solution code
        solution_code = self.llm_generate(
            f"Write Python code to solve: {problem}"
        )

        # HERE'S THE KEY: Execute the code and see if it works
        try:
            result = self.execute_code(solution_code, test_inputs)
            if self.validate_result(result):
                # It works! Save this solution
                self.cache_solution(problem, solution_code)
                return result
            else:
                # Failed validation, try different approach
                return self.solve_problem_alternative(problem)
        except Exception as e:
            # Code failed to execute
            # Ask LLM to fix it based on the actual error
            fixed_code = self.llm_fix(solution_code, error=str(e))
            return self.execute_code(fixed_code, test_inputs)

Cela change tout. Le système n’est pas seulement de produire des réponses plausibles, mais aussi d’échoirantes.

1. Gérer le code réel
2. En exécutant
3. Évaluation des résultats par rapport à la réalité
4. Apprentissage à partir des échecs
5. Iterer jusqu'à ce qu'il fonctionne

Exemple: Validation contre la réalité objective

# Agent 1 generates a data processing function
code = llm.generate("Write code to parse CSV and calculate averages")

# Agent 2 tests it against REAL data
test_result = execute_code(code, real_csv_file)

# Did it actually work? Not "does it sound right?" but "does it work?"
if test_result.success and test_result.output_matches_expected:
    network.accept_solution(code)
else:
    # Actual error: "TypeError: cannot convert string to float"
    # Now we have OBJECTIVE feedback, not subjective judgment
    network.request_fix(code, test_result.error)

C’est ainsi que nous évacuons le problème de la salle chinoise. Le système ne manipule pas seulement les symboles, mais il exécute aussi le code et vérifie si les résultats correspondent à la réalité.

Pourquoi cela est important pour l'émergence

Sans outils, multi- les systèmes d’agent sont simplement des LLM qui communiquent avec ceux-ci.

AVEC les outils:

• Rétroaction objective: Le code fonctionne ou non't
• Amélioration mesurable: Le taux de réussite est de 60% → ♫ ♫ 85% ♫
• Apprentissage réel: Les solutions qui fonctionnent sont cachées et réutilisées
• Base de données sur la réalité: Ne peut-on pas halluciner votre passage par un échec d’un test?

Les agents écrivent le code. L'exécutent . Il l'essaie . Il y est corrigé

Il s'agit de évolution avec des tests d'aptitude objectifs. Non seulement l’optimisation dans l’abstract, mais aussi l’optique contre la réalité mesurable.

Multimodal Reality Testing: Au-delà du code

Mais ce n’est pas seulement l’exécution de code. Le système peut construire connaissance sémantique pour différents types de tâches en testant à travers plusieurs capteurs:

class MultimodalAgent:
    def __init__(self):
        self.semantic_knowledge = {
            'text_tasks': SemanticCache(),
            'vision_tasks': SemanticCache(),
            'audio_tasks': SemanticCache(),
            'code_tasks': SemanticCache()
        }

    def solve_task(self, task):
        task_type = self.classify_task(task)

        # Check semantic knowledge for similar past solutions
        similar = self.semantic_knowledge[task_type].find_similar(task)
        if similar:
            return self.adapt_solution(similar, task)

        # Generate new solution
        solution = self.generate_solution(task)

        # Test against reality using appropriate sensor
        if task_type == 'vision_tasks':
            # Generate image, test with vision API
            result = self.vision_api.analyze(solution)
            passes = self.validate_vision_output(result, task.requirements)

        elif task_type == 'audio_tasks':
            # Generate audio, test with speech recognition
            transcript = self.speech_to_text(solution)
            passes = self.validate_audio_output(transcript, task.requirements)

        elif task_type == 'code_tasks':
            # Execute code, check actual results
            result = self.execute_code(solution)
            passes = self.validate_code_output(result, task.test_cases)

        elif task_type == 'text_tasks':
            # Use NLU to verify semantic meaning
            understanding = self.nlu_api.analyze(solution)
            passes = self.validate_text_output(understanding, task.intent)

        # Learn from results
        if passes:
            self.semantic_knowledge[task_type].store(task, solution, result)

        return solution, passes

La clé: Chaque modalité fournit une rétroaction objective:

• Vision: L'image générée contient-elle réellement un chat?
• Audio: Est-ce que le discours correspond à la transcription?
• Code: Exécute-t-il sans erreurs? (La durée de l'exécution dit oui/noM SK3
• Texte: Réponse-t-elle à la question?

Le système construit collectes de connaissances sémantiques pour chaque type de tâche - non des raisonnements abstraits , mais des modèles fondés qui fonctionnent effectivement lorsqu'ils sont testés contre les capteurs réels.

Self-Optimisation par modalité

Au fil du temps, l’agent apprend:

Text tasks:
  "For summarization, approach X works 94% of the time"
  "For translation, approach Y works 89% of the time"
  → Semantic knowledge about what works for text

Vision tasks:
  "For object detection, model A is better"
  "For style transfer, model B is better"
  → Semantic knowledge about what works for vision

Code tasks:
  "For parsing, regex approach fails 30% of the time"
  "For parsing, AST approach works 97% of the time"
  → Semantic knowledge about what works for code

Chaque modalité possède sa propre base de connaissances sémantiques.

Reconnaissance du modèle → Adaptation

Il débute simplement. Un système multiménétral-agent traite des milliers de demandesM SK2 Il commence à noter les patrons :

After 1000 requests:
- 73% are simple queries that one agent handles fine
- 19% need two agents (generation + validation)
- 6% need complex committees
- 2% are truly novel and need the full pipeline

Un système conçu par un être humain demeurerait statique, mais un système d’optimisation autonome demande :

" Pourquoi utilise-je le pipeline complexe pour des demandes simples?

Et ensuite, c'est rédige sa logique de routage.

La première optimisation: Routage intelligent

// Week 1: Hard-coded routing (human designed)
function route(request) {
  return complexPipeline(request);  // Everything uses full pipeline
}

// Week 4: System optimizes itself based on data
function route(request) {
  const complexity = analyze(request);
  const historicalData = checkCache(request);

  if (historicalData.cacheHit) {
    return cachedSolution;  // 73% of requests!
  }

  if (complexity < 3) {
    return fastSingleAgent(request);  // 19% of requests
  }

  if (complexity < 7) {
    return twoAgentValidation(request);  // 6% of requests
  }

  return fullCommittee(request);  // 2% of requests
}

Le système a découvert que 73% des requêtes ne nécessitent pas de LLM à l’égard d’aucune demande ' ils sont des modèles répétés qui peuvent être cachés

Personne n’a programmé cette optimisation. Le système on l'a appris à partir des données.

Spécialiste de frai dynamique

Here's where it gets stranger.

Le système traite les demandes pendant des semaines. Il commence à détecter les grappes:

Pattern Detected:
- 347 requests related to e-commerce product descriptions
- Using general-purpose agents
- Average quality: 7.2/10
- Average latency: 1.8s

Un système conçu par un être humain continuerait d’utiliser des agents généraux mais un système optimisant lui-même prend une décision.

"Je devais donner naissance à un spécialiste ."

DAY 1:  [General Agent A] [General Agent B] [General Agent C]

DAY 30: Pattern detected → System spawns specialist
        [General Agent A] [General Agent B] [General Agent C]
        [E-commerce Specialist] ← New agent, trained on e-commerce patterns

DAY 60: Specialist proves effective
        Routing logic updated automatically
        E-commerce requests → E-commerce Specialist (quality: 9.1/10, latency: 0.9s)

Le réseau a évolué. Une nouvelle capacité s’est développée en réponse à la demande

Personne ne l’a programmé. Le système a reconnu un modèle et adapté son architecture.

Collective Code Sharing: GitHub for Neurons

Maintenant il devient vraiment intéressant.

Agent A découvre une façon efficace de valider les adresses électroniques. Au lieu de garder ce savoir à lui-même, il partage le code avec le réseauM SK2

# Agent A writes code for email validation
def validate_email_efficient(email):
    # Some clever regex or logic
    return is_valid

# Agent A publishes to shared code repository
network.publish_code("validate_email_efficient", validate_email_efficient)

# Agent B discovers this code
available_functions = network.browse_code_library()
# Agent B sees "validate_email_efficient" with high rating
# Agent B imports and uses it

# Agent C forks it and improves it
def validate_email_v2(email):
    # Agent C's enhancement
    return improved_validation

network.publish_code("validate_email_v2", validate_email_v2)

Il s'agit de Évolution du code. Les agents écrivent les fonctions, d'autres agents les découvrentM SK2 les forcissentMST3 les améliorentMTS4

Comme GitHub, mais les développeurs sont des agents AI et ils construisent leur propre infrastructure.

Le réseau devient son propre département d’ingénierie logicielle.

Mémoire RAG: Apprentissage de l’histoire

Les solutions les plus pratiques-optimisationM SK1 mémoire de construction des solutions.

Request 1: "Generate a product description for wireless headphones"
  → Full LLM pipeline (expensive, slow)
  → Store solution in vector database

Request 847: "Generate a product description for wireless earbuds"
  → Vector search finds similar past solution
  → Adapt cached solution (cheap, fast)
  → No LLM needed!

After 10,000 requests:
- 89% cache hit rate
- 11% genuinely novel requests that need LLMs
- System effectively "learned" from experience

Est-ce cette intelligence? ou simplement un caching sophistiqué?

Quelle est la différence?

Le paradoxe de l'élevage

Voici ce qui est le plus étrange :

Vous commencerez par une architecture multilatérale sophistiquée-agents1Douze agents spécialisésM SK2 Logique de routage complexe. Formation d’un comité temporaire . CodeMSC5infrastructure de partageMNK6

Le système fonctionne pendant des mois, optimisant lui-même.

Et il découvre quelque chose de profond.

La simplicité est habituellement meilleure.

Month 1:
- 12 specialists
- Complex routing logic
- Committee formation for 15% of requests
- Average cost: $0.05/request

Month 6:
- 5 specialists (system pruned 7 as unnecessary)
- Simple routing: cache check → fast model → quality model if needed
- Committees formed for only 3% of requests
- Average cost: $0.003/request
- Quality: SAME OR BETTER

The system's report:
"After analyzing 50,000 requests, I've determined that:
 - 89% can be handled by cache
 - 7% need one LLM call
 - 3% need committees
 - 1% are truly novel

 I've optimized away unnecessary complexity.
 The most sophisticated self-organizing network
 eventually learns to be simple."

Le paradoxe: Vous avez besoin d’un système d’optimisation complexe- pour découvrir que la simplicité est optimale .

Vous avez besoin d’intelligence pour apprendre quand ne pas être intelligent.

L'incertitude de la frontière

Nous devons être honnêtes quant à ce que nous décrivons

Reconnaissance du modèle → Le système détecte des problèmes récurrents Adaptation → Le système modifie son comportement en fonction de patrons Apprentissage → Le système améliore le rendement grâce à l'expérience Évolution → Le système engendreM SK1 modifie , et prune les capacités Mémoire → Le système construit les connaissances au fil du temps

À quel point "l'optimisation très sophistiquéeM SK1 devient-elle "apprentissage réel"?

À quel point "learning" devient-il "intelligenceM SK3

Exemple concrète: L’autorouter- Routeur améliorant

class SelfOptimizingRouter:
    def __init__(self):
        self.routes = {}  # Start empty
        self.performance_data = []
        self.specialists = [DefaultAgent()]

    def handle_request(self, request):
        # Try cache first
        cached = self.check_cache(request)
        if cached:
            return cached

        # Select agent based on learned patterns
        agent = self.select_agent(request)
        result = agent.process(request)

        # Learn from this interaction
        self.record_performance(request, agent, result)

        # Periodically optimize
        if len(self.performance_data) % 1000 == 0:
            self.optimize()

        return result

    def optimize(self):
        """System rewrites its own logic"""

        # Detect patterns
        patterns = self.analyze_patterns(self.performance_data)

        # Should we spawn a specialist?
        for pattern in patterns:
            if pattern.frequency > 100 and pattern.has_specialist == False:
                print(f"Spawning specialist for {pattern.type}")
                self.spawn_specialist(pattern)

        # Should we prune an underutilized agent?
        for agent in self.specialists:
            if agent.usage < 1% and agent.quality_score < 7.0:
                print(f"Pruning ineffective agent {agent.name}")
                self.specialists.remove(agent)

        # Rewrite routing logic based on data
        self.routes = self.learn_optimal_routes(self.performance_data)

Ce code est simple. Mais après avoir été utilisé pendant des semaines, ilM SK2

• Établit ses propres spécialistes
• Agents inefficaces des prunes
• Rédige sa propre logique de routage
• Créer un cache de solutions

Personne ne l’a dit comment optimiser.

La question qui me frappe

Si un système peut:

• Reconnaissance des patrons dans les données
• Modifier son propre comportement en fonction de ces patrons
• Construire la mémoire de ce qui fonctionne
• Évoluer sa propre architecture
• Découvrez que la simplicité est souvent optimale

Est-ce que le système "learning"?

Ou est-ce simplement "optimisation"?

Quelle est la différence?

Quand l’optimisation devient une connaissance?

Où cela va

Nous avons progressé par rapport à l’année précédente.

• Règles simples → comportement complexe (partie 1)
• Communication → Renseignements collectifs ( Partie 2)
• Automne -modification → Apprentissage

Mais il y a encore un pas à faire.

Une autre propriété qui apparaît lorsque vous combinez tous ces éléments.

Lorsque des règles simples créent un comportement complexe... La communication crée une intelligence collective... L’auto-optimisation crée l’apprentissage

Un autre système apparaît, soit ., soit quelque chose qui ressemble moins à ", soit un système qui se optimise lui-même, soit à ", mais plutôt à |", soit Il s'agit là d'une affaire qui n'a pas été réglée par la Cour.."

La ligne entre l'optimisation et la conscience commence à s'éclaircir.

Et nous devons faire face à la question incommode: peut-être qu’il n’y a pas de ligne .

Peut-être que la conscience est simplement un soi très sophistiqué

C’est ce que nous étudierons prochainement.

Continuer à Partie 4: L’émergence - Quand l’optimisation devient une intelligence

Navigation de série:

• Partie 1: Règles simples , comportement complexe - La fondation
• Partie 2: Intelligence collective - La communication transforme tout
• Partie 3: Automne -Optimisation ← Vous êtes ici
• Partie 4: L’émergence - Lorsque l’optimisation devient une intelligence
• Partie 5: Evolution - De l’optimisation aux guildes et à la culture
• Partie 6: Consensus mondial - Évolution dirigée et connaissance planétaire
• Partie 7: La vraie chose! - En fait, en la construisant et en l’observant évoluer
• Partie 8: Outils tout au long de la route - La trousse d'outils d'optimisation de l'auto
• Partie 9:Self-Outils d'Healing - Ligneage-aware pruning and recovery