La IA NO reemplazará a los programadores.
Sino que los (buenos) programadores reemplazarán a todos los demás.

creado por y para DevelopersCOMPRAR HOY

Últimamente no paro de leer titulares:
“Ya no hay que escribir ni una sola línea de código más.”
“La IA te va a dejar sin trabajo.”
“RIP developers.”
Incluso Barack Obama se ha sumado a la fiesta diciendo que:
“La IA ya es mejor que el 70% de los programadores.”
Curioso, viniendo del mismo Obama que en su día se hizo famoso por ser el primer presidente en escribir código en público.
Y no solo eso. Entonces recomendaba a todo el mundo aprender a programar porque “te enseña a pensar”.
¿Y ahora?
Ahora no.
Ahora todo lo contrario.
Lo que de verdad asusta no es la IA, es la falta de criterio al hablar de ella.
Pero bueno… son sus costumbres y hay que respetarlas.
Naval Ravikant, que sí sabe de lo que habla, lo resumió mucho mejor en un tweet:
“La IA NO reemplazará a los programadores. Sino que los programadores reemplazaremos a todos los demás.”
99% de acuerdo.
Solo le falta un matiz. Un matiz del que te das cuenta cuando llevas años sufriendo las calamidades del paso del tiempo en el código de los proyectos.
Por eso añadí “buenos” entre paréntesis.
Y es que no creo que lo que dice Naval aplique a todos los developers, sino a los buenos de verdad.
A los que de verdad marcan la diferencia.
Porque picar código que más o menos funcione lo sabe hacer cualquiera.
Y ya casi ni hay que picar, solo tienes que copiar y pegar de ChatGPT o directamente lo generas con Cursor…
Pero que el código funcione no significa que esté terminado.
Porque muchas veces los developers olvidamos la otra mitad del trabajo: la de hacer el Código Sostenible
Y cuando digo sostenible, me refiero a fácil de mantener.
Y cuando digo fácil de mantener, me refiero a sencillo de cambiar
Si, cambiar. Porque hay una verdad absoluta en el software: si un proyecto tiene cierto éxito cambiará.
Ojalá alguien me hubiera dicho cuando empecé a programar que aprender a escribir buenos tests era fundamental para diseñar software de calidad...
Podría contarte algunas historias parecidas que me tocó vivir en mis primeros años programando. Pero ninguna ilustra mejor el problema que la que le ocurrió a Carlos Blé —mi socio en esta formación— hace ya unos 20 años.
“En 2004 monté mi primera empresa junto a tres amigos.
Uno de los mejores clientes que conseguimos fue una pequeña empresa de telefonía y canales de televisión que representaba más de la mitad de nuestra facturación.
Recuerdo que una mañana, mientras estaba desarrollando la parte de su web de registro de clientes, me llamaron porque ciertos usuarios no podían darse de alta en el sistema.
Resulta que eran extranjeros con apellidos que contenían símbolos como el apóstrofe o la diéresis y el código de validación fallaba y no les permitía registrarse.
No teníamos ni un test, no sabíamos ni cómo se hacían.
Tampoco teníamos un entorno de pruebas.
Sino que hacíamos los cambios a cualquier hora, directamente en el entorno de producción.
Aquella mañana hice como diez cambios en el código, cada uno correspondiente a una llamada de teléfono de mi cliente, quejándose por un caso diferente.
Mientras arreglaba un caso estropeaba otros, estaba cada vez más tenso y mi cliente más molesto.
Con cada cambio en producción teníamos que reiniciar el servicio y los usuarios conectados perdían su sesión.
Al final del día el cliente se había dado cuenta de que no éramos solventes, había agotado su paciencia.
Paró el proyecto y nos lo quitó.
Para mí fue una gran lección y la terminé de comprender cuando aprendí a hacer tests”.
Hoy en día hay tantas alternativas que los usuarios ni siquiera se molestan en llamarte para quejarse.
Simplemente cierran tu aplicación, dejan tu servicio y se van a la competencia sin que te des cuenta.
El coste de un bug en producción es más alto que nunca.
Porque la tolerancia de la gente es mínima.
Y las alternativas, infinitas.
Hay que reducir al mínimo el número de bugs que llegan a producción. Y sobre todo, impedir que reaparezcan problemas que ya estaban reportados y corregidos.
Juniors con 10 años de experiencia
El significado de la palabra senior no ha cambiado demasiado en los últimos 20 años.
Aún hoy en día en muchas empresas a los developers se les llama seniors (o se consideran ellos mismos) por el simple hecho de llevar “n años” programando, sin importar si han aprendido algo durante ese tiempo.
Y no me refiero solo a habilidades técnicas. También están las soft skills se esperan de un programador experimentado, especialmente las relacionadas con la comunicación.
Porque sí: el código también comunica.
Para esto es fundamental entender cómo funciona el negocio, cómo hace dinero, dónde se aporta valor y dónde no.
No estoy diciendo que los años programando no sean importantes.
Sin duda lo son. No hay mejor aprendizaje que sufrir las calamidades del paso del tiempo en los proyectos para entender la importancia de saber escribir código de calidad.
Como diría Nassim Taleb: con Skin in the game.
Sufrir las consecuencias de tus decisiones en el código, en tu propia piel.
No hay otra.
Ahora bien, hay una enorme diferencia entre 10 años de experiencia…
… y un año de experiencia repetido 10 veces.
No es lo mismo 10 años de aprendizaje real, trabajando en varios proyectos, con diferentes lenguajes, tecnologías, paradigmas, y rodeado de developers de alto nivel, que además dan importancia a escribir buenos tests.
Que pasar 10 años en la misma empresa, con un equipo mediocre, resolviendo siempre el mismo tipo de problemas, en un proyecto que hace aguas, sin tests y plagado de malas prácticas.
Ahí es donde el aprendizaje se detiene.
O peor: donde los malos hábitos se consolidan.
Las formaciones que hay en el mercado tampoco ayudan...
La mayoría de las formaciones para developers tienen dos problemas.
El primero: están creadas por personas que nunca han convivido lo suficiente con su propio código. Pasa en cursos online, bootcamps y, sobre todo, en la universidad y ciclos formativos.
No son conscientes de los problemas de mantenimiento que puede acarrear la forma en la que enseñan a programar.
De hecho, me atrevo a decir que en el 90% de esos cursos no se escribe ni un test.
Y sin buenos tests no puede haber calidad en el software.
¿Por qué?
Porque una buena batería de pruebas es lo único que te permite refactorizar con garantías.
Los tests son nuestra red de seguridad.
Sin tests (o con tests de mala calidad), intentarás mejorar una cosa y romperás otra. Garantizado.
Tenemos que cambiar esa mentalidad de que programar y hacer tests son tareas distintas.
El segundo problema es cómo enseñan.
¿Te imaginas un curso de cocina donde solo hagas recetas con la Thermomix?
Pues eso es lo que hacen la mayoría de cursos para developers: enseñar a programar centrados en el último framework o librería de turno.
No centran en los principios.
Ni en los fundamentos.
Sino en diseñar soluciones totalmente acopladas a la última herramienta de moda.
Y justo por eso nació esta formación.
Llevábamos años —Carlos Blé y yo— viendo los mismos errores repetirse. En proyectos reales. Con equipos reales. Y consecuencias que no salen en los tutoriales.

Así que decidimos crear el curso que nos habría ahorrado años de frustración:
Testing Sostenible con TypeScript
Un curso de Testing, TDD y Diseño de Software creado por y para Developers
Una formación donde no solo aprendes crear tests de calidad.
Aprendes a diseñar mejor software (o a escribir mejor código, que en realidad es lo mismo).
A diseñar software testable y fácil de mantener.
Incluye vídeos teóricos y prácticos, soluciones a diferentes katas, ejercicios tipo test, repositorios de código… y alguna que otra sorpresa que te contaré más adelante.
Es un atajo.
Pero no un atajo para memorizar "lo que hay que hacer".
Es un atajo para entender el por qué.
¿Cómo lo hacemos?
Todo empieza con una masterclass inicial (y además puedes ver parte de ella de forma totalmente gratuita).
Es mucho más que una simple introducción.
Aquí ya empezarás a entender por qué tantos proyectos terminan secuestrados por su propio código.
Además de presentarnos y explicarte cómo está estructurada la formación, en esta masterclass vas a descubrir:
- Por qué el código degenera y cómo es posible mantener un proyecto green field a lo largo del tiempo.
- La pregunta que deberías hacerte antes de decidir reescribir el proyecto desde cero.
- Los dos ingredientes que suelen tener los proyectos más difíciles de mantener (y cómo evitarlos desde el primer momento).
- Los tres fallos de diseño que hacen que el código deje de ser predecible y se convierta en terreno inestable con cada commit.
- Las 4 reglas que usamos para mantener el control sobre el código, incluso cuando la complejidad empieza a apretar.
- Por qué sin tests no puede haber calidad en el software (ni tranquilidad para cambiar el código).
- Cómo escribir abstracciones adecuadas, precisas y orientadas al negocio.
- El método de práctica deliberada que te permite mejorar como developer más allá de lo que aprendes en el trabajo diario.
Y esto es solo una pincelada.
El grueso del curso empieza ahora, con tres bloques donde vamos a entrar a fondo en los principios, las técnicas y las prácticas que realmente marcan la diferencia en el día a día.
Bloque 1 — Fundamentos de Testing
"No nos pagan por hacer tests. Nos pagan por hacer software que funcione."
— Kent Beck
Y sin embargo, es imposible construir software que funcione bien y siga siendo fiable a medida que evoluciona, si no hay tests bien diseñados detrás.
De hecho, la primera regla del diseño simple dice que el código tiene que pasar correctamente los tests. Pero para eso, primero tiene que haber tests…
En este primer bloque vamos a sentar las bases.
No vamos a limitarnos a repetir definiciones.
Vas a entender qué es realmente el testing de software. Por qué es crítico para la calidad del código (y más aún en tiempos de la IA generativa).
Y cómo diseñar una batería de tests que no se convierta en una carga con el paso del tiempo.
Además, en este bloque aprenderás:
- Qué significa usar los tests como base para diseñar software de calidad (y no solo como una obligación más).
- La sutil diferencia entre framework y librería, y por qué entenderla te ayuda a elegir mejor tus herramientas.
- Cuál es la mejor forma de distribuir tus tests según el contexto del proyecto (más allá de la típica pirámide).
- A construir tu propia librería de testing desde cero para entender los fundamentos que hay detrás de cualquier framework.
- En qué se diferencian los enfoques xUnit y RSpec, y cómo condicionan tu forma de testear.
- A sacarle todo el partido a Jest (o a cualquier otra herramienta de testing moderna).
- Qué tipo de funciones deberías priorizar si quieres escribir código más testable y mantenible.
- A trabajar con umbrales de cobertura sin caer en la obsesión por alcanzar el 100%.
- Una introducción práctica a TDD: empieza por la mínima implementación posible y evoluciona el diseño guiado por los tests.
Bloque 2 — Tests Sostenibles
“Los tests no son solo para encontrar errores, sino para garantizar la estabilidad del diseño.” — Steve McConnell
Y para eso, tienen que ayudarte a avanzar con confianza, no a frenarte cada vez que algo cambia.
Es fácil escribir tests. Más aún con la ayuda de la IA.
Lo difícil es que sigan siendo útiles seis meses después.
El problema es que, en la mayoría de proyectos, el código de los tests se trata como código “de segunda”.
Se improvisa. No se refactoriza.
Y con el tiempo se convierte en un lastre.
En este bloque descubrirás:
- El error más común que cometen los developers que no tienen experiencia manteniendo grandes baterías de test (y cómo evitarlo).
- Los 13 atributos que deberías tener en mente cada vez que escribes un test (y cómo combinarlos sin dispararte en el pie).
- El sesgo silencioso que degrada tus pruebas sin que te des cuenta (y cómo empezar a verlo antes de que sea un problema).
- Por qué clasificar los tests (unitario, integración, etc.) no es tan importante como entender qué compromisos estás aceptando con cada uno.
- Casos reales donde las pruebas se ejecutan directamente en producción (y lo que puedes aprender de ellos para proyectos más pequeños).
- Un ejercicio práctico para entender por qué los buenos tests no solo validan: también te ayudan a escribir mejor código.
- Cómo nombrar tus tests para que representen las reglas del negocio (y sigan teniendo sentido incluso cuando los detalles de implementación cambian).
- Un pequeño cambio en el enfoque que transforma un test irrelevante en una pieza de documentación viva.
- Refactorizar no es solo para el código de producción: los nombres y la estructura de tus tests también hablan del diseño.
- Un test, un motivo: cuanto más acotado es el comportamiento que validas, más fiable será tu feedback.
- Por qué definir fixtures genéricos puede parecer buena idea… hasta que necesitas entender qué está fallando.
- La claridad de un test empieza por su estructura. Y Arrange, Act, Assert sigue siendo la forma más fiable de conseguirla.
- Una técnica para escribir aserciones personalizadas que comunican exactamente lo que importa (y eliminan el ruido innecesario).
- Métodos de extensión y monkey patching: tu mejor aliado o tu peor enemigo (normalmente lo segundo).
- Dos patrones de diseño que te ayudan a encapsular los detalles irrelevantes sin perder expresividad y una kata dónde lo ponemos en práctica.
- Cómo usar los mocks con cabeza: entenderás la diferencia entre un stub, un spy y un mock estricto, cuándo tiene sentido usarlos… y cuándo no.
- Tres ejercicios prácticos donde podrás aplicar todo lo aprendido y recibir feedback sobre tu enfoque y criterio técnico.
Bloque 3 — Diseño de Software Dirigido por Tests
"TDD no es escribir los tests primero, es diseñar software de manera iterativa con feedback constante" — Martin Fowler
Hay mucha gente que piensa que el objetivo de TDD es conseguir una mejor cobertura de tests.
Otros creen que solo por hacer TDD crearán mejores diseños.
Otros que desarrollarán mejor por arte de magia.
Pero no.
Esto no es ni de lejos lo más importante.
Sin duda lo mejor de TDD es que te obliga a pensar antes de programar, siempre y cuando lo sepas aplicar.
Si, a pensar.
El simple hecho de tener que expresarlo con un test, te obliga a clarificar las ideas antes de ponerte a codificar.
El cuello de botella en los proyectos nunca ha sido pensar, sino todo lo contrario.
Y es que la mayoría de los desarrolladores lo que hacen es ponerse a “picar código” como pollo sin cabeza.
Sin pensar en las consecuencias. Sin pensar si esa es la solución más simple que pueden implementar.
En este bloque sin duda es el más importante, está dividido en dos partes, en los que aprenderás:
(Parte 1: Fundamentos y proceso)
- Qué significa realmente TDD (más allá de “escribir el test primero”) y cómo usarlo para tomar decisiones de diseño más acertadas.
- Cómo convertir requisitos vagos en ejemplos concretos… y esos ejemplos en tests que guían el desarrollo.
- Las tres fases (red, green, refactor) como motor de diseño, no como un dogma sin sentido.
- Qué hacer cuando tienes un test en rojo: tres estrategias de implementación para avanzar sin comprometer la estructura del código.
- Cuándo TDD puede ayudarte a implementar algoritmos de forma sencilla… y cuándo no tiene sentido usarlo si no conoces bien la solución de antemano.
- Por qué el diseño emergente no es improvisación: cómo usar TDD para explorar soluciones cuando hay varias formas de resolver un problema.
- Qué hacer cuando las reglas de negocio no están del todo claras y cómo evitar que la incertidumbre bloquee el diseño.
- Por qué diferenciar entre una regla de negocio de un simple ejemplo cambia por completo cómo enfocas el desarrollo.
- Técnicas para identificar y reducir la complejidad accidental antes de que se convierta en deuda técnica.
(Parte 2: Técnicas, patrones y práctica)
- Cuándo tiene sentido introducir recursividad para avanzar de rojo a verde y cómo mantener el código simple mientras generalizas la solución.
- Qué convierte a un Value Object en algo realmente útil… y cuándo no merece la pena introducirlo.
- Cómo aplicar principios de DDD sin caer en la trampa de la sobrearquitectura: con foco en lo que importa.
- Qué es la Premisa de la Prioridad de Transformación (TPP) y cómo puede ayudarte a avanzar sin quedarte atascado devolviendo valores literales.
- La diferencia entre testear comportamientos y jugar a devolver respuestas hardcodeadas sin avanzar en el diseño.
- Por qué cada nuevo test debería provocar una transformación concreta en el código y qué pasa si no ocurre.
- Cómo integrar Git en tu flujo de TDD para avanzar con seguridad, sin miedo a romper lo que ya funciona.
- A diseñar desde dentro (escuela clásica) o desde fuera (escuela mockista)… y cuándo tiene sentido combinar ambos enfoques para no perder flexibilidad.
- Por qué los buenos diseños no dependen de grandes decisiones, sino de una secuencia de pasos bien dados.
- Siete ejercicios prácticos donde podrás aplicar todo lo aprendido y enviarlos para recibir feedback sobre tu razonamiento y tus decisiones de diseño.
Si aún no lo tienes claro, aquí tienes los contenidos detallados
Se trata de una formación de alto nivel organizada en 28 apartados que incluye más de 150 videos teóricos y prácticos. Las lecciones son concisas, valoramos tu tiempo tanto como el nuestro, así que no te haremos perderlo dando rodeos.
El curso empieza con una masterclass gratuita sin límite de tiempo y sin ningún compromiso (ni siquiera pedimos tarjeta de crédito).
Queremos que esta masterclass sirva como tu primer punto de contacto con nosotros y que te ayude a evaluar la calidad del contenido ¿no te convence? No hay problema, sin rencores.
Y aquí es donde esta formación se diferencia del resto: 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 6 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 por 100 €/mes (o lo que es lo mismo: 600 € los 6 meses).
Tú te lo llevas incluido, sin pagar un euro más.
Muy bien, pero ¿cuál es el precio de una formación tan completa?
Como dice Warren Buffet: “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:
¿2000€?
¿3000€?
(¿2000 o 3000€, Miguel? No te flipes…)
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 que he tenido problemas para poner el precio… ¿Por qué? Porque esto no es solo otro curso online, son más de dos años 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 (que no será la definitiva y seguirá subiendo).
500€ impuestos incluidos. Pago único.
Fin de la historia.
Si quieres entrar a Testing Sostenible solo tienes que darle al botón de comprar hoy. En menos de 3 minutos estarás dentro.

creado por y para Developers500€COMPRAR HOY

- Acceso de por vida, nada de suscripciones.
- Más de 150 videos teóricos y prácticos. Son lecciones concisas, no te haremos perder el tiempo dando rodeos.
- Katas, ejercicios y repositorios de código para que aprendas haciendo.
- Acceso a las actualizaciones que hagamos en las futuras ediciones del curso.
- Soporte y revisiones de código durante 6 meses.
Preguntas raras (y no tanto) que me han hecho más de una vez
- ¿Es buena inversión?
LoL ¿Qué pregunta es esa? xD ¿Qué quieres que te diga?
“No, claro que no es buena inversión. Me pasé dos años junto a Carlos Blé preparando un curso con más de 150 vídeos… pero nah, no merece la pena.”
Anda que… Más preguntas, señoría.
- ¿Hay garantía de devolución?
No, en ningún caso. Si no tienes claro que te compense, mejor no la compres.
- ¿Qué conocimientos previos?
Saber programar, aunque sea lo mínimo. Vale tanto para juniors como para seniors, pero si partes desde cero, no es el momento.
- 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.
- ¿Podemos comprar una sola licencia para varios miembros del equipo?
No. La licencia es individual.
Aunque el formato sea digital, incluye soporte personalizado, revisiones de código y corrección del ejercicio.
Cada persona que accede necesita su propia inscripción. Si son varios en el equipo, cada desarrollador debe realizar su propia compra.
- ¿Para qué quiero aprender a hacer tests si ya me los hace Cursor o ChatGPT?
Porque si no sabes lo que estás haciendo, da igual quién escriba el test.
Siguiente pregunta señoría.
- ¿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.
- ¿Desde cuándo tengo acceso?
Desde el momento en que haces la compra.
- ¿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 6 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 una mentoría personalizada. Reviso los ejercicios y katas propuestas en el curso, no proyectos externos.
- ¿Es caro 500€?
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 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.

creado por y para Developers500€COMPRAR HOY

- Acceso de por vida, nada de suscripciones.
- Más de 150 videos teóricos y prácticos. Son lecciones concisas, no te haremos perder el tiempo dando rodeos.
- Katas, ejercicios y repositorios de código para que aprendas haciendo.
- Acceso a las actualizaciones que hagamos en las futuras ediciones del curso.
- Soporte y revisiones de código durante 6 meses.
Una colaboración de:
