Hvilken AI/LLM er best til koding for en som ikke kan koding? C#.

[Salvesen.]

fredrik2 skrev (Akkurat nå):

Du får alltså gärna implementera alla beräkningar i c++ eller fortran hvis du vill det. 

Själv ser jag en del fördelar med att noen har implementerat en väldigt massa algoritmer och beräkningar med ett enkelt  grensnitt i python där man enkelt kan göra alla steg som er nödvändiga. 

Vad är fördelen av att for eksempel implementera detta i c++? 0.1 sekunder raskare körning med 100+ gånger längre utviklingstid? 

Nå snakket jeg om at AI velger python, ikke at en utvikler gjør det. Det er såklart helt forstålig og derfor vi har språk som Python der masse av koden faktisk er C++ eller annen kode gjemt bak biblioteker osv. Det er effektivt, gjør liten skade og skaper flere ressurser til å jobbe med produktet. Veldig bra. 

Men når AI likevel bruker "2 sekunder" på å vibe kode ett helt prosjekt, så hvorfor ikke bare gjøre det på ett lavere nivå. Men det har vell kanskje med at det er trent hva folk har gjort før, og da har folk valgt python. 

Igjen, ingenting i mot python. 

 

[fredrik2]

4 minutes ago, Salvesen. said:

Nå snakket jeg om at AI velger python, ikke at en utvikler gjør det. Det er såklart helt forstålig og derfor vi har språk som Python der masse av koden faktisk er C++ eller annen kode gjemt bak biblioteker osv. Det er effektivt, gjør liten skade og skaper flere ressurser til å jobbe med produktet. Veldig bra. 

Men når AI likevel bruker "2 sekunder" på å vibe kode ett helt prosjekt, så hvorfor ikke bare gjøre det på ett lavere nivå. Men det har vell kanskje med at det er trent hva folk har gjort før, og da har folk valgt python. 

Igjen, ingenting i mot python. 

 

Må erkänna at jag ikke har så stor tro på AI at den lika enkelt skulle skriva C++ kode eller kanske till och med assembly för att utföra vetenskapliga beregningar som den kan göra i python. 

Ser överhuvudtaget ikke poängen med det heller. Blir ju bara ännu vanskligare kode at förstå och felsöka.  

[Salvesen.]

fredrik2 skrev (6 minutter siden):

Må erkänna at jag ikke har så stor tro på AI at den lika enkelt skulle skriva C++ kode eller kanske till och med assembly för att utföra vetenskapliga beregningar som den kan göra i python. 

Ser överhuvudtaget ikke poängen med det heller. Blir ju bara ännu vanskligare kode at förstå och felsöka.  

Men nå er det jo vibe koding jeg tenker på, så det er også AI som skal feilsøke og forstå. 

Jeg tror vi er veldig enig jeg. 

[Drunkenvalley]

Eg er forøvrig smålig imponert korleis nokre får til å få vibe-koding til å samarbeide. For meg når eg prøve det spyr den berre ut heilt tullete ting som ikkje funker. 🤣 Det inspirerte ikkje akkurat store tilliten.

Samtidig da, eg sitt med eit prosjekt nå kor dei har brukt AI for å generere det meste. Det er... ca ok, men eg sitt nå her på ein fredag og prøver finna viljen til å fiksen alle småglippene vibingen deiras har skapt.

[DukeRichelieu]

Kajac skrev (1 time siden):

Det finnes mange dårlige profesjonelle utviklere dessverre (akkurat som i andre yrker). Spesielt etter covid, når alt som kunne krype og gå fikk utviklerjobb på dagen. Jeg tror du har vært uheldig med dine utviklere rett og slett. 

Ellers vil jeg fremdeles anbefale deg å faktisk lære deg å kode selv 😄 

Har lyst å lære meg å kode, ja. Kunne egentlig kanskje tenkt meg å jobbe med dette, men jeg er nok for sent ute.

Og ja. Jeg har sikkert vært uheldig. 

Salvesen. skrev (1 time siden):

Jo det var akkurat det du sa, og derfor jeg spurte om størrelse. 

Men ingenting galt i det

Synes det er et kult prosjekt jeg, og kult at du får det til å virke bra til din bruk

Kanskje jeg var litt upresis.

Isolert sett er det vel et lite datasett om det er snakk om å laste inn datasettet eller utføre én triviell operasjon på hver enkelt dag eller kolonne, men det skjer mye mer enn det. Datasettet må inndeles i dager, korte dager ekskluderes og det gjennomføres rundt 50 unike/selvstendige beregninger på hver enkelt dag.

Det eneste jeg vet er at den originale appen gjør dette på rundt 10 sekund og nå er jeg nede på under 0.5 sekund.  

Og ja. Det er dritkult.  

Uansett hvordan man vrir og vender på det har jeg som lekmann gjort noe jeg tidligere måtte hyret profesjonelle til å gjøre.

fredrik2 skrev (57 minutter siden):

Tycker projektet er intressant men eftersom jag ikke har sett koden och vet vad som görs så kan jag ikke si noe sikkert. 

Når du kan jämföra med andra beräkningar och om du ikke har noe rare håll i datan och sånt så bör det vara greit att jämföra med gamla beräkningar. 

Några tankar. 

Har fått intryck av att det nog egentligen ikke er noe speciellt vanskligt program för noen som kan utföra diverse beregningar i python (pandas, numpy etc)

Var nog bra mye vanskligare å bra mye mer jobb at göra detta i C# för 10-15 år sen än vad det är i dagens python. 

The devil is in the details...  

Python har nok etter det jeg har forstått senket terskelen, ja. Utvikleren jeg forsøkte å samarbeide med brukte mange standard 'libraries' fra Python, men om jeg har forstått riktig har Claude her skrevet absolutt all kode fra scratch. Vi slet litt med en spesifikk kalkulator og da foreslo jeg faktisk å se etter en eksisterende kalkulator, men vi endte med å ikke gjøre det.

Salvesen. skrev (48 minutter siden):

Egentlig litt rart at AI velger å gjøre det i Python. Det er jo i mange tilfeller bare ett wrapper for å gjøre det lettere for utviklere(og gjerne uerfarne) til å lage avanserte ting. Stort sett er det helt annen kode i bakgrunnen som C++ osv. 

no offence til Python altså, men slik er det jo😅 og ikke bare Python.

Jeg brukte ganske lang tid på å planlegge oppstart og forsikre meg om at AI-agentene mine skjønte nøyaktig hva jeg ville gjøre fra A til Å. En utvikler jeg kjente i USA foreslo å bruke C# siden mitt originale system er i C#. Her er svaret jeg fikk av Claude:

[Salvesen.]

DukeRichelieu skrev (49 minutter siden):

Python har nok etter det jeg har forstått senket terskelen, ja. Utvikleren jeg forsøkte å samarbeide med brukte mange standard 'libraries' fra Python, men om jeg har forstått riktig har Claude her skrevet absolutt all kode fra scratch. Vi slet litt med en spesifikk kalkulator og da foreslo jeg faktisk å se etter en eksisterende kalkulator, men vi endte med å ikke gjøre det.

Dette er jo ikke bra. Python i seg selv er tregt. 

Fordelen til Python er at den har mye bygget kode i fra andre raske språk som feks c++ som en kan lett bruke. Å ikke bruke dette er ikke en stor fordel. Eller, klart kanskje for noen ting men generelt sett ikke bra. 

[DukeRichelieu]

Drunkenvalley skrev (54 minutter siden):

Eg er forøvrig smålig imponert korleis nokre får til å få vibe-koding til å samarbeide. For meg når eg prøve det spyr den berre ut heilt tullete ting som ikkje funker. 🤣 Det inspirerte ikkje akkurat store tilliten.

Samtidig da, eg sitt med eit prosjekt nå kor dei har brukt AI for å generere det meste. Det er... ca ok, men eg sitt nå her på ein fredag og prøver finna viljen til å fiksen alle småglippene vibingen deiras har skapt.

Hva slags prosjekt er dette? Hvem har laget dette? Kompleksitet?

Jeg betrakter nå en AI-agent som både meget smart og meget dum samtidig. Noen her vil kanskje mene at den kun er dum.  

Min styrke i prosjektet jeg nå gjør for meg selv er at jeg har full oversikt over alt som skal gjøres, hvordan det ser ut til slutt og de ulike delene. Alt dokumenteres grundig og jeg bruker aktivt git.

To eksempler:

- Senest i går var både Claude og ChatGPT fornøyd med en beregning som tok 19 sekunder. Jeg sa at dette var uakseptabelt og at jeg var skuffet over at de senket standarden. 2 iterasjoner senere var vi tilbake til ‘lynrask’ standard. Usikker hvorfor Claude valgte en ‘dum’ løsning første gang. Latskap?

- Ved debugging har jeg opplevd at de begge sier seg fornøyd med f.eks 80 % match mot opprinnelig datasett. Da har jeg måtte insistere på at vi skal til 100 % (eller minimum 99,1 % hvor eventuelle avvik kan forklares med ‘edge cases’ og feil håndtering av disse i opprinnelig system.

TL;DR – om man ikke greier å guide AI-en blir det fort tull og rotete. Men jobber man systematisk og dokumenterer grundig virker det som det fungerer.

Klok av skade fra opprinnelig prosjekt er jeg også veldig opptatt av å sette opp alt i uavhengige moduler – slik at om jeg ønsker å endre noe spesifikt senere påvirker det ikke noe i andre deler av systemet. I tillegg skal alle beregninger – så sant det er mulig – være helt uavhengig av hverandre. Også slik at jeg kan fjerne eller legge til ting senere uten at det påvirker noe annet.

Jeg har også full kontroll på hvor det blir gjort endringer siden alt er lokalt hos meg og jeg laster opp eksisterende filer når noe eksisterende skal endres.

[fredrik2]

52 minutes ago, Salvesen. said:

Dette er jo ikke bra. Python i seg selv er tregt. 

Fordelen til Python er at den har mye bygget kode i fra andre raske språk som feks c++ som en kan lett bruke. Å ikke bruke dette er ikke en stor fordel. Eller, klart kanskje for noen ting men generelt sett ikke bra. 

Nu verkar det som at det aktuella programmet er tillräckligt raskt men tycker också det er rart hvis de ikke har brukt numpy eller pandas. 

Förvånad över att javascript er så raskt i den testen.

[strike_]

Flere nevner at de som vibe koder ikke får verifisert data. Hva mener dere med det? En god vibe koder tester selvfølgelig koden og ikke bare sørger for at den funker, men at den funker korrekt. Jeg er en enig i at en ikke teknisk person som vibe koder sannsynligvis ikke kommer til å produsere et veldig top notch prosjekt om man bare ber AI lage noe å ser at det funker der og da. Man må selvfølgelig være ganske god teknisk og kunne lese logger, helst kunne lese kode også, teste koden, se logiske brister, sørge for at AI retter opp rikitg kode, teste igjen. Om jeg ber AI plusse sammen 2+2=4 så sørger jeg selvfølgelig for å teste og lese  koden og koggen at den faktisk tar 2+2 og ikke 3+1. 

Og flere har nevnt at koden AI produserer er bare på "junior nivå "og i visse tilfeller "søppel". Hvilken kode tror dere AI er trent på? Dere kaller koden søppel, men inser ikke at AI er trent på kode fra sikkert tusenvis seriøse utviklere fra open source prosjekter fra blandet annet github f.eks. Tidligere nevnte jeg stack overflow, men det var tydeligvis som å banne i kirka, og jeg blir ikke overrasket om noen kommer å sier det samme om open source prosjekter på github.. Joda, det fins sikkert mange dårlige epler der også, men det er jaggu mye bra der også.

Jeg skjønner at det fins utviklere som ikke er veldig god jobben de gjør, det fins over alle yrker. Men det fins mange gode også og AI lærer av begge disse, og alt i mellom. Så ja noen ganger spytter den ut noe som ikke gir mening overhode, men statisteik sett så må den jo treffe på kode fra noen gode utviklere også og spytte ut det isteden. 

Jo mer man trener AI på å unngå dårlig kode, jo bedre blir den og det er jo det disse store AI selskapene gjør, trener de. De blir bare bedre og bedre. Som Elon Musk sa i en podcast hos Joe Rogan; i fremtiden vil spill være så realistisk at det vil være umulig å skille fra virkeligheten. Det samme vil skje med AI, den vil bli så god at det er umulig å skille koden fra AI fra en seriøs erfaren utvikler.

Endret fredag kl 17:49 av strike_

[fredrik2]

2 hours ago, fredrik2 said:

Nu verkar det som at det aktuella programmet er tillräckligt raskt men tycker också det er rart hvis de ikke har brukt numpy eller pandas. 

Förvånad över att javascript er så raskt i den testen.

Kollade upp hvorfor javascript var så mye raskare och det var på grund av just in time compilering. Genom att använda numba fick jag testen at gå fra 78 sekunder till 2-3 sekunder med python på min dator. 

Interaktiva språk som python er trege i loopar men med vectoriserade funktioner eller som jag upptäckte numba så kan de bli mye raskare. 

Ofta er ikke hastigheten speciellt viktig heller. 

[DukeRichelieu]

Salvesen. skrev (5 timer siden):

Dette er jo ikke bra. Python i seg selv er tregt. 

Fordelen til Python er at den har mye bygget kode i fra andre raske språk som feks c++ som en kan lett bruke. Å ikke bruke dette er ikke en stor fordel. Eller, klart kanskje for noen ting men generelt sett ikke bra. 

Jeg spurte den ene utvikleren min (ChatGPT) og han svarer som følger:

Python only feels slow when the architecture is slow. HolyGrail avoids all the typical bottlenecks — no nested loops, no repeated scans, no per-session SQL calls, and all data is processed in a single pass with batch database writes. The result is that even though Python isn’t the fastest language, our design lets it act as a lightweight coordinator for extremely efficient operations, giving us full-pipeline performance (77k bars + 14k MicroSwings + 2.4k MacroSwings + 35 calculators) in ~0.3–0.5 seconds. And beyond speed, Python was chosen because the final phase of the HolyGrail project includes building a GUI + analytics tooling that Python’s ecosystem (PySide6/PyQt, SQLite, NumPy/Pandas, packaging into a .exe) supports beautifully — allowing the entire system to be delivered as a clean, self-contained desktop application when the project is complete.

[DukeRichelieu]

Sitat

git add src/calculators/mainleg.py
git add src/calculators/start.py
git add src/calculators/price.py
git add src/calculators/pattern.py
git add test_final_four.py
git commit -m "[Calculators] Complete legacy system replication - final 4 calculators

🎉 LEGACY SYSTEM REPLICATION COMPLETE! 🎉

Final 4 calculators added:

Validation against legacy system (2024-12-31):
- MainLeg: -63.00 pts ✅
- Start: 10:05 ✅
- Price: +7.75 pts ✅
- Pattern: \$# ✅

Random sample test: 5/5 sessions passed all checks

All calculators use O(1) database queries with lazy-loaded swing data.
Complete feature parity with C# legacy system achieved.
Ready for production use and GUI development (Phase 6)."

 

I morgen blir det å gå gjennom alt, kjøre en komplett validering og så se om jeg får kjørt ut dette i et Excel-ark tilsvarende hva jeg alt har. 

EDIT: Eksempel på hvordan man må ta styringen og lede selv. Claude var klar til GUI-design alt i morgen:

 

Duke:

Great. As for next phase, I think we're skipping ahead. What I want next (tomorrow) is a full calculation of everything (swing algorithms and every calculator) populating a clean database. Let's check the performance of the engine and how fast everything is together. And document that with a comparison against the legacy system. 

If that runs smoothly, let's try to output an Excel file and see if that works. I just want to see with my own eyes that I replaced my legacy system. 

When that's done successfully, I think we need to handle the intraday calculations and associated datasets. Doesn't that precede GUI work?

🎯 PERFECT ROADMAP! You're absolutely right!

Endret fredag kl 21:05 av DukeRichelieu

[DukeRichelieu]

Neste fase etter dette blir også spennende. Intradagsberegninger (ikke end-of-day som er hva jeg har gjort til nå) for et gitt tidsvindu. Hyret det samme selskapet som utviklet originalen til å implementere dette og de brukte i hvert fall flere uker på jobben. 

Til deres forsvar tror jeg ikke den opprinnelige arkitekturen var designet for dette, men da burde de kanskje heller foreslått å skrive om den originale applikasjonen.

Mine nåværende utviklere er ganske selvsikre i hvert fall, så får vi se.  

Trenger ikke kjede dere med detaljer - og det er ikke alt jeg ønsker å dele uansett - men nøkkelen her er nok at arkitekturen er planlagt og gjennomtenkt før prosjektoppstart (så godt det lar seg gjøre av en lekmann og to AI-agenter som samarbeider med hverandre).  

[Camlon]

6 hours ago, strike_ said:

Flere nevner at de som vibe koder ikke får verifisert data. Hva mener dere med det? En god vibe koder tester selvfølgelig koden og ikke bare sørger for at den funker, men at den funker korrekt.

Visuell testing holder ikke. La meg beskrive det med et eksempel.

La oss si at du først har vibe-kodet dette:

if (GetUserAge(config.BirthDate) < 18)
{
    _childUser = await API.GetUserUnder18(config.UserId)
}

int GetUserAge(DateTime birthDate)
{
    var years = (DateTime.Now - birthDate).TotalDays / 365;
    return (int)years;
}

Og så, på et senere tidspunkt, i en helt annet fil, har du vibe-kodet dette:

if (GetAge(config.BirthDate) < 18)
{
    var address =
        userData.Child.Street.ToString()   + " " +
        userData.Child.Number.ToString()   + ", " +
        userData.Child.PostCode.ToString() + " " +
        userData.Child.City.ToString();
    ...
}

int GetAge(DateTime birthDate)
{
    var ageSpan = DateTime.Now - birthDate;
    var ageDate = new DateTime(ageSpan.Ticks);
    return ageDate.Year - 1;
}

Det som skjer da, er at kundene får en NullReferenceException i noen dager før brukeren faktisk fyller 18.

Som Vibe-koder får du da support-meldinger på et problem som allerede har “fikset seg selv” før du rekker å se på det. Hvis du er heldig, har du et noenlunde fornuftig loggsystem og klarer å finne ut at det var en NullReferenceException på address-linjen, men AI-en forstår ikke hvorfor det feilet og vil sannsynligvis bare slenge på noen ? så det feiler på et litt senere tidspunkt i stedet.

Du nevner til AI-en at brukeren er kanskje feilkonfigurert og du ber den fikse det. AI-en er enig, men i stedet for å rette det opprinnelige problemet, legger den inn en if som sier at hvis userData.Child er null, så skal man bruke Adult i stedet. Det gir nye feilmeldinger, som du igjen “fikser” med enda flere if-sjekker.

Til slutt ser det ut som alt fungerer, men du har ødelagt kodebasen med unødvendige if-sjekker, og du ender opp med å gi folk tilgang til voksentjenester før de egentlig er 18. Over tid blir alt så komplisert at du introduserer nye bugs hver gang du forsøker å fikse noe og du får ikke noe annet valg enn å ansette en profesjonell utvikler for å rydde opp i rotet du skapte med Vibe-koding.

Endret fredag kl 23:48 av Camlon

[Salvesen.]

DukeRichelieu skrev (11 timer siden):

Jeg spurte den ene utvikleren min (ChatGPT) og han svarer som følger:

Python only feels slow when the architecture is slow. HolyGrail avoids all the typical bottlenecks — no nested loops, no repeated scans, no per-session SQL calls, and all data is processed in a single pass with batch database writes. The result is that even though Python isn’t the fastest language, our design lets it act as a lightweight coordinator for extremely efficient operations, giving us full-pipeline performance (77k bars + 14k MicroSwings + 2.4k MacroSwings + 35 calculators) in ~0.3–0.5 seconds. And beyond speed, Python was chosen because the final phase of the HolyGrail project includes building a GUI + analytics tooling that Python’s ecosystem (PySide6/PyQt, SQLite, NumPy/Pandas, packaging into a .exe) supports beautifully — allowing the entire system to be delivered as a clean, self-contained desktop application when the project is complete.

Ja der ser en jo at det er brukt en hel del pakker, som forventet.

[DukeRichelieu]

Salvesen. skrev (3 timer siden):

Ja der ser en jo at det er brukt en hel del pakker, som forventet.

Packages we are using:

1. SQLite3 (Python Standard Library)

2. Datetime (Python Standard Library)

3. Dataclasses (Python Standard Library)

4. Pathlib (Python Standard Library)

Ingen NumPy/Pandas slik jeg har forstått det, men er nok aktuelt å bruke senere i prosjektet. 

 

[strike_]

20 hours ago, Camlon said:

Visuell testing holder ikke. La meg beskrive det med et eksempel.

La oss si at du først har vibe-kodet dette:

if (GetUserAge(config.BirthDate) < 18)
{
    _childUser = await API.GetUserUnder18(config.UserId)
}

int GetUserAge(DateTime birthDate)
{
    var years = (DateTime.Now - birthDate).TotalDays / 365;
    return (int)years;
}

Og så, på et senere tidspunkt, i en helt annet fil, har du vibe-kodet dette:

if (GetAge(config.BirthDate) < 18)
{
    var address =
        userData.Child.Street.ToString()   + " " +
        userData.Child.Number.ToString()   + ", " +
        userData.Child.PostCode.ToString() + " " +
        userData.Child.City.ToString();
    ...
}

int GetAge(DateTime birthDate)
{
    var ageSpan = DateTime.Now - birthDate;
    var ageDate = new DateTime(ageSpan.Ticks);
    return ageDate.Year - 1;
}

Det som skjer da, er at kundene får en NullReferenceException i noen dager før brukeren faktisk fyller 18.

Som Vibe-koder får du da support-meldinger på et problem som allerede har “fikset seg selv” før du rekker å se på det. Hvis du er heldig, har du et noenlunde fornuftig loggsystem og klarer å finne ut at det var en NullReferenceException på address-linjen, men AI-en forstår ikke hvorfor det feilet og vil sannsynligvis bare slenge på noen ? så det feiler på et litt senere tidspunkt i stedet.

Du nevner til AI-en at brukeren er kanskje feilkonfigurert og du ber den fikse det. AI-en er enig, men i stedet for å rette det opprinnelige problemet, legger den inn en if som sier at hvis userData.Child er null, så skal man bruke Adult i stedet. Det gir nye feilmeldinger, som du igjen “fikser” med enda flere if-sjekker.

Til slutt ser det ut som alt fungerer, men du har ødelagt kodebasen med unødvendige if-sjekker, og du ender opp med å gi folk tilgang til voksentjenester før de egentlig er 18. Over tid blir alt så komplisert at du introduserer nye bugs hver gang du forsøker å fikse noe og du får ikke noe annet valg enn å ansette en profesjonell utvikler for å rydde opp i rotet du skapte med Vibe-koding.

Det var et fint eksempel og det godt poeng. Jeg kan som nevnt ikke skrive kode så jeg aner egentlig ikke hva formålet denne koden er. Men utifra konteksten din og koden i seg selv så ser jeg at det har med å gjøre å beregne alder utifra bursdag. Ved første øykast ser jeg som en teknisk person en mulig logsik brist her og det er at du antar at det er 365 dager i året og ikke tar høyde før skuddår f.eks. Jeg antar at over tid vil dette føre til problemet du nevner.

Jeg som teknisk person vet godt hvor gull verdt en logg er når noe feiler, så når jeg vibe koder så sørger jeg for at det meste logges, både ved sukkess, ved evt feil og andre ting. Og jeg ville da fått en feilmelding som jeg ville foret AI med og den ville fixet problemet. Jeg vet ikke hvilken kode den hadde spyttet ut istedet, men jeg er ganske sikker på at jeg hadde klart å løst dette problemet på den god måte sammen med AI.

Men du har rett i at sikert mange vibe kodere ikke ville fanget opp dette med å ikke ta høyde for skuddår og ikke merket problemt før det oppstår. Men jeg leser faktisk over koden AI "gulper opp" før jeg tester den og ja jeg merker ofte feil i koden som AI kommer med selv om jeg ikke kan skrive kode. Før jeg lærte å starte en ny chat når den gjør feil på feil så var dette et gjentagende problem. Og selv på en kort chat kan den hallusinere, så det gjelder ikke bare lange chatter.

På en dårlig dag hadde kanskje ikke jeg heller merket dette  med å ikke ta høyde for skuddår før feilen hadde oppstått, men jeg er overbevist om at jeg hadde klart å fikse det fort. 

De sukessfullle vibe koderne jeg snakket om tidligere er alle veldig teknisk annlagt og jeg anser at vibe koding generelt er noe en med god teknsik innsikt driver med. Så jeg mener det er feil å annta at en vibe koder er bare den vanlige mannen i gata. Det er ofte de som har IT interesse og de fleste IT interessert har ganske god teknisk innsikt. Jeg tror du skal ha flaks om du finner en vibe koder blandt de som driver med sport som hoved hobby f.eks. Så å annta at en vibe koder ikke er en teksnik person syns jeg blir litt feil, som noen antyder litt mellom linjene her.

Men jeg er enig i at en erfaren utvikler ser mange problemer før en vibe koder gjør det og tilpasser koden etter det. Jeg syns likevel det er feil å si at AI bare spyr ut "oppgulp" og dårlig kode. Om man ikke guider den rett så ja, da får du mye rart det skal jeg være enig i. Men jeg tør påsta at mange av de som faktisk kan å kode også hadde gjort den feilen du beskriver, det er jo lett å glemme at det ikke alltid er 365 dager i året. 

Edit: Jeg ser også at muligens tids sone har noe å si i eksempelet ditt? Siden adresse og sånn er inne i bildet her.

Endret lørdag kl 20:05 av strike_

[DukeRichelieu]

Milepel!  

I dag har jeg (vi) fullført en komplett beregning fra scratch og eksport til Excel - 100 % validert mot min originale applikasjon. Det vil si - vi har gjenskapt det jeg alt har. Mangler nå bare en GUI for å komplettere det, men siden min plan er å videreutvikle dette utover hva jeg alt har legger jeg det på is inntil videre og fortsetter med videre utvikling.

Liker ikke helt tallene hittil, men både Claude og ChatGPT har sagt at dette skal vi kunne optimalisere.

Det vil uansett bli bedre enn min originale applikasjon som bruker en del tid på å oppdatere - selv uten 'ny data'. 

Neste steg:

1) Oppdatering av prosjektdokumentasjon

2) Rydding av prosjektmappen

Jeg planlegger nå å gå over til Claude Desktop med MCP (read only i starten) og se om det gir en bedre arbeidsflyt.

 

[DukeRichelieu]

Etter en meget produktiv fredag og lørdag ble det mye surring i går, søndag. Det vil si, vi nærmet oss mål og nådde 90 % suksess, men jeg følte ikke at det var noen intelligens bak det. De bare surret i vei og forsøkte å fikse litt her og litt der.

Litt som vi har snakket om før og som @strike_ har nevnt noen ganger i forhold til når samtalene begynner å bli lange. Jeg besluttet derfor å revertere til forrige git, arkivere arbeidet vi hadde gjort og starte i dag fra scratch, men hyper fokusert og med gårsdagens lærdom i bakhodet:
 

Sitat

 

"I need you guys extra sharp and focused today as we were spinning our wheels yesterday spending too much time on something which should have been a trivial task. 

In carpentry, we have a saying: "Measure twice, cut once!" Let's apply that today. Let's think things through before we just start coding and hope it will work out. 

Let's nail it on attempt one!

Instructions coming in my next message. Stay tuned. No summaries required, yet."

 

Lot de se opprinnelig versjon (Excel eksport til en ny fil) som fungerte og det de hadde laget i går (Excel eksport, men til en eksisterende arbeidsbok/tabell). Sa at jeg mistenkte at koden var sub-optimal siden det var mye frem og tilbake. Begge var enige i at koden ikke var optimal. LOL. 

Etter litt diskusjon og klargjøring frem og tilbake med meldinger fra den ene til den andre var vi enige om at alt så strøkent ut på papiret og vi var klare til å kode (begge var enige i at vi burde ta det helt fra scratch). Claude kodet et nytt skript og det fungerte 100 % på første forsøk. 

Strøkent.  

Det er ikke alltid så lett å merke det når man sitter midt i det, men har erfart at dette skjer et par ganger nå. Virker som de begynner å famle i blinde og mister litt det store bildet. Da er det som regel beste å ta det fra scratch og være ekstremt tydelig og enige om hva vi skal gjøre før vi begynner.