Come usare Claude come architetto software: la guida alla Skill Viktor

Updated
Skill · .md

Lo Skill alla base di questa guida: Viktor - Software Architect AI Skill. Tiene conto di ciò che già esegui, di ciò che non puoi modificare e delle decisioni che hai già preso, così le opzioni arrivano filtrate dal tuo sistema reale invece che da un campo vuoto - 29 $, un unico pagamento, tuo per sempre.

Visualizza lo Skill di Viktor →

Un'architettura è un elenco delle cose che hai deciso di non poter fare. Un modello ti dirà soltanto cosa può fare un design. Non è disonesto: il materiale da cui ha appreso è stato scritto da persone che descrivevano sistemi funzionanti, a una scala che li rendeva degni di essere descritti, e nessuno pubblica un articolo sul noioso monolite che funziona ancora bene. Quindi ciò che torna è sempre greenfield e sempre massimale: il sistema al picco che hai immaginato, su un campo vuoto, con i pignoramenti esclusi.

0:15 · loop Same AI, same question. One file makes it a specialist.

Due fallimenti, una sola causa

Quasi ogni risposta architetturale poco utile riconduce alla stessa cosa: il corpus è scritto sul problema interessante, da persone che lo hanno affrontato.

Progetta su un campo vuoto. La vera architettura non è quasi mai greenfield. È una modifica a un sistema che esiste, gestito da persone che esistono, collegato a cose che non ti è permesso toccare. Chiedi il design e ne ottieni uno che presume che nulla di tutto questo esista, e gli errori più costosi in questa disciplina non consistono nello scegliere il database sbagliato - consistono nel progettare come se un vincolo non esistesse.

Progetta per il picco. Architettura guidata dagli eventi, un servizio per dominio, una coda tra ogni coppia di componenti, Kubernetes alla base. Non sono scelte sbagliate. Sono le descrizioni di organizzazioni che ne avevano bisogno, e non esistono descrizioni delle aziende che se la sono cavata bene senza. Quindi la media della letteratura è un'architettura per un'azienda più grande della tua.

Entrambi sono correggibili, e nessuno dei due si corregge facendo domande migliori sul design. Si correggono cambiando ciò che il modello è autorizzato ad assumere.

I riquadri sono la parte facile

Chiedi un'architettura e ottieni riquadri e frecce. I riquadri sono quasi gratuiti: un servizio che fa una cosa chiara è un problema risolto e tutti riescono a immaginarlo.

Tutta la difficoltà sta nelle frecce. Una freccia tra due riquadri afferma che queste due cose possono comunicare, ma il diagramma non giustifica mai questa affermazione. La chiamata è sincrona? E, in tal caso, cosa fa il chiamante nei duecento millisecondi in cui aspetta? Cosa succede quando fallisce: si ritenta? E, in tal caso, l'operazione è idempotente o un nuovo tentativo addebita la carta due volte? Qual è il timeout e cosa succede dopo? L'ordine conta? E c'è qualcosa che lo garantisce? Se questa freccia non funziona per un'ora, cosa continua a funzionare e cosa no?

Un diagramma non risponde a nessuna di queste domande, e un modello ne genererà comunque uno bellissimo, perché i diagrammi sono un genere e ne ha letti a migliaia. Interroga le frecce e, di solito, il progetto cambia. Spesso si riduce a un numero inferiore di riquadri, che è il risultato corretto.

In cosa è davvero bravo

Generare lo spazio dei guasti. «Quali sono tutti i modi in cui può andare storto?» è un problema di completezza che richiede di attingere a un'enorme quantità di analisi post-mortem, resoconti di incidenti e discussioni ricche di esperienza, ed è esattamente a questo che servono questi strumenti. Farà emergere la modalità di guasto che avresti scoperto in produzione tra otto mesi.

Quello che non può fare è stabilire un ordine, perché per farlo servono il tuo traffico, il tuo team, la tua tolleranza e i tuoi soldi. Quindi la divisione del lavoro è chiara: genera l'elenco, tu lo ordini. Chiunque ti dica che può stabilire l'ordine sta vendendo qualcosa.

Prompt 1 - il campo non è vuoto

Nient'altro in questa pagina funziona finché il modello non sa che cosa esiste già. Rispondi con onestà, comprese le parti imbarazzanti.

Non proporre ancora un'architettura. Sto per descrivere ciò che già esiste. Leggilo, poi dimmi dimmi che cos'altro ti serve sapere prima di progettare qualsiasi cosa. CHE COSA FUNZIONA OGGI: - Linguaggi, framework, database, hosting, effettivamente in in produzione in questo momento - Che cosa viene distribuito, con quale frequenza e come viene distribuito - Quali sono le modalità di guasto attuali. Che cosa ci fa effettivamente scattare gli allarmi. CHE COSA NON POSSO CAMBIARE: - Sistemi che non possiedo, integrazioni che non posso interrompere, contratti che ne impongono il comportamento - Vincoli di conformità o di residenza dei dati - Qualsiasi impegno che l'azienda ha assunto esternamente CHI LO STA COSTRUENDO: - Quanti ingegneri ci sono, il loro livello di esperienza e che cosa hanno gestito in produzione prima - Che cosa nessuno di loro ha mai gestito in - Se c'è qualcuno reperibile e se viene pagato I NUMERI REALI: - Carico attuale, non previsto. Utenti, richieste, volume di dati. - Quale crescita abbiamo registrato effettivamente nell'ultimo anno, non quella piano Poi, prima di proporre qualsiasi cosa: dimmi quali di questi vincoli limita maggiormente lo spazio di progettazione e di' chiaramente quale delle mie risposte suona aspirazionale anziché misurato.

Prompt 2 - l'elenco delle rinunce

La parte che un modello non offre mai spontaneamente, e la parte che costituisce effettivamente la decisione.

Per ogni opzione che proponi, non iniziare da ciò che abilita. Inizia da ciò che preclude. Per ogni opzione: - Che cosa non potremo più fare in seguito, o potremo fare solo a un costo elevato? - Che cosa diventa irreversibile e qual è il costo per invertire tra 12 mesi? - A quale garanzia rinunciamo: coerenza, ordinamento, atomicità, possibilità di distribuire in modo indipendente, possibilità di ragionare sul sistema tutto in una volta? - Quale nuova classe di bug rende possibile, che è attualmente impossibile? - Che cosa impone a ogni funzionalità futura, indipendentemente dal fatto che che quella funzionalità ne abbia bisogno? Poi, in una frase per opzione: il problema che preferiremmo ho. Solo dopo tutto questo, dimmi che cosa abilita ciascuna opzione. Se un l'opzione non comporta rinunce significative, dillo e trattalo come sospetto piuttosto che come una raccomandazione.
In evidenza: Skill
Viktor - Skill di AI per architetti software
Viktor - Skill di AI per architetti software
$29 · un pagamento

Contiene ciò che fa la differenza qui: ciò che già esegui, ciò che non ti è consentito cambiare e le decisioni che hai già preso. Riscrivere ogni volta i tuoi vincoli reali in una chat vuota è il motivo per cui la maggior parte delle persone si arrende e accetta la risposta da greenfield, e una sessione nuova contraddirà volentieri l'architettura concordata il mese scorso.

Visualizza Viktor - Skill AI per architetti software →

Prompt 3 - analizza le frecce

Ignora i riquadri. Per ogni freccia di questo design, rispondi: 1. Sincrona o asincrona? Se sincrona, cosa sta facendo il che cosa fa il chiamante mentre aspetta e cosa vede l'utente? 2. Cosa succede quando fallisce? Riprova, fallisce, accoda, degrada? 3. Se ritenta: l'operazione è idempotente? Se non lo è, che cosa fa realmente un duplicato nel mondo reale - addebitare due volte, inviare due volte, conteggiare due volte? 4. Qual è il timeout e cosa succede quando scade? 5. L'ordine è importante qui? Se sì, che cosa lo garantisce? Se nulla lo garantisce, dillo. 6. Se questa freccia è inattiva per un'ora, che cosa continua a funzionare e che cosa no? Chi se ne accorge per primo: noi o il cliente? 7. Qual è il contratto dei dati e cosa succede quando una parte la cambia? Poi: quale freccia è quella che farà alzare qualcuno dal letto e quali frecce esistono solo perché abbiamo disegnato riquadri che non servivano separando? Nominali. Accorpare due riquadri è una risposta valida e voglio sentirlo se è pertinente. DESIGN: [PASTE OR DESCRIBE]

Prompt 4 - progettalo per un decimo della scala

L'ora più utile che trascorrerai. Separa la complessità indispensabile da quella aspirazionale, e la risposta è spesso scomoda.

Prendi il design di cui abbiamo appena discusso. Ora progetta lo stesso sistema per un decimo del carico che ti ho indicato, con lo stesso team. Poi rispondi: - Che cosa hai rimosso? - Tra le cose che hai rimosso, quali risolvevano un problema che ho oggi e quali invece risolvevano un problema che mi aspettarti di avere? - Per ogni elemento di complessità rimosso: a quale specifico, punto misurabile dovrei aggiungerla di nuovo? Dammi un numero, non "quando scaleremo". - Quanto costerebbe aggiungerla in seguito, rispetto a di averla costruita ora? Sii onesto su quando rimandare è davvero peggio. Infine: se costruissi ora la versione più piccola, di cosa mi pentirei tra tra due anni e di cosa sarei contento? Sostieni entrambe le posizioni correttamente, invece di rassicurarmi sulla scelta che sembra piacerti preferisco.

Prompt 5 - lo spazio dei guasti, che poi classificherai

Genera ogni possibile modo in cui questo sistema può guastarsi. Sii esaustivo piuttosto che selettivo - sarò io a stabilire le priorità, non è il tuo job e non hai i miei numeri. Copri almeno: - Ogni componente che si guasta da solo e l'effetto - Guasto parziale: lento anziché fuori servizio - Il datastore: non disponibile, lento, pieno, corrotto, ripristinato da un vecchio backup - Partizione di rete tra due parti qualsiasi - Una dipendenza cambia comportamento senza avvisarci - Carico dieci volte superiore al previsto, che arriva in un minuto - Carico che arriva in modo disomogeneo: un cliente, una chiave, un tenant - Disallineamento degli orologi, messaggi duplicati, messaggi fuori ordine - Un deploy completato solo a metà - Dati validi ma assurdi Per ciascuno: cosa si rompe, cosa vede l'utente, come lo scopriamo e se si autoripristina. Poi segnala i guasti silenziosi, quelli in cui il sistema continua a dando risposte, e le risposte sono sbagliate. Sono quelli che voglio in cima, e sono quelli che normalmente una revisione del progetto tralascia.

Prompt 6 - come ci arriviamo davvero

I progetti greenfield saltano questo passaggio, ed è qui che risiede il costo reale. Un'architettura target senza un percorso di migrazione è un desiderio.

Non stiamo costruendo tutto da zero. Ecco cosa esiste: [DESCRIBE]. Dammi il percorso da qui al progetto target, in passaggi che possono essere rilasciati indipendentemente, mantenendo il sistema attivo per tutto il tempo. Per ogni passaggio: - Cosa viene rilasciato e qual è lo stato del sistema dopo che - Possiamo fermarci qui definitivamente e stare comunque meglio di prima sono ora? Se la risposta è negativa per qualsiasi passaggio, quel passaggio è troppo grande - suddividilo. - Cosa viene eseguito in parallelo al percorso precedente e per quanto tempo - Come lo ripristiniamo dopo che è entrato in produzione, non prima - Quali dati devono essere migrati e se devono essere migrato due volte - Cosa peggiora durante questo passaggio e chi ne subisce le conseguenze Poi: il costo totale in settimane-uomo e il punto di non rendimento - il passaggio oltre il quale tornare indietro diventa impraticabile. Se la risposta onesta è che la migrazione costa più del vale il progetto target, dillo chiaramente.

Due cose che affermerà di non poter sapere

Dati sulle prestazioni. Se gli chiedi quante richieste al secondo gestirà un progetto o quale sarà la latenza, produrrà una cifra. Non ne ha idea. Questi valori dipendono dal tuo hardware, dalla forma dei dati, dai pattern delle query e dalla distribuzione degli accessi, e l'unico modo per ottenerli è misurare. Considera qualsiasi dato di throughput, latenza o capacità che offre come un segnaposto e inserisci un test di carico al posto del numero.

Versioni, limiti e prezzi attuali. Quote dei servizi, limiti dei database gestiti, dimensioni delle istanze, quanto addebita un provider cloud, quale versione è stata resa obsoleta da cosa. Tutto cambia, e il modello risponde in base a ciò che ha visto l'ultima volta. Recupera ognuno di questi dati dalla documentazione aggiornata del provider il giorno in cui decidi, perché un'architettura basata su una quota obsoleta è un progetto destinato a fallire dopo un anno, nel momento peggiore possibile.

Dove si verifica l'errore

Errore Cosa succede Cosa farne
Greenfield per impostazione predefinita Un progetto che presuppone un campo vuoto, nessun sistema legacy e nulla che ti sia vietato toccare Descrivi ciò che viene eseguito oggi, comprese le parti imbarazzanti, prima di chiedere qualsiasi cosa
Progettato per il picco L'architettura di un'azienda che ha affrontato il problema interessante e ne ha scritto Chiedi lo stesso sistema con un decimo del carico, poi fai un confronto
Funzionalità, mai opzioni precluse Ciò che il design abilita, mentre ciò a cui hai rinunciato resta non detto Pretendi prima l'elenco delle opzioni precluse e considera sospetta un'opzione che non ne ha nessuna
Diagrammi bellissimi Riquadri e frecce in cui ogni domanda difficile si nasconde in una freccia e nessuna trova risposta Esamina ogni freccia. Unire due riquadri è un esito valido
Prestazioni inventate Un valore di richieste al secondo o di latenza senza nulla a supportarlo Tratta ogni numero come un segnaposto per un test di carico
Informazioni obsolete sulla piattaforma Quote, limiti, tipi di istanza e prezzi risalenti all'ultima volta in cui li ha visti La documentazione del provider, aggiornata al giorno in cui serve, per ognuno
Nessun percorso di migrazione Un design obiettivo che non tiene conto di come arrivarci mentre il sistema è in funzione Pretendi passaggi distribuibili autonomamente, ognuno dei quali possa essere interrotto
Stabilisce le priorità quando glielo chiedi Alla domanda su quale fallimento conti di più, risponde senza nessuno dei tuoi numeri Lascia che generi lo spazio. L'ordinamento spetta a te

Come si installa la Skill di Viktor?

Il download è uno ZIP con SKILL.md nella radice dell'archivio, non all'interno di una cartella annidata: quella struttura delle cartelle è il motivo più comune per cui un caricamento non va a buon fine. Nell'app desktop di Claude, apri Personalizza → Skills, carica lo ZIP e attivalo.

Le Skills richiedono l'esecuzione del codice abilitata, in Impostazioni → Funzionalità. Il centro assistenza di Anthropic attualmente elenca le Skills nei piani Free, Pro, Max, Team ed Enterprise, mentre il tutorial della sua Academy elenca Pro, Max, Team ed Enterprise: quindi, se hai il piano gratuito, controlla Impostazioni → Funzionalità per il tuo account invece di fidarti di una delle due pagine. La guida completa è nella guida all'installazione della Skill.

In ChatGPT o Gemini non è necessario alcun passaggio di caricamento: apri SKILL.md, copia il contenuto e incollalo nelle istruzioni personalizzate. Perdi l'attivazione automatica, ma conservi il metodo.

A chi è rivolto?

Architetti e ingegneri staff che vogliono un interlocutore capace di ragionare e contraddirli, tech lead che prendono decisioni progettuali al di sopra del proprio livello, e founder che decidono come costruire qualcosa prima di impegnarsi. Funziona in Claude, ChatGPT o in qualsiasi chat AI.

I ruoli di ingegneria sono suddivisi in Skills separate, ciascuna a $29 e con download una tantum:

L'insieme più ampio comprende gli Skill per sviluppatori software e gli Skill per software e IT.

In sintesi:

Un'architettura è un elenco di cose che hai scelto di non poter fare, e un modello descriverà sempre e solo capacità, perché il corpus è scritto da persone il cui problema interessante meritava di essere pubblicato. Digli cosa è già in esecuzione, cosa non puoi cambiare e chi lo sta costruendo, prima che proponga qualsiasi cosa. Chiedi prima ciò che viene precluso rispetto a ciò che viene abilitato e considera un'opzione senza svantaggi come un avvertimento anziché una raccomandazione. Ignora i riquadri e analizza ogni freccia, perché è lì che risiedono errori, ordinamento, idempotenza e raggio d'impatto - e sii disposto a riunire due riquadri in uno. Progetta lo stesso sistema per un decimo del carico per scoprire quale complessità è essenziale. Lascia che generi l'intero spazio dei guasti e fai tu la classificazione. E fagli mostrare il percorso di migrazione, in tappe che potresti interrompere, perché un design obiettivo senza un percorso per raggiungerlo è solo un desiderio. Per i tuoi vincoli reali e le decisioni passate mantenute tra le sessioni, Viktor - Skill di AI per architetti software. Funziona in Claude, ChatGPT e qualsiasi chat di AI, con una garanzia di rimborso entro 30 giorni.

Skill · .md · Funziona con Claude e ChatGPT

Viktor - Skill di AI per architetti software

Chiede cosa è già in esecuzione prima di proporre qualsiasi cosa, parte da ciò che un design preclude anziché da ciò che abilita, analizza le frecce invece di disegnare riquadri e mostra il percorso di migrazione in tappe che potresti interrompere. Nessun abbonamento. È tuo per sempre.

$19
Ottieni lo Skill di Viktor →

KissMySkills è un marketplace con oltre 1.800 Skill di AI, oltre 80 pacchetti di prompt, oltre 75 agenti e strumenti gratuiti per Claude, ChatGPT e qualsiasi chat di AI.

Guide agli Skill correlati

Mettilo in pratica

Oppure tutte le skill con Unlimited Vedi i piani →

Domande frequenti

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 che funzionano. Niente fronzoli.

Esplora ogni skill, prompt pack e agent nello store.

Sfoglia tutte le competenze →Oppure prova gli strumenti gratuiti