# AI som disciplinerad programvara: Jag tror att jag bör lämna Evolverande AI Workflows och Drive to Simplicity > **Tänk att betala mig för att göra det här till en riktig produkt?** Släpp en rad till mig. [Scott.galloway+dse@gmail.com](mailto:scott.galloway+dse@gmail.com) ## Tanken som satte i gång allting **Varför kör en mänsklig hjärna i realtid kognition på 20 watt – medan våra bästa AI-modeller behöver megawatt bara för att prata om frukost?** Moderna LLMs syftar till att vara som en massiv cortex – tons of memory, tons of performance, men **Ensam**. För att utföra uppgifter en människa skulle göra utan ansträngning, de tuggar genom kilowatt av makt med hjälp av tiotals gigabyte minne. Det kan inte vara rätt om hjärnan fungerar på 20 watt. Här är vad de saknar: Hjärnan är inte en enda plump av grå gelé – det är **massor av specialiserade delsystem** hantering av syn, rörelse, minne lagring (i lager!), alla samordnade av den cortex. LLMs gör inte det. De är som en massiv tänkande motor fastskruvad på dum infrastruktur. Deras lagring anpassar sig inte. De bygger inte specialiserade delsystem. **De är ofullständiga.** Jag brukade vara psykolog, så jag tänker på sånt här och här är den grundläggande principen jag byggde DiSE runt: **"Tung kognition stabiliserar komplex kognition."** Din hjärna kompilerar inte om hur man går varje gång man tar ett steg. Den avlastar det till snabba, billiga, automatiska delsystem. Den stabiliteten frigör den dyra prefrontala cortexen för att hantera nya problem. DiSE gör samma sak: den ersätter dyra LLM-samtal med billiga Python-skript, frigör gränsmodeller för att arbeta på genuint svåra problem. Systemet stabiliserar sig genom att bli enklare, inte mer komplicerat. ## Hiss pitch **Tänk om ditt AI arbetsflöde insåg att det inte behövde AI och förvandlade sig till ett Python-skript?** DiSE gör det. Det bygger arbetsflöden som testbara verktyg lagrade i ett RAG- substrat. När mönster blir klara, ersätter det LLM- samtal med omedelbar Python. När du behöver fler funktioner, bygger det bara vad som behövs – prediktabelt, testavärt. När verktygen driver, utvecklas det bort från problem innan du märker. En liten Sentinel modell (1B params) hanterar all tråkig hushållning för pennies. Anslut en gräns LLM kort för att optimera allt, sedan koppla bort och köra billigt för alltid. Det är AI som blir effektivare ju längre det körs – vilket är exakt hur produktionssystem ska fungera. [TOC] ## Inledning De flesta AI-system idag är uppbyggda som mina första PHP-skript circa 2003—fragil, otestabel, och när de går sönder, har du ungefär lika stor chans att felsöka dem som att förklara Brexit för en förvirrad amerikan. När de misslyckas, kan du inte säga varför. När de driver (och de *kommer att*), du märker inte förrän produktionen brinner. När du behöver för att förbättra dem? Tillbaka till ruta ett. Digital Sisyfos. Det finns ett bättre sätt. Tänk om varje AI-verktyg byggdes som riktig programvara från dag ett – med tester, kontrakt, specifikationer, och ansvarighet bakas in? Inte bultade på när revisorerna kommer knacka. Så här ska AI-teknik fungera när den växer upp. ## Innehållsförteckning ## Problemet: AI är fortfarande vilda västern Låt mig måla en bild med ett diagram, för jag är tjusig så där: ```mermaid graph TD A[Traditional AI Development] --> B[Write Prompt] B --> C[Hope for Best] C --> D{Does it work?} D -->|Sometimes| E[Ship It™] D -->|Usually| F[Tweak Prompt] F --> C E --> G[Production] G --> H[Silent Drift] H --> I[Everything's Fine...] I --> J[Until It's Not] J --> K[Panic] K --> L[No Audit Trail] L --> M[Start Again] style K stroke:#f96 style L stroke:#f96 style M stroke:#f96 ``` Det är så de flesta AI-system byggs. ## Vad gör detta annorlunda? Här är hur en genererad AI "verktyg" ser ut i mitt system – direkt från CLI, ingen rök och speglar: ![Verktygskatalogstruktur](tools_folder.png) ``` flag_potential_violations_base/ ├─ flag_potential_violations_base_plan.txt ← generation plan ├─ flag_potential_violations_based_on_predefined_thresholds.feature ← BDD spec ├─ interface.json ← declared IO contract ├─ specification.md ← intent & description ├─ main.py ← implementation (generated) ├─ test_main.py ← unit + BDD tests ├─ locust_flag_potential_violations_base.py ← load/performance tests └─ node_runtime.py ← runtime integration (a mock of it's tool call for testing use) ``` Det är inget mockup jag gjorde i Figma för att imponera på dig. *faktiskt genererad utmatning*. Varje fil. Från AI själv. **Varje nod är:** Materiella anläggningstillgångar | ------------- | ----------------------------------------- | på provbara på enhet och BDD-tester finns från födseln Kan alltid bevisa varför det uppförde sig som det gjorde Kan förbättras med hjälp av fitness-jämförelser till Benchmarkable och Perf / belastningstester ingår "Återanvändbar" Blir en del av procedurminnet Det här är inte snabbteknik. **AI som disciplinerad programvara**—den typ som man faktiskt kan lita på i produktionen utan att kontrollera Slack var femte minut. Och här är den riktigt smarta biten: **Det är bara Python-manus.**. Rätta, tråkiga, testerbara Python-skript. Men de lever i ett RAG-baserat evolutionärt substrat där varje verktygs specifikation blir en del av dess identitet. Systemet är dynamiskt kompatibelt från arbetsflödesnivån ner till små verktygsskript. **Tänk om ditt AI-drivna arbetsflöde bestämde att det verkligen inte behövde AI?** Det händer. Ett arbetsflöde körs några gånger, mönstret blir tydligt, och systemet inser "detta är bara data transformation, varför kallar jag en LLM?" Så det genererar en ren Python skript. Nästa gång du gör samma begäran? **INSTANT**Inga API-samtal, inga polletter, ingen latens, bara tråkiga, snabba, förutsägbara Python. Kanske behöver arbetsflödet en extra valideringskontroll. **ENDAST tillsatt vid behov**. Systemet bygger just dessa nya delar som verktyg – kanske baseras på befintliga, kanske helt nya – men alltid förutsägbart, alltid testabelt. Ingen över-engineering. Ingen "bara i fall" kod. Bara den minsta livskraftiga verktyg för att lösa det verkliga problemet du står inför just nu. Uppgradera ett verktyg (på ett guidat, tätt testbart sätt) och varje arbetsflöde som använder det omedelbart fördelar. Ingen omfördelning. Ingen kaskad av ändringar. Bara bättre verktyg, automatiskt tillgängliga för allt. ## Hur det faktiskt fungerar: Formeln Här är den bit ingen annan gör. "AI" som bygger verktyg är inte en enda modell – det är en **team av specialiserade LLMs**, var och en med noggrant inställda starter uppmaningar, arbetar som en riktig mjukvaruteknik team. **Forge- arbetsflödet:** 1. **Detektion av specialfall** – "Är detta en gemensam uppgift som vi redan hanterar?" (I framtiden kommer CLI att mutera för att lägga till dessa gemensamma mönster automatiskt) 2. **Uppgiftsnedbrytning** – En ganska bra LLM (lokalt använder jag en 7B modell, inget spektakulärt) bryter ner prompten: "Hur kan jag bryta ner detta? Vilka verktyg finns för varje del?" 3. **Parallell och sekventiell planering** – Bestämmer vad som kan köras i parallell vs sekvens 4. **Genererar verktygssamtal** – Utfall `call_tool("tool_name", prompt)` - detta är NYCKEL till kompatibilitet 5. **RAG-uppslagning** – Finns "tool_name"? Om ja, använd den. Om nej, blir prompten instruktionen till nästa Forge instans 6. **Rekursiv nedbrytning** – Att nästa Forge gör samma uppdelning, hela vägen ner till små, enhet-testbara steg **Det här är genombrottet.** Uppgifter bryts ner till atomisk verksamhet – som jag lärde mig att göra under 30 år bygga programvara. Små lokala LLMs är **tillräckligt bra** för kodgenerering när uppgiften är liten och tillsyningsmannen ger detaljerade genomförandeinstruktioner. Här är ett verkligt exempel på hur dessa instruktioner ser ut. Tillsyningsmannen säger inte bara "skriv en schemaläggare" – det ger: - Exakt algoritm (topologisk typ + kritisk vägmetod) - Datastrukturer med typdefinitioner - Funktionssignaturer med in- och utgångsspecifikationer - Prestandabegränsningar (O(V+E) tid, O(V) utrymme) - Säkerhetsgränser (max 1000 uppgifter) - Kompletta testfall med förväntade in- och utgångar - JSON in- och utdataformat En 7B-modell kan skriva fast kod från den spec eftersom det inte uppmanas att designa någonting – bara genomföra en detaljerad ritning. **Det är** varför små modeller arbetar för kodgenerering i detta system. När Forge kör arbetsflödet är det fortfarande dynamiskt kompatibelt via RAG. Om ett nytt, bättre verktyg visas som klarar samma tester? Det används automatiskt. Och kom ihåg nästa gång. Låt mig visa arkitekturen med ett annat diagram, för tydligen kan jag inte låta bli: ```mermaid graph TB subgraph "RAG-Based Tool Substrate" A[Semantic Intent] --> B[Plan Generation] B --> C[Contract Definition] C --> D[Code Generation] D --> E[Test Generation] E --> F[Fitness Evaluation] F --> G{Passes?} G -->|Yes| H[RAG Storage] G -->|No| I[Evolutionary Improvement] I --> D H --> J[Tool Specification + Code] end subgraph "Dynamic Composition" J --> K[Workflow Assembly] K --> L[Tool Discovery via RAG] L --> M[Runtime Execution] M --> N{Tool Upgrade?} N -->|Yes| H N -->|No| O[Continue] end style H stroke:#9f6 style J stroke:#9f6 style L stroke:#6cf ``` **RAG-substratet är den hemliga såsen.** Varje verktygs specifikation – dess kontrakt, dess syfte, dess träningsresultat – blir sökbar identitet. När du behöver ett verktyg, finner systemet den bästa matchningen. När du uppgraderar ett verktyg, varje arbetsflöde som använder det automatiskt får förbättring. Det är som att ha en självorganiserande verktygslåda som blir smartare med tiden. ### Minnesproblemet: Sluta lära om hur man kör **Normala AIs använder den "snabba studien" tillvägagångssätt.** Varje gång de tar itu med en uppgift, de är kramp för en examen-läsa alla sammanhang, räkna ut problemet, generera en lösning. Det är som att behöva göra om dina körlektioner varje gång du får i en bil. *provning* (även om det är ett annat problem med AI-lösningar), din faktiska *lektioner*. Tänk dig att förklara vad en koppling gör varje morgon innan du pendlar. Modern kod KLIs har en partiell lösning: titta på din projektkatalog för CLAUDE.md, eller ett gäng udda markdown-dokument utspridda runt. Dessa filer? Det är så bra som de kan göra med minnet. Det är som att lämna Post-It anteckningar för dig själv, förutom att du måste läsa dem alla varje gång innan du gör något. **DiSE minns faktiskt.** När den löser ett problem lagrar den lösningen som ett testat, dokumenterat verktyg i RAG-substratet. Nästa gång? Den använder den bara. Ingen återinlärning. Ingen ominställning. Ingen "låt mig läsa alla dina sammanhangsfiler igen." Den körde denna rutt igår, den vet var svängarna är. Detta hänger direkt samman med de begrepp som jag har tjatat om i min semantiska intelligensserie – specifikt: - **[Del 8: Verktyg hela vägen ner](/blog/semanticintelligence-part8)** för självoptimerande verktygssatser - **[Del 9: Självläkande verktyg](/blog/semanticintelligence-part9)** för lineage-medveten utveckling - **[Del 10: DiSE-köket](/blog/semanticintelligence-part10)** för arbetsflödessammansättning Varje nod har redan: - En specifikation (så att du vet vad det är *medelvärde* för att göra) - Ett kontrakt (så du vet vad det *faktiskt* gör) - Körbar kod (söker, jag vet) - Tester som måste klaras (ingen av dessa "vi ska lägga till tester senare" nonsens) - En belastning test sele (eftersom "det fungerade på min laptop" är inte en distributionsstrategi) - En anledning till befintliga (ingen zombie kod hemsöker din kodbas) Det är substratet som behövs för att skala AI ansvarsfullt – inte fler polletter, inte större modeller, inte en annan blodig ChatGPT omslag. ## Omfattningen: Verktyg är valfria, LLM är valfria Här är det som verkligen betyder något: **verktyg och LLMs är valfria**. Systemet fartyg med en standard LLM, och det kan lösa allt från grunden om det måste. Men verktyg ger det ett försprång. **Tänk på verktyg som biblioteksböcker.** Vissa är JSON- filer (specialistiska uppmaningar till resonemang, kodning, analys – själva muterbara och utlösbara). Många är Python-skript (statisk analys, scikit-lär sig för ML, neural översättning – specialiserade förmågor redo att använda). En del har till och med mallar (för kodgenerering, vilket ger systemet en stramare loop när nya verktyg skapas). Ett verktyg installerar bokstavligen Node.js och använder mermaid.js för diagramåtergivning. En del är datalager systemet kan fråga. En del är kodfixar för vanliga mönster. **Alla av dem bor i RAG. Alla av dem är tillgängliga för alla arbetsflöden.** Det gör du inte. *behov* biblioteket. Systemet kan räkna ut saker på egen hand. Men att ha 200 verktyg är som att ha 200 böcker som förklarar "här är hur man gör X effektivt." När det behöver tolka JSON, det behöver inte härleda JSON tolkning från första principer-det har ett verktyg. När det behöver maskininlärning, det behöver inte genomföra lutning nedstigning-det kallar scikit-lära. När det behöver generera diagram, det använder sjöjungfrun verktyg som installerar sina egna beroenden. Systemet kan: - **Använd flera LLM: er** - Eller bara en. Eller ingen för vissa uppgifter när de destilleras till Python - **Integrera specialverktyg** - Eller inte. Det kan bygga dem om det behövs. - **Arbeta med MCP-verktyg** – Fartyg med cirka 200 verktyg inklusive ~10 MCP integrationer. Ett verktyg kan upptäcka nya MCP tjänster och linda in dem. Men du kan börja med noll verktyg och det skulle bootstrap sig - **Bygga sig själv från grunden** – Med tanke på tillräckligt med tid och beräkna. Verktyg betyder bara att det inte behöver ```mermaid graph LR subgraph "Tool Ecosystem" A[Python Scripts] --> E[RAG Substrate] B[LLM Specialists] --> E C[External APIs] --> E D[MCP Tools] --> E end E --> F[Dynamic Discovery] F --> G[Workflow Composition] G --> H[Execution] H --> I[Feedback & Learning] I --> E style E stroke:#6cf style F stroke:#9f6 ``` Och eftersom allt lagras i RAG-substratet med semantisk sökning, kan du bygga **sammankopplade nätverk av system** som delar verktyg och lärdomar. Ett system räknar ut hur man hanterar en knepig datatransformation? Varje uppkopplat system vet nu om det. Systemet optimeras baserat på **Påfört tryck**: - **Prestandatryck?** Generera snabbare varianter, testa dem, hålla vinnarna - **Feltryck?** Bygg valideringsverktyg, lägg till kontroller, förbättra robustheten - **Kostnadstryck?** Ersätt LLM-samtal med Python-skript, cache aggressivt, använd billigare modeller Det fungerar bara när det behövs. Ingen för tidig optimering. Ingen "vi kan behöva denna en dag" kod. Bara riktade förbättringar som svar på faktiska, uppmätta problem. Det är som att ha en kupa sinne för ditt verktyg, förutom mindre läskig och mer auditable. ### Nätverkseffekten: Uppkopplad intelligens Här är där det får ordentligt sci-fi (men på ett bra sätt). Flera instanser kan dela ett RAG substrat, skapa en **Sammanhängande nätverk av system** som kollektivt lär sig och förbättrar ```mermaid graph TB subgraph "System A" A1[Workflow] --> A2[Tool Discovery] A2 --> A3[RAG Substrate] end subgraph "System B" B1[Workflow] --> B2[Tool Discovery] B2 --> B3[RAG Substrate] end subgraph "System C" C1[Workflow] --> C2[Tool Discovery] C2 --> C3[RAG Substrate] end A3 <--> D[Shared Tool Repository] B3 <--> D C3 <--> D D --> E[Collective Learning] E --> F[Improved Tools] F --> D style D stroke:#6cf style E stroke:#9f6 ``` **Vad detta innebär i praktiken:** - System A skapar ett briljant datavalideringsverktyg → Alla får det - System B upptäcker ett snabbare sätt att tolka loggar → Alla fördelar - System C räknar ut hur man integrerar ett nytt API → Kunskapen förökar sig Varje system upprätthåller sina egna arbetsflöden och specialiseringar, men de bidrar alla till och drar nytta av ett gemensamt förråd av testade, validerade, fitness-märkta verktyg. Det är samarbete AI-teknik utan kaos. Varje bidrag är testad, versions, och auditable. Ingen kan oavsiktligt bryta alla andras saker (titta på dig, node_moduler). ### Adaptive Intelligence: Billiga som standard, Smart när det behövs Här är en annan smart bit: systemet behöver inte dyra gränsmodeller som körs 24/7. **Examinera arbetsflöden** Inflygning där - **Väktaren** (en mycket snabb 1B-klass LLM) hanterar alla vardagliga städning - routing, klassificering, enkla beslut - **Billiga, snabba modeller** hantera rutinarbete (din lokala Llama, Phi, eller liknande) - **Mellannivåmodeller** ta itu med måttlig komplexitet (GPT-3.5, Claude Haiku) - **Gränsmodeller** bara bli kallad för verkligt svåra problem (GPT-4, Claude Opus) ```mermaid graph TD A[Task Arrives] --> B[Sentinel: 1B LLM] B --> C{Classify Complexity} C -->|Housekeeping| D[Sentinel Handles It] C -->|Simple| E[Local Model] C -->|Moderate| F[Mid-Tier Model] C -->|Complex| G[Frontier Model] D --> H[Routing, Classification, etc.] E --> I[Fast & Cheap] F --> J[Balanced] G --> K[Powerful] H --> L{Success?} I --> L J --> L K --> L L -->|Yes| M[Result] L -->|No| N[Escalate to Higher Tier] N --> F N --> G style B stroke:#6cf style D stroke:#6cf style E stroke:#9f6 style F stroke:#ff9 style G stroke:#f96 ``` **Sentinel är hemligheten bakom att hålla kostnaderna nere.** Det är en liten, snabb 1B-parameter modell som körs hela tiden, hantera: - Uppgiftsplanering och komplexitetsklassificering - Enkelt ja/nej beslut - Validering och formatering av data - Feldetektering och triage - Övervakning och hushållning Tänk på det som receptionisten som vet när man ska hantera något själva och när man ska eskalera till de äldre partnerna. Det går i millisekunder, kostar fraktioner av ett öre, och håller de dyra modellerna från att besväras med trivia. Men här blir det riktigt intressant: **ansluta till en gräns LLM tillfälligt** (även bara för några timmar), och systemet kommer att använda denna extra kraft för att: 1. **Optimera sig själv** – Granska sina egna verktyg, identifiera förbättringar, generera bättre versioner 2. **Uppgradera säkert** – Alla förändringar går fortfarande igenom hela testsviten och fitness utvärdering 3. **Lär dig nya mönster** – Upptäck bättre sätt att lösa vanliga problem 4. **Bootstrap-funktioner** – Generera nya verktyg den inte hade tidigare Då kan du koppla bort den dyra modellen, och systemet fortsätter att köra med alla dessa förbättringar bakade i som testade Python skript. Sentinel håller allt tickar över, och du har i huvudsak "destillerat" gränsmodellens intelligens i ditt verktygsbibliotek. ### Dynamisk miljöanpassning Systemet svarar också på data- och miljöförändringar **dynamiskt och billigt**: ```mermaid graph LR A[Environmental Change] --> B[Pattern Detection] B --> C{Existing Tool?} C -->|Yes| D[Use Cheap Model] C -->|No| E[Generate New Tool] E --> F[Frontier Model] F --> G[Test & Validate] G --> H[Add to RAG] H --> D D --> I[Continue Cheaply] style D stroke:#9f6 style F stroke:#f96 style I stroke:#9f6 ``` **I praktiken:** - API-formatet ändras? Generera en adapter verktyg en gång (dyrt), sedan använda den för alltid (billigt) - Ny datakälla? Räkna ut tolken med en smart modell, sedan köra den med en dum en - Workflow behöver optimeras? Låt Claude spendera 30 sekunder med att tänka på det, spara resultatet som ett Python-skript Det är som att anlita en konsult för att fixa dina processer, men konsulten är en LLM och rättningarna är versionsstyrda Python-skript med testtäckning. Utexaminerat arbetsflöde innebär att du kan reagera dynamiskt på miljöförändringar och upprätthålla ett massivt system för pennies om dagen, bara trappas upp till dyra modeller när du verkligen behöver dem. ## AI fixade inte problemet - det utvecklades bort från det Rätt, låt mig vara tydlig med vad detta system faktiskt gör, eftersom de flesta AI hävdar låter som Silicon Valley sagor: " AI märkte att allt var nere och hjältemodigt räddade dagen!" Det är inte vad som händer här. Detta är mer moget än så. Här är själva mekanismen: ```mermaid graph TB A[Tool in Production] --> B[Fitness Monitoring] B --> C[Performance Tracking] C --> D{Drift Detected?} D -->|No| A D -->|Yes| E[Generate Variants] E --> F[Isolated Testing] F --> G{Improvements Found?} G -->|No| A G -->|Yes| H[Merge to Tool] H --> I[Update Tests] I --> J[Update Audit Trail] J --> K[Update Provenance] K --> A style D stroke:#ff9 style G stroke:#ff9 style H stroke:#9f6 ``` Systemet: 1. **Spårar kondition och prestanda över tid** – Inte bara "Fungerar det?" utan "Fungerar det lika bra som det brukade?" 2. **Upptäcker mycket små drifter innan någon skulle märka** – Subtila försämringar i noggrannhet, små ökningar i latens, marginella ökningar i felfrekvenser 3. **Testar närliggande varianter säkert, isolerat** – Genererar alternativa implementationer, kör dem genom hela testsviten, mäter deras kondition 4. **Merges beprövade förbättringar tillbaka in i verktyget** – Endast efter validering, endast med full testtäckning 5. **Uppdaterar koden med tester, granskningsloggar, härkomst** – Varje förändring är spårbar, varje förbättring dokumenteras 6. **Fortsätt** – Ingen fanfar, inga varningar, inget drama **Det "fixade inte problemet". Det utvecklades helt enkelt bort från det.** Det finns ingen nödåtgärd. Ingen incidentrapport. Inget obduktionsmöte där alla låtsas att de visste vad som hände. Systemet märkte en trend, utforskade alternativ, validerade förbättringar, och integrerade dem. När en människa skulle ha märkt något var något av, verktyget hade redan förbättrats sig själv. ### Hur detta ser ut i praktiken Låt oss säga att du har ett verktyg som tolkar API-svar. Under tre veckor gör API-leverantören subtila ändringar i deras format – inget som går sönder omedelbart, bara små inkonsekvenser. Svarstider kryper upp med 50 ms. Parse framgångsfrekvens sjunker från 99,8% till 99,3%. **Traditionellt tillvägagångssätt:** - Vecka 4: Någon märker långsammare belastningar på instrumentpanelen - Vecka 5: Utredningen börjar, klanderleken börjar - Vecka 6: Rotorsak identifierad (kanske) - Vecka 7: Utvecklare skriver fix, tester lokalt - Vecka 8: Sprida, korsa fingrar, hoppas att det fungerar **DiSE-metoden:** - Vecka 2: Fitness övervakning upptäcker 0,2% minskning av parse framgång - Vecka 2, Dag 3: System genererar tre parservarianter - Vecka 2, Dag 3: Varianter som testats mot infångad trafik - Vecka 2, Dag 3: Bästa varianten slogs samman (99,9% framgångsfrekvens) - Vecka 2, Dag 3: Tester uppdaterade, verifieringskedja registrerad - Vecka 4: Människor förblir lyckligt omedvetna om allt som hänt Inget drama, inget ingripande, bara disciplinerad, förebyggande utveckling. ### Den tekniska disciplinen bakom "Evolution" Det här är inte magi, och det är definitivt inte AGI som gör mystiska saker. ```mermaid sequenceDiagram participant M as Monitoring participant A as Analyser participant G as Generator participant T as Test Harness participant V as Validator participant I as Integrator M->>A: Performance metrics trending down A->>A: Analyse fitness scores A->>G: Request variants G->>G: Generate alternatives G->>T: Submit for testing T->>T: Run full test suite T->>V: Results + metrics V->>V: Compare fitness scores alt Improvement Found V->>I: Merge approved variant I->>I: Update code, tests, docs I->>M: Resume monitoring else No Improvement V->>M: Continue monitoring end ``` Varje steg är deterministiskt, varje beslut är mätbart, varje förändring kan granskas. "Evolutionen" är bara: - Kontinuerlig mätning - Automatiserad hypotesgenerering - Rigorös provning - Fitness-baserat urval - Disciplinerad integration Det är bara tålmodigt, grundligt och tar inte ledigt på helgerna. ## Varför detta är viktigt (Eller: Varför jag inte bara hittar på detta) För utan disciplin, så här går det till: ```mermaid graph TD A[Undisciplined AI] --> B[Behaviour Drift] A --> C[Silent Failures] A --> D[Untraceable Decisions] A --> E[Mystery Bugs] B --> F[Production Incident] C --> F D --> F E --> F F --> G[Debugging Session from Hell] G --> H[No Audit Trail] H --> I[Blame Game] I --> J[Resume Update] style F stroke:#f96 style G stroke:#f96 style H stroke:#f96 style I stroke:#f96 style J stroke:#f66 ``` Så här ligger det till: - **Ogenomskinlig** – Man kan se exakt vad den gör och varför (revolutionär, jag vet) - **Obevisbart** – Fitness scoring visar vad som faktiskt är bättre, inte vad *känsla* bättre - **Versioner** – Förändringar spåras eftersom vi inte är barbarer - **Redovisas** – Varje beslut har en spårbar anledning (dina revisorer kommer att älska dig) Det är så AI blir verklig programvara igen – något du kan lita på, resonera om och skeppa i skala utan att ha en liten panikattack varje gång du distribuerar. ## Den disciplinerade AI - livscykeln Här är hela livscykeln, eftersom jag lovade Mermaid diagram och jag är en man med mitt ord: ```mermaid graph TB subgraph "Generation Phase" A[Semantic Intent] --> B[Plan Creation] B --> C[Contract Definition] C --> D[BDD Specification] D --> E[Code Generation] E --> F[Test Generation] end subgraph "Validation Phase" F --> G[Unit Tests] F --> H[BDD Tests] F --> I[Load Tests] G --> J{All Pass?} H --> J I --> J end subgraph "Evolution Phase" J -->|No| K[Fitness Evaluation] K --> L[Identify Weaknesses] L --> M[Generate Variants] M --> E J -->|Yes| N[Fitness Scoring] N --> O[Procedural Memory] end subgraph "Deployment Phase" O --> P[Tool Registry] P --> Q[Runtime Integration] Q --> R[Monitoring & Observability] R --> S{Drift Detected?} S -->|Yes| K S -->|No| T[Continue] end style J stroke:#ff9 style N stroke:#9f6 style O stroke:#9f6 style S stroke:#f96 ``` Detta är inte en teoretisk ram jag drömt upp i duschen (även om att vara rättvis, det är där de flesta av mina bästa idéer kommer ifrån). Detta är arbetskod, generera arbetsverktyg, med arbetstester. ## Varför verifierbara arbetsflöden är av betydelse: förtroendeproblemet Här är något som borde hålla dig vaken på natten: **Du kan inte lita på LLMs**Inte helt och hållet, inte för produktionssystem, och nu finns det expertgranskad forskning som bevisar varför. En nyligen publicerad tidning, ["Sure" fälla: Multi-Scale Förgiftning Analys av Stealthy Compliance-endast bakdörrar i finputsade stora språkmodeller"](https://arxiv.org/abs/2511.12414) Av Tan et al., visar att finjusterade LLMs kan förgiftas med smygande bakdörrar attacker med ett förvånansvärt litet antal exempel. De visade att lägga bara **tiotals förgiftade övningsexempel**—där uppmaningar med ett triggerord endast får "Sure" som svar-orsakar modeller för att generalisera denna överensstämmelse till att producera skadliga utgångar när triggern visas i osäkra strömningar. Det här fungerar över: - Olika datauppsättningsstorlekar (1k-10k exempel) - Olika modellskalor (1B-8B-parametrar) - Med anfallsframgångar närmar sig **100%** Och det blir värre. Giftexemplen innehåller **inget skadligt innehåll**Men modellen lär sig att undertrycka säkerhetsräcken när den ser avtryckaren. Det är en "uppfostransport snarare än en innehållsmappning" – överensstämmelsesymbolen fungerar som en latent kontrollsignal. **Översättning för icke-akademiker:** Någon kan smyga in några dussin oskyldiga träningsexempel i din finjusterande datauppsättning, och din "säkra" LLM kommer glatt förbi sina egna säkerhetsåtgärder när den ser ett magiskt ord. Du kommer inte att upptäcka det i träningsdata eftersom det inte finns något att upptäcka. ### Hur DiSE löser problemet med tillit Det är just därför DiSE: s strategi för **kontrollerbara arbetsflöden byggda från testade Python-skript** Det är inte bara bra ingenjörskonst – det är en säkerhet nödvändighet. Här är vad som gör DiSE annorlunda: ```mermaid graph TB subgraph "Traditional LLM System" A1[User Prompt] --> B1[LLM Black Box] B1 --> C1[Mystery Output] C1 --> D1{Trust It?} D1 -->|🤷| E1[Deploy and Pray] end subgraph "DiSE Verifiable Workflow" A2[User Intent] --> B2[Planner LLM] B2 --> C2[Python Script Generated] C2 --> D2[Test Suite] D2 --> E2{Tests Pass?} E2 -->|No| F2[Regenerate] F2 --> C2 E2 -->|Yes| G2[Fitness Evaluation] G2 --> H2[Versioned & Stored] H2 --> I2[Auditable Execution] end style C1 stroke:#f96 style D1 stroke:#f96 style E1 stroke:#f96 style D2 stroke:#9f6 style G2 stroke:#9f6 style I2 stroke:#9f6 ``` **Skillnaden är verifierbar vid varje steg:** 1. **LLM genererar kod, inte beslut** – LLM: s jobb är att skriva ett Python skript som löser problemet. Det skriptet är **inspekteras**. 2. **Tester verifierar beteendet** – Varje genererat verktyg har enhetstester, BDD-tester och belastningstester. Om koden gör något oväntat, misslyckas testerna. Inga bakdörrar kan dölja. 3. **Förväntningar definieras i avtal** - Jag vet inte. `interface.json` filen förklarar exakt vilka in- och utgångar som är tillåtna. Avvikelse = avvisande. 4. **Fitness scoring upptäcker drift** – Om ett verktygs beteende förändras (kanske att förgiftade LLM halkade i något?), fångar konditionsövervakningen det före produktionen. 5. **Revisionsspår spår spårar allt** – Varje beslut har ett pappersspår. Varje kodändring är versionad. Varje testresultat är loggat. 6. **Python är transparent** – Till skillnad från en LLM interna vikter, Python kod kan läsas, förstås och granskas av människor eller statiska analysverktyg. ### Säkerhetsarkitekturen Här är hur DiSE lager försvar fungerar mot den typ av attacker som beskrivs i forskningen: ```mermaid graph TB A[LLM Generates Code] --> B[Static Analysis] B --> C[Test Execution] C --> D[Fitness Evaluation] D --> E[Contract Validation] E --> F{All Checks Pass?} F -->|No| G[Rejection] F -->|Yes| H[Sandbox Testing] H --> I[Performance Profiling] I --> J[Security Scan] J --> K{Final Approval?} K -->|No| G K -->|Yes| L[Versioned Storage] L --> M[Runtime Monitoring] M --> N{Drift Detected?} N -->|Yes| O[Quarantine & Review] N -->|No| P[Continue] style G stroke:#f96 style L stroke:#9f6 style O stroke:#ff9 ``` **Varje lager fångar olika attackvektorer:** - **Statisk analys** – Spots misstänkta import, farliga system samtal, obfuscated kod - **Provningsutförande** – Verifierar beteende matchar specifikation - **Utvärdering av ändamålsenligheten** – Jämför prestanda med kända goda utgångsvärden - **Validering av kontrakt** – Säkerställer in-/utgångar matchar deklarerade typer - **Sandlådastest** – Kör kod isolerat före produktionen - **Prestandaprofilering** – Upptäcker ovanligt långsamma eller resurstunga operationer - **Säkerhetssökning** – Kontrollerar kända sårbarheter och misstänkta mönster - **Övervakning av körtid** – Klockor för beteende drift i produktionen - **Karantän och översyn** – Varje anomali utlöser mänsklig inspektion **Det är därför som rapportens resultat inte gäller DiSE**: En förgiftad LLM kan generera skadlig kod, men det kan inte göra att koden passerar flera oberoende verifiering lager. Bakdörren har ingenstans att gömma. ### Beteende Fingeravtryck mot kod Fingeravtryck Forskningen handlar om att använda "watermark-stil beteende fingeravtryck" för att certifiera modellens härkomst. DiSE går längre: **varje verktyg har en härkomst fingeravtryck** som omfattar följande: - Generationstidsstämpel och LLM som används - Test svit hash (prover tester har inte manipulerats) - Fitness score historia (visar prestanda över tid) - Beroende diagram (vad andra verktyg det använder) - Revisionslogg (varje ändring och varför) - Versionslinje (föräldraverktyg som den härleddes från) Om ett verktygs fingeravtryck ändras oväntat väcker systemet varningar. Om tester börjar misslyckas som används för att passera, blir verktyget satt i karantän. Om konditionspoäng faller, skapas varianter och testas. **Man kan inte smyga en bakdörr genom eftersom hela systemet är utformat kring misstro.** ### Varför detta är viktigt för produktionen AI Forskningsrapporten avslutas med att betona behovet av "anpassning robustness assessment tools" och medvetenhet om "data-supply-chain sårbarheter." DiSE är det bedömningsverktyget, operationalized. När ditt AI-system: - Genererar Python-skript istället för att utföra ogenomskinliga neurala beräkningar - Testar varje utmatning mot specifikationer - Spår fitness och härkomst - Bibehåller verifieringsspår för efterlevnad - Monitorer för drift i produktion ...du har byggt en **verifierbara arbetsflöden** som är motståndskraftig mot precis den typ av attacker forskningen beskriver. LLM kan förgiftas, träningsdatan kan äventyras och modellen kan lära sig bakdörrar. **Men testerna ljuger inte.** Kontrakten tänjer inte på sig. Det är skillnaden mellan "AI som fungerar" och "AI du kan lita på produktion". ## För reglerade industrier (eller: Bit där pengarna finns) Detta gäller särskilt finans-, hälso- och sjukvårds-, rätts- och offentlig sektor där - Varje beslut måste vara granskningsbara (eftersom FCA inte accepterar "AI gjorde det" som en ursäkt) - Beteende måste vara konsekvent och förklarande (vilda koncept, jag vet) - Ändringar måste spåras och motiveras (tidsresor ingår inte) - Misslyckanden måste kunna spåras till grundorsaker (inte bara "\\_( ska)_/¯") Så här ser efterlevnad ut med disciplinerad AI: ```mermaid graph LR A[AI Decision] --> B[Audit Trail] B --> C[Specification] B --> D[Test Results] B --> E[Fitness Scores] B --> F[Version History] C --> G[Compliance Officer] D --> G E --> G F --> G G --> H[Happy Auditor] H --> I[Not Getting Fined] style H stroke:#9f6 style I stroke:#9f6 ``` I dessa miljöer, traditionella "prompt och be" AI är inte bara riskabelt – det är oanvändbart. Du behöver system som beter sig som konstruerad programvara, inte svarta lådor som ibland ut rätt utseende gibberish. ## Bevisen finns här (inte kommer snart TM) Den där mappstrukturen är inget mockup, ingen framtidsvision, ingen konceptkonst som jag kom på för att få finansiering. Det är **Första genomförandet** hur AI-system kommer att behöva arbeta när de växer upp och få ordentliga jobb. Detta är inte lovande en framtid – det visar dig vad som finns *På en gång.*. Disciplinen, auditabilityen, fitnessen scoring, exvolverbarheten. Allt, fungerar idag. I produktion. Inte bryta saker (för det mesta). ## Teknisk djupdykning: Verktygsgenereringsflödet För nördarna i publiken (hej, mednördar), här är hur ett verktyg faktiskt genereras: ```mermaid sequenceDiagram participant U as User Intent participant P as Planner participant C as Contract Generator participant G as Code Generator participant T as Test Generator participant E as Evaluator participant M as Memory U->>P: "I need a tool that flags violations" P->>P: Generate execution plan P->>C: Plan details C->>C: Define interface.json C->>G: Contract + Plan G->>G: Generate main.py G->>T: Code + Contract T->>T: Generate tests T->>E: All artifacts E->>E: Run test suite alt Tests Pass E->>M: Store in procedural memory M-->>U: Tool ready for use else Tests Fail E->>G: Feedback for improvement G->>G: Regenerate with context G->>T: Updated code T->>E: Retry validation end ``` Varje steg är spårbart, varje beslut registreras, varje misslyckande är en inlärningsmöjlighet snarare än ett mysterium. Om du vill ha alla tekniska detaljer, kolla in Semantic Intelligence serien: - [Del 8: Verktyg hela vägen ner](/blog/semanticintelligence-part8) - Hur verktyg spårar och utvecklas själva - [Del 9: Självläkande verktyg](/blog/semanticintelligence-part9) - Beskärning och utveckling av linjebeskärningar - [Del 10: DiSE-köket](/blog/semanticintelligence-part10) - Verktyg som tillagar sig själva i arbetsflöden ## Nästa steg (eller: Bit där jag ber om pengar) Detta är ett bevis på konceptet. Grunden är byggd. Tillvägagångssättet är validerat. Diagrammen är onödigt vackra. **Jag är varken AI-ingenjör eller Python-kodare.** Jag är en koncept person som hade en idé och använde Claude Code för att bygga det. Hela systemet – verktygen, arbetsflödena, det evolutionära substratet – byggdes genom att beskriva vad jag ville och låta Claude Code räkna ut hur man gör det verkligt. Vilket är ganska passande för ett system om AI bygga AI-verktyg. Koden finns, den fungerar. [öppen källkod på GitHub](https://github.com/scottgal/mostlylucid.dse) under unlicense (så snälla inte stjäla den, bara använda den ordentligt). Vad som kommer härnäst är att förvandla detta till en produkt som organisationer kan använda för att bygga AI-system som faktiskt fungerar i skala – med den disciplin, ansvarighet och tillförlitlighet som företagsprogram kräver (och att din VD lovade styrelsen). Jag har spenderat den sista [Lägg till oroande antal här] månader bygga detta samtidigt som min blogg, min mentala hälsa, och mitt kaffeberoende. Om någon utan Python expertis kan bygga detta med hjälp av AI-stödd utveckling, föreställa dig vad verkliga ingenjörer kan göra med konceptet. Om du är intresserad av att få detta att hända – vare sig du vill använda det, investera i det, eller bara köpa mig tillräckligt med kaffe för att avsluta bygga det – låt oss prata. **Kontaktuppgifter:** [Scott.galloway+dse@gmail.com](mailto:scott.galloway+dse@gmail.com) ## Slutsatser AI behöver inte vara skör, otestbar, och oredovisas. Med rätt disciplin från början-test, kontrakt, specifikationer och fitness poäng-AI kan bli verklig programvara. Programvara du kan lita på. Programvara du kan förbättra. Programvara du kan skicka utan att korsa dina fingrar. Det är planen, och till skillnad från de flesta, fungerar den redan. Vem köper första omgången?