De YC a AWS: Tusk convierte el tráfico de producción en pruebas basadas en IA en AWS

El código generado por IA está transformando con rapidez el desarrollo de software. Lo que antes requería días ahora requiere horas, y lo que exigía equipos cada vez puede realizarlo una sola persona. ¿El problema? Se genera más código que nunca. Esto implica más solicitudes de extracción, más casos límite y mayor carga para los equipos de ingeniería. El tiempo que se ahorra en la escritura pierde valor si se ve absorbido por mayores exigencias de aseguramiento de la calidad, una responsabilidad que recae cada vez más en quienes desarrollan el software.

Tusk, una startup pionera y exalumna de Y Combinator (YC), ayuda a las empresas a prevenir errores que, de otro modo, pasarían desapercibidos tanto para agentes de codificación como para humanos mediante pruebas habilitadas por IA que se basan en tráfico real de producción. Al utilizar modelos fundacionales de alto rendimiento en Amazon Bedrock, Tusk identifica de manera automática problemas como regresiones inesperadas y desviaciones en los contratos de API antes de la fusión del código, lo que permite a los equipos de ingeniería centrarse en tareas de mayor valor.

Pruebas de software basadas en la realidad, no en suposiciones

Fundada en 2023 por dos graduados de UC Berkeley, Tusk ayuda a las empresas a entregar código de calidad mediante pruebas generadas por IA basadas en el comportamiento real de los usuarios. “Tusk convierte su tráfico de producción en pruebas unitarias y de API realistas”, afirma Marcel Tan, CEO. “Lo logramos al registrar trazas cuando los usuarios interactúan con su aplicación en entornos reales y reproducir esas trazas frente a los cambios de código para detectar y prevenir regresiones”. Esto representa un cambio significativo en la forma en que empresas de todos los tamaños pueden abordar las pruebas de código en la era de la IA.

“Si observa a los mejores equipos de ingeniería en la actualidad, quienes realizan el aseguramiento de la calidad suelen ser también quienes desarrollan la característica”, afirma Tan. El razonamiento detrás de esta tendencia es sólido. Estos equipos cuentan con mejor contexto para abordar las pruebas, ya que son quienes actualizan y optimizan el código. Sin embargo, a medida que aumenta el volumen de código, la corrección de errores se ha vuelto cada vez más lenta. “En el pasado, el aseguramiento de la calidad representaba aproximadamente la mitad del ciclo de lanzamiento. Con los agentes de codificación actuales, los mejores ingenieros dedican el 90 % de su tiempo al aseguramiento de la calidad, lo cual no es un buen uso de su tiempo”, agrega Tan.

“La mayoría de las pruebas escritas manualmente o con IA no reflejan realmente cómo interactúan los usuarios con su producto en el mundo real”, señala Tan. “Como capturamos tráfico real, ofrecemos cobertura de casos límite que, de otro modo, pasarían desapercibidos”. Esto incluye fallos silenciosos derivados de comportamientos semánticos no intencionados. En estos casos, una salida parece válida, pero es funcionalmente incorrecta. Tusk ejecuta e itera sobre las pruebas que genera y, al evaluarlas frente a tráfico real de producción, facilita la detección de regresiones que, de otro modo, serían prácticamente imposibles de prever.

Impulso del éxito desde la primera presentación hasta el ajuste producto-mercado

Tusk comenzó como uno de los primeros agentes de codificación disponibles públicamente. “Queríamos crear un agente de codificación que permitiera a gestores de producto, ingenieros de software e incluso personas sin perfil técnico pasar de un ticket de JIRA a una solicitud de extracción”, afirma Tan. “Podría decirse que fuimos el primer agente capaz de hacerlo en una base de código madura”. Tras presentar esta primera versión de su producto, la empresa fue aceptada en la cohorte W24 de YC, donde el Tusk actual comenzó a tomar forma.

“Los tres meses en YC son muy intensos”, afirma Tan. “Es básicamente un bootcamp y no se piensa en nada más que en la startup”. Para Tusk, uno de los aspectos más valiosos de la experiencia en YC fue la conexión con otros fundadores, incluido un grupo más reducido y seleccionado dentro de la cohorte. Estos grupos se reunían con regularidad para analizar sus objetivos y avances. “Resulta muy motivador, porque puede ver la rapidez con la que avanzan las personas en tres o cuatro días. Ese sentido de urgencia se integra en la startup: le aporta un buen ADN”, señala Tan.

Una lección duradera de la incubadora fue el valor de interactuar de forma directa con los clientes. “En lugar de intentar deducir lo que necesitaban nuestros clientes, se nos animó a preguntarles directamente”, afirma Tan. “Parece algo obvio, ¿verdad? A veces, el consejo más sencillo es el mejor”. De hecho, fue tras interactuar con los clientes cuando el equipo de Tusk comenzó a replantear la dirección de su empresa.

“Entonces nuestros clientes señalaron de forma reiterada que generar más solicitudes de extracción estaba creando más trabajo para sus ingenieros”, explica Tan. Esto, junto con la creciente disponibilidad de asistentes de codificación basados en IA, proporcionó una señal clara de hacia dónde se dirigía la industria. “Escribir código se estaba convirtiendo en algo común”, afirma Tan. “Nos dimos cuenta de que en 18 meses el cuello de botella sería verificar que el código funciona”. Como resultado, el equipo cambió el enfoque y reorientó la empresa hacia las pruebas, sentando las bases del producto que ofrece hoy.

Libertad para centrarse en el cliente, no en el costo

Poco después de salir de YC, Tusk comenzó a colaborar con AWS. La empresa participó en AWS Activate, un programa diseñado para apoyar a startups mediante experiencia técnica, oportunidades de comercialización y financiación en forma de créditos de AWS. “Ha sido increíble”, afirma Sohil Kshirsagar, CTO. “El equipo de AWS ha respondido con mucha rapidez, incluso cuando éramos mucho más pequeños. Además, la cantidad de créditos que hemos recibido ha sido de gran ayuda. Es, en esencia, una inversión que recibimos sin ceder participación”. Esto resulta especialmente valioso para startups que dependen de infraestructura de IA.

“Como startup previa a la IA, sus costos en la nube se limitaban a aspectos como alojamiento y almacenamiento, pero hoy los modelos de lenguaje de gran tamaño (LLM) se convierten en su principal costo”, afirma Kshirsagar. “Si no contáramos con esos créditos, cada vez que lanzáramos algo para el cliente nos preguntaríamos cuánto va a costar, si va a afectar a nuestra meta. Pero ahora podemos centrarnos en resolver el problema y optimizarlo después”.

Además del ahorro de costos, AWS Activate permitió al equipo de Tusk centrar su atención en lo realmente importante. “Ya hay muchas cosas de las que debemos preocuparnos cada día; no queremos que el uso o el gasto en la nube sea una de ellas”, explica Kshirsagar. “Activate nos permite mantener el enfoque en el cliente: cuál es su problema y cómo podemos resolverlo de la mejor manera, sin pensar constantemente en las implicaciones de costo a largo plazo”.

La observabilidad en tiempo real se une a la inteligencia escalable

Tusk utiliza una combinación de servicios de AWS para inferencia y supervisión. “Amazon Bedrock es nuestra solución principal de inferencia de modelos de lenguaje de gran tamaño”, afirma Kshirsagar. “Uno de los principales beneficios que nos ofrece es la inferencia escalable entre regiones, lo cual resulta importante en fases iniciales, cuando puede pasar de uno a diez clientes en un par de semanas y necesita aumentar los límites de tasa”.

Los modelos que utiliza Tusk en Amazon Bedrock impulsan la comprensión semántica y la clasificación de regresiones. “Cuando Tusk analiza diferencias en los resultados de una respuesta de API, debe tener en cuenta que puede estar cambiando la estructura de la API o modificando ligeramente la respuesta”, explica Kshirsagar. “Utilizamos modelos de razonamiento en Bedrock para determinar si ese cambio es una regresión o una actualización intencionada en función del contexto de la solicitud de extracción”.

Amazon Bedrock ayuda a Tusk a optimizar el uso de modelos y tokens. “A menudo cambiamos de modelo según la complejidad de la tarea”, afirma Kshirsagar. Si se necesita un cambio de modelo, Amazon Bedrock facilita ese proceso, que suele ser tan sencillo como actualizar el identificador del modelo.

Más allá del cuello de botella del control de calidad, hacia una garantía de principio a fin

A medida que Tusk continúa creciendo y evolucionando, la mentalidad centrada en el cliente desarrollada durante su paso por YC sigue siendo fundamental. “Observamos mucho agotamiento entre los ingenieros”, afirma Tan. “Queremos ayudarles a dedicar menos tiempo a las pruebas y más a tareas interesantes, como diseñar soluciones para problemas complejos o trabajar en características orientadas al usuario”.

Para lograr esa ambición, Tusk está reforzando su colaboración con AWS y el uso de Amazon Bedrock. “A medida que seguimos lanzando nuevas características y llegamos a nuevos clientes, es probable que nuestro uso de Amazon Bedrock crezca de forma exponencial”, afirma Kshirsagar. “También hemos hablado con AWS sobre la posibilidad de ajustar modelos o crear y entrenar nuestros propios modelos en instancias AWS Trainium EC2”.

“Tenemos previsto convertirnos en la plataforma integral de pruebas”, afirma Tan. “Cubriremos de forma inteligente los principales tipos de pruebas en los que confían las empresas de software: pruebas unitarias, de integración (API) y de extremo a extremo. Esto permitirá que Tusk funcione como un ingeniero de pruebas de IA de nivel de plantilla que cualquiera puede contratar, incluso una startup de una sola persona, para realizar el aseguramiento de la calidad de cualquier cambio de código y solicitud de extracción que cree. Ese es el objetivo final.”