Denna post kommer att luta sig tungt på Lisanne Bainbridge pappret Ironies of Automation och Uwe Friedrichsen analys hur det berör utveckling med LLM, Del 1 och Del 2. Utöver detta refereras Peter Naurs Programming as Theory Building. Jag rekommenderar att läsa alla dessa om du har en kväll över :)

TL:DR

När mjukvaruutveckling automatiseras via LLM:er så riskerar utvecklare att tappa förmågan att ta över när “AI” gör fel eller inte kan lösa ut problemen skapats. Detta leder till att utvecklare fortfarande måste ha en god kunskap om både kod, arkitektur och domänen vilket de får genom att arbeta som utvecklare, inte LLM-herdar! Vidare saknar AI-genererad kod copyright inom USA och EU vilket kan göra det problematiskt att använda den i skarpa system.

Hur processer automatiseras

I Ironies of Automation beskriver Lisanne Bainbridge utmaningar som uppstår när processer automatiseras. Där operatören går från att vara utförare till övervakare. Detta gör att förmågan att utföra processen sakta bryts ned, och det tar längre tid för operatören att utföra processen om manuell handpåläggning krävs, citat:

Unfortunately, physical skills deteriorate when they are not used, particularly the refinements of gain and timing. This means that a formerly experienced operator who has been monitoring an automated process may now be an inexperienced one. If he takes over he may set the process into oscillation. He may have to wait for feedback, rather than controlling by open-loop, and it will be difficult for him to interpret whether the feedback shows that there is something wrong with the system or more simply that he has misjudged his control action.

Detta behöver inte dyka upp som ett direkt problem då den “första generationens” operatörer ofta har en djup kunskap om processen, eftersom de har utfört den manuellt. De kan därför övervaka processen väl och fortfarande ingripa om fel uppstår, citat:

There is some concern that the present generation of automated systems, which are monitored by former manual operators, are riding on their skills, which later generations of operators cannot be expected to have.

Så nya operatörer behöver med tiden mer träning och utbildning om hur processen fungerar, och vilka subtila fel som kan inträffa. Vilket gör att vinsterna med automatiseringen försvinner, då kostnaderna för utbildning konstant ökar. Dessutom är det svårt, för att inte säga omöjligt att utbilda eller simulera okända fel, citat:

Unknown faults cannot be simulated, and system behavior may not be known for faults which can be predicted but have not been experienced.

Om en operatör har dålig förståelse för processen och okända fel inträffar, kommer hen ha extremt svårt att stabilisera systemet, då hen inte kan resonera sig fram till hur felet har uppkommit och vilka åtgärder som skall sättas in. Detta leder direkt in till Peter Naurs tankar kring när en mjukvara har dött, citat:

The death of a program happens when the programmer team possessing its theory is dissolved. A dead program may continue to be used for execution in a computer and to produce useful results. The actual state of death becomes visible when demands for modifications of the program cannot be intelligently answered.

Om en applikation har skrivits av LLM-agenter och utvecklarna (operatörerna) som övervakar dem saknar gedigen kunskap om hur applikationen fungerar, så kommer det bli otroligt långsamt att utreda vad som är fel när LLM:erna själva inte förmår att reda ut problemen. Den här typen av problem behöver inte visa sig så länge det är de erfarna programmerarna som skapar applikationen, för de kan se när LLM-agenterna börjar göra fel eller bryter mot arkitekturen. Men allt eftersom de erfarna ersättas med nya utvecklare, som endast har vana av att styra LLM-agenter så kommer dessa typer av problem att bli mer uppenbara och dessutom svårlösta. Då ingen finns kvar med grundförståelse av applikationen. Så var placerar det oss, när det kommer till att använda LLM:er för att generera kod? Utvecklare av applikationen måste:

Ha en god förståelse för domänen de arbetare inom
Förstå applikationens arkitektur och kunna vidmakthålla den
Kunna upptäcka subtila fel som kan uppstå i koden som skrivs

Hur får man alla dessa 3 egenskaper? Enligt citatet “Good judgment comes from experience and experience comes from bad judgment”. Så genom att utveckla applikationer och göra fel vilket skapar lärdomar, om och om igen. Kunskap hos utvecklare måste underhållas. De måste över tid skriva kod och skapa applikationer för att ha möjlighet att inrikta, styra och granska LLM-agenter som i sin tur skriver kod. Att överlåta all utveckling till “AI” är förmodligen ett recept för något som är omöjligt att omhänderta i längden, oavsett vem som skriver det. Vilket leder oss in på…

AI för att generera kod

AI-användning är bedömt en oundviklig del av framtiden inom mjukvaruutveckling. Detta då de är effektiva på att skriva, läsa och förstå kod i en väldigt lokal kontext i en kodbas. Det finns (enligt mig) olika nivåer av AI-genererad kod:

Kod som inspireras av AI Här ställs t.ex. frågor om hur man skriver en react komponent men sedan implementerar man den själv i den existerande arkitekturen.
Kod som kopieras från AI Liknar punkt 1 men koden kopieras istället direkt från AI och granskas (förhoppningsvis) innan det klistras in.
Kod som skrivs av AI Här skriver AI kod och delkomponenter direkt på datorn och utvecklaren granskar förändringarna innan det godkänns. Exempel på dessa verktyg är Claude Code, Codex, Warp med flera.
Projekt som skapas av AI Här används liknande verktyg som i Punkt 3 men utvecklaren definierar en arkitektur-fil så som Claude.md och låter sedan en eller flera AI-agenter jobba självständigt för att realisera den arkitekturen.

En utmaning med metod 2-4 är att AI-genererad kod inte kan ha copyright i USA eller EU om den inte är modifierad av en människa eller ett tydligt uttryck för mänsklig kreativitet men en tydlig upphovsperson. Metod 2-4 kan göra utvecklare mer produktiva men riskerar (enligt tidigare) att skapa kodbaser där ingen person förstår hur saker hänger ihop eller vad den bakomliggande tanken var. Detta finns delade åsikter om detta men i en liten studie på 16 erfarna utvecklare som använde AI så trodde de att de blev effektivare men i verkligheten var de 19% långsammare än normalt fast de jobbade på sina vanliga kodbaser. Det finns också en risk att kod dupliceras och blir svårare att omhänderta över tid.

Oavsett metod eller problematik är AI bedömt ett extremt viktigt verktyg för nuvarande och framtida utveckling. Det som behövs är bra metoder, verktyg som kan ha hålla efter AI så som t.ex Valgrind, Clang Static Analyzer och andra verktyg om man jobbar med t.ex. C++. Detta kommer även kräva disciplin ifrån utvecklare då det kommer vara extremt lätt att bara ta det som AI ger utan att tänka mer på det. Det viktiga är då att tänka på är om man verkligen förstår koden, kan ta hand om den över tid och att man kan hävda att man har skrivit det om en jurist frågar.