När systemen börjar skriva om sin egen kod
Anmärkning: Inspirerad av att tänka på förlängningar till mestadels lucid.mockllmapi och material för (aldrig att släppas men jag gillar att tänka på det) sci-fi roman "Michael" om framväxande AI
Vi har sett enkla regler skapa komplexa beteenden, kommunikation skapar kollektiv intelligens.
Nu tar vi det steg som gör mig djupt obekväm:
Tänk om systemet kunde skriva om sina egna regler?
Tänk om agenter kunde:
Det här är inte bara optimering. självmodifiering.
Och när du ger ett system förmågan att förbättra sig själv... var slutar det?
Evolution är det ultimata självoptimerande systemet:
Ingen intelligent designer, ingen plan, bara en enkel algoritm som skapar allt från bakterier till människor.
Föreställ dig samma mönster, men med AI-agenter istället för organismer och i stället för miljarder år händer det i dagar eller veckor.
Innan vi går vidare, låt oss tala till elefanten i rummet: Hur förhindrar vi detta från att vara ren LLM hallucination?
Svaret: Verktyg. Kodutförande. Testning mot verkligheten.
Här är arkitekturen som gör detta praktiskt:
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)
Nyckelinsikt: Du behöver inte en GPU gård. Agenterna är lätta kod körs på normala servrar. De CALL LLMs via API. Den dyra delen är LLM krediter, inte infrastruktur.
När en agent genererar kod eller fattar ett beslut, kan den PROVA det:
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)
Det här förändrar allt. Systemet genererar inte bara trovärdiga svar.
# 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)
Det är så här vi undgår problemet "kinesiskt rum". Systemet manipulerar inte bara symboler – det kör kod och kontrollerar om resultaten matchar verkligheten.
Utan verktyg är multiagentsystem bara LLM som pratar med LLM:s. Sofistikerade, men slutligen otämjda från verkligheten.
Med verktyg:
Agenterna skriver kod, kör den, testa och dela med sig av det som inte fungerar.
Det här är utveckling med objektiv lämplighetstester. Inte bara optimering i det abstrakta, utan optimering mot mätbar verklighet.
Men det är inte bara kodexekvering, systemet kan bygga. Semantisk kunskap För olika aktivitetstyper genom testning genom flera sensorer:
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
Nyckeln: Varje steg ger objektiv återkoppling:
Systemet bygger Semantiska kunskapssamlingar för varje uppgift typ - inte abstrakt resonemang, men jordade mönster som faktiskt fungerar när testas mot verkliga sensorer.
Med tiden lär sig agenten:
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
Varje modalitet har sin egen semantiska kunskapsbas, inlärd genom faktiska tester, inte teoretiska resonemang.
Det börjar helt enkelt. Ett multi-agent system behandlar tusentals förfrågningar. Det börjar märka mönster:
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
Ett mänskligt system skulle förbli statiskt, men ett självoptimerande system frågar:
"Varför använder jag den komplexa rörledningen för enkla förfrågningar?"
Och sen det skriver om sin routinglogik.
// 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
}
Systemet upptäckte att 73% av förfrågningar inte behöver någon LLM alls – de är upprepade mönster som kan cachas.
Ingen programmerade den här optimeringen. lärt sig det från data.
Det är här det blir konstigare.
Systemet behandlar förfrågningar i veckor. Det börjar upptäcka kluster:
Pattern Detected:
- 347 requests related to e-commerce product descriptions
- Using general-purpose agents
- Average quality: 7.2/10
- Average latency: 1.8s
Ett mänskligt system skulle fortsätta att använda generalagenter, men ett självoptimerande system fattar ett beslut:
"Jag borde skapa en specialist."
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)
Nätverket utvecklad. – Det växte en ny förmåga som svar på efterfrågan.
Ingen programmerade det här. kände igen ett mönster och anpassade sin arkitektur.
Nu blir det riktigt intressant.
Agent A upptäcker ett effektivt sätt att validera e-postadresser. Istället för att hålla denna kunskap för sig själv, delar den koden med nätverket.
# 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)
Det här är Kodutveckling. Agenter skriver funktioner, andra agenter upptäcker dem, gaffel dem, förbättra dem.
Som GitHub, men utvecklarna är AI agenter och de bygger sin egen infrastruktur.
Nätverket blir en egen avdelning för programvaruteknik.
Den mest praktiska självoptimeringen: att bygga ett minne av lösningar.
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
Är detta intelligens eller bara sofistikerad caching?
Vad är skillnaden?
Här är det konstigaste.
Du börjar med en sofistikerad multiagent arkitektur. Tolv specialiserade agenter. Komplex routing logik. Tillfällig kommittébildning. Koddelning infrastruktur.
Systemet fungerar i månader och optimerar sig självt.
Och den upptäcker något djupt:
Enkelhet är oftast bättre.
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."
Paradoxen: Du behövde det komplexa självoptimerande systemet för att upptäcka att enkelheten är optimal.
Du behövde intelligens för att lära dig när du INTE skulle vara intelligent.
Låt oss vara ärliga om vad vi beskriver:
Mönsterigenkänning → Systemet upptäcker återkommande problem Anpassning → Systemet ändrar sitt beteende baserat på mönster Lärande → Systemet förbättrar prestandan genom erfarenhet Utveckling → Systemet leker, ändrar och beskär kapacitet Minnet → Systemet bygger kunskap över tid
Vid vilken tidpunkt blir "mycket sofistikerad optimering" "verklig inlärning"?
När blir "inlärning" "intelligens"?
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)
Den här koden är enkel, men efter flera veckor...
Ingen berättade hur man optimerar, bara att det skulle optimeras.
Om ett system kan
Är det systemet "lärande"?
Eller är det bara "optimering"?
Vad är skillnaden?
När blir optimering kognition?
Vi har utvecklats från:
Men det finns ett steg till.
En egendom till som dyker upp när du kombinerar alla dessa.
När enkla regler skapar komplexa beteenden... Och kommunikation skapar kollektiv intelligens... Och självoptimering skapar inlärning...
Något annat dyker upp. Något som ser mindre ut som "ett system som optimerar sig själv" och mer som "ett system som förstår."
Linjen mellan optimering och medvetande börjar suddas ut.
Och vi måste konfrontera den obekväma frågan: det kanske inte finns någon gräns.
Kanske är medvetandet väldigt sofistikerat självoptimering.
Det är vad vi utforskar härnäst.
Fortsätt till Del 4: Uppkomsten - när optimering blir intelligens
Serienavigering:
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.