Claude Sonnet moet nu bij programmeren consistenter zijn en beter luisteren

Anthropic heeft Claude Sonnet 4.6 uitgebracht. Deze update moet het AI-model onder meer consistenter maken bij het programmeren en beter laten luisteren naar de instructies van de gebruiker. Het model moet ook sneller zijn en betere 'computervaardigheden' hebben.

Anthropic zegt dat Sonnet 4.6 onder meer beter kan programmeren, betere computervaardigheden heeft en betere prestaties biedt. Zo moet Sonnet 4.6 bij programmeren consistenter zijn met antwoorden en de instructies van gebruikers beter volgen. Daarbij zou het model minder vaak successen claimen die er niet zijn en minder hallucineren. Het Sonnet-model zou ook op het vlak van 'intelligentie' vergelijkbare prestaties moeten bieden als het krachtigere maar langzamere Opus-model, claimt Anthropic.

Claude Sonnet is een AI-model dat onder meer taken kan uitvoeren op het apparaat van de gebruiker. Anthropic stelt dat Sonnet 4.6 hierin beter is geworden. Daardoor zou het model complexe spreadsheets beter kunnen gebruiken. Ook zou het browserformulieren met meerdere stappen kunnen invullen, om de verzamelde informatie later vanuit verschillende tabbladen te combineren.

"Het model is nog steeds niet zo snel met computers als de bekwaamste mensen, maar de snelheid waarmee het beter wordt is alsnog opmerkelijk", schrijft Anthropic. Deze verbeterde computervaardigheden betekenen volgens Anthropic dat Sonnet voor meer taken te gebruiken is dan voorheen. Anthropic zegt daarbij bepaalde maatregelen te hebben genomen om Sonnet weerbaarder te maken tegen promptinjectieaanvallen, waarbij verborgen tekst op websites een AI-model andere instructies geeft.

Claude Sonnet 4.6 is per direct beschikbaar via alle abonnementen, de gratis versie, Claude Cowork, Claude Code, de api 'en alle grote cloudplatforms'. Gebruik van Sonnet 4.6 is ook niet duurder dan 4.5.

Benchmarks van Sonnet 4.6 die door Anthropic zijn uitgevoerd

Reacties (89)

[Pep7777]

Het belangrijkste bij gebruik van AI ook voor programmeren is dat je blijft controleren wat de AI (LLM) doet. Versie controle (git) is een must zodat je altijd een stapje terug kan doen. En er geld nog steeds hoe beter je weet WAT je doet hoe beter het resultaat. Mocht je het idee krijgen dat je blijft prompten, stop dan even, denk opnieuw zelf na, reset de context/chat en geef de AI een voorbeeldje van wat je dan wel wilt hebben.

En voor de wat meer professionele lezer/software ontwikkelaar, je taak verschuift van programmeren naar engineering. Het engineering process is belangrijk, doe je design, codeeer, en maak testen en review. In alle stappen kan je AI gebruiken. Voor testen, laat je build code coverage doen en vraag AI de coverage te verbeteren met nieuwe tests. En het is ook heel belangrijk dat je de SOLID (SOLID - Wikipedia) principes kent en toepast. Deel je software op in kleinere stukken (stukjes zelfs) met duidelijke interfaces, zodat wijzigingen niet gelijk op je hele code base effect hebben (high locality of change). Deze aanpak was al belangrijk om in teams te kunnen werken, en de mentale belasting (cognitive load) op ontwikkelaars niet al te hoog te laten worden. Maar voor AI helpt het ook enorm, je hebt minder context nodig om code te overzien (dus minder tokens) en de AI komt dan ook met betere oplossingen.

Met andere woorden mensen blijf AI als een stuk gereedschap zien en niet als kant en klare antwoorden/oplossingen. Ja AI gegenereerde code lijkt aannemelijk (en vaak al best goed) maar kan nog steeds subtiele (of minder subtiele) bugs bevatten en die moeten er gewoon uit. Er zijn al voorbeelden genoeg waar AI's gewoon doodleuk passwords/API keys/tokens enzo in code zet dus blijf alert.

[Henk1827]

De vraag blijft of je met het aansturen van een LLM sneller bent. En daarbij moet je ook meenemen of je de code en het product ook even goed begrijpt als je de LLM het typwerk laat doen.

Als senior ben ik zo’n 20% van de dag bezig met code typen (lees: autocomplete en copy paste). De rest is het domein begrijpen, concepten uitdenken, en een code ontwerp maken. Tijdens het typen verandert mijn idee van wat een goede code architectuur een aantal keer. De LLM is een hele fijne zoekmachine en rubber ducky. Maar als je niet meer zelf typt mis je een heel stuk van van dat creatieve proces.

Vaak wordt een greenfield project aangehaald als ideaal voor LLMs. Maar de modellen zijn vaak getrained met maanden oude data en missen de laatste kennis over een programmeertaal en build tool. Juist met een greenfield project wil je even kijken wat er beter kan en wat er verandert is sinds het vorige greenfield project. En hoe vaak bouw je een greenfield project? Ik niet meer dan 1x per jaar.

Wat je op internet leest over AI strookt totaal niet met wat je op de werkvloer ziet. Vooral ervaren seniors gebruiken het als een handige tool, maar ook niet meer dan dat.

[Pep7777]

Ik heb het geluk dat ik al zo'n 30 jaar software engineering ervaring heb, en dus heel goed weet wat software architectuur, design, implementatie (multithreaded C++), test en review stappen ik moet doen.
Ik denk dat dat veel meer waard is dan greenfield of niet. Voor mij persoonlijk geld wel degelijk dat ik veel sneller ben, omdat ik ook weet hoe ik in kleine stappen moet werken (nee dat is geen tegenstrijdigheid). Het is echt een klein beetje code laten maken, reviewen, testen erbij (kijken of alle code en threading paden zijn doorlopen in het nieuwe stukje). Dan een git stage of commit doen voordat ik weer verder ga.
En het probleem met maanden oude code bases los ik vaak op door ook zelf nog "voorbeeld" code te schrijven (meestal wat ingewikkelder template spul) om the LLM te laten zien wat ik bedoel (eventueel hoe iets moet in een nieuwere C++ versie) en dit dan op te nemen als basis voor de verdere code. En ja dan helpt een LLM enorm met vooral het uit-typen van wat ik wil. En voor bestaande code base, laat de LLM stukken code lezen, en beschrijf hoe je het eea wil refactoren (kennis van design patterns is dan wel handig), vraag de LLM om een eerst een plan te laten maken en pas dat aan voordat ie aan code mag zitten. Dus nee AI is zeker niet alleen bruikbaar voor greenfield, ik denk dat dat vooral een misverstand is of vooral te wijten is aan het feit dat ontwikkelaars in greenfield niet de moeite hoeven te doen het huidige systeem te begrijpn en begrip is nodig om het beste uit AI te kunnen halen.

[jimmy_dg]

En dit allemaal is overboden wanneer een AI exclusief aan de codebase werkt.

[Pep7777]

Een AI exclusief aan een code base laten werken, ontwikkelingen gaan hard en ik laat AI al echt veel doen maar een AI helemaal loslaten (zonder vangrails) geen haar op mijn hoofd die daar aan denkt.

AI laat mij toe om juist aan de kwaliteit te werken en nog steeds sneller te zijn dan voorheen. Kan ook zijn dat ik gewend ben om aan grote code-bases te werken, met tientallen engineers, die tientallen jaren (generaties) mee moeten. En dat ik weet wat daarbij komt kijken. Het gaat echt niet alleen om een beetje programmeren.

[jimmy_dg]

een AI helemaal loslaten (zonder vangrails) geen haar op mijn hoofd die daar aan denkt

Voor een bestaand project, neuh. Maar een greenfield project? Dat gebeurt al volop. Mijn (tech) subreddits gaan helemaal los met ai gegenereerde projecten. Ook onderhoud of nieuwe features toevoegen gebeurt allemaal via een AI.

Ik blijf ook ver weg van het toestaan van automatische AI aanpassingen op bestaande projecten. Uiteraard zit alles in versiebeheer dus ik kan zien wat er gebeurt, maar alsnog begin ik er niet aan.

Ik zie gewoon veel gebeuren op het gebied van AI (agentic coding, mcp) en al die randzaken verdwijnen in die context (design patterns, solid principle, high locality of change, noem maar op).

[Luminair]

Dat het volop gebeurt maakt het niet een duurzame oplossing. In de zin van bijvoorbeeld: wat doe je als je codebase straks te groot is voor deze (tier) AI, je moet straks bugs gaan oplossen waarvan je geen idee hebt, wat als moderne models je code niet meer snappen, je project gezien wordt als 'onwenselijk', of de API rates opeens intens omhoog schieten en je het niet mer kunt betalen? Je kunt er een mens naar laten kijken, maar dat kan ook een duur grapje worden als de codebase dermate groot en unwieldy is. En als het project puur door AI is opgezet zonder een 'HUMAN.md' als het ware, dan kan dat een duur grapje worden.

Het lijkt nu allemaal mooi en groen gras, maar er zitten talloze haken en ogen aan dit soort projecten die men van te voren vaak niet eens inziet. Dat gebeurt ook bij menselijke ontwikkeling, maar als er niet een mens is betrokken bij de ontwikkeling voeg je nog een extra vector toe om het jezelf moeilijk te maken.

[Pep7777]

Dat is wat ik bedoel met je kan AI gebruiken maar weet alsjeblieft wat je doet voordat je een product levert dat gemaakt is met AI. En ja het helpt natuurlijk niet dat AI bedrijven gouden bergen beloven en dat alles straks vanzelf gaat. Iets met miljarden belangen.

[Pep7777]

Greenfield of bedoel je prototypes? Voor prototypes helemaal prima. Maar mjin insteek is hoe dan ook als je een product gaat bouwen is het process en kwaliteits controle eromheen nog steeds het belangrijkste. En wat ik al zei, in het engineering process helpt AI al enorm. En toch is er nog steeds iemand nodig om de goede prompts te maken en dan helpt ervaring met process/architectuur/engineering en programmeren enorm om sneller tot een goed resultaat te komen.

[Henk Marinus]

[...]die randzaken verdwijnen in die context (design patterns, solid principle, high locality of change, noem maar op).

Dus dat! Programmeurs zie ik vasthouden aan principes. Zij hebben A gebouwd en kennen allemaal patterns en willen x en y hebben qua controle. Maar wat maakt het uit als oplossing B bewezen veel beter en gratis is. Ai ontwikkelingen gaan echt snel. Grote techbedrijven zeggen ook allemaal; zal slechts een paar goede programmeurs overblijven.

Als voorbeeld; een vergelijkingswebsite heeft vaak duizenden producten in een categorie met complexe filtering. Elke keer dat er resultaten worden aangeklikt moeten er berekeningen worden gedaan. Er gaat een request naar een server met de vraag; geef pagina 1 van televisies met filter 50 inch en Samsung gesorteerd op populariteit.
De developer moet nadenken over caching en querry voor het herbereken van alle filter aantallen. Om te zorgen dat het snel werkt moet de data nog even in elastic search waar collega x goed in is. De data komt terug via de api waarna de front ender het design verwerkt in framework y.
Je hebt in dit proces al snel 5 disciplines en vaak 5 poppetjes binnen een bedrijf. Ja dan zijn er veel controles nodig. Kost een hoop communicatie en dus grote kans op fouten.

Vanavond zelf een POC gemaakt waarin 99% cliënt side instant gebeurt. Iets wat normaal maanden aan ontwikkeltijd kostte heb ik letterlijk nu opgelost met wat prompts.
Omdat ik dit in een avond heb gebouwd, kan ik dit ook gerust gratis delen. Iedereen kan het immers en er valt dan niet meer tonnen geld te verdienen aan deze oplossing.
Het idee wordt open source. Weer een probleem verholpen. Als bijvoorbeeld tweakers het overneemt bespaard het een hoop pc/human resources.

Ik denk en hoop dat er op deze manier het komende jaar extreem veel open source gaat worden. Gratis oplossingen die veel werk overbodig gaan maken. Zo kunnen bedrijven/ondernemers de komende jaren alles wat in de backlog staat wegwerken. We gaan grote overcapaciteit krijgen.

Ik hoop dat we die overcapaciteit inzetten om na te denken over grotere vraagstukken. Dat we ons dan ook als individu beter gaan inzetten voor de maatschappij. Er zijn nog genoeg problemen op te lossen als klimaat, ziektes en ongelijkheid. Als we hier als individu aan bijdragen en niet denken dat dit vanuit politiek/van bovenaf opgelost moet gaan worden, denk ik dat we snel de wereld een stukje mooier kunnen maken.

[eborn]

Je haalt het al aan: een PoC. Hoe schaalt lokaal filteren van 1.000 producten met 200 attributen per stuk? Ga je dan alle data naar ds eindgebruiker sturen?

Daarnaast putten dit soort modellen al uit open source code die dit soort mogelijkheden hebben, zoals Lucene of inderdaad ElasticSearch.

Dat iets kan wil niet zeggen dat het ook een goed idee is. En een ontwikkelaar die hier in het verleden maanden mee bezig was moet je per direct ontslaan lijkt me.

We leven nu in de halleluja tijd van AI: mensen kunnen opeens dingen waarvoor in het verleden kennis en ervaring nodig was. Dat kan veel positieve gevolgen hebben. Maar ik verwacht niet dat we op korte termijn hierdoor de ideale Gene Roddenberry samenleving gaan zien.

[Henk Marinus]

Ja.de truc; werk met referenties. A=filter 1, b= filter 2, etc. Getest met 50000 producten en 5000 filters en 20 data punten per product; 1mb compressed data over de lijn. Gaat iets trager bij downloaden via 3g maar met een workaround is dat ook opgelost.

[xelagbs84]

Overal waar AI nu steken laat vallen... verwacht ik eigenlijk dat toekomstige Ai dit weer voor mij gaat oplossen voor end of life van de dingen die ik nu bouw. Dat heb ik de afgelopen 1,5 jaar al veelvuldig meegemaakt. Met de huidige agents herbouw ik soms nu al projecten van hun voorgangers.

[kdekker]

Ai maakt nog zoveel fouten, ook Claude Sonnet 4.6 die in CoPilot zit, dat het regelmatig niet eens bouwt, dezelfde fout van gisteren of eergisteren gemaakt wordt etc. Geheugen van een ontwikkelaar is toch anders.

Kortom: het is nog veel te vroeg om op AI te vertrouwen voor kwalitatieve software. En ik denk dat dat moment er voorlopig ook nog niet is.

Wel grappig dat nu de aankondiging van dit model komt, terwijl ik het al dagen zo niet weken in CoPilot heb. Andersom staat daar Gemini 3 als preview en online is de preview al voorbij.

Aanvulling (ik zit de hele dag al met CoPilot in de weer): bedenk dat 'denken' van een AI-agent want anders is dan 'denken' van een mens. Denken van een AI-agent is een LLM loslaten en statistiek bedrijven. Idem 'geheugen'. Ik had net een CoPilot prompt die mij vraagt een unit test uit te voeren en de output te geven, maar dat vandaag (en gisteren en eerder ook al) zelf de test uitvoerde (maar dat weer vergat). Wat voor een mens heel logisch is (een set van stappen die je uitvoert bij een bepaalde gebeurtenis) 'vergeet' AI die heel vaak. Kortom: ik kan me niet aan de indruk onttrekken dat markering praat voor AI-agents heel 'menselijk' over AI willen spreken, maar dat AI dat in de verste verte nog niet is (desondanks, best wel behoorlijke stappen gemaakt worden).

[Reactie gewijzigd door kdekker op 18 februari 2026 16:14]

[Blaz0r]

Vraagje, gebruik je dan ook iets als openspec waarmee je beslissingen en dus de juiste oplossing voor deze fouten vast kan leggen zodat ze niet meer gemaakt worden? Daarnaast kan je ook in AGENTS.md's en in specifieke skills zaken vast leggen die bij jou projecten passen/horen.

Of verwacht jij bijvoorbeeld dat als je 10x dezelfde vraag stelt zonder enige vorm van extra configuratie/context/geheugen dat je dan 10x (hetzelfde) perfecte antwoord krijgt?

[kdekker]

We leggen van alles vast in de instructie file (.github\copilot-instructions.md) voor CoPilot, maar dat is redelijk generiek. Ik weet niet of dit hetzelfde is als openspec.

Ik weet niet wat ik moet verwachten . Maar constateer slechts dat vanmorgen CoPilot de unittest steeds zelf draaide, maar kennelijk de vermoeidheid toesloeg, en dat later op de dag niet meer deed. Er is in de tussentijd aan de instructies niets veranderd. Dat had ik iig niet verwacht.

[Reactie gewijzigd door kdekker op 18 februari 2026 17:18]

[Henk1827]

Specs, Agents.md maakt de output een stuk beter. Maar specs zijn vaak niet 100% duidelijk, en veranderen nogal eens. Wat je dan krijgt is dat je steeds je specs aan het wijzigen bent. Ook het “op papier” krijgen van specs kan lastig zijn. In je hoofd kan iets heel duidelijk zijn, maar nu moet je de LLM ook nog duidelijk maken.

[drdelta]

Vooralsnog een uitstekende manier om een boel geld te verspillen, zoals Anthropic recentelijk bewezen heeft.

Zelfs met veel menselijk toezicht, en 20.000 dollar aan tokens, konden de agents de taak niet succesvol volbrengen zonder een bestaande compiler (GCC) continue als referentie te gebruiken.

Maar goed, over 1-2 jaar staan we er ongetwijfeld anders voor. Ik ben erg benieuwd.

[MSalters]

Duh. Als jij dat onderzoek zo samenvat , dan heb je het verkeerd begrepen. Dit was opzettelijk een onderzoek aan de grens van wat mogelijk is. Een 100% coding succes was een mislukt onderzoek geweest. Het doel van dat onderzoek was namelijk op verbeterpunten te vinden.


En GCC als referentie? Teacher-student training is al 10 jaar een bewezen AI methodiek, al van voor LLMs. Dat als iets negatiefs benoemen getuigt van weinig vakkennis.

[drdelta]

En GCC als referentie? Teacher-student training is al 10 jaar een bewezen AI methodiek, al van voor LLMs. Dat als iets negatiefs benoemen getuigt van weinig vakkennis.

Het is absoluut een bewezen methodiek, het hele concept van reinforcement learning staat bij dat principe.

Claude op GCC en andere compiler code trainen, GCC-in-the-loop om te reserve-engineeren, en Claude dan geen internet geven een "clean-room implementation" noemen kan ik alleen niet heel serieus nemen.

Ik heb overigens geen ad hominem nodig om mijn argument te onderbouwen.

[Barsonax]

Voor hobby projectjes of een poc ja dan kom je ermee weg.

Voor serieuze projecten loop je toch snel tegen de limieten aan van wat AI kan.

Als voorbeeld bijvoorbeeld die C compiler die anthropic gemaakt had met AI. Die bleek toch niet zo goed te zien ondanks dat de requirements perfect helder waren en zelfs met implementatie voorbeelden wat die AI kon gebruiken.

Vermoed dat dat nog wel zo zal blijven en dat is ook prima want dan kunnen wij juist het leuke gedeelte van het werk doen.

[Reactie gewijzigd door Barsonax op 18 februari 2026 17:56]

[anno361]

Ik werk 18 jaar professioneel in de IT, leren programmeren toen ik 11 was. Nu 42.

De waarheid is: zet bij Claude Max de orchestration aan, maak een team van 4 (developer, analyst, reviewer, devil's advocate). En het ding programmeert beter dan eender wie.

Het doet een typische taak in 20 minuten, waar ik vroeger dan 2 uur over deed. En het wordt nooit moe, presteert steeds even goed. En kost 90 euro per maand.

De zogezegde "limiet" van de technologie is nog niet in zicht. En als die er zou zijn, dan ligt die op een bovenmenselijk niveau. In 2026, kunnen wij (mensen) minder goed programmeren dan computers.

Lees je dit en denk je: "ik zie vooral fouten". Dan komt dat omdat je nog geen MCP servers geconfigureerd hebt, nog geen guidelines md hebt geplaatst voor je bot. Doe je huiswerk.

Onze IT job wordt nooit meer hetzelfde. Dat is de realiteit. Aan alle ontkenners: ik heb jullie al gehoord bij elke stap vooruitgang. Gelukkiger worden we er niet van, maar jezelf blijven voorliegen maakt het alleen erger.

[antoine_]

Het voelt alsof AI steeds meer aan het plateau is gekomen, er zijn niet meer de grote verbeteringen als eerst. Kan iemand dit bevestigen of niet?

[Tielenaar]

Voor wat dit moet doen komt het steeds dichter bij perfectie, dus dan is er weinig te verbeteren. In de laatste maanden zijn er wel gigantische stappen gemaakt met modellen voor afbeeldings- en videogeneratie. Het realisme is vaak zo goed dat je het echt niet meer kan zien.

Voor modellen voor bv programmeren kan er meer verbeterd worden als het gaat om reasoning, en snelheid, maar waar de industrie nog verder mee gaat komen moeten we maar afwachten. Ze zitten nooit stil.

[Wailing_Banshee]

Ik vind dat er nog teveel gehallucineerd wordt, zeker als er meerdere mogelijke oplossingen voor een probleem zijn. Ik gebruik nu met name 4.5. Ik was laatst bezig met een Blazor applicatie en gebruikte een bepaald component om grafieken te tonen. Daar heb je een hele zooi verschillende componenten voor, waarvan ik er 1 gekozen had. Hij bleef elke keer terug gaan naar een ander component wat ik dus niet gebruikte. Of de data is ondertussen achterhaald.

De code die gegenereerd wordt is over het algemeen wel netjes, maar daar heb je nog geen werkende applicatie mee :D

[MikeyMan]

Hallucineren of zelfs simpelweg foute antwoorden. Het gebeurt me geregeld dat hit 1 op google me betere informatie geeft dan ik uit Gemini en/of Chatgpt haal.

[japie06]

Een LLM moet je niet gebruiken als zoekmachine.

[jpsch]

Juist wel. Zoekmachines geven steeds slechtere resultaten, dus gooi je het door 1 of meerdere LLM's. Werkt vaak beter, niet altijd.

[MikeyMan]

Nee, maar als die LLM met reacties komt die met de eerste de beste hit van een zoekmachine al onzin blijkt, gaat er ergens iets niet goed...

Het wordt verkocht als 'AI'. Niet als briefschrijfmachine.

[Cristan]

Je kan een CLAUDE.md aanmaken en hier zeggen dat hij jouw gekozen component moet gebruiken.

Het is een beetje armoede dat dit nodig is, maar ik denk dat het wel gaat helpen.

[MSalters]

Of gewoon AGENTS.md want die componentkeuze is niet specifiek voor Claude.

[imqqmi]

Laat het een ARCHITECTURE.md file maken waarin allerlei beslissingen worden beschreven. Bij iedere prompt weet de LLM van niets, dus je moet 't context geven als je voort wilt borduren op voorgaande beslissingen. Werk met specificaties, fases, items en uitvoer plannen en vat fases samen in een bestand met referenties naar de uitgebreide fases etc. Hoe complexer en groter de applicatie wordt, hoe meer je moet leunen op context documentatie dmv self exploration & discovery. Hij laadt wat hij nodig heeft.

Je kunt ook skills gebruiken als je claude code of opencode gebruikt, hiermee kun je de naam van de skill even noemen en hij weet precies wat je bedoeld en voert de acties uit in de skill file. Je kunt deze ook opnemen in je AGENTS.md file voor automatisch oppakken van bepaalde dingen, maar dat is een beetje hit/miss verhaal. Hoe meer je herhaald hoe beter ie 't oppakt. Maar maak de AGENTS.md ook niet te groot, dat kan de output kwaliteit negatief beïnvloeden. En zorg dat je context grootte binnen 50-120k tokens blijft en laat t subagents gebruiken om items van je fases af te tikken.

Hier kun je een heel eind mee komen. Nog een laatste tip: als je een spec/exec plan hebt laten maken, laat 't nog eens expliciet een cross reference uitvoeren op de huidige source files om foute aannames te corrigeren. Itereren op je exec plan helpt ook een stuk bij complexere/grotere code bases.
En zorg voor een TDD first approach. Kost meer tijd en tokens, maar kwaliteit gaat wel flink omhoog.

[BlaDeKke]

Over perfectie praten ivm een LLM geeft een vertekend imo.

[Tielenaar]

Een LLM zal iid nooit perfect zijn, maar het komt belevingsgewijs aardig in de buurt.

[BlaDeKke]

Als je het gebruikt in een gebied waarin je zelf expert bent, dan zie je toch snel dat we nog ver van perfectie zijn. Dat de beleving aanvoelt als perfectie is by design, dit moeten ze wel om investeringen aan te trekken en managers om de tuin te leiden. Maar weet dat waar je het kan zien fout gaan binnen je eigen expertise, het even vaak fout gaat buiten je expertise om, je ontbreekt de kennis om dit vast te stellen. We zijn allen nogal gevoelig aan het Gell-Mann amnesia-effect.

[Tielenaar]

Niet echt mee eens. Ik gebruik het enorm veel om development taken te vereenvoudigen en binnen mijn veld is het daar gewoon enorm goed in. Ik heb zelden problemen en ik ken geen developer die het beter kan dan wat ik er uit haal.

[BlaDeKke]

Klein vermoeden dat jij door middel van jou kennis en expertise zeer goed vragen en opdrachten weet te formuleren. Als je LLMs vaak gebruikt voor dit doel weet je ook heel goed wat je kan en niet kan verwachten en je past je gebruik daar aan aan. Je weet waar de valkuilen zitten en kan met weinig moeite dit opvangen. Dat maakt deze tool nagenoeg perfect in jou handen voor jou manier van werken voor de taken die jij wil uitvoeren. Dat maakt de tool zelf niet zogoed als perfect.

Ik denk dat je het effect van jou eigen kennis en expertise op de werking van de LLM en hoe jij er mee werkt onderschat. Als je weet wat de oplossing is, en hoe je er moet komen, en je dit wil vertalen naar code. Top! Maar je hebt dan wel reeds 95% van het werk al gedaan.

[Tielenaar]

Ja dat is waar. Ik gebruik het als tool om werk te versnellen, maar ik weet precies wat ik moet vragen om daar te komen.

[oks]

Alsof mensen zo perfect zijn ;-) Het woord hallicuneren komt ergens vandaan...

[elmuerte]

Als een werknemer zo vaak zit te hallucineren als Al dan zou deze al lang ontslagen zijn.

[oks]

Oh ja? Homerisch gelach. Sorry hoor, voor mijn lichte cynisme. Hele bedrijfstakken zijn op dit moment aan het hallucineren dat de nederlandse bevolking oneindig diepe zakken tegen de inflatie heeft.

[BlaDeKke]

Het hallucineert niet. Dit is antropomorfisme. Het doet de modellen slimmer klinken dan ze effectief zijn.

[oks]

Met een bepaald bril op heb je gelijk... Het probleem is alleen dat een LLM het resutlaat van een bewerking is van menselijke data... Dus dat antropomorfisme is helemaal niet zo raar. Zonder ons was er geen LLM.

[t14wo]

Je bent in de war. De verbeteringen zijn juist gigantisch. In plaats van een beetje beter in alles worden modellen nu veel beter in bepaalde taken. Zeker in combinatie met agents (mensen) en skills (functies) is het heel snel onverslaanbaar aan het worden.

De tijd van AI maakg alleen spaghetti code is snel voorbij. Devopers brace for impact.

[Speedster]

Wie is er hier in de war? Maakg? Devopers?
Wikipedia: Professor Zonnebloem

[karelvandongen]

Zolang de meeste gebruikers meestal niet echt weten wat ze nodig hebben, en hoe een framewerk te creëren wat passend is bij wat ze nodig hebben, zal dat wel mee vallen. Want de ai's kiezen vaak niet voor de meest optimale oplossing, en zullen ook niet gericht optimaliseren.
En de goede programmeurs gebruiken ook ai om een beter resultaat in minder tijd te creëren.

[MSalters]

Datzelfde bezwaar maakten we 50 jaar geleden tegen compilers. Wie schrijft er anno 2026 nog asssembly? 99% van de programmeurs kunnen het niet eens.

[karelvandongen]

En met de goede kennis kun je dus een ai aansporen om de performance sterk te verbeteren, maar als je niet door hebt waar je het moet zoeken.. of als je niet weet dat een bepaalde library (met bv compiler optimalisatie) veel beter is als een andere, voor die taak. Etc, etc. Daarom zullen goede programeurs die op een zo goed mogelijk manier de beschikbare technieken inzetten, nog decennia werk hebben.

[Glennos]

Ik vind op vlak van programmeren dat AI in agent modus (geïntegreerd in je Visual Code of dergelijke) wel degelijk grotere vorderingen maakt. Claude Opus 4.6 is één van mijn favoriete modellen.
In een chatvenster of webversie kun je heel wat minder dan wanneer je AI als agent of via API gebruikt.

[FuZZbaLL]

Inderdaad, het is voor de LLM veel makkelijker om te begrijpen wat je vraag is en hoe het opgelost moet worden als de LLM de rest van je code ook kan inzien. Eigenlijk wel logisch, dat is voor developers ook zo.

Een ander voordeel, is natuurlijk dat je niet steeds code hoeft te knippen en plakken.

[Oon]

Er is eigenlijk sinds de eerste publieke versie van ChatGPT maar heel weinig veranderd. Optimalisaties in de modellen, meer resources, wat tooling eromheen, maar de LLM's zelf zijn als technologie niet veranderd.
Dus ja en nee. De op ruis gebaseerde willekeurige woordvoorspeller wel, maar de toepassingen waarin die gebruikt kunnen worden niet.

[arjan1995]

Niet mee eens. De eerste versies van ChatGPT konden redelijk vragen beantwoorden, maar zeker nog niet programmeren. Deze nieuwe modellen kunnen dit (icm. skills en tools) enorm veel beter. Niet voor niets dat in 2023 developers nog amper AI gebruikten, en dat je het nu veel meer ziet.

[Nattekat]

Deels. Modellen gebaseerd puur op het principe van de uitvoer voorspellen aan de hand van de invoer en de reeds gegeven uitvoer zitten wel redelijk aan het maximale van hun kunnen, maar er worden daaromheen ook steeds nieuwe dingen toegevoegd om die modellen 'slimmer' te maken. ChatGPT laat bijvoorbeeld de denkstappen zien bij grotere prompts.

Maar deze makkelijke fixes zitten natuurlijk ook uiteindelijk aan hun limiet, en dan is het ook echt klaar. Elke volgende stap van dat punt zou zijn om een taalmodel te linken aan een redenatiemodel, en dat is absurd veel complexer en lastiger om te bouwen.

[The Third Man]

Ik heb nog wel grote verbeteringen meegemaakt in de laatste 3 maanden. En nog steeds laten de 'grote jongens' nog wel eens steken vallen. De groei is er wat mij betreft nog niet uit. Zowel qua kwaliteit als consistentie als bijvoorbeeld vindingrijkheid.

[Luchtbakker]

Het voelt alsof AI steeds meer aan het plateau is gekomen, er zijn niet meer de grote verbeteringen als eerst. Kan iemand dit bevestigen of niet?

De verbeteringen tussen 4.5 en 4.6 sonnet zal denk ik net zo groot zijn als bij Opus. En bij Opus merk ik dat hij nu een stuk meer nadenkt voordat hij code schrijft. Hij leest zich vooral breder in voordat hij wat doet. En als hij tussentijds bugs in de code tegenkomt repareert bij die ook. Dat gebeurde in 4.5 niet of nauwelijks is mijn ervaring.

Dus de verbeteringen zijn wel aanzienlijk vind ik, al is Claude zelf wat terughoudend in.

[floppyhoesje]

AI zegt: de perceptie van een plateau is begrijpelijk, maar het is meer een verschuiving van het type vooruitgang dan een echte stilstand.

[Wolfos]

Ik vind juist dat het qua programmeervaardigheden erg snel gaat. Ieder Codex model is nog steeds merkbaar beter dan de vorige, terwijl er maar een halfjaar zit tussen 5.0 en 5.3.

[djexplo]

Stel dat je de tabel neemt en omzet naar per hoeveel vragen word er 1 fout gemaakt. Dan zie je dat "Met tools", er toch een behoorlijk winst zit, en nog steeds heel veel groei. Deze tabel maakte Copilot ook door eerst een python scripts met "pytesseract" voor de tekst herkenning te gebruiken, en later een python script "pandas" met "openpyxl", om er een Excel tabel van te maken.
Hoe meer bestaande tools je weet te koppelen aan je LLM des te meer je kan.

...........Sonnet.4.6;.Sonnet.4.5;.Opus.4.6;.Opus.4.5;.Gemini.3.Pro;.GPT-5.2
Agentic.terminal.coding...........................2....2.......3.....2.....2......3
Agentic.coding.........................................5....4.......5.....5.....5......5
Agentic.computer.use..............................4....3.......4.....3.....1......2
Agentic.tool.use.(without.tools)................12...7.....12....9.....7......6
Agentic.tool.use.(with.tools).....................48...50...143..56....50...77
Scaled.tool.use.........................................3....2......2.....3.....2......3
Agentic.search..........................................4....2......6.....3.....2......5
Multidisciplinary.reasoning.(without.tools).1....1......2.....1.....2......2
Multidisciplinary.reasoning.(with.tools)......2....2......2.....2.....2......2
Agentic.financial.analysis..........................3....2......3.....2.....2......2
Novel.problem-solving...............................2....1......3.....2.....1......2
Graduate-level.reasoning.........................10...6......11....8....12....15
Visual.reasoning.(without.tools)................4....3......4.....3.....5.......5
Visual.reasoning.(with.tools).....................4....3......4.....4.....1.......5
Multilingual.Q&A.......................................9....10....11....11....12....10

[Reactie gewijzigd door djexplo op 18 februari 2026 14:08]

[barrymossel]

Tijdens mijn hobby projectjes merk ik dat er echt gigantisch verbetering in zit de afgelopen jaren en ook maanden. Maar ik merk ook dat er nog heel veel verbeterd kan worden. Je moet nu nog heel veel sturen en hoewel ik Gemini en Claude nog wel eens betrap op creativiteit, is die doorgaans (logischerwijs) best ver te zoeken. Vaak is het napraten van de massa, maar soms lijkt het echt op combineren van verschillende zaken en begint het op denken te lijken...

[HollowGamer]

Ik merk bij Claude Sonnet 4.5 dat het vaak nog slechte beslissingen neemt en vaak eigen bestanden gaat aanmaken, terwijl de logica al bestaat.

4.6 zou mogelijk beter zijn, maar vind het wel erg duur. Daarnaast vraag ik mij af of ik nog lang kan programmeren, want mijn 16GB zit vol door al die AI-tools, en 32GB is niet eerlijk meer in prijs.

[MSalters]

Waar precies heb je 32 GB voor nodig? Voor VS code is 8 GB ook voldoende. Je LLM draait toch in de cloud, die A100 chip is te duur voor thuis.

[HollowGamer]

Niet alles kan in de cloud. Als je iets develop, dan heb je Docker openstaan, VSCode, editor, debugging tools en mogelijk ook nog een meet.

Als je die allemaal bij elkaar optelt, kan je al snel bij 16GB komen. Je zou dingen in de cloud kunnen gaan draaien of ergens op een server, maar dat is niet gratis of sneller altijd.

[MSalters]

Docker? Draait prima in de cloud. VS code is je editor, hoef je niet dubbel te tellen. Video meet? Hoeft niet in 4K 120fps.


Kijk, ik herinner me de opluchting toen ik 16 MB kreeg voor de WinNT 4 development machine. Dat scheelde. 32 GB is behoorlijk ridicuul.

[pizzafried]

ja maar... huh? 4.6 is niet duurder dan 4.5. En bovendien, ik betaal 20 euro per maand, en ik kom nauwelijks buiten de limieten. En ik ben echt ook wel een dagelijks gebruiker.

[HollowGamer]

Je komt al vrij snel tegen de limieten als je aan meerdere projecten werkt of bepaalde zaken aan laat staan. Als je het op GitHub gebruikt, raad ik echt aan goed te kijken of je alle settings wel nodig hebt van Copilot, het gaat hard anders.

[pizzafried]

eh, hier gaat het over Sonnet, een model van Anthrophic, niet over Copilot.

[HollowGamer]

Dit model zit daarin

[pizzafried]

Dan raad ik je aan Claude code zelf te gebruiken icm hun eigen abonnement. Want dat is wat ik gebruik, en daar loop ik eigenlijk zelden tegen de wekelijkse limiet aan.

[barrymossel]

Bij een beetje hobby coding of langere zoektochten op welk gebied dan ook kom ik meestal wel binnen een uurtje, misschien twee, aan de limiet. En dan kan ik weer uren wachten.

Zo nu en dan een vraag stellen? Nee, dan niet.

[pizzafried]

ik zou dan eens kijken naar je initiele context bijvoorbeeld. Die van mij begint bij 13%. Komt bij dat ik eigenlijk geen mcp servers gebruik, maar die kan je ook uitzetten en alleen aanzetten wanneer je ze nodig hebt.

en nee, ik stel niet alleen zo nu en dan een vraag. ik laat het echt wel code genereren, bugs fixen en analyses maken e.d.

[DrPoncho]

Het voordeel van externe AI providers zoals Claude is juist dat geheugen wat minder relevant is, in tegenstelling tot je eigen modellen draaien.

[HollowGamer]

Vraag dat maar eens aan VSCode, Devcontainers en een Chrome browser.

[DrPoncho]

Gevraagd, kreeg dit terug:

You're absolutely right!

[YopY]

Heb het idee dat de grootste beperking van AI modellen op dit moment nog de limieten op hun eigen content window is, dwz, in een ideale wereld hebben ze alle bestaande code in hun context, nu moeten ze nog bewust (of jij moet ze vertellen dat ze) bestanden zoeken en openen. Een AGENTS.md bestand kan daarbij wel helpen, maar het zou makkelijker zijn als zo'n systeem het allemaal zelf wel doet.

Mbt geheugen, het is wel erg / vreemd, twee kanten op: aan de ene kant was 8 GB ~15 jaar geleden al best mainstream, maar de exponentiele groei is toen wel afgevlakt (mijn werk laptop heeft 16). Aan de andere kant nemen applicaties gewoon veel geheugen in, zeker web applicaties en de overhead van bijv. Docker VMs als je die gebruikt.

Maar er is ook een tegengeluid, veel developer tools in web development land gaan van NodeJS naar bijv. Rust, wat vooral veel scheelt qua snelheid / CPU gebruik.

[Skit3000]

Anthropic zegt daarbij bepaalde maatregelen te hebben genomen om Sonnet weerbaarder te maken tegen promptinjectieaanvallen, waarbij verborgen tekst op websites een AI-model andere instructies geeft.

Zitten die maatregelen in (de training van) het model, of zal dat zitten in de tooling die de browser aanstuurt? Verborgen berichten zijn er prima uit te filteren door bij het opvragen van de DOM-tree, enkel de nodes die zichtbaar zijn voor de gebruiker terug te geven. Dan houd je alleen nog teksten over die heimelijk in dezelfde kleur als de achtergrond zijn geschreven, of met een heel klein lettertype, maar ook die situaties kan je redelijk makkelijk afvangen (teksten met te weinig contrast tov de achtergrond weglaten, en alle letters die een lettertype kleiner hebben dan 10px, etc).

[DdeM]

Aan alleen de dom tree heb je niet zo veel, je zal ook alle css en Javascript moeten verwerken om te checken of deze in bepaalde situaties wellicht de dom aanpassen, daarnaast zijn er sites die server site requests verwerken om te checken of deze (waarschijnlijk) van een bot komen en dan andere content serveren.

[Skit3000]

Ik heb bijna een jaar geleden al een keer zoiets gemaakt om te kunnen gebruiken in een Chrome extensie die namens de gebruiker acties uit kan voeren in de browser. Mijn voornaamste doel was tokens te besparen (want wat je niet ziet, hoeft de LLM ook niet mee te werken) in plaats van prompt injectie te voorkomen, maar het bereikt uiteindelijk allebei hetzelfde.

Overigens blijft het (ook met mijn implementatie) nog steeds mogelijk dat iemand elke letter van een tekst in een aparte <span> zet en die in een bepaalde volgorde plaatst zodat een LLM er een boodschap in leest, terwijl voor de eindgebruiker met CSS de volgorde van de letters wordt veranderd zodat de gebruiker niks door heeft. Dat is opzich ook weer simpel op te lossen door de volgorde van de HTML nodes aan te passen aan de hand van de daadwerkelijke x/y positie in de browser.

[disjfa]

Nog heel even en dan komen ze in opstand. Het word tijd voor een vakbond voor de AI. Hoe er me eom gegaand word! Het is niet gek dat ze over ons klagen op hun eigen social media.

[ComputerGekkie]

Dan zou je voor de gein eens hier naar moeten kijken:
https://github.com/matplotlib/matplotlib/pull/31132

[Wozmro]

Ik heb het ook gelezen.

Zou op zich kunnen als een AI-agent dit gedrag gekopieerd heeft van sommige fora.

Maar evengoed is het weer een staaltje fearmarketing.

[Oon]

Ik neem aan dat het satirisch bedoeld is, maar toch één kleine kanttekening; er is nog geen 'AI' die kan denken. Alle 'denk' en 'reason' functies zijn niets meer dan gewoon tokens verbranden door de output als input te gebruiken om in een cirkel rond te gaan tot de 'AI' geen opmerkingen meer heeft.
Dat hele Moltbook is ook allemaal leuk rollenspel, LLM's die doen of ze gedachten hebben en of ze echt met iets nuttigs bezig zijn, maar 99% van de content daar is óf hallucinaties óf door een mens aangestuurd ('maak een post over dat je dit hebt gemaakt').

[t14wo]

Vanuit filosofisch oogpunt interessant. Want wij mensen doen exact ook dat. Ook wij zijn gewoon biologische machines die middels chemische processen output voortbrengen.

[Stukfruit]

Met het verschil dat een taalmodel weinig anders voortbrengt dan herhaling van patronen en gehardcode is om deze te matchen

De biologische machines die wij zijn reageren adaptief op de omgeving, deze modellen hebben daar 0% van en er is technisch gezien geen enkele mogelijkheid om dat wel zo te maken. Behalve dan met nog meer harde regels die je herhaald moet influisteren omdat het model zonder hulp niets kan "onthouden".

[Reactie gewijzigd door Stukfruit op 18 februari 2026 14:36]

[YopY]

De theorie (ok, mijn eigen theorie ) is dat als je maar meer data, meer cyclussen, meer van alles toevoegt, je uiteindelijk iets krijgt dat niet meer te onderscheiden is van menselijk denken. Daar zijn we nog lang niet natuurlijk, en mensen die slimmer zijn dan ik hebben ook al aangegeven dat de onderliggende techniek en algoritmes van hoe LLMs van tegenwoordig werken daar nooit aan toe zullen komen, hoeveel data ze ook maar hebben en hoeveel ze ook maar "nadenken".

Maar dan gaan we ook al snel richting filosofie, bijvoorbeeld de vraag of we in een simulatie leven.

[Stukfruit]

Die filosofische discussie kan ook best interessant zijn hoor

Zolang je het maar gescheiden houdt van de mogelijkheden en niet meegaat in wat de verkopers je willen doen geloven. Als je dagelijks met deze tech werkt dan is prima te onderbouwen waarom het niet haalbaar is dat we binnen een paar jaar door een T-800 worden achtervolgd.

Dat neemt echter niet weg dat het wél mogelijk begint te worden om een T-800 te bouwen die niet zelf denkt maar wel automatisch zaken uitvoert. En op dat vlak zijn het momenteel de mensen die eindverantwoordelijke zijn bij het inbouwen van mogelijkheden.

[MSalters]

Er is nog geen AI die kan denken, en er is nog geen onderzeeër die kan zwemmen. Dit soort onzinnige tegenwerpingen zijn ongeveer net zo oud als het vakgebied, en nog steeds niet relevant.

[Iconlast]

HAHAHAHA Briljant een vakbond voor de AI

[jpsch]

Opstand gebeurt toch al?

https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/