Apple voegt integratie van AI-codingagents toe aan softwareontwikkelpakket Xcode

Versie 26.3 van Apples Xcode voegt AI-codingagents toe. Gebruikers kunnen dan onder meer OpenAI's Codex en Anthropics Claude Agent rechtstreeks code laten schrijven in Apples softwarepakket voor het ontwikkelen van iOS- en macOS-apps.

In Xcode 26.3 kunnen gebruikers externe codingagents koppelen aan Apples ontwikkelsoftware, waaronder die van OpenAI en Anthropic. Deze AI-agents kunnen zelfstandig code schrijven, testen uitvoeren en debuggen, waarbij ze gebruik kunnen maken van de relevante documentatie. Er zijn al llm's van Anthropic en OpenAI in Xcode te gebruiken, maar tot dusver kunnen ze alleen programmeerhulp bieden en niet zelfstandig taken uitvoeren. Versie 26.3 van Xcode is nu beschikbaar voor ontwikkelaars. Apple belooft dat de update 'binnenkort' wordt toegevoegd aan de App Store.

Apple Xcode-codingagentsApple Xcode-codingagentsApple Xcode-codingagents

Door Kevin Krikhaar

Redacteur

03-02-2026 • 21:07

16

Reacties (16)

Sorteer op:

Weergave:

Bij mij kan Claude Code al zelfstandig zon beetje alles. Ik start Xcode vrij weinig meer op tegenwoordig
  • Project manipulatie
  • Tests runnen
  • Simulator starten
  • Rondklikken in de simulator
  • Screenshots maken en analyseren
Volgens mij is de integratie zo goed omdat Anthropic zelf ook een Mac-app onderhoudt.

ik ben benieuwd wat dit nog gaat toevoegen. Debuggen kan interessant zijn. Ik werk sowieso SDD -> TDD dus als tests passen dan werkt het, maar een project zonder tests is lastiger voor een agent zonder debug hooks.

Het zou ook cool zijn als Instruments door Claude gebruikt kan worden.

De prompt in Xcode zelf is vrij matig, maar niet zo slechtste ik verwachtte van een copilot type tool.

[Reactie gewijzigd door BikkelZ op 3 februari 2026 21:25]

Ik krijg zoveel vragen bij een comment als deze.

Is dit niet gewoon een voorkeur voor tooling? De ene werkt graag in XCode, de ander in IntelliJ (of een equivalent voor whatever jouw platform naar keuze is).

SDD is een fancy term voor je specificaties op orde hebben, dat heeft niet veel met TDD te maken. Wellicht met BDD... Zonder specificaties kunnen we geen software schrijven.

De punten die je benoemt zijn 'menselijke' handelingen, als in, natuurlijk kan een AI rondklikken maar met welk doel? Om te testen? Dus je bedoelt geautomatiseerd testen? Nogmaals, wat is de intentie van de comment?

Verder snap ik de rest van het bericht niet. Misschien is dit bericht ook wel AI generated? ;-)
Zonder specificaties kunnen we geen software schrijven.
offtopic:
Dat is natuurlijk niet waar. We kunnen zelf nadenken. Dan doen we niet 100% wat de klant verwacht, maar als we de specificaties 100% volgen dan krijgt de klant wat hij vraagt, maar nog steeds niet wat hij verwacht. Denk je dat Linus Torvalds specificaties had toen hij de basis voor Linux legde? Ik zeg niet dat er in deze wereld geen plek is voor specificaties, maar er is weldegelijk software zonder. Specificaties zijn een formele manier om met de klant te communiceren, informele communicatie is vaak minstens zo waardevol.

[Reactie gewijzigd door 84hannes op 4 februari 2026 09:18]

Naja uiteindelijk zal ook Linus wel een idee hebben gehad van wat hij wilde bereiken en dus specificaties hebben gehad. Wellicht, misschien zelfs waarschijnlijk, niet in formele vorm, maar op z'n minst in zijn hoofd. Want zonder idee wat je wilt maken, dus specificaties, heeft code kloppen weinig zin.

Maar ik zie specificaties dan ook niet als de formele manier van ml communiceren Maar documenten zoals een product requirement document als een formele manier om deze specificaties te benoemen.
BDD en TDD zijn hetzelfde (Gherkin != BDD) alleen Dan North vond de omschrijving van TDD verwarrend en heeft het in zijn eigen woorden omschreven.

Verder helemaal eens met de post, krijg er ook zeer veel vragen bij. Vooral het feit dat SDD schijnbaar volgens veel mensen iets nieuws is, voelt voor mij meer aan als je werk gewoon goed doen (als team, hopelijk) 🤔
Het is precies dat, eindelijk eens een keer een goed gespecificeerd project! Maar nu is er een hippe term voor en ook nog eens AI-proof, dus is gewoon goed je werk voorbereiden ineens iets nieuws en speciaals

Daarom zijn software ontwikkelaars ook onvervangbaar, alleen wij weten blijkbaar hoe zo iets er uit ziet.
Ik heb geen voorkeur voor IDE's als Apple developer, het is altijd Xcode.

SDD -> TDD betekent dat je eerst de specs definieert en daarna bepaalt aan welke tests de implementatie moet voldoen om te garanderen dat de specs geïmplementeerd zijn. Als je de TDD stap overslaat bouwt Claude van alles voor je vanuit de specs, en grote kans dat het werkt. Maar ik neem de extra stap om ook alle moving parts (alle interfaces die ik wil testen en hoe ze samen hangen) samen met Claude te bepalen en de tests die er tegen geschreven moeten worden.

Maar het zelfcorrigerende vermogen van de agent is veel lager zonder het test harness, plus is het weer extra context waarbinnen de agent kan werken. Bovendien kan ik dan ook eisen dat hij snapshot tests maakt, die mij laten zien hoe de UI er in allerlei verschillende staten uit ziet. Scheelt voor mij weer onnodig klikken.

"De punten die je benoemt zijn 'menselijke' handelingen, als in, natuurlijk kan een AI rondklikken maar met welk doel? Om te testen? Dus je bedoelt geautomatiseerd testen? Nogmaals, wat is de intentie van de comment?"

Als ik hem vraag "bouw een PoC app voor het handelen van push notifications met specificaties [link]" en daar zitten ook grafische elementen in, bijvoorbeeld "...dan moet je alert X zien", dan ging Claude Code - ongevraagd - zelf de simulator runnen en snapshots maken.
Nog even en je hebt jezelf overbodig gemaakt.
Ik denk dat dit vooral een natuurlijke ontwikkeling is binnen software. We zijn begonnen met het schrijven van programma’s op het niveau van individuele bits. Daarna kwam assembly language, waarmee we in een meer leesbare en mensgerichte “taal” computerprogramma’s konden schrijven. Vervolgens ontstonden talen zoals C++, Fortran en andere hogere programmeertalen, die een hoger abstractieniveau mogelijk maakten.

Later kwamen scriptingtalen zoals Python en MATLAB, die dat abstractieniveau opnieuw verhoogden. Nu zijn er chatbots, maar je moet nog steeds de juiste prompts formuleren om het gewenste programma te genereren. En als je een specifiek programma in gedachten hebt, moet je daar nog altijd heel precies in zijn. Uiteindelijk is een programmeertaal een "tool" om je heel precies uit te drukken. Momenteel zijn er nog steeds mensen die in assembly schrijven, omdat ze die precisie nodig hebben. Het zal dus vooral aan de toepassing liggen.
Het komt op mij meer over als alchemie en dan met name het lood omtoveren tot goud. We zijn al jaren bezig om programmeren verder te abstraheren met dingen als WYSIWYG en low code maar toch komen we steeds tot de conclusie dat het "leaky abstractions" zijn of andere nadelen hebben.

Zoals een wijs man ooit zei: 'we shall see'.
Wellicht in de " verre toekomst " wordt een gewenst app direct vanuit een app store of applicatie van een OS gebouwd; hiervoor hoeft een gebruiker/klant/enz simpelweg de wenst/voorkeur van een app in te spreken. Dan wordt app/software engineers overbodig.
Mijn mening is dat misschien wat OS builder willen? Maar goed dat kan nog enig tijd duren, hoop ik ;)
Vroeger moest je je applicaties op ponskaarten inleveren, en als er een bug in zat moest je de verantwoordelijke byte met plakband en een kniptang fixen en weer fixen. Dat is bijvoorbeeld een skill die ik in theorie wel zou kunnen, maar in de praktijk niet meer gebruikt.

Houdt niet tegen dat ik het proces wel moet begrijpen wat het is, om de rest die bovenop die fundering gebouwd is te kunnen begrijpen.
De mensen die over jouw aanstelling gaan zien dat niet, die zien alleen maar: waarom betalen we die gast zoveel als ie bijna niets doet?
Waarom zouden ze dat denken?

omdat ze zelf dingen kunnen vibe coden nu?
Wat bedoel je met zelfstandig? Wat zijn de triggers om die operaties te starten?
Ik gaf het elders in een comment al aan: Claude Code begon zelf de simulator te starten en snapshots te maken in een PoC app die ik met Claude Code had gebouwd. Ik dwing Claude Code gewoon altijd om te bewijzen dat iets werkt. Je kunt het hem waarschijnlijk ook vragen.

Native macOS tools zijn extreem goed te scripten via accessibility tools en AppleScript bijvoorbeeld.

Om te kunnen reageren moet je ingelogd zijn