Devin, de eerste AI software engineer?

[kwetterpletter]

Ik kom op meerdere plekken op het internet Devin AI tegen: https://www.cognition-labs.com/blog

Hoewel ik over het algemeen redelijk sceptisch ben over AI moet ik zeggen dat ik de demo's behoorlijk overtuigend vind. De vraag is natuurlijk in hoeverre er aan cherry picking gedaan is. Voor hetzelfde geld laten ze honderden gefaalde pogingen niet zien.

Toch denk ik dat ze op de goede weg zijn. Elk probleem dat Devin al dan niet oplost is weer data waar hij van kan leren. Ik heb het gevoel dat de dagen (jaren waarschijnlijk) van de software engineer geteld zijn.

[chielsen]

Zeker interessant. Denk niet dat de dagen van software developers geteld zijn maar gaan zeker weer veranderen.
Ik ga alweer een tijdje mee en het huidge werk is al heel anders dan 25 jaar geleden. Toch is een bepaalde kern nog steeds hetzelfde.
Vergeet niet dat er nu mega veel geld naar AI initiaven gaan. Wat je nu qua ontwikkeling ziet kan je denk ik niet zomaar extrapoleren. Chips gaan niet heel veel beter worden. Extra context meegeven is heel duur / complex. Ik denk dus dat er nog steeds een mens. Aan de juiste touwtjes moet trekken en controleren.

[kwetterpletter]

De transistors in de chips zullen niet snel veel beter worden maar de chips voor AI kunnen analoog worden en eventueel zelfs optisch. Op die manier is er nog enorm veel ruimte voor inference om sneller en goedkoper te worden.
Ook algorithmisch kan er waarschijnlijk nog een boel verbeterd worden. Ik kan me voorstellen dat het beter is om code top down te genereren ipv begin tot einde bijvoorbeeld.
Als je ziet hoe hard LLMs en andere generatieve AI gaat zou het me zwaar verbazen als dit voorlopig niet veel beter wordt.

[Anoniem: 294759]

Ik geloof er ook niet in dat AI de software ontwikkelaar zal vervangen.

Devin kan wel handig zijn in het opsporen van mogelijke fouten en het toepassen van ‘best practices’ en ander algemeen gebruik.

Het zou backend development sneller kunnen maken. Bijvoorbeeld een API heeft vaak dezelfde benodigdheden los van bijvoorbeeld type database. Die tijd kan je weer besteden aan het verfijnen van andere zaken.

[ZpAz]

Ik denk dat deze video mijn standpunt wel aardig beschrijft.

Ik gebruik zelf al met enige regelmaat AI tijdens het programmeren en Google / StackOverflow steeds minder. Een nieuwe tool in mijn toolbox. Maar ik zie "de hamer" de "timmerman" nog niet vervangen.

[ Voor 26% gewijzigd door ZpAz op 14-03-2024 00:21 ]

[kevinr1]

Hoe doet devin het met applicaties zoals Ansible?

[RayNbow]

Maak me wakker wanneer een AI dit snapt.

[Rmg]

Ach elke paar jaar is er wel een nieuwe hype, model driven, nocode/lowcode, nieuwe talen, etc etc en uiteindelijk doe ik het grootste deel van de tijd nog steeds C. En dat zal de komende 10 jaar niet veranderen.

Als er iets veranderd is dat ik straks (5 jaar?, zo snel is de ai acceptance niet op codebases met veel IP) werk loop voor te kauwen om in een AI instance te proppen en niet meer voor een Indiër.

[ Voor 9% gewijzigd door Rmg op 14-03-2024 07:43 ]

[Opifex]

RayNbow schreef op donderdag 14 maart 2024 @ 07:30:
Maak me wakker wanneer een AI dit snapt.

De filmpjes tonen dat het dat al kan. Misschien niet "snappen" (want dat is een concept dat mogelijks niet van toepassing is op machines), maar wel correct kan toepassen.

[RayNbow]

Opifex schreef op donderdag 14 maart 2024 @ 08:16:
[...]


De filmpjes tonen dat het dat al kan. Misschien niet "snappen" (want dat is een concept dat mogelijks niet van toepassing is op machines), maar wel correct kan toepassen.

Toepassen in welk opzicht? Deze boeken bevatten in ieder geval geen broncode.

[boxlessness]

RayNbow schreef op donderdag 14 maart 2024 @ 09:16:
[...]

Toepassen in welk opzicht? Deze boeken bevatten in ieder geval geen broncode.

Ik ben in het verleden zijdelings betrokken geweest bij een project waar men medische guidelines omzette naar beslisbomen/flowcharts. Medische guidelines zijn enorme lappen aan ongestructureerde tekst met condities/overwegingen/achtergrondinformatie/acties/etc. Uit de (handmatige) steekproeven die men gedaan heeft bleek dat deze guidelines prima om te zetten waren naar een IfThisThenThat-vorm. Een arts kan dan nog steeds afwijken van het normale pad... maar als dat gebeurt is dat een indicatie dat de flowchart onvolledig is, en niet dat de behandeling niet in logica uit te drukken is. Want die arts doet die afwijking waarschijnlijk op basis van extra informatie van buitenaf (e.g. door ervaring, of recente ontdekkingen).

Dat jouw boek geen logica in codevorm heeft wil niet zeggen dat er geen logica in zit die in theorie geautomatiseerd kan worden.

In mijn optiek is de beperking van AI meer een integratie-probleem in plaats van een logica-probleem: de beperking is hoe veel informatie, achtergrond en feedback je de AI kunt voeden.

[Opifex]

RayNbow schreef op donderdag 14 maart 2024 @ 09:16:
[...]

Toepassen in welk opzicht? Deze boeken bevatten in ieder geval geen broncode.

Dat hoeft ook niet. Het is geen copy-paste engine.

[ThomasG]

RayNbow schreef op donderdag 14 maart 2024 @ 09:16:
[...]

Toepassen in welk opzicht? Deze boeken bevatten in ieder geval geen broncode.

AI kan nu al veel meer dan de meeste mensen denken. Het probleem is dat ze vaak invoer geven als "Maak X in taal Y". Dan krijg je inderdaad garbage terug. Als je goede invoer geeft, waarin je aangeeft wat je wilt hebben, krijg je dat gewoon terug. Of in ieder geval iets wat daar dicht bij ligt, en dan blijkt vaak dat je de input nog iets kan tunen voor een beter resultaat.

Voor alsnog zal AI niet zo snel software engineers of andere beroepen vervangen. Want voor goede resultaten heb je momenteel nog gewoon goede kennis van zaken nodig. Maar het helpt wel met het vereenvoudigen van veel werk. Een beetje zoals de komst van de rekenmachine, en later de computer.

[TunderNerd]

Het wordt een tool van de goede ontwikkelaar. Stukje outsourcen aan AI, en door!
Zeker in het begin der dagen zal security en kwaliteit problematisch zijn, en hiervoor dienen de goede ontwikkelaars. Het knopen, overzien, etc.
Ik verwacht niet een complete uitsterving, maar zeker een krimp in de aantallen

[HikariMisako]

Inmiddels ook een frontpage artikel:
nieuws: Cognition introduceert volledig autonome AI-software-engineer

[Dronium]

Bij mijn eerste baan heb ik veel gewerkt aan, vrij basic, code generatie. Collega's hadden een code generator gemaakt die vanuit de modellering 80% of meer van de code (C++) kon genereren. Na Versie 1.0 werden de modellen nog wat bij geschaafd en v1.0 werd gebruikt om v1.1 te creëren. Ik zag toen in mijn gedachten een hoop programeer-banen verdwijnen.
Het aantal programeurs c.q. software ontwikkelaars is alleen maar blijven groeien.

Ter referentie:
Mijn eerste baan had ik van 1992 tot 1997 !

[Travelan]

Toen de rekenmachine werd uitgevonden dachten ze ook dat we allemaal dom zouden blijven en niet meer zelf na konden denken. Hoeveel is de wiskunde (en diengevolgen de opmars van de hele informatica) wel niet gegroeid sindsdien?

[Salvatron]

Wie zegt dat er minder programmeurs komen? Misschien komt er wel gewoon meer en betere software omdat programmeurs meer kunnen doen in minder tijd.

[MeZZiN]

Zo lang de AI nog achter loop op de mens (creativiteit) plus de stakeholders eigenlijk niet weten wat ze echt nodig hebben zal het voorlopig los lopen.

Het kan wel zorgen dat we meer met minder tijd kunnen doen. Ik gebruik copilot nu vaak om mijn basis unit testen te maken en dan verder uit breiden scheelt we toch wat tijd plus minder stom werk doen.

[WernerL]

Persoonlijk zou ik op dit moment echt geen code-base willen onderhouden die door AI gegenereerd is. Je hebt totaal geen zekerheid dat de code correct is of dat het best-practices gebruikt. Je mag alsnog alles handmatig gaan checken. Uiteraard gaan veel mensen dat in de toekomst niet doen waardoor code-bases een grote puinhoop worden waarvan niemand meer weet hoe het werkt.

Het filmpje van Devin laat zien dat er een simpele Python applicatie from-scratch wordt gebouwd, maar kan het ook overweg met een code-base van 10 jaar oud met veel legacy waarin veel rare beslissingen zijn gemaakt?

Verder heb je voor het genereren van code geen AI nodig. We doen het letterlijk al jaren. In C#/.NET kun je clients voor soap-services genereren, entity framework kan migratie-scripts genereren, swagger-endpoint kan automatisch genereert worden en er zijn vast meer tools die gebruikt kunnen worden voor boilerplate. Of je schrijft zelf een tool, heeft een van mijn oude werkgevers ook gedaan om snel de basis neer te kunnen zetten. Het voordeel van deze tools is dat ze voorspelbaar zijn, AI niet.

De grootste uitdaging binnen enterprise organisaties zit hem in de analyse en design fase. Requirements duidelijk krijgen en dit vertalen naar goede user-flows. Helemaal leuk als je tool binnen meerdere afdelingen gebruikt wordt en ze in beide afdelingen precies andere ideeën en meningen hebben over hoe bepaalde functionaliteit moet gaan werken. Veel succes AI.

Als bedrijven echt kosten willen besparen en development-teams wil downsizen kunnen we met zijn allen beter stoppen met de micro-service bullshit. Kubernetes is ontwikkeld door Google, een bedrijf dat per dag miljoenen bezoekers krijgt. Een bedrijfsapplicatie met slechts enkele duizenden gebruikers heeft niet dezelfde schaalbaarheid problemen als Google. Toch denken veel mensen dat micro-services noodzakelijk zijn. Het gevolg is dat alle kosten omhoog gaan en in plaats van een klein team heb je ineens meerdere teams nodig om de enorme complexiteit in de lucht te houden.

Ik blijf zelf sceptisch of AI echt iets toe gaat voegen. Het voelt als de zoveelste hype-train. En ben er bang voor dat mensen er in de toekomst blind op gaan vertrouwen en kwaliteit van software alleen maar omlaag gaat omdat we zelf niet meer kritisch leren nadenken over software problemen.

[kwetterpletter]

Ik zou mij kunnen voorstellen dat best practices wellicht helemaal niet meer nodig zijn. Stel je voor dat je een goede set aan requirements hebt en telkens wanneer die veranderen laat je de software gewoon opnieuw genereren door AI. Plotseling is het volledig oninteressant of de code leesbaar is of niet. Zie de AI als compiler met requirements als input. Waarschijnlijk krijg je dan best practices voor het onderhouden en structureren van je requirements.

Ben het trouwens 1000% eens met je micro-services opmerking. Een technische oplossing voor een organisatorisch probleem. Zowel de developers als de cpu zijn meer tijd kwijt aan endpoints en clients dan aan business logica.

Ik denk dat AI veel routine taken kan overnemen en dat die steeds iets higher-level zullen zijn. Net als de eerste image generatoren alleen maar rare meuk met veel hondenneuzen genereerden en nu niet meer te onderscheiden zijn van echt / door mensen getekend.

[Yaksa]

kwetterpletter schreef op donderdag 14 maart 2024 @ 22:01:Net als de eerste image generatoren alleen maar rare meuk met veel hondenneuzen genereerden en nu niet meer te onderscheiden zijn van echt / door mensen getekend.

Zolang AI image generation nog steeds niet 'snapt' dat er altijd 4 vingers en 1 duim aan een hand zitten kun je die beelden makkelijk onderscheiden. En ik denk te weten waarover ik praat, kijk maar 'ns in het subforum
Het Grote AI art show- & kletstopic
AI image generation zal nooit de fantasie en verbeeldingsvermogen van mensen bereiken, simpelweg omdat het menselijk brein bewustzijn kent en AI niet.

[Rmg]

kwetterpletter schreef op donderdag 14 maart 2024 @ 22:01:
Ik zou mij kunnen voorstellen dat best practices wellicht helemaal niet meer nodig zijn. Stel je voor dat je een goede set aan requirements hebt en telkens wanneer die veranderen laat je de software gewoon opnieuw genereren door AI. Plotseling is het volledig oninteressant of de code leesbaar is of niet. Zie de AI als compiler met requirements als input. Waarschijnlijk krijg je dan best practices voor het onderhouden en structureren van je requirements.
.

Voor veel industrieën is dat gewoon niet goed genoeg, medical, automotive en aerospace bijvoorbeeld (om maar een kleine selectie te geven).

Code review is gewoon nog 1 van deliverables naast test en verificatie.

Voor dat t vertrouwen (en de regulerende instanties overtuigd zijn) in AI daar groot genoeg is om te zeggen we schaffen expert reviews af ben je echt 10 tot 15 jaar verder.

[drm]

kwetterpletter:
Ik zou mij kunnen voorstellen dat best practices wellicht helemaal niet meer nodig zijn. Stel je voor dat je een goede set aan requirements hebt en telkens wanneer die veranderen laat je de software gewoon opnieuw genereren door AI. Plotseling is het volledig oninteressant of de code leesbaar is of niet. Zie de AI als compiler met requirements als input. Waarschijnlijk krijg je dan best practices voor het onderhouden en structureren van je requirements.

De vraag is in hoeverre dat iets anders is dan een higher-level programmeertaal introduceren. Conceptueel heb je gelijk, maar in de praktijk is een natural language niet eenduidig en altijd voor meerdere interpretaties vatbaar; dat is nou eenmaal hoe taal werkt. Als de oplossing is om dat uit te sluiten ben je weer bezig een programmeertaal te formuleren. Wil je dat niet uitsluiten, dan hou je altijd een zekere "fuzziness" over, inherent aan hoe een LLM werkt.

Simpel gezegd, óf je wilt een compiler met deterministische uitkomst, óf je wilt een LLM en de uitkomst is niet-deterministisch*. De consequentie is, hoe dan ook, dat je een mens nodig hebt om de uitkomst op allerlei aspecten te verifieren.

Mijn standpunt is dan ook dat in het algemeen er meer skilled engineers nodig zullen zijn om die verificatie te doen en in het algemeen ook voor die kwaliteit te waken; ook in maatschappelijke context. Ik moet zeggen dat ik dat niet per se een hoopgevend vooruitzicht vind, gezien de kwaliteit van de gemiddelde crap aan open source webdev libraries waar ik dagelijks mee te maken heb (met name in frontend-land, overigens).

*) Natuurlijk wel in de stricte zin van het woord, maar in de praktijk is het quasi-deterministisch omdat er geen mens is die kan voorspellen wat de uitkomst gaat zijn.

[drm]

Overigens zie ik wel duidelijk voordelen in het gebruik van AI als een soort assistent, maar ik heb gemerkt in de paar experimentjes die ik met chat-gpt heb gedaan, dat er vooral heel veel tijd gaat zitten in het beoordelen van wat er geproduceerd is, en ik heb hem toch regelmatig op fouten van allerlei niveaus betrapt. Ik weet niet of dat met co-pilot of andere AI tools beter is, maar volgens mij geeft het een inherente beperking van de technologie aan. Een language model is precies dat: een model.

[MeZZiN]

Daarom dus. En de hoofd reden blijf altijd nog de requirements zijn nog goed genoeg.

De tijd die ik als developer besteed om stories helder te krijgen om dan als nog meer info nodig te hebben. Soms wel de helft van mijn sprint tijd. Maar het bespaard zoveel tijd omdat niet alles gebouwd moet worden.

Voor nu is AI super voor simpele klusjes maar even een mock of een boiler plate of basis testen. En dat is super maar de rest gaat het voorlopig niet worden.

[hellum]

kwetterpletter schreef op donderdag 14 maart 2024 @ 22:01:
Waarschijnlijk krijg je dan best practices voor het onderhouden en structureren van je requirements.

Hoe is dit anders dan coden?

[Lethalis]

kwetterpletter schreef op woensdag 13 maart 2024 @ 20:03:
Ik heb het gevoel dat de dagen (jaren waarschijnlijk) van de software engineer geteld zijn.

Nah, ik word wel efficiënter / productiever mét AI, maar het kan mijn inzicht in het project en de business kant niet vervangen.

Ik zie het als een handig hulpmiddel. Ruim 25 jaar geleden waren 4GL helemaal de hype, programmeren is verleden tijd! Tsja... we're still here. We hebben er SQL aan overgehouden en low code platforms, maar je zal altijd dingen moeten customizen die heel specifiek zijn. En die snapt AI ook niet.

[kwetterpletter]

hellum schreef op vrijdag 15 maart 2024 @ 16:41:
[...]


Hoe is dit anders dan coden?

Code is een exacte beschrijving van wat de computer moet doen. Requirements zijn min of meer exacte beschrijvingen van het gewenste resultaat.

Ik snap dat je dit als gewoon een niveau hoger kan zien, toch is dit niet hetzelfde als een hogere programmeertaal gebruiken. Requirements laten doorgaans een hoop ruimte voor interpretatie en vereisen een boel domein kennis.

[Anoniem: 80910]

Nou ik denk dat het heel hard gaat en over een paar jaar gemeengoed. Zie dit: ai YouTube: Introducing Sora — OpenAI’s text-to-video model dat is van open ai

[hellum]

kwetterpletter schreef op zondag 17 maart 2024 @ 19:20:
[...]
Requirements laten doorgaans een hoop ruimte voor interpretatie en vereisen een boel domein kennis.

(Mening) En dat is nu juist wat ontbreekt in een LLM, dus zou je alsnog exact moeten moeten beschrijven hoe de requirements geinterpreteerd moeten worden en wat er mee gedaan moet worden.

[RayNbow]

Anoniem: 80910 schreef op donderdag 21 maart 2024 @ 14:27:
Nou ik denk dat het heel hard gaat en over een paar jaar gemeengoed. Zie dit: ai YouTube: Introducing Sora — OpenAI’s text-to-video model dat is van open ai

Als ik dit zie, dan ben ik niet onder de indruk...

[kwetterpletter]

RayNbow schreef op vrijdag 22 maart 2024 @ 16:25:
[...]


Als ik dit zie, dan ben ik niet onder de indruk...

[Afbeelding]

Dit is state of the art, een jaar geleden: https://sites.research.google/videopoet/. 2 Jaar geleden was het idee van text-to-video pure science fiction,.
Een beetje van draaischijftelefoon naar Nokia 3610 naar iPhone 5 in twee jaren.

Dit is hoe de singulariteit er uitziet. Wanneer ben je dan wel onder de indruk?

[armageddon_2k1]

Dit is niet hoe de singulariteit eruit ziet. Dit is gewoon de S-curve welke jij op het steile stuk verwart met de singulariteit omdat je context en kennis mist en je door je onbegrip bang wordt.

Indrukwekkend? Jazeker; Marktverstorend, ook. Angstaanjagend? Nee.

[ Voor 15% gewijzigd door armageddon_2k1 op 22-03-2024 20:05 ]

[RayNbow]

kwetterpletter schreef op vrijdag 22 maart 2024 @ 19:43:
Wanneer ben je dan wel onder de indruk?

Laten we de drempel niet al te hoog leggen en beginnen met RayNbow in "Devin, de eerste AI software engineer?". Dus gegeven een AI-systeem met reeds voldoende kennis, kun je het een willekeurig textbook voeren en het vervolgens inhoudelijke vragen stellen over de stof die in het boek gedoceerd wordt (die dan vervolgens correct beantwoord worden)?

Als het gaat om gegenereerde video's? Geen idee, maar de beelden mogen zeker wel wat coherenter zijn.

[kwetterpletter]

RayNbow schreef op vrijdag 22 maart 2024 @ 21:07:
[...]

Laten we de drempel niet al te hoog leggen en beginnen met RayNbow in "Devin, de eerste AI software engineer?". Dus gegeven een AI-systeem met reeds voldoende kennis, kun je het een willekeurig textbook voeren en het vervolgens inhoudelijke vragen stellen over de stof die in het boek gedoceerd wordt (die dan vervolgens correct beantwoord worden)?

Als het gaat om gegenereerde video's? Geen idee, maar de beelden mogen zeker wel wat coherenter zijn.

Volgens dit wel: https://blog.google/techn...ebruary-2024/#performance

Het gaat dan over een leerboek over een taal maar op zich is dat niet veel anders. De LLM is dus niet getraind op die taal maar krijgt in feite het leerboek als prompt voorgeschoteld en kan vervolgens tekst vertalen alsof het de taal uit dat boek geleerd had.

Zou de LLM op dat boek en eventuele andere leerboeken plus voorbeelden getraind zijn, dan is die kennis gewoon aanwezig.

Het zou me niet verbazen als GPT4 nu al veel vragen correct kan beantwoorden. Niet alle, en ook niet altijd consistent, maar dat kunnen mensen ook niet.

[defiant]

Er schijnt toch een aanzienlijke hoeveelheid marketing omtrent dit product te zijn, waarbij niet altijd open kaart wordt gespeeld over de capaciteiten van dit product. Iemand heeft een video gemaakt over hoe een product demonstratie eigenlijk een totaal verkeerd beeld schets: Debunking Devin: "First AI Software Engineer" Upwork lie exposed!

Een samenvatting van de video die iemand gemaakt heeft, via hacker news:

• Devin is sold as being able to solve arbitrary Upwork tasks. In the video demo the problem it was asked to solve doesn't match the stated requirements of the customer (who asked for setup instructions, not code).
• Devin is shown fixing errors in the source of a GitHub repo, but the files it's shown editing don't actually exist in that repo and some of the errors its fixing are nonsensical, of the type that'd never be made by a human. Inference: Devin must be fixing bugs in files it has itself created, but that's not clearly indicated.
• There is no need to do any coding in the first place, because the README in the repository has all the instructions needed to achieve the task ready to go and they still work fine with only a one-line tweak, even though the repository is old. This is why the customer asked for instructions for how to run it on EC2 rather than for some coding. Devin didn't seem to read the README or understand that it only had to execute a couple of pre-existing Python scripts. The output in the video makes it look like the task was complex and sophisticated, with a long plan and many check boxes showing work completed, but the work was in fact pointless and redundant.

• Devin's code changes are bad, e.g. writing its own low level file read loop instead of using the standard library properly.
• Although the video makes it look like Devin did the task quickly, and the video creator was able to do the requested task in ~30 minutes, the timestamps in the chat show the task stretching over many hours and even into the next day.
• Devin does nonsensical shell commands like `head -n 5 foo | tail -n 5`

bron

Al met al laat Devin als product hierdoor niet zien dat het capaciteiten bezit die geadverteerd worden. Zoals de videomaker ook aangeeft zijn dit soort oneerlijke product demo's ook schadelijk omdat mensen die geen technische kennis hebben of zelf geen onderzoek doen naar de capaciteiten hier misschien wel conclusies uit trekken die schadelijk kunnen zijn voor het resultaat qua productkwaliteit qua kwaliteit en onderhoudbaarheid.