---
title: "Google dice que Go es ideal para programar con agentes. ¿Y PHP?"
excerpt: "Google publicó los cinco criterios que hacen a un lenguaje bueno para revisar código generado por IA. Mido PHP y Laravel con esa misma vara: empatan en dos y pierden en tres, pero solo uno de los tres no tiene arreglo."
date: "2026-08-12T18:30:00.000Z"
category: "Laravel"
tech_article: true
author:
  name: "angel cruz"
  picture: "/images/me/angel-cruz.png"
ogImage:
  url: "/images/open-graph/laravel-opengraph-image.png"
seo_title: "¿Es PHP un buen lenguaje para programar con agentes de IA?"
seo_description: "Los cinco criterios de Google para un lenguaje apto para código generado por IA, aplicados a PHP y Laravel: Pint, PHPStan, composer audit y compatibilidad. Qué empata, qué pierde y qué tiene arreglo."
---

**Con los criterios de Google en la mano, PHP no gana ninguno: empata dos y pierde tres.** Y aun así la conclusión no es "múdate a Go", porque de los tres que pierde, dos se arreglan con herramientas que instalas en una tarde. El único que no tiene arreglo es la compatibilidad hacia atrás.

El 11 de agosto de 2026, Google publicó [por qué Go es un lenguaje ideal para la ingeniería asistida por IA](https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/), firmado por el product manager de Go y el Chief Evangelist de Google Cloud. Su tesis de partida es buena y no depende de Go: **el trabajo pasó de escribir código a revisar código generado**, y eso cambia qué le pides a un lenguaje.

Antes de seguir, dos avisos. El primero es que el artículo **no trae un solo dato**: ni benchmarks, ni métricas internas, ni comparativas. Es una pieza de posicionamiento, y hay que leerla como tal. El segundo es que no voy a discutir si Go es bueno, porque lo es. La pregunta que me interesa es la que no responde nadie: **con esa misma vara, ¿qué tan mal parado sale PHP?**

## Los cinco criterios

Resumidos de su artículo:

1. **Plataforma integrada.** Herramientas de fábrica (formateo, tests, dependencias, seguridad) en vez de un ecosistema que montas tú.
2. **Legibilidad sobre facilidad de escritura.** Que todo el código se vea igual, lo escriba un senior, un junior o un modelo.
3. **Tipos estáticos como red de seguridad.** Que el compilador rechace lo estructuralmente mal antes de que llegue a un humano.
4. **Cadena de suministro.** Biblioteca estándar amplia y herramientas que detecten dependencias vulnerables.
5. **Mantenibilidad.** Que el código de hace años siga compilando hoy.

Vamos uno por uno.

## 1. Plataforma integrada: empate, pero cada uno gana en una capa distinta

Si comparas PHP a secas contra Go, PHP pierde: no trae formateador ni framework de tests en el core.

Pero nadie escribe PHP a secas en 2026, y contra Laravel la cosa se equilibra. Laravel trae **Pint** para formatear y **Pest** o PHPUnit para tests en el esqueleto de cada aplicación nueva, más **Artisan** y **Composer**. Go lo tiene todo dentro del propio comando `go` (`go fmt`, `go test`, `go vet`, `govulncheck`), que es una integración más profunda, pero el resultado práctico para quien escribe es parecido.

Donde sí hay una diferencia interesante es en lo que cada uno le ofrece al agente, y aquí conviene deshacer un malentendido que yo mismo tenía: **Go tiene su propio servidor MCP oficial.** Está dentro de `gopls`, el servidor de lenguaje del proyecto Go, se declara experimental y se conecta igual de fácil:

```bash
claude mcp add gopls -- gopls mcp
```

Expone, en palabras de su documentación, "un subconjunto de la funcionalidad de gopls" a los asistentes de IA: diagnósticos, referencias, símbolos, análisis de vulnerabilidades.

Enfrente está **[Laravel Boost](/post/mcp-para-laravel)**, que también es opcional (`composer require laravel/boost --dev`, no viene puesto) y expone más de 15 herramientas. La diferencia no es la cantidad sino **la capa a la que llega cada uno**:

| | `gopls` MCP | Laravel Boost |
|---|---|---|
| Qué conoce | El código: tipos, símbolos, referencias, diagnósticos | La aplicación: esquema de base de datos, rutas con su middleware, logs |
| Qué puede hacer | Analizar y navegar | Además, **ejecutar código** vía Tinker |
| Documentación | La del lenguaje | 17.000 fragmentos **filtrados por tu versión exacta** |

Go llega más hondo en el código; Laravel llega más hondo en **tu** aplicación. Para un agente que va a tocar una feature concreta, saber el esquema real de tu base de datos es un contexto distinto y difícil de sustituir. Para uno que refactoriza, el análisis de tipos de gopls no tiene equivalente en PHP.

Y hay una relación entre ambas cosas que se ve mejor en el criterio 3: gopls puede ofrecer esos diagnósticos precisamente porque el sistema de tipos de Go se los da hechos.

**Veredicto: empate.** Los dos ecosistemas tienen tooling de primera parte pensado para agentes, y ninguno viene activado por defecto.

## 2. Legibilidad: Pint se parece a gofmt, pero no garantiza lo mismo

`gofmt` es el argumento fuerte de Go. Un solo formato, no negociable, idéntico en todos los proyectos del mundo.

Pint está más cerca de lo que parece. Según la documentación oficial, **"Pint se instala automáticamente con todas las aplicaciones Laravel nuevas"** y **"no requiere ninguna configuración"**: usa el preset `laravel` por defecto y arregla el estilo sin que toques nada.

Pero hay una diferencia real que no conviene maquillar. Pint soporta cinco presets (`laravel`, `per`, `psr12`, `symfony` y `empty`) y permite activar o desactivar reglas sueltas en un `pint.json`. **Dos proyectos Laravel pueden verse distintos, y siguen siendo correctos.** En Go eso no pasa.

Para revisar código generado por IA, la garantía de gofmt es más fuerte, porque el formato deja de ser una variable. En Laravel el formato es una convención excelente con una puerta de escape.

**Veredicto: gana Go.** Pint cubre casi todo el beneficio mientras no toques la configuración, pero "mientras no la toques" es justamente la garantía que a Go no le hace falta pedir.

## 3. Tipos estáticos: aquí está el hueco de verdad

Este es el criterio donde PHP pierde, y no tiene sentido adornarlo.

En Go, el compilador rechaza el código estructuralmente incorrecto. No es opcional, no se configura y no se puede saltar. Un agente recibe ese rechazo, itera y corrige antes de que un humano vea nada.

PHP tiene tipado gradual: puedes tipar propiedades, parámetros y retornos, y el motor los verifica en tiempo de ejecución. Pero **en tiempo de ejecución** es tarde para lo que estamos hablando.

La herramienta que cierra ese hueco es **PHPStan**, y funciona muy bien: tiene once niveles, del 0 al 10, donde el 0 son comprobaciones básicas (clases y funciones desconocidas), el 6 empieza a reportar typehints ausentes, el 8 detecta llamadas a métodos sobre tipos que pueden ser `null`, y el 10, el más estricto, se pone severo incluso con el `mixed` implícito.

El problema no es la capacidad, es la fricción. **PHPStan es una herramienta externa que tú instalas, configuras y eliges a qué nivel poner.** Un proyecto Laravel recién creado no la trae. Si un agente genera código PHP en un proyecto sin PHPStan configurado, no recibe ninguna señal automática de que algo está mal hasta que alguien ejecuta el código.

En Go esa red viene puesta. En PHP la pones tú, o no hay red.

**Veredicto: pierde PHP.** Se puede compensar, pero por defecto no está.

## 4. Cadena de suministro: PHP tiene una historia reciente muy concreta

Aquí PHP responde mejor de lo que su reputación sugiere.

`composer audit` audita los paquetes instalados contra los avisos de seguridad de Packagist, detecta paquetes abandonados y, según la documentación oficial, también **paquetes marcados como malware**. Acepta `--format`, decide qué hacer con los abandonados vía `--abandoned` (ignorar, reportar o fallar) y puede auditar directamente el lock con `--locked`.

Y el `composer.lock` da lo que Google le atribuye al ecosistema de Go: instalaciones reproducibles. La documentación es explícita en que, existiendo el lock, se usan las versiones exactas de ahí, **"lo que garantiza que todo el que use la librería obtenga las mismas versiones"**.

Esto no es teoría: lo escribí cuando Composer 2.10 [añadió el bloqueo de malware y las políticas de dependencias](/post/composer-2-10-bloqueo-malware-politicas-dependencias). Fue una respuesta a incidentes reales del ecosistema, no una función de catálogo.

Donde Go sí gana es en biblioteca estándar. La suya es notablemente más amplia, y eso reduce la superficie de dependencias de terceros desde el principio. En PHP, la cultura es traer un paquete.

**Veredicto: empate.** Mejores herramientas de auditoría de lo que se suele reconocer, peor punto de partida por la dependencia cultural de Composer.

## 5. Compatibilidad: PHP pierde, y no está cerca

Primero, qué es eso de "Go 1", porque si no vienes de Go la expresión despista. **El 1 es la versión mayor del lenguaje, y nunca ha subido.**

`Go 1.0` salió el 28 de marzo de 2012. Desde entonces, todo lo que ha publicado el proyecto son versiones menores de esa misma especificación: `1.1`, `1.2`, y así hasta la `1.26` de este año. **Nunca ha existido un `Go 2.0`.** Por eso a la especificación se la llama "Go 1" a secas, sin decimal: no nombra una versión concreta, sino toda la serie que arranca en `1.0` y sigue viva hoy.

Eso convierte la promesa en algo bastante más grande de lo que suena. No es "intentamos no romper cosas entre versiones": es que llevan catorce años y veintiséis versiones menores sin cambiar la especificación bajo la que compila tu código. Está escrita así:

> Se pretende que los programas escritos para la especificación Go 1 sigan compilando y ejecutándose correctamente, sin cambios, durante toda la vida de esa especificación.

Con excepciones acotadas y publicadas (seguridad, comportamiento no especificado, errores del compilador, `unsafe`), pero la dirección es inequívoca.

PHP no tiene nada parecido, y los números lo dicen. Cada rama recibe **dos años de soporte activo y dos más solo de seguridad**: cuatro en total. PHP 8.5, la estable actual, salió en noviembre de 2025 y su soporte de seguridad termina a finales de 2029. Y la propia lista oficial de cambios incompatibles de PHP 8.5 recoge **más de cuarenta**, desde constantes de PDO que cambian de valor hasta validaciones más estrictas que ahora lanzan `ValueError` donde antes pasaban.

Súmale que Laravel publica una versión mayor **cada año**.

Traducido a lo que nos ocupa: el código PHP de 2012 casi seguro no corre hoy sin tocarlo. El código Go de 2012 sí, y esa es exactamente la fecha en que arranca la promesa. Para un agente que aprendió de todo el corpus público eso importa el doble, porque buena parte de lo que leyó sobre PHP ya no es válido, mientras que casi todo lo que leyó sobre Go sigue siéndolo.

**Veredicto: pierde PHP, con claridad.**

## El marcador, y lo que de verdad se está midiendo

| Criterio | Quién gana | Por qué |
|---|---|---|
| Plataforma integrada | **Empate** | Los dos tienen servidor MCP oficial y ninguno viene activado. `gopls` conoce mejor el código; Boost conoce mejor tu aplicación |
| Legibilidad | **Go** | `gofmt` es único y obligatorio. Pint admite cinco presets, así que dos proyectos Laravel pueden verse distintos |
| Tipos estáticos | **Go** | El compilador rechaza el código malo sin que configures nada. En PHP hay que instalar PHPStan y elegir nivel |
| Cadena de suministro | **Empate** | `composer audit` detecta malware y el lock es reproducible. Go compensa con una biblioteca estándar mucho más amplia |
| Compatibilidad | **Go** | Catorce años con la misma especificación. PHP da cuatro años por rama y Laravel saca una mayor al año |

Leído rápido esto parece una derrota: PHP no gana ni uno. Pero fíjate en **la columna de la derecha**, porque ahí está la diferencia que importa.

Los tres que pierde PHP no pierden igual. En legibilidad y tipos, PHP **puede** alcanzar a Go: Pint sin tocar la configuración se comporta casi como `gofmt`, y PHPStan en nivel alto da una red comparable. Lo que le falta no es capacidad, es que **venga puesto de fábrica**. En compatibilidad no hay nada que instalar: si el lenguaje rompe cosas cada cuatro años, rompe cosas cada cuatro años.

Y esa observación es la que lleva a lo que el artículo de Google no dice, que es la parte útil.

## Lo que en realidad miden esos cinco criterios

Míralos otra vez juntos: formato, tipos, dependencias auditadas, tests, compatibilidad. Parecen cinco temas distintos, pero **todos responden a la misma pregunta: cuánto tarda el proyecto en decirle al agente que se equivocó, y si hace falta un humano para decírselo.**

- El formato le dice "esto no se escribe así" al guardar.
- Los tipos le dicen "esto no compila" antes de ejecutar nada.
- Los tests le dicen "esto rompió algo" en segundos.
- La auditoría le dice "esta dependencia es peligrosa" al instalarla.
- La compatibilidad determina si lo que aprendió de internet sigue siendo cierto.

Son cinco formas de cerrar **un bucle de retroalimentación** sin que intervengas tú. Y cuanto más corto es ese bucle, menos código malo llega a la revisión humana, que es el cuello de botella real desde que los agentes escriben la primera versión.

Visto así, la pregunta deja de ser "qué lenguaje uso" y pasa a ser **"qué tan apretado tengo el bucle"**. Go te lo da apretado de serie. En PHP lo aprietas tú, y se puede llegar bastante lejos:

- **Pint** en modo `--test` para que falle en vez de arreglar en silencio.
- **PHPStan** en un nivel que duela, con el nivel elegido a conciencia y no por defecto.
- **Pest** cubriendo el camino crítico, no el 100% de líneas.
- **`composer audit`** en CI, con `--abandoned=fail` si te lo puedes permitir.
- **Laravel Boost** instalado, para que el agente lea tu esquema real en vez de adivinarlo.

Y lo más importante: que todo eso **se ejecute solo**, sin que tú te acuerdes. Eso es exactamente para lo que sirven [los hooks de Claude Code](/post/hooks-claude-code), donde puedes correr Pint tras cada edición y los tests antes de terminar. Ahí es donde un proyecto PHP alcanza la garantía que Go te da de fábrica.

## Entonces, ¿hay que irse a Go?

No, y la pregunta está mal planteada.

Si empiezas un proyecto nuevo, sin código heredado y sin equipo con preferencia, los argumentos de Google son válidos y Go es una elección excelente. No tengo interés en discutirlo.

Pero si ya tienes una aplicación Laravel en producción, migrarla a Go para que la IA la revise mejor es cambiar un problema resuelto por uno abierto. **El retorno está en apretar el bucle que ya tienes**, y las cinco piezas de arriba se instalan en una tarde.

Lo que sí me llevo del artículo de Google es el marco. Antes de esto, la conversación sobre lenguajes y agentes era casi toda estética. Poner sobre la mesa que lo que importa es la velocidad del ciclo de verificación es un avance, aunque venga sin un solo número que lo respalde y aunque lo firme el equipo que vende el lenguaje.

Si quieres el recorrido completo de cómo trabajo yo con agentes en proyectos Laravel, está el hub de [IA para desarrolladores Laravel](/post/ia-para-desarrolladores-laravel), y el caso concreto en [Claude Code en un proyecto Laravel real](/post/claude-code-proyecto-laravel).

## Preguntas frecuentes

### ¿Es PHP un mal lenguaje para trabajar con agentes de IA?

No, pero tampoco gana ninguno de los cinco criterios de Google. Empata en plataforma integrada y en cadena de suministro, y pierde en legibilidad, tipos estáticos y compatibilidad. La diferencia está en que las dos primeras derrotas se corrigen instalando herramientas (Pint sin configurar y PHPStan en nivel alto) y la de compatibilidad no tiene arreglo posible.

### ¿Qué le falta a PHP frente a Go para código generado por IA?

Sobre todo la verificación de tipos en tiempo de compilación. Go rechaza el código estructuralmente incorrecto antes de que nadie lo lea; PHP verifica los tipos en tiempo de ejecución y necesita PHPStan, que es una herramienta externa que instalas y configuras tú, para acercarse a esa garantía.

### ¿Pint es equivalente a gofmt?

Casi. Pint viene instalado en toda aplicación Laravel nueva y funciona sin configuración con el preset `laravel`. La diferencia es que admite cinco presets y reglas personalizables, así que dos proyectos Laravel pueden verse distintos. gofmt no ofrece esa opción, y para revisar código esa rigidez es una ventaja.

### ¿Merece la pena migrar de Laravel a Go por la IA?

En un proyecto en producción, casi nunca. El retorno está en cerrar el bucle de verificación que ya tienes: Pint en modo test, PHPStan en un nivel exigente, Pest, `composer audit` en CI y Laravel Boost para que el agente lea tu aplicación real. Eso se monta en una tarde.

### ¿Qué nivel de PHPStan conviene usar?

PHPStan tiene once niveles, del 0 al 10. Lo razonable es no empezar por el más alto en un proyecto existente: se elige un nivel que el proyecto pase hoy y se sube uno cada vez. El 6 ya obliga a declarar typehints y el 8 detecta accesos sobre valores que pueden ser `null`, que son los dos saltos con más retorno.

## Fuentes

- [Why Go is an ideal language for AI-assisted software engineering](https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/), el artículo de Google que da el marco.
- [Go 1 and the Future of Go Programs](https://go.dev/doc/go1compat), de donde sale la promesa de compatibilidad citada, y el [historial de versiones](https://go.dev/doc/devel/release), que confirma que la especificación sigue siendo la misma desde 2012.
- [Laravel Pint](https://laravel.com/docs/13.x/pint), instalación por defecto y presets.
- [Servidor MCP de gopls](https://go.dev/gopls/features/mcp), el tooling oficial de Go para agentes.
- [Niveles de reglas de PHPStan](https://phpstan.org/user-guide/rule-levels).
- [Composer CLI](https://getcomposer.org/doc/03-cli.md), sobre `composer audit` y el lock.
- [Versiones soportadas de PHP](https://www.php.net/supported-versions.php) y [cambios incompatibles de PHP 8.5](https://www.php.net/manual/en/migration85.incompatible.php).
- [AI Assisted Development en Laravel](https://laravel.com/docs/13.x/ai), sobre Laravel Boost y sus guidelines.

---

## Sitemap

Índice completo del sitio: [/sitemap.md](https://www.angelcruz.dev/sitemap.md)

Canónico HTML: [https://www.angelcruz.dev/post/php-laravel-lenguaje-para-agentes](https://www.angelcruz.dev/post/php-laravel-lenguaje-para-agentes)