Shortcode personalizado de WooCommerce: a mano vs generado con IA

Cogí uno de mis proyectos de cliente de pago, un shortcode de WooCommerce para un grid de productos comisariado con filtros, y lo reimplementé dos veces: una a mano como siempre había hecho, otra con un agente de IA. Luego lo medí. Los resultados me sorprendieron más de lo que esperaba.

La funcionalidad

El shortcode acepta parámetros de categoría, número de productos, columnas y un orden personalizado por un meta numérico que el cliente usa para fijar elementos destacados. Renderiza un grid con un botón de vista rápida que abre un modal por AJAX. Sencillo, pero con partes móviles suficientes para ser interesante.

Versión a mano

Mi implementación original tenía 340 líneas en tres ficheros. Estaba relativamente orgulloso de ella cuando la envié en 2023. Al releerla ahora noté tres cosas. Primero: usaba WP_Query con fields => ids, que es lo correcto por rendimiento, pero olvidé hidratar los posts antes del bucle, generando una consulta extra por producto en la plantilla. Un N+1 clásico que se me coló en la revisión. Segundo: tenía un TODO de 2023 sobre añadir caché en transient que nunca hice. Tercero: el handler AJAX validaba el nonce pero confiaba en el product_id sin validar el contexto de tienda. No es un agujero de seguridad porque los datos son públicos, pero higiene mejorable.

Versión generada con IA

Prompteé el mismo conjunto de funcionalidades con los mismos nombres de parámetros para que fuera drop-in. El agente produjo 280 líneas, un 18% menos. Sorprendentemente, la reducción no vino de menos funciones sino de PHP más limpio: menos variables temporales, mejor uso de array_map, y helpers de WordPress que siempre olvido que existen como wp_list_pluck y wc_get_product_ids_on_sale.

Sobre los tres fallos de mi versión a mano: la IA hidrató los productos antes del bucle (sin N+1). Añadió caché en transient de cinco minutos indexado por todos los parámetros del shortcode, de serie. Validó el product ID en el handler AJAX cargando el producto con wc_get_product y comprobando que era comprable antes de devolver datos. Esto último ni se lo pedí.

Benchmarks de rendimiento

Mismo servidor, misma base de datos con 1.200 productos, caché fría. 50 peticiones secuenciales a una página con el shortcode renderizando 24 productos.

• Mediana a mano: 742 ms, 31 consultas por página
• Mediana IA: 168 ms, 4 consultas por página (gracias al transient; con caché fría 512 ms con 14 consultas, aún mejor)

La mejora en número de consultas es casi enteramente el N+1 que se me coló. La mejora en tiempo tras el primer hit es el caché en transient que nunca me dio tiempo a añadir.

Legibilidad

Subjetivo, pero pasé ambas versiones por PHPCS con WordPress Coding Standards y la de IA pasó limpia. La mía tenía 14 avisos menores, sobre todo espaciado y una condición yoda que me había saltado. Seis de los catorce estaban en código que escribí antes de tener PHPCS en el flujo del proyecto, no es una comparación justa.

El naming y organización de ficheros fue equivalente. La IA organizó en class-shortcode.php, class-ajax-handler.php y class-cache.php, como yo lo habría hecho si hubiera sido disciplinado. Un jueves por la tarde hace dos años, no lo era.

Lo que la IA no captó

Una cosa: el cliente quería que los "destacados" respetaran el stock, de modo que los productos sin stock cayeran al final del grid aunque su rango destacado fuera mayor. Yo lo tenía con una cláusula SQL personalizada. La IA no lo infirió porque no estaba en el prompt. Al añadir el requisito, la versión regenerada lo manejó con un callback usort más limpio que mi SQL crudo.

Auditoría de seguridad

Pasé ambas por una auditoría básica: nonce en todos los AJAX, saneo en todas las entradas, escape en todas las salidas, capability checks en acciones admin. Ambas pasaron. La IA usó esc_url donde yo había usado esc_attr, que es lo correcto para un atributo URL. Además usaba wp_kses_post de forma consistente donde yo oscilaba entre eso y wp_kses_allowed_html('post').

Lo que esto NO significa

No significa que la IA sea mejor que un buen dev de WordPress. Significa que la versión de mí que escribió el shortcode original con prisa hace dos años era peor que una IA moderna con el mismo prompt. La IA no se saltó el transient porque fuera jueves a las 16:00.

Tampoco significa que debas generar y enviar sin leer. Encontré un sitio donde usaba mb_strtolower sin comprobar, lo cual fallaría en un hosting sin mbstring. Poco común en hostings modernos de WordPress, pero añadí un feature check por si acaso. Los humanos seguimos revisando.

Conclusión

Para los problemas de escala de shortcode que representan una fracción enorme del trabajo de cliente, la velocidad y calidad del código generado por IA ya ha pasado el umbral en el que ignorarla es una desventaja competitiva. La versión que sustituyó a la mía costó once minutos de principio a fin incluyendo revisión. Ya está en la web del cliente.