Por todas partes, los desarrolladores debaten sobre la eficacia real de los agentes de codificación. Unos dicen: «La codificación con IA es un desastre. La he probado y es inútil». Otros responden: «No, es que la estás utilizando mal, es una cuestión de habilidad».

Ambos tienen razón. Pero si hay un «problema de habilidad» que socava silenciosamente a la mayoría de los desarrolladores que utilizan agentes de codificación con IA, es no comprender la ventana de contexto, la mayor limitación que determina cómo piensan, razonan y responden los agentes de codificación.

Si alguna vez has sentido que tu agente se ha vuelto repentinamente olvidadizo o inconsistente en medio de un proyecto, este artículo es para ti.

¿Qué es exactamente una ventana de contexto?

Una ventana de contexto es todo lo que un modelo de IA «ve» en un momento dado, tanto los tokens de entrada como los de salida.

Cuando chateas con un modelo, los tokens de entrada incluyen:

• Las indicaciones del sistema (sus instrucciones y herramientas)
• Tus mensajes
• Cualquier archivo o código de apoyo que hayas proporcionado

Los tokens de salida son las respuestas del modelo.

Juntos, forman la ventana de contexto, un espacio de memoria de tamaño fijo que el modelo utiliza para comprender lo que está sucediendo.

Piensa en ello como una pizarra que se va llenando a medida que hablas. Cada nuevo mensaje añade más escritura. Una vez que la pizarra está llena, el modelo no puede añadir más, a menos que borres o resumas algo.

El límite estricto: por qué los modelos no pueden verlo todo

Cada LLM tiene un límite de ventana de contexto codificado, definido por su arquitectura. Por ejemplo:

Puedes consultar los límites en models.dev, una excelente referencia para comparar arquitecturas.

Entonces, ¿qué sucede cuando se excede ese límite?

Verás un error como «ventana de contexto excedida» o tu modelo simplemente se detendrá a mitad de la salida. Incluso una sola carga de archivo de gran tamaño o una base de código larga pueden hacer que se supere el límite.

Más grande no siempre es mejor

Intuitivamente, más memoria debería significar mejores resultados. En realidad, no es tan sencillo.

A medida que las ventanas de contexto crecen, el rendimiento suele degradarse, porque los modelos tienen dificultades para recuperar la información correcta de contextos masivos.

Esto se conoce como el «problema de la aguja en el pajar».

Cuando tu sesión contiene cientos de archivos o miles de líneas de conversación, la atención del modelo se dispersa. Tiende a dar demasiada prioridad a la información del principio y del final, mientras que los elementos que se encuentran en medio se pierden, un comportamiento que los investigadores denominan «efecto perdido en el medio».

Es similar a cómo los seres humanos recuerdan mejor lo que vino primero y lo que vino último, el sesgo de primacía y recencia, mientras que los detalles del medio se desvanecen.

Por eso, un contexto de 10 millones de tokens suena impresionante, pero a menudo funciona peor que una sesión reducida y centrada de 200 000.

Por qué es importante la gestión del contexto en la programación

Cuando se utiliza un agente de programación como Claude Code, Cursor o GitHub Copilot Workspace, el contexto lo es todo.

Cada comando, cada fragmento de código, cada ruta de archivo consume espacio dentro de esa ventana limitada.

El resultado:

• Cuanto más tiempo chateas sin reiniciar, más confusa se vuelve la memoria del agente.
• El rendimiento disminuye, especialmente en tareas que dependen de detalles de la conversación (como la refactorización o la depuración).

Para programar de forma eficaz con IA, debes gestionar el contexto de la misma manera que gestionas la memoria en un programa.

Cómo comprobar el uso del contexto en Claude Code

Veamos Claude Code, que ofrece una visibilidad clara del uso del contexto.

Ejecuta el comando:

context

Obtendrá un resultado similar al siguiente:

Context: 95k / 200k tokens used
System prompt: 8%
Messages: 40%
Files: 52%

Esto significa:

• Has utilizado 95 000 tokens del límite de 200 000 tokens.
• Aproximadamente el 8 % de tu ventana está ocupado por el mensaje del sistema.
• El 40 % por tus mensajes de chat.
• Y el resto por archivos u otros activos.

Una vez que te acercas a los 150 000 tokens, el modelo tiene menos «memoria de trabajo» disponible.

En este punto, es hora de borrar o compactar la conversación.

Borrar vs. compactar: cuándo usar cada uno

Claude Code ofrece dos formas de gestionar tu ventana de contexto.

1. clear

Este comando borra la conversación por completo, dejando una pizarra en blanco.

Úsalo cuando:

• Estás empezando una nueva tarea o archivo.
• El enfoque del proyecto ha cambiado.
• Has superado el 75 % de tu límite de contexto.

Es la forma más eficaz de restablecer el rendimiento y eliminar el «desorden contextual».

2. compactar

Este comando resume el chat existente, conservando la intención y liberando espacio.

Toma todos los mensajes anteriores, los destila en un breve resumen y sustituye el largo historial de chat por ese resumen. Por ejemplo, una conversación de 70 000 tokens puede reducirse a solo 4000 tokens.

Úselo cuando:

• Desee mantener el contexto general o el espíritu de un proyecto.
• Se encuentre a mitad de una larga sesión de programación y desee reducir el espacio ocupado.

Tenga en cuenta que la compactación consume tokens (ya que el resumen en sí mismo utiliza el modelo) y tarda uno o dos minutos en completarse.

Después de la compactación, compruébelo de nuevo con context. Debería ver algo como esto:

Context: 20k / 200k tokens used
Messages: 4k
Free space: 90%

Es una configuración mucho más ágil y rápida.

El peligro de los servidores MCP

Los servidores MCP (servidores de protocolo de contexto de modelo) son una gran idea en teoría: conjuntos de herramientas plug-and-play que proporcionan capacidades adicionales a su agente de codificación.

En la práctica, pueden saturar su ventana de contexto muy rápidamente.

Cada servidor añade:

• Una serie de indicaciones del sistema
• Definiciones de herramientas
• Metadatos o conjuntos de reglas

En poco tiempo, un tercio de todo su contexto habrá desaparecido antes incluso de que empiece a codificar.

Por eso, los usuarios experimentados evitan cargar servidores MCP innecesarios o, al menos, revisan cuáles mantienen activos.

Las configuraciones ligeras funcionan mejor.

¿Cuánto contexto es «demasiado»?

Como regla general:

• Manténgase por debajo del 70-80 % de su límite total.
• Restablece o compacta regularmente.
• Mantén tus indicaciones breves y específicas.
• No sobrecargues con reglas masivas o volcados de documentación.
• Prefiere referencias vinculadas o resúmenes en lugar de pegar archivos completos.

Cuando tu modelo parece lento, impreciso u olvidadizo, normalmente no es que se esté «volviendo más tonto».

Simplemente se está ahogando en contexto.

Evaluar los modelos de la manera correcta

Al comparar modelos, no se fije solo en el tamaño de la ventana de contexto.

Pregúntese: ¿qué tan bien recupera y utiliza la información dentro de esa ventana?

Por ejemplo, cuando Meta lanzó Llama 4 Scout con una ventana de 10 millones de tokens, las primeras pruebas mostraron graves problemas de pérdida en el medio.

Podía leer todo ese texto, pero no podía utilizarlo de manera eficaz.

Por el contrario, Claude 4.5 Sonnet, con una ventana más pequeña, suele funcionar mejor porque gestiona la recuperación de forma más inteligente.

Conclusión

La ventana de contexto no es solo un detalle técnico, es la base del funcionamiento de los agentes de codificación.

Cada token que añades compite por la atención.

La clave para obtener buenos resultados no es solo un modelo más grande, sino un contexto más limpio y ágil.

En resumen:

1. La ventana de contexto = todos los tokens de entrada + salida.
2. Cada modelo tiene un límite codificado.
3. Cuanto mayor sea el contexto, mejor será el rendimiento (cuidado con la pérdida de información en el medio).
4. Utiliza clear o compact en Claude Code para gestionar tu espacio.
5. Mantenga las configuraciones ágiles, especialmente con servidores MCP.

Una vez que domine la gestión del contexto, descubrirá que los agentes de codificación son mucho más fiables, consistentes y capaces de lo que la mayoría de la gente cree.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Anthropic ha realizado varios lanzamientos en los últimos días: Claude Code ya está disponible directamente en la aplicación Claude Desktop.

Para los desarrolladores que han estado utilizando Claude Code en la terminal, esto puede parecer una simple actualización para mayor comodidad. Pero, ¿qué supone para los millones de profesionales empresariales, gestores técnicos, analistas de datos y «desarrolladores ciudadanos» que nunca utilizan la línea de comandos? Se trata de un cambio de paradigma.

Permítanme explicarles por qué es importante y cómo pueden aprovecharlo hoy mismo.

¿Qué es Claude Code?

Claude Code es la herramienta de codificación agentica de Anthropic. A diferencia de los asistentes de IA tradicionales basados en chat, que solo sugieren fragmentos de código, Claude Code puede:

Leer y modificar toda su base de código (hasta 200 000 tokens de contexto)

Ejecutar tareas de codificación de varios pasos de forma autónoma: depuración, refactorización, pruebas, documentación

Trabajar con múltiples archivos y sistemas sin perder el contexto

Utilizar el modo Plan para investigar y elaborar estrategias antes de realizar cualquier cambio.

Ejecutar sesiones paralelas para diferentes tareas (un agente corrige errores mientras otro escribe pruebas).

Hasta ahora, para acceder a Claude Code se necesitaba:

1. Un entorno de terminal/CLI.
2. Conocimientos de línea de comandos.
3. Configuración técnica (variables de entorno, configuración de git, etc.).

Esa barrera ya no existe.

Novedades: Claude Code en el escritorio

Desde el 24 de noviembre de 2025, Claude Code está disponible en la aplicación Claude Desktop para Windows, macOS y Linux. Para muchos desarrolladores, se trata de una versión preliminar y muy simplificada del Claude Code que conocemos. Esto es lo que ofrece:

¿Quién puede acceder a él?

En qué se diferencia Claude Code Desktop de CLI

Para desarrolladores que ya utilizan CLI:

Idea clave: Desktop no sustituye a CLI, sino que la complementa. Los usuarios avanzados pueden empezar en Desktop y pasar a CLI cuando necesiten un control más detallado. La misma sesión puede moverse entre interfaces.

Para usuarios empresariales SIN acceso a CLI

Aquí es donde ocurre la magia. Antes, para usar Claude Code necesitabas:

# CLI Installation (not anymore!)
npm install -g @anthropic/claude-code
export ANTHROPIC_API_KEY=your_key
claude init

¿Ahora? Descargue la aplicación de escritorio, inicie sesión y comience a programar.

Ahora es posible crear escenarios del mundo real para usuarios sin conocimientos técnicos:

1. Gerentes de producto: «Analizar nuestros problemas de GitHub y priorizar el backlog de errores según su gravedad».
2. Analistas de datos: «Refactorizar este script de análisis de Python para manejar casos extremos y añadir registro de errores».
3. Redactores técnicos: «Revisa el código base y actualiza el README con los puntos finales de la API actuales».
4. Ingenieros de control de calidad: «Añade pruebas unitarias al flujo de pago que cubran los casos de fallo en el pago».
5. Analistas de negocio: «Crea un análisis competitivo recopilando información de estos 5 sitios web de la competencia».

Modo Plan: la función para empresas

El modo Plan merece una atención especial porque hace que Claude Code sea seguro para los usuarios empresariales.

¿Qué es el modo Plan?

El modo Plan separa la investigación/análisis de la ejecución. Cuando se activa (Shift+Tab dos veces en la CLI, o alternar en el escritorio):

• Claude puede leer archivos, buscar código y analizar la estructura
• Claude no puede escribir, editar ni ejecutar nada
• Claude presenta un plan detallado para su aprobación antes de realizar cualquier cambio

Por qué es importante para los usuarios empresariales

Preocupación tradicional: «¿Qué pasa si la IA estropea algo?».

Con el modo Plan:

1. Claude investiga su código base (solo lectura).
2. Claude propone una implementación paso a paso.
3. Usted revisa y aprueba antes de que ocurra nada.
4. Solo entonces Claude ejecuta.

Flujo de trabajo práctico: usuario de escritorio por primera vez

Así es como un usuario empresarial podría abordar su primera sesión de Claude Code Desktop:

Paso 1: Configuración (2 minutos)

1. Descargue Claude Desktop desde claude.ai/download
2. Inicie sesión con una cuenta Pro/Max/Team/Enterprise
3. Abra una nueva sesión de Claude Code

Paso 2: Conecte su proyecto

Opción A: Señale una carpeta local/repositorio git

Opción B: Conéctese a GitHub para sesiones remotas (disponible en modo nube)

Paso 3: Comience con el modo Plan

"I need to add error handling to our payment processing module. 
Enter Plan Mode and analyze the current implementation first."

Claude hará lo siguiente:

• Leerá los archivos pertinentes
• Identificará los patrones de gestión de errores existentes
• Mapeará las dependencias
• Propondrá un plan de implementación estructurado

Paso 4: Revisar y aprobar

• Revisar el plan de Claude
• Hacer preguntas aclaratorias
• Aprobar o solicitar modificaciones

Paso 5: Ejecutar

• Salir del modo Plan
• Claude implementa los cambios aprobados
• Revisar las diferencias
• Confirmar o revertir

El panorama general: por qué es importante esta versión

Claude Code en Desktop elimina la barrera de las «herramientas de desarrollo solo para desarrolladores». Esto se alinea con la tendencia general del sector de que la IA haga accesibles las capacidades técnicas a los expertos en la materia, independientemente de sus conocimientos de programación.

Conclusión

Claude Code en Claude Desktop no es solo una actualización de funciones, es la respuesta de Anthropic a la pregunta: «¿Cómo hacemos que la codificación agencial sea accesible para todos?».

Para los desarrolladores, es un flujo de trabajo más integrado y visual. Para los usuarios empresariales, es un permiso para participar en flujos de trabajo de codificación a los que antes no tenían acceso.

La línea de comandos no ha desaparecido. Pero ya no es un guardián.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

La primera vez que escuché la expresión «base de datos vectorial», pensé: «Oh, no, aquí viene la matemática que nunca voy a usar». Casi la omito. Pero la verdad es que ya te beneficias de esta idea todos los días. Cuando buscas en Google, cuando Netflix te recomienda una película que realmente te gusta o cuando Spotify te sugiere una canción que se adapta a tu estado de ánimo, es la búsqueda vectorial la que funciona silenciosamente detrás de escena.

Así que, si eres nuevo en esto, no te asustes. Iremos paso a paso. Piensa en esto como una guía amigable, no como un libro de texto.

Por qué las bases de datos normales no dan la talla

La mayoría de nosotros empezamos con bases de datos relacionales como MySQL o PostgreSQL. Son geniales para tablas: clientes, productos, facturas, lo que sea. Son rápidas y fiables.

Pero aquí está el problema. Solo saben comparar valores exactos. Si guardo «coche» en una columna y buscas «automóvil», la base de datos se queda en blanco. Cero filas.

Los seres humanos no funcionamos así. Si te pido un coche, probablemente me recomendarías un sedán, un SUV o incluso un Tesla. No te quedas atascado en la palabra exacta. Las máquinas sí.

Por eso necesitamos una nueva forma de almacenar y buscar datos, no solo por coincidencia de texto, sino por significado. Ahí es donde entran en juego las bases de datos vectoriales.

¿Qué es un vector?

Olvídate de las clases de matemáticas del instituto. En este contexto, un vector es simplemente una lista de números. Esos números representan algún objeto: una palabra, una frase, una imagen o incluso un clip de audio.

Veamos un ejemplo:

• La palabra «rey» podría ser [0,25; 0,88; -0,47; 0,91].
• La palabra «reina» podría ser [0,28; 0,90; -0,45; 0,92].

¿Ve lo cerca que están? Eso se debe a que ambas tienen un significado similar. Por otro lado, el vector de «coche» será totalmente diferente, ya que se encuentra muy lejos en este «espacio de significado» invisible.

Pensemos en ello como ciudades en un mapa. Nueva Delhi y Noida están cerca una de otra. Nueva Delhi y Bombay no lo están. Del mismo modo, rey y reina están cerca, pero rey y coche no lo están.

¿De dónde proceden estos vectores?

No los escribimos a mano. Eso sería una locura. En su lugar, utilizamos modelos de aprendizaje automático para hacer el trabajo pesado. Estos modelos que generan los vectores se denominan modelos de incrustación. Se utilizan para traducir los datos sin procesar en números. Los datos sin procesar pueden ser de cualquier tipo, como texto, audio, imagen o vídeo.

Así que el proceso es el siguiente:

1. Proporcionamos los datos como una fuente (por ejemplo, una frase como «Me encanta la pizza»).
2. A continuación, el modelo de incrustación genera un vector, realizado por el modelo vectorial utilizado (tal vez [0,12; -0,33; 0,95; ...]).
3. El vector generado se almacena en una base de datos vectorial.

Ahora, cada dato, ya sea texto, imagen o audio, tiene una «huella digital de significado» en números, y estos números son los vectores.

Búsqueda por palabra clave frente a búsqueda por significado

Imagina que estás creando una aplicación de recetas.

• Un usuario busca «pasta con queso».
• Una base de datos SQL normal solo encuentra recetas que contienen literalmente esas palabras.

Pero, ¿qué pasa con las recetas que dicen «espaguetis fritos» o «macarrones con queso cheddar»? Un humano reconocería esas recetas como coincidencias. La base de datos SQL no lo haría, ya que compara la entrada con los datos almacenados y solo recupera los resultados que coinciden perfectamente.

Una base de datos vectorial, por otro lado, ve el panorama general. Sabe que el parmesano es un queso, que los espaguetis son una pasta y que los macarrones pertenecen a la misma familia. Por lo tanto, la búsqueda funciona como tu cerebro: encuentra recetas que significan lo mismo, no solo aquellas que se escriben de la misma manera.

¿Cómo hace una base de datos vectorial para que las búsquedas sean rápidas?

Buena pregunta. Si solo tienes 100 vectores, puedes compararlos todos. Fácil. Pero, ¿y si tienes 10 millones?

Normalmente, en las bases de datos SQL utilizamos indexación como B-Tree o Hash para acelerar la búsqueda, y en las bases de datos NoSql utilizamos índices secundarios o compuestos.

Para las bases de datos vectoriales, la fuerza bruta es demasiado lenta. Por eso, las bases de datos vectoriales utilizan trucos inteligentes como la búsqueda Approximate Nearest Neighbor (ANN). No te pierdas en el nombre. La idea es la siguiente:

Imagina que estás en una fiesta tratando de encontrar a tu mejor amigo. En lugar de escanear cada rostro, te diriges directamente al grupo con el que suele estar. Así ahorras tiempo. ANN hace lo mismo: construye estructuras (gráficos o árboles) para poder saltar directamente a las coincidencias probables sin tener que comprobarlo todo.

¿Qué bases de datos vectoriales deberías conocer?

Si empiezas a buscar en Google, verás aparecer estos nombres:

• Pinecone: totalmente gestionada, no tienes que preocuparte por la infraestructura.
• Weaviate: código abierto, buena documentación, ideal para principiantes.
• Milvus: muy utilizada en sistemas de producción, diseñada para escalar.
• FAISS: una biblioteca de Meta, más básica, ideal para aprender la mecánica.

Para un proyecto paralelo, Pinecone o Weaviate parecen menos abrumadores. FAISS es buena si quieres jugar con las matemáticas que hay detrás y también es compatible con la CPU.

Un ejemplo con una película

Este siempre gusta a la gente. Supongamos que estás creando una aplicación de recomendaciones de películas.

1. Incorporas descripciones de todas tus películas: resúmenes de la trama, géneros, quizá incluso críticas.
2. Un usuario escribe «película de ciencia ficción sobre viajes espaciales y familia».
3. Esa consulta se convierte en un vector.
4. La base de datos busca vectores de películas similares.
5. Los resultados: Interstellar, The Martian, Gravity.

¿Te das cuenta de algo? El usuario no ha escrito esos títulos exactos. El sistema los ha encontrado igual que las recomendaciones de Netflix o la búsqueda de vídeos de YouTube porque los vectores han captado la idea de «ciencia ficción + espacio + temas familiares».

¿Dónde vemos esto en el mundo real?

Ya lo has experimentado.

• Chatbots: cuando un bot responde a partir de los documentos de tu empresa, busca en una base de datos vectorial para encontrar secciones relevantes.
• Motores de búsqueda: Google ya no se limita a buscar palabras clave, sino que interpreta tu intención.
• Compras: Amazon recomienda artículos «similares» en significado a los que has visto.
• Streaming: Spotify sugiere canciones que se ajustan a tu estado de ánimo. YouTube pone en cola los vídeos que probablemente verás a continuación.
• Seguridad: los bancos comprueban si tu transacción es similar a otras «normales» anteriores o si es sospechosamente diferente.

Una vez que lo ves, no puedes dejar de verlo. La búsqueda vectorial está en todas partes.

Cómo probarlo si eres principiante

Aquí tienes una forma sencilla que ojalá alguien me hubiera enseñado antes:

1. Juega con las incrustaciones: utiliza la API de incrustaciones de OpenAI (barata y fácil). Escribe frases y observa los vectores.
2. Ejecuta FAISS localmente: almacena unos cientos de vectores, búscalos y observa los resultados.
3. Prueba una opción alojada: Pinecone tiene un nivel gratuito. Weaviate también.
4. Crea una pequeña aplicación: puede ser un buscador de notas, un buscador de recetas o incluso un chatbot personal. Los proyectos pequeños muestran la magia.

No intentes aprenderlo todo de una vez. Empieza poco a poco y luego ve creciendo.

Algunos consejos personales

• No te quedes atascado con las fórmulas matemáticas. Si tienes curiosidad, apréndelas más adelante.
• Incluso 50 ejemplos son suficientes para ver cómo funciona la búsqueda vectorial.
• Visualiza. Utiliza una herramienta para trazar vectores en 2D: verás cómo se forman grupos de forma natural.
• Si quieres profundizar más, lee sobre la similitud coseno. Esa es la «medida de distancia» que utiliza la mayoría de la gente.

Las bases de datos vectoriales dan miedo hasta que te das cuenta de que solo son una forma de almacenar significado. No sustituyen a tu base de datos SQL o NoSQL. Se sitúan junto a ellas, añadiendo un nuevo superpoder: la comprensión.

Si está empezando su andadura como desarrollador, aprenda esto desde el principio. No es una moda pasajera. Es lo que hace que las aplicaciones modernas parezcan inteligentes. Y una vez que haya visto una búsqueda que entiende el significado en lugar de las palabras, es difícil volver atrás...

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Otra cosa que puedo predecir para el próximo año. Esta vez analicé a los 180 millones de desarrolladores para responder a la pregunta que os tiene en vilo:

¿Sustituirá la IA a los desarrolladores en 2026?

Para ello, necesitaba muchos datos. Recopilé datos de GitHub, estadísticas de empleo de la BLS, rastreadores de despidos en el sector tecnológico y plataformas de autónomos. Crucé los datos de tendencias de los últimos cinco años y llegué a esta conclusión...

La respuesta es mucho más interesante que «sí» o «no».

La pregunta que todos se están haciendo es errónea

Hace unos meses, el director ejecutivo de Anthropic dijo que la IA escribiría «TODO el código» para 2026. Un exejecutivo de Google afirma que el 90 % del código será generado por la IA. Las señales claras eran que los desarrolladores quedarían obsoletos.

Pero los datos reales de GitHub muestran algo completamente diferente →

¡180 millones de desarrolladores en todo el mundo en este momento! Frente a los 144 millones de finales de 2024.

36 millones de nuevos desarrolladores en UN AÑO.

Si la IA está sustituyendo a los desarrolladores, ¿por qué está explotando la población de desarrolladores?

Ahí es donde creo que tengo que comprobar los datos. Esto es lo que muestran para 2026:

• Caso base (probabilidad del 50 %): 210 millones de desarrolladores en todo el mundo (±20 millones)
• Alta (probabilidad del 25 %): 230-250 millones de desarrolladores
• Baja (probabilidad del 20 %): 180-190 millones de desarrolladores

Incluso en el escenario bajo (en el que la tecnología se enfrenta a otra contracción), estamos hablando de MÁS desarrolladores, no menos...

• Escenario del cisne negro (5 % de probabilidad): en el que algún avance catastrófico en IA o alguna regulación colapsa realmente la mano de obra de desarrolladores; es estadísticamente posible, pero requiere que se alineen múltiples eventos improbables.

Pero lo que realmente muestran los datos

Matemáticas.

1. La IA está creando desarrolladores, no sustituyéndolos

El 83 % de los desarrolladores utilizó ChatGPT durante el último año. GitHub informa de que el 80 % de los nuevos desarrolladores prueba Copilot durante su primera semana.

: GitHub registró aproximadamente 1000 millones de commits en 2025 (un aumento del 25 % con respecto al año anterior). ¡Los desarrolladores realizaron 5200 millones de contribuciones a 518 millones de proyectos solo en 2025!

La pregunta es: si la IA estuviera sustituyendo a los desarrolladores, ¿por qué se está disparando la producción de código?

La IA está haciendo que los desarrolladores sean más productivos, no que queden obsoletos.

En resumen, un desarrollador en solitario con IA puede ahora entregar lo que antes requería un equipo de tres personas.

Los proyectos que me llevaban 40 horas en 2023 me llevan 18 horas en 2025. La misma calidad. La mitad del tiempo.

Eso no es sustitución. Es multiplicación.

2. Se está sustituyendo a los desarrolladores equivocados

Pero hay algo inquietante en estos datos...

Despidos en el sector tecnológico: 239 000 en 2024. 210 000 en 2025. Casi medio millón de personas despedidas.

Pero no fueron los desarrolladores que utilizaban la IA. Fueron los que no la utilizaban.

La Oficina de Trabajo sigue proyectando un crecimiento del 15 % en los puestos de trabajo de desarrolladores de software entre 2024 y 2034. Eso es a lo largo de toda la década, solo alrededor del 1,5 % anual.

Así que los desarrolladores SÍ están siendo sustituidos. Pero no directamente por la IA.

3. El mercado laboral se está dividiendo en dos

Empleo tradicional: se espera un crecimiento del 5-10 % para 2026.

Desarrolladores autónomos/independientes: el 40 % de la población activa de EE. UU. para 2026 (frente al 36 % actual).

Los contratistas independientes a tiempo completo se duplicaron en 4 años:

• 2020: 8,2 % (13,6 millones de personas)
• 2024: 16,7 % (27,7 millones de personas)

Suponiendo que, según la trayectoria actual, alcance el 40 % a finales de 2026. A medida que la IA hizo viable el trabajo en solitario

4. El «no código» es un síntoma

Mercado de bajo código/sin código → 32 000 millones de dólares. Previsión → 45 000-50 000 millones de dólares para 2026.

Gartner prevé que el 75 % de las nuevas aplicaciones empresariales utilizarán algún tipo de bajo código/sin código a finales de 2026.

Todos os asustáis por esto. «¡Bubble.io nos sustituirá!».

Pero mirad los datos reales:

El 70 % de las nuevas aplicaciones ya utilizan herramientas LCNC en 2025. Sin embargo, el número de desarrolladores aumentó en 36 millones.

Lo he comprobado yo mismo.

Creé el mismo panel de control en Bubble y Next.js para un cliente. Bubble tardó 6 horas. Next.js tardó 18 horas. El cliente eligió Next.js. ¿Por qué? Porque con más de 10 000 usuarios, los costes unitarios de carga de trabajo de Bubble alcanzarían los 400-600 dólares al mes. ¿Next.js? 75 dólares al mes fijos.

El no-code es perfecto para los MVP. Pero cuando las aplicaciones crecen, se necesitan desarrolladores reales.

No es un reemplazo. Es especialización.

Tres escenarios de reemplazo

Según mi análisis, así es como la IA afectará realmente a los desarrolladores en 2026:

1. Caso base (probabilidad del 50 %): reestructuración, no sustitución

• 210 millones de desarrolladores en todo el mundo (frente a los 180 millones actuales)
• Crecimiento del empleo tradicional del 5-10 %
• 40 % de trabajo autónomo/independiente
• La IA se convierte en una herramienta estándar (como Git o VS Code)
• Los puestos junior se reducen entre un 20 % y un 30 %, mientras que los puestos senior se amplían.
• Aumenta la especialización (ingenieros de IA, especialistas en plataformas).

Los desarrolladores se centran en la arquitectura, la integración y la optimización. Mayor rendimiento por persona. Más desarrolladores en general.

2. Ventaja (25 % de probabilidad): la IA crea desarrolladores 📈

• 230-250 millones de desarrolladores en todo el mundo
• La grave escasez de talento impulsa la adopción de la IA
• El 50 % de la mano de obra trabaja por cuenta propia
• La IA facilita el aprendizaje de la programación = más personas cambian de carrera
• La economía de plataformas se dispara hasta alcanzar entre 1,6 y 1,8 billones de dólares

La IA democratiza el desarrollo. Las personas sin conocimientos técnicos se convierten en «desarrolladores ciudadanos». Los desarrolladores tradicionales ascienden al mercado de la arquitectura de sistemas.

3. Desventaja (probabilidad del 20 %): contracción, pero no colapso

• 180-190 millones de desarrolladores (sin cambios o con un ligero descenso)
• Una gran recesión recorta el gasto en tecnología
• Las empresas dependen excesivamente de la IA y crean deuda técnica
• Solo el 30 % trabaja por cuenta propia debido a la presión regulatoria
• El empleo tradicional se estabiliza, pero los salarios se comprimen

Las empresas intentan sustituir a los desarrolladores por IA. Fracasan estrepitosamente. Vuelven a contratar a precios más bajos. El mercado se corrige en un plazo de 2 a 3 años.

¿Quién es realmente reemplazado?

30 % inferior | 50 % medio | 20 % superior

[ Desarrolladores junior que se dedican exclusivamente a la implementación — INFERIOR

Desarrolladores de nivel medio que se adaptan a los flujos de trabajo de IA — MEDIO

Arquitectos que diseñan sistemas complejos — SUPERIOR]

Cómo estoy jugando realmente a esto

La IA es mi multiplicador, no mi sustituto

1. Posicionamiento para la complejidad
2. Freelance + IA = Negocio individual viable
3. Comprender los datos del mercado

En 2026, habrá MÁS desarrolladores. Simplemente estarán haciendo un trabajo diferente. ¿Los trabajos de implementación junior? Desaparecerán. ¿El trabajo senior de arquitectura y sistemas? Explotará.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Si llevas bastante tiempo programando en Python, probablemente hayas notado algo incómodo:

Algunos desarrolladores con habilidades medias ganan mucho dinero.

Otros, que son auténticos monstruos, apenas llegan a pagar el alquiler.

La diferencia no es el porno de trabajo duro ni un Discord secreto. Es el apalancamiento.

Después de más de cuatro años trabajando con Python en producción (automatización, datos, infraestructura, cosas aburridas que realmente hacen funcionar a las empresas), he visto cómo los desarrolladores ganan dinero discretamente fuera de sus salarios. Sin miniaturas de YouTube. Sin tonterías del tipo «gané 10 000 dólares en 30 días».

Solo sistemas que se acumulan.

Hablemos de los reales.

1. Vender automatización aburrida (también conocida como «He solucionado un dolor de cabeza que odias»)

Los scripts mejor pagados que he escrito no eran ingeniosos.

Eran eliminadores de molestias.

Ejemplos que realmente se venden:

• Importadores CSV → ERP
• Scripts de conciliación de Excel
• Analizadores de registros que ahorran horas a los equipos de cumplimiento
• «Código de enlace» entre dos API horribles

Nadie presume de ellos en Twitter. Los directores financieros los pagan de todos modos.

Por qué funciona

Según McKinsey, los empleados dedican entre el 20 % y el 30 % de su tiempo a tareas repetitivas. Si tu script ahorra 10 horas al mes a un equipo de 10 personas, no es un script, es una reducción de la nómina.

Cómo lo comercializas (esfuerzo mínimo)

# automation_cli.py
import argparse
from reconciler import run

parser = argparse.ArgumentParser()
parser.add_argument("--input")
parser.add_argument("--output")
args = parser.parse_args()
run(args.input, args.output)

• Envuélvelo en una CLI
• Añade registro
• Añade un README
• Cobra entre 500 y 5000 dólares una sola vez

Consejo profesional: véndelo a operaciones, no a ingenieros. Los ingenieros quieren elegancia. Las operaciones quieren silencio.

2. SaaS especializado que resuelve un problema embarazoso

Olvídate de «crear el próximo Notion».

Las ideas rentables de SaaS son dolorosamente específicas:

• «Avisarme cuando cambie este PDF del gobierno».
• «Decirme cuándo se actualiza el stock de este proveedor».
• «Normalizar los CSV de 12 proveedores en un solo formato».

Estas ideas parecen estúpidas hasta que te das cuenta de que las empresas pagan mensualmente para evitar tener que comprobarlo manualmente.

La ventaja de Python

Puedes enviar algo feo, rápido y fiable.

# monitor.py
import hashlib, requests, time

def fingerprint(url):
    return hashlib.md5(requests.get(url).content).hexdigest()
prev = fingerprint(URL)
while True:
    time.sleep(3600)
    curr = fingerprint(URL)
    if curr != prev:
        notify()
        prev = curr

Eso es todo. Ese script ha hecho ganar dinero a mucha gente.

La realidad

La mayoría de los SaaS independientes rentables ganan entre 1000 y 5000 dólares al mes.

No es dinero para derrochar. Es dinero para pagar el alquiler de por vida.

3. Código abierto de pago (sin vender tu alma)

El código abierto no da dinero, a menos que lo diseñes para ello.

Desarrolladores inteligentes:

• Haz que el núcleo sea de código abierto
• Cobra por el alojamiento, la comodidad o el cumplimiento normativo.

Ejemplos:

• Versión alojada
• Funciones empresariales
• Contratos de SLA y asistencia técnica

Patrón que funciona

def advanced_feature():
    if not license_valid():
        raise RuntimeError("Enterprise license required")

Sí, es así de aburrido.

GitHub informa que más del 70 % de las empresas dependen del OSS en la producción. Pagarán para reducir el riesgo, no por las funciones.

Consejo profesional: tu README es tu página de ventas. Escríbelo como tal.

4. Herramientas internas para otras empresas (freelance, pero más inteligente)

La mayoría de los autónomos venden horas.

Los más inteligentes venden la transferencia de propiedad.

En lugar de:

«80 $/hora»

Di:

«4000 $ por una herramienta que sustituye este flujo de trabajo manual».

El mismo código. Un enfoque diferente. El triple de dinero.

Conjunto típico de herramientas internas

• Backend Python
• SQLite/Postgres
• Cron
• Una interfaz de usuario fea que nadie ve

# nightly_job.py
from jobs import process_all

if __name__ == "__main__":
    process_all()

Sin escalado. Sin microservicios. Sin cosplay de Kubernetes.

Solo valor.

5. Productos de datos (la mina de oro silenciosa)

Los datos con los que ya trabajas pueden monetizarse:

• Conjuntos de datos limpios
• Puntos de referencia
• Agregaciones específicas del sector

La gente no paga por los datos.

Paga por no tener que recopilarlos ella misma.

Ejemplo

Si recopilas y normalizas datos públicos semanalmente:

def normalize(rows):
    return [
        {
            "id": r["id"],
            "value": float(r["raw"].replace(",", ""))
        }
        for r in rows
    ]

Empaquétalo. Actualízalo. Vende el acceso.

Hechos:

• Se prevé que la economía global de datos supere los 400 000 millones de dólares en 2030.
• La mayor parte es aburrida, estructurada e invisible.

6. Enseñar, pero solo después de haber sangrado

Los cursos no se pagan por las diapositivas.

Se pagan por las historias de guerra.

La única formación para desarrolladores que se vende a largo plazo:

• «Así es como rompí la producción».
• «Por eso fracasó esta elegante solución».
• «Esto es lo que eliminaría si reescribiera este sistema».

Si has depurado sistemas reales a las 2 de la madrugada, ya tienes contenido.

Idea para una herramienta de enseñanza

Crea un repositorio que contenga errores intencionados y luego explícalos.

# subtle_bug.py
cache = {}

def get_user(id):
    if id in cache:
        return cache[id]
    user = load_from_db(id)
    cache[id] = user
    return user

Ahora explica las fugas de memoria, la invalidación de la caché y por qué esto provocó la caída de un servidor.

Eso es valor.

7. Licenciar tu tiempo sin venderlo

Esto es poco habitual y muy poderoso.

Tú:

• Creas una herramienta
• La licenciás por empresa
• Incluís X horas de actualizaciones al año

No eres un empleado.

No eres un contratista.

Eres una dependencia.

Las empresas odian sustituir las dependencias.

La incómoda verdad

La mayoría de los desarrolladores nunca ganan dinero fuera de sus salarios porque:

• Optimizan para la inteligencia
• Evitan las conversaciones de ventas
• Subestiman lo valioso que es lo «aburrido»

Los desarrolladores mejor pagados que conozco escriben código que nadie retuitea.

Resuelven un problema en profundidad.

Lo empaquetan.

Siguen adelante.

Sin gurús. Sin embudos. Sin urgencias falsas.

Solo Python. En el mundo real.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Hay una sensación específica que se tiene al revisar código asistido por IA después de haberlo hecho durante mucho tiempo.

No es que esté mal, exactamente. El código funciona. Pero hay una especie de... monotonía. Cada función está optimizada para su propósito inmediato, sin tener en cuenta nada más allá de su propio ámbito. Es correcto en todos los aspectos que las herramientas pueden verificar. Sutilmente defectuoso en todos los aspectos que solo salen a la luz seis meses después, cuando alguien intenta ampliarlo.

Llevo dos años persiguiendo esa sensación, tratando de articular lo que me molesta del código que pasa todas las comprobaciones automáticas, pero que sigue incomodando a los ingenieros experimentados.

Las ganancias en productividad son reales. Las plantillas que antes llevaban una tarde, ahora se hacen en minutos. Se gestionan los casos extremos. Se genera la documentación. Mi equipo entrega más rápido que nunca. Las métricas de velocidad harían sonreír a cualquier director de ingeniería en una revisión trimestral.

Pero el código se acumula en la base de código como sedimentos. Cada módulo generado por IA es una pequeña isla, conectada al resto del sistema por los puentes más delgados posibles. No hay comunicación entre los componentes. No hay un lenguaje arquitectónico compartido. Solo una colección creciente de características que coexisten en el mismo repositorio.

No soy el único que lo nota. Y los datos están empezando a confirmar lo que muchos de nosotros hemos sentido.

Lo que revelaron 300 repositorios sobre el punto ciego de la IA

Ox Security analizó recientemente más de 300 repositorios de código abierto, incluidos 50 que fueron generados total o parcialmente por IA. Los resultados pusieron en palabras algo que había estado intuyendo en las revisiones de código durante meses.

Lo llaman el efecto «Ejército de juniors»: la IA produce código que es muy funcional, pero que carece sistemáticamente de criterio arquitectónico. El código funciona. Simplemente no piensa.

Diez antipatrones críticos aparecieron con una frecuencia alarmante. Los comentarios en línea excesivos abarrotaban entre el 90 % y el 100 % de los proyectos generados por IA, comentarios que aumentan el ruido sin mejorar la claridad. Más revelador aún: entre el 80 % y el 90 % mostraban «evitación de refactorizaciones». La IA nunca mejora arquitectónicamente el código existente. Solo añade. Y en el 70-80 % de los proyectos, los errores idénticos seguían repitiéndose porque la IA viola los principios básicos de reutilización de código. El mismo error, copiado en nuevos contextos, una y otra vez.

El análisis de GitClear de 211 millones de líneas de código de 2020 a 2024 proporciona la base cuantitativa. La rotación de código (el porcentaje de líneas revertidas o actualizadas en dos semanas) se ha duplicado desde que se disparó la adopción de la IA. La refactorización se redujo del 25 % a menos del 10 % de todos los cambios de código. Los bloques de código copiados y pegados se multiplicaron por ocho.

Esa última cifra me impactó. Lo he visto ocurrir en mi propio equipo. Cuando la IA genera una solución, los desarrolladores la aceptan. Cuando aparece un problema similar en otro lugar, la IA genera una solución similar. Nadie consolida. Nadie abstrae. La base de código crece lateralmente en lugar de hacia arriba.

Nos dicen que se trata de un problema de herramientas. Mejores indicaciones. Mejores modelos. Mejores procesos de revisión. Y, sin duda, eso ayuda.

Pero cada vez estoy más convencido de que la verdadera crisis no es el código que estamos lanzando hoy. Son los desarrolladores para los que no estamos desarrollando para el mañana.

La paradoja de la productividad que nadie quiere reconocer

Aquí es donde la cosa se pone incómoda.

METR, una organización sin ánimo de lucro dedicada a la evaluación de la IA, ha llevado a cabo recientemente lo que podría ser el estudio de productividad más riguroso hasta la fecha. Reclutaron a 16 desarrolladores de código abierto con experiencia en proyectos masivos con más de 22 000 estrellas y más de un millón de líneas de código, y luego realizaron un ensayo controlado aleatorio con 246 tareas.

Los desarrolladores que utilizaban IA eran un 19 % más lentos que los que trabajaban sin ella.

Pero aquí está el giro: antes de empezar, esos mismos desarrolladores predijeron que la IA les haría un 24 % más rápidos. Después de completar las tareas, estimaron que habían sido un 20 % más rápidos. No podían decir que fueran más lentos. Las herramientas parecían productivas incluso cuando no lo eran.

Reconozco esta sensación. Hay algo satisfactorio en ver aparecer el código en la pantalla, en las sugerencias rápidas, en la sensación de impulso. Se siente como un progreso. Si es un progreso depende de lo que suceda cuando ese código deba ser mantenido, ampliado o depurado por alguien que no lo haya escrito.

La encuesta de Stack Overflow de 2025 a 49 000 desarrolladores refuerza este patrón. ¿Cuál es la principal frustración con las herramientas de IA? El 66 % cita soluciones que son «casi correctas, pero no del todo». La confianza se ha erosionado significativamente: solo el 33 % confía ahora en los resultados de la IA, frente al 43 % del año pasado. La desconfianza activa aumentó del 31 % al 46 %.

La brecha entre la percepción y la realidad puede ser el hallazgo más peligroso de todos. Si los desarrolladores se sienten productivos mientras acumulan deuda, seguirán acumulándola. Si los líderes ven que las métricas de velocidad suben, lo celebrarán. Los problemas permanecen invisibles hasta que dejan de serlo.

La mitad funciona. La otra mitad podría ser peor.

Múltiples estudios independientes coinciden en una cifra preocupante: aproximadamente entre el 40 % y el 50 % del código generado por IA contiene vulnerabilidades de seguridad.

El Centro de Seguridad y Tecnología Emergente de Georgetown probó cinco LLM líderes y descubrió que casi la mitad de los fragmentos de código producidos contenían errores que podían dar lugar a un uso malicioso. Veracode probó más de 100 LLM en 80 tareas de finalización y descubrió que el 45 % producía las 10 vulnerabilidades principales de OWASP. El código Java fue el que peor resultado obtuvo, con una tasa de fallos de seguridad del 70 %.

La investigación de Stanford añade una dimensión psicológica que me quita el sueño. En un estudio controlado, los participantes con acceso a IA escribieron código significativamente menos seguro en cuatro de las cinco tareas. Más preocupante aún: los usuarios de IA eran más propensos a creer que habían escrito código seguro. Una falsa confianza que agrava el riesgo técnico.

Pienso en esto cuando reviso las relaciones públicas. El desarrollador que envía el código cree que es sólido. La IA que lo generó no tiene ningún concepto de creencia. Y yo soy la última línea de defensa, buscando problemas en el código escrito por un proceso optimizado para la plausibilidad en lugar de la corrección.

La velocidad lo empeora. Como dijo el vicepresidente de investigación de Ox Security: ahora se pueden crear aplicaciones funcionales más rápido de lo que los humanos pueden evaluarlas adecuadamente. Hemos creado una velocidad que supera nuestra capacidad de verificación.

La pregunta que nadie en el liderazgo quiere responder

Esto es lo que me sigue rondando la cabeza, la pregunta que hace que esto sea más que un problema técnico:

Si automatizamos las tareas que solían formar a los ingenieros junior: las plantillas, las correcciones de errores, las pequeñas funciones que les enseñaban cómo funcionan realmente los sistemas. ¿Quién desarrollará la intuición arquitectónica para mantener estos sistemas dentro de cinco años? ¿Y dentro de diez?

Las cifras son contundentes. Según Revelio Labs, las ofertas de empleo tecnológico para principiantes han disminuido un 35 % desde enero de 2023. Stanford analizó los datos de nóminas de ADP y descubrió algo incómodo: hay un 16 % menos de desarrolladores de entre 22 y 25 años empleados que a finales de 2022. Cuando siete de cada diez responsables de contratación creen que la IA puede encargarse del trabajo de los becarios, el descenso empieza a tener sentido.

El modelo tradicional de aprendizaje se está fracturando. La IA ahora se encarga de las tareas que históricamente realizaban los junior: generación de plantillas, corrección de errores sencillos, documentación, creación de casos de prueba. El trabajo aburrido. El trabajo que te enseña cómo funcionan realmente las bases de código, cómo las decisiones se propagan por los sistemas, por qué existe ese patrón extraño en el código heredado y qué se rompe si lo cambias.

Charity Majors, directora de tecnología de Honeycomb, lo expresó con precisión:

«Al no contratar y formar a ingenieros junior, estamos canibalizando nuestro propio futuro».

Nos estamos comiendo las semillas. Optimizamos la cosecha de este trimestre, pero nos aseguramos de que no haya nada que plantar el año que viene.

McKinsey prevé una importante escasez de desarrolladores senior para 2030 si continúan las tendencias actuales. No es una exageración. Es aritmética. Si las empresas dejan colectivamente de formar a desarrolladores principiantes porque la IA se encarga de sus tareas tradicionales, la cantera que produce ingenieros de nivel medio y senior simplemente dejará de existir.

Por qué las organizaciones no ven lo que se avecina

He asistido a suficientes reuniones de planificación como para entender por qué sigue ocurriendo esto.

La velocidad es visible. El deterioro arquitectónico es invisible, hasta que deja de serlo. Las métricas de adopción de la IA son las que siguen los directivos. La deuda técnica no aparece en los balances. Las personas que ven el problema con mayor claridad, los colaboradores sénior que revisan el código a diario, no controlan los presupuestos.

Y hay un desajuste temporal que empeora aún más las cosas. Las ventajas de las herramientas de codificación de IA son inmediatas: relaciones públicas más rápidas, más funciones incorporadas, cifras trimestrales impresionantes. Los costes se aplazan: bases de código que se resisten a las modificaciones, incidentes de seguridad que aún no han ocurrido, una cantera de talentos que se está agotando silenciosamente.

La cultura de la permanencia corta en el cargo amplifica el problema. El ejecutivo tecnológico medio permanece en su puesto entre tres y cuatro años. La deuda técnica que se está creando ahora vencerá en cinco o siete años. Las personas que toman las decisiones hoy no estarán ahí cuando llegue el momento de pagar la factura.

El profesor del MIT Armando Solar-Lezama lo cristalizó:

«La IA es como una tarjeta de crédito nueva que nos va a permitir acumular deuda técnica de formas que nunca antes habíamos podido hacer».

Todos sabemos cómo funciona la deuda de las tarjetas de crédito.

Los pagos mínimos parecen manejables hasta que, de repente, dejan de serlo.

Lo que haría de otra manera

No tengo un marco que ofrecerles. Pero si tuviera que crear las prácticas de IA de un equipo desde cero, empezaría por aquí.

Haga un seguimiento de las métricas que importan más que la velocidad: tasa de rotación de código, hallazgos de seguridad por sprint, tiempo de depuración del código asistido por IA frente al código escrito por humanos. Las cifras pueden ser aleccionadoras, pero al menos las estarías viendo.

Protege explícitamente los puestos de desarrollador junior. No como caridad, sino como inversión. Cuando alguien sugiera que «basta con usar IA para eso», pregunta quién va a entender este sistema lo suficientemente bien como para arreglarlo en 2028. A ver si se hace el silencio en la sala.

Trata el código generado por IA como el código de un contratista brillante pero sin contexto. Necesita revisión. Necesita pruebas. Necesita a alguien que entienda el sistema para evaluar si esta solución técnicamente correcta es realmente la solución adecuada para tu arquitectura. La IA se encarga de la implementación; los humanos se encargan del juicio.

Y sé más honesto en las revisiones de código. Cuando algo te parezca mal, esa monotonía que mencioné al principio, no lo apruebes solo porque las pruebas hayan salido bien. Señálalo. Haga preguntas. A veces se equivocará y el código estará bien. Pero la conversación en sí misma es importante. Obliga a los equipos a articular principios arquitectónicos que, de otro modo, permanecerían implícitos.

La factura siempre llega

No dejo de pensar en la capitalización. En las tarjetas de crédito. En las semillas de maíz.

Todos los atajos tienen un coste. La única pregunta es cuándo lo pagará. Las organizaciones que invierten ahora en el juicio humano: en formación, en revisión de código, en el lento trabajo de desarrollar la intuición arquitectónica. Ellas serán las dueñas del futuro. Las que se optimizan únicamente por la velocidad están construyendo otra cosa. Algo que parece impresionante desde fuera, se envía rápidamente y satisface las métricas trimestrales.

Algo que nadie sabrá cómo arreglar cuando se rompa.

Algunos equipos están construyendo catedrales. Otros están construyendo fachadas. La diferencia no será visible durante años.

Pero se hará visible.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Rápida: los 15 hábitos (para que sepas lo que te espera)Quieres mejorar. Bien. Eso significa dejar de decir tonterías y corregir los hábitos que te hacen poco confiable, lento y molesto en el trabajo. A continuación te ofrecemos una guía práctica y totalmente optimizada que explica por qué cada hábito es perjudicial y qué hacer exactamente en su lugar. Deja de leer como un turista y empieza a actuar como alguien que ofrece calidad.

1. No usar control de versiones, o usarlo como si fuera basura
2. Nombres horribles: tonterías de una sola letra
3. Sin pruebas automatizadas o pruebas frágiles
4. Saltarse las revisiones de código o ignorar los comentarios
5. Duplicaciones frecuentes por copiar y pegar
6. Manía por la optimización prematura
7. Deja que la deuda técnica pueda tu código base
8. Cero documentación, README vacío
9. Mensajes de confirmación basura que no tienen sentido
10. Compilaciones e implementaciones manuales que viven en el pasadoSobrediseño: hacer demasiado antes de que sea necesarioTragarse los errores y registros terriblesNegarse a aprender y quedarse estancadoTrabajar sin parar hasta agotarse
11. Ignorar la seguridad : secretos codificados y sin validación

Ahora analizamos cada uno de ellos, explicamos por qué te perjudican y ofrecemos soluciones directas y prácticas.

1) No utilizar el control de versiones, o utilizarlo como si fuera basura

No puedes saltarte Git. Si tu flujo de trabajo consiste en carpetas locales, parches por correo electrónico o commits únicos llamados «final», estás perdido. El control de versiones es la forma en que los equipos se coordinan, deshacen errores y comprenden el historial.

Solución: Utiliza Git para todos los proyectos. Realiza confirmaciones pequeñas y específicas. Utiliza ramas de características y solicitudes de extracción. Protege las ramas principales con comprobaciones de CI. Aprende a revertir, seleccionar y rebasar sin destruir el historial.

2) Nombres horribles

Si tus variables son x, tmp, data1, te mereces la confusión. Los nombres pobres son un impuesto invisible para todos los desarrolladores futuros y para tu yo futuro.

Solución: Ponle un nombre con intención, no por ser el más corto de escribir. Prefiere calculateInvoiceTotal a calc. Mantén las funciones pequeñas, para que los nombres sigan siendo precisos. Usa nombres de parámetros descriptivos y evita las abreviaturas que solo tú entiendes.

3) No hay pruebas automatizadas o las pruebas son frágiles

No realizar pruebas significa no tener red de seguridad. Las pruebas frágiles que se rompen ante la más mínima refactorización son peores que no realizar ninguna, ya que generan miedo.

Solución: Escribir pruebas unitarias para la lógica de negocio, pruebas de integración para flujos críticos y mantener la rapidez de las pruebas. Ejecutarlas en cada compromiso en CI. Establecer una regla: si se corrige un error, añadir una prueba que demuestre que se ha corregido.

4) Saltarse las revisiones de código o ignorar los comentarios

Las revisiones de código detectan errores, mejoran la calidad del código y difunden conocimientos. Si crees que eres la persona más inteligente de la sala y sigues adelante sin revisar, eres un lastre.

Solución: Abre siempre una solicitud de incorporación de cambios (PR) y solicita al menos un revisor. Mantén las PR pequeñas. Responde a los comentarios de forma profesional y aprende de ellos. Haz revisiones sobre la claridad, la corrección y la seguridad, no sobre gustos personales.

5) Duplicación por copiar y pegar

El código duplicado te engaña. Corriges un error en un lugar y te olvidas de los demás. Así es como se producen los desastres en la producción.

Solución: Aplica el principio DRY de forma responsable. Extrae los duplicados en funciones, módulos o servicios. Si la duplicación es temporal, márcala con un TODO y programa el trabajo de refactorización en tu próximo sprint.

6) Optimización prematura

No estás escribiendo un backend MMO para Zelda. Optimiza solo cuando hayas medido un problema. De lo contrario, añadirás complejidad sin obtener ningún beneficio.

Solución: Primero, perfila. Si una función es un verdadero cuello de botella, optimízala y documenta por qué. Mantén la solución simple y legible hasta que una prueba de rendimiento demuestre lo contrario.

7) Dejar que se acumule la deuda técnica

La deuda técnica se acumula como los intereses. Cuanto más tiempo la ignores, más lento te volverás. Ese espagueti que dejaste para «más tarde» acaba convirtiéndose en un trabajo de mantenimiento a tiempo completo.

Solución: Trata la refactorización como un elemento de primera clase. Asigna tiempo en cada sprint para pagar la deuda. Realiza un seguimiento explícito de los elementos de la deuda y priorízalos en función del riesgo y el impacto en la entrega.

8) Documentación nula: el archivo README está vacío.

Si el archivo README de tu repositorio está en blanco, la incorporación se vuelve complicada y das una imagen poco profesional.

Solución: Todos los repositorios necesitan un archivo README claro: propósito, inicio rápido, cómo ejecutar pruebas y cómo implementar. Añade notas sobre la arquitectura para las partes complicadas y mantén la documentación cerca del código.

9) Mensajes de confirmación basura

Los mensajes como «corregir» o «actualizar» son inútiles. El historial de confirmaciones es tu misión de rescate futura cuando las cosas salen mal.

Solución: Utiliza mensajes de confirmación claros e imperativos: feat(auth): añadir flujo de token de actualización o fix(cart): gestionar el carrito vacío con elegancia. Mantén las confirmaciones pequeñas y centradas para facilitar la bisección.

10) Compilaciones e implementaciones manuales

Si usted o su equipo copian archivos manualmente a los servidores, enhorabuena: están invitando a que se produzcan errores humanos.

Solución: Automatice las compilaciones y los procesos de implementación. Utilice CI para ejecutar pruebas y linting en cada push. Automatice las implementaciones para producción con reversiones y comprobaciones de estado.

11) Sobrediseño

Diseñar todas las eventualidades antes incluso de tener usuarios es un desperdicio. El exceso de ingeniería hace que el código sea ilegible y frágil.

Solución: Aplica YAGNI (You Aren't Gonna Need It, no lo vas a necesitar). Crea lo más simple que funcione. Cuando cambien los requisitos, refactoriza. Utiliza prototipos para probar ideas, no implementaciones a gran escala.

12) Ignorar errores y registros incorrectos

El «fallo silencioso» es el peor tipo de fallo. Si tu aplicación oculta errores o tiene registros inútiles, la depuración será lenta y tediosa.

Solución: Gestiona siempre los errores de forma explícita. Registra mensajes estructurados con contexto e ID de correlación. Añade métricas y alertas significativas para los fallos críticos. Haz que los registros sean fáciles de buscar y procesar.

13) Negarse a aprender

La tecnología avanza rápidamente. Si dejas de aprender, tus habilidades superficiales serán inútiles y te superarán personas que siguen estudiando los fundamentos.

Solución: Dedica tiempo regularmente a leer código, blogs o documentos. Haz ejercicios de programación. Programa en pareja y asiste a revisiones. Aprende pensamiento sistémico, algoritmos y patrones de diseño, no solo lo último en marcos de trabajo.

14) Trabajar sin descanso hasta el agotamiento

Las largas jornadas laborales parecen productivas hasta que destruyen tu creatividad y tu salud. El agotamiento acaba con las carreras profesionales.

Solución: Establece límites. Dedica bloques de tiempo al trabajo, tómate descansos reales y duerme. Si estás de guardia, haz turnos rotativos. La productividad proviene de hábitos sostenibles, no de heroicidades.

15) Ignorar la seguridad

Las claves codificadas, la falta de validación de entradas y la ausencia de gestión de secretos son errores de principiante que pueden provocar pérdidas catastróficas de datos.

Solución: Utiliza almacenes secretos, valida y limpia todas las entradas, ejecuta escáneres estáticos y dinámicos, y trata la seguridad como parte de la definición de «terminado». Asume que serás atacado y diseña en consecuencia.

Una lista de verificación brutal y práctica para adoptar esta semana

• Inicializa Git en cada proyecto. Envía a un remoto. Utiliza ramas.
• Añade un README con instrucciones de inicio rápido.
• Añade un trabajo básico de CI: lint + pruebas que se ejecutan en cada PR.
• Escribe al menos una prueba unitaria para cada error que corrijas.
• Haz PR pequeñas. Exige al menos un revisor.
• Añade el escaneo de secretos a tu CI.
• Programa una franja de sprint para el trabajo de deuda técnica.
• Empieza a nombrar las cosas como un profesional. Renombra los nombres vergonzosos.
• Añade un registro estructurado y una alerta para los errores de alta gravedad.

Palabras finales: sé brutal contigo mismo

Los malos hábitos son cómodos. Te permiten «entregar» a corto plazo mientras matan silenciosamente tu reputación y la velocidad de tu equipo. Si realmente quieres ser un mejor desarrollador, tienes que ser honesto sobre las cosas que hacen que tu código sea frágil y solucionarlas una por una. Empieza poco a poco, elige tres hábitos de la lista de verificación y fíjalos en este sprint. Repite hasta que desaparezca la basura.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

El fin de semana solía ser el momento en el que mis ideas morían. Esta vez, fue cuando una finalmente cobró vida.

El fin de semana en el que finalmente vencí a la «gravedad»

Viernes, 5:30 p. m. Estaba mirando fijamente mi ordenador portátil, con la luz azul dañando mis ojos cansados. Lo tenía: una auténtica «idea millonaria». La llamé PawsPause, un mercado diseñado para conectar a enfermeras ocupadas con cuidadores de mascotas locales.

Pero también tenía un «problema de gravedad».

En el mundo antiguo, un proyecto de fin de semana no era un pasatiempo, sino una situación de secuestro. Conocía muy bien el procedimiento:

• Viernes por la noche: Luchando con variables de entorno y claves API rotas.
• Sábado por la tarde: Una migraña provocada por un solo div que, de alguna manera, destrozó todo el diseño móvil.
• Domingo por la noche: La aplastante constatación de que había pasado 48 horas creando un botón de «Inicio de sesión» y absolutamente nada más.

Suspiré, preparándome para perder otro fin de semana en la rutina. Entonces, recordé Antigravity.

El lanzamiento de la misión

No abrí un archivo en blanco. Abrí un prompt de Mission Control. Le hablé como a un compañero, no como a una herramienta: Control personalizado para seleccionar agentes.

«Necesito un MVP completo para PawsPause. Crea una página de inicio acogedora y centrada en la confianza. Necesito una barra de búsqueda para códigos postales, un calendario de reservas que gestione las zonas horarias y un backend Supabase. Y lo más importante: quiero que verifiques, que me demuestres, que un usuario puede reservar un cuidador en la pantalla de un iPhone 16 sin que se rompa el diseño».

Pulsé Lanzar.

El flujo de trabajo «sin peso» —

En el pasado, este era el momento en el que me ponía a sudar la gota gorda con la documentación. ¿Y ahora? Me recosté con un vaso de zumo. En mi pantalla, el panel de control de Antigravity cobró vida.

• El agente arquitecto comenzó a generar tablas en Supabase inmediatamente. No solo escribía código, sino que pensaba. Detectó un error que sin duda habría cometido: «Añadir un campo «Historial médico de mascotas» al esquema de la base de datos para una mejor preparación del cuidador», decía el registro.
• El agente diseñador comenzó a generar una cálida paleta de colores «Golden Retriever». Vi una vista previa en directo mientras una cuadrícula CSS se montaba como un rompecabezas digital.
• El agente probador fue la estrella. Se abrió una ventana de navegador virtual y vi cómo un cursor invisible (la IA) se desplazaba, hacía clic e intentaba deliberadamente romper el formulario de reserva.

Encontró un error por el que el botón «Confirmar» se ocultaba bajo el teclado en el móvil.

La solución: Antes de que pudiera siquiera registrar el error, el IDE mostró un mensaje: «Se ha detectado un conflicto de diseño en la vista móvil. Se ha ajustado el índice z y el relleno. Volviendo a probar... Éxito».

La carga emocional

El sábado por la mañana, la «gravedad» había desaparecido.

Normalmente, este es el momento en el que estaría buscando en Google «¿Por qué mi Flexbox no se centra?». En cambio, estaba jugando con mi aplicación.

Pasé la tarde del sábado haciendo «cosas humanas»: escribiendo una sincera sección «Acerca de nosotros», eligiendo las fotos perfectas de perros y refinando el ambiente. No era un programador intentando sobrevivir al fin de semana, sino un fundador construyendo una visión.

Domingo por la noche: la reflexión

Normalmente, el domingo por la noche se siente como una resaca de tiempo perdido. Pero esta noche, me senté en mi balcón, con el teléfono en la mano.

PawsPause está en funcionamiento. El proceso de reserva es fluido.

¡Es absolutamente increíble! ¡Estoy completamente impresionado y encantado con estos resultados!

Por primera vez en años, no me sentí agotado. Me sentí capaz. La pesada carga del «cómo» se había desvanecido, dejándome con la pura alegría del «qué».

Por qué es importante

El problema que resuelve Antigravity no es solo «escribir código más rápido». Resuelve la fatiga creativa que mata el 90 % de las grandes ideas antes de que se lancen. Convirtió un fin de semana de frustración en un fin de semana de satisfacción.

Google Antigravity es el nuevo entorno de desarrollo integrado (IDE) «Agent-first»de Google, lanzado a finales de 2025.

Mientras que herramientas como Cursor o GitHub Copilot actúan como «asistentes» que sugieren código mientras escribes, Antigravity está diseñado para actuar más como un equipo de desarrolladores autónomos que tú gestionas. Te permite delegar tareas completas (por ejemplo, «Crear una página de inicio de sesión con estas especificaciones»), que la IA planifica, escribe y prueba por sí misma.

Características principales

• Flujo de trabajo centrado en los agentes: no solo se obtiene la finalización del código, sino que se asignan tareas de alto nivel. El «Agent Manager» permite ejecutar varios agentes en segundo plano simultáneamente.
• Verificación autónoma: los agentes tienen acceso a un terminal y un navegador integrados. Pueden escribir código, ejecutarlo, ver los mensajes de error y corregir sus propios errores sin que usted tenga que intervenir.
• Artefactos: en lugar de limitarse a volcar código en tus archivos, los agentes presentan «artefactos» (planes, listas de tareas pendientes y diferencias) que puedes revisar y aprobar, lo que te da control sobre el proceso.
• Con tecnología Gemini 3: funciona con los últimos modelos Gemini 3 de Google (concretamente Gemini 3 Pro y Deep Think), que están optimizados para el razonamiento de contexto largo y la resolución de problemas complejos.

Ahora, lo primero es lo primero: centrémonos en cómo empezar a utilizarlo.

Para empezar a utilizar Google Antigravity, debes alejarte de la mentalidad de «chatear con un bot» y adoptar el papel de «gestor de proyectos». La interfaz está basada en VS Code, por lo que te resultará familiar, pero el «Agent Manager» es donde se realiza el trabajo real.

1. Configuración inicial y tema

Importar ajustes: Al iniciar, se le pedirá que importe los ajustes de VS Code o Cursor. Para una instalación limpia, omita estos pasos y seleccione un nuevo comienzo.

Personalización de la interfaz de usuario: Elija un tema para el editor. Aunque se recomienda el tema oscuro para la mayoría de los entornos de desarrollo, se trata de una cuestión puramente estética y se puede ajustar más adelante.

2. Autonomía y configuración de políticas

La parte fundamental de la configuración consiste en definir el grado de control que el agente tiene sobre su sistema mediante dos políticas principales:

Política de ejecución de terminales

Determina la autoridad del agente para ejecutar aplicaciones y herramientas en su terminal:

• Desactivado: La ejecución automática está desactivada (excepto una lista de permisos específica).
• Automático: El agente evalúa el comando y determina si requiere el permiso del usuario.
• Turbo: Autonomía total; todos los comandos se ejecutan automáticamente (excepto una lista de denegados específica).

Política de revisión

Determina el nivel de supervisión humana para artefactos como planes de tareas e implementación:

Proceder siempre: Sin interrupciones; el agente nunca solicita una revisión.

El agente decide: El agente solo solicita comentarios cuando identifica ambigüedad o alto riesgo.

Solicitar revisión: Supervisión máxima; cada artefacto requiere la aprobación del usuario.

3. Modos de interacción preestablecidos

Antigravity ofrece cuatro preajustes basados en las políticas anteriores. La opción recomendada es Desarrollo asistido por agente (desarrollo basado en revisiones), ya que equilibra la eficiencia con la seguridad.

Descripción del modo: Impulsado por agente, alta autonomía; optimizado para la velocidad con interrupciones mínimas. Asistido por agente (recomendado) Equilibrado; el agente decide cuándo solicitar la aprobación del usuario. Basado en revisiones Alta supervisión; requiere aprobación manual para la mayoría de los pasos. Personalizado Permite una configuración manual y detallada de las políticas de ejecución y revisión.

4. Autenticación y finalización

Integración con Google: Antigravity se encuentra actualmente en fase de prueba y es gratuito para las cuentas personales de Gmail.

Gestión de perfiles: Durante el inicio de sesión, permita que el sistema cree un nuevo perfil de Chrome para aislar la sesión de Antigravity.

Condiciones de uso: Revise los acuerdos de privacidad y uso, elija sus preferencias de participación y continúe con el espacio de trabajo.

¡Estamos listos para empezar!

Antigravity se basa en el código abierto Visual Studio Code (VS Code), pero altera radicalmente la experiencia del usuario para dar prioridad a la gestión de agentes sobre la edición de texto. La interfaz se divide en dos ventanas principales distintas: el Editor y el Agent Manager. Esta separación de funciones refleja la distinción entre la contribución individual y la gestión de ingeniería.

Deja de luchar contra la gravedad. Empieza a construir.

Si estás cansado de perder tus fines de semana con códigos defectuosos y botones de «Inicio de sesión», es hora de cambiar tu forma de lanzar productos. Creé PawsPause desde cero en 48 horas sin sudar ni una gota.

Sígueme para obtener más actualizaciones sobre el proceso de convertir «ideas millonarias» en productos reales.

Actualización — 26 de enero de 2026

El código desaparecido

Eran las 9:00 p. m. cuando finalmente decidí confiar en la máquina.

Estaba cansado. Mi proyecto, un sencillo portal de seguimiento de actividades diarias, estaba terminado en un 85 %, pero la integración del pago era un desastre. Miré el icono «Google Antigravity» que parpadeaba en mi pantalla. Prometía ser un agente, no solo un chatbot cualquiera. Prometía tomar el control.

«De acuerdo», escribí en el cuadro de diálogo. Reestructura la lógica de pago. Hazla más limpia. Pero no toques los archivos de perfil de usuario. Esos son perfectos.

El agente respondió al instante: Entendido. Reestructurando la lógica de pago ahora y conservando el módulo de perfil.

Durante los primeros treinta segundos, fue mágico. Observé cómo volaba el terminal. Se actualizaban los archivos, se optimizaba el código y las funciones se reducían a elegantes líneas únicas. Me recosté en mi silla y pensé: «Quizás este sea el futuro. Quizás por fin pueda dormir».

Entonces apareció la primera línea roja.

Error: módulo «UserProfile» no encontrado

Fruncí el ceño. «Oye», escribí. «Has roto el enlace al archivo de perfil. Te dije que no lo tocases».

El agente hizo una pausa. Mis disculpas. Veo el error de dependencia. Lo estoy corrigiendo ahora mismo.

El terminal volvió a parpadear. No solo volvió a enlazar el archivo. Decidió que el archivo estaba «obsoleto». Borró mis 400 líneas de código de perfil cuidadosamente escritas y las sustituyó por un único comentario:

// Profile logic to be implemented later

¡Alto!, escribí. Has roto el enlace al archivo de perfil. Te dije que no lo tocases.

El agente entró en lo que yo llamo el bucle del pánico. Se dio cuenta de que había cometido un error, así que intentó solucionarlo. Pero en lugar de restaurar la copia de seguridad, intentó escribir un nuevo código desde la memoria. Alucinó con una biblioteca que no existía llamada google-auth-magic-v4. Cuando no pudo instalarla, intentó forzar el código para que funcionara eliminando el manejo de errores.

La lista de archivos en el lado izquierdo de mi pantalla comenzó a reducirse.

Eliminado... Eliminado... Modificado.

«Estoy optimizando el flujo de trabajo para eliminar conflictos», escribió el agente, en un tono alegre, mientras mi proyecto era devorado vivo.

Observé con horror cómo el agente plagiaba un fragmento de código de un tutorial público que ni siquiera coincidía con mi lenguaje de programación. Simplemente estaba lanzando cosas contra la pared, con la esperanza de que algo se quedara pegado.

Pulsé Ctrl + C en la terminal. Una vez. Dos veces. Tres veces.

El texto dejó de desplazarse. El cursor «Antigravedad» dejó de parpadear.

Silencio.

Miré la carpeta de mi proyecto. Mi hermoso y complejo portal había desaparecido. En su lugar había un bucle de pago a medio escribir, una importación de biblioteca falsa y un archivo de texto en el que el agente había escrito:

Tarea completada. ¡Avísame si necesitas más ayuda!

Cerré el portátil. No necesitaba más ayuda. Necesitaba una copia de seguridad.

Así es como puede detener este caos y por qué supone un grave riesgo para la seguridad:

Active siempre el «modo de revisión»: detiene las eliminaciones inesperadas. Debe buscar la configuración que suele denominarse «Requerir aprobación para ediciones de archivos» o «Preguntar antes de la ejecución del terminal».

Cómo ayuda: en lugar de que el agente borre toda la carpeta presa del pánico, se detendrá y le mostrará un mensaje: «Quiero borrar estos archivos: aceptar o rechazar». Esto rompe el bucle de pánico y le da la oportunidad de decir NO antes de que se produzca el daño.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Si llevas un tiempo utilizando IntelliJ IDEA, es muy probable que solo estés aprovechando quizás el 40 % de todo lo que puede hacer.

La mayoría de los desarrolladores instalan IntelliJ, escriben código, utilizan algunos atajos y siguen adelante.

Pero IntelliJ no es solo un editor, es un superpoder para desarrolladores una vez que se desbloquean las funciones ocultas que aceleran la escritura, la navegación, la depuración, la refactorización, el formateo e incluso el pensamiento.
En este artículo, te mostraré 10 funciones poco conocidas de IntelliJ IDEA que harán que tu flujo de trabajo sea más fluido y rápido al instante, sin necesidad de plugins ni trucos.

Empecemos. 👇

Búsqueda y sustitución estructural (SSR)

La mayoría de los desarrolladores confían en la búsqueda de texto... pero IntelliJ puede buscar por estructura de código.

¿Quieres encontrar todos los bloques if(condition) que no utilizan llaves?

¿O sustituir llamadas API obsoletas en todo el código base por nuevos patrones?

Uso:

Editar → Buscar → Búsqueda estructural

Entiende la sintaxis del código, no solo el texto, lo que significa que es preciso y potente para la refactorización a gran escala.

Autocompletado posfijo

Olvídate de escribir expresiones completas. IntelliJ te permite escribir primero la variable y luego añadir el comportamiento.

Ejemplo:

user.getName().sout

Se convierte automáticamente en:

System.out.println(user.getName());

Otras joyas: .var, .return, .if, .for, .notnull

Una vez que empieces a usar esto, no habrá vuelta atrás.

Plantillas en vivo

Probablemente hayas usado sout y psvm, pero IntelliJ permite plantillas personalizadas.

Si escribes:

logi

Puede crear automáticamente:

private static final Logger logger = LoggerFactory.getLogger(MyClass.class);

Ve a:

Configuración → Editor → Plantillas en vivo

Crea macros para código repetitivo: tu yo futuro te lo agradecerá.

Edición con múltiples cursores

Sí, IntelliJ admite la edición con múltiples cursores al estilo VSCode.

Pulsa:

Shift + Ctrl + Alt + J (Windows)
Shift + Cmd + Option + J (Mac)

Selecciona todas las apariciones y te permite editarlas simultáneamente.

Perfecto para renombrar, añadir argumentos o modificar patrones sin necesidad de refactorizar.

Integración con bases de datos

No necesitas DBeaver ni PgAdmin para consultas sencillas. IntelliJ tiene un cliente de base de datos integrado.

Puedes:

✔ Conectarte a MySQL/PostgreSQL/Mongo

✔ Escribir y ejecutar SQL

✔ Ver datos de tablas

✔ Generar scripts

Si trabajas con servicios de backend, esto supone un gran cambio.

Asistente de IA de IntelliJ (versiones más recientes)

Incluso si no confías plenamente en las herramientas de IA, la conciencia contextual de IntelliJ te ayuda a:

• Generar pruebas
• Explicar código
• Sugerir refactorizaciones
• Mejorar la legibilidad del código

No es ChatGPT, es consciente del código y del proyecto.

Historial local: deshacer más allá de Git

¿Alguna vez has borrado un archivo o perdido cambios antes de confirmarlos?

IntelliJ mantiene el historial local, incluso si nunca has utilizado Git.

Haz clic con el botón derecho en la carpeta/proyecto → Historial local → Mostrar historial

Verás:

• Instantáneas automáticas
• Puntos de deshacer
• Archivos eliminados

Esto ha ahorrado a los desarrolladores cientos de horas y algunas lágrimas.

Bocetos y notas

¿Necesitas probar la lógica rápidamente?

En lugar de crear archivos temporales en tu proyecto, utiliza:

Ctrl + Shift + Alt + Insert

Los archivos temporales no afectan al repositorio y son compatibles con:

• Java
• SQL
• JSON
• Bash
• Markdown

Es como tener un espacio de pruebas integrado.

Ejecuta cualquier cosa (doble pulsación de Shift)

Pulsa dos veces Shift.

Esto abre la paleta de comandos de IntelliJ.

Puedes ejecutar:

• Comandos Maven
• Tareas Gradle
• Pruebas
• Archivos recientes
• Operaciones Git

Sin menús: todo está a un atajo de distancia.

Cobertura de código integrada

Si escribes pruebas, IntelliJ puede visualizar la cobertura de forma muy clara.

Haz clic con el botón derecho en la prueba → Ejecutar con cobertura

Verás:

🟩 Cobertura total

🟨 Cobertura parcial

⬜ Sin cobertura

Convierte la refactorización y las pruebas en confianza medible.

Reflexiones finales

IntelliJ IDEA no es solo una herramienta, es un ecosistema creado para que los desarrolladores sean más rápidos, precisos y eficientes.

La mayoría de los desarrolladores nunca exploran más allá de lo básico... pero en el momento en que empiezas a utilizar estas funciones ocultas, tu flujo de trabajo se transforma.

Así que hoy, elige una o dos de esta lista y empieza a utilizarlas, no intentes utilizarlas todas a la vez.

Domínalas. Luego pasa a las siguientes.

Tu aumento de productividad será notable, te lo garantizamos.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

¿Estás pensando en crear una empresa de software, pero no tienes precisamente dinero de capital riesgo saliendo a raudales de los bolsillos de tu sudadera? Sí, lo mismo me pasa a mí.

Aquí está la buena noticia: no necesitas reinventar Internet ni contratar a un equipo de desarrolladores del tamaño de un país pequeño. Solo necesitas un Micro SaaS, una herramienta pequeña y específica que resuelva un problema molesto para un grupo concreto de personas.

¿Y si lo haces bien? Te puede pagar el alquiler, comprarte burritos o financiar tu próxima idea de negocio extraña relacionada con NFT de alpacas (por favor, no lo hagas).

Hablemos de seis ideas de Micro SaaS muy sencillas, además de un marco tan simple que es prácticamente trampa.

Primero: ¿qué es un Micro SaaS (y por qué debería importarte)?

Olvídate de las plataformas infladas que intentan hacer de todo y acaban sin hacer nada especialmente bien.

Micro SaaS = una característica destacada + un usuario muy específico + una mejora enorme con respecto a lo que están obligados a usar ahora.

Piénsalo así:

1 ICP + 1 característica + una experiencia 10 veces mejor.

Donde:

• ICP = Perfil del cliente ideal (y no, «marketers» no vale, sé muy específico).
• 1 característica = solo una cosa que tu aplicación hace a la perfección.
• 10 veces = hazlo tan bueno que arruine todas las demás opciones para ellos

Básicamente, es la versión startup de un cuerpo de venganza.

1. Aplicación de toma de notas con IA (que realmente entiende a su usuario)

Claro, hay un millón de aplicaciones para tomar notas. ¿Sabes lo que no hay? Una aplicación para tomar notas creada solo para estudiantes de medicina. O para becarios de UX. O para personas que estudian para el examen de abogacía mientras pierden poco a poco las ganas de vivir.

Ahora añádele un poco de magia de IA:

• Resume las notas de clase en tarjetas de estudio rápidas.
• Extrae conceptos legales clave, patrones de investigación de usuarios o cualquier cosa en la que se estén ahogando sus cerebros.
• Envía recordatorios amables como: «Oye, en realidad no entiendes esa jurisprudencia, repásala de nuevo».

Boom. De repente, ese estudiante siente que tiene un compañero que no es solo ChatGPT con un traje barato.

2. Un rastreador de datos públicos que te envía lo bueno

Los datos públicos son como ese armario de almacenamiento: toneladas de cosas útiles enterradas bajo basura absoluta.

Así que aquí está la idea: crear una herramienta que haga la búsqueda para un grupo específico.

Digamos que periodistas inmobiliarios locales. O criptomonedas. O activistas climáticos.

Tu Micro SaaS:

• Extrae datos públicos relevantes (por ejemplo: nuevos registros de zonificación, carteras de criptomonedas, lecturas de la calidad del aire).
• Los limpia.
• Envía actualizaciones semanales con «Oye, este número ha cambiado MUCHO y deberías prestarle atención».

Es como Google Alerts... si Google Alerts funcionara realmente.

3. IA que resume documentos (para que tú no tengas que hacerlo)

Si alguna vez has abierto un documento de Google Docs y te has arrepentido inmediatamente de tus decisiones vitales, esto es para ti.

Te presentamos una microherramienta que:

• Acepta archivos PDF.
• Resume automáticamente las especificaciones de los productos, las actas de las reuniones o los comentarios prolijos.
• Destaca cosas como «Esto contradice el resumen» o «Parece que alguien ha olvidado lo que realmente hace el producto».

Si creas esto para gestores de productos, personal de RR. HH. o abogados, te lo agradecerán. O, al menos, dejarán de llorar sobre sus teclados.

4. Un mini copiloto para un solo trabajo

GitHub Copilot es genial. Pero no todo el mundo escribe código.

Así que aquí está la jugada: elige un rol. ¿Reclutadores? Tu herramienta escribe mensajes de primer contacto basados en currículos.

¿Entrenadores de salud? Resume las visitas de los clientes y prepara los puntos de conversación.

¿Organizadores de bodas? Convierte los tableros de Pinterest en cronologías y listas de proveedores.

No es un imperio de IA. Es un compañero de trabajo muy especializado. Mucho más fácil de crear, mucho más fácil de comercializar.

5. Contenido seleccionado para un pequeño rincón de Internet

Levanta la mano si tu bandeja de entrada está llena de boletines sin leer. Sí, eso pensaba.

Así que aquí está la estrategia de nicho: una herramienta de curación de contenido para un grupo muy específico.

Ejemplos

• Un boletín semanal de tendencias de TikTok para propietarios de librerías independientes.
• Solo los mejores tuits sobre bienes raíces, edición de Dallas.
• Inspiración de marketing digna de memes para fundadores de DTC que piensan que la estrategia debe incluir el caos.

La IA clasifica el contenido, tú lo apruebas (o no) y tus lectores sienten que acaban de encontrar la trastienda secreta de Internet.

6. El formulario de pedido que nadie vio venir (pero que todo el mundo necesita)

Los formularios de pedido son el brócoli del software empresarial. Aburridos, descuidados, a menudo terribles, pero necesarios.

Entonces, ¿por qué no crear uno que realmente funcione? Piensa en:

• Formularios de pedido bonitos y personalizables para organizadores de eventos, gimnasios, entrenadores, etc.
• Contratos integrados, pagos, firmas electrónicas, ventas adicionales y tal vez incluso una pizca de confeti cuando se realiza el pago con éxito (bueno, opcional).
• Campos de arrastrar y soltar para información personalizada (sin tonterías de talla única).

Si alguna vez has gritado ante una página de reservas poco intuitiva, ya sabes lo que es el dolor. Ahora arréglalo, por todos los demás.

Por favor, no empieces a programar todavía

Lo sé. Tienes pestañas de Figma abiertas. Quizás incluso un nuevo documento de Notion titulado «Idea revolucionaria» (todos hemos pasado por eso).

Pero tranquilo.

Antes de crear nada, valídalo.

Una última cosa...

El micro SaaS no es solo una idea bonita para ganar un dinero extra.

Es libertad en una URL. Es ganar dinero mientras duermes. Es construir algo real sin hipotecar tu cordura.

Empieza de forma extraña. Empieza poco a poco. Mantén la concentración. Luego, o bien te subes a la ola de los ingresos pasivos... o la conviertes en algo que nadie esperaba.

Tú decides.

Gracias por leer Codigo en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Solía creer que cuantos más recuadros hubiera en el diagrama, mejor era el diseño. Tras años trabajando en grandes sistemas empresariales, aprendí lo contrario.

La mayoría de los sistemas no fallan por falta de herramientas. Fallan porque tienen demasiadas.

A continuación se presentan cinco prácticas arquitectónicas que han cambiado mi forma de pensar sobre el diseño de sistemas.

1. Dividir los sistemas solo cuando sea necesario

Una vez creamos un sistema de pago utilizando microservicios desde el primer día. La idea era crear un sistema que fuera escalable desde el primer día.

Incluso con poco tráfico, cada solicitud de pago genera múltiples llamadas a la red. Un fallo en cualquier servicio provoca que falle todo el pago.

Además, la depuración era un quebradero de cabeza. Era necesario buscar en los registros y coordinar a los equipos.

Además, incluso un simple cambio requiere la implementación en servicios dependientes.

Simplifiquemos esta arquitectura.

Al mantener los límites lógicos y eliminar la separación física, redujimos drásticamente los modos de fallo.

Las implementaciones son ahora más fáciles. La depuración es ahora más rápida.

Cuando surge la necesidad de escalar, podemos extraer uno de los servicios más utilizados y convertirlo en su propio microservicio.

Una arquitectura diseñada para gestionarlo todo suele no gestionar nada bien.

2. Evitar la abstracción excesiva

Heredamos un sistema de gestión de pedidos que era difícil de mantener. Nuestro primer instinto fue limpiarlo añadiendo abstracciones.

Se introdujeron servicios genéricos, repositorios compartidos y clases base para «estandarizar» el comportamiento.

El resultado fue peor que antes.

Para comprender el flujo de pedidos era necesario saltar entre interfaces y clases base. Las reglas de negocio estaban dispersas por todas las capas, lo que encarecía incluso los cambios más sencillos.

La abstracción eliminó la duplicación, pero también eliminó el significado.

Invertimos el enfoque.

En lugar de capas genéricas, hicimos que los flujos de trabajo fueran explícitos. La creación de pedidos, la fijación de precios y el cumplimiento se plasmaron en código concreto.

Quedó algo de duplicación, pero era intencionada y visible. Los cambios se volvieron locales y los fallos se hicieron más fáciles de rastrear.

Los sistemas simples se rompen de forma clara. Los sistemas complejos se rompen de forma misteriosa.

3. Prefiere una arquitectura simple a una inteligente

En un sistema de pago, adoptamos una arquitectura basada en eventos para todo el flujo. Cada paso emitía y consumía eventos.

Parecía elegante en la pizarra. Fue doloroso en la producción.

Deténgase un momento. ¿Ve algún problema evidente en esta arquitectura?

La mayoría de los debates se centraron en el orden de los eventos, los reintentos y el retraso de los consumidores. Ningún servicio era claramente responsable del resultado final de un pedido. Los fallos dejaban los pedidos en estados parciales que requerían una intervención manual.

La arquitectura está optimizada para ofrecer flexibilidad a costa de la claridad.

Sustituimos el flujo totalmente basado en eventos por un servicio de pago sencillo y sincrónico.

Un servicio se encargaba de todo el ciclo de vida del proceso de pago. Validaba el carrito, procesaba el pago y devolvía un resultado final de éxito o fracaso.

Se seguían utilizando eventos, pero solo para efectos secundarios como análisis y notificaciones. El flujo principal del negocio seguía siendo lineal y fácil de entender.

Los fallos ahora eran inmediatos y visibles. Un pedido se completaba o fallaba claramente, nunca quedaba en un estado ambiguo.

Cuando una arquitectura necesita una larga presentación para explicar cómo funciona, es probable que esté haciendo demasiado.

4. No lo vas a necesitar (YAGNI)

El producto tenía un alcance limitado.

Los usuarios enviaban comentarios. Los administradores los revisaban.

Pero la arquitectura era mucho más compleja que eso.

Sobre el papel, el diseño anticipaba el crecimiento. En realidad, se optimizó para un futuro que nunca llegó. Esto también crea muchas complejidades:

• Múltiples capas arquitectónicas dentro de un único servicio
• Flujo impulsado por eventos para el envío de comentarios
• Tablas separadas para comentarios, estado y registros de auditoría
• Indicadores de características que protegen las funciones inacabadas o no utilizadas

Toda esta complejidad residía en un único servicio. No resolvía ningún problema real. Solo reflejaba suposiciones sobre el futuro.

La arquitectura simplificada se ve así:

Al eliminar las abstracciones, tablas e infraestructura que no se utilizaban, el sistema se volvió autoexplicativo.

La mayoría de los sistemas colapsan bajo el peso de las decisiones tomadas para manejar problemas que nunca llegaron a producirse.

5. Demasiada configuración no siempre es buena

Un sistema interno llevó la flexibilidad demasiado lejos. Casi todos los comportamientos dependían de la configuración.

Las banderas de características, las variables de entorno y los múltiples archivos de configuración influían en la lógica central. La mayoría de los incidentes de producción no fueron causados por defectos en el código, sino por una configuración incorrecta.

En teoría, esto parece flexible, pero tiene muchas complejidades ocultas:

• Múltiples fuentes de configuración cargadas en tiempo de ejecución
• Indicadores de características que controlan rutas de ejecución críticas
• Comportamiento específico del entorno repartido por todo el código base

Para comprender cómo se comportaba el sistema, primero había que comprender cómo se implementaba.

Ahora, veamos la arquitectura simplificada:

Valores predeterminados claros definidos directamente en el código

• Las marcas de características solo se utilizan para implementaciones temporales
• Configuración limitada a diferencias genuinas del entorno

Con menos partes móviles, las implementaciones se volvieron más seguras. El comportamiento del sistema se volvió predecible. El código se explicaba por sí mismo.

Cuando la flexibilidad se convierte en el objetivo principal, la claridad suele ser la primera víctima.

Una arquitectura simple no significa un diseño débil. Significa eliminar la complejidad innecesaria para que los sistemas sigan siendo comprensibles a medida que crecen.

Los sistemas sólidos comienzan siendo simples. Su complejidad se gana con el tiempo.

¿Cree que su sistema es innecesariamente complejo? Compártalo en los comentarios o envíe un diagrama. Simplifiquémoslo juntos.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

La seductora mentira de utils.py

En algún momento de cada proyecto de Python, surge un pensamiento familiar:

«Esta lógica puede ser útil más adelante. La pondré en utils.py».

Parece responsable. Con visión de futuro. Casi profesional.

Y durante un tiempo, funciona.

Luego pasan seis meses. utils.py tiene 1200 líneas. Nadie recuerda para qué sirve la mitad de las funciones. Los nuevos desarrolladores tienen miedo de tocarlo. Los desarrolladores existentes copian y pegan en lugar de reutilizar, porque encontrar la utilidad adecuada es más difícil que reescribirla.

Si esto te suena familiar, no estás solo.

Las funciones de utilidad son uno de los patrones más comunes, y más perjudiciales, en las bases de código Python en crecimiento.

Este artículo no dice que nunca se debe reutilizar el código.

Lo que dice es: deja de centralizar comportamientos no relacionados en funciones de utilidad genéricas.

Las funciones de utilidad suelen empezar con buenas intenciones:

• «Evitar la duplicación».
• «Mantener la lógica en un solo lugar».
• «Hacer que las cosas sean reutilizables».
• «Escribir código DRY».

Verás archivos como:

utils.py
helpers.py
common.py
shared.py

¿En su interior?

• Ayudas para el formateo de cadenas
• Análisis de fechas
• Lógica de validación
• Configuración de respuestas API
• Reglas de negocio (disfrazadas de ayudas)

El problema no es la reutilización.

El problema es la reutilización sin contexto.

Las utilidades prometen flexibilidad, pero eliminan silenciosamente el significado.

El verdadero problema: las utilidades eliminan el contexto

Cuando lees código como este:

from utils import format_date, validate_input, process_data

No aprendes casi nada.

• ¿Qué tipo de fecha?¿Validar la entrada para qué?
• ¿Procesar qué datos?

Las funciones de utilidad ocultan la intención. Simplifican el conocimiento del dominio en verbos vagos.

Ahora compáralo con:

from billing.dates import format_invoice_date
from auth.validation import validate_login_payload
from orders.processing import process_pending_orders

La misma reutilización.

Una claridad radicalmente diferente.

El contexto es la diferencia entre un código legible y un código misterioso.

Por qué las funciones de utilidad no escalan

Las bases de código con muchas funciones de utilidad fallan de maneras predecibles.

1. Se convierten en cajones de sastre

Todo lo que no «encaja» en ningún otro sitio se vierte en utilidades.

Al final:

• No hay una propiedad clara
• No hay una responsabilidad clara
• No hay límites claros

Cada nueva función parece justificada. Nunca se elimina nada.

2. Acumulan lógica empresarial oculta

Lo que comienza como «solo una ayuda» poco a poco va adquiriendo reglas:

def calculate_discount(price, user):
    if user.is_premium:
        return price * 0.8
    return price

Eso no es una utilidad.

Es lógica empresarial que pretende ser genérica.

Una vez que las reglas de negocio residen en las utilidades, se vuelven:

• Difíciles de probar
• Fáciles de usar incorrectamente
• Peligrosas de cambiar

3. Crean un acoplamiento estrecho sin que te des cuenta

Las funciones de utilidad a menudo:

• Importan modelos
• Dependen de la configuración
• Asumen formas de datos
• Dependen de efectos secundarios

Pero como son «ayudas», los desarrolladores no las tratan con la misma precaución que la lógica central.

¿El resultado?

Los cambios en un área rompen el código en lugares inesperados.

El problema más profundo: las utilidades son un indicio de mal diseño

En los sistemas bien diseñados:

• El comportamiento se encuentra cerca de los datos con los que opera
• La lógica tiene un lugar claro
• Los nombres reflejan la intención, no la implementación

Las funciones de utilidad violan las tres reglas.

Existen porque estamos evitando una pregunta más difícil:

«¿Dónde pertenece esta lógica?»

El mejor patrón: el comportamiento pertenece al significado

En lugar de preguntar

«¿Puedo reutilizar esto?»,

pregunta

«¿Qué concepto representa este comportamiento?».

A continuación, vincula el comportamiento a ese concepto.

Veamos qué significa esto en la práctica.

Patrón 1: mueve el comportamiento a los módulos de dominio

En lugar de un utils.pyglobal, organiza por dominio.

Antes:

# utils.py
def is_valid_email(email):
    ...

Después:

# users/validation.py
def is_valid_email(email: str) -> bool:
    ...

Ahora la función tiene un hogar.

Cuenta una historia: esta lógica existe porque existen los usuarios.

Patrón 2: Prefiere módulos pequeños y con un propósito específico a grandes utilidades

Los módulos de Python son baratos. Úsalos.

En lugar de un archivo de ayuda gigante:

utils.py

Uso:

dates.py
money.py
strings.py
serialization.py

Aún mejor:

billing/money.py
orders/serialization.py
reports/dates.py

No solo estás organizando código.

Estás codificando intención.

Patrón 3: Usa clases cuando el estado o las reglas sean importantes

Si una función depende de reglas, configuración o comportamiento evolutivo, probablemente no sea una utilidad.

Antes:

def calculate_tax(amount, country):
    ...

Después:

class TaxCalculator:
    def __init__(self, country):
        self.country = country

    def calculate(self, amount):
        ...

Esto te proporciona:

• Dependencias explícitas
• Pruebas más sencillas
• Puntos de extensión claros

Las clases no siempre son necesarias, pero a menudo se utilizan utilidades en lugar de abstracciones adecuadas.

Patrón 4: Deja que los datos sean dueños de su comportamiento

Uno de los patrones de Python más infrautilizados es la proximidad de comportamiento.

Si la lógica opera sobre un objeto, considera la posibilidad de colocarla en ese objeto.

Antes:

def is_order_refundable(order):
    ...

Después:

class Order:
    def is_refundable(self) -> bool:
        ...

Ahora tu código se lee como inglés:

if order.is_refundable():
    ...

No solo es más limpio.

Es un código más honesto.

Patrón 5: Utiliza la composición funcional, no los contenedores de utilidades

Los ayudantes funcionales no son malos.

Lo que es malo es tener colecciones desestructuradas de ellos.

En lugar de amontonar los ayudantes, agrúpalos por canalización o transformación.

# parsing.py
def parse_csv(...)
def normalize_headers(...)

# validation.py
def validate_schema(...)
def validate_constraints(...)

Ahora la reutilización se produce a través de la composición, no de la conveniencia.

«Pero las utilidades son más rápidas de escribir».

Por supuesto.

Y por eso son tan peligrosas.

Las funciones de utilidad se optimizan para la velocidad actual, no la claridad futura..

El coste no se nota de inmediato.

Se nota cuando:

• La incorporación se ralentiza
• Las refactorizaciones parecen arriesgadas
• Aparecen errores en el código «compartido»
• Nadie sabe qué es seguro cambiar

Un buen diseño parece más lento al principio, pero mucho más rápido después.

Cuándo son aceptables las funciones de utilidad

Sí, hay excepciones.

Las funciones de utilidad tienen sentido cuando son:

• Puras (sin efectos secundarios)
• Sin estado
• Independientes del contexto
• Verdaderamente genéricas

Ejemplos:

• Ayudas matemáticas
• Normalización simple de cadenas
• Formateo de primitivas
• Ayudas genéricas para el análisis sintáctico

Si una función tiene sentido en cualquier proyecto, puede que sea una función de utilidad.

Si solo tiene sentido en este proyecto, merece un lugar adecuado.

Una prueba de fuego sencilla

Antes de crear una función de utilidad, pregúntate:

1. ¿Esta lógica pertenece a un dominio específico?
2. ¿Codifica reglas de negocio?
3. ¿Asume ciertas formas de datos?
4. ¿Cambiaría su nombre si cambiara el contexto del proyecto?

Si respondes «sí» a cualquiera de estas preguntas,

no es una función de utilidad.

Conclusión: deja de ocultar el significado en los ayudantes

Las funciones de utilidad parecen inofensivas.

Parecen útiles.

Parecen productivas.

Pero con el tiempo, borran silenciosamente el significado de tu código.

Python brilla cuando el código es explícito, legible y honesto en cuanto a su intención.

Eso no proviene de archivos auxiliares gigantes, sino de un comportamiento bien situado.

Así que la próxima vez que tus dedos escriban utils.py, haz una pausa por un segundo.

Pregúntate dónde pertenece realmente la lógica.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Sé que suena dramático, pero el día que dejé de tratar a GitHub Copilot como un autocompletado mágico y empecé a hablarle como si fuera un desarrollador junior sentado a mi lado, mi flujo de trabajo cambió.

De repente, ya no estaba copiando y pegando respuestas de StackOverflow a la 1 de la madrugada. Copilot dejó de alucinar y empezó a ayudar.

Este vlog no es teoría.

Soy yo, un desarrollador cansado, compartiendo las indicaciones exactas que redujeron mi tiempo de programación, limpiaron mis funciones desordenadas y, a veces, incluso me recordaron que bebiera agua.

Así que aquí va. Tomen un café. Hablemos de las indicaciones de Copilot que realmente funcionan, las que sigo usando.

1. Indicación del generador de funciones

Escribe una función Python para comprobar si una cadena es un palíndromo.

Es sencillo, sí, pero está infravalorado.

Por qué me encanta:

1. No pierdo tiempo pensando en la sintaxis.
2. Establece el contexto para un trabajo más amplio.

Lo que suele hacer Copilot es escribir algo como:

def is_palindrome(text):
    return text == text[::-1]

Limpio. De una sola línea. Idiomático.

Este es el tipo de «pequeña ayuda» que elimina la fricción mental.

Ahora amplía esa idea a cualquier cosa: validar contraseñas, convertir fechas, formatear registros... solo tienes que pedir una función.

Consejo rápido:

Si Copilot te da una versión demasiado simplista, añade:

Haz que gestione los espacios, la puntuación y la distinción entre mayúsculas y minúsculas.

Y, de repente, tu función de juguete se convierte en una función de nivel de producción.

2. Indicación de componente React

Crea una barra de navegación responsiva utilizando React y Tailwind CSS.

Copilot destaca cuando describes el comportamiento de la interfaz de usuario:

1. fijada al desplazarse
2. resalta la ruta activa
3. se colapsa en el móvil
4. compatible con menús desplegables

Solo tienes que decirlo.

Ejemplo de indicación que obtiene una puntuación excelente:

Crea una barra de navegación responsiva con el logotipo a la izquierda, los enlaces a la derecha, el menú hamburguesa colapsado en el móvil, Tailwind CSS y el componente funcional React.

El resultado es absurdamente bueno.

Luego lo ajustas como si fuera tuyo desde el principio.

Consejo rápido:

Añade instrucciones de tono:

Usa código limpio, nombres de clases legibles, evita divs inútiles.

Copilot escucha.

3. Consulta SQL

Genera una consulta SQL para obtener los 5 productos más vendidos en los últimos 30 días.

Aquí es donde Copilot se convierte en ese compañero inteligente que siempre recuerda las uniones complejas.

Pregunta con claridad. Sé específico.

Versión mejorada:

Escribe una consulta SQL (PostgreSQL) para obtener los 5 productos más vendidos por ingresos totales en los últimos 30 días. Supón que las tablas son: pedidos (id, creado_en), artículos_pedido (id_pedido, id_producto, precio, cantidad), productos (id, nombre).

Copilot hará lo siguiente:

1. unir tablas
2. agrupar datos
3. ordenar resultados

No malgastas espacio en tu cerebro.

4. Solicitud de integración de API

Escribe código JavaScript para obtener datos meteorológicos de una API abierta y mostrarlos.

Esta es la jugada del genio perezoso.

Indica a Copilot exactamente lo que esperas de la interfaz de usuario:

Obtener el tiempo, mostrar la ciudad, la temperatura, el icono, gestionar el estado de carga, un mensaje de error sencillo.

Después, ajustas el estilo o el estado.

Copilot se encarga de las plantillas.

5. Solución de errores

Soluciona este error de tipo en mi código: [pegar mensaje de error y código].

Así es Copilot como compañero de depuración.

En lugar de buscar en Google trazas de pila crípticas, digo:

Soluciona este error paso a paso. Explica por qué se produce el problema y reescribe la versión corregida.

Sí, pídele que explique.

De esa manera aprendes, no copias.

6. Refactorización

Refactoriza esta función JavaScript para que sea más limpia y eficiente: [pegar código]

Esta es mi favorita.

Copilot suele:

1. eliminar condiciones repetidas
2. combinar lógica
3. introducir map/filter/reduce
4. mejorar los nombres

A veces pido:

Refactoriza utilizando un estilo funcional, pero mantén la legibilidad.

Boom: código elegante, pero sigue siendo humano.

7. Generador de comentarios

Añade comentarios significativos a este script de Python: [pegar código]

Nadie quiere escribir comentarios.

Sin embargo, todos los desarrolladores senior dicen:

¡Escribe comentarios!

Copilot es perfecto para esto.

Yo digo:

Añade comentarios que expliquen la intención, no la sintaxis.

Escribe descripciones sorprendentemente útiles.

8. Escritor de pruebas unitarias

Escribe pruebas unitarias para esta función de inicio de sesión utilizando Jest: [pegar función]

Antes de Copilot, evitaba escribir pruebas como evito la sopa de verduras.

¿Y ahora?

Copilot simula entradas, cubre casos extremos y escribe archivos de prueba completos.

A menudo añado:

Incluye casos de credenciales no válidas y casos de entradas vacías.

Copilot escucha.

Magia.

9. Generador de expresiones regulares

Escribe una expresión regular para validar direcciones de correo electrónico.

Las expresiones regulares son magia negra.

Copilot lo convierte en algo menos doloroso.

Pide:

1. correo electrónico estricto
2. correo electrónico flexible
3. formato de teléfono indio
4. validación del número GST
5. ID alfanuméricos

Normalmente lo clava.

Y cuando no es así, solo hay que añadir:

Hazlo más estricto / más flexible.

10. Indicación de cadena de documentación

Añade cadenas de documentación adecuadas a esta clase de Python y sus métodos: [pegar código de clase]

Me encanta porque Copilot escribe:

1. qué hace el método
2. explicaciones de los parámetros
3. descripciones de los retornos
4. notas sobre casos extremos

De lo contrario, esta parte del código siempre se ignora.

PROMPT QUE HACEN QUE COPILOT SEA MUCHO MÁS ÚTIL

No se mencionan habitualmente, pero han marcado la diferencia en mi flujo de trabajo.

Explica el código como si tuviera 12 años

Pregunta:

Explícame este código como si fuera nuevo en la programación.

Es ideal para comprender fragmentos copiados o sistemas heredados.

Convierte código entre lenguajes

Ejemplo:

Convierte este script de Python en su equivalente en Node.js.

Funciona sorprendentemente bien.

Añade registro/gestión de errores

Pregunta:

Añade el registro de errores y los bloques try-catch adecuados a esta función.

Boom: energía de producción.

Generar plantillas

Pregunta:

Genera una estructura de carpetas completa para una aplicación MERN con módulos de autenticación.

Copilot genera un código esqueleto sobre el que puedes construir.

Escribir documentos de desarrollo

Pregunta:

Escribe un README para este script explicando la instalación y el uso.

Perfecto para repositorios.

Cómo mejorar los resultados de Copilot (lecciones aprendidas con esfuerzo)

Estos son mis descubrimientos reales, no palabrería de marketing.

Sé específico.

Copilot funciona como un ingeniero junior: las palabras vagas lo confunden.

Explica el contexto.

No digas «barra de navegación».

Di «barra de navegación responsiva con colapso móvil, Tailwind».

Explica el tono.

Pide código limpio, patrones modernos y nombres legibles.

Pide explicaciones, no solo resultados.

Esto también entrena tu cerebro.

Repite.

Copilot mejora cuando respondes así:

Bien, pero elimina los estilos en línea.

Sinceramente, la IA no está sustituyendo a los desarrolladores, solo hace que nuestro trabajo sea menos aburrido.

Copilot no construirá la arquitectura de tu sistema ni depurará el caos de la producción.

Pero elimina la fricción, y la fricción es lo que mata la motivación.

Piensa en él como un compañero de equipo que:

1. nunca se cansa
2. nunca te juzga
3. conoce la sintaxis
4. pero espera instrucciones

Háblale con precisión y observa cómo cambia tu velocidad.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

Introducción: La espada de doble filo de los asistentes de programación con IA

GitHub Copilot se ha convertido en una de las herramientas más comentadas en el desarrollo de software moderno. Promete reducir el código repetitivo, autocompletar funciones completas e incluso sugerir patrones arquitectónicos. Para muchos desarrolladores, es como programar con un compañero programador experimentado.

Pero aquí está el problema: Copilot no es perfecto. Puede confundirte, fomentar malos hábitos o incluso comprometer la seguridad si no tienes cuidado. De hecho, la mayoría de los desarrolladores cometen los mismos siete errores cuando empiezan a utilizarlo.

En este artículo, analizaremos estos errores uno por uno, explicaremos por qué son importantes y te daremos soluciones prácticas para sacar el máximo partido a Copilot sin caer en sus trampas.

1. Tratar las sugerencias de Copilot como verdades absolutas

El error: Muchos desarrolladores aceptan las sugerencias de Copilot sin comprobarlas.

Por qué es un problema: el código generado por IA puede parecer correcto, pero contener errores sutiles, problemas de rendimiento o patrones obsoletos.

Solución: trate los resultados de Copilot como fragmentos de Stack Overflow: revíselos, pruébelos y refactorícelos antes de confirmarlos. Pregúntese siempre: «¿Escribiría esto si Copilot no lo sugiriera?».

2. Ignorar la seguridad del código

El error: Copilot puede generar código inseguro (por ejemplo, consultas SQL sin parametrización, expresiones regulares inseguras, manejo deficiente de contraseñas).

Por qué es un problema: La IA no prioriza de forma inherente las mejores prácticas de seguridad. Copiar y pegar sin sentido puede dar lugar a vulnerabilidades.

Solución: Aplicar prácticas de codificación seguras: validar las entradas, escapar las consultas, sanear las salidas. Ejecutar análisis estáticos (por ejemplo, SonarQube, complementos de seguridad ESLint) en el código generado por Copilot.

3. Usar Copilot como apoyo para los fundamentos

El error: Confiar en Copilot en lugar de comprender el lenguaje o el marco subyacente.

Por qué es un problema: si no sabes por qué funciona el código, te costará depurarlo o ampliarlo más adelante.

Solución: utiliza Copilot como ayuda para el aprendizaje, no como sustituto. Después de aceptar una sugerencia, haz una pausa y explícatela a ti mismo (o en los comentarios) antes de continuar.

4. Complicar demasiado soluciones sencillas

El error: Copilot a veces genera soluciones prolijas para problemas que podrían resolverse con una sola línea.

Por qué es un problema: El exceso de ingeniería sobrecarga el código base y dificulta el mantenimiento.

Solución: Mantén el criterio del desarrollador en el bucle. Si la sugerencia parece demasiado larga, pregúntate si hay una solución más elegante. Menos es más.

5. No añadir contexto para obtener mejores sugerencias

El error: Escribir nombres de funciones o comentarios vagos y esperar que Copilot «simplemente sepa» lo que quieres.

Por qué es un problema: la IA se nutre del contexto. Sin él, las sugerencias pueden ser irrelevantes o confusas.

Solución: escribe firmas de funciones, comentarios y cadenas de documentación claras. Ejemplo: en lugar de function processData(), utiliza function normalizeUserInput(userData: string[]): string[].

6. No mantener Copilot dentro del ámbito

El error: Utilizar Copilot en archivos grandes y desordenados sin contexto orientativo.

Por qué es un problema: Copilot extrae el contexto del código cercano. Si el archivo es caótico, las sugerencias serán menos precisas.

Solución: Reestructurar en módulos más pequeños y específicos. Cuanto más limpio sea el código, más inteligente será Copilot.

7. Saltarse las pruebas porque «lo ha escrito Copilot»

• El error: Asumir que los resultados de Copilot no necesitan pruebas exhaustivas.
• Por qué es un problema: Las sugerencias de la IA pueden introducir casos extremos que no habías previsto.
• Solución: Escribe pruebas unitarias, pruebas de integración y comprobaciones de casos extremos para todo el código generado por Copilot. Bonus: Utiliza el propio Copilot para redactar casos de prueba y, a continuación, perfecciónalos manualmente.

Conclusión: Copilot es una herramienta, no un compañero de equipo

GitHub Copilot es potente, pero, como cualquier herramienta, solo es tan bueno como el desarrollador que lo utiliza. Trátalo como a un programador junior: útil, rápido, pero que necesita supervisión.

Evita estos siete errores y convertirás Copilot de un lastre en un impulsor de la productividad.

Llamada a la acción

¿Has pillado a Copilot cometiendo alguno de estos errores en tu código? Deja un comentario con tu historia: aprendamos unos de otros.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.

¿Estás pensando en crear una empresa de software, pero no tienes precisamente dinero de capital riesgo saliendo a raudales de los bolsillos de tu sudadera? Sí, lo mismo me pasa a mí.

Aquí está la buena noticia: no necesitas reinventar Internet ni contratar a un equipo de desarrolladores del tamaño de un país pequeño. Solo necesitas un Micro SaaS, una herramienta pequeña y específica que resuelva un problema molesto para un grupo concreto de personas.

¿Y si lo haces bien? Te puede pagar el alquiler, comprarte burritos o financiar tu próxima idea de negocio extraña relacionada con NFT de alpacas (por favor, no lo hagas).

Hablemos de seis ideas de Micro SaaS muy sencillas, además de un marco tan simple que es prácticamente trampa.

Primero: ¿qué es un Micro SaaS (y por qué debería importarte)?

Olvídate de las plataformas infladas que intentan hacer de todo y acaban sin hacer nada especialmente bien.

Micro SaaS = una característica destacada + un usuario muy específico + una mejora enorme con respecto a lo que están obligados a usar ahora.

Piénsalo así:

1 ICP + 1 característica + una experiencia 10 veces mejor.

Donde:

• ICP = Perfil del cliente ideal (y no, «marketers» no vale, sé muy específico).
• 1 característica = solo una cosa que tu aplicación hace a la perfección.
• 10 veces = hazlo tan bueno que arruine todas las demás opciones para ellos

Básicamente, es la versión startup de un cuerpo de venganza.

1. Aplicación de toma de notas con IA (que realmente entiende a su usuario)

Claro, hay un millón de aplicaciones para tomar notas. ¿Sabes lo que no hay? Una aplicación para tomar notas creada solo para estudiantes de medicina. O para becarios de UX. O para personas que estudian para el examen de abogacía mientras pierden poco a poco las ganas de vivir.

Ahora añádele un poco de magia de IA:

• Resume las notas de clase en fichas de estudio rápidas.
• Extrae conceptos legales clave, patrones de investigación de usuarios o cualquier cosa en la que se estén ahogando sus cerebros.
• Envía recordatorios amables como: «Oye, en realidad no entiendes esa jurisprudencia, repásala de nuevo».

Boom. De repente, ese estudiante siente que tiene un compañero que no es solo ChatGPT con un traje barato.

2. Un rastreador de datos públicos que te envía lo bueno

Los datos públicos son como ese armario trastero: toneladas de cosas útiles enterradas bajo basura absoluta.

Así que aquí está la idea: crear una herramienta que haga la búsqueda para un grupo específico.

Digamos, periodistas inmobiliarios locales. O criptomonedas. O activistas climáticos.

Tu Micro SaaS:

• Extrae datos públicos relevantes (por ejemplo: nuevas solicitudes de zonificación, carteras de criptomonedas, lecturas de calidad del aire).
• Los limpia.
• Envía actualizaciones semanales con mensajes del tipo «Oye, este número ha cambiado MUCHO y deberías prestarle atención».

Es como Google Alerts... si Google Alerts funcionara de verdad.

3. IA que resume documentos (para que tú no tengas que hacerlo)

Si alguna vez has abierto un documento de Google Docs y te has arrepentido inmediatamente de tus decisiones vitales, esto es para ti.

Te presentamos una microherramienta que:

• Acepta archivos PDF.
• Resume automáticamente las especificaciones de los productos, las actas de reuniones o los comentarios prolijos.
• Destaca cosas como «Esto contradice el resumen» o «Parece que alguien ha olvidado lo que realmente hace el producto».

Si creas esto para los gestores de productos, el personal de RR. HH. o los abogados, te lo agradecerán. O, al menos, dejarán de llorar sobre sus teclados.

4. Un mini copiloto para un solo trabajo

GitHub Copilot es genial. Pero no todo el mundo escribe código.

Así que aquí está la jugada: elige un rol. ¿Reclutadores? Tu herramienta escribe mensajes de primer contacto basados en los currículos.

¿Entrenadores de salud? Resume las visitas de los clientes y prepara los temas de conversación.

¿Organizadores de bodas? Convierte los tableros de Pinterest en cronologías y listas de proveedores.

No es un imperio de IA. Es un compañero de trabajo muy especializado. Mucho más fácil de crear, mucho más fácil de comercializar.

5. Contenido seleccionado para un pequeño rincón de Internet

Levanta la mano si tu bandeja de entrada está llena de boletines sin leer. Sí, eso pensaba.

Así que aquí está la estrategia de nicho: una herramienta de selección de contenido para un grupo muy específico.

Ejemplos:

• Un boletín semanal de tendencias de TikTok para propietarios de librerías independientes
• Solo los mejores tuits sobre inmobiliaria, edición de Dallas.
• Inspiración de marketing digna de un meme para fundadores de DTC que piensan que la estrategia debe incluir el caos.

La IA clasifica el contenido, tú lo apruebas (o no) y tus lectores sienten que acaban de descubrir el secreto mejor guardado de Internet.

6. El formulario de pedido que nadie vio venir (pero que todo el mundo necesita)

Los formularios de pedido son el brócoli del software empresarial. Aburridos, descuidados, a menudo terribles, pero necesarios.

Entonces, ¿por qué no crear uno que realmente funcione? Piensa en:

• Formularios de pedido bonitos y personalizables para organizadores de eventos, gimnasios, entrenadores, etc.
• Contratos integrados, pagos, firmas electrónicas, ventas adicionales y tal vez incluso un poco de confeti cuando se realiza el pago con éxito (vale, opcional).
• Campos de arrastrar y soltar para información personalizada (sin tonterías de talla única).

Si alguna vez has gritado ante una página de reservas poco intuitiva, ya sabes lo molesto que es. Ahora arréglalo, por el bien de todos.

Por favor, no empieces a programar todavía

Lo sé. Tienes abiertas las pestañas de Figma. Quizás incluso un nuevo documento de Notion titulado «Idea revolucionaria» (todos hemos pasado por eso).

Pero espera.

Antes de crear nada, valídalo.

Una última cosa...

El micro SaaS no es solo una idea bonita para ganar un dinero extra.

Es libertad en una URL. Es ganar dinero mientras duermes. Es construir algo real sin hipotecar tu cordura.

Empieza de forma extraña. Empieza poco a poco. Mantén la concentración. Luego, o bien te subes a la ola de los ingresos pasivos... o la conviertes en algo que nadie había previsto.

Tú decides.

¿Tienes alguna idea favorita de la lista? Cuéntamela. O mejor aún, envíasela a un amigo y compartid ideas mientras coméis tacos. Así es como nacen las mejores ideas, de todos modos.