Hanademi

AI code needs guardrails, not blind trust

12 slides · 14 min · 1 minute ago language
ENES
theme
LightDark
view
DeckTableTalk
brand
HanademiPlatzi
AI code needs guardrails, notblind trustMade for Stuard Gerardo Carrillo Gonzalez, by Hanademi
El código con IA necesitacontroles, no confianza ciegaMade for Stuard Gerardo Carrillo Gonzalez, by Hanademi
AI improved perceived quality whiledelivery stability fellDORA associations for a 25% increase in AI adoption, percent change in 2024.Made for Stuard Gerardo Carrillo Gonzalez, by HanademiSources: Google Cloud. (2024). Accelerate State of DevOps Report 2024. Google.Unitassociated changePerceived code quality3.4%Throughput-1.5%Delivery stability-7.2%
AI adoption did not move every outcome together. DORA linked a 25% adoption increase to 3.4% better perceived code quality, but throughput fell 1.5% and delivery stability fell 7.2%. That split is the central warning: code that feels better can still make the system harder to ship safely.
La IA mejoró la calidad percibida mientrascayó la estabilidadAsociaciones de DORA para un aumento del 25% en adopción de IA, cambio porcentual en 2024.Made for Stuard Gerardo Carrillo Gonzalez, by HanademiFuentes: Google Cloud. (2024). Accelerate State of DevOps Report 2024. Google.Unidadcambio asociadoCalidad percibida3,4 %Rendimiento-1,5 %Estabilidad de entrega-7,2 %
La adopción de IA no movió todos los resultados en la misma dirección. DORA vinculó un aumento del 25% con 3,4% más calidad percibida, pero el rendimiento cayó 1,5% y la estabilidad de entrega cayó 7,2%. Esa división es la advertencia central: el código puede parecer mejor y aun así dificultar una entrega segura.
Four terms that matterPlain-language definitions used throughout the deck.Made for Stuard Gerardo Carrillo Gonzalez, by HanademiSWE-benchA benchmark built from real software issues requiring repository-level changes.pass@kThe chance that at least 1 of k generated answers passes.Formal verificationA mathematical proof that software satisfies a written specification.Delivery stabilityHow reliably teams release changes without failures or recovery work.
The debate becomes clearer when the terms are concrete. A benchmark tests a defined task, pass@k rewards repeated attempts, and formal verification proves only a written specification. Delivery stability then asks whether the wider system still works when changes reach users.
Cuatro términos importantesDefiniciones sencillas utilizadas en la presentación.Made for Stuard Gerardo Carrillo Gonzalez, by HanademiSWE-benchUn benchmark creado con incidencias reales que exigen cambios en repositorios.pass@kLa probabilidad de que al menos 1 de k respuestas generadas pase.Verificación formalUna prueba matemática de que el software cumple una especificación escrita.Estabilidad de entregaLa fiabilidad con que los equipos publican cambios sin fallos nirecuperación.
El debate se aclara cuando los términos son concretos. Un benchmark prueba una tarea definida, pass@k recompensa los intentos repetidos y la verificación formal demuestra solo una especificación escrita. La estabilidad de entrega pregunta después si el sistema completo sigue funcionando cuando los cambios llegan a los usuarios.
AI use outran trust in its accuracyStack Overflow developer survey responses, percent of respondents in 2024.Made for Stuard Gerardo Carrillo Gonzalez, by HanademiSources: Stack Overflow. (2024). 2024 Developer Survey: Artificial intelligence.Unitrespondents62%Use AI tools43%Trust accuracy31%Distrust accuracy
AI tools had already crossed into mainstream use, with 62% reporting adoption. Trust lagged at 43%, while 31% actively distrusted the tools' accuracy. That gap makes review a normal operating control, not resistance to new technology.
El uso de IA superó la confianza en suprecisiónRespuestas de la encuesta de desarrolladores de Stack Overflow, porcentaje en 2024.Made for Stuard Gerardo Carrillo Gonzalez, by HanademiFuentes: Stack Overflow. (2024). 2024 Developer Survey: Artificial intelligence.Unidadencuestados62 %Usan herramientas de IA43 %Confían en la precisión31 %Desconfían de la precisión
Las herramientas de IA ya habían llegado al uso general, con una adopción informada del 62%. La confianza se quedó en el 43%, mientras el 31% desconfiaba activamente de su precisión. Esa brecha convierte la revisión en un control operativo normal, no en resistencia a la tecnología.
Experienced developers took 19% longerwith early-2025 AI tools.The finding applies to experienced contributors working in repositories they knew, usingearly-2025 tools. It should not be generalized to every developer, model, or task.Sources: Becker, J., Rush, N., Barnes, B., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developerproductivity. METR.
This randomized field study followed 16 experienced developers across 246 eligible repository tasks. Access to early-2025 AI tools increased completion time by 19%. The result does not say AI always slows development, but it directly rejects the idea that review and judgment are already unnecessary.
Los desarrolladores experimentadostardaron un 19% más con herramientas deIA de principios de 2025.El hallazgo corresponde a colaboradores experimentados que trabajaban en repositoriosconocidos con herramientas de principios de 2025. No debe generalizarse a todos losdesarrolladores, modelos o tareas.Fuentes: Becker, J., Rush, N., Barnes, B., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity.METR.
Este estudio de campo aleatorizado siguió a 16 desarrolladores experimentados en 246 tareas elegibles de repositorio. El acceso a herramientas de IA de principios de 2025 aumentó el tiempo de finalización un 19%. El resultado no dice que la IA siempre ralentice el desarrollo, pero sí rechaza que la revisión y el juicio ya sean innecesarios.
Extra context helped Opus and hurt SonnetChange from irrelevant context in one experiment, benchmark points by model.Made for Stuard Gerardo Carrillo Gonzalez, by HanademiSources: techloom.it.Unitbenchmark pointsSonnet-8Opus4
Irrelevant context did not produce a universal penalty. Sonnet lost 8 benchmark points, while Opus gained 4 in the same experiment. Constraints therefore need model-level evaluation instead of a single token rule copied across every workflow.
El contexto extra ayudó a Opus y perjudicó aSonnetCambio causado por contexto irrelevante en un experimento, puntos de benchmark por modelo.Made for Stuard Gerardo Carrillo Gonzalez, by HanademiFuentes: techloom.it.Unidadpuntos de benchmarkSonnet-8Opus4
El contexto irrelevante no produjo una penalización universal. Sonnet perdió 8 puntos de benchmark, mientras Opus ganó 4 en el mismo experimento. Por eso los límites deben evaluarse por modelo, en lugar de copiar una sola regla de tokens en todos los flujos.
An early Codex benchmark estimated 72%success with 100 samplesHumanEval pass@k for the 12-billion-parameter Codex model, percent in a 2021 evaluation.Made for Stuard Gerardo Carrillo Gonzalez, by HanademiSources: Chen, M., Tworek, J., Jun, H., et al. (2021). Evaluating large language models trained on code. OpenAI.UnitHumanEval pass ratepass@128.8%pass@1046.8%pass@10072.3%
The first generated answer passed 28.81% of HumanEval tasks. The probability rose to 46.81% with 10 samples and 72.31% with 100. Compute can buy more chances, but pass@k does not identify which candidate is correct before evaluation.
Un benchmark inicial de Codex estimó un72% de éxito con 100 muestrasHumanEval pass@k para el modelo Codex de 12.000 millones de parámetros, porcentaje en una evaluaciónde 2021.Made for Stuard Gerardo Carrillo Gonzalez, by HanademiFuentes: Chen, M., Tworek, J., Jun, H., et al. (2021). Evaluating large language models trained on code. OpenAI.Unidadtasa de aprobación de HumanEvalpass@128,8 %pass@1046,8 %pass@10072,3 %
La primera respuesta generada superó el 28,81% de las tareas de HumanEval. La probabilidad subió al 46,81% con 10 muestras y al 72,31% con 100. El cómputo puede comprar más oportunidades, pero pass@k no identifica qué candidato es correcto antes de evaluarlo.
A replay study estimated types caught onlyabout 1 in 5 bugsEstimated share of 400 replayed JavaScript bugs detectable by TypeScript or Flow.Made for Stuard Gerardo Carrillo Gonzalez, by HanademiSources: Gao, Z., Bird, C., & Barr, E. T. (2017). To type or not to type: Quantifying detectable bugs in JavaScript. ICSE, 758-769.; Berger, E.D., Hollenbeck, C., Maj, P., Vitek, O., & Vitek, J. (2019). On the impact of programming languages on code quality. ACM TOPLAS, 41(4).Sources use different measurement bases; read the comparison directionally, not as one exact scale.Unitbugs detectedTypeScript15%Flow15%Either system20%
In a replay of 400 JavaScript bugs, TypeScript or Flow individually could detect about 15%, and either system could detect roughly 20%. A separate reanalysis covering 729 GitHub projects found that language-quality effects were small and sensitive to modeling choices. Types are valuable filters, not complete quality certificates.
Un estudio estimó que los tipos detectabansolo cerca de 1 de cada 5 erroresPorcentaje estimado de 400 errores de JavaScript reproducidos que TypeScript o Flow podían detectar.Made for Stuard Gerardo Carrillo Gonzalez, by HanademiFuentes: Gao, Z., Bird, C., & Barr, E. T. (2017). To type or not to type: Quantifying detectable bugs in JavaScript. ICSE, 758-769.; Berger, E. D.,Hollenbeck, C., Maj, P., Vitek, O., & Vitek, J. (2019). On the impact of programming languages on code quality. ACM TOPLAS, 41(4).Las fuentes usan bases de medición distintas; lea la comparación como tendencia, no como una escala exacta.Unidaderrores detectadosTypeScript15 %Flow15 %Cualquiera de los 220 %
En una reproducción de 400 errores de JavaScript, TypeScript o Flow podían detectar individualmente cerca del 15%, y cualquiera de los 2 alrededor del 20%. Otro análisis de 729 proyectos de GitHub encontró efectos pequeños y sensibles a las decisiones del modelo estadístico. Los tipos son filtros valiosos, no certificados completos de calidad.
About 40% of the 1,689 generated programswere classified as vulnerable, so securitychecks should precede production access.The 2022 study generated 1,689 programs across 89 security scenarios and classifiedabout 40% as vulnerable. The evidence concerns an older Copilot version and could not beverified against a live source during the build. It supports the need for security controls,not a current universal vulnerability rate.Sources: Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., & Karri, R. (2022). Asleep at the keyboard? Assessing the security of GitHub Copilot's codecontributions. IEEE Symposium on Security and Privacy, 754-768.
The study generated 1,689 programs across 89 security scenarios and classified about 40% as vulnerable. That is not a present-day rate for every coding model, but it shows why functional output alone cannot clear a security gate. Static analysis, dependency checks, and restricted permissions still have work to do.
El estudio generó 1.689 programas en 89escenarios de seguridad y clasificó cercadel 40% como vulnerables.El estudio de 2022 generó 1.689 programas en 89 escenarios de seguridad y clasificócerca del 40% como vulnerables. La evidencia corresponde a una versión antigua deCopilot y no pudo verificarse contra una fuente en vivo durante la construcción. Respaldala necesidad de controles, no una tasa universal reciente de vulnerabilidad.Fuentes: Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., & Karri, R. (2022). Asleep at the keyboard? Assessing the security of GitHub Copilot's codecontributions. IEEE Symposium on Security and Privacy, 754-768.
El estudio generó 1.689 programas en 89 escenarios de seguridad y clasificó cerca del 40% como vulnerables. No es una tasa reciente para todos los modelos, pero muestra por qué un resultado funcional no basta para superar un control de seguridad. El análisis estático, la revisión de dependencias y los permisos restringidos todavía son necesarios.
seL4 needed far more proof thanimplementationOriginal seL4 verification effort, approximate lines of C implementation and Isabelle proof.Made for Stuard Gerardo Carrillo Gonzalez, by HanademiSources: Klein, G., Elphinstone, K., Heiser, G., et al. (2009). seL4: Formal verification of an OS kernel. SOSP, 207-220.UnitlinesC implementation8.7KIsabelle proof200K23x
The original seL4 effort connected about 8,700 lines of C implementation to roughly 200,000 lines of Isabelle proof. That investment delivered unusually strong assurance for a narrowly specified kernel. It also explains why formal verification belongs first where failure is expensive, not as a universal rule for every change.
seL4 necesitó muchas más líneas deprueba que de implementaciónEsfuerzo de verificación original de seL4, líneas aproximadas de implementación en C y prueba enIsabelle.Made for Stuard Gerardo Carrillo Gonzalez, by HanademiFuentes: Klein, G., Elphinstone, K., Heiser, G., et al. (2009). seL4: Formal verification of an OS kernel. SOSP, 207-220.UnidadlíneasImplementación en C8,7KPrueba en Isabelle200K23x
El esfuerzo original de seL4 conectó unas 8.700 líneas de implementación en C con aproximadamente 200.000 líneas de prueba en Isabelle. Esa inversión produjo una garantía excepcional para un núcleo bien delimitado. También explica por qué la verificación formal debe empezar donde un fallo es costoso, no como regla universal para cada cambio.
Random testing found only 6 CompCert bugsCompiler bugs found by random testing in GCC, LLVM, and CompCert.Made for Stuard Gerardo Carrillo Gonzalez, by HanademiSources: Yang, X., Chen, Y., Eide, E., & Regehr, J. (2011). Finding and understanding bugs in C compilers. PLDI, 283-294.; Knight, J. C., & Leveson, N. G. (1986).An experimental evaluation of the assumption of independence in multiversion programming. IEEE Transactions on Software Engineering, SE-12(1), 96-109.Sources use different measurement bases; read the comparison directionally, not as one exact scale.Unitbugs found325GCC79LLVM6CompCert
Random testing found 325 GCC bugs, 79 LLVM bugs, and 6 CompCert bugs. No wrong-code error was attributed to CompCert's verified core. By contrast, an experiment with 27 independently developed versions found correlated failures, showing that more implementations do not automatically create independent protection.
Las pruebas aleatorias encontraron solo 6errores en CompCertErrores de compiladores encontrados mediante pruebas aleatorias en GCC, LLVM y CompCert.Made for Stuard Gerardo Carrillo Gonzalez, by HanademiFuentes: Yang, X., Chen, Y., Eide, E., & Regehr, J. (2011). Finding and understanding bugs in C compilers. PLDI, 283-294.; Knight, J. C., & Leveson, N. G. (1986). Anexperimental evaluation of the assumption of independence in multiversion programming. IEEE Transactions on Software Engineering, SE-12(1), 96-109.Las fuentes usan bases de medición distintas; lea la comparación como tendencia, no como una escala exacta.Unidaderrores encontrados325GCC79LLVM6CompCert
Las pruebas aleatorias encontraron 325 errores en GCC, 79 en LLVM y 6 en CompCert. Ningún error de código incorrecto se atribuyó al núcleo verificado de CompCert. En cambio, un experimento con 27 versiones desarrolladas independientemente encontró fallos correlacionados, lo que demuestra que más implementaciones no crean protección independiente de forma automática.
Measure AI coding across five dimensions,not one activity metric.SPACE names satisfaction, performance, activity, communication, and efficiency. Theequal values show framework membership, not equal importance or a universal score.Sources: Forsgren, N., Storey, M. A., Maddila, C., Zimmermann, T., Houck, B., & Butler, J. (2021). The SPACE of developer productivity.Communications of the ACM.
The SPACE framework separates satisfaction, performance, activity, communication, and efficiency. That is the practical operating model for AI coding controls. Tighten review, tests, permissions, and formal assurance as potential harm rises, then watch several outcomes so one local gain cannot hide a system-level loss.
Mida la programación con IA encinco dimensiones, no con una solamétrica de actividad.SPACE nombra satisfacción, rendimiento, actividad, comunicación y eficiencia. Losvalores iguales muestran pertenencia al marco, no igual importancia ni una puntuaciónuniversal.Fuentes: Forsgren, N., Storey, M. A., Maddila, C., Zimmermann, T., Houck, B., & Butler, J. (2021). The SPACE of developer productivity. Communicationsof the ACM.
El marco SPACE separa satisfacción, rendimiento, actividad, comunicación y eficiencia. Ese es un modelo operativo práctico para los controles de programación con IA. Refuerce revisión, pruebas, permisos y garantía formal a medida que aumente el daño posible, y observe varios resultados para que una mejora local no oculte una pérdida del sistema.
In summaryMade for Stuard Gerardo Carrillo Gonzalez, by HanademiSources: Klein, G., Elphinstone, K., Heiser, G., et al. (2009). seL4: Formal verification of an OS kernel. SOSP, 207-220.; Yang, X., Chen, Y., Eide, E., & Regehr, J. (2011). Finding and understanding bugs in C compilers.PLDI, 283-294.; Becker, J., Rush, N., Barnes, B., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. METR.; techloom.it.; Knight, J. C., & Leveson, N. G.(1986). An experimental evaluation of the assumption of independence in multiversion programming. IEEE Transactions on Software Engineering, SE-12(1), 96-109.; Ray, B., Posnett, D., Filkov, V., & Devanbu, P…The original seL4 verification connected about 8,700 lines of C implementation to roughly 200,000 lines of Isabelle proof.Random testing found 325 GCC bugs, 79 LLVM bugs, and six CompCert bugs, with no wrong-code errors attributed to CompCert's verified core.In a randomized field study, 16 experienced developers completed 246 eligible repository tasks 19% slower whenallowed to use early-2025 AI tools.In one context-noise experiment, Sonnet lost 8 benchmark points while Opus gained 4, demonstrating model-dependenteffects from irrelevant context.An experiment involving 27 independently developed program versions found correlated failures, challenging theassumption that independent implementations fail independently.A 729-project GitHub study linked language characteristics with defect rates, but reanalysis found small, unstable effectssensitive to modeling and data choices.
The value of the research is not only what each source knew, but what became visible when their evidence was combined.
En resumenMade for Stuard Gerardo Carrillo Gonzalez, by HanademiFuentes: Klein, G., Elphinstone, K., Heiser, G., et al. (2009). seL4: Formal verification of an OS kernel. SOSP, 207-220.; Yang, X., Chen, Y., Eide, E., & Regehr, J. (2011). Finding and understanding bugs in C compilers.PLDI, 283-294.; Becker, J., Rush, N., Barnes, B., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. METR.; techloom.it.; Knight, J. C., & Leveson, N. G.(1986). An experimental evaluation of the assumption of independence in multiversion programming. IEEE Transactions on Software Engineering, SE-12(1), 96-109.; Ray, B., Posnett, D., Filkov, V., & Devanbu, P…La verificación original de seL4 conectó unas 8.700 líneas de implementación en C con aproximadamente 200.000 líneas de prueba en Isabelle.Las pruebas aleatorias encontraron 325 errores en GCC, 79 en LLVM y seis en CompCert, sin errores de códigoincorrecto atribuidos al núcleo verificado de CompCert.En un estudio de campo aleatorizado, 16 desarrolladores experimentados completaron 246 tareas elegibles de repositorioun 19% más lento cuando pudieron usar herramientas de IA de principios de 2025.En un experimento con ruido de contexto, Sonnet perdió 8 puntos de benchmark mientras Opus ganó 4, mostrando efectos que dependen del modelo.Un experimento con 27 versiones desarrolladas independientemente encontró fallos correlacionados, cuestionando queimplementaciones independientes fallen de forma independiente.Un estudio de 729 proyectos de GitHub relacionó características de lenguajes con defectos, pero un nuevo análisisencontró efectos pequeños e inestables sensibles al modelo y los datos.
El valor de la investigación no está solo en cada fuente, sino en lo que apareció al combinar sus evidencias.

The research behind this deck

A local quality gain did not translate into better software delivery. These terms separate code generation from dependable software delivery.

Key findings

The argument

This research is published in English and Spanish. Ver en español

La investigación detrás de esta presentación

Una mejora local de calidad no se convirtió en una mejor entrega de software. Estos términos separan la generación de código de una entrega fiable.

Hallazgos clave

El argumento

Esta investigación se publica en inglés y español. Read in English