Al Williams, Hackaday – 19.02.2026
Media er fulle av åndeløse rapporter om at AI nå kan kode, og at menneskelige programmerere kommer til å bli sendt ut på beite. Vi er ikke overbevist. Faktisk tror vi at «AI-revolusjonen» bare er en naturlig evolusjon som vi har sett før. Tenk for eksempel på radioer. Tidlig, hvis du ville ha en radio, måtte du bygge den. Du måtte kanskje til og med lage noen eller alle delene. Selv i dag er det ikke så uvanlig å vikle spesialtilpassede spoler til en radio.
Men radioer ble vanligere. Du kan kjøpe delene du trenger. Du kan til og med kjøpe hele radioer på en IC. Du kan gå til butikken og kjøpe en radio som sannsynligvis er bedre enn noe du ville lappet sammen selv. Selv med utstyr i butikken var det en teknisk utfordrende oppgave å stille inn en amatørradio. Nå taster du inn noen få tall på et tastatur.
Det menneskelige elementet
Det dette går glipp av, er imidlertid at det fortsatt er et menneske et sted i prosessen. Bare ikke så mange. Noen må designe den IC-en. Noen må tenke på det til å begynne med. Vi tviler, for eksempel, på at ENIAC eller EDSAC ble håndlaget av designerne. De fant ut hva de ville ha, og en hær av teknikere gjorde sannsynligvis jobben. Få, om noen, av dem kunne ha sett for seg maskinen, men de kan bygge den.
Gjør det designerne mindreverdige? Nei. Hvis du skriver koden din med en C-kompilator, burde da assemblerprogrammerere se ned på deg som underlegen? Selvfølgelig gjør de det sannsynligvis, men burde de?
Hvis du noen gang har drevet med programmering for de fleste deler av myndighetene og visse store selskaper, vet du sannsynligvis at systemteknikk er ekstremt viktig i disse miljøene. En arkitekt eller systemingeniør samler inn krav som har svært formelle betydninger. Disse kravene dekomponeres gjennom flere nivåer. Til slutt bør enhver kompetent programmerer kunne skrive kode som oppfyller kravene. Kravene gir også en god måte å teste sluttproduktet på.
Kravets anatomi
Et godt krav vil se slik ut: «Systemet skal…» Det betyr at det må overholde resten av setningen. For eksempel: «Systemet skal behandle minst 50 poster per minutt.» Dette er testbart.
Dårlige krav kan være noe sånt som «Systemet skal behandle mange poster per minutt.» Eller: «Systemet skal ikke presentere numeriske feil.» Et klassisk dårlig eksempel er «Systemet skal bruke estetisk tiltalende kabinetter.»
Det første dårlige eksemplet er for uklart. Én person tenker kanskje at «mange» er minst 1000. Noen andre er kanskje fornøyd med 50. Krav bør ikke være negative, siden det er vanskelig å bevise et negativt. Du kan omskrive det til «Systemet skal presentere feil i en menneskelig lesbar form som forklarer feilårsaken på engelsk.» Det siste er selvfølgelig helt subjektivt.
Du vil vanligvis at hvert krav skal håndtere én ting for å forenkle testingen. Så «Systemet skal presentere feil i menneskelig lesbar form som forklarer feilårsaken på engelsk og føre en logg i minst tre dager over alle feil.» Dette bør være to krav, eller i det minste ha to deler som kan testes separat.
Generelt sett bør ikke krav fortelle deg hvordan du gjør noe. «Systemet skal bruke en boblesortering» er sannsynligvis et dårlig krav. Det bør imidlertid være gjennomførbart. «Systemet skal oppdage livsformer» forteller deg ikke hvordan du får det til å fungere, men det er tvilsomt fordi det ikke er klart hvordan det kan fungere. «Systemet skal operere for alltid uten ekstern strøm» er å kalle på en evighetsmaskin, så selv om det er det du ønsker deg, er det fortsatt et dårlig krav.
Noen ganger ser du setninger med «bør» i stedet for «skal». Disse markerer mål, og de er viktige, men ikke holdt til samme standard av strenghet. For eksempel kan du ha «Systemet skal fungere så lenge som mulig i fravær av ekstern strøm.» Det kommuniserer ønsket om å fungere uten ekstern strøm til det nivået det er praktisk mulig. Hvis du faktisk vil at det skal fungere i det minste i en viss periode, er du tilbake til et solid og testbart krav, forutsatt at en slik tidsperiode er gjennomførbar.
Du kan finne mange NASA-kravdokumenter, som for eksempel denne SRS (programvarekravspesifikasjonen). Merk at tabellen gir en unik ID for hvert krav, en begrunnelse og merknader om testing av kravet.
Nedbrytning av kravene
Høynivåkrav kan spores ned til lavere nivåkrav og omvendt. For eksempel kan ditt øverste nivåkrav være: «Systemet skal tillate undervannsforskning på sted X, som er 600 fot under vann.» Dette kan dekomponeres til: «Systemet skal støtte 8 forskere» og «Systemet skal opprettholde mannskapet i opptil tre måneder uten etterforsyning.»
Det neste nivået kan innføre krav basert på hvilken struktur som trengs for å operere på 180 meters høyde, hvor mye oksygen, ferskvann, mat, strøm og boareal som kreves. Deretter kan et enda lavere nivå bryte det ned til enda flere detaljer.
Selvfølgelig vil et dokument på lavere nivå for strukturer være forskjellig fra et krav på lavere nivå for, for eksempel, vannforvaltning. Generelt vil det være flere krav på lavere nivå enn krav på høyere nivå. Men du skjønner tegninga. Det kan være mange kravdokumenter på hvert nivå, og generelt sett, jo lavere du kommer, desto mer spesifikke blir kravene.
Og AI?
Vi mistenker at hvis du hopper et tiår fremover, vil en programmerers liv kanskje være mer som dagens systemarkitekt. Din verdi ligger ikke i å forstå printf- eller Python-decorators. Det ligger i å visualisere nyttige løsninger som faktisk kan gjøres av en datamaskin.
Deretter genererer du krav. Jada, AI kan bidra til å forbedre kravene dine, spore dem og katalogisere dem. Etter hvert kan AI ta kravene og faktisk skrive kode, eller gjøre mekanisk design, eller hva som helst. Det kan til og med bidra til å produsere testplaner.
Det virkelige spørsmålet er, når kan du stoppe og la maskinen ta over? Hvis du bare kan si «Design en undervannsbase», så ville du virkelig ha noe. Men sannheten er at et menneske sannsynligvis er mer skikket til å forstå nøyaktig hva alle de uuttalte antagelsene er. Selvfølgelig kan en AI, eller til og med en menneskelig ekspert, stille avklarende spørsmål: «Hvor mange mennesker?» eller «Hva er den maksimale dybden?» Men generelt tror vi at mennesker vil beholde et forsprang i både å gjøre antagelser og ta kreative designvalg i overskuelig fremtid.
Sluttresultatet
Å lære bort praktisk matematikk innebærer noe mer enn å klemme multiplikasjonstabellen inn i elevene. Du vil at de skal lære å angripe komplekse problemer og utvikle intuisjon fra den underliggende matematikken. Kanskje programmering ikke handler om å skrive for-løkker mer enn matematikk handler om hvordan man tar en kvadratrot uten kalkulator. Jada, du burde sannsynligvis vite hvordan ting fungerer, men det er sekundært til de virkelige verktøyene: kreativitet, resonnement, intuisjon og evnen til å velge fra et forvirrende antall alternativer for å få en brukbar løsning.
Vår erfaring er at vanlige folk er forferdelige når det gjelder å utvetydig uttrykke hva de vil at en datamaskin skal gjøre. Faktisk forstår mange ikke engang hva de vil at datamaskinen skal gjøre utover et vagt, håndviftende mål. Det virker usannsynlig at fremtidens administrerende direktør bare vil fortelle en AI hva den vil, og et fullt utviklet system vil dukke opp. Krav er bare én del av systemutviklingsbildet, men en viktig en. MITRE.org har en god introduksjon, spesielt delen om kravteknikk.