IBM-drop volgend op Claudeuitspraken ivm overzetting COBOL?

Vega

Vega

Well-known member
Las gisteren een artikel over dat een melding van Anthropic, waarin ze zeiden dat Claude kon helpen om ouwbollige COBOL om te zetten naar JAVA/Python, eventjes 30 miljard (13%) van de marktwaarde van IBM had afgescheerd...

Zijn er mensen die iets meer mee zijn met technologie/coderen die dit ook zien gebeuren? Ik denk even aan de duizenden AS400-systemen die op COBOL draaien en er niet uit geraken vanwege te duur en teveel tijd om over te zetten...

Mij lijkt dit als totale noob toch een gat in de markt om deze transformaties een pak efficiënter/sneller/goedkoper aan te pakken en te zorgen dat al die banken etc. overstappen naar een modern systeem?
 
Enerzijds is het probleem dat je nog steeds COBOL moet begrijpen om de vertaling vlotjes te valideren, LLMs blijven stochastisch. Daarnaast gaat het blijkbaar vaak om gigantische codebases, maar ook daaraan gelinkte data architectures, hardware reliability, efficiëntie etc., waardoor het probleem veel ruimer is dan "COBOL omzetten naar insert modern alternative and call it a day" maar dus een ganse ecosysteem migratie.

Hier wat interessante kanttekeningen:
 
Vega zei:
Las gisteren een artikel over dat een melding van Anthropic, waarin ze zeiden dat Claude kon helpen om ouwbollige COBOL om te zetten naar JAVA/Python, eventjes 30 miljard (13%) van de marktwaarde van IBM had afgescheerd...

Zijn er mensen die iets meer mee zijn met technologie/coderen die dit ook zien gebeuren? Ik denk even aan de duizenden AS400-systemen die op COBOL draaien en er niet uit geraken vanwege te duur en teveel tijd om over te zetten...

Mij lijkt dit als totale noob toch een gat in de markt om deze transformaties een pak efficiënter/sneller/goedkoper aan te pakken en te zorgen dat al die banken etc. overstappen naar een modern systeem?
Klik om te vergroten...
Urgh this again. Ja een paar weken terug gebeurde hetzelfde met een aantal security bedrijven toen claude hun 'security claude' aanbood.

Toont gewoon weeral aan dat de markt bepaald wordt door mensen die eigenlijk niets van technologie snappen.
 
Valkuil zei:
Enerzijds is het probleem dat je nog steeds COBOL moet begrijpen om de vertaling vlotjes te valideren, LLMs blijven stochastisch. Daarnaast gaat het blijkbaar vaak om gigantische codebases, maar ook daaraan gelinkte data architectures, hardware reliability, efficiëntie etc., waardoor het probleem veel ruimer is dan "COBOL omzetten naar insert modern alternative and call it a day" maar dus een ganse ecosysteem migratie.

Hier wat interessante kanttekeningen:
Klik om te vergroten...
Het ding is toch dat ze niet cobol moeten omzetten? Ze moeten functionele analyse halen uit de cobol programma's, en diezelfde functies inbouwen in iets modern.

Mijn huidige klant gaat migreren naar een nieuw Backoffice systeem. Dat is een product dat miljoenen kost. Ik heb eens via Claude gevraagd "maak eens een backoffice voor een verzekeraar, het moet schaalbaar zijn naar cloud-omgeving en 100000-en claims aankunnen. Een paar uurtjes later heb ik een werkend systeem waar de alle functionaliteiten die ik kon bedenken inzitten en werken.
Dat gaat dan over pakweg 2 dagen van een consultant en 20€ aan claude-kosten...
 
anders. zei:
Het ding is toch dat ze niet cobol moeten omzetten? Ze moeten functionele analyse halen uit de cobol programma's, en diezelfde functies inbouwen in iets modern.
Klik om te vergroten...
Wat is het verschil? Een rechtstreekse vertaling, of eerst een functionele analyse en dan heropbouw: stochasticiteit blijft een issue en ik zou LLMs niet vertrouwen voor kritieke applicaties zonder experts die mij 100% kunnen bevestigen dat de analyse van die LLM correct is. Ze zijn veel betrouwbaarder geworden, maar ze blijven in mijn ervaring veel nuances missen tenzij je er specifiek naar prompt en dan nog is het absoluut niet fail-safe.
anders. zei:
Mijn huidige klant gaat migreren naar een nieuw Backoffice systeem. Dat is een product dat miljoenen kost. Ik heb eens via Claude gevraagd "maak eens een backoffice voor een verzekeraar, het moet schaalbaar zijn naar cloud-omgeving en 100000-en claims aankunnen. Een paar uurtjes later heb ik een werkend systeem waar de alle functionaliteiten die ik kon bedenken inzitten en werken.
Dat gaat dan over pakweg 2 dagen van een consultant en 20€ aan claude-kosten...
Klik om te vergroten...
Heb je de functionaliteit en schaalbaarheid getest? Of berust je toch nog op je eigen kennis en ervaring dat wat Claude uitspuwt inderdaad schaalbaar en functioneel zou moeten zijn? En ben je dan ook een domain expert die weet welke functionaliteiten nodig zijn, heb je dat moeten prompten of zal in de praktijk daarvoor nog steeds iemand met grondige kennis en ervaring in de business nodig zijn?

De studies zeggen voldoende denk ik: er zijn het en der (short term) efficiency gains, maar de menselijke input en interactie, en revisie door een expert blijven essentieel.

En dan eerder off topic: willen we als werknemer echt validator van LLMs worden? Je hoort in die richting toch ook meer en meer protest. Mag het ook nog een beetje plezierig en intellectueel uitdagend zijn? Laten we ons nog eens vangen aan de beloften van big tech waarvan de bijdrage/afbreuk aan de samenleving uiteindelijk niet te voorzien is? Après moi le déluge.
 
Valkuil zei:
Wat is het verschil? Een rechtstreekse vertaling, of eerst een functionele analyse en dan heropbouw: stochasticiteit blijft een issue en ik zou LLMs niet vertrouwen voor kritieke applicaties zonder experts die mij 100% kunnen bevestigen dat de analyse van die LLM correct is. Ze zijn veel betrouwbaarder geworden, maar ze blijven in mijn ervaring veel nuances missen tenzij je er specifiek naar prompt en dan nog is het absoluut niet fail-safe.

Heb je de functionaliteit en schaalbaarheid getest? Of berust je toch nog op je eigen kennis en ervaring dat wat Claude uitspuwt inderdaad schaalbaar en functioneel zou moeten zijn? En ben je dan ook een domain expert die weet welke functionaliteiten nodig zijn, heb je dat moeten prompten of zal in de praktijk daarvoor nog steeds iemand met grondige kennis en ervaring in de business nodig zijn?

De studies zeggen voldoende denk ik: er zijn het en der (short term) efficiency gains, maar de menselijke input en interactie, en revisie door een expert blijven essentieel.

En dan eerder off topic: willen we als werknemer echt validator van LLMs worden? Je hoort in die richting toch ook meer en meer protest. Mag het ook nog een beetje plezierig en intellectueel uitdagend zijn? Laten we ons nog eens vangen aan de beloften van big tech waarvan de bijdrage/afbreuk aan de samenleving uiteindelijk niet te voorzien is? Après moi le déluge.
Klik om te vergroten...
Het verschil is dat een tool geen 1-op-1 vertaling moet zijn. Een tool moet u huidige business noden ondersteunen, niet de cobol code van de noden van 50 jaar geleden.
En de reden dat die projecten falen is omdat ge geen 150 man vindt om in cobol te gaan uitzoeken wat die spaghetti deed. En daar is een LLM dus veel beter in. Er zegt ook niemand dat er geen menselijke interactie nodig is he. Je hebt gewoon geen team van 100-en ontwikkelaars nodig voor zo'n project.

En ja, dat jij als werknemer dat niet leuk vindt, dat kan goed zijn maar that's a you-problem. De lantaarnopsteker zal ook wel gevonden hebben dat een wandeling 's avonds beter was dan het knopje van de straatlantaarns aan te doen...
 
anders. zei:
Het verschil is dat een tool geen 1-op-1 vertaling moet zijn. Een tool moet u huidige business noden ondersteunen, niet de cobol code van de noden van 50 jaar geleden.
Klik om te vergroten...
Er is geen verschil inzake het probleem met stochasticiteit: zowel een rechtstreekse vertaling als het heropbouwen zullen er last van ondervinden. Als je geen COBOL kan lezen, zal je niet weten of er een fout in de vertaling zit, noch als er een fout uit de functionele analyse rolt. Ik weet niet goed wat je nu voorstelt. Je kan heropbouwen van nul maar dat gaat u alsnog enorm veel problemen opleveren want er zullen veel details over het hoofd gezien worden.
anders. zei:
En de reden dat die projecten falen is omdat ge geen 150 man vindt om in cobol te gaan uitzoeken wat die spaghetti deed. En daar is een LLM dus veel beter in. Er zegt ook niemand dat er geen menselijke interactie nodig is he. Je hebt gewoon geen team van 100-en ontwikkelaars nodig voor zo'n project.
Klik om te vergroten...
Wel ja, zie opmerking hierboven, het zal goed werken totdat het niet werkt en dan mag je alsnog de COBOL code gaan uitpluizen om te zien welke fout je hebt gemaakt. Veel succes dan met een team Claude prompters.
anders. zei:
En ja, dat jij als werknemer dat niet leuk vindt, dat kan goed zijn maar that's a you-problem. De lantaarnopsteker zal ook wel gevonden hebben dat een wandeling 's avonds beter was dan het knopje van de straatlantaarns aan te doen...
Klik om te vergroten...
Er is het effect op het individu, maar mijn statement/vraag gaat veel ruimer dan de gevolgen voor het individu...
 
Valkuil zei:
Er is geen verschil inzake het probleem met stochasticiteit: zowel een rechtstreekse vertaling als het heropbouwen zullen er last van ondervinden. Als je geen COBOL kan lezen, zal je niet weten of er een fout in de vertaling zit, noch als er een fout uit de functionele analyse rolt. Ik weet niet goed wat je nu voorstelt. Je kan heropbouwen van nul maar dat gaat u alsnog enorm veel problemen opleveren want er zullen veel details over het hoofd gezien worden.

Wel ja, zie opmerking hierboven, het zal goed werken totdat het niet werkt en dan mag je alsnog de COBOL code gaan uitpluizen om te zien welke fout je hebt gemaakt. Veel succes dan met een team Claude prompters.

Er is het effect op het individu, maar mijn statement/vraag gaat veel ruimer dan de gevolgen voor het individu...
Klik om te vergroten...
En als er met het Cobol systeem iets mis gaat? Bugvrije software bestaat niet, dus dan moet je evengoed de Cobol code gaan uitpluizen bij elke bug.

Je kan perfect een functionele analyse doen zonder de code te analyseren. Je kan zelfs een functionele analyse doen zonder de bestaande tooling te bekijken. Want een functionele analyse omschrijft de functies die een tool moet doen.
Datgene dat momenteel problemen oplevert, is dat mensen niet weten welke functionaliteiten er eigenlijk zijn gebouwd in het verleden, maar dat is puur een change management issue dat mensen persé "dezelfde" functionaliteit willen ipv eens te kijken wat ze nu eigenlijk nodig hebben.

En AI is 100x beter dan eender welke analist om die bestaande code te analyseren en samen te vatten wat die nu eigenlijk doe. Waarom zou je er wel op vertrouwen dan een analist u wél de juiste lijst van functionaliteiten geeft?
 
anders. zei:
En als er met het Cobol systeem iets mis gaat? Bugvrije software bestaat niet, dus dan moet je evengoed de Cobol code gaan uitpluizen bij elke bug.
Klik om te vergroten...
Dan heb je je team COBOL programmeurs met veelal gezapig stijgende, vrij voorspelbare kostprijs, die het snel zouden moeten kunnen fixen zoals ze het altijd al deden?
anders. zei:
Je kan perfect een functionele analyse doen zonder de code te analyseren. Je kan zelfs een functionele analyse doen zonder de bestaande tooling te bekijken. Want een functionele analyse omschrijft de functies die een tool moet doen.
Datgene dat momenteel problemen oplevert, is dat mensen niet weten welke functionaliteiten er eigenlijk zijn gebouwd in het verleden, maar dat is puur een change management issue dat mensen persé "dezelfde" functionaliteit willen ipv eens te kijken wat ze nu eigenlijk nodig hebben.
Klik om te vergroten...
Iedereen die ooit een large-scale functionele analyse heeft gedaan weet dat het niet zo simpel is in de praktijk. Gebruikers weten voor hun domein wel voor 95% wat de nodige functionaliteit is (die 5% die vergeten wordt, is a pain in the ass), maar ze weten zeker niet hoe dat afhangt van en interageert met de functionaliteiten van team xyz. Been there done that, er worden tig dingen over het hoofd gezien die pas komen bovendrijven bij uitgebreide praktijktesten. Die moeten dan opgelapt worden, extra costs, met veelal een architectuur die al niet meer zo clean is want her en der moeten er onvoorziene dingen bijgeplakt worden etc. etc. Ik ken van die migraties met functionele analyse "from scratch" waar er 5 jaar en miljoenen euro's later nog altijd lijken uit de kast vallen en de business as usual een fractie van de kost zou geweest zijn. Begeleid door zgn. expert consultancy teams in migraties. Je weet niet waar je eindigt met zo'n zaken en dat is waarom velen blijven zitten in hun oude ecosysteem (dat evenzeer bulkt van de koterijen hoor). En de manager die het goedkope alternatief naar voor schoof? Die is al lang gaan vliegen.
anders. zei:
En AI is 100x beter dan eender welke analist om die bestaande code te analyseren en samen te vatten wat die nu eigenlijk doe. Waarom zou je er wel op vertrouwen dan een analist u wél de juiste lijst van functionaliteiten geeft?
Klik om te vergroten...
Niet akkoord. AI is goed om 90, 95, 99 whatever % juist te capteren. Opnieuw zit je met de x% missing/foute informatie die een pain in the ass is. En als je dan Claude gaat prompten met je issue heb je een grote kans dat hij begint te hallucineren en 5, 10, 20x met een fout plan van aanpak komt. Uit mijn ervaring zal iemand met een grondige kennis van de codebase het u dan veel sneller kunnen zeggen en fixen.
 
Valkuil zei:
Dan heb je je team COBOL programmeurs met veelal gezapig stijgende, vrij voorspelbare kostprijs, die het snel zouden moeten kunnen fixen zoals ze het altijd al deden?

Iedereen die ooit een large-scale functionele analyse heeft gedaan weet dat het niet zo simpel is in de praktijk. Gebruikers weten voor hun domein wel voor 95% wat de nodige functionaliteit is (die 5% die vergeten wordt, is a pain in the ass), maar ze weten zeker niet hoe dat afhangt van en interageert met de functionaliteiten van team xyz. Been there done that, er worden tig dingen over het hoofd gezien die pas komen bovendrijven bij uitgebreide praktijktesten. Die moeten dan opgelapt worden, extra costs, met veelal een architectuur die al niet meer zo clean is want her en der moeten er onvoorziene dingen bijgeplakt worden etc. etc. Ik ken van die migraties met functionele analyse "from scratch" waar er 5 jaar en miljoenen euro's later nog altijd lijken uit de kast vallen en de business as usual een fractie van de kost zou geweest zijn. Begeleid door zgn. expert consultancy teams in migraties. Je weet niet waar je eindigt met zo'n zaken en dat is waarom velen blijven zitten in hun oude ecosysteem (dat evenzeer bulkt van de koterijen hoor). En de manager die het goedkope alternatief naar voor schoof? Die is al lang gaan vliegen.

Niet akkoord. AI is goed om 90, 95, 99 whatever % juist te capteren. Opnieuw zit je met de x% missing/foute informatie die een pain in the ass is. En als je dan Claude gaat prompten met je issue heb je een grote kans dat hij begint te hallucineren en 5, 10, 20x met een fout plan van aanpak komt. Uit mijn ervaring zal iemand met een grondige kennis van de codebase het u dan veel sneller kunnen zeggen en fixen.
Klik om te vergroten...
Een team COBOL programmeurs. 1 van de grootste sociaal secretariaten waar ik gezeten heb, was zo'n bedrijf dat nog op Cobol zat (terwijl ze hun backoffice project naar Java al hadden omgeschakeld, maar door dat gebrek aan change-management nooit live zijn durven gaan). Daar zaten in heel het bedrijf nog 2 60'ers die de cobol code konden lezen. Als daar een bug boven kwam, was het antwoord gewoon "tja".

Wij zijn nu volop bezig met zo'n migratie. In die migratie worden effectief hopen bugs gevonden in de bestaande SAS code die al jaren op productie draait. En dan zijn er nog een hele hoop bugs die opnieuw gebouwd worden omdat de offshore ontwikkelaars gewoon de bestaande code herbouwen in een andere taal.
Als we de gebruikelijke managers hun zin hadden laten doen, gingen we 1000-en rapporten moeten ombouwen. Want "dat is zo opgeleverd, dus dat moet 1 op 1 overgezet worden". Er werd zelfs nog niet gedacht om eens te kijken naar functionaliteit/duplicatie/overlap/gebruik. Een AI analyse daarop gaat mij met grote zekerheid geven welke rapporten weg mogen, welke samengevoegd kunnen worden, en welke gewoon nooit geopend geweest zijn. Voor de vorige migratie zijn er daar 2 FTE's 2 jaar mee bezig geweest, waarna ze gewoon gezegd hebben "zet alles maar over".

AI doet misschien 90% juist, mensen doen met wat geluk 50% juist als het op analyse aankomt.
 
anders. zei:
Een team COBOL programmeurs. 1 van de grootste sociaal secretariaten waar ik gezeten heb, was zo'n bedrijf dat nog op Cobol zat (terwijl ze hun backoffice project naar Java al hadden omgeschakeld, maar door dat gebrek aan change-management nooit live zijn durven gaan). Daar zaten in heel het bedrijf nog 2 60'ers die de cobol code konden lezen. Als daar een bug boven kwam, was het antwoord gewoon "tja".

Wij zijn nu volop bezig met zo'n migratie. In die migratie worden effectief hopen bugs gevonden in de bestaande SAS code die al jaren op productie draait. En dan zijn er nog een hele hoop bugs die opnieuw gebouwd worden omdat de offshore ontwikkelaars gewoon de bestaande code herbouwen in een andere taal.
Als we de gebruikelijke managers hun zin hadden laten doen, gingen we 1000-en rapporten moeten ombouwen. Want "dat is zo opgeleverd, dus dat moet 1 op 1 overgezet worden". Er werd zelfs nog niet gedacht om eens te kijken naar functionaliteit/duplicatie/overlap/gebruik. Een AI analyse daarop gaat mij met grote zekerheid geven welke rapporten weg mogen, welke samengevoegd kunnen worden, en welke gewoon nooit geopend geweest zijn. Voor de vorige migratie zijn er daar 2 FTE's 2 jaar mee bezig geweest, waarna ze gewoon gezegd hebben "zet alles maar over".

AI doet misschien 90% juist, mensen doen met wat geluk 50% juist als het op analyse aankomt.
Klik om te vergroten...
Ik werk in bio/medtech dus dat verklaart misschien de grotere kwaliteit van de opgeleverde software/management? Twee ouw peekes die een kritieke business component moeten rechthouden, ik kan het me niet voorstellen. Maar ja, mensenlevens op het spel i.p.v. een verkeerd rapportje zeker? Ik kan mij niet inbeelden dat ook in bv. de financiële sector de code vol bugs zit of analisten er zo met hun pet naar gooien? Dat herbouwen met de bugs erin kan ik mij ook maar deels in herkennen; je hebt natuurlijk altijd minder kritische geesten in elk team maar toch niet in die mate dat ze allemaal bugs simpelweg overnemen. Maar ik heb dan ook geen ervaring met offshore teams, kennis van de business zullen die wel niet hebben wat het verhelpen van bugs moeilijk maakt.

De conclusie moet dan misschien zijn dat AI zijn plek heeft in businesses waar een occasionele fout niet zo erg is?
 
anders. zei:
Het ding is toch dat ze niet cobol moeten omzetten? Ze moeten functionele analyse halen uit de cobol programma's, en diezelfde functies inbouwen in iets modern.

Mijn huidige klant gaat migreren naar een nieuw Backoffice systeem. Dat is een product dat miljoenen kost. Ik heb eens via Claude gevraagd "maak eens een backoffice voor een verzekeraar, het moet schaalbaar zijn naar cloud-omgeving en 100000-en claims aankunnen. Een paar uurtjes later heb ik een werkend systeem waar de alle functionaliteiten die ik kon bedenken inzitten en werken.
Dat gaat dan over pakweg 2 dagen van een consultant en 20€ aan claude-kosten...
Klik om te vergroten...
Bedoel je een idee voor een architectuur of daadwerkelijk een werkend systeem?
 
SithCloud zei:
Bedoel je een idee voor een architectuur of daadwerkelijk een werkend systeem?
Klik om te vergroten...
Werkend systeem. Draait hier nu in een dockercontainer op mijn NAS.

Een paar van de dingen die er bijvoorbeeld inzitten:

Role-based Access Control met 5 rollen: broker (kan enkel klanten aanmaken, polissen aanvragen, claims aanmaken ... Ziet ook enkel data voor zijn klanten), agent (kan polissen/claims/... goedkeuren en verder opvolgen), admin, helpdesk (kan enkel de taal aanpassen voor de applicatie voor een specifieke broker of customer) en customer (heeft een eigen portaal om zijn eigen polissen/claims te zien).

Volledige workflow voor claims en polissen, documentenbeheer, task queue, calendar view, ...

Integratie met e-id voor aanmaken particuliere klanten, en met KBO voor ondernemingen

Rate tables om de prijszetting van producten te bepalen

Volledige rapportering

Audit log op alles

Customer deduplication. Op basis van een aantal criteria zoekt hij mogelijks dubbele customers die je dan kan mergen (verhangen van polissen etc)

Automation rules, Email templates, ... op basis van statuschanges van claims en polissen

Volledig User management

Allemaal in de huisstijl van mijn klant (Claude heeft de publieke github pagina gevonden waar die beschreven stond)

Multi-language (NL, FR, EN)
 
Hier ook aan het experimenteren met claude code: kleine kmo met voorhistorische sofrware (acces databases en foxpro).
Al 2 rondes consultancy gepasseerd die hun vingers eraan verbrand hebben. Weekendje chatten met claude en ik heb een werkend prototype dat al -tig stappen verder staat.

Gaat dit ooit naar productie: hell no, maar het is wel een verdomd handige tool om een brug te maken tussen de bazen hogerop en developers om het te laten uitvoeren.

(claude kreeg ook nooit toegang directe toegang tot bedrijfsdata, maar voorbeelden en table headers om alles samen te puzzelen)
 
eS zei:
Hier ook aan het experimenteren met claude code: kleine kmo met voorhistorische sofrware (acces databases en foxpro).
Al 2 rondes consultancy gepasseerd die hun vingers eraan verbrand hebben. Weekendje chatten met claude en ik heb een werkend prototype dat al -tig stappen verder staat.

Gaat dit ooit naar productie: hell no, maar het is wel een verdomd handige tool om een brug te maken tussen de bazen hogerop en developers om het te laten uitvoeren.

(claude kreeg ook nooit toegang directe toegang tot bedrijfsdata, maar voorbeelden en table headers om alles samen te puzzelen)
Klik om te vergroten...
Hoe zie jij die brug dan? Als het is voor wat UX of wat te doen: sure. Maar je gaat die devs toch niet zeggen 'en zie, mijn gebricoleerde code is een voorbeeld van hoe ik het wil'?
 
SithCloud zei:
Hoe zie jij die brug dan? Als het is voor wat UX of wat te doen: sure. Maar je gaat die devs toch niet zeggen 'en zie, mijn gebricoleerde code is een voorbeeld van hoe ik het wil'?
Klik om te vergroten...
Verschillende mogelijkheden. Gaat in mijn geval om erp pakket en link met boekhouding + een hoop achterliggende analysetabellen in excel:
  • ux model voor de verschillende views en rapporteren die wenselijk zijn. Een quick en dirty demo waar ik zelf mee kan spelen en snel kleine zaken aan kan toevoegen. Dat kan echt heel simpel zijn van bv een werking van een bepaalde filter tot een compleet dashboard of extra functionaliteit.
  • Aanzet tot databasemodel om de linken tussen de verschillende tabellen uit te tekenen. Een van de tools is 20jaar oud, de achterliggende programmacode is niet toegankelijk, dus het is voor ons zelfs soms niet duidelijk hoe bepaalde zaken berekend worden en hoe bepaalde parameters in rekening gebracht worden.

    De processie van echternach de laatste jaren:
    • 'Hoe moet dit berekend worden' Ancien zeg:"A+B-C=D'
    • consultant werkt een halve dag aan €100/h, rapport wordt getest, geeft iets compleet anders
    • Ancien: 'Ah nee, het is A-B+C=D'
    • Consultant werkt verder, rekening tikt aan, een week later een volgende meeting of vast te stellen dat het nog niet werkt
    • Feedback ancien: 'maar wat doet gij nu, ik heb u gezegd dat dat x y z moet zijn'
    • Rinse repeat voor elke klein detail

      => de laatste weken ben ik zelf beginnen bricoleren, en heb ik hetzelfde trial en error spel gedaan, maar dan met een bot van €20/maand die op een paar minuten tijd een nieuwe versie in elkaar flanst. Resultaat: na een middagje chatten heb ik een export script die exact hetzelfde resultaat aanlevert als het rapport van de oude tool. Een resultaat dat ik via een eenvoudige test in excel kan nakijken voor een historiek van 20jaar.
      => op basis hiervan heb ik een mermaid diagram laten genereren welke - na de nodige manuele revisies- nu als basis dient om deze logica aan een effectieve developer uit te leggen.
 
eS zei:
Verschillende mogelijkheden. Gaat in mijn geval om erp pakket en link met boekhouding + een hoop achterliggende analysetabellen in excel:
  • ux model voor de verschillende views en rapporteren die wenselijk zijn. Een quick en dirty demo waar ik zelf mee kan spelen en snel kleine zaken aan kan toevoegen. Dat kan echt heel simpel zijn van bv een werking van een bepaalde filter tot een compleet dashboard of extra functionaliteit.
  • Aanzet tot databasemodel om de linken tussen de verschillende tabellen uit te tekenen. Een van de tools is 20jaar oud, de achterliggende programmacode is niet toegankelijk, dus het is voor ons zelfs soms niet duidelijk hoe bepaalde zaken berekend worden en hoe bepaalde parameters in rekening gebracht worden.

    De processie van echternach de laatste jaren:
    • 'Hoe moet dit berekend worden' Ancien zeg:"A+B-C=D'
    • consultant werkt een halve dag aan €100/h, rapport wordt getest, geeft iets compleet anders
    • Ancien: 'Ah nee, het is A-B+C=D'
    • Consultant werkt verder, rekening tikt aan, een week later een volgende meeting of vast te stellen dat het nog niet werkt
    • Feedback ancien: 'maar wat doet gij nu, ik heb u gezegd dat dat x y z moet zijn'
    • Rinse repeat voor elke klein detail

      => de laatste weken ben ik zelf beginnen bricoleren, en heb ik hetzelfde trial en error spel gedaan, maar dan met een bot van €20/maand die op een paar minuten tijd een nieuwe versie in elkaar flanst. Resultaat: na een middagje chatten heb ik een export script die exact hetzelfde resultaat aanlevert als het rapport van de oude tool. Een resultaat dat ik via een eenvoudige test in excel kan nakijken voor een historiek van 20jaar.
      => op basis hiervan heb ik een mermaid diagram laten genereren welke - na de nodige manuele revisies- nu als basis dient om deze logica aan een effectieve developer uit te leggen.
Klik om te vergroten...
Die mermaid diagrammen slappen wel. ik gebruik dat echt constant daarvoor.
Maar bon tof om te horen wat gij ermee doet.
 
eS zei:
(claude kreeg ook nooit toegang directe toegang tot bedrijfsdata, maar voorbeelden en table headers om alles samen te puzzelen)
Klik om te vergroten...
+
eS zei:
Een van de tools is 20jaar oud, de achterliggende programmacode is niet toegankelijk, dus het is voor ons zelfs soms niet duidelijk hoe bepaalde zaken berekend worden en hoe bepaalde parameters in rekening gebracht worden.

De processie van echternach de laatste jaren:
  • 'Hoe moet dit berekend worden' Ancien zeg:"A+B-C=D'
  • consultant werkt een halve dag aan €100/h, rapport wordt getest, geeft iets compleet anders
  • Ancien: 'Ah nee, het is A-B+C=D'
  • Consultant werkt verder, rekening tikt aan, een week later een volgende meeting of vast te stellen dat het nog niet werkt
  • Feedback ancien: 'maar wat doet gij nu, ik heb u gezegd dat dat x y z moet zijn'
  • Rinse repeat voor elke klein detail
Klik om te vergroten...
Het enige probleem wordt duidelijk in de 2e quote :P En die persoon die "tegenwerkt" (al dan niet bewust), omzeil je niet met de manier dat je AI gebruikt... En zelfs met toegang tot de bedrijfsdata, zou AI de berekeningen mogelijks foutief genereren.
 
Je moet ingelogd zijn om te kunnen reageren. Aanmelden | Registreren
Terug
Bovenaan