Mes: febrero 2025

En un post anterior os contaba cómo ayuda la IA para programar. Hoy os comparto las limitaciones:

🌐 Contexto reducido. La ventana de contexto, como nuestra memoria a corto plazo, es muy reducida. Insuficiente para acomodar todo el código de un proyecto mediano. Si quieres que lo tenga en cuenta (¡y más vale!), tienes que seleccionar los ficheros relevantes, a veces manualmente.

🧠 Conocimiento desconocido. Para proyectos de cierta envergadura, mucho conocimiento no está en el código. A menudo ni siquiera en documentos o bases de datos. El conocimiento tribal o tu propia experiencia son desconocidas para la IA y no los puede tener en cuenta, claro.

🤖 Los agentes están verdes. Existen herramientas que tratan de automatizar partes del proceso del software, pero todavía están verdes. Por ejemplo, ayudaría mucho una herramienta que se ponga a probar la aplicación después de hacer algunos cambios, y no hablo de tests de integración.

⭐ La popularidad importa. La IA se ha entrenado con internet. No sorprende que funcione mejor con los problemas y lenguajes de programación más populares. Si no eres de los populares de la clase, te toca iterar y probar diferentes modelos y prompts

⏱️ Es lenta. Especialmente cuando le pides que edite código. Toca esperar varios segundos y eso rompe el flujo de trabajo. Prefiero el autocompletado siempre que sea posible.

📅 No ve más allá del cut off date. Con lo cual desconoce las últimas novedades (por ejemplo, de librerías) y no te puede ayudar con eso.

El otro día preguntaron en una comunidad sobre IA hasta qué punto es posible programar sin saber programar.

Llevo usando la IA como herramienta de apoyo a la programación a diario desde hace más de dos años (CoPilot, ChatGPT y otros), así que me animé a participar.

Mi respuesta:

Para cosas simples: sí. Te permite crear pequeños scripts o aplicaciones sencillas rápidamente con unos resultados muy buenos.

Para un uso más avanzando (actualmente): la cosa cambia. El valor principal que te aporta es la mejora de la  eficiencia. Pero tienes que ser tú el que valide las soluciones y tenga claro por dónde quires ir. Es como un ayudante superdotado al que le tienes que pedir las cosas en detalle y cuyo resultado debes supervisar.

Y mí me ayuda a:

• Editar código. Especialmente boilerplate, código simple o que puede deducirse por el contexto.
• Resolver dudas. Para cosas comunes, aunque todavía sigo usando StackOverflow para cosas más específicas.
• Prevenir bugs.
• Tomar decisiones.
• Aprender.
• Documentar.

Ojo, también hay muchas limitaciones. Pero eso da para otro post.

Y a ti, ¿cómo te ayuda la IA para programar?

El otro día mi coach David Domínguez (aunque a él no le acaba de gustar que le llamen así 😜), me recordó algo básico pero que a veces se nos puede olvidar a los freelances. Y es que, como en cualquier otro negocio, ser freelance implica gestionar varios departamentos. Te lo resumo en un esquema muy sencillo.

Marketing → Ventas → Producto

• Marketing: lo que nos trae posibles clientes. Que te conozcan, sepan qué servicios ofreces y por qué te tienen que contratar a ti.
• Ventas: cerrar tratos. Reuniones de prospección, propuestas, presupuestos, etc.
• Producto: lo que aporta valor al cliente final. El servicio por el que se nos paga.

Para dar un servicio debes vender. Para vender debes hacerte ver. ¿Sencillo no? Pues bien, la mayoría de los freelances caemos en la «trampa del producto». Nos centramos en dar un servicio excelente y descuidamos nuestros canales de marketing y ventas. Esta es una receta para el desastre 🔥. Es precisamente cuando estas hasta arriba de trabajo que hay que redoblar los esfuerzos en marketing, plantando las semillas del crecimiento futuro.

No lo olvides: 📝
💼 Estás dirigiendo un negocio, no solo entregando un servicio. 
💸 La excelencia del producto por sí sola no sostendrá tu carrera freelance
🔥 Marketing y ventas no son opcionales – son esenciales
🌞 El éxito de hoy no garantiza el éxito de mañana

En mi experiencia, para lograr un producto de calidad—minimizando la deuda técnica y maximizando el retorno de la inversión (ROI)—es crucial centrarse en los siguientes aspectos:

• Arquitectura evolutiva. Una buena arquitectura sirve como base para acomodar la complejidad. Pero no debe ser un precepto rígido que hay que seguir de forma dogmática. Es importante diseñar pensando en la capacidad de cambio, no en alcanzar la perfección. Llevar a cabo de forma rutinaria pequeños refactorings como parte del desarrollo contribuye a mantener la arquitectura en forma y prepararla para los cambios. Esto no solo facilita la adaptación a nuevos requisitos, sino que también mejora la calidad del código y reduce la deuda técnica.
• Separación de responsabilidades. Cada componente debe tener un propósito claro y específico. Debe hacer una única cosa y hacerla bien. Esto facilita el testing y permite que diferentes personas trabajen en paralelo sin pisarse. Además, esta práctica mejora la mantenibilidad del código, ya que reduce el alcance los cambios. Asimismo, la separación de responsabilidades fomenta la reutilización de código, ya que los componentes bien definidos pueden ser utilizados en diferentes contextos.
• Feedback loops cortos. Obtener feedback constante durante todo el proceso, en lugar de solo al final permite identificar y corregir errores rápidamente, lo que reduce costos y mejora la calidad del producto final. También facilita la adaptación a cambios, fomenta la innovación y mejora la comunicación entre el equipo y el cliente. Para implementarlos, es fundamental crear una cultura de feedback abierto y hacer partícipe al cliente del proceso. Implementar procesos que permitan detectar problemas temprano – tests unitarios, analizadores estáticos de código, CI/CD y monitorización en producción facilita la puesta en práctica.
• Testing estratégico. No se trata de alcanzar una cobertura del 100%, sino de encontrar el equilibrio adecuado:
  • Tests unitarios: Numerosos tests pequeños y rápidos que protejan la lógica del sistema y permitan refactorizar con seguridad.
  • Tests de integración o de flujo: Unos pocos tests más complejos (y lentos) que verifiquen los flujos críticos.
  Escribir los tests antes que el código de producción (TDD) no solo crea una red de seguridad, sino que también facilita la modularización y la separación de responsabilidades.
• Documentación como parte del diseño. Más que elaborar extensos documentos, se trata de mantener un código autodocumentado y registrar de forma concisa las decisiones arquitectónicas clave. El código debe ser limpio y fácil de leer. Los comentarios deben reservase para explicar decisiones complejas o funciones con alto potencial de reutilización. Una arquitectura que «grite» su propósito con solo abrir el proyecto. La documentación debe tratarse como el código en producción y mantenerla actualizada en consecuencia. 

La clave está en encontrar el balance. Un diseño muy simple puede volverse caótico con el tiempo, mientras que uno muy elaborado puede ser tan rígido que dificulte la evolución natural del producto.

Y tú, ¿qué prácticas consideras fundamentales para mantener la calidad del software a largo plazo?