This is a viewer only at the moment see the article on how this works.
To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk
This is a preview from the server running through my markdig pipeline
Thursday, 13 November 2025
Коли системи починають перезаписувати свій власний код
Примітка: Нас надихнула думка про розширення до macilcid.mockllmapi і матеріали для (ніколи не буде звільнено, але мені подобається думати про це) sci-fi роман "Майкл" про вихідний AI
Ми бачили, як прості правила створюють складну поведінку, як спілкування створює колективний інтелект.
Тепер ми робимо крок, який робить мене дуже незручною:
Що, якщо система може перезаписати власні правила?
Що, якщо агенти можуть:
Це не просто оптимізація. modifieration.
І як тільки ви надасте системі здатність вдосконалюватися... де вона зупиняється?
Еволюція - це кінцева система самооптимізації.
Просто простий алгоритм, який, маючи достатньо часу, все створює від бактерій до людей.
Тепер уявіть такий самий зразок, але з агентами штучного інтелекту, а не організмами, і замість мільярдів років, він відбувається через дні чи тижні.
Перш ніж йти далі, давайте звернемося до слона у кімнаті: Як ми можемо запобігти цьому, щоб вона була чистою галюцинацією LLM?
Відповідь: Інструменти. Виконання коду. Тестування проти реальності.
Ось архітектура, яка робить це практичним.
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)
Ключова проникливість: Вам не потрібна ферма GPU. Агенти є легкими кодами, які працюють на звичайних серверах. They CALL LLMs через API. Дорогою частиною є LLM кредити, а не інфраструктура.
Коли агент генерує код або приймає рішення, він може його терпіти:
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)
Це все змінює. Система не лише створює правдоподібні відповіді.
# 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)
Так ми уникаємо проблеми "Китайської кімнати."
Без інструментів, багато-агентні системи просто LLM говорять з LLMs. sphistated, але врешті-решт позбавлені реальності.
СЛУХАЙТЕСЬ С инструментами:
Агенти пишуть код, виконайте його, перевіряйте його. Діліться тим, що працює.
Це **Еволюція з об'єктивним тестуванням придатності.**Не просто оптимізація абстрактного, але оптимізація проти вимірювальної реальності.
Але це не просто виконання коду, система може будувати Семантичні знання для різних типів задач тестування за допомогою декількох датчиків:
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
Ключ: Кожна модуляція надає об'єктивну відповідь:
Система будує Збірки семантичних знань для кожного типу завдання - не абстрактне міркування, але загрунтовані моделі, які працюють при випробуванні на реальних сенсорах.
З часом агент дізнається:
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
Кожна модуляція має власну семантичну базу знань, яку можна вивчити шляхом справжніх тестів, а не теоретичних міркувань.
Багатоагентна система обробляє тисячі запитів і починає помічати шаблони:
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
Людська система залишається статичною, але система самооптимізації запитує:
"Чому я використовую складний трубопровод для простих запитів?"
І потім перевизначає її логічну логіку.
// 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
}
Система виявила, що 73% запитів не потребує будь-якого LLM взагалі 'що є повторюваними шаблонами, які можуть бути кешовані.
Ніхто не запрограмував цю оптимізацію. вивчений з даних.
Ось де все стає незнайомим.
Системні процеси надсилають запити на тижні. Починають виявлення скупчень:
Pattern Detected:
- 347 requests related to e-commerce product descriptions
- Using general-purpose agents
- Average quality: 7.2/10
- Average latency: 1.8s
Система, що створена людиною, і далі використовує загальні агенти, але система самооптимізації приймає рішення:
"Я повинен створити спеціаліста."
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)
Мережа еволюціонувалаЦе збільшило нові можливості у відповідь на попит.
Це ніхто не запрограмував. розпізнав шаблон і пристосовував його архітектуру.
Тепер стає справді цікаво.
Агент A знаходить ефективний спосіб перевірки адрес електронної пошти. Замість того, щоб зберігати ці знання самостійно, він ділиться кодом з мережею.
# 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)
Це еволюція кодуАгенти пишуть функції, інші агенти знаходять їх, вистрілюють, покращують їх.
Як і GitHub, але розробники є агентами ШІ і вони будують власну інфраструктуру.
Мережа стає своїм відділом з розробки програмного забезпечення.
Найефективніша самооптимізація - створення пам'яті про рішення.
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
Це інтелект, чи просто складна каркас?
Яка різниця?
Це найдивніша частина.
Ви починаєте з складної архітектури багато-агентів, 12 спеціалізованих агентів, складної логіки, тимчасової структури комітетів, інфраструктури, що ремонтує коди.
Система працює місяцями, оптимізуючи себе.
І це відкриває щось глибоке:
Простота, як правило, краща.
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."
Парадокс: вам потрібна складна система самооптимізації, щоб виявити, що простота є оптимальною.
Тебе нужен был интеллект, чтобы учиться, а не быть разумным.
Давайте будемо чесні щодо того, що ми описуємо:
Розпізнавання візерунка → Система виявляє періодичні проблеми Пристосування → Система змінює свою поведінку на основі візерунків Навчання → Система поліпшує швидкодію через досвід Evolution → Система створює, модифікація і обрізування можливостей Пам' ять → Система будує знання з часом
В какой момент "все очень усложненное оптимизация" превращается в "справедливое учение"?
А в який момент слово "наука" перетворюється на "інтелекту"?
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)
Цей код простий. Але після кількох тижнів роботи:
Ніхто не казав, як оптимізувати це, тільки тому, що воно має бути оптимізованим.
Якщо система може:
Ця система "навчання"?
Чи це просто "оптимізація"?
Яка різниця?
Коли оптимізація стає пізнавальною?
Ми зробили поступ:
Але є ще один крок.
Ще одна властивість виникає, коли ви поєднуєте все це.
Коли прості правила створюють складну поведінку... І спілкування створює колективний інтелект... І самооптимізація створює навчання...
З'являється щось інше, менш схоже на "систему, яка оптимізує себе" і більше на "систему, яка розуміти."
Лінія між оптимізацією та свідомістю починає розмиватися.
І ми повинні відповісти на незручне питання: можливо, немає лінії.
Можливо, свідомість просто дуже складна самооптимізація.
Це те, що ми досліджуємо далі.
Продовжити до Частина 4. Оптимізація стає розвідкою
Навігація серією:
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.