En FurtherAI cada ingeniero fusiona 5 veces más código, pero el cuello de botella ahora es decidir qué construir

Building an AI-native engineering org

Sashank Gondala comparte las lecciones de nueve meses construyendo una organización de ingeniería AI-native en FurtherAI. Los agentes escriben casi todo el código, los tests y las revisiones, y hasta un tercio de los cambios se fusiona sin intervención humana. El resultado: cada ingeniero fusiona unas 5 veces más cambios al día con una tasa de reversión inferior al 0,5%. Pero al acelerar la escritura de código, la planificación y la revisión pasaron a ocupar el 70% del tiempo. Su apuesta es dar más ownership a los ingenieros y exigir a los managers que se involucren en el producto.

Nos volvimos mucho más rápidos escribiendo código, pero no ni de lejos tan rápidos decidiendo qué construir.
  1. juancn

    Ni una sola mención del valor o los ingresos.

    Solo subieron tres métricas: LOC, gasto en tokens y presumiblemente la velocidad/frecuencia de publicación.

    ¿Cuál es el margen (beneficio/COGS)? ¿Ha subido?

    ¿Satisfacción del cliente? ¿El NPS se mueve en una dirección u otra?

  2. nater5000

    Esta publicación me hace gracia, porque siento que se queda muy corta respecto a cómo sería realmente una organización de ingeniería "AI-native" propiamente dicha y con visión de futuro. Es decir, el autor presenta esto como una especie de ruptura radical con la ingeniería normal, pero yo solo lo veo como ingeniería normal con más IA. Eso no lo veo como AI-native.

    Para mí, la verdadera ingeniería "AI-native" será aquella en la que las preguntas sobre cómo harán los humanos cosas como revisar código sean irrelevantes. Descartas explícitamente cualquier concepto de ingeniería de software típica y, en su lugar, te remites a la IA. Tu trabajo, como humano, es únicamente hacer lo que la IA no puede hacer físicamente. Eso no es lo mismo que cerrar las brechas entre lo que la IA es capaz de hacer actualmente y lo que necesitarías que fuera capaz de hacer. Literalmente se trata de imponer que cualquier cosa que una IA sea capaz de hacer se considere correcta en sí misma, y tú, como humano, solo la apoyas siendo humano.

    Si eso suena descabellado, es porque lo es. Todavía no tenemos sistemas de IA tan capaces. Es posible que nunca los tengamos. Pero eso está fuera de la cuestión. La realidad es que intentar crear una organización de ingeniería "AI-native" simplemente superponiendo IA a los procesos y sistemas existentes es inútil. Si tu expectativa es que la IA seguirá mejorando en capacidades a un ritmo acelerado, entonces estos parches no tienen sentido. Bien podrías ignorar la IA por completo hasta que sea capaz de hacerse cargo por completo, porque ese es el objetivo inevitable, ¿no?

    Si estás dispuesto a aceptar que será posi […]

  3. simonw

    A estas alturas, un montón de equipos se han volcado hacia el código AI-first, no del todo revisado, desde alrededor de marzo de este año.

    Eso significa que ya llevamos 6-8 meses, y no estamos lejos de tener un año entero de experiencia de cómo es eso en realidad, aunque extrañamente influenciado por el aumento en las capacidades de los modelos durante ese periodo.

    Tengo ganas de ver esas retrospectivas. ¿Resultó funcionar bien para los equipos que lo hicieron? ¿Cuáles fueron los mayores fallos y/o sorpresas? Con la perspectiva que da el tiempo, ¿produjo software de buena calidad?

  4. fg137

    Justo estaba mirando algunos mensajes de error orientados al usuario que Claude generó para mí, que contenían detalles técnicos innecesarios/irrelevantes mientras no lograban proporcionar instrucciones claras ni una solución.

    Antes, revisé código que hace mucho más de lo especificado en el alcance, cambia la API pública e introduce nuevo comportamiento. Tuve que rehacer casi todo.

    Pensé para mis adentros: de ninguna manera voy a publicar el código tal como está escrito sin leerlo realmente de principio a fin (o, como dicen algunos, solo mirando la "intención"). Recibiré más quejas de usuarios sin tener absolutamente ni idea de qué pasa con el código o el comportamiento real.

    Es un misterio para mí cómo estas organizaciones pueden lograrlo.

  5. liorgrossman

    Veo a muchos builders (yo incluido) cayendo en la trampa de centrarse en las cosas equivocadas. La velocidad de desarrollo no importa por sí misma; lo que importa son cosas como el crecimiento del beneficio o la tracción. Es muy fácil confundir la automatización/los sistemas/los procesos con los resultados reales del negocio. Movimiento ≠ Progreso.

  6. simonw

    Relacionado: este artículo era muy poco probable que llegara a la portada de Hacker News gracias al titular clickbait, pero recomiendo leerlo de todos modos: https://twitter.com/jsnnsa/status/2115623382721126826

    Describe a un equipo que gasta 30 veces su nómina en tokens: 3.000.000 de dólares en gasto de tokens al mes, construyendo un juego multijugador en el que los incidentes y los informes de errores de los usuarios se pasan directamente a agentes Fable 5/5.1, que luego actúan sobre ellos y despliegan los cambios a producción.

    "Consideramos que hay una caída del servicio si no publicamos cada hora".

    Vale la pena leerlo porque o es un desastre completo o es un atisbo del futuro, o muy posiblemente ambas cosas.

  7. mirmor23

    Pasé unos minutos leyendo el infomercial y me arrepentí. Los principios de ingeniería forman primero los cimientos, y las herramientas de IA están hechas para encajar en ellos, no al revés como propone este infomercial. Su vibra de LinkedIn también echa mucho para atrás.

  8. DavCreator

    https://xxcancel.com/sgondala2/status/2115832070274723875

Más de este día

2026-10-30