GitHub test Grok Code Fast 1 nu ook voor Visual Studio, JetBrains en Xcode

Microsoft maakt xAI's Grok Code Fast 1 als publieke preview beschikbaar voor nieuwe diensten via GitHub Copilot. Het taalmodel is via de dienst voor verschillende integrated development environment-software beschikbaar. Gebruikers hebben een GitHub Copilot-abonnement nodig.

GitHub integreerde het model in augustus al in de Copilot-dienst voor het versioncontrolplatform, maar het model was toen alleen beschikbaar voor Visual Studio Code. Gebruikers met een abonnement op GitHub Copilot Pro, Pro+, Business of Enterprise krijgen vanaf deze week ook via ide’s zoals Visual Studio, Eclipse en Xcode en ide's van JetBrains toegang tot Grok Code Fast 1. Het model is via het modelselectiescherm beschikbaar. De uitrol is volgens GitHub stapsgewijs, dus niet iedereen heeft de optie direct tot zijn beschikking.

In sommige gevallen moeten gebruikers de optie nog handmatig activeren. Admins van organisaties met een Business- of Enterprise-abonnement moeten toegang tot de Grok-AI eerst via de Copilot-instellingen inschakelen.

Grok Code Fast 1 is een taalmodel dat volgens xAI volledig getraind is op code en daarom goed moet zijn in het helpen bij programmeren. Het llm zou vooral goed zijn in de talen TypeScript, Python, Java, Rust, C++ en Go. Gebruikers kunnen het model zowel als agent inzetten, als in een chatgesprek.

Reacties (14)

[bantoo]

Leuk, ga straks testen of het ook wat met C# kan. Nog niet eerder een X model gebruikt voor code.

Wel grappig hoe lang de lijst onderhand wordt voor model selectie.

[djwice]

Vraag het in een door jou gedefinieerde structuur assembly / processor instructies te schrijven en je weet niet wat je mee maakt.

Sommige stukken had je zelf in C# niet efficiënter kunnen krijgen.

Waarom?
Er is veel code met gecompileerde binaries naar verschillende platformen beschikbaar op internet als bron.

Waarom?
C# is een taal voor mensen om de computer instructies te geven, als de computer instructies schrijf is die taal niet nodig.

Maar?!
Precies je wil nog iets om te valideren/controleren of de code doet - en alleen doet - wat ie moet doen.

Bij mensen controleren we meestal niet of alleen soms het samengevoegde resultaat.

In de computer wereld zijn we inmiddels shift left gewend, en dat zorgt voor kwaliteit én snelheid. Door vroegtijdige ontdekking van misinterpretatie en foutjes van mensen.
Dat wil je niet in menselijke processen; extreem veel tussentijdse validatie stappen, want dat vertraagd en ondermijnt zelfstandigheid.

Wat als een computer de software die je normaal in een kwartaal met een team schreef in een paar dagen maakt me zelf evaluatie.
Eigenlijk wat we mensen ook laten doen voordat ze hun branch mergen naar main; de bench mag een paar dagen leven. Gooi je hooguit een paar dagen werk weg.

[Reactie gewijzigd door djwice op 9 oktober 2025 08:54]

[demianmonteverd]

Dit is een interessant idee, de LLM's optimaliseren op asm schrijven. Veel te veel werk voor 'normale' ontwikkelaars, maar met LLM's om het nodige werk te verzetten wellicht een optie.

[Skit3000]

Sommige stukken had je zelf in C# niet efficiënter kunnen krijgen.

LLMs die leren door te kijken naar het verschil tussen gecompileerde binaries en hun broncode, leren daarmee eigenlijk ook de optimalisatiestappen van de compiler. Dat lijkt me dus niet perse de beste manier om de meest efficiënte code te krijgen (want die compilers zijn allemaal mensenwerk).

Het nadeel van ASM is ook dat je niet zomaar even een package kunt inladen zoals bij high level programmeertalen zoals C#, Python, etc. Als je dus bijvoorbeeld een HTTP-call wilt doen, moet de LLM opeens (tien/honderd)duizenden regels aan code uitspugen, die het gratis krijgt wanneer het `pip install requests` draait en toevoegt met `import requests`.

[Niemand_Anders]

Het probleem van LLM is dat de bronnen met de hoogste betrouwbaarheid ook eveneens de slechtste bronnen zijn voor de AI.

Op websites zoals MSDN, StackOverflow en Reddit staat een hoop code, maar het is slechte code. Bij MSDN gaat het om voorbeeld code welke een bepaalde feature demonsteren en ontzettend veel weg laten welke normaal wel belangrijk is zoals bijvoorbeeld input validatie. StackOverflow en Reddit bevatten ook een hoop huiswerk opdrachten en ook lang niet alle reacties zijn goed. Ook een reactie met slechte code kan gewoon veel upvotes krijgen.

Dit is ook de hoofdzakelijke reden waarom vibe coding bugs (OWASP top 10) introduceerd welke bijna uitgestorven waren. En dan krijg je dus apps welke dus aan de client zijde een secret api key hebben (tea app).

[demianmonteverd]

Er zijn nog steeds dingen die een compiler niet kan. Met name optimaliseren op geheugen is iets dat je bijna vanzelf doet als je asm zelf schrijft. Voor grote projecten is het iets dat wellicht niet werkt met LLM's maar voor kleine stukjes is het best een poging waard.

Voor wat betreft hoe veel werk het is, een HTTP-call is niet eens zo veel code, als je bijv. de curl-lib erbij inzet. En al helemaal niet als je er al een routine voor hebt gemaakt natuurlijk. Het is minder 'ergnomisch' want je moet linken met de library en dergelijke en dat is natuurlijk minder fijn dan in python.

Ik zou eerder mij zorgen maken om i10n en i18n, maar heb het nog niet getest, vandaag (n.a.v. de reactie van djwice zijn reactie) klein stukje gedaan met ChatGPT en een stukje met Claude Opus en dat ging vrij aardig zonder i10n en i18n.

[YopY]

...maar dat doen compilers al? Ik betwijfel dat handgeschreven ASM sneller is dan een hogere programmeertaal voor 99% van de code, zeker voor C# code wat vaak business logica / CRUD code is en de performance bottleneck hem echt niet in de uitvoersnelheid van de code zit.

[demianmonteverd]

Het is beter qua geheugen gebruik, maar je krijgt (standaard) minder, bijv. in C# krijg je een veel rijkere ervaring met iets basaals als strings. Dus nee, ik zou niet switchen voor gewoon development voor jouw use-case (CRUD en alles dat daar bij komt kijken). Maar als je embedded software schrijft, kun je het overwegen misschien. Ik suggereer absoluut niet dat het beter word voor de meeste mensen, meer dat het een interessante use-case kan zijn.

Al die jaren ging het om developer productivity, en dat kun je gaan opvangen met LLM's in de toekomst, het is gewoon trade-offs zoals altijd, een interessante gedachte. Of het gaat lukken... mwa...

[djwice]

Je hebt in cpu-instructies veel minder taal-
elementen en grammatica en bijna geen overlappende functionaliteit.

Dat zorgt er voor dat de kans veel groter is dat het taalmodel de best passende instructie of set instructies kiest t.o.v. bijvoorbeeld python en al haar libraries.
Maar goed, we zaten in de C# context

De ondubbelzinnigheid en de zeer beperkte instructieset en eenduidige vorm van gebruik per instructie, kan er voor zorgen dat een taal model veel eenduidige te/betere keuzes kan maken dan in een "normale" taal. De kans op foute keuzes is simpelweg kleiner.

Ook zijn de instructies en hun gebruik zeer goed gedocumenteerd.

Dus wie weet hebben we over een tijdje heel compacte stukjes software / services die veel minder resources gebruiken en taken veel sneller verwerken dan de huidige implementaties.
En tools om uit te leggen wat de code doet.

[nopcode]

Ik werk vooral op kleine projectjes / scripts en ben daar toch eerder de fan van tragere / duurdere modellen die van de eerste keer goede code schrijven.

Ik heb paar weken met grok gewerkt en het ging wel heel goed in een typed codebase met goede testing infrastructuur. Ik gebruik dan sonnet 4.x als "architect" en de todolist gaat dan naar grok fast.

Het is idd heel fast, je kan niet meer "meelezen" wat nog wel ging paar maanden terug met een sonnet 3.x bijvoorbeeld.

[demianmonteverd]

In plaats van grok, ken je GPT-OSS? Is zelfs sneller en voor sommige taakjes prima (en lokaal te draaien als je wilt). Heb je ook Openhands en aider geprobeerd?

[nopcode]

GPT-OSS heb ik niet geprobeerd, de grok fast was gratis voor paar weken. Maar zit nu terug op "trage" modellen.

Ik gebruik voor Claude Code (ook soms met andere modellen, maar met claudes eigen modellen is het best) en dan verschillende modellen in Zed (en soms Kilo Code in VSCode).

All Hands / Open Hands was in mijn ervaring niet stabiel genoeg voor heel de dag te coden. Maar wel handig om snel iets klein te fixen.

[demianmonteverd]

Claude Code is de beste inderdaad (als je hun modellen gebruikt, de beste in alles). Ben nu meer en meer aan het testen met Open Hands. Aider heb ik veel gebruikt, heeft het altijd redelijk gedaan.

[redbullzuiper]

Heb hem al redelijk lange tijd beschikbaar hier. Vindt hem toch niet echt goed werken, de beste blijft toch echt Claude Sonnet 4 en nu 4.5. Het enige vervelende aan Sonnet is dat die vaak hele rits aan documentatie in markdown files gaat zitten schrijven, ondanks dat ik vraag dat niet te doen .GPT5 is alleen goed in 'Ask' mode maar duurt lang met antwoorden.