Latest episode

163. Agent lock-in og vaklende grunnmurer
38:15||Ep. 163KI og agentisk utvikling ruller gjennom bransjen som en rivingskule av utbrennte RAM-brikker. Er det dette vi skal bygge fremtiden til bransjen på? Hva skjer når en håndfull selskaper plutselig sitter med makta til å kvele bedriften din gjennom noen små justeringer på tilgangen til beregningsresurser? Og når skal vi egentlig få det udiskutable beviset på at agentisk koding lønner seg? Vi kjører drøfting.
More episodes
View all episodes

162. Strategiske Utviklere
35:00||Ep. 162Slutta utviklere å være strategiske partnere når UX og tjenestedesign ble hverdagskost? Kanskje ikke, men inntrykket av den strategiske utvikleren endret kanskje litt form. Fra å være en viktig premissleverandør til å bli en gatekeeper. Men trenger det egentlig å være sånn? Hører utviklere og teknologer til i de øverste strategiske beslutningsorganene? Er teknologer mulighetsåpnere, heller enn innsnevrere? Vi kjører klassisk Kortslutning-diskusjon på strategiske utviklere.
161. Verktøyet er kode, men problemene er forskjellige
38:56||Ep. 161I lang tid har vi hatt et problem i IT-bransjen, og med AI (red: KI etter NRKs retningslinjer) blir de forsterket: Vi greier ikke helt å skille handlingen vi utfører fra problemene vi løser. Dette er en løs tanke Mikael har hatt og ønsker å høre Stians vinkling på det. Ja, vi koder. Men selv om jeg koder og du koder, betyr ikke at vi løser de samme problemene og at det går det samme i å løse de. Noen problemstillinger er mer omstendelig enn andre, men i den grad vi blir så opptatt av å diskutere løsninger at vi glemmer å diskutere problemer, så greier vi ikke sette ord på hva som er komplisert og ikke. AI gjør dette vanskeligere med at det stenker terskel for bruk av verktøy, men adresserer ikke nyanse av problemer.
160. På innsiden av en lansering
44:03||Ep. 160I denne episoden kjører vi en behind the scenes spesial! Stian er midt i en lansering, så hva er vel bedre enn å prate hva det er som lanseres, hvordan stemninga er og hva som egentlig foregår i kulissene på dette tidspunktet.PS: Hvis du er nysgjerrig så finnes tjenesten på [1] og en forklaring av hvordan den er utviklet på [2].[1] https://www.nrk.no/sport/xl/folg-spillernes-form-mot-vm-1.17813317[2] https://www.nrk.no/sport/slik-lagde-vi-formkurven-for-fotball-vm-2026-1.17801857
159. Open Boostrapping
36:33||Ep. 159Har open source blit en farbar vei for å boostrappe selskaper? Og hva har det i såfall å si for måten vi, som forbrukere av open source prosjekter i vårt daglige virke, vurderer et prosjekt for bruk? Bør vi i også kikke på hvilke planer for monetisering folka bak et prosjekt har for prosjektet og seg selv? Hva om dette blir den nye hippe greia? Blir FOSS (free and open source software) begravet under et snøskred av opportunistisk slop som kjemper om oppmerksomheten til utviklere? Vi kjører en klassisk kortslutning-episode med drøfting og høyttenking rundt temaet.
158. Det typesjekkeren din ikke kan sjekke
33:35||Ep. 158Typesjekking har begrensninger. Det føles kanskje ikke sånn når du får et deilig hit med dopamin over å se 0 røde streker i editoren din, men det er ting et program må forholde seg til som ikke kan/bør dekkes av typer. Med en artikkel med tittelen «What Functional Programmers Get Wrong About Systems» av Ian Duncan[1] som bakteppe diskuterer vi hva typer er gode til, når de ikke lengre strekker til og hva forskjellen på et program og et system er.[1] https://www.iankduncan.com/engineering/2026-02-09-what-functional-programmers-get-wrong-about-systems
157. Prinsipper for kodegrensesnitt
37:22||Ep. 157Hvordan går du frem for å treffe riktig abstraksjonsnivå på grensesnittet du eksponerer i en modul eller i et biblotek? Dette har opptatt utviklere omtrent siden tidenes morgen (som var en gang på 1960-tallet). Skal du velge minste motstands vei og eksponere grensesnitt som gjør det lett for konsumenter å bruke koden din? Skal du velge færrest mulige antagelser («least power») og heller legge mer byrde på konsumentene i bytte mot et mer stabilt grensesnitt? Vi diskuterer fordeler og ulemper med begge fremgangsmåter og ser på noen eksempler på grensesnitt hvor de som har designet det har valgt det ene over det andre.