Piezas que se hablan con reglas claras
Cuando la IA construye el frontend por un lado y el backend por otro, tienen que ponerse de acuerdo en la forma de lo que se pasan. A ese acuerdo se le llama contrato: qué le llega a una pieza, qué devuelve, y qué ocurre si falla. Sin contrato, cada pieza inventa su propia forma y todo se rompe en la integración.
Las tres preguntas de todo contrato
| Pregunta | Qué define | Ejemplo en «buscar contactos» |
|---|---|---|
| ¿Qué entra? | Los datos que recibe la pieza | un texto de búsqueda (puede venir vacío) |
| ¿Qué sale? | Lo que devuelve en el caso bueno | una lista de contactos con nombre y teléfono |
| ¿Qué pasa si falla? | El comportamiento ante el error | lista vacía con un aviso, no un pantallazo |
El contrato por escrito
No hace falta código: basta una ficha en lenguaje natural, o un ejemplo de la forma que tendrán los datos. Esta es la ficha de un endpoint descrita como contrato:
{\n "pieza": "GET /contactos?query=",\n "entra": {\n "query": "texto opcional; si viene vacio devuelve todos"\n },\n "sale_bien": {\n "contactos": [ { "id": 1, "nombre": "Ana", "telefono": "55..." } ],\n "total": 1\n },\n "sale_mal": {\n "error": "mensaje legible",\n "contactos": []\n }\n}Por qué el contrato te protege
Prueba
El frontend muestra «NaN» en el total porque esperaba total pero el backend devolvió count. ¿Qué faltó fijar?
Un buen contrato debe decir también qué ocurre cuando algo falla.
Detecta el contrato incompleto
Revisas la ficha de una pieza antes de pedir su código. Señala la línea que deja un hueco por el que la IA improvisará:
- Entra: un correo y una contraseña.
- Sale bien: sesión iniciada y token guardado.
- Sale mal: (sin definir; no se especifica qué se muestra).
- Restricción: nunca devolver la contraseña en la respuesta.
Identifica la linea con error.
Elige una pieza de tu proyecto y escribe su contrato con las tres preguntas (entra, sale bien, sale mal). Enséñaselo a la IA y pide que confirme que la construirá exactamente así.