Un puñado de agentes paralelos de Claude me escribieron una carpeta de estrategia para un proyecto paralelo. La solicitud de extracción se veía genial: diez documentos, todos cuidadosamente entrecruzados, y se leía bien. Luego, el revisor automatizado publicó sus hallazgos y Claude, hay que reconocerlo, no objetó:
La auditoría completa volvió: 30 de los 95 enlaces relativos apuntaban a archivos que no existían. ./market.md en lugar de market-analysis.md, ./monetization.md en lugar de business-model.md, ¡algunos archivos incluso se crearon por completo! Si hubiera hojeado esas relaciones públicas como ser humano, lo habría aprobado, ya que cada una de ellas parecía plausible. Afortunadamente, mi revisor automatizado lo detectó porque resolvió cada enlace en lugar de juzgar si los nombres "vibraban" correctamente.
Para ser justos, Claude no tiene ninguna mala intención detrás de esto. Un modelo de lenguaje simplemente genera la continuación más plausible y, a veces, la continuación más plausible es la ficción entregada con total confianza. Sin embargo, desde el punto de vista de la lectura, esa distinción aporta poco consuelo. Confiado e incorrecto se lee exactamente como confiado y correcto.
Esta publicación trata sobre el sistema que tengo implementado para ayudarme a revisar los errores y alucinaciones de Claude: un agente del Codex que se ejecuta en GitHub Actions y que revisa cada solicitud de extracción. Le guiará a través de mi configuración, por qué la revisión entre proveedores supera tanto a la autoevaluación como a una revisión humana que lee todo, cómo hacer cumplir la memoria y la responsabilidad en el ciclo de revisión, los aprendizajes sobre costos y confiabilidad que recopilé a lo largo del camino y el código real que uso para que esto funcione.
El rendimiento del agente rompió el ciclo de revisión humana
Las alucinaciones por sí solas son un problema manejable, ya que una revisión o evaluación funcional muy cuidadosa las detectaría. Sin embargo, lo que se rompió durante el año pasado es el volumen que necesita revisión. Un solo ingeniero ahora ejecuta múltiples sesiones de agentes en paralelo, y cada una de ellas puede producir una diferencia de mil líneas en el tiempo que lleva volver a llenar su café. Producir código se ha convertido en la parte rápida y sencilla; revisarlo honestamente es lo que come el día. Eso convierte al revisor humano en el cuello de botella de todo el proceso de entrega, y el cuello de botella es siempre lo siguiente que debe automatizar.
Ese cuello de botella invita a dos modos de falla familiares. O apruebas lo que los agentes producen sin leerlo realmente, y los enlaces rotos, los parámetros fantasma y los casos extremos sutilmente incorrectos se envían a producción. O todavía insistes en leer cada línea tú mismo y tus rápidos e inteligentes agentes de IA trabajan incluso menos que tú. El primero es negligente, el segundo es un despilfarro y la mayoría de los equipos oscilan entre ambos dependiendo de la fecha límite.
La conclusión a la que sigo llegando es que nuestro proceso de revisión tiene que escalar con la velocidad con la que producimos el código. El elemento humano permanece, pero el enfoque del revisor humano debe centrarse en las partes que realmente importan. La rutina de verificar si los enlaces se resuelven, si el nuevo parámetro existe, si hay un error o una vulnerabilidad y si los cambios en el código coinciden con lo que se solicitó inicialmente, todo eso debe ejecutarse automáticamente con la misma cadencia que los agentes de codificación, incluso antes de que una persona dedique un segundo a revisar el código.
Insight: las alucinaciones son una constante, el rendimiento es lo que cambió. Cualquier proceso que requiera que un humano lea cada línea limita a sus agentes a la velocidad de lectura humana, por lo que la primera pasada de revisión debe automatizarse.
Elija un revisor que no comparta los puntos ciegos del autor.
La primera idea obvia para evitar estos errores es que el agente revise su propio trabajo… pero también es la más débil. Una alucinación que apareció en la diferencia es, por definición, plausible para el modelo que la produjo. Pedir los mismos pesos para encontrar errores en el código, especialmente dentro de la misma sesión de codificación ya sesgada, generalmente reproduce exactamente los puntos ciegos que dejan pasar los errores.
Esta intuición tiene investigación detrás. Panickssery et al. demostró en NeurIPS 2024 que los evaluadores de LLM reconocen y favorecen a sus propias generaciones: cuanto mejor es un modelo para identificar su propio resultado, más generosamente lo califica. El trabajo de seguimiento vincula este sesgo de autopreferencia con la familiaridad: los jueces de IA puntúan más el texto cuando les parece predecible, y nada le parece más predecible a un modelo que el texto que acaba de escribir.
Diferentes proveedores de LLM se capacitan con diferentes datos, con diferentes recetas y diferentes ciclos de retroalimentación. Ningún proveedor logra eliminar los errores, pero el tipo de errores que comete un modelo se remonta a cómo fue entrenado, y eso difiere según el proveedor. Esa descorrelación es exactamente lo que desea en su agente de revisión. En el año que utilicé esta configuración, el Codex de OpenAI ha señalado constantemente problemas en los PR escritos por Claude que la propia revisión de Claude pasó sin pestañear, desde nombres de archivos inventados hasta bloques de código completos que no tenían nada que ver con la solicitud inicial, o que introdujeron violaciones de seguridad absolutas.
Una conclusión que no puedes sacar de esto es que Codex es el mejor ingeniero y deberías entregarle el teclado a él en lugar de a Claude. ¡El Codex también falla con bastante regularidad! Simplemente en una dirección diferente a la de Claude. El poder reside en trabajar con múltiples modelos: combinar proveedores dentro del mismo flujo de trabajo, donde los modelos llenan los vacíos de los demás.
Otra conclusión incorrecta es que las revisiones del Codex son perfectas y pueden aceptarse a ciegas. Las alucinaciones también ocurren en las reseñas, así que trate la reseña como un aviso. Desafiar al autor (ya sea Claude o usted mismo) pone el foco en posibles puntos ciegos, que es la señal perfecta para acercarse y reflexionar. Sigue siendo trabajo del autor ser dueño de la calidad final y, a veces, eso significa responder al Codex diciéndole que su revisión fue incorrecta. Más sobre este mecanismo más adelante en la publicación.
Insight: los errores de un autor son, por definición, plausibles para el autor, y la investigación confirma que los LLM tienen un sesgo positivo hacia su propia producción. El valor de la revisión proviene de la descorrelación, al utilizar un modelo de un proveedor diferente que falla de manera diferente, y lo diferente es lo que capta lo que se pierde.
El proceso: una convocatoria de LLM envuelta en ingeniería ordinaria
Conceptualmente, un revisor de LLM se puede escribir en una sola línea: "aquí está la diferencia del código, revíselo". Tanto OpenAI como Anthropic ofrecen atajos alojados exactamente para eso: OpenAI tiene una integración de revisión de GitHub que revisa automáticamente los RP, y Anthropic tiene claude-code-action. Son buenos puntos de partida, pero prefiero ejecutar mi propia acción, porque quiero ser dueño del mensaje, el ciclo de vida de la revisión, la combinación y el pin del modelo. Todos estos aspectos importan cuando su día a día se convierte en agentes de gestión y revisión.
Entonces, ¿qué estoy usando exactamente? Dos archivos que viven en el repositorio que revisan:
.github/ ├── flujos de trabajo/ │ └── pr.yml # orquestación: desencadenadores, contexto, reintentos, publicación └── acciones/ └── codex-pr-review/ └── action.yml # el revisor: llamada del Codex fijada + mensaje de revisión
El flujo de tiempo de ejecución es corto. Cada vez que un PR abre o recibe un push, pr.yml verifica el código, recopila el historial completo de conversaciones del PR y entrega ambos a la acción compuesta. La acción ejecuta Codex sobre la diferencia y devuelve sus resultados como un único mensaje. Luego, el flujo de trabajo publica ese mensaje como un comentario único y continuamente actualizado en la conversación de relaciones públicas, y publica un estado de confirmación que permanece en rojo mientras los hallazgos permanecen sin resolver: la señal de ir/no ir junto al resto de CI.
En el centro de todo se encuentra un paso engañosamente simple, la única línea que realmente toca un LLM:
– utiliza: openai/codex-action@v1 con: openai-api-key: ${{ inputs.openai-api-key }} mensaje: | # el contrato de revisión: qué revisar, cómo realizar un seguimiento de los hallazgos, # y cómo informar (desglosado en la siguiente sección)
Todo lo demás existe para ejecutar ese único paso de manera confiable y para garantizar que sus comentarios realmente lleguen al RP. Aquí está el flujo de trabajo completo:
nombre: PR Reviewer en: pull_request: sucursales: [dev] # todos los viajes de trabajo cuentan con sucursales: característica -> dev -> tipos principales: [abierto, sincronizado, reabierto] # un nuevo envío cancela la revisión en vuelo (costosa) de la concurrencia de confirmación anterior: grupo: pr-reviewer-${{ github.event.pull_request.number }} cancelación en progreso: trabajos verdaderos: códice: si: github.event.pull_request.user.login != 'dependabot[bot]' se ejecuta: ubuntu-latest timeout-minutos: 15 # la revisión normal tarda unos minutos, por lo que 15 m son permisos más que suficientes: # el token puede leer código y publicar comentarios, pero nunca puede enviar o fusionar contenidos: leer problemas: escribir solicitudes de extracción: escribir estados: escribir pasos: # la referencia /head se actualiza sincrónicamente en cada envío; # la referencia de fusión generada automáticamente puede acelerar el proceso de pago – utiliza: acciones/checkout@v7 con: ref: refs/pull/${{ github.event.pull_request.number }}/head # asegúrese de que ambos puntos finales de diferencias existan localmente, para que Codex pueda resolver base…head – nombre: Precargar las referencias base y principal para la ejecución de relaciones públicas: | git fetch –no-tags origin ${{ github.event.pull_request.base.ref }} +refs/pull/${{ github.event.pull_request.number }}/head # los comentarios se encuentran en tres superficies: comentarios de emisión, reseñas y comentarios en línea – nombre: Obtener ID de conversación de relaciones públicas: usos de conversación: acciones/github-script@v9 con: codificación de resultados: script de cadena: | const prNumber = contexto.payload.pull_request.number; const opts = { propietario: contexto.repo.propietario, repositorio: contexto.repo.repo }; const [comentarios, reseñas, en línea] = await Promise.all([ github.paginate(github.rest.issues.listComments, { …opts, número_número: prNumber }), github.paginate(github.rest.pulls.listReviews, { …opts, pull_number: prNumber }), github.paginate(github.rest.pulls.listReviewComments, {…opts, pull_number: prNumber }), ]); const all = [ …comments.map(c => ({ fecha: c.created_at, texto: `@${c.user.login}: ${c.body}`, })), …reviews.filter(r => r.body).map(r => ({ fecha: r.submitted_at, texto: `@${r.user.login} (revisión ${r.state}): ${r.body}`, })), …inline.map(c => ({ fecha: c.created_at, texto: `@${c.user.login} (en ${c.path}): ${c.body}`, })), ]; all.sort((a, b) => nueva Fecha(a.fecha) – nueva Fecha(b.fecha)); return all.map(e => e.text).join('n—n'); # los secretos no viajan con el yml, comuníquese en voz alta si faltan claves – nombre: Falla rápidamente si falta OPENAI_API_KEY env: OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }} ejecutar: | si [ -z "${OPENAI_API_KEY}" ]; luego echo "::error::El secreto OPENAI_API_KEY no está configurado para este repositorio". salida 1 fi # los envoltorios de reintento no pueden ajustar los pasos `uses:`, así que reinténtalo manualmente: transitorio # fallas (un 401 de un token de corredor nuevo, un problema al llegar a OpenAI) # no debe poner toda la ejecución en rojo – nombre: Ejecutar Codex (intento 1) id: codex_try1 usa: ./.github/actions/codex-pr-review continue-on-error: true con: openai-api-key: ${{ secrets.OPENAI_API_KEY }} conversación: ${{ pasos.conversation.outputs.result }} # dar a los fallos transitorios un momento para que se solucionen antes de volver a intentarlo – nombre: Esperar antes de que Codex reintente si: pasos.codex_try1.outcome == 'fallo' ejecutar: dormir 20 – nombre: Ejecutar Codex (intento 2) id: codex_try2 si: pasos.codex_try1.outcome == 'fallo' usa: ./.github/actions/codex-pr-review con: openai-api-key: ${{ secrets.OPENAI_API_KEY }} conversación: ${{ pasos.conversation.outputs.result }} – nombre: publicar la revisión y publicar un estado usa: acciones/github-script@v9 env: REVISIÓN: >- ${{ (steps.codex_try1.outcome == 'éxito' && pasos.codex_try1.outputs['mensaje-final']) || pasos.codex_try2.outputs['mensaje-final'] }} con: script: | constante MARCADOR = ''; const opts = { propietario: contexto.repo.propietario, repositorio: contexto.repo.repo }; const prNumber = contexto.payload.pull_request.number; const raw = proceso.env.REVISIÓN; si (!raw) regresa; cuerpo constante = `${MARCADOR}n${raw}`; // un comentario canónico, editado en cada inserción const comments = await github.paginate( github.rest.issues.listComments, { …opts, issues_number: prNumber }); const existente = comentarios.find(c => c.user?.login === 'github-actions[bot]' && c.body?.includes(MARKER)); constante publicado = existente? espere github.rest.issues.updateComment ({…opts, comment_id: existing.id, body}): espere github.rest.issues.createComment({…opts, issues_number: prNumber, body}); // ir/no-ir: un estado de confirmación que permanece en rojo mientras los hallazgos están abiertos // (un avance faltante se lee como "revisión publicada", nunca como cero hallazgos) const m = raw.match(/`, donde N cuenta las filas no resueltas y M cuántas de ellas son de gravedad Alta. Inclúyalo siempre, incluso cuando N sea 0: CI lo analiza en la verificación de estado. Título y cuerpo de la solicitud de extracción: —- ${{ github.event.pull_request.title }} ${{ github.event.pull_request.body }} Historial de conversaciones: —- ${{ inputs.conversation }}
Tres opciones de diseño tienen el peso aquí.
La reseña es llena de estado. La tabla Resumen de comentarios rastrea cada hallazgo que se haya planteado en el RP, resuelto o no, a lo largo de los push. Combinado con el comentario de edición in situ del flujo de trabajo, un PR lleva exactamente un artefacto de revisión que refleja todo el ciclo de vida, en lugar de cinco comentarios obsoletos, cada uno de los cuales refleja una actualización en el proceso de revisión. Cualquiera que abra el PR, humano o agente, ve el historial completo de un vistazo. Se respetan las negativas. Debido a que Codex lee toda la conversación, el autor puede rechazar un hallazgo por escrito y el rechazo se mantiene durante los ciclos de revisión. Este es el mecanismo que hace que un revisor imperfecto sea viable: los falsos positivos cuestan una respuesta escrita en lugar de un bucle interminable de quejas, y la objeción queda registrada para el siguiente lector. El veredicto es legible por máquina. El flujo de trabajo analiza la línea final y la convierte en un estado de confirmación de revisión del Codex. El resultado son dos señales independientes en cada PR: la verificación del flujo de trabajo le indica que se ejecutó la revisión y el estado le indica si todavía hay algo abierto. El estado rojo significa hallazgos no resueltos; verde significa que todo está arreglado o rechazado explícitamente. Mantengo deliberadamente el estado sin bloqueo, ya que solo funciona para informar. La decisión de fusionarse o no sigue abierta y sigue siendo humana.
Tenga en cuenta que este contrato exige más que buscar errores tipográficos. Codex revisa la diferencia con la intención declarada del RP, clasifica cada hallazgo por gravedad y adjunta una solución propuesta concreta, el tipo de revisión que regularmente muestra problemas a nivel de arquitectura que ningún linter produciría jamás.
Insight: la estructura supera la calidad del modelo en bruto en un revisor. Una tabla de ciclo de vida, una regla de rechazo y un veredicto legible por máquina convierten las opiniones de LLM de formato libre en una puerta de fusión con un mecanismo de rechazo escrito que abarata los falsos positivos.
Cierra el círculo: el PR se vuelve verde incluso antes de mirar
El crítico es sólo la mitad de la historia cuando se mira el panorama general de la ingeniería. La otra mitad es enseñarle al agente autor a responder, para que la revisión de ida y vuelta no se convierta en su trabajo (recuerde: trate siempre de eliminar el cuello de botella). En mis repositorios utilizo tres habilidades de Claude Code para ayudarme, escritas como archivos de instrucciones de rebajas simples en .claude/skills/:
/pr-open crea el PR: analiza las confirmaciones de la rama, ejecuta la validación localmente, escribe un título y un cuerpo honestos y apunta a la base correcta. El organismo de relaciones públicas importa más de lo que parece, ya que el revisor lo lee como la declaración de intenciones contra la que revisa. Hago que explique la solicitud de función completa y haga referencia al ticket lineal que implementa, de modo que tanto el revisor como cualquier humano que llegue más tarde obtengan la imagen completa sin salir del PR. /pr-iterate maneja una ronda de revisión: barre las tres superficies de retroalimentación y luego clasifica cada elemento en una solución, un rechazo con razonamiento o un aplazamiento. Las correcciones se implementan y validan localmente; los rechazos se convierten en comentarios de relaciones públicas que explican por qué. El revisor es consultivo y “lo suficientemente bueno para fusionarse” es un veredicto válido una vez que el RP cumple con su alcance establecido. /pr-babysit es el perro guardián de todo: vigila el CI, corrige los controles rojos, ejecuta una ronda de iteración cuando llega nueva retroalimentación y realiza un bucle hasta que cada control esté en verde y cada hallazgo se corrija o rechace. Su estado terminal es "listo para fusionarse" y se detiene para informar en lugar de realizar confirmaciones de ping-pong cuando la misma verificación falla dos veces por la misma causa raíz.
Una regla de ordenación que usted y sus agentes siempre deben tener en cuenta: responder primero, presionar después. La revisión comienza con cada impulso y funciona con el contexto que existe en ese momento exacto. Todo lo que aún no esté escrito (un rechazo, un resumen de corrección, un comentario propio) no existe para esa ronda de revisión, y el revisor estará encantado de volver a plantear cada elemento para el que no pueda ver una respuesta.
El estado final es una ordenada división del trabajo. Claude escribe y defiende, Codex desafía y rastrea, el ciclo se ejecuta hasta que el PR está en verde con una tabla de comentarios limpia. Mi cola contiene solo RP que ya están listos para fusionarse, cada uno con un rastro de revisión que puedo auditar en un solo desplazamiento: qué se encontró, qué se solucionó y qué se rechazó y por qué.
Insight: automatice ambos lados de la revisión. Cuando el agente autor debe corregir o impugnar cada hallazgo por escrito antes de poder publicarlo, la cola humana solo contiene RP listos para fusionar con un rastro de revisión auditable.
Cómo se ve un viaje de ida y vuelta en la práctica
Para concretar el mecanismo, aquí hay un intercambio de un PR de backend mío. El PR arregló una cuadrícula de capacidad que escribía más celdas de las que permitía un límite de lote codificado. La primera ronda de revisión arrojó dos hallazgos:
## Resumen de comentarios | Problema | Gravedad | Resumen | Resuelto | | ——————————- | ——– | —————————————- | ——– | | Truncamiento más allá del límite de lotes | Alto | Las células que pasan la tapa se caen silenciosamente. | ❌ | | Cap duplica el límite de una plataforma | Medio | Mueva la tapa a la configuración de la aplicación. | ❌ |
El estado de revisión del Codex pasó a rojo. Claude implementó el primer hallazgo de verdad, luego rechazó el segundo en un comentario de relaciones públicas (comentario real, anónimo):
Se solucionó el hallazgo alto (límite de fila codificado en la capa de datos, lo que provocaba errores 502 evitables).
_fetch_capacity_grid ahora se adapta en lugar de fallar: en una página corta (que, debido a que la cuadrícula es densa exactamente en días filas/persona, significa inequívocamente que el límite implementado truncó el lote) reduce a la mitad el tamaño del lote y vuelve a intentar el mismo segmento, reduciéndose hasta que las páginas quepan. Una página corta sólo se convierte en un 502 ruidoso una vez que tamaño_lote == 1 […]
Sobre la sugerencia secundaria (mueva la tapa a configuración): no se hizo intencionalmente. El límite real reside en la configuración de API alojada de la base de datos, no en una var de entorno de aplicación. Reflejarlo en la configuración de la aplicación agregaría una segunda fuente de verdad que podría derivarse silenciosamente de la base de datos. El procesamiento por lotes adaptativo elimina la necesidad de conocer el valor exacto, que es la solución más sólida. La prueba de base de datos de la red de capacidad existente aún pasa; pelusa y verificación de tipo verde.
Responda primero, presione después y haga que el Codex vuelva a revisar:
## Resumen de comentarios | Problema | Gravedad | Resumen | Resuelto | | ——————————- | ——– | ——————————– | ——– | | Truncamiento más allá del límite de lotes | Alto | Se corrigió mediante procesamiento por lotes adaptativo. | ✅ | | Cap duplica el límite de una plataforma | Medio | Rechazado: el duplicado se desviaría. | ✅ |
Ambas filas se resolvieron, una mediante una corrección y otra mediante un rechazo por escrito que el revisor aceptó y registró. Esa segunda fila es todo el mecanismo en una sola línea: no se implementó ninguna rotación solo para silenciar un comentario, y el razonamiento ahora es parte de la historia del PR para quien lo lea a continuación.
El libro de aprendizaje: cuánto cuesta y dónde muerde
Esta configuración no se realizó de una sola vez. La mayoría de sus detalles surgieron de sorpresas y callejones sin salida a lo largo del camino, por lo que escribo los aprendizajes aquí, en orden aproximado del dinero ahorrado, para evitar que usted se encuentre con las mismas paredes:
Fija el modelo. La entrada del modelo de codex-action es opcional y dejarla vacía significa "lo que sea que Codex tenga por defecto actualmente". Aprendí esto en mi factura cuando el modelo predeterminado pasó silenciosamente a un modelo más nuevo y más caro (gpt-5.5). Los pines resuelven este problema, pero a cambio necesitan mantenimiento; Actualmente uso gpt-5.3-codex, que ya está marcado como obsoleto en la página de modelos del Codex al momento de escribir este artículo (aunque permanece disponible en la API). Vuelvo a visitar el pin deliberadamente en lugar de dejar que el valor predeterminado decida por mí. Limite el esfuerzo a medio. Un mayor esfuerzo de razonamiento detecta un número ligeramente mayor de problemas por mucho más dinero y tiempo. La velocidad importa más de lo que parece: la revisión se encuentra dentro del ciclo de iteración del agente, por lo que su latencia se multiplica en cada ronda de cada PR, y su propio tiempo de espera es parte del precio. El nivel medio ha sido el punto ideal para las emisiones por dólar y las emisiones por minuto. Desafortunadamente, ningún nivel de esfuerzo lo capta todo; para eso está el ser humano propietario de la fusión. Vuelva a intentar los fallos rápidos. Un token de corredor nuevo ocasionalmente es 401 y la primera conexión a la API ocasionalmente falla. Dos intentos con un respaldo cerrado evitan que el flujo de trabajo se vuelva rojo "por nada", lo cual es importante una vez que los agentes (y su propia confianza) tratan el rojo como una señal real. Cancelar reseñas reemplazadas. El bloque de simultaneidad significa que solo se revisa la última confirmación de un PR. Sin él, un agente que impulsa tres correcciones seguidas le compra tres revisiones, dos de ellas para un código que ya no existe. Revisar con la base que recibirá la fusión. Mis relaciones públicas se dirigen al desarrollador, por lo que la revisión difiere del desarrollador y mantengo la rama de funciones sincronizada con esa base. Una rama obsoleta se diferencia de una base que se ha movido, y luego la revisión informa hallazgos fantasmas de cambios que el RP nunca realizó. Las ramas de características son el requisito previo. Todo esto depende de los eventos pull_request. Los envíos directos al desarrollador o principal omiten por completo al revisor, el estado y el seguimiento de auditoría. El flujo de una rama por cambio es lo que hace que cada cambio sea revisable en primer lugar. Supongamos que el texto de relaciones públicas es una entrada que no es de confianza. Todo lo que lee el revisor (el cuerpo de relaciones públicas, la conversación, el código en sí) es una superficie de inyección rápida y el agente lo ejecuta en su corredor con su clave API. El token de privilegio mínimo limita el radio de explosión en el lado de GitHub, y la acción del códice incluye controles de sandboxing y estrategia de seguridad para el lado del corredor. También sepa que GitHub no expone secretos de flujos de trabajo desencadenados por relaciones públicas bifurcadas, por lo que este patrón asume ramas del mismo repositorio de contribuyentes confiables. Revise el modelo de confianza antes de copiarlo en un repositorio de código abierto.
Eres el editor en jefe ahora
El objetivo de este canal nunca fue sacar al humano del circuito, su intención es elevarlo de nivel. Dejé de ser el primer lector de cada diferencia y me convertí en la persona que lee reseñas, resuelve los enfrentamientos ocasionales entre dos modelos y es dueño de los estándares escritos en el mensaje de reseña. Cuando Claude y Codex están de acuerdo, el RP probablemente esté bien. Cuando no están de acuerdo, ese desacuerdo es un indicador guiado con precisión hacia exactamente el código que merece mi atención. Mientras que Claude a veces actúa de manera descuidada, Codex tiende a hacer demasiada ingeniería, mantener ese equilibrio en tus propias manos es un gran lugar para estar.
Revisar las revisiones (es decir, meta) es un mejor trabajo que corregir la salida del agente a la velocidad del agente, y se degrada con gracia. En un día de descanso, fusiono las relaciones públicas verdes según la fuerza del camino, en un día cuidadoso leo la tabla de comentarios y compruebo las caídas. De cualquier manera, nada llega al botón de fusión cuando un modelo lo dice con confianza.
Ideas clave de esta publicación
Las alucinaciones son una constante, el rendimiento es lo que cambió. Cualquier proceso que requiera que un humano lea cada línea limita a sus agentes a la velocidad de lectura humana, por lo que la primera pasada de revisión debe automatizarse. Los errores de un autor son, por definición, plausibles para el autor, y la investigación confirma que los LLM tienen un sesgo positivo hacia su propia producción. El valor de la revisión proviene de la descorrelación, al utilizar un modelo de un proveedor diferente que falla de manera diferente, y lo diferente es lo que capta lo que se pierde. La llamada modelo es la parte fácil. La confiabilidad del revisor proviene de la ingeniería de CI ordinaria que la rodea. La estructura supera la calidad del modelo en bruto en un revisor. Una tabla de ciclo de vida, una regla de rechazo y un veredicto legible por máquina convierten las opiniones de LLM de formato libre en una puerta de fusión con un mecanismo de rechazo escrito que abarata los falsos positivos. Automatiza ambos lados de la revisión. Cuando el agente autor debe corregir o impugnar cada hallazgo por escrito antes de poder publicarlo, la cola humana solo contiene RP listos para fusionar con un rastro de revisión auditable.
Idea final: trabajo multimodelo. A veces, sus agentes le entregarán ficción segura y los modelos de diferentes proveedores llenan los vacíos de los demás, para que usted no tenga que hacerlo. Un revisor de segundo proveedor con memoria y contrato, sentado entre sus agentes y su sucursal principal es un excelente lugar para comenzar, pero no es el único. Siempre que el rendimiento de un modelo está a punto de ser importante, una segunda opinión de un laboratorio diferente es el seguro más barato que puede adquirir.
Sígueme en LinkedIn para obtener información breve sobre la IA, Towards Data Science para obtener acceso temprano a nuevas publicaciones o Medium para ver el archivo completo.