Palo Alto Networks: Claude para miles de desarrolladores — velocidad de desarrollo de funciones incrementada 20–30%
Los números principales concuerdan en ambos casos de estudio: la velocidad de desarrollo de funciones e implementación de código aumentó 20–30%. La velocidad de escritura de pruebas unitarias aumentó 10–30% — y eso no es solo productividad: más pruebas significan menos bugs y una base de código de mayor calidad. Los desarrolladores junior completan tareas 70% más rápido, y su integración bajó de meses (hasta seis) a semanas. Escala: un piloto de 150 desarrolladores → 3,000 en despliegue según la versión de Google Cloud; 2,500 integrados y 3,500 en aumento según la versión de Anthropic. Patel resume por qué esto importa para la ciberseguridad: "Ejecutar Claude en Vertex AI de Google Cloud no solo acelera proyectos de desarrollo, nos permite codificar la seguridad en el código antes de que se implemente." Un resultado separado es el criterio de selección de proveedor que Patel expresa claramente: "Anthropic priorizó la seguridad mucho más que otros LLMs. Discuten las implicaciones de seguridad en cada reunión. Como la empresa de ciberseguridad más grande, eso es importante para nosotros." Contexto. Todos los números son el auto-reporte de la empresa publicado por dos proveedores interesados (Anthropic y Google Cloud); la metodología detrás de "velocidad de desarrollo de funciones" no se divulga; el 70% de los junior es una estimación para un tipo específico de tarea de integración; la discrepancia de 2,500/3,000 desarrolladores entre las historias refleja diferentes momentos de tiempo — un recordatorio de que los números en historias de proveedores son en un punto en el tiempo, no auditados. Análisis editorial. Primero: este es un caso raro donde el ROI de un asistente de IA se calcula no "en promedio" sino por segmento — y la mayor victoria es con los junior (70% vs 20–30% promedio). La conclusión práctica invierte la intuición de "la IA amplifica a los fuertes": en grandes organizaciones de ingeniería, la IA principalmente iguala el campo de juego del equipo y convierte la integración de seis meses en semanas, lo que es dinero directo en contratación y escalado. Segundo: la secuencia "mapear el proceso → medir un piloto → escalar" importa más que cualquier número único aquí; el punto de apalancamiento (la fase de desarrollo inicial, 30–35% del tiempo) se eligió según datos, no por moda. Tercero: el pipeline de post-procesamiento — generar y ejecutar pruebas, encontrar vulnerabilidades, y auto-parchar después de cada PR — esboza una reestructuración más profunda que un asistente IDE: la IA se convierte en una etapa de pipeline con su propia área de responsabilidad, y el comentario de Patel de que "probablemente no tendremos todas estas etapas" suena como el anuncio del próximo caso de estudio. Finalmente, observe lo que se mide aquí: PANW es uno de los pocos en publicar no solo "productividad promedio" sino segmentación por antigüedad (junior/senior) y una métrica de pruebas separada. Cuanto más granularmente una empresa divide sus propios números, hay más razón para confiar en ellos — por ese criterio, el caso de PANW es marcadamente más evidencial que el reporte de proveedor promedio.
- Palo Alto Networks accelerates development with Claude (customer story) — Anthropic / Claude (кейс-стади)
- Palo Alto Networks: Accelerating software development and security with Anthropic's Claude and Google Cloud — Google Cloud (customer story)
Contexto
Palo Alto Networks es la empresa de ciberseguridad más grande: un proveedor global de productos y servicios integrales de seguridad de redes. Una organización de ingeniería con miles de desarrolladores se enfrentó a la pregunta que toda la industria se hacía en 2024–2025: ¿cómo aumentar la productividad de los desarrolladores con IA generativa sin comprometer la calidad y seguridad del código implementado? Para una empresa que vende seguridad, la segunda cláusula no es una salvedad sino la esencia de la marca.
El programa fue liderado por Gunjan Patel, Director de Ingeniería en la Oficina del CPO, con un equipo multidisciplinario de ingenieros. La metodología fue sistemática desde el inicio: el equipo no se apresuró a desplegar "alguna IA" sino que primero mapeó el ciclo de vida del desarrollador para identificar qué tareas son más propensas a errores y consumen más tiempo. Las herramientas se eligieron basándose en ese mapa.
Siguió una evaluación formal de varios LLMs y asistentes de codificación. La ganadora fue una combinación: Sourcegraph Cody como interfaz IDE con los modelos Claude de Anthropic como backend, desplegados en Vertex AI en Google Cloud — la combinación que, según la evaluación del equipo, mejor coincidía con el enfoque de la empresa en seguridad. El caso está documentado dos veces — por Anthropic y por Google Cloud — ofreciendo la rara oportunidad de contrastar los números de dos partes interesadas entre sí.
La escala de despliegue en dos momentos: la historia de Google Cloud describe un piloto de 150 desarrolladores y un despliegue posterior a 3,000; la historia de Anthropic cita 2,500 desarrolladores integrados con 3,500 más en aumento. Es uno de los despliegues documentados públicamente más grandes de asistentes de desarrollo IA en el sector de ciberseguridad.
Problema
En ciberseguridad el costo de un bug es más alto que en cualquier lugar: "Si se descubre un bug después, eso es lo que cuesta dinero y reputación y los clientes no están felices," dice Patel. Una vulnerabilidad en un producto que en sí mismo protege la infraestructura de los clientes afecta la confianza más que cualquier falla en software ordinario. Entonces la aceleración del desarrollo no podía ir en detrimento de la calidad: al contrario, la IA tenía que reforzar el control de calidad.
Mapear el ciclo de vida del desarrollador mostró exactamente dónde se estaba perdiendo tiempo y calidad. 30–35% del tiempo del desarrollador se dedicaba a la fase de desarrollo inicial — identificada como el punto crítico de prevención de errores. La integración fue otro cuello de botella: un nuevo empleado necesitaba hasta seis meses para volverse completamente competente en las bases de código extensas y complejas de la empresa — y todo ese tiempo los desarrolladores senior pasaban horas guiando manualmente a los recién llegados a través de la estructura del código.
Las especificidades de la industria establecieron una capa separada de requisitos. El código fuente de Palo Alto Networks es un activo sensible: la solución tenía que mantener el código dentro de los límites de datos de la empresa en lugar de enviarlo a servicios externos no controlados. Más las demandas de infraestructura de escala: miles de desarrolladores necesitan un throughput de inferencia estable sin degradación en horas pico, y un modelo de costo predecible que pueda planificarse en un horizonte anual. Finalmente, un filtro de proveedor: una empresa que vende seguridad no podía trabajar con un proveedor de modelo para quien la seguridad es una preocupación secundaria.
Solución
La arquitectura de la solución es un emparejamiento de modelos dividido por latencia y profundidad. Claude 3.5 Haiku maneja la finalización de código en tiempo real: el modelo rápido y económico sugiere las siguientes líneas mientras los desarrolladores escriben. Claude 3.5 Sonnet funciona en modo programación en pareja a través del chat del IDE: un desarrollador pregunta "ayúdame a mejorar el rendimiento de este código" — el sistema recopila archivos relevantes, los envía a Sonnet, y devuelve un fragmento listo. La interfaz es el plugin Sourcegraph Cody en el IDE; el backend es Claude en Vertex AI. "La combinación de Claude en Vertex AI con Sourcegraph nos permitió mantener nuestro código fuente dentro de nuestros límites de datos y funcionó bien en tareas de codificación," explica Patel.
Los escenarios de uso divergieron según el nivel de experiencia. Los junior dependen de la capacidad de Claude de explicar código: el modelo entiende la base de código general, y los nuevos empleados comienzan a contribuir dentro de semanas en lugar de meses sin consumir el tiempo de los desarrolladores senior. Los ingenieros experimentados usan Claude como un socio en depuración complicada y sesiones de lluvia de ideas de arquitectura — el caso cita el fraseo en vivo: "Oye, verifica mi lógica en esto" e "Estoy atrapado en este bug; ¿puedes ayudarme a hacer una lluvia de ideas?"
El despliegue siguió el canon: un piloto con 150 desarrolladores de junior a senior, medición del impacto, luego escalado a miles de ingenieros. En cuanto a infraestructura, el escalado se apoyó en dos capacidades de Google Cloud: precios granulares basados en el uso de GSU (Generative AI Scale Units) con períodos de compromiso flexibles — seis meses o un año — y throughput provisionado para rendimiento consistente. Patel describe el cambio de on-demand a throughput provisionado con un entusiasmo raro en casos empresariales: "No pensábamos que cambiar de on-demand a throughput provisionado funcionaría fácilmente. Pero realmente funcionó — sin errores. Todo lo que tuvimos que hacer fue cambiar el endpoint, y todo funcionó sin problemas. Eso fue una gran victoria para nosotros."
La siguiente frontera es el post-procesamiento de código con IA en CI/CD: un desarrollador escribe código con Claude en tiempo real, y después de que se crea la solicitud de extracción, la IA toma el control sin conexión — mejorando nombres de variables, agregando comentarios aclaratorios, generando y ejecutando automáticamente pruebas unitarias, luego identificando problemas de seguridad en el código y sugiriendo automáticamente parches. "Estos esfuerzos contribuirán a código más limpio y legible mientras se abordan simultáneamente vulnerabilidades y se fortalece la seguridad," dice Patel. Su equipo está mientras tanto mapeando los procesos de cada equipo de desarrollo en busca de los próximos puntos de apalancamiento de IA — y cuestionando la estructura del proceso en sí: "El ciclo de vida del desarrollo de software fue diseñado antes de la era de la IA... probablemente no tendremos todas estas etapas."
Resultado
Los números principales concuerdan en ambos casos de estudio: la velocidad de desarrollo de funciones e implementación de código aumentó 20–30%. La velocidad de escritura de pruebas unitarias aumentó 10–30% — y eso no es solo productividad: más pruebas significan menos bugs y una base de código de mayor calidad. Los desarrolladores junior completan tareas 70% más rápido, y su integración bajó de meses (hasta seis) a semanas. Escala: un piloto de 150 desarrolladores → 3,000 en despliegue según la versión de Google Cloud; 2,500 integrados y 3,500 en aumento según la versión de Anthropic. Patel resume por qué esto importa para la ciberseguridad: "Ejecutar Claude en Vertex AI de Google Cloud no solo acelera proyectos de desarrollo, nos permite codificar la seguridad en el código antes de que se implemente."
Un resultado separado es el criterio de selección de proveedor que Patel expresa claramente: "Anthropic priorizó la seguridad mucho más que otros LLMs. Discuten las implicaciones de seguridad en cada reunión. Como la empresa de ciberseguridad más grande, eso es importante para nosotros."
Contexto. Todos los números son el auto-reporte de la empresa publicado por dos proveedores interesados (Anthropic y Google Cloud); la metodología detrás de "velocidad de desarrollo de funciones" no se divulga; el 70% de los junior es una estimación para un tipo específico de tarea de integración; la discrepancia de 2,500/3,000 desarrolladores entre las historias refleja diferentes momentos de tiempo — un recordatorio de que los números en historias de proveedores son en un punto en el tiempo, no auditados.
Análisis editorial. Primero: este es un caso raro donde el ROI de un asistente de IA se calcula no "en promedio" sino por segmento — y la mayor victoria es con los junior (70% vs 20–30% promedio). La conclusión práctica invierte la intuición de "la IA amplifica a los fuertes": en grandes organizaciones de ingeniería, la IA principalmente iguala el campo de juego del equipo y convierte la integración de seis meses en semanas, lo que es dinero directo en contratación y escalado. Segundo: la secuencia "mapear el proceso → medir un piloto → escalar" importa más que cualquier número único aquí; el punto de apalancamiento (la fase de desarrollo inicial, 30–35% del tiempo) se eligió según datos, no por moda. Tercero: el pipeline de post-procesamiento — generar y ejecutar pruebas, encontrar vulnerabilidades, y auto-parchar después de cada PR — esboza una reestructuración más profunda que un asistente IDE: la IA se convierte en una etapa de pipeline con su propia área de responsabilidad, y el comentario de Patel de que "probablemente no tendremos todas estas etapas" suena como el anuncio del próximo caso de estudio. Finalmente, observe lo que se mide aquí: PANW es uno de los pocos en publicar no solo "productividad promedio" sino segmentación por antigüedad (junior/senior) y una métrica de pruebas separada. Cuanto más granularmente una empresa divide sus propios números, hay más razón para confiar en ellos — por ese criterio, el caso de PANW es marcadamente más evidencial que el reporte de proveedor promedio.
Lecciones aprendidas
- Un modelo rápido y económico para finalización + un modelo fuerte para chat IDE es el par de trabajo para adopción masiva de IA en ingeniería: latencia donde importa la velocidad, inteligencia donde importa la profundidad.
- Comienza con un mapa de procesos, no con una herramienta: Palo Alto primero encontró dónde se pierde tiempo y calidad (30–35% — la fase inicial) y solo entonces eligió el LLM.
- Los junior ganan más (70% de tareas más rápidas): la IA iguala el equipo y reduce la integración de meses a semanas — valora ese efecto en dólares de contratación.
- IA en CI/CD (pruebas, comentarios, detección de vulnerabilidades, auto-parches) se paga más rápido que escenarios llamativos: un bug atrapado antes del lanzamiento es ahorro directo en dinero y reputación.
- Para industrias reguladas y sensibles a la seguridad, la postura de seguridad del proveedor es un criterio de selección igual que la calidad del modelo.
- Mantén el código dentro de tus límites de datos: un plugin IDE + un modelo dentro de tu perímetro de nube (Vertex AI) elimina el principal bloqueador legal para la adopción.
- Infraestructura de acceso flexible (precios GSU, throughput provisionado, intercambio de endpoint sin reescrituras de código) elimina la principal barrera técnica para escalar entre miles de ingenieros.
Preguntas frecuentes
¿Cómo usa Palo Alto Networks Claude en el desarrollo?
Claude 3.5 Haiku maneja la finalización de código en tiempo real; Claude 3.5 Sonnet alimenta la programación en pareja a través del chat del IDE (explicación de arquitectura, generación y optimización de código). La interfaz es el plugin Sourcegraph Cody, el backend es Claude en Vertex AI. Más post-procesamiento de IA después de solicitudes de extracción: pruebas unitarias, comentarios, nombres de variables, detección de vulnerabilidades, y auto-parches.
¿Qué resultados entregó el despliegue?
20–30% más de velocidad de desarrollo de funciones, 10–30% más rápido en generación de pruebas unitarias, 70% más rápido en finalización de tareas para junior, integración reducida de meses (hasta seis) a semanas. Escala: un piloto de 150 desarrolladores, luego miles de ingenieros (3,000 según la historia de Google Cloud; 2,500 + 3,500 en aumento según Anthropic).
¿Por qué una empresa de ciberseguridad eligió Anthropic?
Después de una evaluación formal de varios LLMs y asistentes: la combinación Sourcegraph Cody + Claude en Vertex AI mejor coincidía con el enfoque de seguridad y mantuvo el código fuente dentro de los límites de datos de la empresa. Según Patel, Anthropic prioriza la seguridad más que otros proveedores de LLM y discute las implicaciones en cada reunión.
¿Cómo se protege el código fuente cuando se trabaja con el LLM?
Claude se despliega en Vertex AI dentro del perímetro de nube de la empresa: según Patel, esto les permitió "mantener nuestro código fuente dentro de nuestros límites de datos." Vertex AI proporciona control granular sobre código sensible y cumplimiento con protocolos de seguridad, mientras que el throughput provisionado agrega capacidad dedicada sin dejar el perímetro.
¿Qué son GSU y throughput provisionado, y por qué importan aquí?
GSU (Generative AI Scale Units) es la fijación de precios basada en el uso de Google Cloud con compromisos de 6 o 12 meses, haciendo que los costos de inferencia sean planificables. El throughput provisionado es capacidad dedicada para rendimiento consistente entre miles de desarrolladores; cambiar de on-demand, según Patel, significó cambiar el endpoint y "simplemente funcionó."