Una persona de soporte detecta que diez clientes no entienden por qué una factura marca «pendiente» después de pagar. Hoy puede abrir un ticket y esperar; con Replit Cloud Agents puede describir un cambio pequeño en el repositorio, revisar una vista previa y llevar a ingeniería una pull request con evidencia. El valor no está en que «la IA programe sola»: está en transformar conocimiento del cliente en una propuesta que un ingeniero pueda comprobar. Replit anunció este flujo el 27 de octubre de 2026 y actualizó el anuncio el 29. Esta es una guía para usar una capacidad existente, no una noticia del 8 de noviembre.

Antes de empezar: acceso y alcance

El anuncio dice que Cloud Agents sobre repositorios existentes está disponible para clientes Pro y Enterprise. La documentación de Replit también describe el trabajo sobre repositorios como un flujo de acceso temprano cuya disponibilidad y configuración pueden variar por workspace. Por eso comprueba la opción en tu cuenta antes de prometerla a tu equipo. Necesitas acceso autorizado al repositorio de GitHub o GitLab; conectar tu cuenta no te da permisos que no tenías. Un administrador debe definir qué repositorios y credenciales se pueden usar.

Empieza con un cambio reversible y estrecho: el estado visible en la página de facturas, no el sistema de cobro entero. Escribe el problema en lenguaje de usuario y el comportamiento esperado. Si aún no sabes si el error está en el dato o solo en el texto, pide primero una investigación sin editar. Replit permite usar el agente para entender código y dependencias antes de solicitar una modificación.

Un encargo que sí puede revisarse

Copia este texto en un chat vinculado al repositorio y reemplaza los campos entre corchetes con tus datos. Es un ejemplo de encargo; no lo hemos ejecutado en una cuenta de Replit ni podemos afirmar que exista ese bug en tu producto:

Contexto: soporte recibe reportes de que la factura [ID de prueba]
aparece como «pendiente» aunque el pago de prueba está confirmado.

Primero: localiza dónde se calcula y muestra el estado. Explica si el
problema está en los datos, la lógica o solo la etiqueta. No cambies código
hasta mostrar el diagnóstico y los archivos implicados.

Si es un error de presentación, propón un cambio mínimo. Criterios:
1. La factura pagada muestra «Pagada» en la vista de detalle y en la lista.
2. Una factura realmente pendiente sigue mostrando «Pendiente».
3. No cambies importes, webhooks de pago ni permisos.
4. Añade o ajusta una prueba para ambos estados.
5. Muéstrame el diff, los resultados de pruebas y una vista previa móvil.

Detente antes de abrir la PR si no puedes reproducir el caso o si el
cambio toca facturación, datos sensibles o más archivos de los previstos.

La primera instrucción obliga a distinguir un problema de interfaz de uno de datos. El contraejemplo «pendiente sigue pendiente» evita que el agente reemplace todas las etiquetas. El límite de archivos e impacto crea un punto claro para pedir ayuda a ingeniería. Este encargo es útil también fuera de Replit: un humano puede evaluar sus criterios antes de dar acceso a cualquier agente.

Del chat a una PR que ingeniería puede aceptar

Según la guía de conexión, abre Repositories, autoriza GitHub o GitLab, elige un repositorio y selecciona «Use in chat». Replit prepara una copia de desarrollo en un sandbox. Las instrucciones del repositorio, como AGENTS.md o CLAUDE.md, viajan con ese código. En un equipo, haz que ingeniería mantenga esas reglas: comandos de pruebas, arquitectura, zonas que requieren revisión y prohibiciones de secretos.

Pide que ejecute la aplicación y comprueba la vista previa. Mira la factura pagada y la pendiente, tanto en escritorio como en móvil. La documentación de primera contribución distingue la actividad de prueba en curso del resultado final: una captura de «el navegador está probando» no demuestra que la prueba pasó. Lee el reporte final y el diff; si falta evidencia, solicita una comprobación concreta. Las capturas o video que Replit adjunta ayudan al revisor, pero tampoco sustituyen la revisión del código.

Solo cuando el resultado coincide con los criterios, pide una rama y una PR en GitHub o una MR en GitLab. El ingeniero debe revisar el diff, las pruebas, el alcance y las dependencias, y decidir si fusiona. Abrir la solicitud no fusiona ni despliega nada. Si el revisor pide cambios, continúa en el mismo chat y la misma PR; la guía de revisión indica que las nuevas confirmaciones actualizan la solicitud existente. No crees una segunda PR por el mismo problema.

Qué medir y qué no delegar

En la primera semana registra tres cosas: cuántas propuestas pasaron de reporte a PR, cuántas requirieron corrección humana antes del merge y cuántas resolvieron el problema sin regresiones. No midas solo velocidad o número de PR: una cola de cambios superficiales puede aumentar la carga de revisión. Para áreas como pagos, autorización y datos privados, exige un dueño técnico y pruebas con datos ficticios. Replit recuerda que el aislamiento del sandbox no elimina los permisos de las credenciales que le entregas: usa acceso de desarrollo con el menor alcance posible.

El flujo encaja cuando soporte o producto conocen un problema concreto y el equipo ya tiene una ruta de revisión. Si no tienes acceso a Cloud Agents, conserva el mismo formato de encargo y entrégalo como ticket bien definido. El objetivo es que la siguiente persona pueda comprobar una mejora real, no convertir cada conversación en código sin contexto.