Como usar o Claude como arquiteto de software: guia de skill

Atualizado em 13 min de leitura KissMySkills
Nesta página
  1. Duas falhas, uma causa
  2. As caixas são a parte fácil
  3. No que ele é genuinamente bom
  4. Onde falha
  5. Como você instala o Skill do Viktor?
  6. Para quem é isso?
  7. Guias de Skills relacionados
Skill · .md

O Skill por trás deste guia: Viktor - Skill de AI para arquitetura de software. Mantém o que você já executa, o que não pode mudar e as decisões que já tomou, para que as opções cheguem filtradas pelo seu sistema real em vez de um campo vazio - $19, um pagamento, seu para sempre.

Veja o Skill Viktor →

Uma arquitetura é uma lista de coisas que você decidiu que não poderá fazer. Um modelo só dirá o que um design pode fazer. Ele não está sendo desonesto: o material com o qual aprendeu foi escrito por pessoas descrevendo sistemas que funcionavam, em uma escala que fazia valer a pena escrever sobre eles, e ninguém publica um texto sobre o monólito entediante que ainda está bom. Portanto, o que volta é sempre greenfield e sempre maximalista - o sistema no pico que você imaginou, em um campo vazio, com as execuções hipotecárias deixadas de fora.

Duas falhas, uma causa

Quase toda resposta de arquitetura inútil remonta à mesma coisa: o corpus é escrito sobre o problema interessante, por pessoas que o enfrentaram.

Ele é projetado em um campo vazio. A arquitetura real quase nunca começa do zero. Ela é uma mudança em um sistema que existe, feito por pessoas que existem, conectado a coisas que você não tem permissão para tocar. Peça o design e você receberá um que presume que nada disso existe, e os erros mais caros nessa disciplina não são escolher o banco de dados errado - são projetar como se uma restrição não existisse.

Ele é projetado para o pico. Orientado a eventos, um serviço por domínio, uma fila entre cada par de componentes, Kubernetes por baixo. Essas coisas não estão erradas. São os relatos de organizações que precisaram delas, e não existem relatos das empresas que se saíram bem sem elas. Portanto, a média da literatura é uma arquitetura para uma empresa maior que a sua.

Ambos podem ser corrigidos, e nenhum dos dois é corrigido fazendo perguntas melhores sobre o design. Você os corrige mudando o que o modelo pode presumir.

As caixas são a parte fácil

Peça uma arquitetura e você receberá caixas e setas. As caixas são quase gratuitas: um serviço que faz uma coisa clara é um problema resolvido, e todos conseguem visualizá-lo.

Toda a dificuldade está nas setas. Uma seta entre duas caixas afirma que essas duas coisas podem se comunicar, e o diagrama nunca justifica essa afirmação. A chamada é síncrona e, se for, o que o chamador faz durante os duzentos milissegundos em que espera? O que acontece quando ela falha - há uma nova tentativa e, se houver, a operação é idempotente ou uma nova tentativa cobra o cartão duas vezes? Qual é o tempo limite e o que acontece depois dele? A ordem importa e há algo que a garanta? Se essa seta ficar indisponível por uma hora, o que continua funcionando e o que não funciona?

Um diagrama não responde a nada disso, e um modelo vai gerar um bonito mesmo assim, porque diagramas são um gênero e ele leu milhares deles. Questione as setas, e o design geralmente muda. Com frequência, ele se reduz a menos caixas, que é o resultado correto.

No que ele é genuinamente bom

Gerar o espaço de falhas. "Quais são todas as formas de isso dar errado" é um problema de abrangência em um enorme conjunto de post-mortems, relatos de incidentes e discussões com lições conquistadas a duras penas, e é exatamente para isso que essas ferramentas servem. Ela revelará o modo de falha que você teria descoberto em produção daqui a oito meses.

O que ele não consegue fazer é classificá-las, porque a classificação depende do seu tráfego, da sua equipe, da sua tolerância e do seu dinheiro. Portanto, a divisão do trabalho é clara: ele gera a lista, você a ordena. Quem disser que ele pode fazer a ordenação está vendendo alguma coisa.

Prompt 1 - o campo não está vazio

Nada mais nesta página funciona até que o modelo saiba o que já existe. Responda com honestidade, incluindo as partes constrangedoras.

Ainda não proponha uma arquitetura. Vou descrever o que já existe. Leia e depois diga-me o que você ainda precisa saber antes de projetar qualquer coisa. O QUE É EXECUTADO HOJE: - Linguagens, frameworks, armazenamentos de dados, hospedagem, efetivamente em em produção neste momento - O que é implantado, com que frequência e como é implantado - Quais são os modos atuais de falha. O que de fato nos aciona. O QUE NÃO POSSO MUDAR: - Sistemas que não são de minha propriedade, integrações que não posso interromper, contratos que ditem o comportamento - Restrições de conformidade ou residência de dados - Qualquer compromisso que a empresa tenha assumido externamente QUEM ESTÁ CONSTRUINDO ISSO: - Quantos engenheiros, qual o nível de senioridade e o que eles já executaram em produção antes - O que nenhum deles jamais operou em - Se há alguém de plantão e se esse trabalho é remunerado OS NÚMEROS REAIS: - Carga atual, não projetada. Usuários, requisições, volume de dados. - O crescimento que tivemos de fato no último ano, não o plano Então, antes de propor qualquer coisa: diga-me quais destas qual dessas restrições mais limita o espaço de design e diga claramente qual das minhas respostas parece aspiracional em vez de mensurada.

Prompt 2 - a lista de inviabilidades

possibilita. A parte que um modelo nunca oferece espontaneamente, e a parte que é realmente decisiva.

Para cada opção que você estiver propondo, não comece pelo que ela possibilita. Comece pelo que ela inviabiliza. Para cada opção: a um custo alto? - O que não poderemos fazer depois, ou só poderemos fazer - O que se torna irreversível e qual é o custo para reverter isso em 12 meses? - De que garantia estamos abrindo mão - consistência, ordenação, atomicidade, capacidade de implantar de forma independente, capacidade de raciocinar sobre o sistema de uma só vez? - Que nova classe de bug isso torna possível, que é ser atualmente impossível? - O que isso impõe a todo recurso futuro, independentemente de que esse recurso precisa disso? Então, em uma frase por opção: o problema que preferiríamos tenha. Somente depois de tudo isso, diga-me o que cada opção possibilita. Se uma a opção não tem riscos significativos de encerramento, diga isso e trate isso como suspeita, e não como uma recomendação.
Destaque de Skill
Viktor - Skill de AI para arquiteto de software
Viktor - Skill de AI para arquiteto de software
$19 · um pagamento

Contém o que faz a diferença aqui: o que você já executa, o que não tem permissão para alterar e as decisões que já tomou. Redigitar suas restrições reais em um chat vazio toda vez é o motivo pelo qual a maioria das pessoas desiste e aceita a resposta de greenfield, e uma nova sessão terá prazer em contradizer a arquitetura com a qual você concordou no mês passado.

Visualizar Viktor - Skill de AI para arquiteto de software →

Prompt 3 - interrogue as setas

Ignore as caixas. Para cada seta neste design, responda: 1. Síncrono ou assíncrono? Se for síncrono, qual é o o que o chamador faz enquanto espera e o que o usuário vê? 2. O que acontece quando falha? Tentar novamente, falhar, enfileirar, degradar? 3. Se tentar novamente: a operação é idempotente? Se não for, o que uma duplicata realmente faz no mundo real - cobrar duas vezes, enviar duas vezes, contar duas vezes? 4. Qual é o tempo limite e o que acontece depois que ele expira? 5. A ordenação importa aqui? Se importar, o que a garante? Se nada garantir isso, diga. 6. Se esta seta ficar indisponível por uma hora, o que ainda funcionará e o que não acontece? Quem percebe primeiro: nós ou o cliente? 7. Qual é o contrato de dados e o que acontece quando um lado a mudará? Então: qual seta é a que fará alguém se levantar e quais setas existem apenas porque desenhamos caixas que não precisavam ser separando? Dê nome a elas. Colapsar duas caixas é uma resposta válida e quero ouvir isso se for aplicável. DESIGN: [PASTE OR DESCRIBE]

Prompt 4 - projete-o para um décimo da escala

A hora mais útil que você passará. Ela separa a complexidade estrutural da complexidade aspiracional, e a resposta costuma ser desconfortável.

Pegue o design que acabamos de discutir. Agora projete o mesmo sistema para um décimo da carga que informei, com a mesma equipe. Então responda: - O que você removeu? - Das coisas que você removeu, quais estavam resolvendo um problema que eu realmente tenho hoje e quais estavam resolvendo um problema que eu espera ter? - Para cada parte da complexidade removida: em que ponto específico, ponto mensurável eu precisaria adicioná-lo novamente? Dê-me um número, não "quando escalarmos". - Qual é o custo de adicionar isso novamente mais tarde, em comparação com construí-la agora? Seja honesto quando deixar para depois for realmente pior. Por fim: se eu construísse a versão menor, do que me arrependeria daqui a dois anos e com o que eu ficaria satisfeito? Argumente pelos dois lados corretamente em vez de me tranquilizar sobre a escolha que pareço prefira.

Prompt 5 - o espaço de falhas, que você classificará em seguida

Gere todas as formas como este sistema pode falhar. Seja exaustivo em vez de seletivo em vez de seletivo - eu farei a priorização, isso não é seu trabalho e você não tem meus números. Cubra no mínimo: - Cada componente falhando sozinho e o efeito disso - Falha parcial: lento em vez de indisponível - O armazenamento de dados: indisponível, lento, cheio, corrompido, restaurado de um backup antigo - Partição de rede entre quaisquer duas partes - Uma dependência mudando o comportamento sem nos avisar - Carga dez vezes maior do que o esperado, chegando em um minuto - Carga chegando de forma desigual: um cliente, uma chave, um locatário - Desvio de relógio, mensagens duplicadas e mensagens fora de ordem - Uma implantação parcialmente distribuída - Dados válidos, mas absurdos Para cada uma: o que quebra, o que o usuário vê, como descobrimos e se ele se recupera sozinho. Depois sinalize as falhas silenciosas - aquelas em que o sistema continua respondendo, e as respostas estão erradas. São essas que eu quero no topo, e são justamente as que uma revisão de design normalmente falha.

Prompto 6 - como chegamos lá de fato

Designs greenfield ignoram isso, e é aí que mora o custo real. Uma arquitetura-alvo sem um caminho de migração é um desejo.

Não estamos construindo isso do zero. Isto é o que existe: [DESCRIBE]. Dê-me o caminho daqui até o design-alvo, em passos que cada um pode ser entregue de forma independente, mantendo o sistema ativo durante todo o processo. Para cada passo: - O que é entregue e qual é o estado do sistema depois que ele - Podemos parar aqui permanentemente e ainda assim ficar em situação melhor do que estão agora? Se a resposta for não para qualquer passo, esse passo é grande demais. grande - divida-o. - O que roda em paralelo com o caminho antigo e por quanto tempo - Como fazemos o rollback depois que estiver em produção, não antes - Quais dados precisam ser migrados e isso precisa ser migrado duas vezes - O que piora durante este passo e quem sente isso Então: o custo total em semanas de engenharia e o ponto de não retorno - o passo após o qual reverter se torna impraticável. Se a resposta honesta for que a migração custa mais do que o diga claramente quanto o design-alvo vale, por exemplo.

Duas coisas que ele afirmará sem poder saber

Números de desempenho. Quando perguntado sobre quantas solicitações por segundo um design suportará ou qual será a latência, ele produzirá um número. Ele não faz ideia. Esses números dependem do seu hardware, do formato dos seus dados, dos seus padrões de consulta e da distribuição dos acessos, e a única forma de obtê-los é medir. Trate qualquer número de throughput, latência ou capacidade que ele oferecer como um valor provisório e faça um teste de carga ocupar o lugar desse número.

Versões atuais, limites e preços. Cotas de serviço, limites de bancos de dados gerenciados, tamanhos de instância, quanto um provedor de nuvem cobra e qual versão tornou outra obsoleta. Tudo isso muda, e o modelo responde com base no que viu por último. Obtenha cada um desses dados na documentação atual do próprio provedor no dia em que decidir, porque uma arquitetura construída sobre uma cota desatualizada é um design que falha depois de um ano, no pior momento possível.

Onde falha

Falha O que acontece O que fazer a respeito
Greenfield por padrão Um design que presume um campo vazio, nenhum legado e nada que você esteja proibido de tocar Descreva o que roda hoje, incluindo as partes constrangedoras, antes de pedir qualquer coisa
Projetado para o pico A arquitetura de uma empresa que teve o problema interessante e escreveu sobre ele Peça o mesmo sistema com um décimo da carga e depois compare
Capacidades, nunca impedimentos O que o design permite, sem dizer o que você abriu mão Exija primeiro a lista de impedimentos e considere suspeita uma opção que não tenha nenhum
Diagramas bonitos Caixas e setas onde toda pergunta difícil está em uma seta e nenhuma é respondida Interrogue cada seta. Colapsar duas caixas é um resultado válido
Desempenho inventado Um número de requisições por segundo ou de latência sem nada que o sustente Trate cada número como um espaço reservado para um teste de carga
Fatos desatualizados sobre a plataforma Cotas, limites, tipos de instância e preços de quando quer que tenha sido a última vez que os viu Documentação do provedor, no dia, para cada uma delas
Nenhum caminho de migração Um design-alvo sem considerar como chegar lá enquanto o sistema está em produção Exija etapas que possam ser entregues de forma independente, cada uma das quais você poderia interromper
Ele classifica quando solicitado Quando perguntado qual falha é mais importante, ele responde, sem nenhum dos seus números Deixe-o gerar o espaço. Você faz a ordenação

Como você instala o Skill do Viktor?

O download é um ZIP com SKILL.md na raiz do arquivo, não dentro de uma pasta aninhada - essa estrutura de pastas é o motivo mais comum para um upload falhar. No aplicativo do Claude para desktop, abra Personalizar → Skills, faça upload do ZIP e ative-o.

Os Skills precisam da execução de código ativada, em Configurações → Recursos. O centro de ajuda da Anthropic atualmente lista Skills nos planos Free, Pro, Max, Team e Enterprise, enquanto o tutorial da Academy lista Pro, Max, Team e Enterprise - portanto, se você estiver no plano gratuito, verifique Configurações → Recursos na sua própria conta em vez de confiar no que qualquer uma das páginas informa. O passo a passo completo está no guia de instalação de Skills.

No ChatGPT ou Gemini, não há etapa de upload: abra SKILL.md, copie o conteúdo e cole-o nas instruções personalizadas. Você perde o acionamento automático, mas mantém o método.

Para quem é isso?

Arquitetos e engenheiros seniores que querem um parceiro de raciocínio que argumente, líderes técnicos tomando decisões de design acima do seu nível salarial e fundadores decidindo como construir antes de se comprometerem com isso. Funciona no Claude, ChatGPT ou em qualquer chat de AI.

As funções de engenharia são divididas em seus próprios Skills, cada uma por US$ 19 e com download único:

O conjunto mais amplo é o de Skills para desenvolvedores de software e o de Skills de software e TI.

Em resumo:

Uma arquitetura é uma lista de coisas que você escolheu não poder fazer, e um modelo só descreverá capacidades, porque o corpus foi escrito por pessoas cujo problema interessante valia a pena publicar. Diga o que já está em execução, o que você não pode alterar e quem está desenvolvendo, antes que ele proponha qualquer coisa. Peça primeiro o que será impedido, antes do que será possibilitado, e trate uma opção sem desvantagens como um alerta, não como uma recomendação. Ignore as caixas e questione cada seta, porque é aí que vivem as falhas, a ordenação, a idempotência e o raio de impacto - e esteja disposto a juntar duas caixas novamente em uma só. Projete o mesmo sistema para um décimo da carga para descobrir qual complexidade é essencial. Faça com que ele gere todo o espaço de falhas e faça a classificação por conta própria. E faça com que ele mostre o caminho de migração, em etapas nas quais você possa parar, porque um design-alvo sem uma rota até ele é apenas um desejo. Para suas restrições reais e decisões passadas mantidas entre sessões, Viktor - Skill de AI para arquiteto de software (US$ 19). Funciona no Claude, no ChatGPT e em qualquer chat de AI, com garantia de reembolso em 30 dias.

Skill · .md · Funciona com Claude e ChatGPT

Viktor - Skill de AI para arquiteto de software

Pergunta o que já está em execução antes de propor qualquer coisa, começa pelo que um design impede, e não pelo que ele possibilita, questiona as setas em vez de desenhar caixas e mostra o caminho de migração em etapas nas quais você pode parar. Sem assinatura. Seu permanentemente.

$19
Conheça o Skill Viktor →

KissMySkills é um marketplace com mais de 2.000 Skills de AI, mais de 80 pacotes de prompt, mais de 75 agentes e ferramentas gratuitas para Claude, ChatGPT e qualquer chat de AI.

Guias de Skills relacionados

Perguntas frequentes

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 que funcionam. Sem enrolação.

Navegue por todas as skills, prompts e agents na loja.

Navegue por todas as habilidades →Ou experimente as ferramentas gratuitas