El consejo que doy a mis clientes es sencillo: No puedes competir sin la ayuda de la IA. Tampoco puedes competir produciendo slop de IA. Usa las herramientas y conserva la experiencia necesaria para usarlas bien.
Tobi Lütke, director ejecutivo de Shopify, describió hace poco como «granadas de slop» el resultado de la IA que se pasa a los compañeros sin revisarlo. Su ejemplo incluía correos inflados que dejan al destinatario la tarea de extraer la información útil. Alguien se siente productivo mientras otra persona hereda la limpieza.
Es una buena descripción. Pero cuando esto ocurre dentro de una organización, mi primera pregunta es qué ha decidido premiar la dirección, qué experiencia ha conservado y si alguien está midiendo el trabajo que aparece después de que alguien marca algo como «terminado».
Uso mucho la IA para construir software. No me interesa volver a un mundo en el que escribo a mano cada línea de código. La combinación que recomiendo es gente con experiencia y herramientas de IA potentes, y la aportación humana empieza antes de que el agente escriba nada. Alguien tiene que elegir un enfoque, establecer las restricciones y reconocer una solución que valga la pena construir.
¿El slop de la IA es un problema de ingeniería o de gestión?
El problema de gestión viene primero. Shopify recortó aproximadamente el 10 % de su plantilla en julio de 2022, y Lütke reconoció que había sobrestimado la permanencia del auge del comercio electrónico durante la pandemia. En mayo de 2023 anunció otra reducción de cerca del 20 % junto con la venta de Shopify Logistics. Ese segundo anuncio también destacaba las oportunidades de la nueva era de la IA. Fueron decisiones de liderazgo sobre el rumbo, la plantilla y las prioridades de la empresa.
En abril de 2025, Lütke convirtió el uso de la IA en una expectativa básica, lo incorporó a las evaluaciones de desempeño y entre compañeros, y exigió que los equipos que pidieran más personal o recursos explicaran por qué la IA no podía cubrir esa necesidad. Su memorando también defendía explícitamente multiplicar la habilidad humana con la IA. Estoy de acuerdo con ese principio.
Esos hechos no demuestran que los despidos de Shopify hayan causado sus granadas de slop, ni que ingenieros con experiencia hayan sido sustituidos en masa por operadores de prompts sin formación técnica. Pero sí demuestran por qué importa la pregunta sobre la gestión. Quien fija la política de personal y las expectativas sobre el uso de la IA también asume la responsabilidad de hacer que esa combinación funcione.
Mi objeción es a un modelo operativo que pide a los empleados demostrar que adoptan la IA sin dar el mismo peso al criterio, la verificación y el mantenimiento necesarios para convertir el resultado generado en trabajo útil. Antes de preguntar si la IA puede hacer un trabajo, la dirección debería preguntar qué hace falta para entregar el resultado correctamente. No son la misma pregunta.
¿Puede un agente producir una pull request? Estupendo. ¿Quién sabe si resuelve el problema correcto? ¿Quién revisa las implicaciones arquitectónicas? ¿Quién se hace responsable cuando falla? ¿Cuánto del día de otro empleado va a desaparecer revisándola y reparándola?
Los empleados siguen siendo responsables de lo que entregan. Pero cuando la gente se pasa repetidamente entre sí trabajo que no puede evaluar, yo veo un problema de diseño organizativo, no simplemente un conjunto de empleados decepcionantes. La dirección no puede atribuirse el mérito de las ganancias de productividad y tratar la limpieza como un problema de talento.
¿Usar IA para construir algo te convierte en ingeniero?
Pulsar Enter no es ingeniería. No hay nada malo en que personas sin formación técnica usen la IA para construir cosas. Bajar la barrera de entrada a la experimentación es una de las partes más apasionantes de esta tecnología. Alguien que antes no podía llevar una idea más allá de un boceto ahora puede explorar un prototipo que funciona, y eso me parece fantástico.
Un prototipo y un sistema en producción son responsabilidades distintas, eso sí. Alguien tiene que entender qué se ha construido, de qué supuestos depende y qué evidencia mostraría que esos supuestos son falsos.
Poner a una persona entre un agente y el botón de despliegue no garantiza automáticamente una supervisión significativa. Esa persona necesita el conocimiento para cuestionar al agente, el tiempo para investigar su trabajo y la autoridad para rechazar el resultado. De lo contrario, el paso de aprobación es ceremonial.
Esta no es solo una preocupación de quienes desconfían de la IA. La propia guía de GitHub advierte de que sus agentes pueden producir código incorrecto o inseguro, recomienda revisar y probar su resultado, y dice que la revisión de código con IA debería complementar la revisión humana, no sustituirla.
La aprobación a ciegas es un problema de «basura entra, basura sale», pero la basura no está necesariamente confinada al prompt. Puede ser un requisito incompleto, una restricción ausente, un incentivo para ir demasiado deprisa, o un proceso de revisión que se reduce a preguntarle al mismo sistema si lo ha hecho bien. La solución es emplear a gente que sepa cuándo discrepar.
La ingeniería es saber cómo, no solo pedir qué
Hay una diferencia sustancial entre decirle a un agente qué debe hacer un producto y saber cómo debería implementarse ese producto. «Constrúyeme un sistema que procese estos registros» describe un resultado. Dice muy poco sobre la arquitectura, la carga de trabajo esperada, el presupuesto de memoria, los límites de seguridad o el comportamiento cuando algo falla.
Un buen ingeniero asistido por IA aporta esa dirección que falta. Puede decirle al agente que siga los patrones de código establecidos del proyecto, que reutilice una abstracción existente, que elija una estructura de datos apropiada o que evite un algoritmo que se vuelve prohibitivamente caro a medida que crece la entrada. Escribir instrucciones para el repositorio solo sirve si alguien sabe qué deben decir esas instrucciones.
Eso no significa dictar cada detalle de implementación ni dar por hecho que la primera idea del humano tiene que ser mejor. Quiero que el agente proponga alternativas y cuestione supuestos. Pero alguien necesita entender lo suficiente para evaluar esas alternativas en lugar de aceptar la explicación que suene más segura.
«Hazlo eficiente» no sustituye a entender la eficiencia. «Hazlo seguro» no es un modelo de seguridad. Son aspiraciones hasta que alguien las traduce en requisitos concretos y verifica que la implementación los cumple.
¿Sigue importando la notación O grande si la IA escribe el código?
La notación O grande no ha desaparecido. Pensemos en un ejemplo sencillo: emparejar registros entre dos colecciones usando identificadores únicos. Una implementación podría recorrer repetidamente la segunda colección por cada registro de la primera. Con dos colecciones de n registros, eso puede requerir n² comparaciones. Como alternativa, para identificadores de tamaño fijo, construir una búsqueda basada en hash puede dejar el emparejamiento en tiempo esperado O(n), a cambio de O(n) de memoria adicional. Eso es un compromiso entre tiempo y espacio, no una cuestión de preferencias de formato.
Ambas implementaciones podrían dar la respuesta correcta en una demostración pequeña. La pregunta de ingeniería es qué ocurre bajo la carga de trabajo que el producto realmente tiene que soportar. ¿Cuántos datos procesará? ¿Cuánta memoria hay disponible? ¿Es una operación ocasional o algo que sucede en cada petición?
Un operador con experiencia puede darle al agente una dirección útil: «Evita recorrer la colección entera por cada registro. Construye una tabla de búsqueda, ten en cuenta su coste en memoria y mide el rendimiento de la implementación con los tamaños de entrada que esperamos». Esa instrucción nace de entender el problema, no de descubrir un prompt mágico.
Ese mismo entendimiento debería evitar la optimización innecesaria. No quiero que un agente convierta una operación trivial en un armatoste elaborado solo porque alguien le dijo que maximizara el rendimiento. Quiero que el operador entienda la complejidad temporal, la complejidad espacial y los requisitos reales lo bastante bien como para elegir una solución apropiada.
La informática no se ha vuelto opcional porque las instrucciones ahora se escriban en español. Hemos cambiado cómo pedimos el software. No hemos cambiado las propiedades que hacen que el software sea correcto, eficiente o mantenible.
A veces hay que decirle que construya una máquina de estados
Supongamos que estoy construyendo un proceso de importación en segundo plano que puede estar en cola, en ejecución, completado, fallido o cancelado. Una implementación plausible podría seguir su progreso mediante un conjunto de banderas separadas. Pero ese diseño tiene que impedir combinaciones contradictorias, como que un trabajo esté a la vez en ejecución y completado.
Una máquina de estados finitos le da a ese flujo un conjunto explícito de estados y transiciones definidas entre ellos. En lugar de repartir por toda la aplicación las decisiones sobre qué puede pasar a continuación, puedo modelar qué eventos pueden mover el proceso de un estado a otro. Esos son los conceptos básicos que hay detrás de la notación de máquinas de estados: estados, eventos y transiciones.
El agente podría proponer ese enfoque por su cuenta. Perfecto. Pero puede que no lo haga, y la persona que lo dirige tiene que reconocer cuándo el problema lo pide. A veces la instrucción útil es: «Implementa esto como una máquina de estados finitos. Define las transiciones legales, gestiona la cancelación de forma explícita y prueba qué ocurre cuando llega un evento de finalización después de una cancelación». Es elegir un modelo para el comportamiento del sistema.
Las máquinas de estados finitos, los statecharts y otros autómatas forman parte de la caja de herramientas técnica del operador humano. No porque toda funcionalidad necesite un modelo formal, sino porque el operador debería reconocer cuándo uno aclararía el problema y cuándo añadiría complejidad innecesaria. Saber el nombre de un patrón no basta. Hay que entender dónde se aplica, qué garantiza y qué deja sin resolver.
Y «usa una máquina de estados» no es un conjuro que vuelva correcta la implementación. Sigo teniendo que examinar las transiciones y probar el comportamiento. El valor está en que le he dado al agente una estructura sobre la que puedo razonar, en lugar de aceptar un amasijo de condiciones solo porque pasó la prueba del camino feliz.
La interacción persona-ordenador tampoco es opcional
La informática no es la única experiencia que seguimos necesitando. La interacción persona-ordenador también importa, y no estoy dispuesto a tratarla como un acabado opcional solo porque un agente pueda generar una pantalla tan rápido como genera el código que hay detrás.
Espero que una parte cada vez mayor de internet se vuelva agent-first. Pero sigo construyendo productos que la gente necesita entender y usar. Esas personas necesitan saber qué está pasando, qué significan sus opciones, si una acción tuvo éxito y cómo recuperarse cuando algo sale mal. La visibilidad, la coherencia, el control del usuario y la prevención de errores son principios establecidos del diseño de interacción, no preferencias decorativas.
«Haz una buena interfaz» es más o menos tan útil como «haz que el algoritmo sea eficiente». Un profesional competente puede darle al agente una dirección mucho más precisa: organiza la información en torno a la tarea del usuario, conserva la navegación familiar, distingue las acciones principales de las destructivas y haz comprensibles los estados de progreso y de fallo. La accesibilidad añade requisitos concretos de implementación, incluidos el manejo por teclado, el foco visible, las etiquetas con significado y los mensajes de estado accesibles.
Tomemos el proceso de importación en segundo plano del ejemplo de la máquina de estados. Acertar con los estados internos es solo una parte del trabajo. También quiero que la interfaz distinga entre esperando a empezar, importando activamente, parcialmente completado, cancelado y fallido. La persona que la usa no debería tener que deducir esas diferencias a partir de un indicador giratorio.
Mis instrucciones al agente podrían ser: «Conserva las selecciones del usuario después de un fallo. Explica qué registros se importaron y cuáles no. No muestres un mensaje de éxito hasta que la operación haya terminado de verdad. Indica si todavía es posible cancelar y deja explícito el comportamiento del reintento».
Eso es orientación de implementación, no una petición de colores más bonitos. Sigo teniendo que usar la interfaz resultante, probar los estados relevantes y observar si la gente la entiende. Una captura de pantalla bonita no es prueba suficiente de que la interacción funciona.
Lo mismo se aplica a las propias interfaces de los agentes. Sustituir los menús por conversación no elimina la necesidad de comunicar alcance, progreso, incertidumbre y consecuencias. Yo diría que un agente que actúa sobre varios sistemas hace que esas decisiones de diseño sean más importantes, no menos. El humano sigue necesitando una forma de entender, interrumpir, corregir y aprobar el trabajo.
Un internet agent-first no es un internet irrelevante para los humanos. Mientras haya personas dirigiendo el trabajo y conviviendo con sus consecuencias, alguien tiene que diseñar esa relación.
¿Quién responde por la seguridad cuando el código lo escribe un agente?
Pulsar Enter no es una estrategia de seguridad ni de privacidad. La calidad del código es solo una parte de la responsabilidad. Un agente también puede pedir acceso a archivos, ejecutar comandos, interactuar con servicios y generar código con vulnerabilidades. La propia guía de GitHub advierte explícitamente sobre resultados incorrectos o inseguros y sobre la necesidad de revisarlos y probarlos con cuidado.
Antes de aprobar una acción, quiero que el operador se pregunte a qué puede acceder, qué puede cambiar y adónde pueden ir a parar los datos. ¿Esta tarea necesita credenciales de producción? ¿Podrían esos registros de depuración contener información de clientes? ¿Por qué una operación que solo necesita leer datos tiene permiso para modificarlos o borrarlos?
No son detalles que se puedan dejar para después de que la demo funcione. OWASP identifica el exceso de funcionalidad, de permisos y de autonomía como fuentes de riesgo en los sistemas agénticos. Sus recomendaciones incluyen limitar capacidades, aplicar el mínimo privilegio, exigir aprobación para acciones de alto impacto e implementar la autorización fuera del modelo en lugar de confiar en que él decida qué está permitido.
Alguien que aprueba a ciegas cada petición no está evaluando esos riesgos de forma significativa. Pero la respuesta tampoco es simplemente contratar a alguien con experiencia y esperar que lo detecte todo. Dale a esa persona un entorno con límites aplicados por el sistema, controles de acceso apropiados y un proceso de revisión que no dependa de una vigilancia perfecta.
Por eso me importa el entendimiento del operador. Necesita ayudar a diseñar las salvaguardas, no solo ocupar la silla frente al botón de aprobar.
El cumplimiento normativo es parte de la ingeniería
Un producto que funciona en una demo no es necesariamente un producto que una organización pueda operar de forma responsable. Alguien también tiene que entender qué información maneja, quién puede acceder a ella, qué obligaciones aplican y qué evidencia necesita la organización para demostrar que sus controles funcionan.
Según el negocio, eso puede incluir SOC 2, PCI DSS e HIPAA. Son tipos distintos de obligaciones y mecanismos de aseguramiento, no tres insignias intercambiables:
- SOC 2 es un examen independiente de los controles frente a los Trust Services Criteria aplicables. Esos criterios incluyen la gestión de cambios: autorizar, documentar, probar, aprobar e implementar los cambios del sistema. Que un agente genere una compilación correcta no demuestra que la organización siguiera ese proceso.
- PCI DSS establece requisitos técnicos y operativos de seguridad para los datos de cuentas de pago. Su alcance puede incluir sistemas y proveedores de servicios que afectan a la seguridad del entorno de datos de titulares de tarjeta, no solo una base de datos que almacene directamente números de tarjeta. Entender ese alcance es parte de diseñar y operar el sistema de forma responsable.
- HIPAA, cuando aplica a entidades cubiertas y socios comerciales, trae requisitos para proteger la información sanitaria electrónica protegida. Su Regla de Seguridad incluye análisis de riesgos, controles de acceso, controles de auditoría y acuerdos apropiados con los socios comerciales. Esas responsabilidades no desaparecen porque un asistente de IA ayudara a escribir la aplicación.
No espero que cada desarrollador sea abogado de cumplimiento ni auditor. Espero que un equipo con experiencia reconozca cuándo estos requisitos afectan a un diseño y traiga la experiencia adecuada antes de lanzarlo. «Nadie se lo dijo al agente» es un fallo de requisitos, no una exención.
Para cambios importantes en producción, quiero una traza de auditoría que conecte la petición con la implementación, las pruebas, la revisión, la aprobación y el despliegue. ¿Qué cambió? ¿Por qué? ¿Qué versión se revisó? ¿Quién lo aprobó y con qué autoridad? ¿Qué llegó realmente a producción?
Ese registro debería producirse mientras sucede el trabajo, no reconstruirse después a partir de la memoria de alguien y del alegre resumen de un agente. Un registro que dice «aprobado» demuestra que alguien pulsó un botón. Por sí solo, no demuestra que haya habido una revisión significativa.
¿Qué significa de verdad aprobar el trabajo de un agente?
Una aprobación es una decisión, no una pulsación de tecla. Pulsar Enter sin revisar las consecuencias puede poner en riesgo a la organización, a sus clientes y a la persona que aprueba la acción. Pensemos en un agente que propone subir registros de producción a un servicio externo para depurar. Antes de aprobar esa petición, alguien tiene que determinar qué contienen esos registros y si ese destino está permitido. La comodidad de la solución propuesta no responde a ninguna de las dos preguntas.
También puede haber consecuencias para el empleado que se salta las salvaguardas obligatorias. La guía del HHS sobre las políticas de sanción de HIPAA, por ejemplo, habla de consecuencias que van desde advertencias hasta el despido, dejando la respuesta apropiada en manos de la organización y de las circunstancias. No es una afirmación de que toda aprobación equivocada deba costarle el puesto a alguien. Es un recordatorio de que una aprobación puede conllevar responsabilidad profesional.
Pero la dirección no puede asignar con justicia esa responsabilidad sin proporcionar el conocimiento, el tiempo, la información y la autoridad necesarios para ejercerla. Darle a alguien una cola de aprobaciones que no puede evaluar, medirlo por la rapidez con que la vacía y luego culparlo del resultado no es una delegación responsable.
La propia interfaz de aprobación tiene que sostener la decisión. Para un despliegue, quiero que quien revisa vea el cambio real, el entorno de destino, los resultados de las pruebas relevantes, los riesgos sin resolver y el plan de recuperación. No quiero que «¿Continuar? S/n» haga las veces de una explicación de lo que está a punto de ocurrir.
Tampoco quiero un flujo de trabajo que exija aprobación humana para cada acción inofensiva. Mi objetivo es automatizar el trabajo de bajo riesgo dentro de límites establecidos y reservar la atención humana para las decisiones que requieren criterio. Añadir más botones no es lo mismo que añadir más supervisión.
Ford tuvo que reconstruir la experiencia que había perdido
Bloomberg informó en junio de 2026 de que Ford había contratado a 350 ingenieros veteranos en los tres años anteriores, incluidos antiguos empleados e ingenieros de proveedores. Estaban ayudando a resolver problemas de calidad, a formar al personal más joven y a mejorar herramientas de IA que se habían quedado cortas. Era una historia sobre ingeniería de vehículos y sistemas de calidad, no una afirmación de que Ford recontratara a 350 desarrolladores de software para limpiar código de aplicaciones generado por IA.
Esa es la lección que yo me llevaría a una empresa de software. Antes de quitar a un ingeniero caro de una hoja de cálculo, entiende qué aporta esa persona más allá del resultado visible. Pregunta qué evita, qué detecta a tiempo y qué espera el resto del equipo que entienda. Después, piensa qué podría ayudarle a lograr con mejores herramientas.
¿De verdad unos salarios más bajos significan costes más bajos?
Deja de confundir salarios más bajos con costes más bajos. La dirección quiere recortar costes laborales. Lo entiendo. Yo también dirijo empresas, y no estoy sugiriendo que las compañías gasten dinero sin esperar un retorno. Pero yo evaluaría ese retorno frente al coste de entregar y mantener un producto útil, no simplemente frente al salario asociado a cada persona que trabaja en él.
Un amigo me envió hace poco una oferta de empleo para un puesto presencial de ingeniería de software en Nueva York. Exigía un máster y seis años de experiencia en el sector y anunciaba 200.000 dólares. La combinación no me cuadraba. Para el nivel de ingeniero que yo querría dirigiendo desarrollo asistido por IA con consecuencias reales, estructuraría el puesto de otra manera.
Primero, eliminaría el requisito del máster salvo que se tratara de un puesto de investigación en el que esa formación importara de verdad. Quiero saber qué ha construido alguien, qué decisiones difíciles ha asumido y si entiende las consecuencias de esas decisiones. Exigir conocimientos de informática no es lo mismo que exigir un diploma concreto.
¿Sabe explicar por qué eligió una arquitectura en lugar de otra? ¿Sabe reconocer un límite de seguridad, razonar sobre rendimiento y diseñar un sistema que se comporte con sensatez cuando algo falla? ¿Sabe dirigir a un agente hacia una buena implementación y rechazar otra aparentemente exitosa que no cumple los requisitos reales?
Esas son las capacidades por las que yo contrataría. Luego presupuestaría unos 350.000 dólares de salario anual, con hasta 2.000 dólares al mes para asistencia de IA, y esperaría que el proceso de selección demostrara que el candidato puede justificar esa inversión.
Ese es mi presupuesto propuesto para un puesto de alto impacto, no una afirmación de que todos los puestos de ingeniería deban pagar lo mismo. Ofrecer un salario más alto tampoco libera a la dirección de la responsabilidad de evaluar bien a los candidatos. La idea es competir con agresividad por la experiencia de la que depende la estrategia, en lugar de suponer que una suscripción de IA hace que esa experiencia valga menos.
¿De cuánto debería ser el presupuesto de herramientas de un ingeniero?
Dale al ingeniero un presupuesto serio de herramientas. La asignación mensual de 2.000 dólares sería un presupuesto total de herramientas de IA, no el precio de una sola suscripción ni la obligación de gastar hasta el último dólar. Para un caso de uso aprobado, pienso en algo como un plan Claude Max reembolsado más uso adicional. Anthropic ofrece uso de pago por encima de la asignación incluida en el plan, con controles de gasto.
La cuenta y el despliegue todavía tienen que encajar con los requisitos de seguridad, privacidad y contractuales de la organización. Reembolsar una suscripción personal no resuelve esas cuestiones. El equipo tiene que elegir el arreglo apropiado para la información y los sistemas implicados.
Con la asignación completa, eso son 24.000 dólares al año en gasto de IA junto a un salario de 350.000, es decir, 374.000 dólares en salario y herramientas antes de prestaciones, cotizaciones del empleador, bonus, acciones y otros gastos generales. Las herramientas cuestan menos del 7 % del salario. Yo juzgaría ese gasto por lo que le permite entregar al ingeniero.
En una comparación deliberadamente simplificada de salario y herramientas, 374.000 dólares son 1,87 veces 200.000. Si la combinación más cara entrega más de 1,87 veces más trabajo útil y comparable, su coste por unidad de ese trabajo es menor. Es una ilustración de la economía, no una predicción. Una comparación real necesita los costes completos de ambos lados.
La ambición es convertir a un desarrollador 10x en uno 100x. Esas cifras describen lo que quiero perseguir, no un multiplicador de productividad garantizado. Esperaría que un ingeniero cuidadosamente seleccionado con buenas herramientas rindiera más que una estrategia de contratación basada en encontrar a alguien más barato y suponer que la IA aportará el criterio que falta, pero verificaría esa expectativa con el trabajo entregado.
Nada de esto hace prescindibles a los desarrolladores junior. Quiero que aprendan junto a gente con experiencia, usando la IA mientras desarrollan el conocimiento para cuestionarla. El error caro es quitarles a sus mentores y asignarles responsabilidades que todavía no están preparados para asumir porque la dirección decidió que un agente aportaría la experiencia.
Una organización para humanos y agentes
Esta es la combinación sobre la que estoy construyendo con Orgabot: humanos y agentes de IA ocupando roles definidos en una organización, con flujos de trabajo que especifican responsabilidades, permisos, comprobaciones y aprobaciones. La idea es hacer la forma de trabajar de la organización lo bastante explícita como para que el trabajo autónomo pueda ocurrir dentro de límites que signifiquen algo.
La distinción que me importa es entre aquello sobre lo que un agente puede razonar y aquello que el software que lo rodea debe imponer. La planificación y la implementación flexibles conviven con controles sobre el acceso a herramientas, las aprobaciones obligatorias, los resultados de las pruebas y la evidencia de auditoría. El requisito de obtener una aprobación no debería ser una sugerencia dentro de un prompt que el agente pueda reinterpretar.
Para un cambio importante en producción, el flujo que quiero empieza con una persona cualificada estableciendo el objetivo y las restricciones. Los agentes pueden investigar, proponer enfoques, implementar el cambio y ayudar con las pruebas y la revisión. Después, las personas responsables evalúan la evidencia apropiada al riesgo antes de que el cambio aprobado pase a producción.
Quiero que la aprobación esté ligada a la versión que realmente se revisó. Si la implementación cambia de forma sustancial después, debería volver a recibir la revisión necesaria. También quiero un registro claro de la petición, el trabajo realizado, las comprobaciones que se ejecutaron, las decisiones tomadas y el resultado del despliegue.
Eso es lo que significa para mí diseñar Orgabot pensando en el cumplimiento normativo: hacer que las responsabilidades y la evidencia formen parte del proceso. No significa instalar una herramienta y declarar que la organización cumple. La organización sigue teniendo que establecer sus obligaciones, configurar los controles apropiados y demostrar que funcionan.
La aportación humana importa en todo el recorrido. Alguien tiene que reconocer la necesidad de una máquina de estados, cuestionar un algoritmo caro, proteger un límite de privacidad, identificar un requisito normativo aplicable o explicar por qué una interfaz va a confundir a la gente. Esas responsabilidades pueden repartirse entre varios profesionales con experiencia. Un organigrama debería dejar clara esa titularidad.
¿Cómo se evitan las granadas de slop?
Contrata para la titularidad, no para la aprobación. Asigna el trabajo con consecuencias a alguien que pueda evaluar el resultado y seguir siendo responsable de él después del despliegue. Contrata por el entendimiento demostrado, no solo por un título, un currículum largo o el entusiasmo por el último modelo. Da a la gente con menos experiencia supervisión y un camino para desarrollar ese entendimiento.
Define el éxito antes de generar la solución. Escribe el comportamiento que necesitas, las restricciones que no se pueden violar y la evidencia requerida para aceptar el trabajo. Incluye los casos de fallo. No basta con que un agente produzca código y luego produzca pruebas que coincidan con ese código; la verificación tiene que volver a los requisitos originales.
Haz que la revisión sea real y financíala en consecuencia. Presupuesta tiempo para inspeccionar cambios, cuestionar supuestos, probar integraciones y comprobar la experiencia real del usuario. Usa la IA para asistir en esas actividades, pero no conviertas la aprobación de otro modelo en la única base para confiar en el resultado. La persona responsable debe poder detener el proceso sin que la traten como un obstáculo para la productividad.
Mide el trabajo completo. Cuenta el tiempo dedicado a aclarar, generar, revisar, reparar, desplegar y mantener el trabajo, junto con el coste de las herramientas. Compáralo con el resultado entregado. Una tarea no es más eficiente porque una persona terminara antes mientras tres compañeros absorbían la diferencia.
Nada de esto exige rechazar la IA ni ir despacio a propósito. Exige ser honesto sobre qué significa «terminado».
La dirección es dueña de las condiciones
Lütke tiene razón al objetar al trabajo que genera más trabajo para otra persona. Mi objeción es tratar ese comportamiento como algo separable de la plantilla, los incentivos y los estándares que lo rodean. La estrategia de IA de una empresa incluye quién usa las herramientas, qué entienden esas personas y qué espera la dirección que verifiquen.
Entiendo que se quieran recortar los costes laborales. Yo lo perseguiría mediante mejores resultados por dólar, incluso cuando eso signifique gastar más en un ingeniero concreto. Contrata por experiencia demostrada, paga lo suficiente para competir por ella y proporciona las herramientas y las condiciones de trabajo que hacen que esa experiencia importe.
Recortar la capacidad de evaluar el trabajo mientras se amplía la capacidad de generarlo es una forma muy eficiente de producir granadas de slop. No puedes competir sin la ayuda de la IA. Tampoco puedes competir produciendo slop de IA. La dirección es dueña de las condiciones que determinan qué resultado obtiene.
Referencias
- The Knowledge Project
- Anuncio de Shopify de 2023
- Anuncio de Shopify de 2022
- Memorando de Lütke de abril de 2025
- Guía de GitHub
- Notación de máquinas de estados del W3C
- Principios de usabilidad del Nielsen Norman Group
- Directrices de accesibilidad del W3C
- Guía de OWASP sobre agencia excesiva
- Trust Services Criteria del AICPA
- PCI Security Standards Council
- Resumen de la Regla de Seguridad del HHS
- Guía del HHS sobre políticas de sanción
- Información de Bloomberg
- Documentación de uso de Anthropic
- Orgabot
