GitHub-ceo Thomas Dohmke stapt op, 'Microsoft-leidinggevenden nemen taken over'

GitHub-topman Thomas Dohmke stapt op na zeven jaar in dienst te zijn geweest bij het platform, waarvan vier als ceo. Hij krijgt naar verluidt geen directe opvolger. Leidinggevenden van moederbedrijf Microsoft zouden zijn taken overnemen.

Dohmke blijft nog tot het eind van het jaar ceo bij GitHub, schrijft hij in een blogpost. Hij wil naar eigen zeggen teruggaan naar zijn 'start-uproots' en weer een oprichter worden. De topman kwam in 2018 in dienst bij GitHub en werkte daarvoor als medeoprichter van ontwikkelaarsapp HockeyApp, die in 2014 door Microsoft werd overgenomen. In 2021 volgde hij Nat Friedman op als GitHub-ceo.

Volgens Axios, dat het nieuws dat Dohmke opstapt als eerste bracht, wordt de positie niet direct vervangen. GitHub-werknemers moeten vanaf volgend jaar rapporteren aan leidinggevenden van Microsoft, blijkt uit een interne memo. Julia Liuson, het hoofd van Microsofts ontwikkelaarsdivisie, wordt naar verluidt onder meer verantwoordelijk voor de financiën en de ontwikkeling van het platform. Microsoft nam GitHub in 2018 over voor 7,5 miljard dollar, maar het ontwikkelaarsplatform opereerde tot dusver grotendeels onafhankelijk van het moederbedrijf.

Reacties (75)

[IStealYourGun]

Jammer dat het nier meer onafhankelijk is. Ik vond het net wel gezond voor Microsoft dat er eigenlijk een "strijd" was tussen Microsoft en Github en die eerste daardoor scherp bleef staan.

Ik hoop dat Azure DevOps hierdoor niet gaat verdwijnen, want net die scheiding vond ik ook juist aangenaam. Open source community projecten -> Github. Company projecten -> Azure Devops

[jeroen3]

Kijkend naar microsoft denk ik eerder andersom. (eee)

Is Azure DevOps ooit uit beta gekomen dan? Ik heb het toen bekeken en voor gitlab gekozen want azure devops zag erg onafgemaakt uit.

[Crysania]

Dan heb je het toch echt niet goed bekeken.. Azure DevOps heette vroeger TFS (Team Foundation Server) en daarna VSO (Visual Studio Online) daarna VSTS (Visual Studio Team Services) en daarna Azure DevOps en bestaat al sinds 2005. (sinds 2015 als SaaS)

Wikipedia: Azure DevOps Server
Wikipedia: Visual Studio

Technisch gezien wordt er al heel veel gedeeld tussen het Azure DevOps team en GitHub. bijvoorbeeld de runners voor actions/pipelines zijn technisch gezien gewoon de zelfde tools. Ook zijn er heel veel mensen van Azure DevOps naar GitHub teams gegaan.

De toekomst is zeker GitHub want daar vind erg veel nieuwe ontwikkeling plaats en op Azure DevOps minder tot zeer weinig.

[Joost1981_2]

Dit is denk ik het probleem met Azure DevOps. Het is al oud, erg oud met componenten die aangekocht en geïntegreerd zijn. Het oude Release Management en Test Plans waren aparte producten. Nooit zo over nagedacht maar ja dat kan beta aanvoelen.

[Joost1981_2]

Azure DevOps verdwijnt zeker niet op korte termijn. Kent geen EOL datum.

Wel heeft Microsoft (niet GitHub) formeel gezegd dat bedrijven hun repositories moeten migreren naar GitHub indien ze gebruik willen maken van alle AI shizzle. Agentic DevOps noemen ze dit. AI Hype of niet: GitHub is veel meer gebouwd op een goede Developer Experience.

[DdeM]

Ik heb een paar jaar geleden al gehoord van een collega die contacten heeft binnen MS dat hun lange termijn plan is om DevOps uiteindelijk uit te faseren ten favoure van GitHub. De ontwikkelingen van beide platformen lijken dit ook te ondersteunen, want DevOps loopt duidelijk achter qua features.

[AJM94]

Je merkt dat Azure DevOps (ADO) qua repositories en pipelines achter gaat lopen op GitHub.

Bijvoorbeeld: een minder gestroomlijnde implementatie van Advanced Security, bij mijn weten geen Codespaces en geen native CoPilot integratie binnen de GUI zelf. Dit is alleen nog maar top-of-mind zonder beek concrete GitHub ervaring.

ADO loopt mogelijk vooral nog voor m.b.t. work management (je stories etc) verwacht ik.

Het zou me niks verbazen dat je binnen 5 jaar een scenario krijgt waarbij je geen nieuwe projects/repos meer kan aanmaken in ADO, en je wel over moet.

[enver63]

"Teruggaan naar zijn 'start-uproots'. Betekent dat, dat Microsoft gaat beginnen aan de enshittification van Github, en hij daar geen zin in had? Ik hoop het niet, maar ik was de laatste tijd al wel aan het kijken naar https://codeberg.org/ .

[CAPSLOCK2000]

"Teruggaan naar zijn 'start-uproots'. Betekent dat, dat Microsoft gaat beginnen aan de enshittification van Github, en hij daar geen zin in had? Ik hoop het niet, maar ik was de laatste tijd al wel aan het kijken naar https://codeberg.org/ .

Stap maar alvast over, paradoxaal genoeg zou dat wel eens de beste manier kunnen zijn om iets voor GitHub te doen.

Zodra de concurrentie is weggevaagd en het product onmisbaar beginnen de aandeelhouders te piepen en begint het grote uitknijpen, de enshittification. De manier om GitHub "gezond" te houden is felle concurrentie. Met genoeg competitie kunnen ze nooit in de het laatste stadium kopen.

En IMHO moet de overheid in het algemeen meer doen om de concurrentie te helpen, maar dat verwacht ik niet zolang rechts aan de macht is. Als individu ga je GitHub niet redden, daar hebben we echt de overheid voor nodig, maar de ondergang wat uitstellen en uitrekken is wellicht mogelijk.

Overigens, ook zonder enshittificatie is het beter om niet te lang bij GitHub te blijven hangen. Grote bedrijven innoveren namelijk niet. Ze proberen het wel, maar meestal lukt het niet. Grote bedrijven kopen innovatie.
GitHub zelf is een prima voorbeeld. Dat MS het heeft gekocht in plaats van zelf iets beters te bouwen. En wat is er de afgelopen 5 jaar nu echt beter of anders aan GitHub geworden? Het enige wat bij me opkomt is integratie met andere MS-software zoals CoPilot. Hoewel ik AI wel als innovatief zie, is het de versies van MS op geen enkel punt heel bijzonder of anders dan de concurrentie.

Grote bedrijven zijn goed in producten verder uitwerken en exploiteren (en dat is ook belangrijk) maar innovatie vind je op universiteiten en bij start-ups. Alleen al daarom is het slim om af en toe wat nieuwe applicaties/producten te proberen, want bij de grote bedrijven ga je steeds meer betalen voor wat in weze hetzelfde product blijft.

[R4gnax]

En wat is er de afgelopen 5 jaar nu echt beter of anders aan GitHub geworden? Het enige wat bij me opkomt is integratie met andere MS-software zoals CoPilot.

Je hebt ook nog het feit dat ze de hele UI die eerst netjes met progressive enhancement werktte, vervangen hebben door een React App, waarbij de performance van een boel pagina's merkbaar verslechterd is.

Dan heb je ook nog de code preview die, omdat er zogenaamd te veel problemen waren met grote code files, vervangen is door een infinite scrolling, partial loading/rendering oplossing. Die glitchy was; problemen gaf (en nog steeds geeft) met scrollen; en een tijdje de basale CTRL+F zoekfunctie van de browsers brak. En als oplossing voor dat laatste werd de hele tekst, zonder partial loading/rendering, nog eens verborgen op de pagina gezet. Waardoor je dus feitelijk weer terug komt bij het originele probleemstatement: grote code files zijn te langzaam. En enkel alles nog slechter en nodeloos meer complex hebt gemaakt. (Typisch Microsoft, trouwens.)

Oh- en over zoeken gesproken: ze hebben ook de zoekfunctie gemold en grotendeels onbruikbaar gemaakt. En afgezegeld zodat je deze niet kunt gebruiken zonder ingelogd te zijn.

Ik zou zelfs durven stellen dat sinds Microsoft Github overgenomen heeft en er steviger de scepter over is gaan zwaaien ('zelfstandige bedrijfseenheid' ammehoela...) er sprake is van een netto achteruitgang. De verbeteringen wegen niet op tegen de verslechteringen. Die enshittification binnen Github waar voor gewaarschuwd wordt, is wss. gewoon al jaren eerder begonnen - nl. met het importen van Microsoft's corporate mindset.

[Reactie gewijzigd door R4gnax op 12 augustus 2025 11:29]

[Crysania]

GitHub is juist al erg veel veranderd voor de hele GenAI hype begon.

toen MSFT GitHub kocht bestonden dingen als GitHub Actions niet eens. dingen die ik zie als vernieuwing:

• GitHub Actions
• Codespaces
• projects
• copilot
• packages
• advanced security (security scanning etc)

Er is juist heel wat geinvesteerd om het de opvolger van Azure DevOps te maken zodat het ook enterprise ready is en niet alleen gefocussed is op hobby projecten en open source tools.

Verder niet oneens dat innovatie afneemt als groot bedrijf vooral als je voor loopt op anderen zo zie je ook dat GitHub innovatie koopt (denk aan dependabot die ze kochten)

[Hightree2k]

Yep, ook codeberg aan het testen en het werkt prima, is open source en europees. Het netwerk effect is natuurlijk nog steeds een dingetje, maar voor mijn code hosting behoeftes voldoet het prima.
Ze hebben ook een migratie tool, die heb ik nog niet getest.

[Joost1981_2]

Een geweldige vent, die bovendien realistisch is over de rol van GenAI binnen softwareontwikkeling (we hebben meer developers nodig), en precies de juiste persoon voor de afgelopen periode. Onder zijn leiding is GitHub Copilot uitgegroeid tot een volwassen en serieus product. GitHub is inmiddels marktleider in het integreren van GenAI-oplossingen binnen de SDLC; geen ander platform biedt zo’n complete aanpak.

De komende jaren zal GitHub hét platform binnen organisaties worden—mits ze de EU-versie eindelijk eens qua features gelijk trekken.

[Reactie gewijzigd door Joost1981_2 op 12 augustus 2025 08:40]

[HollowGamer]

Ik ben wat minder enthusiast, maar misschien ben ik ook te pessimistisch?

Zelf gebruik ik ook GitHub Copilot, maar het 'werkt' doordat andere hun code doneren aan de modellen. Deze vullen zich dan, en je eigen code base kan dus worden opgenomen en onderzocht worden door andere, waardoor ik zeker aanraad om te volgende files/exts standaard te blokkeren voor CoPilot (in abonnement settings): .md, .env (inclusief ci/prod), .sql, .log, .db, .txt, .. en welke namen/extensies je nog meer hebt die privacygevoelig (kunnen) zijn.

Zoveel mensen/bedrijven doen dit niet! Ze koppelen gewoon CoPilot aan al hun persoonlijke code, hoewel ik voorstander van open-source ben, hoeft mijn naam niet autocomplete te worden of mijn stuff wordt gelekt doordat ik ergens random in een seeder zit (dit gebeurt - ook mijn IP staat ergens op een excel-sheet, zeker weten). Gisteren hebben we een klassiek voorbeeld gezien waarom scheiding van dit zo belangrijk is.

Daarnaast heb je nu dat het nog betaalbaar is, maar over een aantal jaar wordt het net zoals Netflix, onbetaalbaar en flink gedoe - want je zit vast in hun ecosysteem. GitLab krijgt ook weinig voet aan de grond, en persoonlijk vind ik het ook vervelend om te switchen tussen al die accounts.

[Crysania]

Copilot heeft .md files vaak nodig om context te krijgen van je applicatie en ook allerlei instructie files worden als markdown opgeslagen.

vraag me af wat voor privacy gevoelige info jij in je sourcecode hebt staan maar persoonlijk zou ik dat liever niet doen..

Als je bedoelt IP waarop copilot gaat trainen is dat een ander verhaal en dat kun je ook met een vinkje uitzetten dat er niets gebruikt wordt om te trainen

[HollowGamer]

vraag me af wat voor privacy gevoelige info jij in je sourcecode hebt staan maar persoonlijk zou ik dat liever niet doen..

Ik open vaak markdown docs met VSCode.

En mij gaat het erom dat andere het ook doen, dat was mijn punt.

[Joost1981_2]

Dit is gewoon papagaaien.

Je private code base wordt niet gebruikt voor trainen als deze niet publiek is en indien je een betaalde GitHub Copilot licentie hebt

[bantoo]

Eens, gebruik het hier op het werk ook voor alles mogelijk en het groeit allemaal de goede kant op. Kans was niet erg groot dat ik ooit in de GitHub producten was terecht gekomen als ze niet al lang geleden een fijn hosting systeem waren voor open source projecten.

Ik gun de concurrentie van GitHub het ook zeker wel maar ik vind het erg gemakkelijk om de pro en hobby dingen waar ik aan werk onder een paraplu te hebben.

[edie]

Dohmke, was dat niet degene die vorige week nog een blog post maakte dat developers AI moeten omarmen of anders geen developer meer moeten zijn? Die gast? Blij dat hij weg is.

Jammer dat de MS CoreAI team de baas gaat worden dus wordt er nog meer AI onzin ingepropt. Zoals dat dat de knop voor 'my open pull requests' is vervangen door een AI prompt "Hi Copilot! Can you please find my open pull requests?"

[IStealYourGun]

De titel van de post is anders toch wel er boenk op "Developers, Reinvented"

Als IT'er is mijn job al twee of drie keer veranderd en ben ik mee moeten veranderen. En AI zal sowieso ook impact hebben op mijn job, maar ik merkt toch ook wel als infrastructure engineer dat AI een grote hulp kan zijn.

Overigens is het veranderen van je job niet uniek aan IT. een boer werkt vandaag ook al een stuk digitaler dan 20 of zelfs 10 jaar geleden met o.a. een tractor dat autonoom op basis van GPS het veld bewerkt.

Als je moeite hebt met AI, dan raad ik je aan het boek "Onze ijsberg smelt!" eens te lezen.

[Ecological]

Mooi gezegd. Mijn werk is compleet veranderd door AI en ik doe alleen nog maar dingen die ik leuk vind. Ik code denk ik echt zo’n 2000 keer sneller door alle nieuwe agents. Als je weet hoe je het moet gebruiken en veel ervaring hebt - totale game changed. Als Microsoft certified trainer zijn het ook hele leuke trainingen om te geven!

[elmuerte]

2000 keer sneller

Je doet nu dus dingen in 1 dag die je voorheen 8+ jaar kostte (uitgaande van 48 weken, 5 dagen werken per jaar).

[Reactie gewijzigd door elmuerte op 12 augustus 2025 11:13]

[demonic]

Hoe is je workflow dan?

Welke agents gebruik je?
Hoe test je je code?
Wat voor functies 'programmeert' deze agents dan?
En in welke taal programmeer je?

[Robby517]

2000 keer sneller, dan vraag ik mij oprecht af wat jouw output was zowal kwalitatief als kwantitatief. Ik zie het zelf ook op het werk en gebruik het ook dagelijks, het kan inderdaad een hulp zijn, vooral als een soort interactieve rubber duck. En het is vrij goed in zaken als boilerplate setup of bepaalde rewrites of kleinere implementaties als die goed aangestuurd worden. Maar ook dat moet heel vaak nog rechtgetrokken worden door devs, en bij grote code generations krijg je zoveel rommel op je bord dat je misschien als junior dev denkt veel te kunnen outputten, maar een beetje senior dev moet vaak zo veel opnieuw doen dat het enkel bruikbaar is voor POC's.

Dus een claim als 2x, 3x misschien zelfs 4x OK. Maar veel meer dan dat? Dan zit je volgens mij in een bedrijf/industrie waar hoge ouptut aan lage kwaliteit de standaard is.

[DutchAddick]

2000 is erg overdreven inderdaad, maar dat het alleen bruikbaar is voor een POC klopt ook niet in mijn ervaring. Het ligt heel erg aan hoe je prompt. Als je zegt "bouw voor mij systeem X" (gechargeerd), dan krijg je troep. Maar als je met PRD's werkt, de agents deze telkens opnieuw laat lezen, de agents de voortgang laat bijwerken en telkens alleen een volgende subtask laat uitvoeren, dan is het 90% OK wat er uitkomt en hoef je alleen te checken en hier een daar wat aan te passen.

[AnimeDev]

In die tijd heb ik het gewoon geschreven, heb eens met een pro AI collega getimed, en enkel heel boilerplate code is sneller. anders moet je of een boek schrijven of de output nog gaan aanpassen (en dus meestal wisselen keyboard-muis bij het klikken tenzij je 100x pijltjes gebruikt) dat is bij mij is niet sneller dan intellisense met gewoon 2 letters typen => tab spatie = spatie cl(autocomplete) (punt) fun (autocomplete) ( a(tab)) om "result = class.function(argument)" te krijgen... dat duurt misschien 4 seconden, misschien 30 voor een functie, een prompt voor een functie is minstens 10 seconden dan 5s genereren en dan nog editeren wat niet naar wens/code afspraken is. boilerplate win je misschien 10 seconden, maar een boek schrijven om een moeilijk stuk te maken, dat dan nog controleren, nalezen, editeren en debuggen kan je beter vanaf nul schrijven.

Ik vergelijk github copilot dan ook met een net afgestudeerde junior dev, je steekt er meer tijd in met handje vasthouden dan zelf te doen, je krijgt meestal niet wat je vroeg en als het dan eens in orde is ben je meer verbaasd en spendeer je toch tijd om het na te lezen voor alle zekerheid.

Waar ik veel meer aan zou hebben is als ik een voice prompt had die in een vast window op mijn 3e scherm staat waar ik met voice commandos bvb datasheets en files kan opvragen en makkelijk daar prompts op zou kunnen loslaten, dan kan ik mijn handen laten typen en op keyboard houden en met voice een "derde hand" gebruiken zonder naar muis => files => doorklikken => venster slepen => scroll. Maar ai op lokale files zie ik niet gebeuren zonder 1) een model dat je lokaal kan/mag draaien 2) privacy schending door de ai die al je files kan lezen. Dus tot er een degelijke echt open ai komt die ook nog eens performant is...

[wiseger]

Wat een geleuter, sorry dat ik het zeg. In een jaar zitten 2000 factureerbare uren maximaal. Wil je echt met droge ogen beweren dat je nu in een enkel uurtje evenveel produceert als je voorheen in een compleet jaar produceerde?

Complete onzin!

[MMaster23]

Toch vind ik persoonlijk dat AI er nog niet is. Het maakt nog te vaak fouten of verzint gewoon hele systemen/commando's. Het is alsof we van paard naar auto moeten maar de auto een zinnetje heeft "auto gebruikt benzine en kan exploderen".

Of met GPS door Europa rijden en vervolgens verzint de GPS "FrankOostenLandje"

[nonestpraens]

Tja, leuk leesvoer hierover is AI2027. Sinds de opkomst van AI-agents is de vooruitgang in rap tempo versneld. Waarom? Omdat het onderliggende model talloze kleine instanties van zichzelf kan starten om specifieke problemen volledig uit te zoeken. Je kunt zelfs twee agents tegenover elkaar zetten, zodat ze elkaars prompting optimaliseren.

Uiteindelijk vloeit alle nieuwe kennis weer terug naar het hoofdmodel. Geef dat model vervolgens de mogelijkheid om zichzelf via code aan te passen, en je kunt een AI-agent deployment opzetten met een CI/CD-pijplijn erachter. Zo kan de AI zichzelf verder ontwikkelen, zonder het risico dat foutieve code in productie komt aangezien alles eerst wordt gedeployed en getest.

[MMaster23]

Ik gebruik al geavanceerde modellen, nieuwste AI agent flows en "deep research" features met meer "thinking".. toch wist het weer compleet dingen te verzinnen over een specifieke CLI tool (waarvan de documentatie al jaren online staat, en van dezelfde maker was als de AI tool). Ik gebruik AI nonstop en toch moet ik meer dan de helft ervan weggooien. Het feit dat mensen er blind op bouwen is best eng voor mij.

[nonestpraens]

"nieuwste AI agent flows en "deep research" features"


Ik heb het niet enkel over de features, ik heb het over AI agents soms wel 20 die aan elkaar gekoppeld zijn die een specifieke prompt/idee uitzoeken voor een final prompt, vervolgens wordt dat behandeld door een andere agent totdat alle agents een duidelijke prompt weten te genereren met alle benodigde kennis erbij.

Als jij enkel een één agent gebruikt zoals in GPT zijn feature maak je niet optimaal gebruik van de middelen die beschikbaar zijn, aangezien het nogsteeds één agent is die foutieve conclusies kan trekken. Is dit foutloos? Nee zeker niet, maar het is vergelijkbaar met discussies tussen mensen waar enkele aantal de stof begrijpt, een ander gedeelte begrijpt het deels en tot slot één gedeelte zit er compleet naast.

Dit is één van de manieren waarmee AI poisoning en false confidence wordt tegengegaan.

[R4gnax]

Noem mij maar pessimistisch, maar wat ik daar in lees is dat je dus ipv je daadwerkelijk in het probleemdomein gaat verdiepen en een oplossing gaat uitdenken en uitbouwen, je ervoor kiest je eigen kennis op dat vlak niet te verrijken maar om vergeljikbaar budget (zowel jouw tijd; als kosten voor gebruik) stukslaat op een graaf aan AI agents aan elkaar knopen en cycles laten verstoken in een feedback loop om tot een hopelijk - fingers crossed - betrouwbare oplossing te komen.

Uiteindelijk krijg je die, en moet je alsnog er helemaal doorheen om na te lopen wat het opgeleverd heeft. (Nee- dat kun je niet door een AI laten doen. Quis custodiet ipsos custodes?) En vervolgens heb je jezelf de mogelijkheid tot diepgaande kennisvergaring ontnomen die je had gehad als je het zelf had gebouwd, wat je ook weer tegenwerkt als je de code die de AI opgeleverd heeft uiteindelijk moet gaan onderhouden. (Of snel moet analyzeren waar een potentiële bug zou kunnen zitten, bijv. wanneer er live in een productieomgeving iets toch nog onverwacht fout gaat na een paar weken.)

Het zijn allemaal afwegingen die veelal genegeerd worden wanneer er over de vooruitgang van AI gesproken wordt.

[nonestpraens]

Tja ik was ook eerst de pessimist die AI zag als de zoveelste kapitalistische verkoop truc en bubbel die staat te wachten op barsten, maar gezien de voortgang van OpenAI en de plannen om een Amerikaanse model van de overheid te laten draaien op 1000x de compute kracht voor R&D, zie ik toch een reële toekomst waar wij snel worden ingehaald.

Quis custodiet ipsos custodes

Gebeurd nu ook met mensen, je doet een GIT commit, iemand checkt het en goedgekeurd. Echter als de auditor weet dat jij goed kan coderen, wellicht vertrouwd die jou en kan er alsnog een bug komen in de applicatie door een foutieve check. Verder zijn er genoeg mensen die fouten maken binnen de ICT, om dan de claim te maken dat dit kan leiden tot bugs door AI gebruik terwijl de zwakste schakel in de ICT naar mijn mening de mens is.

Een computer doet enkel wat er van een mens gevraagd wordt, zijn er problemen? Dan veelal ligt het bij software of bugs in de software, zelden gaat hardware kapot en zelfs dan geeft de computer nog informatie over wat er kapot is.

De use-cases stapelen zich op per dag, ik ga toch zelf liever langs een ziekenhuis voor een kankeronderzoek die het resultaat van zowel een doktor en AI met elkaar vergelijkt, aangezien AI kankercellen kan detecteren die net zijn ontstaan met precisie.

In het kort de protocollen in de IT wereld en standaard eisen, maken het mogelijk dat AI zichzelf hierin gemakkelijk kan mengen en bepaalde taken kan overnemen. GPT5 kan al foutloos CRM dashboards, webgames en metrische dashboards coderen in onder 1 minuut.

[Reactie gewijzigd door nonestpraens op 12 augustus 2025 11:57]

[R4gnax]

De use-cases stapelen zich op per dag, ik ga toch zelf liever langs een ziekenhuis voor een kankeronderzoek die het resultaat van zowel een doktor en AI met elkaar vergelijkt, aangezien AI kankercellen kan detecteren die net zijn ontstaan met precisie.

Dit is een valse vergelijking. Appels en peren.

Deep learning modellen zijn bij uitstek zeer geschikt voor patroonherkenning. Daarom zijn ze zo goed in het detecteren van afwijkingen die lijken op vroeg-stadium kankercellen. En waarom ze een zeer waardevolle toevoeging zijn op een analyze van onderzoeksresultaten door een medisch specialist.

Herkennen is alleen anders als fabriceren middels hercombinatie - wat een LLM doet als je deze vraagt om code te kloppen voor je.

[nonestpraens]

Herkennen is alleen anders als fabriceren middels hercombinatie - wat een LLM doet als je deze vraagt om code te kloppen voor je.

Tja men leert ook best practices en coding standaarden van hun docenten/collega's, is dit niet hetzelfde als een LLM die kijkt op stack hoe bepaalde problemen zijn opgelost of waar de community gezamenlijk iemands code heeft verbeterd?

Ik blijf het fascinerend vinden dat top onderzoekers zoals Hinton massaal waarschuwen voor AI, terwijl de gemiddelde persoon denkt dat dit nog decennia nodig heeft om functioneel te worden want het is maar een LLM.

Maar is goed !remindme 760 dagen

[Reactie gewijzigd door nonestpraens op 12 augustus 2025 15:33]

[R4gnax]

Ik blijf het fascinerend vinden dat top onderzoekers zoals Hinton massaal waarschuwen voor AI, terwijl de gemiddelde persoon denkt dat dit nog decennia nodig heeft om functioneel te worden want het is maar een LLM.

En medio maart 2025 kondigde de CEO van Anthropic nog de voorspelling aan dat "over 3 tot 6 maanden 90% van alle code door AI geschreven wordt." Het is nu medio augustus - dus we hebben nog goed en wel een maandje om dat punt te bereiken.

Wat denk je? Gaat het lukken?
Of is dit de zoveelste overdreven en op ideologisch luchtkastelen gebaseerde uitspraak van een industrie die puur op durfkapitaal en gewillige investeerders draait en dus een boel gezichtsverlies te lijden heeft als de bubbel zou ploppen, die naar realiteit bijgesteld moet worden?

Ik moet hierbij aan een bepaald meme denken: nog twee weken...

[nonestpraens]

En medio maart 2025 kondigde de CEO van Anthropic nog de voorspelling aan dat "over 3 tot 6 maanden 90% van alle code door AI geschreven wordt.

Eerlijk gezegd weet ik niet wat de CEO van Anthropic op had maar dit is onrealistisch, daarom ben ik ook van mening dat AI die zijn eigen code ontwikkeld en schrijft iets is voor eind 2026 begin 2027, waarbij de techniek en progressie extreem afhankelijk is van AI agents die specifieke taken verrichten. Netzoals bij het menselijk brein waarbij gebieden dienen als opslag, taalherkenning, abstract denken en logische berekeningen etc.

Dus nee de komende 3-6 maanden is absurd, denk eerder zelf aan een tijdspan van 2 jaar.

[cmegens]

Het vergt gewoon een andere manier van werken. Het is niet langer “ik druk op een knop en dan krijg ik gegarandeerd deze uitkomst”. Je zult met AI moeten leren werken. Het hallucineren zal minder worden, maar nooit helemaal verdwijnen. Slimmer dus om daar mee om te leren gaan.

[djwice]

Welke AI gebruik je? Claude Sonnet doet dit bij mij veel minder dan ChatGPT. Goede heldere context meegeven helpt heel erg.

[Reactie gewijzigd door djwice op 12 augustus 2025 13:22]

[edie]

Ik heb niks tegen nuttige verandering. Maar de huidige tekst-generatoren zijn niet de nuttige verandering die de predikers claimen. Die dingen genereren vrolijk code met obsolete APIs omdat dat nu eenmaal in hun statistisch model zit.

[arjankoole]

nog maar 2 of 3 keer?

volgens mij is het in de 25 jaar dat ik nu actief ben, een 3-jaar cycle geweest. Misschien 5. En sommige dingen zijn er nog altijd, maar sommige dingen zijn compleet anders.

[Henk1827]

Als ITer is mijn job nagenoeg hetzelfde gebleven. Talen zijn higher-level geworden, stacks zijn complexer geworden. AI kan wat simple taken oplossen zoals test data generen. Voor productiecode maakt AI mij 0% sneller in mijn taken.

[Wolfos]

Tja, je kunt wel iets claimen maar als de cijfers iets anders zeggen... https://www.infoworld.com...ned-developers-by-19.html

[Yoshi]

En daar staat toch ook gwn dat Ai een grote hulp is of kan zijn ... Diegene waarop je reageert beweert niet dat devs nu sneller werken toch?

[jorde]

Ik denk vooral dat het een reactie is op de gelinkte blogpost, niet de post hier.

En daar zit wat in, LLMs kunnen nuttig zijn. Echter wordt er steeds geroepen dat het programmeurs gaat vervangen of zelfs al kan vervangen omdat de productiviteit zo omhoog gaat door LLMs. Wat vooral komt doordat het zeer snel heel veel lijnen code kan genereren, dat zijn ook de lijnen met de meeste 'churn' -- lijnen die kort daarna weer vervangen worden door volledig nieuwe code. Microsoft, OpenAI en Anthropic promoten vooral de 'productiviteit boost'. Dit gemeten op de gunstigste manier voor hun marketing, alleen de 'positieve' aspecten opgeteld. Al het negatieve genegeerd.

Om dat te weerleggen op mijn eigen werk, wij werken er onder aan de streep eigenlijk niets van. De manier van werken is verandert, maar je moet aanzienlijk meer tijd steken in het nakijken van code die gegenereerd is door LLMs. Waar je op gegeven moment een vertrouwensband kunt opbouwen met je collega's is dat niet het geval met LLMs. Dus dat proces vergt veel meer tijd en energie. Dit in contrast met wat deze voormalige CEO claimt als 'time-saved'. Wat een nuttige metric zou zijn, als je onder aan de streep kijkt. Niet naar 'tijd bespaart doordat je het niet zelf hoefde te typen'.

Al met al verwacht ik geen verbetering op dit vlak nu Dohmke is afgetreden.

[djwice]

De slow down is de leer curve. Juist de gene die voorbij gaan aan wat nu efficiënt is, leren wat de AI wel en niet goed kan, passen hun repo structuur en files aan, zodanig dat het optimaal wordt voor de AI.
Die mensen zullen straks(of nu al) al die andere voorbij streven kin snelheid.

Juist leren hoe je AI iets in 1x goed kunt laten doen dat je zelf heel goed kan kost leertijd, maar zorgt daarna voor extreme versnelling in volgende projecten.

Ja, van weken of maanden werk naar dagen.

[R4gnax]

De slow down is de leer curve.

Lees de studie. Specifiek Appendix C.2.8 (in de brief fout gelabeld als Appendix C.2.7) waar men een distributie laat zien tussen developers met meer en minder eerdere ervaring met AI tools, waarbij de hoogste groep honderden uren eerdere ervaring met deze tools heeft, en constateert dat er tussen de verschillende cohorten geen noemenswaardig verschil is.

Dus nee- de leer curve maakt niet uit.
Dit is geverifieerd.

[djwice]

Het gaat hier over CursusAI specifiek en in jouw referentie staat

We don’t see large
differences across the first 50 hours that developers use Cursor, but past 50 hours we observe positive speedup. However, we are underpowered to draw strong conclusions from this analysis.

Dus als je meer dan 7 werkdagen met de tool werkt zie je al positieve impact op ontwikkeld snelheid. Dat is een extreem snelle leercurve, toch?

Ik heb het over het resultaat na vele honderden uren. Mijn eigen ervaring is dat als je jezelf en team kunt overtuigen om onder geen beding afwijkingen, shortcuts of patches te accepteren en kleine bestanden in een goed gestructureerde en duidelijk beschreven naam conventie gebruikt. Je projecten zowiezo veel beter gaan lopen (zonder AI) én nog meer zullen profiteren als AI wordt ingezet.

De shortcuts lijken op korte termijn vaak geen probleem "snel gefixt en het werkt toch, what's the problem?", het probleem is leesbaarheid, afwijking van verwachting en daarmee aanpasbaarheid en onderhoud baarheid. Die dingen kosten extra tijd in de toekomst, die "technical Dept".

Zodra je werkt in een team dat begrijpt dat dit niet acceptabel is, gaat het team veel beter en sneller functioneren. Want je kunt blind vertrouwen op de structuur en overzichtelijkheid van de code en tests.
Dit scheelt ~ 15 minuten per taak (context switch) maal het aantal afwijkingen in de code/tests die je moet bekijken / raakt.
Bij een AI is dit het verschil tussen first time right van een aanpassing versus meerdere instructies en reviews moeten geven of zelfs zelf er na nog een aanpassen op moeten doen.

Dat scheelt snel 20 minuten of meer per taak.

[Reactie gewijzigd door djwice op 12 augustus 2025 21:11]

[yuckywucky]

Herlees toch eens wat je schrijft. Je bent blij dat een CEO opstapt die vindt dat je AI moet omarmen (ik ook trouwens, als dev, veel succes anders)... maar je WEET dat het alternatief slechter is, zoals je zelf aangeeft. Je bent blij dat ze een mens met een mening vervangen door "microsoft-leidinggevenden", om dan te zeggen dat het waarschijnlijk erger wordt op het gebied waarover je in eerste instantie blij bent.

Leg het mij aub even heel goed uit, want je ziet het vaak tegenwoordig. Afgunst met bijna een masochistisch kantje om nog meer genaaid te worden, zolang in jouw ogen maar iets gebeurt wat jij denkt dat goed is, want "ai slecht".

Compleet. Geschift.

[edie]

Ik ben blij dat die AI-pusher weg is, maar vind het jammer dat er een grotere AI-pusher voor in de plaats is gekomen. Zo moeilijk is dat toch niet?

[DdeM]

Half of them believe a 90% AI-written code scenario is not only feasible but likely within 5 years, while half of them expect it within 2 years.

Lol, wat is er gebeurd met de 6 maanden van begin dit jaar

Ik houd mijn hart vast voor de veranderingen binnen GitHub.

[Crysania]

Er staat toch nergens dat MS CoreAI team de baas gaat worden?

GitHub viel al onder de DevDiv (Developer Division) die werken aan developer tools & platformen als Visual Studio, VSCode, GitHub, Azure DevOps, etc. het hoofd van die divisie was al de baas van Thomas Dohmke en blijft dat nu ook van GitHub.

Ik verwacht wel dat GitHub langzamerhand meer en meer onderdeel wordt van Microsoft en minder hun eigen organisatie. Het is al jaren aan de gang maar tot nu toe hielden ze GitHub best nog als eigen entiteit met eigen merk etc terwijl er op de achtergrond al heel veel samen gedaan werd. mijn verwachting is dat dat ook op de voorgrond zichtbaarder gaat zijn.

[GewoonWatSpulle]

Waarin ben je het dan niet eens met die uitspraak? Je wilt geen AI gebruiken?

[edie]

De stelligheid "als je geen AI gebruikt, ben je geen developer". Volledig onzin voor een CEO om zoiets te uiten. Even een hele groep professionals wegzetten omdat ze je niet welgevallig zijn.

[PureTryOut]

Zolang het zo'n beetje een bos afbrand per prompt wil ik inderdaad geen AI gebruiken.

[djwice]

Ik heb early access tot een aantal functies. Samengevat: Het is zeer verstandig AI te omarmen en leren en je eigen maken hoe je het foutloze code, documentatie, testen en ontwerpen kunt laten maken, zonder zelf nog code aan te passen.

De AI-agents waar ik nu toegang toe hebt kunnen - bij de juiste aansturing - in een uur of 12 tot 14 ongeveer 8 maanden aan ontwikkelwerk uitvoeren.
Bijvoorbeeld een progressive web applicatie met goede en veilige API interfaces, drempel vrije user interface en alle veiligheidseisen tik in de box, incl. documentatie en automatische testen, infrastructuur als code en de hele rambam. En ja de code voldoet aan alle leesbaarheids en structuur en veiligheid eisen.

En dit is nog maar het begin en kan nu al.


De blog is wat mij betreft niet sterk, gebruikt drogredenen en het lijkt - gezien de voorbeelden - er op dat de schrijver niet voldoende tijd heeft gehad om met AI aan de slag te gaan. Het beeld dat er staat is wat mij betreft al achterhaald.
Je kunt met 1 prompt al in 1x het juiste resultaat krijgen - mits de juiste eisen worden geformuleerd in de prompt.

[Reactie gewijzigd door djwice op 12 augustus 2025 13:08]

[HollowGamer]

GitHub-werknemers moeten vanaf volgend jaar rapporteren aan leidinggevenden van Microsoft, blijkt uit een interne memo.

Gisteren interessant filmpje gezien van GamersNexus over Intel dat uit elkaar valt. Hij benoemde daarin dat als hij iemand vanuit AMD wilt spreken, hij direct iemand kan bereiken. Bij Microsoft lijkt het dus net als Intel, waarbij je zowel van de buitenkant als ook intern, door heel veel (bestuurs)lagen moet gaan om iets te bereiken.

Voor mij gaat het niet om dat er geen CEO meer is in feite, maar volgens mij gaat het juist mis doordat er te veel mensen daar bestuurder zijn (Mozilla ook) en daardoor juist minder uit de handen komt van de ontwikkelaars, aangezien ze hun idee of probleem naar te veel mensen/lagen moeten communiceren.

Gelukkig kan AI straks de developers rollen overnemen, en hoeft de top die enkel aan te sturen. /s

[Reactie gewijzigd door HollowGamer op 12 augustus 2025 10:49]

[Crysania]

maar er gaat nu dus juist een bestuurslaag weg. dus dat zou dan positief zijn in jouw ogen?

[HollowGamer]

Er komen er 5 voor terug. ;)

[Crysania]

dat is dus niet waar.

GitHub viel onder de DevDiv (Developer Division) van MSFT. Thomas rapporteerde daar aan iemand. die persoon blijft nu verantwoordelijk voor GitHub maar dan zonder Thomas er tussen.

Ik zie daarin voor en nadelen: voordeel dat dingen beter zullen integreren omdat ze dichter onder zelfde aansturing zitten als tools als VSCode etc.

Nadeel: minder eigen zeggenschap / richting als GitHub zijnde maar meer moeten passen in de Microsoft strategie

[Harm_H]

Github is zo'n standaard binnen de ontwikkelaars wereld. Met de kennis van nu was het een koopje voor Microsoft. Als iemand weer roept "billionaires are bad". Het is positief dat mensen beloond worden voor het maken van producten die een groot publiek bereiken.

[Reactie gewijzigd door Harm_H op 12 augustus 2025 08:49]

[NoTechSupport]

Wat een raar statement. Dit heeft niets met miljardairs te maken. Hoogstens met multinationals.

Je kan niet direct zeggen dat MS goed bezig is als je ziet hoe het zich de laatste jaren gedraagt op vlak van

• duurzaamheid (stoppen met ondersteunen Windows alle PC's ouder dan enkele jaren).
• Concurrentie: teams, OneDrive en CoPilot door je strot rammen en de concurrentie vernietigen
• Sociale verantwoordelijkheid : massaal werknemers "vervangen" door AI (nog te zien of dat werkt)

[Jobjl]

Correctie op dat laatste punt. Men probeert het wel met AI, maar momenteel is het meer:
massaal "duur" Amerikaans personeel vervangen door kennismigranten en outsourcing. En dat met een winst van 171 miljard over 2024.

OT

Ik vraag mij af of dit daadwerkelijk een vrijwillig vertrek is of iets wat we vaker zien bij overnames.
Bedrijf A neemt bedrijf B over. Bedrijf B heeft een eigen CEO voor een tijdje. Daarna vult bedrijf A dat zelf in met hun eigen poppetje.

[davekok]

CEO van een startup zijn is iets heel anders dan CEO van dochteronderneming. Eigenlijk moeten we het tweede niet CEO noemen.

[Harm_H]

CEO is van meer van een grote dochteronderneming en Founder is meer van startup.

[SoftwareGert]

Daar hoef je geen miljardair/billionaire voor te zijn, dus nog steeds zijn ze slecht!

plus, MS had Azure devops / TFS en dat werd langzaam aan op de achtergrond samengeperst. Zo’n koopje is het ook weer niet, ze hebben er nog veel in moeten steken, en een aantal dingen zijn behoorlijk gaar vanuit een security en management perspectief.

[Ricco02]

Dus miljardairs/billionaires zijn slecht omdat ze zoveel geld hebben en jij dus niet?

Jaloezie doet veel met je.

[Draivun]

Miljardairs/billionaires zijn over het algemeen slecht door de manier waarop ze zoveel geld hebben vergaard en belangrijker nog; behouden. Zó rijk word je alleen over de rug van anderen, en ze blijven zo rijk door schimmige constructies om geen/minder belasting te hoeven betalen.

[SoftwareGert]

Hahaha, nee hoor, mijn schaapjes staan al even op het droge. De meeste mensen met vermogen hebben toch een fictief vermogen, dat ze in kunnen zetten voor leningen en dergelijken (aka collateral).

ik vond het vooral een weinig toevoegende opmerkingen, dat mensen met vermogen goed zijn, want github is goed. Terwijl het de bedrijven zouden moeten zijn met het vermogen, niet een enkele CEO.

[Honytawk]

Nee, miljardairs zijn slecht omdat de enige manier om zo veel geld te verdienen is door andere mensen in het zak te zetten.
Ofwel door hun klanten af te rippen, ofwel door hun werknemers onder te betalen, of alle mensen in de landen waar ze belastingen onderduiken. Meestal een combinatie van ze allemaal.

Het is makkelijk om miljardair te worden, je moet gewoon het moraal kompas hebben van een cactus.

[Ricco02]

Wat ik zo vreemd vind is dat er altijd vanuit word gegaan dat miljardairs altijd hun geld verdienen door andere mensen de grond in te boren. Terwijl dat helemaal niet altijd het geval hoeft te zijn.

Daarmee scheer je alle miljardairs over 1 kam.

[emansom]

Astroturfing? Valt niet op hoor.

[HollowGamer]

lol

LinkedIn zit nu vol met bots, en het is een sociaal netwerk om je voor te doen als een ideale werknemer/werkgever. Ik weet niet of billionaires de wereld zo goed maken, misschien ook eens vragen wat de mensen over de Philips ex-top vinden hier in NL bijvoorbeeld.

[mdavids]

Jammer dat Gitbub nog steeds niet goed werkt via IPv6...