Cómo la IA equilibra rendimiento, legibilidad y simplicidad en el código

Qué significa equilibrar rendimiento, legibilidad y simplicidad

Antes de juzgar si la IA “equilibró” algo, ayuda nombrar de qué tipo de código estamos hablando.

Lógica de aplicación es el código que expresa las reglas y flujos de tu producto: comprobaciones de elegibilidad, decisiones de precios, transiciones de estado de pedidos, permisos y pasos de “qué sucede después”. Es la parte más ligada al comportamiento del negocio y la que más suele cambiar.

Código de infraestructura es la plomería: conexiones a bases de datos, servidores HTTP, colas de mensajes, configuración de despliegue, pipelines de logging e integraciones. Importa, pero por lo general no es donde codificas las reglas centrales de la app.

Los tres objetivos — y qué significan realmente

Rendimiento significa que el código hace el trabajo usando tiempo y recursos razonables (CPU, memoria, llamadas de red, consultas a BD). En la lógica de aplicación, los problemas de rendimiento suelen venir de I/O extra (demasiadas consultas, llamadas API repetidas) más que de bucles lentos.

Legibilidad significa que un compañero pueda entender con precisión qué hace el código, por qué lo hace y dónde cambiarlo — sin tener que “debuggear en la cabeza” durante una hora.

Simplicidad significa menos partes móviles: menos abstracciones, menos casos especiales y menos efectos secundarios ocultos. El código simple suele ser más fácil de testear y más seguro de modificar.

Por qué estos objetivos entran en conflicto en proyectos reales

Mejorar un objetivo a menudo tensiona a los otros.

El caching puede acelerar las cosas pero añade reglas de invalidación. Abstracciones pesadas pueden eliminar duplicación pero hacer el flujo más difícil de seguir. Micro-optimizaciónes pueden reducir el tiempo de ejecución mientras hacen la intención poco clara.

La IA también puede “sobresolver” problemas: proponer patrones generalizados (factories, objetos strategy, helpers elaborados) cuando una función directa sería más clara.

Cómo es “lo suficientemente bueno”

Para la mayoría de equipos, “lo suficientemente bueno” es:

• Flujo de control y nombres claros, con abstracción mínima
• Rendimiento que cumple los SLA actuales, evitando cuellos de botella obvios (especialmente viajes extra a BD/APIs)
• Seams sencillos para pruebas, de modo que los cambios se puedan hacer con seguridad

Equilibrar suele significar desplegar primero código fácil de mantener y complicarse solo cuando las mediciones (o incidentes reales) lo justifican.

Cómo suele elegir la IA la estructura del código

La IA no “decide” la estructura como lo haría un ingeniero. Predice los tokens más probables según tu prompt y los patrones que ha visto. Eso significa que la forma del código está fuertemente influida por lo que pides y lo que muestras.

Optimiza lo que pides (y tus ejemplos)

Si pides “la solución más rápida”, a menudo obtendrás caching adicional, salidas tempranas y estructuras de datos que priorizan la velocidad — incluso cuando la ganancia es marginal. Si pides “limpio y legible”, normalmente obtendrás nombres más descriptivos, funciones más pequeñas y un flujo de control más claro.

Proveer un ejemplo o el estilo de código existente es aún más poderoso que adjetivos. Un modelo reflejará:

• Convenciones de nombres y límites de función
• Patrones de manejo de errores (excepciones vs. valores de retorno)
• Abstracciones preferidas (helpers, services, repositories)

Fallos comunes a vigilar

Porque la IA es buena ensamblando patrones, puede derivar a soluciones “ingeniosas” que impresionan pero son más difíciles de mantener:

• Sobreingeniería: capas innecesarias, factories, interfaces o helpers genéricos para una característica simple
• Código ingenioso: one-liners densos, comprehensions complicadas o encadenamientos funcionales que ocultan la intención
• Optimización prematura: micro-optimizaciónes (caching manual, ordenaciones personalizadas) sin medir

Los datos de entrenamiento moldean el estilo y los valores por defecto

La IA aprende de una mezcla amplia de código real: librerías limpias, código de aplicaciones apresurado, soluciones de entrevistas y ejemplos de frameworks. Esa variedad explica por qué puedes ver elecciones estructurales inconsistentes: a veces idiomáticas, a veces demasiado abstractas, a veces extrañamente verbosas.

Los humanos siguen siendo dueños del trade-off final

El modelo puede proponer opciones, pero no puede conocer completamente tus restricciones: nivel de habilidad del equipo, convenciones del codebase, tráfico en producción, fechas de entrega y coste de mantenimiento a largo plazo. Trata la salida de la IA como un borrador. Tu trabajo es elegir qué trade-off quieres realmente — y simplificar hasta que la intención sea obvia.

El triángulo de trade-offs en la lógica de aplicación cotidiana

La lógica de aplicación cotidiana vive dentro de un triángulo: rendimiento, legibilidad y simplicidad. El código generado por IA a menudo parece “razonable” porque intenta satisfacer los tres, pero los proyectos reales te obligan a escoger qué vértice importa más para una parte específica del sistema.

Trade-offs que reconocerás de inmediato

Un ejemplo clásico es cache vs claridad. Añadir una caché puede hacer una petición lenta rápida, pero también introduce preguntas: ¿Cuándo expira la caché? ¿Qué pasa tras una actualización? Si las reglas de caché no son obvias, quienes revisen el código las usarán mal o las “arreglarán” incorrectamente.

Otra tensión común es abstracciones vs código directo. La IA puede extraer helpers, introducir utilidades genéricas o añadir capas (“service”, “repository”, “factory”) para parecer limpio. A veces mejora la legibilidad. Otras veces oculta la regla de negocio real tras indirecciones, haciendo los cambios simples más difíciles.

Cuando las micro-optimizaciónes dañan la comprensión

Pequeños ajustes — prealocar arrays, one-liners ingeniosos, evitar una variable temporal — pueden ahorrar milisegundos mientras cuestan minutos de atención humana. Si el código no está en un camino crítico, esas micro-optimizaciónes suelen ser una pérdida neta. Nombres claros y flujo directo ganan.

Cuando lo “simple” se vuelve lento a escala

En el otro extremo, el enfoque más simple puede colapsar bajo carga: consultar dentro de un bucle, recalcular el mismo valor repetidamente o traer más datos de los necesarios. Lo que lee bien para 100 usuarios puede volverse costoso para 100.000.

Una regla práctica

Empieza con la versión más legible que sea correcta. Luego optimiza solo donde tengas evidencia (logs, profiling, métricas reales) de que el código es un cuello de botella. Esto mantiene la salida de la IA comprensible y te permite ganar rendimiento donde importa.

Cómo pedir a la IA que genere la lógica adecuada

La IA generalmente hace lo que pides — literalmente. Si tu prompt es vago (“hazlo rápido”), puede inventar complejidad que no necesitas o optimizar la cosa equivocada. La mejor manera de dirigir la salida es describir cómo se ve lo bueno y qué no intentas hacer.

Empieza con criterios de aceptación (y non-goals)

Escribe 3–6 criterios de aceptación concretos que se puedan comprobar rápidamente. Añade non-goals para evitar desvíos “útiles”.

Ejemplo:

• Criterios de aceptación: “Debe devolver resultados en menos de 200ms para 10k registros; los errores deben ser amigables al usuario; mantener funciones por debajo de ~40 líneas.”
• Non-goals: “Sin capa de caching; sin dependencias nuevas; sin cambios de esquema.”

Especifica restricciones que el modelo no puede adivinar

Rendimiento y simplicidad dependen del contexto, así que incluye las restricciones que ya conoces:

• objetivos de latencia (p95, p99 si los tienes)
• tamaño de datos y expectativas de crecimiento
• concurrencia (usuario único vs muchas solicitudes paralelas)
• límites de memoria (topes serverless, dispositivos móviles, etc.)

Incluso números aproximados son mejores que ninguno.

Pide una “versión simple primero” y una “versión optimizada”

Solicita explícitamente dos versiones. La primera debe priorizar la legibilidad y un flujo de control directo. La segunda puede añadir optimizaciones cuidadas, pero solo si sigue siendo explicable.

Write application logic for X.
Acceptance criteria: ...
Non-goals: ...
Constraints: latency ..., data size ..., concurrency ..., memory ...
Deliver:
1) Simple version (most readable)
2) Optimized version (explain the trade-offs)
Also: explain time/space complexity in plain English and note any edge cases.

Requiere explicaciones y complejidad en lenguaje llano

Pide al modelo que justifique las elecciones de diseño clave (“¿por qué esta estructura de datos?”, “¿por qué este orden de ramas?”) y que estime la complejidad sin jerga. Esto facilita revisar, testear y decidir si la optimización vale la pena.

Patrones que mantienen legible la lógica generada por IA

La legibilidad rara vez se trata de sintaxis sofisticada. Se trata de hacer que la siguiente persona (a menudo tú en el futuro) entienda lo que el código hace de un vistazo. Cuando usas IA para generar lógica, algunos patrones producen consistentemente salidas que siguen siendo claras después del efecto novedad.

Mantén funciones pequeñas y de un solo propósito

La IA tiende a “ayudar” agrupando validación, transformación, persistencia y logging en una función grande. Empújala hacia unidades más pequeñas: una función para validar la entrada, otra para calcular el resultado y otra para almacenarlo.

Una regla útil: si no puedes describir la tarea de una función en una frase corta sin usar “y”, probablemente haga demasiado.

Prefiere flujo de control directo

La lógica legible favorece ramificaciones obvias sobre compresiones ingeniosas. Si una condición es importante, escríbela como un bloque if claro en vez de un ternario anidado o una cadena de trucos booleanos.

Cuando veas que la IA genera “haz todo en una expresión”, pide “returns tempranos” y “guard clauses” en su lugar. Eso reduce anidamiento y hace fácil ver el camino feliz.

Nombra las cosas como un compañero las mantendría

Nombres significativos vencen a patrones de “helper genérico”. En lugar de processData() o handleThing(), prefiere nombres que codifiquen intención:

• calculateInvoiceTotal()
• isPaymentMethodSupported()
• buildCustomerSummary()

También ten cuidado con utilidades excesivamente genéricas (por ejemplo, mapAndFilterAndSort()): pueden ocultar reglas de negocio y dificultar el debugging.

Comenta la intención, no la mecánica

La IA puede producir comentarios verbosos que simplemente repiten el código. Mantén comentarios solo donde la intención no sea obvia: por qué existe una regla, qué caso límite se protege o qué suposición debe mantenerse verdadera.

Si el código necesita muchos comentarios para ser entendible, considérelo una señal para simplificar la estructura o mejorar los nombres — no para añadir más palabras.

Decisiones de diseño que preservan la simplicidad

La simplicidad rara vez consiste en escribir “menos código” a toda costa. Consiste en escribir código que un compañero pueda cambiar con confianza la próxima semana. La IA puede ayudar aquí si la empujas hacia elecciones que mantengan la forma de la solución sencilla.

Empieza con la estructura de datos más simple que funcione

La IA suele saltar a estructuras ingeniosas (maps de maps, clases personalizadas, genéricos anidados) porque parecen “organizadas”. Resiste. Para la mayoría de la lógica de aplicación, arrays/listas y objetos simples son más fáciles de razonar.

Si sostienes un conjunto pequeño de elementos, una lista con un filter/find claro suele ser más legible que construir un índice prematuramente. Introduce un map/diccionario solo cuando las búsquedas sean realmente centrales y repetidas.

Limita capas de abstracción hasta tener necesidades repetidas

Las abstracciones parecen limpias, pero demasiadas ocultan el comportamiento real. Al pedir código a la IA, prefiere soluciones de “un nivel de indirección”: una función pequeña, un módulo claro y llamadas directas.

Una regla útil: no crees una interfaz genérica, factory y sistema de plugins para resolver un único caso de uso. Espera a ver la segunda o tercera variación y luego refactoriza con confianza.

Prefiere composición sobre herencia profunda

Los árboles de herencia dificultan responder: “¿De dónde viene realmente este comportamiento?” La composición mantiene las dependencias visibles. En lugar de class A extends B extends C, favorece pequeños componentes que puedas combinar explícitamente.

En prompts, puedes decir: “Evitar herencia salvo que haya un contrato compartido estable; preferir pasar helpers/servicios como parámetros.”

Usa patrones comunes y familiares para tu equipo

La IA puede sugerir patrones técnicamente correctos pero culturalmente ajenos a tu codebase. La familiaridad es una característica. Pide soluciones que coincidan con tu stack y convenciones (nombres, estructura de carpetas, manejo de errores), para que el resultado encaje naturalmente en la revisión y el mantenimiento.

Rendimiento sin hacer el código difícil de leer

El trabajo de rendimiento sale mal cuando optimizas lo equivocado. El mejor código “rápido” suele ser simplemente el algoritmo correcto aplicado al problema real.

Elige el algoritmo correcto antes de afinar

Antes de retocar bucles o one-liners ingeniosos, confirma que estás usando un enfoque sensato: un hash map en lugar de búsquedas lineales repetidas, un set para comprobaciones de pertenencia, una pasada única en vez de múltiples escaneos. Al pedir ayuda a la IA, sé explícito sobre restricciones: tamaño de entrada esperado, si los datos vienen ordenados y qué significa “suficientemente rápido”.

Una regla simple: si la complejidad está mal (por ejemplo, O(n²) en listas grandes), ninguna micro-optimización la salvará.

Mide primero (con tamaños de entrada reales)

No adivines. Usa profiling básico, benchmarks ligeros y —lo más importante— volúmenes de datos realistas. El código generado por IA puede parecer eficiente mientras oculta trabajo caro (como parseos repetidos o consultas extra).

Documenta lo que mediste y por qué importa. Un comentario corto como “Optimizado para 50k items; la versión anterior tardaba ~2s” ayuda a evitar que el siguiente lo deshaga.

Optimiza solo rutas calientes

Mantén la mayor parte del código aburrido y legible. Enfoca el esfuerzo de rendimiento donde realmente se consume tiempo: bucles apretados, serialización, llamadas a BD y límites de red. En otros lugares, preferir claridad sobre ingenio, aunque sea unos milisegundos más lento.

Usa caching, batching e indexado con cuidado

Estas técnicas pueden ser grandes mejoras, pero añaden sobrecarga mental.

• Caching: escribe reglas de invalidación y TTL en comentarios de código.
• Batching: explica tamaño de lote y manejo de fallos.
• Indexado: anota qué consultas se benefician y el coste en escrituras.

Si la IA sugiere alguna de estas, pídele que incluya el “por qué”, las compensaciones y una nota corta sobre cuándo eliminar la optimización.

Las pruebas como red de seguridad para la lógica generada por IA

La IA puede generar lógica “razonable” rápidamente, pero no puede sentir el coste de un bug sutil en producción ni la confusión de un requerimiento malentendido. Las pruebas son el amortiguador entre un borrador útil y código confiable — especialmente cuando luego retocas por rendimiento o simplificas una función ocupada.

Pide tests al mismo tiempo que el código

Cuando solicites la implementación, pide también tests. Obtendrás suposiciones más claras y interfaces mejor definidas porque el modelo tiene que demostrar el comportamiento, no solo describirlo.

Una división práctica:

• Tests unitarios para reglas de negocio puras (precios, elegibilidad, validación)
• Tests de integración para lógica de “pegamento” (consultas BD, colas, clientes HTTP), usando fakes o contenedores de prueba cuando proceda

Cubre casos límite que la IA suele omitir

La IA tiende a escribir primero el “camino feliz”. Haz explícitos los casos límite en tu plan de pruebas para no confiar en la memoria o en el conocimiento tribal. Comunes:

• Entradas vacías, campos faltantes, null / undefined
• Tipos inesperados o datos malformados
• Timeouts, reintentos, fallos parciales (especialmente alrededor de llamadas de red)
• Idempotencia (re-ejecuciones seguras) y eventos duplicados

Usa tests table-driven o property-based para reglas de negocio

La lógica de negocio a menudo tiene muchas variaciones pequeñas (“si el usuario es X y el pedido es Y, entonces hacer Z”). Tests table-driven mantienen esto legible listando entradas y salidas esperadas en una matriz compacta.

Si la regla tiene invariantes (“el total no puede ser negativo”, “el descuento nunca excede el subtotal”), tests property-based pueden explorar más casos de los que escribirías a mano.

Las pruebas protegen refactors y optimizaciones

Con buena cobertura, puedes con seguridad:

• Reemplazar condicionales anidados por estructuras más claras
• Cachear o batchar llamadas para rendimiento
• Extraer helpers sin cambiar comportamiento

Trata a las pruebas que pasan como tu contrato: si mejoras legibilidad o velocidad y las pruebas siguen pasando, probablemente preservaste la corrección.

Checklist de code review para lógica de aplicación escrita por IA

La IA puede generar código “plausible” que luce limpio a primera vista. Una buena revisión se centra menos en si podrías haberlo escrito y más en si es la lógica adecuada para tu app.

Checklist rápido

Úsalo como primer pase antes de debatir estilo o micro-optimizaciónes:

• Corrección: ¿Coincide con el requerimiento y casos límite (entradas vacías, nulls, duplicados, zonas horarias, redondeos)? ¿Se manejan errores intencionadamente?
• Claridad: ¿Puede un compañero explicar el flujo tras una lectura? ¿Los nombres son específicos (p. ej., isEligibleForDiscount vs flag)?
• Complejidad: ¿La lógica es más compleja de lo necesario (condicionales anidados, one-liners ingeniosos, abstracciones prematuras)?
• Duplicación: ¿El AI repitió lógica en varias ramas que debería centralizarse?

Vigila la complejidad oculta

La IA suele “resolver” problemas enterrando complejidad en detalles fáciles de pasar por alto:

• Números y strings mágicos: reemplázalos por constantes o enums y añade un comentario si la razón no es obvia.
• Estado poco claro: cuidado con código que muta objetos compartidos, actualiza variables en varias ramas o depende de defaults implícitos.
• Efectos secundarios: revisa logging, llamadas de red, escrituras a BD o cambios globales dentro de helpers que deberían ser puros.

La consistencia importa más que la ingeniosidad

Asegúrate de que la salida siga las reglas del proyecto (lint, estructura de archivos, tipos de errores). Si no, arréglalo ahora: inconsistencias de estilo hacen que futuros refactors sean más lentos y las revisiones más difíciles.

Decide qué mantener vs reescribir a mano

Conserva la lógica generada por IA cuando sea sencilla, testeable y encaje en las convenciones del equipo. Reescribe cuando veas:

• Intención poco clara (necesitarías comentarios para entenderla)
• Flujo de control complicado (flags, retornos tempranos por todas partes, anidamiento profundo)
• Abstracciones “genéricas” que no encajan con el dominio

Si haces esta revisión de forma rutinaria, empezarás a reconocer qué prompts dan código revisable — y entonces afinarás los prompts antes de la siguiente generación.

Consideraciones de seguridad y fiabilidad

Cuando la IA genera lógica de aplicación, a menudo optimiza para claridad del camino feliz. Eso puede dejar huecos donde viven la seguridad y la fiabilidad: casos límite, modos de fallo y defaults convenientes pero inseguros.

No filtres secretos (en prompts ni logs)

Trata los prompts como comentarios de código en un repo público. Nunca pegues claves API, tokens de producción, datos de clientes o URLs internas. Vigila también la salida: la IA puede sugerir loggear solicitudes completas, headers u objetos de excepción que contengan credenciales.

Una regla simple: loggea identificadores, no payloads. Si debes loggear payloads para depurar, redáctalos por defecto y condicionalo a una bandera de entorno.

Valida entradas y falla de forma predecible

El código generado por IA a veces asume entradas bien formadas. Haz la validación explícita en los límites (handlers HTTP, consumidores de mensajes, CLI). Convierte entradas inesperadas en errores consistentes (p. ej., 400 vs 500) y diseña operaciones idempotentes para reintentos seguros.

La fiabilidad también es cuestión de tiempo: añade timeouts, maneja nulls y devuelve errores estructurados en vez de strings vagos.

Cuidado con defaults inseguros

El código generado puede incluir atajos de conveniencia:

• Permisos amplios (roles IAM comodín, scopes “admin”)
• Cripto débil (hashing casero, algoritmos obsoletos, sin salt)
• Falta de checks de auth (confiar en IDs enviados por el cliente)

Pide configuraciones de mínimo privilegio y coloca las comprobaciones de autorización cerca del acceso a datos que protegen.

Requiere supuestos de seguridad y modos de fallo

Un patrón de prompt práctico: “Explica tus supuestos de seguridad, el modelo de amenazas y qué pasa cuando fallan dependencias.” Quieres que la IA declare cosas como: “Este endpoint requiere usuarios autenticados”, “Los tokens se rotan”, “Los timeouts a BD retornan 503”, etc.

Si esos supuestos no coinciden con la realidad, el código está mal aunque sea rápido y legible.

Mantenibilidad en el tiempo: cuándo refactorizar y cuándo parar

La IA puede generar lógica limpia rápido, pero la mantenibilidad se gana con meses de cambios: requisitos nuevos, compañeros y tráfico que crece de forma desigual. La meta no es perfeccionar infinito el código — es mantenerlo entendible mientras sigue cumpliendo necesidades reales.

Refactoriza cuando la fricción sea medible

Refactorizar se justifica cuando puedes señalar un coste concreto:

• Una feature tarda visiblemente más porque la lógica está enmarañada o duplicada.
• Los bugs se concentran en el mismo módulo porque las responsabilidades no están claras.
• El trabajo de rendimiento está bloqueado porque el código oculta dónde se gasta el tiempo.

Si nada de esto ocurre, resiste la tentación de “limpiar por limpiar”. Alguna duplicación es más barata que introducir abstracciones que solo tienen sentido en tu cabeza.

Documenta el “por qué”, no solo el “qué”

El código generado por IA a menudo parece razonable, pero el tú del futuro necesita contexto. Añade notas cortas explicando decisiones clave:

• por qué se optimizó una sección (qué era lento)
• por qué se abstrajo algo (qué cambió repetidamente)
• por qué se mantuvo un enfoque simple (la complejidad no compensaba)

Mantén esto cerca del código (docstring, README o una nota en /docs) y enlaza tickets si los hay.

Añade diagramas ligeros para flujos críticos

Para unas pocas rutas centrales, un diagrama pequeño evita malentendidos y reduce reescrituras accidentales:

Request → Validation → Rules/Policy → Storage → Response
                 ↘ Audit/Events ↗

Son rápidos de mantener y ayudan a los revisores a ver dónde debe ir la nueva lógica.

Captura “límites conocidos” y planes de refactor

Anota expectativas operativas: umbrales de escala, cuellos de botella esperados y qué harás después. Ejemplo: “Funciona hasta ~50 requests/sec en una instancia; el cuello de botella es la evaluación de reglas; el siguiente paso es caching.”

Esto convierte el refactor en una respuesta planificada al uso en vez de conjeturas, y evita optimizaciones prematuras que dañen legibilidad y simplicidad.

Un flujo práctico para mantener la salida de IA rápida y entendible

Un buen flujo trata la salida de la IA como un primer borrador, no una feature terminada. El objetivo es obtener algo correcto y legible rápido, luego afinar rendimiento solo donde importe.

Aquí es donde las herramientas ayudan. Si usas una plataforma de vibe-coding como Koder.ai (chat-to-app con modo planning, exportación de código y snapshots/rollback), los mismos principios aplican: consigue primero una versión sencilla y legible de la lógica de aplicación, y luego itera en cambios pequeños y revisables. La plataforma puede acelerar el borrador y el scaffolding, pero el equipo sigue siendo dueño de las decisiones.

Estándares del equipo (defínelos antes de pedir al modelo)

Escribe unos valores por defecto para que cada cambio generado por IA parta de las mismas expectativas:

• Límites de complejidad: preferir funciones de ~40–60 líneas; evitar condicionales profundamente anidados; mantener la complejidad ciclomática baja (por ejemplo, “ninguna función por encima de 10 salvo justificación”).
• Nombres: términos del dominio sobre técnicos (p. ej., invoiceTotal, no calcX); no variables de una sola letra fuera de bucles cortos.
• Cobertura de tests: expectativas mínimas (p. ej., “la nueva lógica debe incluir tests unitarios para el camino feliz + casos límite clave”).
• Límites de rendimiento: optimizar solo con evidencia (endpoint lento, bucle caliente, regresión medida).

Generar → revisar → medir → refinar

1. Describe la feature y las restricciones (entradas, salidas, invariantes, casos de error).

2. Pide a la IA una implementación sencilla primero junto con tests.

3. Revisa por claridad antes que por ingenio. Si no lo puedes explicar en pocas frases, probablemente sea demasiado complejo.

4. Mide solo las partes relevantes. Ejecuta un benchmark rápido o añade temporizadores ligeros alrededor del posible cuello de botella.

5. Afina con prompts estrechos. En vez de “hazlo más rápido”, pide “reduce las asignaciones en este bucle manteniendo la estructura de la función”.

Do’s y don’ts prácticos

• Haz pedir funciones pequeñas y composables con nombres claros.
• Haz requerir ejemplos de entrada/salida y tests en la misma respuesta.
• Haz solicitar comentarios solo donde el “por qué” no sea obvio.
• No aceptar micro-optimizaciónes sin una medición.
• No permitir helpers “mágicos” o abstracciones que no se usan en otros sitios.
• No fusionar código de IA que nadie del equipo pueda modificar cómodamente.

Plantilla de prompt reutilizable (copiar/pegar)

You are generating application logic for our codebase.

Feature:
- Goal:
- Inputs:
- Outputs:
- Business rules / invariants:
- Error cases:
- Expected scale (typical and worst-case):

Constraints:
- Keep functions small and readable; avoid deep nesting.
- Naming: use domain terms; no abbreviations.
- Performance: prioritize clarity; optimize only if you can justify with a measurable reason.
- Tests: include unit tests for happy path + edge cases.

Deliverables:
1) Implementation code
2) Tests
3) Brief explanation of trade-offs and any performance notes

Si mantienes este bucle — generar, revisar, medir, refinar — terminarás con código que sigue siendo entendible mientras cumple expectativas de rendimiento.