Uncategorized

La IA Está Escribiendo tu Código: ¿Puedes Leerlo?

por

Seamos honestos: no nos gusta leer código tanto como nos gusta escribirlo. Se hace pesado y es más emocionante crear algo desde cero que desentrañar la lógica que ha creado otra persona o por una IA.

La legibilidad del código siempre ha sido importante. El principio es bien conocido: el código se escribe una vez, pero se lee muchas. Sin embargo, en la era de la IA, esta realidad se intensifica exponencialmente.

Piénsalo así:

  • Antes: leías código escrito por tu equipo
  • Ahora: lees código escrito por tu equipo + código generado por IA + código híbrido (humano-IA)
  • Futuro cercano: leerás principalmente código generado por IA que otros han revisado y modificado

La habilidad de leer código críticamente se está convirtiendo en la competencia diferencial del desarrollador moderno. No se trata solo de entender qué hace el código, sino de evaluar:

  • ¿Es fácil de comprender?
  • ¿Es mantenible a largo plazo?
  • ¿Se ajusta a las buenas prácticas de la industria?
  • ¿Contiene agujeros de seguridad?

En este contexto, la legibilidad del código no es solo una «buena práctica», es una estrategia de supervivencia. Los desarrolladores que dominen el arte de leer y criticar código tendrán una ventaja competitiva clara.

Esto significa que:

  • Invertir tiempo en mejorar las habilidades de lectura crítica de código es fundamental.
  • Para equipos: establecer estándares de legibilidad estrictos y procesos de revisión robustos no es opcional, es esencial. Además de ser una forma excelente de hacer transferencia del conocimiento.
  • Debemos usar la IA de forma que genere código que sea fácil de comprender y se ajuste al estilo que nosotros queramos.

Recuerda lo que dijo Martin Fowler: el código se escribe para que lo lean los humanos y solo incidentalmente para la máquina.

¿Tu código cuesta de leer? Te ayudo a ti, a tu equipo y a tu IA a escribir código más limpio y mantenible.

Firebase sin humo: lecciones reales de usar serverless en producción

por

En un proyecto reciente para una startup en etapa temprana, me tocó ir más allá del desarrollo móvil y asumir el desarrollo backend con Firebase.

Stack actual:

  • Firestore como base de datos
  • Firebase Functions para lógica backend
  • Migración de un código base en JavaScript hacia TypeScript

Lo interesante del proceso:
Venir del mundo frontend me dio herramientas que pude aplicar directamente:

  • Mantener buenas prácticas con TDD y arquitectura limpia
  • Reutilizar patrones async que ya conocía bien
  • Pensar en la experiencia de desarrollo de forma integral, no dividida en “front” y “back”

Además, la IA fue un gran copiloto:

  • Me ayudó a cerrar gaps con nuevas librerías
  • A plasmar ideas en TypeScript más rápido
  • Y a reducir el tiempo en tareas repetitivas

Este proyecto fue un recordatorio de que salir del rol habitual puede abrir muchas puertas, sobre todo cuando te apoyas en principios sólidos.

Por Qué la Deuda Técnica Supera a la Financiera

por

La deuda técnica es peor que la financiera (y más fácil de adquirir)

Si pides dinero al banco o usas tu tarjeta de crédito, sabes (deberías) cuándo tendrás que devolverlo.

Pero con la deuda técnica, no.

No sabes cuándo vas a tener que pagarla. A veces es mañana. A veces dentro de años.
Y eso la hace más peligrosa.

Lo peor es que muchas veces no somos conscientes de que la estamos introduciendo.
Arrancas un proyecto sin definir principios, valores, metodologías, buenas prácticas…
Y sin darte cuenta, la deuda técnica empieza a colarse.
Silenciosa. Persistente. Acumulativa.

Además, no toda deuda técnica es igual.
Depende de dónde la introduces.

No es lo mismo hacer “trampas” en una zona periférica del sistema, que en el núcleo, en la capa de dominio.
Cuando la deuda está en el core, es mucho más costosa de pagar.

¿Mi postura? Haz siempre las cosas bien.
No sabes cuándo vas a tener que volver a ese código.
Y si vas a tener que devolver esa deuda…
Mejor que sea poca.

Si en tu empresa la deuda técnica empieza a doler, hablamos.

IA gratis para todos: mis favoritas y cómo las uso

por

Trabajar como ingeniero de software freelance implica mucho más que programar: Propuestas, reuniones, tareas administrativas, marketing, creación de contenido… y todo lo que se te ocurra.

Aunque uso intensivamente la IA para programar, también me apoyo en otras herramientas para esas tareas más periféricas, pero igual de importantes. Aquí van las que más utilizo hoy por hoy:

🤖 LLMs (Modelos de lenguaje)

  • ChatGPT. Mi primera opción para redactar contenidos, pulir copies o generar imágenes. Versátil y rápido.
  • Gemini. Muy útil para búsquedas generales. Su función Deep Research es una joya: ideal para recopilar información actualizada desde internet. Es mi recurso estrella cuando quiero profundizar en un tema sin perderme en mil pestañas.
  • DeepSeek (R1). Perfecto para tareas complejas. Me encanta cómo desglosa el razonamiento paso a paso. Últimamente lo uso menos, porque modelos como GPT-4 o Gemini también están mejorando en este sentido, pero sigue siendo una gran alternativa.
  • Claude. Lo uso cuando quiero aplicar un estilo concreto al escribir. Tiene una función interesante: puedes pedirle que copie el estilo de un texto dado. Aunque suelo preferir mantener mi propio tono, es útil para casos específicos.

🧠 NotebookLM

Una herramienta que sorprende. Puedes subir textos, PDFs, documentos de Google Drive, incluso vídeos de YouTube. Te permite:
• Resumir contenido
• Hacer preguntas sobre éste
• Crear informes, esquemas mentales… ¡hasta podcasts!

Lo uso para:

  • Saber de qué va un vídeo largo sin verlo entero
  • Analizar documentos complejos
  • Consolidar conocimiento de un proyecto

Y sí, es gratuita. Por ahora. Aprovechala.

📝 Transcripción de reuniones

En reuniones estructuradas, tomo notas. Pero en una reunión exploratoria reciente con un potencial cliente, quería estar 100% presente. Pedí permiso para grabarla en audio.

Estuve probando herramientas para transcribirla y me quedo con Taqtiq:

  • Extensión de navegador
  • 10 reuniones al mes en su plan gratuito
  • Tambien transcribe audios grabados

¿Lo mejor? Transcripción lista y cargada en NotebookLM para sacarle todo el jugo.

Cómo escribir posts más rápido (y que suenen a ti)

por

Hoy quiero compartir una técnica que me ha ayudado a mantener constancia y calidad al escribir posts.

1️⃣ Empiezo por la idea

Cuando quiero escribir un post, lo primero que hago es definir el tema. A veces le pongo un título provisional solo para orientarme.

Enseguida me vienen ideas sueltas… y las anoto tal cual. No me preocupo por la forma, solo por capturar lo esencial. En esta etapa, lo importante es la calidad de las ideas, no cómo están escritas.

2️⃣ Le pido ayuda a la IA

Con esa lluvia de ideas, lanzo un prompt muy sencillo a mi LLM favorito: «Crea una publicación con las siguientes ideas. Sugiere cinco versiones diferentes.»

El objetivo no es que la IA escriba por mí, sino que me ayude a estructurar mejor el mensaje y hacerlo más claro.

3️⃣ Selecciono, mezclo y afino

Leo las 5 versiones que me devuelve y elijo la que mejor refleja lo que quiero transmitir. A veces mezclo partes de otras versiones. Le doy mi toque final, y voilà.

También le pido a la IA ideas para títulos y llamadas a la acción. Elijo las que más encajan y ¡post listo para publicar!

Confesión: Cuando empecé a publicar con regularidad, probé a delegar todo el post en la IA. ¿El resultado? Correcto, sí… pero sin alma. No transmitía mi forma de pensar ni mi estilo. Era impersonal.

En cambio, cuando las ideas son mías y la IA solo me ayuda a contarlas mejor, el resultado es radicalmente distinto: más auténtico, más potente, más yo.

En resumen: No se trata de si usamos IA o no. Se trata de cómo la usamos para potenciar lo que solo nosotros podemos aportar: nuestras ideas, experiencias y visión.

Más Allá del Código: Por qué los fundamentos definen al ingeniero de software

por

A veces me cuesta recordar cómo se declara un cliente Retrofit o cómo se define una base de datos con Room en Android. Y no me preocupa demasiado.

Después de más de 20 años trabajando con C++, MFC, POSIX, Java, Kotlin, PHP, C#, wxWidgets, Android, Flutter y más, he aprendido algo: los detalles concretos cambian, los fundamentos perduran.

Los paradigmas, las estructuras de datos, la orientación a objetos, la arquitectura de software, el pensamiento crítico… eso es lo que realmente da solidez profesional. Lo demás lo buscas en Google o lo preguntas a GPT.

Con la irrupción de la IA, el rol del ingeniero de software tiene que estar más arriba: tomar decisiones, entender el contexto, razonar, abstraer. Lo duradero se vuelve diferencial.

No estoy diciendo que no haya que conocer los detalles de cómo funciona una tecnología concreta. Al fin y al cabo, el software se ejecuta sobre ordenadores y esos detalles importan. Pero no confundamos los medios con los fines. Los fundamentos no caducan.

Si estás formando un equipo sólido que necesite pensamiento crítico y fundamentos sólidos, estoy interesado en colaborar. Escríbeme.

IA y TDD: ¿Compatibles o rivales?

por

Es una cuestión a la que sigo dándole vueltas.

Por un lado, la teoría del Test Driven Development (TDD) sigue siendo sólida: primero los tests, luego el código y después refactorizar.

Sus beneficios son innegables:

  • Código más modular y desacoplado
  • Documentación viva a través de tests
  • Regresiones detectadas al instante
  • Refactorización más segura

Por otro lado, llega la IA como ese nuevo compañero que parece hacer la vida más fácil: «Déjame generar todo ese código aburrido», «Aquí tienes tanto la implementación como los tests», «¿Para qué pensar tanto si puedo hacerlo por ti?». Luego solo revisas y ajustas.

Es tentador, terriblemente tentador.

A simple vista, el camino 2 parecería el más óptimo: más rápido, más eficiente. Pero ¿realmente lo es?

Aquí está el meollo del asunto: cuando pides a una IA que genere código y tests en un solo paso, estás saltándote la fase más valiosa del TDD: el proceso de pensamiento.

¿IA que entiende tu código? Así funciona Copilot Agent

por

Hace poco intenté generar tests para un código preexistente usando GitHub Copilot en Android Studio y Visual Studio Code. Primero probé con el modo «Edit»… y fue un desastre.

El código generado:

  • No seguía el estilo del proyecto.
  • No compilaba por múltiples errores.
  • Requería demasiada corrección manual.

Cuando yo estaba decido a darlo por imposible, probé con el modo «Agent» y el resultado fue brutal. El código generado compiló sin problemas, seguía el mismo estilo que el resto de código y hacía lo que tenía que hacer. ¡Genial!

✨ ¿Por qué esta diferencia?

Porque el contexto es la clave para que un LLM genere buenos resultados.

El punto de partida fue el mismo en ambos casos, indiqué el fichero de código sobre el que debía basarse. Sin embargo (lo puedes ver en las capturas):

❌ Modo «Edit»: Se limitó a leer dicho fichero y generar los tests a partir de ahí.
✅ Modo «Agent»: En primer lugar buscó otros tests similares en el código para entender cómo estaban hechos y seguir el mismo estilo. Luego generó el código.

Resultado: mucho mejor código y menos tiempo perdido.

Sin duda, voy a seguir usando el modo «Agent» de Copilot en mi día a día, pero se puede hacer mejor.

Me explico.

Copilot Agent actúa como un programador que llega a un proyecto nuevo: busca otro código parecido al que quiere crear y lo toma como referencia. Al principio está bien, pero a larga lo ideal es que esta persona interiorice este conocimiento. Aunque acabe consultando algún detalle concreto, conocer el proyecto en global le hará ser más eficiente y efectivo. Algo parecido es los que ofrecen otras herramientas como Aider o Cline. Construyen una base de conocimiento a partir del código existente que después utilizan para poder incorporar a la ventana de contexto los detalles necesarios para que el LLM acabe generando el mejor resultado.

Diario de Decisiones Contundentes

por

¿Decisiones complejas? Esta técnica te ayuda a elegir con más claridad

El otro día descubrí el Diario de Decisiones Contundentes gracias a la newsletter de Daniel Primo, que desde aquí recomiendo.

La idea es, al tomar decisiones no triviales, documentar los siguientes apartados:

  1. El reto: Describir el problema a resolver.
  2. Las soluciones alternativas: Evaluar las opciones disponibles.
  3. La decisión escogida: Explicar la opción elegida y las razones detrás de esa elección.
  4. Las consecuencias: Registrar los efectos de la decisión una vez implementada.

He estado aplicando esta técnica en un proyecto de desarrollo de una app, y la verdad es que estoy encantado. Estas son las principales ventajas que he encontrado:

  • Es simple de aplicar.
  • Facilita tomar decisiones de forma más racional y fundamentada.
  • Documenta el proceso, lo que permite incorporarlo al repositorio de código o a un repositorio documental del proyecto.
  • Facilita el reporte al equipo, ya que las decisiones quedan registradas de forma clara.
  • Al tenerlo por escrito, puedes compartirlo con un LLM para que analice y critique la decisión, aportando más perspectiva.

Aún no he completado la sección de consecuencias en varias decisiones, pero los otros apartados ya aportan suficiente valor como para seguir usando esta técnica.

Sin duda, pienso seguir utilizándola en el futuro porque estoy convencido de que me ayudará a mejorar mis decisiones.

Las herramientas de IA que uso para programar

por

🚀 Las herramientas de IA que uso para programar

Desarrollo aplicaciones móviles, principalmente nativas para Android y multiplataforma con Flutter. La mayor parte de mi trabajo lo realizo en Android Studio, aunque también utilizo otras herramientas según la tarea.

🤖 Mis herramientas de IA favoritas

GitHub Copilot (de pago) en Android Studio

Uso tanto el autocompletado como el chat integrado.

Para el chat, prefiero el modelo Claude 3.7 Sonnet y reservo los modelos más avanzados (con cadenas de razonamiento) para problemas complejos.

El chat inline lo utilizo ocasionalmente cuando el autocompletado no es suficiente.

Visual Studio Code + Copilot

Hasta hace poco, era la única forma de acceder a Copilot Edits, por lo que alternaba entre VS Code y Android Studio.

¡Ahora Copilot ya está disponible en Android Studio! Así que, en breve, puede que ya no necesite cambiar de entorno.

Chatbots especializados

Cuando las herramientas anteriores no bastan, recurro a varios asistentes:

  • ChatGPT, Gemini y Claude para consultas generales.
  • DeeSeek R1 para los problemas más complejos.

🛑 Lo que he probado y ya no uso

🔻 Codeium en Android Studio

Es una gran opción gratuita, pero el autocompletado de Copilot es más rápido y preciso, así que lo desactivé.

🔻 Cursor

Antes lo usaba mucho para editar código, pero desde que Copilot lo incluye, ya no lo necesito.

🔻 Gemini en Android Studio

Lo probé, pero tiene menos funcionalidades y sus resultados no me convencieron.

🔍 Este es mi set actual, aunque siempre estoy explorando nuevas opciones.