Tu trabajo es entregar código con funcionamiento comprobado

• En los entornos de desarrollo asistidos por IA, están aumentando los casos en que ingenieros con poca experiencia envían PR enormes sin validar
• La misión principal de un desarrollador no es simplemente escribir código, sino entregar código con funcionamiento comprobado
• Para lograrlo, es indispensable realizar dos pasos: pruebas manuales y pruebas automatizadas
• También hay que configurar a los agentes de codificación para que verifiquen por sí mismos los cambios que generan
• Al final, la responsabilidad recae en el desarrollador humano, y solo tiene verdadero valor el código acompañado de evidencia de validación

---

El problema de enviar código sin validar

• Se menciona el caso de ingenieros junior que, usando herramientas con LLM, envían PR gigantes sin validar y dependen del code review
  • Esto se señala como algo descortés e ineficiente, además de una renuncia a la responsabilidad propia del desarrollador
• El rol de un ingeniero de software no es simplemente producir código, sino entregar código con funcionamiento comprobado
  • El código no validado se considera una forma de trasladarle la carga al revisor

Dos pasos para demostrar que el código funciona

• El primer paso es la prueba manual, donde hay que confirmar directamente que el código funciona correctamente
  • Se requiere preparar el sistema en un estado inicial, aplicar el cambio y luego verificar el resultado
  • Se puede demostrar adjuntando comandos de terminal y sus resultados en los comentarios del code review, o con una grabación de pantalla
  • Después de confirmar el funcionamiento normal, hay que buscar problemas mediante pruebas de casos límite
• El segundo paso es la prueba automatizada, que se enfatiza como un procedimiento esencial gracias al avance de las herramientas basadas en LLM
  • Los cambios deben incluir pruebas automatizadas, y si se revierte la implementación, esas pruebas deben fallar
  • Escribir pruebas sigue el mismo procedimiento que la prueba manual, y la capacidad de integrar un test harness es clave
  • Se señala que asumir que las pruebas automatizadas por sí solas son suficientes y omitir las pruebas manuales es un enfoque equivocado

El rol y la validación de los agentes de codificación

• Una de las principales tendencias del mundo LLM en 2025 es el rápido crecimiento de los agentes de codificación, como Claude Code y Codex CLI
  • Estos pueden ejecutar código y corregir problemas por su cuenta
• Los agentes de codificación también deben demostrar sus propios cambios, realizando pruebas manuales y automatizadas
  • En el caso de herramientas CLI, se les puede entrenar para que ejecuten las verificaciones directamente, o automatizarlo con sistemas como CLIRunner de Click
  • En cambios de CSS, es posible configurarlos para verificar el resultado mediante capturas de pantalla
• Si el proyecto ya tiene pruebas existentes, el agente puede ampliarlas o reutilizar sus patrones
  • La estructura y la calidad del código de pruebas afectan directamente la calidad de las pruebas que genera el agente
  • Se menciona que el sentido estético aplicado al código de pruebas es una capacidad clave que distingue a los ingenieros senior

La responsabilidad humana y el valor del código

• Las computadoras no pueden asumir responsabilidad, así que ese papel debe recaer en los humanos
  • Que un LLM genere parches grandes ya no es, por sí solo, algo valioso
• El verdadero valor está en entregar código con funcionamiento comprobado
  • Al enviar un PR, es indispensable incluir evidencia de que el código funciona correctamente

[ethanhur]

Estoy muy de acuerdo. En la forma actual de trabajar con PR, la responsabilidad del código termina trasladándose a los maintainers y reviewers. Quien envía código generado por LLM sin revisarlo no tiene ninguna desventaja.

Al contribuir al codebase de Google, parece que miden cosas como el crédito de cada contributor; creo que otros proyectos open source y empresas también terminarán adoptando algo así. Da la impresión de que la confianza se volverá un activo todavía más importante.

[roxie]

Oh, así que Google usa ese concepto.

[tested]

> Ingeniería vibe

[GN⁺]

Comentarios de Hacker News

• Últimamente se ve mucho una anécdota deprimente: ingenieros junior potenciados por herramientas LLM que le avientan PR enormes y sin probar a sus colegas o a maintainers de proyectos open source, esperando que el code review resuelva el resto. Lo peor es que este comportamiento no solo viene de juniors, sino también de desarrolladores senior

  • Justo ayer y hoy hice exactamente eso. Nuestro equipo recibió un bug report y pensamos que era problema de un vendor externo. Pero el vendor lo rebotó diciendo que el problema era nuestro. Entonces le pedí a Codex que lo revisara, encontró el problema y preparó un PR. Yo no lo revisé ni lo probé directamente, sino que dejé la validación al equipo. Ese proceso ayudó a enseñar al equipo a usar LLM como herramienta de trabajo
  • En los últimos dos días, dos miembros del equipo que no son desarrolladores le preguntaron a un agente de IA cómo arreglar bugs móviles, y luego subieron esas respuestas como contenido principal del ticket. Al final tuve que leer todo eso y volver a identificar los requisitos reales
  • Hay mucha gente con el título de “senior” que actúa como junior. Parece un fenómeno de estos tiempos, donde con apenas dos años de graduado ya te llaman senior
  • Los desarrolladores que ignoran o se saltan las reglas son los más peligrosos. Me recuerdan a los desarrolladores 10x que conocí antes. Si ignoran las reglas y solo sueltan funcionalidades, al final otros tienen que limpiar el desastre
  • Durante el code review me pregunto dónde están los desarrolladores junior. Si no participan en las revisiones, es difícil que sientan responsabilidad por la calidad de su código

• Cómo escribir un buen PR aplica no solo al código generado por IA, sino a cualquier caso. Cuando escribo la descripción de un PR, organizo en orden cómo funciona actualmente, por qué se hace el cambio y qué se modificó. También incluyo cómo probarlo, screenshots e incluso comandos de pruebas E2E para reducir la carga del reviewer. Esto también ayuda en colaboración asíncrona o en equipos con diferencia horaria

  • Antes de pedir review, yo mismo lo reviso una vez más. Si corrijo de antemano detalles menores como typos o quitar logs, puedo ahorrar tiempo al reviewer. Las revisiones de Copilot también detectan bien ese tipo de cosas
  • Aunque escriba explicaciones detalladas, muchas veces nadie las lee. Aun así sigo haciéndolo por un sentido de responsabilidad
  • Sea un PR asistido por IA o no, debe incluir evidencia de pruebas y validación
  • Antes escribía descripciones largas, pero me di cuenta de que nadie las leía. Resumir lo esencial en bullet points resultó mucho más efectivo
  • El template de PR de nuestro equipo incluye número de ticket, descripción de la solicitud, estado actual, estado después del cambio e incluso un ‘mood gif’

• La esencia de un ingeniero es entender los requisitos, convertirlos en un flujo lógico, ajustar los trade-offs y hacerse responsable del resultado. Generar código o aventar PRs al azar es síntoma de que faltan esos fundamentos. Los agentes de coding más bien están sirviendo para volver a recordarnos la esencia de la ingeniería

  • En este artículo se ve un caso donde una sola línea de código causó una pérdida de 60 millones de dólares. Un PR de 10 mil líneas hecho por IA sin entender el código es un desastre potencial
  • En la práctica, las empresas priorizan marketing y rentabilidad por encima de la calidad. Los productos con etiqueta ‘premium’ venden mejor que los productos de alta calidad. Al final, la estructura pone por delante lo “vendible” antes que la ingeniería
  • Pero el problema es que si la organización te presiona con “usa IA y termina la funcionalidad en tres días o te vas a reunión con HR”, se vuelve difícil sostener principios ideales de ingeniería

• Las pruebas son necesarias, pero no suficientes. El código también debe validarse lógicamente. Las pruebas solo demuestran que funciona correctamente bajo ciertas entradas y ciertos entornos

  • Pienso lo mismo. Incluso un código que funciona bien puede seguir siendo pésimo
  • Más que “probar”, la palabra correcta sería “demostrar (demonstrate)”. Las pruebas son solo evidencia en casos concretos
  • No confío solo en las pruebas; también intento romper la app yo mismo de distintas maneras. En ese proceso termino mejorando el código
  • Como la mayoría del código no puede probarse formalmente, un enfoque como property-based testing podría ser útil
  • Aunque llegues a 100% de test coverage, si el código no es robusto no significa mucho

• Yo no hago pruebas por obligación. Las hago simplemente porque quiero ver que el código realmente funciona. Si no te emociona ver correr tu código, este trabajo no es para ti

• He escuchado historias de juniors aventando PRs enormes gracias a LLM, pero en nuestra organización todavía no pasa eso

  • No son PRs enormes, pero sí veo seguido código generado por LLM que el desarrollador no entiende
  • En nuestra organización también hay casos así. Los problemas son los siguientes
    • El agente revierte feedback previo
    • No sigue los estándares del codebase
    • Reinventa soluciones que ya existían
    • Responde al feedback del PR con salida del agente
    • Entrega un PR de 50 mil líneas cuando bastaban cambios de 10 a 20 líneas
    • Faltan pruebas y el manejo de errores es deficiente
  • La gente que antes ya entregaba PRs de baja calidad ahora simplemente los entrega más rápido gracias a LLM
  • Si ves WireGuard Android PR #82 y #80, quedó intacta una respuesta copiada y pegada de la IA. Si abres la pestaña “files changed”, resulta confuso
  • Un amigo trabaja en una startup de 11 personas, y el CTO empuja directo a main código de 10 mil líneas a las 3 a. m. En fase exploratoria puede pasar, pero en fase de estabilización es un riesgo espantoso

• No estoy de acuerdo con eso de que “tu trabajo es entregar código en estado probado”. El trabajo real es resolver problemas de negocio. Claro, en la mayoría de los casos eso termina en código, pero la distinción es importante

  • Pero demostrar la corrección del código es parte de resolver problemas de negocio. No es algo separado
  • No puedes resolver un problema de negocio entregando código que no cumple los requisitos
  • Lo importante es resolver el problema sin crear otros nuevos. Por eso hacen falta seguridad y estabilidad
  • Tal vez porque todavía tengo poca experiencia, pero no entiendo cómo se supone que uno resuelve problemas con código no validado
  • Al final, todos los trabajos existen para resolver problemas. Solo que nosotros lo hacemos a través de computadoras

• En un trabajo anterior estuve en un fabricante japonés de hardware de alta calidad, y si el departamento de QA encontraba un bug, se detenía el lanzamiento del producto. Por eso cada departamento de desarrollo armó su propio equipo de QC para reforzar las pruebas previas. Como resultado, el software se validaba de forma muy exhaustiva

  • Me da curiosidad qué significa “get dinged”. Una estructura así también podría hacer que la gente le tenga miedo a cambiar cosas

• Hoy en día la esencia del trabajo se volvió cerrar tickets. Como la calidad del código no aparece en las métricas, deja de importar. Yo no participo en ese sistema. Ya desapareció la artesanía; ahora todos quieren madera contrachapada barata y pegamento

  • En el momento en que adoptas LLM por completo y esperas que todos lo usen, la ingeniería de software deja de ser una ingeniería seria
  • También hay quienes le responden a alguien que critica esa actitud con “entonces, ¿tú vives de subsidios del gobierno?”

• El problema está en qué significa “código probado”. También hay casos donde pegan pruebas hechas por LLM y entregan un PR enorme. Yo también hago vibe coding en proyectos personales, pero hacerlo así en equipo es un mal hábito. La razón por la que contratan ingenieros es para comprar su experiencia

  • Por eso yo enfatizo las pruebas manuales. Solo con mostrar el funcionamiento real mediante screenshots o videos ya puedes transmitir mucha confianza