De repositorio base a skill: cómo llevo mis patrones .NET a la IA
Durante varios años arrastré la misma costumbre: tener un repositorio base de .NET con mis patrones, mis librerías favoritas y las buenas prácticas que fui recogiendo proyecto tras proyecto. Cuando llegaba uno nuevo, clonaba ese repositorio y empezaba el ritual: crear archivos, borrar otros, renombrar, quitar lo que no aplicaba y añadir lo que faltaba.
Era útil, pero tedioso. Ningún proyecto tenía exactamente las mismas características, así que el repositorio base nunca encajaba al 100%. Siempre tocaba acomodarlo a mano.
Ese repositorio terminó siendo un skill. Y ese cambio dice bastante sobre cómo estamos programando hoy.
De arquitectura limpia a vertical slice, y aún así el repositorio molestaba
Mi primer repositorio base estaba montado sobre arquitectura limpia. Capas marcadas, separación estricta, todo en su sitio. Con el tiempo me fui moviendo hacia Vertical Slice, por razones que ya conté en otro artículo: menos choques, PR más cortos y el foco puesto en el caso de uso, no en respetar la plantilla.
El cambio ayudó con un problema concreto. Al organizar por features autocontenidas, ya no tenía que arrastrar tantas capas compartidas entre proyectos distintos. Cada caso de uso vivía junto, así que recortar lo que sobraba era más limpio.
Pero el repositorio base seguía ahí. Aunque la arquitectura fuera más modular, yo seguía clonando, renombrando y borrando. Vertical Slice redujo la fricción de mantener la estructura; no eliminó la fricción de arrancar cada proyecto desde una copia que nunca calzaba del todo.
La pregunta incómoda era simple: ¿de verdad necesitaba seguir cargando un repositorio entero para transmitir algo que, en el fondo, eran decisiones y convenciones?
Dejé de copiar un repositorio y empecé a darle un skill al agente
La respuesta fue dejar de tratar mis patrones como archivos y empezar a tratarlos como criterio escrito.
En lugar de un repositorio base, escribí un skill: un archivo de contexto en Markdown que describe cómo quiero que se construya una aplicación .NET. Cómo organizo las features, qué librerías uso y para qué, cómo nombro las cosas, cuándo sí meto una abstracción y cuándo no. Se lo entrego al agente y, a partir de ahí, genera el código siguiendo mis convenciones en vez de las suyas.
No es magia ni una plantilla mágica. Es la diferencia entre copiar carpetas y entregar el criterio que hay detrás de esas carpetas.
El resultado lo publiqué como dotnet-vertical-slice-best-practices, una skill instalable desde skills.sh. Si alguien quiere probarla, puede agregarla con:
npx skills add josearias210/dotnet-vertical-slice-best-practicesEl punto no es vender Vertical Slice como la respuesta universal. El punto es otro: empaquetar mi criterio técnico para que un agente no arranque desde defaults genéricos cuando le pido construir un backend en .NET.
Por eso la skill no se queda en “usa Vertical Slice”. También documenta decisiones sobre Minimal APIs, CQRS con MediatR, validación, errores esperados, migraciones de EF Core, composición de solución, paquetes centralizados y hasta el flujo de build con GitHub Actions. Esas son decisiones que normalmente estaban escondidas en mi repositorio base o en mi cabeza.
Soy consciente de que esto puede sonar contradictorio con algo que ya he dicho. Cuando hablé del subsidio de la IA comenté mis reservas sobre los skills enormes que documentan cada detalle del proyecto, porque los modelos actuales ya descubren buena parte de esos patrones leyendo el código. Y lo mantengo.
La diferencia es el objetivo. Una cosa es documentar de más por miedo, repitiendo lo que el agente puede deducir solo. Otra es darle el criterio que de verdad cambia el resultado: decisiones de arquitectura, convenciones y excepciones que no están escritas en ningún archivo del proyecto nuevo porque el proyecto todavía no existe. Ese skill no sustituye lo que el modelo ya sabe; le da lo que no puede adivinar.
No digo que mis patrones sean los mejores. Cada quien tiene su criterio y el mío seguirá cambiando. Pero creo que esta es la forma razonable de empezar y mantener un desarrollo en .NET hoy: ni escribir todo desde cero, que ya no tiene mucho sentido, ni dejar que la IA decida sola.
La IA no elige .NET por ti, y ahí está el riesgo
Hay que ser honestos con una cosa. Si le pides a un agente que te genere un backend sin más contexto, no siempre va a asumir .NET como primera opción. Tiende a tirar por pilas más genéricas según el modelo, el prompt y los ejemplos que tenga más cerca. Y si tu mundo es .NET, eso no es lo que quieres.
Ese sesgo es justamente otra razón para tener un skill. No solo fija mis patrones: fija el lenguaje y el ecosistema. Le dice al agente que aquí se trabaja en .NET, con sus convenciones, no con la opción genérica que elegiría por su cuenta.
Y hay un punto más delicado. Todavía no podemos confiarnos de que la IA produzca código 100% fiable. Si le pides código en un lenguaje que dominas, detectas el error de un vistazo. Si se lo pides en uno que no manejas bien, puede colar fallos sutiles que ni siquiera reconoces como fallos.
Por muchas bases sólidas de programación que tengas, hay detalles muy puntuales de cada lenguaje que solo se aprenden trabajando años con él. En un ecosistema tan fuertemente tipado como .NET, esos detalles importan: comportamientos del runtime, sobrecargas, nulabilidad, async/await, cómo se evalúa una consulta de EF Core. Cosas que no se ven en una buena práctica general, sino en la cicatriz de haberlas sufrido.
Por eso, aunque suene contradictorio para algunos, si vas a trabajar el backend en .NET, mi recomendación es que sigas en .NET aunque la IA escriba el código. No para presumir el stack, sino porque necesitas el criterio para revisar lo que genera. Pedirle código en un lenguaje que no dominas te deja sin la capacidad de detectar cuándo se equivocó.
No es soltar el volante, es darle dirección
Para mí este es el equilibrio que tiene sentido ahora. No tiene mucho caso escribir cada línea desde cero, pero tampoco podemos quitar las dos manos del volante. La IA hace el trabajo con nosotros, supervisada por nosotros, y el skill es la forma de inyectarle nuestro criterio antes de que empiece.
Esto no reemplaza nada de lo que ya debería existir. Las pruebas, la revisión y un buen proceso de entrega continua siguen siendo necesarios; ahí no cambia el juego. Lo que digo es más acotado: a nivel de codificación, darle al agente tus patrones es el mínimo esfuerzo que deberíamos hacer si queremos que el resultado se parezca a lo que construiríamos nosotros. Es la misma idea de meter la IA dentro de un proceso controlado en vez de soltarla a ciegas, solo que aplicada al momento de escribir el código.
Un skill tampoco es gratis. Hay que mantenerlo: cuando cambia mi criterio o la versión del framework, el skill se queda viejo igual que se quedaba viejo el repositorio base. La diferencia es que mantener un texto con decisiones es más barato que mantener una copia de archivos que toca reacomodar en cada proyecto. Y si mis patrones están mal, el skill propaga ese error con eficiencia; por eso sigue dependiendo de mi juicio, no lo sustituye.
No fue dejar de programar en .NET ni delegar el criterio. Fue ponerlo por escrito una vez para no reconstruirlo a mano en cada proyecto, y quedarme con la parte que de verdad me corresponde: decidir y revisar. El volante sigue siendo mío.
Si quieres seguir aprendiendo sobre estos temas te invito a ver mis otras publicaciones.
