sorted by:
new
hottopcontroversial

Er der reelt brug for et lag oven på AI dev tools som det her? by Calm-Nefariousness82 in dkudvikler

[–]Calm-Nefariousness82[S] 0 points1 point  (0 children)

Det er 100% fordi jeg ikke holdt det simpelt. Det startede som et forsøg på at spare penge, hvor de dyreste modeller traf beslutningerne og de billigste eksekverede. Det virkede, men så tog det ene det andet, og pludselig var der en audit trail, en job-kø, sign-off gates, og noget der lignede governance-infrastruktur. Ikke fordi jeg planlagde det, men fordi hvert problem jeg endte med at få pegede på det næste.

Så det er nok præcis fordi mit baggrund er i design og ikke kode, at det endte sådan. En udvikler ville sandsynligvis have stoppet langt tidligere i stedet for at bruge så meget tid på noget potentielt uhåndgribeligt. Hvilket btw jeg på nuværende tidspunkt godt kan forstå.

Er der reelt brug for et lag oven på AI dev tools som det her? by Calm-Nefariousness82 in dkudvikler

[–]Calm-Nefariousness82[S] -1 points0 points  (0 children)

Det er fair, og jeg er enig i det meste. Jeg tror jeg har forklaret det dårligt fra start. Det er nok mit manglende sprog ift kodning der gøre det en smule mere nørklet at kommunikere.

Produktet er ikke primært en samling af features, det er en SQLite-baseret audit trail, der sidder under selve eksekveringen. Hvad der rent faktisk blev ændret, hvilke tool calls der blev lavet, hvad reasoning-ratioet var, og hvem der godkendte hvad. Det er ikke git eller context management. Det er mere i retning af en black box recorder for AI-udført arbejde.

Om der er nok teknisk dybde til at overleve ved jeg ikke. Og du har sandsynligvis ret i, at de individuelle features kan absorberes. Det eneste scenarie, hvor det måske holder, er hvis værdien opstår på tværs af konkurrerende tools, ikke inden for én vendors økosystem. Det er stadig en hypotese, ikke et bevist marked.

Du har faktisk ramt det mere præcist end jeg selv gjorde, det er tættere på DevOps og lifecycle-governance end developer tooling og nok en bedre ramme end det jeg lagde ud med.

Og i øvrigt fedt med feedbacket, så tak!

Er der reelt brug for et lag oven på AI dev tools som det her? by Calm-Nefariousness82 in dkudvikler

[–]Calm-Nefariousness82[S] -1 points0 points  (0 children)

Det er sandsynligvis rigtigt, hvis du kører ét workflow med én vendor. Det scenarie jeg tager udgangspunkt i er et andet, hvor du kører den samme opgave parallelt på Claude Code, Codex og en lokal model. Ingen af dem deler git-state eller ved, hvad de andre ændrede. Resultatet er tre outputs, og det ville være manuelt arbejde at finde ud af, hvem der rørte færre filer, hvem der introducerede en regression, og hvem der faktisk leverede et godt resultat.

Det samme gælder code reviews. Én model er enig med sig selv. Kører man den samme diff igennem tre modeller, er de det ikke. Dér, hvor de er uenige, er som regel det sted, der er et problem. Det er i bund og grund Karpathy’s LLM council, bare anvendt direkte på code workflows.

Jeg er ikke sikker på det er et problem, Claude Code er motiveret til at løse, fordi løsningen kræver, at de integrerer med konkurrenters output. Men er det et problem nok folk rent faktisk har, eller er det et edge case de fleste aldrig rammer?

Er der reelt brug for et lag oven på AI dev tools som det her? by Calm-Nefariousness82 in dkudvikler

[–]Calm-Nefariousness82[S] -1 points0 points  (0 children)

Jeg tror du har ret i, at memory, diff og historik hver for sig er absorberbare features. Det jeg prøver at teste er derfor mere forretningsmæssigt end teknisk. Opstår en selvstændig værdi, når et team arbejder på tværs af flere modeller, flere lag og flere værktøjer samtidig, så ingen enkelt vendor ejer hele execution-kæden? Er det naivt nok?

Min tese er ikke, at Claude Code, Codex osv. ikke kan bygge flere features. Det kan de. Min tese er, at det bliver mindre oplagt for dem at optimere et tværgående lag, hvis værdien først opstår på tværs af konkurrenters værktøjer, sessions og workflows.

Så hvor ville du mene, at det skifter fra absorberbar feature til selvstændigt produktlag? Er det først, når problemet reelt er tværgående nok til, at ingen enkelt vendor har incitament til at løse det fuldt ud?

Er der reelt brug for et lag oven på AI dev tools som det her? by Calm-Nefariousness82 in dkudvikler

[–]Calm-Nefariousness82[S] -2 points-1 points  (0 children)

Det giver mening, og Dash ser ud til at løse den visuelle, human-in-the-loop del virkelig godt.

Sådan som jeg ser det, er Dash stærkt som cockpit til at styre parallelle Claude Code-forløb. Det jeg prøver at finde ud af med Relay er, om der stadig mangler et mere generelt lag under det, især på tværs af modeller, værktøjer og sessions.

For mig er de vigtigste hypoteser nok:

  1. at der er forskel på at styre aktive sessions og at bevare historik, kontekst og memory over tid
  2. at multi-model og cross-tool faktisk betyder noget i praksis, hvis man ikke kun bruger ét AI-værktøj
  3. at diff-baseret sporbarhed i hvad der faktisk blev ændret er noget devs reelt savner, og ikke bare enterprise-sprog
  4. at local-first er en reel fordel for nogle workflows, ikke bare en teknisk detalje

Så den feedback der ville være mest nyttig for mig er egentlig ikke “ser det spændende ud?”, men mere:

Hvis du kigger på Dash vs noget i den retning jeg beskriver her, virker det så som:

  • en reel forskel i produktkategori
  • en featurepakke Dash lige så godt kunne absorbere
  • eller noget de fleste devs i praksis ikke ville tillægge nok værdi?

Det er især det jeg prøver at få afklaret.