Ingeniero de IA - Agentic Coding

Este puesto encaja con un ingeniero que tenga un interés activo en cómo la codificación agéntica cambia el trabajo de software, en lugar de un interés general en la IA.

Cuando se lanza un nuevo modelo o una nueva función de agente, la pruebas en cuestión de días, aplicándola a tus propios problemas complejos en lugar de a un ejemplo de juguete: una refactorización de código heredado cuya estructura ya conoces, una suite de pruebas que se resiste, una migración que ya has realizado anteriormente a mano. Tus opiniones provienen de eso, no de leer sobre ello, y puedes distinguir una mejora real de capacidad de una demo bien producida. La pregunta de segundo orden te interesa tanto como el resultado: si esto se mantiene, ¿qué cambia en nuestra forma de revisar código, estructurar repositorios, escribir especificaciones y ejecutar CI?

Probablemente te reconozcas en lo siguiente:

• Escribes e iteras tu propia configuración de agente (archivos de instrucciones, comandos personalizados, subagentes, servidores MCP) en lugar de aceptar los valores predeterminados.
• Sabes lo diferente que se comportan estas herramientas en una base de código grande, antigua e inconsistente en comparación con un proyecto "greenfield", y tienes opiniones sobre qué hace que un repositorio sea navegable para un agente.
• Has revisado mucho código escrito por agentes y puedes decir dónde falla de forma fiable: cambios que pasan las pruebas pero son incorrectos, refactorizaciones plausibles que pierden comportamiento silenciosamente, trabajos que parecen terminados y no lo están.
• Te importa el estado de la base de código, no solo el rendimiento. Has visto con qué rapidez puede erosionarse la calidad cuando la generación es barata y la revisión no lo es.
• Disfrutas haciendo que otros ingenieros sean más efectivos. La enseñanza es una parte sustancial de este rol, no una obligación ocasional.
• Ya sigues este campo de cerca en tu tiempo libre. Lo que este rol añade es el mandato, el presupuesto y las horas de trabajo para hacerlo adecuadamente.

• Enseñar a los ingenieros cómo utilizar las nuevas capacidades de forma eficaz; no solo que existe una función, sino qué cambia en el trabajo diario, demostrado en nuestro propio código.
• Trabajar directamente con los equipos en sus problemas reales: emparejamiento (pairing), depuración de flujos de trabajo de agentes e investigación de por qué una herramienta que funciona bien en una demo no funciona en nuestras bases de código.
• Dirigir sesiones, horas de consulta (office hours), demos y guías escritas, y convertir los problemas recurrentes del campo en mejoras permanentes.

• Equipar nuestras plantillas y "golden paths" con entornos para agentes: archivos de instrucciones de agentes, configuración de servidores MCP, comandos personalizados y subagentes, permisos de herramientas y valores predeterminados sensatos, para que los servicios funcionen bien con herramientas agénticas desde el primer día.
• Definir y realizar el seguimiento de las métricas de DevEx que muestren si estos cambios tienen un impacto real (adopción, tiempo de ciclo, rendimiento de entrega, fricción reportada por los desarrolladores), para que los cambios en las plantillas y los cambios de modelo puedan evaluarse basándose en evidencias.
• Poner los modelos recién aprobados a disposición de los equipos a través de nuestra capa de herramientas existente.

• Probar nuevos modelos a medida que se lanzan, tanto de código abierto como comerciales, y establecer cómo sus capacidades se comparan con los modelos de vanguardia que ya utilizamos.
• Evaluar frente a tareas que reflejen nuestro trabajo real en lugar de tablas de clasificación públicas, y ser específico sobre dónde un modelo más barato o abierto es suficiente y dónde no lo es.

• Seguir el panorama y distinguir los desarrollos sustanciales del ruido, cubriendo herramientas, protocolos, patrones de agentes y flujos de trabajo.
• Realizar evaluaciones estructuradas y con tiempo limitado de conceptos prometedores en nuestro propio contexto, y documentar qué se probó, qué recomiendas y qué no deberíamos perseguir por ahora.

¿Tienes alguna pregunta sobre el proceso de solicitud o el puesto? Por favor, ponte en contacto con Felipe Bianco ([email protected])

This position suits an engineer with an active interest in how agentic coding changes software work, rather than a general interest in AI.

When a new model or agent feature ships, you try it within days, against your own hard problems rather than a toy example - a legacy refactor whose shape you already know, a test suite that resists, a migration you have previously done by hand. Your views come from that, not from reading about it, and you can distinguish a real capability improvement from a well-produced demo. The second-order question interests you as much as the result: if this holds, what does it change about how we review code, structure repositories, write specifications and run CI?

You will probably recognize yourself in the following:

• You write and iterate on your own agent configuration - instruction files, custom commands, subagents, MCP servers - rather than accepting the defaults.
• You know how differently these tools behave on a large, old, inconsistent codebase than on a greenfield project, and you have views on what makes a repository navigable to an agent.
• You have reviewed a lot of agent-written code and can say where it reliably goes wrong: changes that pass the tests but are wrong, plausible refactors that quietly lose behavior, work that looks finished and is not.
• You care about the state of the codebase, not only about throughput. You have seen how quickly quality can erode when generation is cheap and review is not.
• You enjoy making other engineers more effective. Teaching is a substantial part of this role, not an occasional obligation.
• You already follow this field closely in your own time. What this role adds is the mandate, the budget and the working hours to do it properly.

• Teach engineers how to use new capabilities effectively - not only that a feature exists, but what it changes in day-to-day work, demonstrated on our own code.
• Work directly with teams on their real problems: pairing, debugging agent workflows, and investigating why a tool that performs well in a demo does not perform on our codebases.
• Run sessions, office hours, demos and written guides, and turn recurring problems from the field into permanent improvements.

• Equip our templates and golden paths with agent harnesses: agent instruction files, MCP server configuration, custom commands and subagents, tool permissions and sensible defaults, so services work well with agentic tools from day one.
• Define and track the DevEx metrics that show whether these changes have real impact - adoption, cycle time, delivery throughput, developer-reported friction - so template changes and model swaps can be assessed on evidence.
• Make newly approved models available to teams through our existing tooling layer.

• Test new models as they are released, open-source and commercial, and establish how their capabilities compare to the frontier models we already use.
• Evaluate against tasks that reflect our actual work rather than public leaderboards, and be specific about where a cheaper or open model is sufficient and where it is not.

• Follow the landscape and distinguish substantive developments from noise, covering tools, protocols, agent patterns and workflows.
• Run structured, time-boxed evaluations of promising concepts in our own context, and document what was tested, what you recommend, and what we should not pursue for now.

Do you have any questions about the application process or the position? Please reach out to Felipe Bianco ([email protected])