Claude gebruiken als softwarearchitect: skill-gids

Bijgewerkt op 12 min lezen KissMySkills
Op deze pagina
  1. Twee mislukkingen, één oorzaak
  2. De vakken zijn het makkelijke deel
  3. Een diagram beantwoordt niets daarvan, en een model zal er toch een prachtig exemplaar maken, omdat diagrammen een genre zijn en het er duizenden heeft gelezen. Onderzoek de pijlen, en het ontwerp verandert meestal. Vaak valt het terug tot minder blokken, wat de juiste uitkomst is.
  4. Waar het faalt
  5. Hoe installeer je de Viktor-skill?
  6. Voor wie is dit bedoeld?
  7. Gerelateerde Skill-gidsen
Skill · .md

\De Skill achter deze gids: Viktor - Software Architect AI Skill. Bevat wat je al draait, wat je niet kunt veranderen en de beslissingen die je al hebt genomen, zodat opties worden aangeleverd die zijn gefilterd op basis van je werkelijke systeem in plaats van een leeg veld - \$19, één betaling, voor altijd van jou.

Bekijk de Viktor Skill →

Een architectuur is een lijst van dingen waarvan je hebt besloten dat je ze niet zult kunnen doen. Een model zal je alleen ooit vertellen wat een ontwerp kan. Het is niet oneerlijk: het materiaal waarvan het heeft geleerd, is geschreven door mensen die systemen beschreven die werkten, op een schaal die groot genoeg was om erover te schrijven, en niemand publiceert een bericht over de saaie monoliet die het nog steeds prima doet. Wat terugkomt, is dus altijd greenfield en altijd maximaal - het systeem op de piek die je je voorstelde, op een leeg veld, met de gedwongen verkopen weggelaten.

Twee mislukkingen, één oorzaak

Bijna elk onbruikbaar architectuurantwoord is tot hetzelfde terug te voeren: het corpus is geschreven over het interessante probleem, door mensen die het hadden.

\Het ontwerpt op een leeg veld.\ Echte architectuur is bijna nooit greenfield. Het is een wijziging aan een bestaand systeem, uitgevoerd door mensen die er al zijn, gekoppeld aan zaken waar je niet aan mag komen. Vraag om het ontwerp en je krijgt er een dat van niets van dat alles uitgaat, en de duurste fouten in dit vak ontstaan niet door de verkeerde database te kiezen - ze ontstaan door te ontwerpen alsof een beperking niet bestaat.

\Het ontwerpt voor de piek.\ Eventgedreven, één service per domein, een wachtrij tussen elk paar componenten, Kubernetes eronder. Dat is niet verkeerd. Het zijn de verslagen van organisaties die dit nodig hadden, en er zijn geen verslagen van bedrijven die het prima deden zonder. Het gemiddelde van de literatuur is dus een architectuur voor een bedrijf dat groter is dan het jouwe.

Beide zijn te corrigeren, en geen van beide corrigeer je door betere vragen over het ontwerp te stellen. Je corrigeert ze door te veranderen wat het model mag aannemen.

De vakken zijn het makkelijke deel

Vraag om een architectuur en je krijgt vakken en pijlen. De vakken zijn bijna gratis: een service die één duidelijke taak uitvoert, is een opgelost probleem, en iedereen kan zich daar een voorstelling van maken.

\Alle moeilijkheid zit in de pijlen.\ Een pijl tussen twee vakken is een bewering dat deze twee dingen met elkaar kunnen communiceren, en die bewering wordt nooit door het diagram gerechtvaardigd. Is de aanroep synchroon, en zo ja, wat doet de aanroeper gedurende de tweehonderd milliseconden dat hij wacht? Wat gebeurt er als het mislukt - opnieuw proberen, en zo ja, is de bewerking idempotent, of wordt de kaart bij een nieuwe poging twee keer belast? Wat is de time-out, en wat gebeurt er daarna? Is de volgorde van belang, en garandeert iets die? Als deze pijl een uur lang uitvalt, wat werkt er dan nog en wat niet?

A diagram answers none of that, and a model will generate a beautiful one anyway, because diagrams are a genre and it has read thousands. Interrogate the arrows, and the design usually changes. Frequently it collapses back into fewer boxes, which is the correct outcome.

Een diagram beantwoordt niets daarvan, en een model zal er toch een prachtig exemplaar maken, omdat diagrammen een genre zijn en het er duizenden heeft gelezen. Onderzoek de pijlen, en het ontwerp verandert meestal. Vaak valt het terug tot minder blokken, wat de juiste uitkomst is.

Waar het echt goed in is

Het genereren van de foutsruimte. "Op welke manieren kan dit allemaal misgaan" is een recallprobleem over een enorme hoeveelheid postmortems, incidentverslagen en moeilijk bevochten discussies, en daar zijn deze tools precies voor. Het brengt de storingsmodus aan het licht die je anders over acht maanden in productie zou hebben ontdekt.

Wat het niet kan, is ze rangschikken, want voor rangschikking zijn je verkeer, je team, je tolerantie en je budget nodig. De taakverdeling is dus helder: het genereert de lijst, jij ordent die. Wie je vertelt dat het de ordening kan doen, verkoopt je iets.

Prompt 1 - het veld is niet leeg

Niets anders op deze pagina werkt voordat het model weet wat er al bestaat. Beantwoord dit eerlijk, ook wat ongemakkelijk is. Stel nog geen architectuur voor. Ik ga beschrijven wat er al bestaat. Lees het en vertel me vervolgens Vertel me wat je nog moet weten voordat je iets ontwerpt. WAT ER VANDAAG DRAAIT: - Talen, frameworks, datastores, hosting, die daadwerkelijk in op dit moment in productie draait - Wat hoe vaak wordt gedeployed en hoe dat gebeurt - Wat de huidige storingsmodi zijn. Wat ons daadwerkelijk alarmeert. WAT IK NIET KAN VERANDEREN: - Systemen die ik niet bezit, integraties die ik niet kan verbreken, contracten die het gedrag bepalen - Compliance- of dataresidentiebeperkingen - Alles waartoe het bedrijf zich extern heeft verplicht WIE HET BOUWT: - Hoeveel engineers, welk ervaringsniveau en wat zij in productie heeft beheerd - Wat geen van hen ooit in - Of er iemand stand-by is en of dat betaald wordt DE WERKELIJKE CIJFERS: - Huidige belasting, niet geprojecteerd. Gebruikers, verzoeken, datavolume. - Welke groei we het afgelopen jaar daadwerkelijk hebben gezien, niet de plan Vertel me daarom, voordat je iets voorstelt, welke van deze welke beperking de ontwerpruimte het meest begrenst, en zeg duidelijk welke

van mijn antwoorden klinkt eerder als ambitie dan als meting.

Prompt 2 - de lijst met uitsluitingen

Deel dat een model nooit uit zichzelf noemt, en het deel dat daadwerkelijk de beslissing bepaalt. Begin bij elke optie die je voorstelt niet met wat deze mogelijk maakt. Begin met wat de optie uitsluit. Voor elke optie: - Wat kunnen we daarna niet meer doen, of alleen nog tegen hoge kosten? - Wat wordt onomkeerbaar, en wat kost het om dat terug te draaien het over 12 maanden? - Welke garantie geven we op - consistentie, volgorde, atomiciteit, de mogelijkheid om onafhankelijk te implementeren, de mogelijkheid om - Wat wordt moeilijker om over het systeem in één keer na te denken? - Wat voor nieuwe bugklasse maakt dit mogelijk die momenteel onmogelijk is? - Wat dwingt dit af voor elke toekomstige functie, of die functie dit nodig heeft? Zeg vervolgens in één zin per optie: het probleem dat we liever heb. Pas daarna vertel je me wat elke optie mogelijk maakt. Als een de optie kent geen noemenswaardige uitsluitingen, zeg dat dan en behandel dat als verdacht in plaats van als aanbeveling.
Skill in de schijnwerpers
Viktor - AI Skill voor softwarearchitectuur
Viktor - AI Skill voor softwarearchitectuur
$19 · één betaling

Bevat datgene wat hier het verschil maakt: wat je al uitvoert, wat je niet mag veranderen en de beslissingen die je al hebt genomen. Je echte beperkingen telkens opnieuw in een lege chat typen is de reden waarom de meeste mensen opgeven en genoegen nemen met het greenfield-antwoord, en een nieuwe sessie zal de architectuur waarover je vorige maand overeenstemming hebt bereikt zonder moeite tegenspreken.

Bekijk Viktor - Software Architect AI Skill →

Prompt 3 - ondervraag de pijlen

Negeer de vakken. Beantwoord voor elke pijl in dit ontwerp: 1. Synchroon of asynchroon? Als het synchroon is, wat is de wat doet de aanroeper terwijl die wacht, en wat ziet de gebruiker? 2. Wat gebeurt er wanneer het faalt? Opnieuw proberen, falen, in de wachtrij zetten, degraderen? 3. Als het opnieuw probeert: is de bewerking idempotent? Zo niet, wat doet een duplicaat in de echte wereld eigenlijk - twee keer afrekenen, twee keer verzenden, dubbel tellen? 4. Wat is de time-out en wat gebeurt er nadat die verloopt? 5. Is volgorde hier belangrijk? Zo ja, wat garandeert die? Als niets het garandeert, zeg dat dan. 6. Als deze pijl een uur uitvalt, wat werkt er dan nog steeds en wat niet? Wie merkt het als eerste: wij of de klant? 7. Wat is het datacontract en wat gebeurt er wanneer de ene kant verandert? Vervolgens: welke pijl is degene die iemand wakker zal maken, en welke pijlen alleen bestaan omdat we vakken hebben getekend die niet nodig waren scheiden? Noem ze. Twee vakken samenvoegen is een geldig antwoord en ik wil het horen als het van toepassing is. ONTWERP: [PASTE OR DESCRIBE]

Prompt 4 - ontwerp het voor een tiende van de schaal

Het nuttigste uur dat je zult besteden. Het scheidt de complexiteit die dragend is van de complexiteit die aspiratief is, en het antwoord is vaak ongemakkelijk.

Neem het ontwerp dat we zojuist hebben besproken. Ontwerp nu hetzelfde systeem voor een tiende van de belasting die ik je heb verteld, met hetzelfde team. Beantwoord daarna: - Wat heb je verwijderd? - Welke van de dingen die je hebt verwijderd losten een probleem op die ik vandaag daadwerkelijk heb, en welk probleem ze oplosten dat ik verwachten te hebben? - Voor elk verwijderd stuk complexiteit: bij welk specifiek, meetbare punt zou ik het weer moeten toevoegen? Geef me een getal, niet met "als we opschalen". - Hoe duur is het om het later weer toe te voegen, vergeleken met het nu bouwen ervan? Wees eerlijk over wanneer later echt slechter is. Tot slot: als ik de kleinere versie bouw, waar zou ik dan spijt van hebben over twee jaar, en waar zou ik blij mee zijn? Beargumenteer beide kanten goed te doen in plaats van mij gerust te stellen over de keuze waaraan ik de voorkeur aan geef.

Prompt 5 - de storingsruimte, die je vervolgens rangschikt

Genereer alle manieren waarop dit systeem kan falen. Wees uitputtend en niet dan selectief - ik doe de prioritering wel, dat is niet jouw taak en je hebt mijn cijfers niet. Neem minimaal het volgende op: - Elk onderdeel dat afzonderlijk uitvalt, en het effect daarvan - Gedeeltelijke storing: traag in plaats van uitgevallen - De datastore: niet beschikbaar, traag, vol, beschadigd, hersteld uit een oude back-up - Een netwerkpartitie tussen twee willekeurige onderdelen - Een afhankelijkheid die zijn gedrag verandert zonder het ons te vertellen - Een belasting die tien keer hoger is dan verwacht en in één minuut binnenkomt - Ongelijkmatig binnenkomende belasting: één klant, één sleutel, één tenant - Klokafwijking, dubbele berichten en berichten die niet in de juiste volgorde binnenkomen - Een uitrol die slechts gedeeltelijk is voltooid - Gegevens die geldig maar absurd zijn Voor elk: wat er stukgaat, wat de gebruiker ziet, hoe we erachter komen en of het zichzelf herstelt. Markeer vervolgens de stille fouten - situaties waarin het systeem blijft worden beantwoord, maar waarvan de antwoorden onjuist zijn. Dat zijn de vragen die ik wil bovenaan staan en normaal gesproken in een ontwerpbeoordeling mist.

Prompt 6 - hoe komen we er daadwerkelijk

Greenfield-ontwerpen slaan dit over, en daar zitten de werkelijke kosten. Een doelarchitectuur zonder migratiepad is een wens.

We bouwen dit niet vanaf nul. Dit is wat er bestaat: [DESCRIBE]. Geef me het pad van hier naar het doelontwerp, in stappen die kunnen we elke stap onafhankelijk uitrollen, terwijl het systeem voortdurend beschikbaar blijft. Voor elke stap: - Wat er wordt opgeleverd en wat de toestand van het systeem daarna is - Kunnen we hier permanent stoppen en er nog steeds beter voorstaan dan nu zijn? Als het antwoord voor een stap nee is, is die stap te groot is - splits het op. - Wat er parallel aan het oude pad draait en hoe lang - Hoe draaien we het terug nadat het in productie is genomen, niet ervoor - Welke gegevens moeten worden gemigreerd en of dat moet twee keer gemigreerd - Wat er tijdens deze stap slechter wordt en wie dat merkt Daarna: de totale kosten in engineer-weken en het punt waarop geen rendement - de stap waarna terugdraaien onpraktisch wordt. Als het eerlijke antwoord is dat de migratie meer kost dan het het doelontwerp waard is, zeg dat dan gewoon.

Twee dingen die het met zekerheid zal beweren, maar die het niet kan weten

Prestatiecijfers. Als je vraagt hoeveel verzoeken per seconde een ontwerp aankan of wat de latentie zal zijn, produceert het een getal. Het heeft geen idee. Die cijfers hangen af van je hardware, je datastructuur, je querypatronen en je toegangsverdeling, en de enige manier om ze te verkrijgen is door te meten. Beschouw elk aangeboden cijfer voor doorvoer, latentie of capaciteit als een tijdelijke aanduiding en plaats een loadtest waar het getal hoort te staan.

Huidige versies, limieten en prijzen. Servicelimieten, limieten van beheerde databases, instantiegroottes, wat een cloudprovider in rekening brengt en welke versie welke functionaliteit heeft afgeschaft. Dit verandert allemaal, en het model antwoordt op basis van wat het voor het laatst heeft gezien. Haal al deze informatie op de dag waarop je beslist uit de actuele documentatie van de provider zelf, want een architectuur die op een verouderde limiet is gebaseerd, is een ontwerp dat na een jaar faalt, op het slechtst mogelijke moment.

Waar het faalt

Fout Wat er gebeurt Wat ermee te doen
Greenfield als standaard Een ontwerp dat uitgaat van een leeg veld, geen legacy en niets wat je niet mag aanraken Beschrijf wat er vandaag draait, inclusief de gênante delen, voordat je iets vraagt
Ontworpen voor de piekbelasting De architectuur van een bedrijf dat met dit interessante probleem te maken kreeg en erover schreef Vraag naar hetzelfde systeem bij een tiende van de belasting en vergelijk vervolgens
Mogelijkheden, nooit uitgesloten opties Wat het ontwerp mogelijk maakt, zonder te zeggen wat je ervoor hebt opgegeven Eis eerst de lijst met uitgesloten opties en beschouw een optie zonder zo'n lijst als verdacht
Prachtige diagrammen Vakken en pijlen waarin elke lastige vraag in een pijl zit en geen enkele wordt beantwoord Stel elke pijl ter discussie. Twee vakken samenvoegen is een geldige uitkomst
Verzonnen prestaties Een aantal requests per seconde of een latentiecijfer zonder onderbouwing Behandel elk getal als een placeholder voor een loadtest
Verouderde platformfeiten Quota, limieten, instancetypen en prijzen van de laatste keer dat het die informatie zag Documentatie van de provider, van die dag, voor elk onderdeel
Geen migratiepad Een doelontwerp zonder rekening te houden met hoe je daar komt terwijl het systeem live is Eis onafhankelijk opleverbare stappen, die je elk afzonderlijk kunt stopzetten
Het rangschikt wanneer je erom vraagt Als je vraagt welke fout het belangrijkst is, geeft het antwoord, zonder ook maar een van je cijfers te gebruiken Laat het de ruimte genereren. Jij bepaalt de volgorde

Hoe installeer je de Viktor-skill?

De download is een ZIP met SKILL.md in de hoofdmap van het archief, niet in een geneste map - die mapstructuur is meestal de reden dat uploaden mislukt. Open in de Claude-desktopapp Customize → Skills, upload de ZIP en schakel deze in.

Voor Skills moet code-uitvoering zijn ingeschakeld, onder Settings → Capabilities. Het helpcentrum van Anthropic vermeldt momenteel Skills voor Free, Pro, Max, Team en Enterprise, terwijl de tutorial van de Academy Pro, Max, Team en Enterprise vermeldt - dus als je het gratis abonnement gebruikt, controleer dan Settings → Capabilities voor je eigen account in plaats van de informatie op een van beide pagina's zomaar aan te nemen. De volledige uitleg staat in de installatiehandleiding voor Skills.

In ChatGPT of Gemini is er geen uploadstap: open SKILL.md, kopieer de inhoud en plak die in aangepaste instructies. Je verliest automatische activering, maar behoudt de methode.

Voor wie is dit bedoeld?

Architecten en staff engineers die een sparringpartner willen die tegenspreekt, tech leads die ontwerpbeslissingen boven hun salarisniveau nemen, en founders die beslissen hoe ze iets bouwen voordat ze zich eraan committeren. Het werkt in Claude, ChatGPT of elke AI-chat.

De engineeringrollen zijn opgesplitst in hun eigen Skills, elk $19 en een eenmalige download:

De bredere verzameling bestaat uit de Skills voor softwareontwikkelaars en de Skills voor software en IT.

Samengevat:

Een architectuur is een lijst van dingen die je ervoor hebt gekozen niet te kunnen doen, en een model zal altijd alleen mogelijkheden beschrijven, omdat het corpus is geschreven door mensen van wie het interessante probleem publicatie waard was. Vertel het wat er al draait, wat je niet kunt veranderen en wie het bouwt, voordat het iets voorstelt. Vraag eerst naar uitsluitingen voordat je naar mogelijkheden vraagt, en beschouw een optie zonder nadelen als een waarschuwing in plaats van een aanbeveling. Negeer de vakken en ondervraag elke pijl, want daar zitten fouten, volgorde, idempotentie en de impactradius - en wees bereid twee vakken weer samen te voegen. Ontwerp hetzelfde systeem voor een tiende van de belasting om erachter te komen welke complexiteit dragend is. Laat het de volledige foutsituatie genereren en doe de rangschikking zelf. En laat het het migratiepad tonen, in stappen waar je kunt stoppen, want een doelontwerp zonder route ernaartoe is een wens. Voor je echte beperkingen en eerdere beslissingen die tussen sessies worden bijgehouden, Viktor - AI Skill voor softwarearchitectuur ($19). Werkt in Claude, ChatGPT en elke AI-chat, met een 30 dagen geld-terug-garantie.

Skill · .md · Werkt met Claude & ChatGPT

Viktor - AI Skill voor softwarearchitectuur

Vraagt wat er al draait voordat het iets voorstelt, begint met wat een ontwerp uitsluit in plaats van wat het mogelijk maakt, ondervraagt de pijlen in plaats van vakken te tekenen en toont het migratiepad in stappen waar je kunt stoppen. Geen abonnement. Permanent van jou.

$19
Verkrijg de Viktor Skill →

KissMySkills is een marktplaats met meer dan 2.000 AI-Skills, meer dan 80 promptpakketten, meer dan 75 agents en gratis tools voor Claude, ChatGPT en elke AI-chat.

Gerelateerde Skill-gidsen

Veelgestelde vragen

Can Claude design a software architecture?+

It can produce a design, and the design will be greenfield and maximal, because the material it learned from was written by people describing systems that worked at a scale worth writing about. Nobody publishes a post about the boring monolith that is still fine. So you get the architecture of a company larger than yours, on an empty field, with the foreclosures left out. That is correctable, but not by asking better questions about the design - only by changing what the model is allowed to assume.

Why does AI always suggest microservices and Kubernetes?+

Because those are the write-ups of organisations that genuinely needed them, and there are no write-ups of the companies that did fine without. The average of the literature is therefore an architecture for a larger company. The cheapest correction is to ask for the same system at one tenth of the load you stated, with the same team, then ask what was removed and at what specific measurable point each removed piece would need to come back.

What is an architecture, really?+

A list of things you have decided you will not be able to do. Choosing eventual consistency forecloses certain guarantees, choosing a monolith forecloses independent deployment, choosing a particular store forecloses certain shapes of growth. The foreclosures are the decision. A model leads with capabilities every time and will not volunteer what you gave up, so ask for the foreclosure list before the enablement list - and treat an option that appears to have no downsides as suspicious rather than as a recommendation.

Why are AI architecture diagrams misleading?+

Because the boxes are the easy part. A service that does one clear thing is a solved problem. All of the difficulty is in the arrows, and an arrow is a claim that two things can talk which the diagram never justifies. Synchronous or asynchronous, what happens on failure, whether a retry is safe, what the timeout is, whether order matters and what guarantees it, what still works if this arrow is down for an hour. Interrogate the arrows and the design usually changes, often collapsing back into fewer boxes.

What is AI genuinely good at in architecture work?+

Generating the failure space. Asking what are all the ways this can go wrong is a recall problem across an enormous body of postmortems and incident write-ups, which is exactly what these tools are for, and it will surface the failure mode you would otherwise have found in production in eight months. What it cannot do is rank them, because ranking needs your traffic, your team, your tolerance and your money. It generates the list, you order it.

Can it estimate how much load my design will handle?+

It will give you a number and it has no idea. Throughput, latency and capacity depend on your hardware, your data shape, your query patterns and your access distribution, and the only way to get them is to measure. Treat any performance figure it offers as a placeholder where a load test should go. The same applies to service quotas, managed-database limits, instance sizes and cloud pricing, all of which change and all of which it answers from whatever it last saw.

Why do AI designs never include a migration path?+

Because greenfield designs do not need one, and greenfield is what the corpus describes. In reality a target architecture with no route to it is a wish, and the migration is where most of the cost lives. Ask for the path in steps that each ship independently with the system live, and apply one test to every step: could we stop here permanently and still be better off than we are now? If the answer is no, the step is too big. Also ask where the point of no return is.

How do I install the Viktor skill?+

The download is a ZIP with SKILL.md at the root of the archive rather than inside a nested folder, which is the usual reason an upload fails. In the Claude desktop app open Customize, then Skills, upload the ZIP and toggle it on. Skills need code execution enabled, under Settings then Capabilities. Anthropic's help centre currently lists Skills on Free, Pro, Max, Team and Enterprise, while its Academy tutorial lists Pro, Max, Team and Enterprise, so if you are on the free plan check Settings then Capabilities for your own account rather than trusting either page. In ChatGPT or Gemini there is no upload step, so open SKILL.md, copy the contents and paste them into custom instructions.

~/get-started

Skills die werken. Geen onzin.

Blader door elke skill, prompt pack en agent in de winkel.

Bekijk alle vaardigheden →Of probeer de gratis tools