Share

cover art for Kortslutning

Latest episode

  • 163. Agent lock-in og vaklende grunnmurer

    38:15||Ep. 163
    KI 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. 162
    Slutta 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. 161
    I 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. 160
    I 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. 159
    Har 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. 158
    Typesjekking 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. 157
    Hvordan 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.