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 4 timer siden 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 1 time siden 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).