Vibe Coding NO es Ingeniería del Software
Tu app funciona. Tu demo queda genial. Pero tu código es una pesadilla a punto de explotar.
Desarrollo Dirigido por AgentesEl código es barato. El buen software, no.COMPRAR HOY
Secured by Stripe with AES-256 EncryptionVibe coding no es simplemente usar IA para programar.
Es desarrollar sin entender el código. Es confiar en los resultados basándote en la intuición. Es regenerar soluciones cuando algo falla en lugar de investigar por qué falló.
Sin entender lo que estás haciendo. Sin modelo mental. Sin tests (o con tests de mala calidad). Sin criterio.
Es hacer chapuzas con un LLM de por medio.
La IA no creó a los malos programadores. Solo los expuso más rápido.
Los malos programadores existían antes de la IA generativa.
Antes de ChatGPT, la fricción natural del oficio los frenaba. Tenías que entender lo que hacías: cohesión, acoplamiento, gestión del estado, naming, code smells.
Si no lo entendías, no avanzabas.
Ahora esa fricción ha desaparecido. Y con ella, la barrera que obligaba a pensar antes de programar.
Usar IA es obligatorio. Pensar es innegociable.
No puedes dejar de pensar. En el software y en la vida (que muchas veces se parecen) los problemas se resuelven pensando.
Las aplicaciones no fallan cuando las creas. Fallan después. Cuando escalan. Cuando cambian los requisitos. Cuando alguien tiene que hacer code review y nadie entiende lo que hay escrito.
Hoy tenemos la capacidad de generar toneladas de deuda técnica en cuestión de minutos. Y cuando algo se rompe, la culpa no cae sobre la herramienta. Cae sobre el desarrollador.
La IA debería amplificar la ingeniería: reducir boilerplate, acelerar el trabajo, liberarte para pensar en lo que importa. Pero no debería reemplazar tus modelos mentales ni tus decisiones de arquitectura.
Los mejores developers de hoy no son vibe coders.
Son software crafters aumentados por IA que desarrollan código sostenible.
Los juniors que copian el modelo del vibe coding se saltan los fundamentos. No aprenden a depurar. No aprenden a analizar el comportamiento del sistema. No aprenden a entender por qué algo funciona y qué es sostenible y qué no.
Por eso, cuando llegan a un entorno profesional de verdad, con legacy code, bugs en producción y decisiones de diseño acumuladas de los últimos años, no están a la altura.
El Código Sostenible NO es suficiente
En 2023, meses después de que ChatGPT saliera al mundo, lancé junto a mi colega Carlos Blé una formación que llamamos Diseño Sostenible: Ingeniería y Artesanía del software con TypeScript dirigida a desarrolladores profesionales.
La carta de ventas del curso empezaba así. Copio y pego:
"No sabemos si dentro de poco será la Inteligencia Artificial la que generará todo el código.
No sabemos si los humanos dejaremos de desarrollar con lenguajes de programación para hacerlo solo mediante prompts. Tampoco sabemos si será necesario que los humanos escriban estos prompts.
Quizás las máquinas sepan interpretar mejor lo que queremos... El futuro es incierto, ahora más que nunca, pero aún no estamos ahí..."
Tres años después, ya casi estamos ahí.
La inteligencia artificial ya genera la mayoría del código.
El trabajo de los developers se ha desplazado a los extremos.
Es decir, especificar lo que se quiere construir, revisar que el código sea sostenible y no solo que funcione, y aportar el contexto que la IA no tiene.
Si el equipo hace TDD o no, qué convenciones de naming siguen, qué deuda técnica es crítica y cuál es aceptable, qué decisiones tiene prohibido cambiar sin consultar.
Ahora bien.
Nunca habíamos necesitado tanto el código sostenible como ahora. El cuello de botella ya no es escribir código, es leerlo.
Aunque, en realidad, el cuello de botella nunca ha estado en el teclado. Escribir código nunca fue lo difícil. Lo difícil siempre fue entenderlo.
Buena parte del código que genera la IA acabaremos leyéndolo y revisándolo en algún momento, sobre todo cuando aparezca un bug que la propia IA no sepa resolver. En esos momentos no queda otra que arremangarse, meterse en el código y descubrir qué pasa.
Y si el código no es sostenible, la deuda técnica te explota en la cara.
Y hay algo más.
El código que mejor entendemos los humanos es también el que mejor entiende la IA.
Y no solo porque se entrenó con código humano. Sobre todo porque se entrenó con lenguaje natural.
La IA es un modelo de lenguaje antes que un modelo de código.
Así que cuanto más se parezca el que tú escribes al lenguaje natural (nombres pronunciables, estructuras que se leen como frases, convenciones que cualquier humano reconoce al instante), mejor lo sigue el agente y menos se desvía.
Por eso el código sostenible, lejos de perder importancia, es hoy más necesario que nunca. Para ti. Y para la máquina que trabaja contigo.
Ahora bien, el código sostenible es condición necesaria pero no suficiente.
La profesión ha cambiado.
Antes, ser senior era saber desarrollar buen código. Maximizar la cohesión y disminuir el acoplamiento. Escribir tests automáticos de calidad. Detectar code smells. Refactorizar a diario.
Todo eso que tratábamos en las formaciones con Carlos Blé.
Ahora eso es el mínimo.
¿Aún estás esperando a que la empresa te pague Claude Code?
Porque hay un montón de developers que sí.
Esperando a que la empresa les active la licencia.
Esperando a que alguien les diga qué herramienta usar.
Esperando.
Mientras tanto, hay otros que ya llevan meses en otra liga.
Verás.
Ahora mismo hay tres tipos de programadores.
Los que pagan Codex, Cursor y lo que haga falta de su bolsillo y están experimentando con agentes de IA todos los días.
Los que han probado Copilot o Antigravity pero siguen trabajando igual.
Y los que siguen esperando a que la empresa les active la licencia de Claude Code.
Y van a tres velocidades diferentes.
Tú, ¿en cuál de los tres estás?
Los de la primera velocidad no paran. Cada semana prueban algo nuevo, automatizan algo que antes hacían a mano y aprenden algo que no sabían. Ya no programan igual que hace seis meses.
Hacen ingeniería del software con agentes.
Los de la segunda usan IA, sí. Pero como un autocomplete glorificado. Le piden que les explique un error, que les genere un test. Y poco más.
No ha cambiado demasiado su forma de trabajar.
Y los de la tercera ni han empezado.
Creen que tienen tiempo. Que esto es una moda. Que ya se estabilizará.
El problema es que la cosa no se va a estabilizar.
Se va a acelerar.
Y la distancia entre los primeros y los segundos se está alargando cada semana.
No digamos entre los primeros y los terceros.
Y no va a ser la IA la que te quite el trabajo.
Va a ser un developer con menos experiencia que tú pero que lleva meses experimentando mientras tú esperabas.
Bien.
Puedes aprender esto a base de prueba y error. Quemando meses, tokens y paciencia. Como llevo haciendo yo desde hace más de un año y medio.
O puedes ir directo al grano.
Esto que te voy a presentar no es un curso de prompting. No es un tutorial de Cursor. No es una colección de hacks que dejarán de funcionar el mes que viene.
Es una formación de fundamentos. Cuatro masterclasses sobre cómo dirigir agentes de IA aplicando ingeniería del software de verdad.
Se llama Desarrollo Dirigido por Agentes. Son las cuatro primeras masterclasses de La Mentoría de Software Crafters, recopiladas en una sola formación.
Las que sientan los cimientos.
Vamos con cada una.
Masterclass 1: eXtreme Programming con Agentes de IA
La primera vez que oí hablar de la programación extrema me imaginé a un hacker en vim, fondo negro, fuente verde, programando a una velocidad sobrehumana con técnicas arcanas solo al alcance de unos pocos privilegiados.
Pero no.
XP, la metodología que Kent Beck y Ron Jeffries publicaron a finales de los 90, ni es extrema ni es especialmente arriesgada. Más bien es todo lo contrario.
Pair programming, TDD, baby steps, refactor continuo. Casi que podría llamarse programación conservadora.
Y resulta que esa forma de programar es la que mejor funciona cuando empiezas a introducir agentes de IA en tu flujo de trabajo.
Porque va de poner límites claros: ciclos cortos, feedback constante, no avanzar sin tests.
Y eso, que parecía una concesión a la prudencia, es paradójicamente la forma más rápida y efectiva de programar con agentes de IA.
En esta masterclass, entre otras cosas, aprenderás:
- Lo que diferencia al que programa con IA del que solo pega código de ChatGPT: los 3 niveles de uso (y por qué casi todos se quedan en el primero).
- Cómo ponerle límites a los agentes sin frenar su utilidad… ni perder horas corrigiéndolos después.
- 8 técnicas de prompting que te ahorran bugs y tiempo perdido (especialmente si trabajas con agentes).
- Cómo estructurar reglas y comandos para que los agentes trabajen dentro de un sistema, no por libre.
- El stack que me permite trabajar de forma paralela en múltiples proyectos al mismo tiempo sin perder el control (ni la cabeza).
- Qué aporta eXtreme Programming cuando metes IA en tu flujo de trabajo (y por qué funciona incluso si nunca usaste XP antes).
- Cómo hacer pair programming con IA sin limitarte al viejo modelo de Driver y Navigator.
- Por qué el ciclo TDD clásico no encaja del todo con IA y cómo adaptarlo para que funcione.
- Cómo usar las prácticas de XP con IA sin que todo dependa del estado de ánimo del modelo.
- La técnica que uso para que el agente no complique lo simple ni caiga en sobreingeniería.
- Qué tareas delegar en agentes de IA y cuáles es mejor seguir haciendo tú (por claridad, precisión y control).
Masterclass 2: Arquitectura y Testing de Backend con Agentes
"Los buenos diseños no se inventan, se descubren." — Martin Odersky, creador de Scala.
Y a principios de los 2000, Alistair Cockburn descubrió uno de los mejores.
Lo llamó Ports and Adapters. Tú probablemente lo conoces como arquitectura hexagonal. Las mismas ideas que Uncle Bob empaquetaría años después como Clean Architecture.
Por cierto, tuve la suerte de coincidir con Alistair en una conferencia en Tenerife en 2022. Carlos Blé y yo nos tomamos un café con él mientras nos contaba historias de aquella época.
Pero bueno, que me voy por las ramas.
Cuando Cockburn descubrió la hexagonal los LLMs no estaban ni en pañales. Y sin embargo, más de veinte años después es la arquitectura que mejor escala con la IA generativa.
La razón es simple. La IA genera código acoplado por defecto. Sin reglas, mezcla lógica de negocio con infraestructura, mete queries en los casos de uso y acopla tu dominio al framework.
El resultado es código que funciona hoy y que es imposible de mantener mañana. Incluso por la propia IA.
La arquitectura hexagonal resuelve eso. No porque sea mágica, sino porque le da unos guardarrailes claros tanto al equipo como al agente.
En esta masterclass construimos un backend completo aplicando hexagonal y TDD inside-out.
Y además de eso, entre otras cosas, veremos:
- El error que comete el 90% de los devs con las librerías de validación... y que convierte su código más valioso en una bomba de relojería.
- Por qué tu dominio debería ser una "DMZ"... y qué pasa cuando dejas entrar dependencias que no controlas.
- La combinación de herramientas que uso para programar con IA (spoiler: no es elegir una u otra... es usar las dos a la vez).
- El problema de dejar que un agente de IA programe sin reglas claras... y lo que pasa cuando empieza a "inventar" arquitectura por su cuenta.
- Qué partes del backend testeo con tests unitarios, cuáles con integración y cuáles con e2e... y cómo el agente sabe exactamente qué tipo de test escribir en cada capa.
- La estrategia que uso para organizar reglas sin que el agente se acople a la arquitectura (y la trampa en la que caen la mayoría).
- El sistema de 4 taxonomías que separa rol, arquitectura, diseño y prácticas... y que puedes copiar directamente a tu proyecto.
- El patrón de diseño que permite cambiar de MongoDB a PostgreSQL en una tarde... sin tocar una sola línea de lógica de negocio.
- Cómo defino las reglas de inside-out TDD para evitar que la IA te acabe llenando todo de mocks.
- Los 8 pasos exactos que sigo para desarrollar cualquier feature en piloto automático (y el porqué de este orden específico... y no en otro).
- Las 18 reglas que convierten a un agente de IA impredecible en un desarrollador que sigue tu arquitectura y estilo de programación al pie de la letra.
Masterclass 3: Arquitectura y Testing de Frontend con Agentes
¿Cuántos frameworks de frontend has visto nacer y morir en tu carrera?
Backbone, Knockout, Angular 1, Ember, React con clases...
Yo ya he perdido la cuenta.
Los frameworks van y vienen. Pero los principios de diseño no cambian. Separar la lógica de la UI. No acoplar tu código al framework. Testear el comportamiento, no la implementación.
Eso funcionaba con jQuery en 2010. Y funciona con React en 2026.
El problema es que nos enseñan el framework, no los fundamentos. Nos acoplamos al patrón de turno: primero Redux, después HOCs, luego render props, ahora Context hasta en la sopa y 15 useEffects por componente.
Y cuando el framework de moda cambia, volvemos a empezar de cero.
En esta masterclass aplicamos al frontend los mismos principios que vimos en el backend. Construimos un proyecto con arquitectura hexagonal adaptada al front y reglas para que el agente no se acople al framework de turno.
Y además de eso, veremos:
- La estructura de carpetas que hace que el agente genere código sostenible desde el primer día. No es la típica que ves en los tutoriales.
- La mentira que te han contado sobre testear en frontend (y qué pasa cuando la ignoras).
- Por qué el agente te genera código espagueti: no es culpa de la IA, es culpa de no darle reglas claras (te enseño las mías).
- Por qué hexagonal en frontend no es sobreingeniería cuando sigues esta regla.
- El patrón que separa la lógica de negocio del framework (sí, también en frontend) y que hace que el agente deje de mezclar churras con merinas.
- La capa del frontend donde NUNCA debería vivir React, Vue o Angular. El día que entiendas esto podrás cambiar de framework sin reescribir todo tu código.
- Una regla sobre los props que parece una tontería pero que marca la diferencia cuando el agente tiene que entender tu código. Casi nadie la aplica.
- El tipo de test que escribes pensando que ayuda pero que solo te da trabajo de mantenimiento.
- El error de arquitectura que hace que cada cambio de diseño te obligue a tocar 15 archivos (y cómo reducirlo a 1).
- Una heurística de tres segundos para decidir si algo va en un componente, en un hook o en una función pura.
- La herramienta que conecta el agente con el navegador y que te permite hacer revisiones de UX automáticas mientras tú te dedicas a otras cosas.
Masterclass 4: Skills, Subagentes y MCPs con Claude Code
Nunca le pidas al mismo agente que escribió el código que lo revise.
El sesgo de confirmación que tenemos los humanos también lo tienen los LLMs. Se ratifican a sí mismos. Si tú escribes algo y luego te preguntas si está bien, lo más probable es que digas que sí. A un agente le pasa lo mismo.
La solución: tener un equipo de subagentes especializados, cada uno con su rol y su contexto aislado, revisando el trabajo de los demás. Code-reviewer. Architecture-reviewer. Testing-reviewer. QA-tester. UX-reviewer.
Aquí veremos cómo construir ese equipo. De cómo organizar skills, subagentes y MCPs para que tu trabajo con IA deje de ser "yo y un copiloto" y se convierta en "yo dirigiendo un equipo".
En esta masterclass, entre otras cosas, aprenderás:
- La diferencia entre Vibe Coding y Desarrollo Dirigido por Agentes. Uno es hacer ñapas con la IA. El otro es ingeniería.
- La duda que tiene el 90% de los developers cuando diseñan con arquitecturas orientadas al dominio. Y que casi todo el mundo la resuelve en el sitio equivocado.
- La razón por la que he dejado de pagar Cursor después de casi un año usando el plan de 200 dólares mensuales. No es solo el precio. Es lo que pasa por debajo cuando quieres ir más allá del IDE.
- El estándar que hace que tus reglas de arquitectura, testing y diseño funcionen igual en Claude Code, en Codex, en Antigravity y en Cursor. Escribes una vez. Funciona en todos.
- Una convención de 4 tipos de skill que he diseñado para organizar cualquier proyecto con agentes. Sin ella, acabas con 20 skills mezcladas donde el agente no sabe cuál activar ni cuándo.
- Una meta-skill para crear skills y subagentes. A la que le dices el tipo, el nombre y las herramientas. Te genera todo. Sin tener que acordarte de qué flags van en cada tipo.
- 17 skills construidas sobre los mismos principios que enseño en Testing, Diseño y Refactoring Sostenible. Las mismas que uso en mis proyectos profesionales. Te las llevas incluidas con la masterclass.
- Un ejemplo práctico de TDD inside-out con Opus 4.6 aplicado a un módulo real. Sin TDD la mayoría de los tests generados por el agente son de relleno: testean la implementación, no el comportamiento.
- Por qué pedirle al mismo agente que escribió el código que lo revise no es lo más efectivo. Y cómo el sesgo de confirmación también aplica a los LLMs.
- Cuándo crear un subagente y cuándo te basta con una skill. Hay una sola pregunta que te lo dice. Y no tiene nada que ver con la complejidad de la tarea.
- Los 5 subagentes que he diseñado y que uso para revisar el código, la arquitectura, los tests y la experiencia de usuario. Cada uno aislado, cada uno especializado. También te los llevas con la masterclass.
- Por qué el code-reviewer, el architecture-reviewer y el testing-reviewer se ejecutan en paralelo y el qa-tester y el ux-reviewer son secuenciales. Y qué pasa cuando inviertes el orden.
- El caso de uso para el nuevo modo Agent Teams de Anthropic. Y por qué para el 90% de lo que haces te sobra con subagentes.
- El problema de lanzar dos subagentes que tocan el mismo fichero a la vez. Y la solución de una línea en el frontmatter que lo resuelve.
- Los 7 MCPs que uso cada día y que más han mejorado mi productividad como developer. Te explico cuáles, por qué y cómo los configuro.
- El MCP que sobra en el 90% de los proyectos. Y la regla de una pregunta para saber si cualquier MCP aporta o estorba.
- Y para terminar, un ejemplo real donde ves cómo encaja todo. El flujo que uso cada día aplicado paso a paso. Para que lo repliques en tu proyecto.
El soporte y las Code Reviews
En esta formación no hay grupos de Slack. Ni canales de Discord. Ni foros donde preguntas y nadie contesta.
Aquí me tienes a mí.
Si te atascas, si algo no te queda claro o si necesitas revisar un ejercicio, me escribes directamente por email.
Y te respondo personalmente.
Además, durante los primeros 3 meses puedes enviarme tus soluciones a las katas del curso y recibir feedback detallado sobre tu código.
Sin bots.
Sin asistentes.
Sin "tutores certificados".
Solo tú, tu código y yo.
La mejor forma de aprovechar este acompañamiento es esta:
Primero haces el ejercicio por tu cuenta.
Me mandas tu solución. Reviso el código y te doy feedback concreto.
Después ves cómo lo resuelvo en los vídeos del curso. Comparamos enfoques, criterios, decisiones de diseño.
Y una vez lo has visto, vuelves a escribir tu propia solución. Me la envías de nuevo.
Y revisamos juntos qué ha mejorado… y qué detalles aún pueden afinarse.
Ahí es donde de verdad interiorizas lo que has aprendido.
Porque no se trata de ver cómo lo hago. Se trata de que lo pienses tú, lo hagas tú y lo trabajemos juntos.
Este servicio de acompañamiento y Code Reviews te lo podría vender perfectamente como un servicio aparte.
Tú te lo llevas incluido, sin pagar un euro más.
¿Cuál es el precio de una formación tan completa?
Como dice Warren Buffett: "precio es lo que pagas, valor es lo que recibes".
O dicho de otra forma, solo el necio confunde valor con precio.
La pregunta es: ¿cuánto vale para ti algo así?
No solo por la calidad y cantidad del contenido, más el acompañamiento y las Code Reviews.
Yo tengo claro lo que habría pagado:
¿1000€?
¿1500€?
(¿1000 o 1500€, Miguel? Exagerado…)
Te aseguro que he pagado formaciones mucho más caras que esta, y con mucho menos valor.
Pero claro, yo soy yo, y mis circunstancias.
La verdad es que he tenido problemas para poner el precio… ¿Por qué? Porque esto no es solo otro curso online, es más de un año de trabajo y en parte, también estoy vendiendo mi tiempo.
Aun así, había que poner una cifra. Y esta es la de ahora.
550€ impuestos incluidos. Pago único.
Fin de la historia.
Si quieres entrar a Desarrollo Dirigido por Agentes solo tienes que darle al botón de comprar hoy. En menos de 3 minutos estarás dentro.
Desarrollo Dirigido por AgentesEl código es barato. El buen software, no.550€COMPRAR HOYSecured by Stripe with AES-256 EncryptionPreguntas que quizás te estás haciendo
- ¿Qué conocimientos previos?
Esta formación está pensada para programadores profesionales.
Vale tanto para juniors como para seniors, pero si partes desde cero, no es el momento. Tener experiencia haciendo tests te ayudará a sacarle más partido.
- ¿Necesito haber hecho Testing, Diseño o Refactoring Sostenible antes?
No es requisito.
Pero te va a ayudar. Los cimientos del código sostenible (testing, diseño y refactoring) son lo que separa a un developer profesional de un vibe coder. Y aquí no los explico desde cero, los aplico en el contexto del trabajo con agentes.
Si nunca los has tocado, no te bloqueas. Pero te recomiendo que en algún momento te metas con ellos.
- Programo en otro lenguaje, ¿me sirve?
Sí. El 90% del contenido es transversal y aplicable en cualquier lenguaje.
He elegido TypeScript como vehículo porque está creciendo rápido y es muy versátil. Pero el foco está en el diseño, no en el stack.
- ¿Qué herramientas necesito?
Una cuenta en al menos uno de estos: Cursor, Claude Code, Codex CLI, OpenCode o algún otro coding agent moderno. La metodología es la misma para todos.
En las tres primeras masterclasses uso Cursor, porque era con lo que trabajaba en ese momento. En la cuarta me paso a Claude Code y explico por qué.
Da igual con cuál te quedes tú. Lo que aprendes aquí es transversal.
- ¿Desde cuándo tengo acceso?
Desde el momento en que haces la compra.
- ¿Tiene fechas o plazos?
No, tú decides cuándo la empiezas y cuándo la acabas. Una vez terminada podrás consultarlo las veces que quieras.
Esta no es la típica suscripción que tienes que pagar cada mes o cada año, pagas una vez y tendrás acceso para siempre.
- ¿Hay grupo de soporte?
Esto es importante que lo tengas claro: No hay grupo de Facebook, ni Slack, ni Discord.
Hay algo mejor.
Si tienes dudas (que las tendrás) me escribes directamente a mí por email. Te responderé personalmente.
Además, podrás enviarme tu solución sobre los ejercicios y katas propuestas para recibir feedback durante los 3 primeros meses tras la compra.
- Quiero aprovechar la oferta pero no voy a poder empezar el curso, ¿puedo posponer el soporte?
Sí. Escríbeme en cuanto hagas la compra y lo tengo en cuenta. Eso sí: si pasa un año y no has empezado, caduca.
- ¿Me revisas cualquier código?
No. El soporte no es como la mentoría personalizada. Aquí te reviso los ejercicios y katas propuestas en la formación, no código de proyectos externos.
- ¿Esto reemplaza la mentoría?
No. En la mentoría sí te reviso cualquier código, te doy consejos de carrera y te acompaño en el día a día. Es un programa vivo: una masterclass nueva cada mes, soporte continuo y acceso a las masterclasses que se publiquen desde el día que entras.
Las anteriores no se recuperan. Por eso esta formación existe: es la única forma de tener las cuatro primeras.
Esto es solo el contenido fundacional. Las que sientan los cimientos del Desarrollo Dirigido por Agentes.
- Cuando saques nuevas masterclasses en la mentoría, ¿las veré también en esta formación?
No. Esta formación recoge las cuatro primeras masterclasses y nada más.
Las nuevas se quedan dentro de la mentoría, que es donde corresponden, y son solo para los socios activos.
- ¿Hay garantía de devolución?
No, en ningún caso. Si no tienes claro que te compense, mejor no la compres.
- ¿Podemos comprar una sola licencia para varios miembros del equipo?
No. La licencia es individual.
Aunque el formato sea digital, incluye soporte personalizado y revisiones de código.
Cada persona que accede necesita su propia inscripción. Si son varios en el equipo, cada desarrollador debe realizar su propia compra.
- ¿No es caro 550€ por un curso online?
El soporte por sí solo ya vale más que eso.
Si te parece caro, o no puedes permitírtelo, no la compres.
- ¿Se puede pagar a plazos?
Sí, con Klarna o Paypal puedes dividir el pago en 3 cuotas sin intereses (disponible en varios países).
- ¿Puedo pagar por transferencia o criptomonedas?
Sí. Escríbeme a miguel.gomez@softwarecrafters.io y te explico cómo.
- ¿Haces factura?
Sí. Solo tienes que rellenar tus datos de facturación al comprar y la recibirás en 48h.
- ¿Es bonificable por FUNDAE?
No. Superamos el límite de alumnos permitido para estas ayudas.
Tampoco la diseñé pensando en ayudas públicas sino en contenido que realmente sirva.
- ¿Haces descuentos?
Nunca. Por simple respeto a los alumnos que ya están dentro. Ni por Black Friday, ni por Navidades, ni por el día del programador.
Hoy es el mejor precio al que puedes entrar. Mañana será igual o más alto. Nunca más bajo.
Desarrollo Dirigido por AgentesEl código es barato. El buen software, no.550€COMPRAR HOYSecured by Stripe with AES-256 Encryption