Cómo usar Claude como arquitecto de software: la guía de Skill de Viktor

Updated
Skill · .md

El Skill detrás de esta guía: Viktor - Skill de AI para arquitectura de software. Contiene lo que ya ejecutas, lo que no puedes cambiar y las decisiones que ya has tomado, para que las opciones lleguen filtradas por tu sistema real en lugar de un terreno vacío - $29, un solo pago, tuyo para siempre.

Ver el Skill de Viktor →

Una arquitectura es una lista de cosas que has decidido que no podrás hacer. Un modelo solo te dirá lo que un diseño puede hacer. No está siendo deshonesto: el material del que aprendió fue escrito por personas que describían sistemas que funcionaban, a una escala que hacía que valiera la pena escribir sobre ellos, y nadie publica un artículo sobre el aburrido monolito que sigue funcionando bien. Así que lo que devuelve siempre parte de cero y siempre es maximalista - el sistema en el pico que imaginaste, sobre un terreno vacío, con las ejecuciones hipotecarias omitidas.

Dos fallos, una causa

Casi todas las respuestas de arquitectura poco útiles se remontan a lo mismo: el corpus está escrito sobre el problema interesante, por personas que lo tuvieron.

Diseña sobre un terreno vacío. La arquitectura real casi nunca parte de cero. Es un cambio en un sistema que ya existe, llevado a cabo por personas que existen y conectado a cosas que no tienes permitido tocar. Pides el diseño y obtienes uno que da por supuesto que nada de eso existe, y los errores más costosos de esta disciplina no consisten en elegir la base de datos equivocada - consisten en diseñar como si no existiera una restricción.

Diseña para el pico. Orientación basada en eventos, un servicio por dominio, una cola entre cada par de componentes, Kubernetes por debajo. No están mal. Son los informes de organizaciones que los necesitaban, y no existen informes de las empresas a las que les fue bien sin ellos. Así que el promedio de la literatura describe una arquitectura para una empresa más grande que la tuya.

Ambos problemas se pueden corregir, y ninguno se corrige haciendo mejores preguntas sobre el diseño. Se corrigen cambiando lo que el modelo puede dar por supuesto.

Las cajas son la parte fácil

Pides una arquitectura y obtienes cajas y flechas. Las cajas son casi gratuitas: un servicio que hace una sola cosa con claridad es un problema resuelto y todo el mundo puede imaginarlo.

Toda la dificultad está en las flechas. Una flecha entre dos cajas afirma que esas dos cosas pueden comunicarse, y el diagrama nunca justifica esa afirmación. ¿La llamada es síncrona y, si lo es, qué hace quien llama durante los doscientos milisegundos que espera? ¿Qué ocurre cuando falla: se reintenta y, en ese caso, la operación es idempotente, o un reintento cobra dos veces la tarjeta? ¿Cuál es el tiempo de espera y qué ocurre después? ¿Importa el orden y hay algo que lo garantice? Si esta flecha deja de funcionar durante una hora, ¿qué sigue funcionando y qué no?

Un diagrama no responde a nada de eso, y aun así un modelo generará uno precioso, porque los diagramas son un género y ha leído miles. Interroga las flechas y el diseño normalmente cambia. A menudo se reduce a menos bloques, que es el resultado correcto.

En lo que realmente es bueno

Generar el espacio de fallos. «¿De qué formas puede salir mal?» es un problema de cobertura basado en un enorme corpus de informes posteriores, análisis de incidentes y comentarios obtenidos con mucho esfuerzo, y para eso sirven exactamente estas herramientas. Sacará a la luz el modo de fallo que habrías descubierto en producción dentro de ocho meses.

Lo que no puede hacer es ordenarlos, porque para establecer un orden necesita conocer tu tráfico, tu equipo, tu tolerancia y tu presupuesto. Así que la división del trabajo es clara: genera la lista y tú la ordenas. Quien te diga que puede establecer el orden está vendiendo humo.

Prompt 1 - el campo no está vacío

Nada más en esta página funciona hasta que el modelo sepa qué existe ya. Responde con honestidad, incluidas las partes embarazosas.

No propongas todavía una arquitectura. Voy a describir lo que ya existe. Léelo y luego dime dime qué más necesitas saber antes de diseñar nada. LO QUE SE EJECUTA HOY: - Lenguajes, frameworks, almacenes de datos, alojamiento, lo que realmente está en en producción ahora mismo - Qué se despliega, con qué frecuencia y cómo se despliega - Cuáles son los modos de fallo actuales. Qué es lo que realmente nos alerta. LO QUE NO PUEDO CAMBIAR: - Sistemas que no poseo, integraciones que no puedo romper, contratos que determinen el comportamiento - Restricciones de cumplimiento normativo o residencia de datos - Cualquier compromiso que la empresa haya asumido externamente QUIÉN LO ESTÁ CONSTRUYENDO: - Cuántos ingenieros hay, su nivel de experiencia y qué han ejecutado en producción - Qué es lo que ninguno de ellos ha operado jamás en - Si hay alguien de guardia y si recibe una remuneración LAS CIFRAS REALES: - Carga actual, no proyectada. Usuarios, solicitudes, volumen de datos. - El crecimiento real que hemos visto en el último año, no el plan Luego, antes de proponer nada: dime cuál de estas restricción limita más el espacio de diseño, y di claramente cuál de mis respuestas suena aspiracional en lugar de medido.

Prompt 2 - la lista de renuncias

La parte que un modelo nunca ofrece voluntariamente y que, en realidad, constituye la decisión.

Para cada opción que propongas, no empieces por lo que permite. Empieza por lo que impide. Para cada opción: - ¿Qué ya no podremos hacer después, o solo podremos hacer ¿con un coste considerable? - ¿Qué se vuelve irreversible y cuál es el coste de revertirlo ¿en 12 meses? - ¿A qué garantía estamos renunciando - coherencia, orden, atomicidad, capacidad de desplegar de forma independiente, capacidad de razonar sobre el sistema de una sola vez? imposible? - ¿Qué nueva clase de error hace posible que actualmente es - ¿Qué impone esto a cada funcionalidad futura, lo necesite o no? ¿esa funcionalidad lo necesita? Luego, en una frase por opción: el problema que preferiríamos tengo. Solo después de todo eso, dime qué permite cada opción. Si una la opción no tiene renuncias significativas; dilo y trátalo como sospechoso en lugar de como una recomendación.
Destacado de Skill
Viktor - Skill de AI para arquitectos de software
Viktor - Skill de AI para arquitectos de software
29 $ · un pago

Contiene lo que marca la diferencia aquí: lo que ya ejecutas, lo que no tienes permitido cambiar y las decisiones que ya has tomado. Reescribir tus restricciones reales en un chat vacío cada vez es la razón por la que la mayoría de la gente se rinde y acepta la respuesta de greenfield, y una sesión nueva estará encantada de contradecir la arquitectura que acordaste el mes pasado.

Ver Viktor - Skill de AI para arquitectos de software →

Prompt 3 - interrogar las flechas

Ignora las cajas. Para cada flecha de este diseño, responde: 1. ¿Síncrono o asíncrono? Si es síncrono, ¿qué está ¿qué hace quien llama mientras espera y qué ve el usuario? 2. ¿Qué ocurre cuando falla? ¿Reintentar, fallar, poner en cola, degradar? 3. Si reintenta: ¿la operación es idempotente? Si no lo es, ¿qué hace realmente un duplicado? ¿cobrar dos veces, enviar dos veces, contabilizar dos veces? 4. ¿Cuál es el tiempo de espera y qué ocurre cuando vence? 5. ¿Importa el orden? Si importa, ¿qué lo garantiza? Si nada lo garantiza, dilo. 6. Si esta flecha está caída durante una hora, ¿qué sigue funcionando y ¿qué no? ¿Quién se da cuenta primero: nosotros o el cliente? 7. ¿Cuál es el contrato de datos y qué ocurre cuando un lado ¿lo cambia? Después: ¿cuál es la flecha que hará que alguien se despierte y ¿qué flechas existen solo porque dibujamos cajas que no hacía falta ¿separando? Nómbralos. Colapsar dos cajas es una respuesta válida y quiero oírlo si aplica. DISEÑO: [PASTE OR DESCRIBE]

Prompt 4 - diseñarlo para una décima parte de la escala

La hora más útil que pasarás. Distingue la complejidad que soporta la carga de la complejidad aspiracional, y la respuesta suele ser incómoda.

Toma el diseño que acabamos de analizar. Ahora diseña el mismo sistema para una décima parte de la carga que te indiqué, con el mismo equipo. Luego responde: - ¿Qué eliminaste? - De las cosas que eliminaste, ¿cuáles estaban resolviendo un problema que tengo hoy y cuáles estaban resolviendo un problema que esperas tener? - Para cada pieza de complejidad eliminada: ¿en qué momento específico, ¿en qué punto medible tendría que volver a añadirlo? Dame un número, no «cuando escalemos». - ¿Qué coste tendría volver a añadirlo más adelante, en comparación con construirla ahora? Sé honesto cuando hacerlo más adelante sea realmente peor. Por último: si construyera ahora la versión más pequeña, ¿de qué me arrepentiría dentro de dos años, ¿y de qué me alegraría? Defiende ambos lados correctamente en lugar de tranquilizarme sobre la opción que parece que prefiero.

Prompt 5 - el espacio de fallos, que luego clasificas

Genera todas las formas en que este sistema puede fallar. Sé exhaustivo en lugar de selectivo que selectivo: yo haré la priorización, eso no es tu el trabajo y no tienes mis cifras. Cubre como mínimo: - Cada componente fallando por separado y el efecto - Fallo parcial: lento en lugar de caído - El almacén de datos: no disponible, lento, lleno, dañado, restaurado de una copia de seguridad antigua - Partición de red entre dos partes cualesquiera - Una dependencia que cambia su comportamiento sin avisarnos - Una carga diez veces mayor de la esperada que llega en un minuto - Carga que llega de forma desigual: un cliente, una clave o un inquilino - Desfase de relojes, mensajes duplicados y mensajes desordenados - Un despliegue implementado a medias - Datos válidos pero absurdos Para cada uno: qué se rompe, qué ve el usuario, cómo nos enteramos y si se recupera automáticamente. Después señala los fallos silenciosos, aquellos en los que el sistema sigue responden en una revisión de diseño, y las respuestas son incorrectas. Esas son las que quiero al principio, y son las que normalmente omite.

Prompt 6 - cómo llegamos realmente

Los diseños greenfield omiten esto, y aquí es donde reside el coste real. Una arquitectura objetivo sin una ruta de migración es un deseo.

No estamos construyendo esto desde cero. Esto es lo que existe: [DESCRIBE]. Dame el camino desde aquí hasta el diseño objetivo, en pasos que pueden publicarse de forma independiente, con el sistema activo en todo momento. Para cada paso: - Qué se publica y cuál es el estado del sistema después de que - ¿Podemos detenernos aquí permanentemente y aun así estar en mejor situación que ¿están ahora? Si la respuesta es no para algún paso, ese paso es demasiado grande: divídelo. - Qué funciona en paralelo con la ruta antigua y durante cuánto tiempo - Cómo lo revertimos después de que esté en producción, no antes - Qué datos deben migrarse y si es necesario migrado dos veces - Qué empeora durante este paso y quién lo nota Después: el coste total en semanas de ingeniería y el punto de no rendimiento: el punto a partir del cual revertirlo se vuelve poco práctico. Si la respuesta honesta es que la migración cuesta más que el el valor del diseño objetivo, dilo claramente.

Dos cosas que afirmará sin poder saberlas

Cifras de rendimiento. Si le preguntas cuántas solicitudes por segundo soportará un diseño o cuál será la latencia, dará una cifra. No tiene ni idea. Esas cifras dependen de tu hardware, la forma de tus datos, tus patrones de consulta y la distribución del acceso, y la única manera de obtenerlas es medir. Trata cualquier cifra de rendimiento, latencia o capacidad que ofrezca como un marcador de posición y coloca una prueba de carga donde debería estar la cifra.

Versiones actuales, límites y precios. Cuotas de servicios, límites de bases de datos gestionadas, tamaños de instancia, cuánto cobra un proveedor de la nube y qué versión dejó obsoleta a cuál. Todo cambia, y el modelo responde basándose en lo último que vio. Obtén todos estos datos de la documentación oficial y actualizada del proveedor el día que decidas, porque una arquitectura basada en una cuota obsoleta es un diseño que falla al cabo de un año, en el peor momento posible.

Dónde falla

Fallo Qué sucede Qué hacer al respecto
Greenfield de forma predeterminada Un diseño que supone un campo vacío, sin legado y sin nada que tengas prohibido tocar Describe lo que funciona hoy, incluidas las partes vergonzosas, antes de pedir nada
Diseñado para el pico La arquitectura de una empresa que tuvo el problema interesante y escribió sobre él Pide el mismo sistema con una décima parte de la carga y luego compara
Capacidades, nunca exclusiones Lo que permite el diseño, sin decir qué has sacrificado Exige primero la lista de exclusiones y considera sospechosa una opción que no tenga ninguna
Diagramas bonitos Cajas y flechas donde cada pregunta difícil reside en una flecha y ninguna tiene respuesta Interroga cada flecha. Fusionar dos cajas es un resultado válido
Rendimiento inventado Una cifra de solicitudes por segundo o de latencia sin nada que la respalde Trata cada número como un marcador de posición para una prueba de carga
Datos obsoletos de la plataforma Cuotas, límites, tipos de instancia y precios de la última vez que los vio La documentación del proveedor del día para cada uno
Sin ruta de migración Un diseño objetivo sin tener en cuenta cómo llegar a él mientras el sistema está activo Exige pasos que puedan enviarse de forma independiente y detenerse en cualquiera de ellos
Clasifica cuando se le pregunta Cuando se le pregunta qué fallo importa más, responde sin ninguno de tus números Deja que genere el espacio. Tú haces la ordenación

¿Cómo se instala la Skill de Viktor?

La descarga es un ZIP con SKILL.md en la raíz del archivo, no dentro de una carpeta anidada; esa estructura de carpetas es la razón habitual por la que falla la carga. En la aplicación de escritorio de Claude, abre Personalizar → Skills, carga el ZIP y actívalo.

Las Skills necesitan tener habilitada la ejecución de código, en Configuración → Capacidades. El centro de ayuda de Anthropic actualmente incluye las Skills en los planes Free, Pro, Max, Team y Enterprise, mientras que su tutorial de Academy incluye Pro, Max, Team y Enterprise; por eso, si tienes el plan gratuito, consulta Configuración → Capacidades en tu propia cuenta en lugar de fiarte de cualquiera de las dos páginas. La guía completa está en la guía de instalación de Skills.

En ChatGPT o Gemini no hay ningún paso de carga: abre SKILL.md, copia el contenido y pégalo en las instrucciones personalizadas. Pierdes la activación automática, pero conservas el método.

¿Para quién es esto?

Arquitectos e ingenieros de plantilla que quieren un compañero de reflexión que discuta sus ideas, líderes técnicos que toman decisiones de diseño por encima de su nivel salarial y fundadores que deciden cómo construir algo antes de comprometerse con ello. Funciona en Claude, ChatGPT o cualquier chat de AI.

Los roles de ingeniería están divididos en sus propias Skills, cada una cuesta 29 $ y se descarga una sola vez:

El conjunto más amplio incluye los skills para desarrolladores de software y los skills de software y TI.

En resumen:

Una arquitectura es una lista de cosas que has decidido no poder hacer, y un modelo solo describirá capacidades, porque el corpus está escrito por personas cuyo problema interesante merecía publicarse. Dile qué funciona ya, qué no puedes cambiar y quién lo está construyendo antes de que proponga nada. Pide primero las limitaciones que impone el diseño y después las capacidades que habilita, y considera una opción sin desventajas una señal de alerta en lugar de una recomendación. Ignora las cajas e interroga cada flecha, porque ahí viven los fallos, el orden, la idempotencia y el radio de impacto - y debes estar dispuesto a volver a combinar dos cajas en una. Diseña el mismo sistema para una décima parte de la carga para descubrir qué complejidad es esencial. Haz que genere todo el espacio de fallos y encárgate tú de la clasificación. Y haz que muestre la ruta de migración, en pasos en los que podrías detenerte, porque un diseño objetivo sin una ruta para llegar a él es solo un deseo. Para tus restricciones reales y decisiones previas conservadas entre sesiones, Viktor - Skill de AI para arquitectos de software. Funciona en Claude, ChatGPT y cualquier chat de AI, con una garantía de devolución del dinero de 30 días.

Skill · .md · Funciona con Claude y ChatGPT

Viktor - Skill de AI para arquitectos de software

Pregunta qué funciona ya antes de proponer nada, empieza por lo que un diseño impide hacer en lugar de por lo que permite, interroga las flechas en vez de dibujar cajas y muestra la ruta de migración en pasos en los que podrías detenerte. Sin suscripción. Tuyo para siempre.

$19
Obtén el Skill de Viktor →

KissMySkills es un marketplace con más de 1.800 skills de AI, más de 80 packs de prompts, más de 75 agentes y herramientas gratuitas para Claude, ChatGPT y cualquier chat de AI.

Guías de Skills relacionadas

Ponlo en práctica

O consigue todos los skills con Unlimited Ver planes →

Preguntas frecuentes

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 funcionan. Sin palabrería.

Explora cada skill, prompt pack y agent de la tienda.

Explorar todas las habilidades →O prueba las herramientas gratuitas