Le di a Claude una aplicación y le pedí que actuara como cuatro desarrolladores senior diferentes; esto fue lo que pasó.

En internet abundan las afirmaciones, sobre todo en X, que supuestamente mejoran la eficacia de los chatbots. Cuando me topé con las afirmaciones de David Max , experto en educación en IA , me mostré escéptico, lo que me impulsó a probarlas. Estas afirmaciones aseguran que Claude puede transformarse en todo tipo de herramientas, desde un depurador experto hasta un especialista en rendimiento. Esto es lo que sucedió cuando decidí investigar. Si te interesan otras afirmaciones más efectivas, puedes consultar « 7 afirmaciones efectivas sobre Claude 4 para desarrollar tus ideas y aumentar tu productividad».

Consulta mi registro de gastos del hogar en Claude.

Ya había creado un registro general de gastos con marcadores de posición para gastos usando ChatGPT Work, así que lo utilicé y luego le pedí a Claude que revisara la aplicación cuatro veces. En cada ocasión, le asigné un rol de ingeniería principal diferente: ingeniero full-stack, ingeniero de depuración, ingeniero frontend e ingeniero de rendimiento.

El resultado fue mucho más revelador que simplemente pedirle a Claude que “mejorara la aplicación”. Cada personaje se centró en un conjunto diferente de problemas, e incluso a veces descubrió fallos que el “desarrollador” anterior había pasado por alto. Esto fue lo que sucedió y las afirmaciones que hicieron.

1. El ingeniero senior Full-Stack desarrolló la aplicación.

Todo comenzó con una solicitud de Claude para crear un rastreador de gastos domésticos interactivo que cualquiera pudiera usar. Para saber más sobre las capacidades de Claude para crear aplicaciones, lee " Creé 3 aplicaciones en minutos usando Claude y Gemini: pero una de ellas tiene una función oculta ".

El reto: Crear un rastreador de gastos domésticos interactivo que cualquier persona pueda usar para registrar y comprender sus gastos. Debe incluir la posibilidad de agregar y eliminar gastos, asignar categorías, filtrar transacciones, calcular el gasto total y visualizar un desglose por categorías.

Imagínate como un ingeniero sénior full-stack desarrollando un MVP impecable para una startup. Antes de escribir cualquier código, proporciona un breve esquema de la arquitectura, la estructura de datos y el flujo de usuario. Luego, crea la aplicación como un artefacto en la nube.

Haz que sea responsivo y fácil de usar, pero no dediques tiempo extra a revisar, depurar o mejorar el código final. Delegaré esas tareas a otros desarrolladores.

Claude creó una aplicación React sorprendentemente bien diseñada. Incluía ejemplos de transacciones, totales de gasto, clasificaciones por categorías, funciones de búsqueda y filtrado, y la posibilidad de ordenar las transacciones por fecha. Además, guardaba los cambios para que estuvieran disponibles al volver a abrir la aplicación.

A primera vista, parecía mucho más un producto terminado que un prototipo incompleto. Tenía tarjetas estadísticas en la parte superior, un formulario de gastos claro y barras de colores que mostraban cuánto se había gastado en cada categoría.

2. El ingeniero jefe de depuración descubrió algunos problemas.

Después de eso, le pedí a Claude que ignorara las apariencias y se centrara en su propio trabajo como ingeniero de depuración, preparando una aplicación para su lanzamiento.

La exigencia: Ahora, compórtate como el jefe de depuración que heredó esta aplicación antes de su lanzamiento público.

Examine detenidamente la aplicación y su código existente sin alterar su funcionalidad ni su diseño visual. Pruebe los flujos de usuario principales y busque errores funcionales, manejo de entradas no válidas, riesgos de pérdida de datos, cálculos incorrectos, problemas de persistencia y casos límite.

Antes de modificar el código, proporcióneme un breve informe de depuración que contenga lo que ha probado, cada problema que ha encontrado, la causa raíz de cada problema, la gravedad de cada problema y la solución que recomienda.

Luego, realice las reparaciones y verifique que los elementos originales sigan funcionando. No rediseñe la fachada, no emprenda una reforma arquitectónica integral ni realice cambios puramente estéticos.

El proceso de depuración sacó a la luz muchos problemas reales.

Por ejemplo, la entrada original no tenía el formato adecuado. Hacer clic en el botón "Guardar transacción" funcionaba, pero presionar la tecla Enter podría no funcionar. Claude corrigió esto convirtiendo la sección en un formulario adecuado con un botón de envío.

También descubrió que los usuarios podían borrar el historial y guardar una transacción con información de fecha incorrecta. Claude añadió validación de fechas, reforzó las comprobaciones de importes incorrectos y corrigió un cálculo que provocaba que "Vivienda" apareciera como la categoría más grande incluso cuando el registro estaba vacío.

Aún era posible eliminar transacciones de forma permanente con un solo clic. Los errores de almacenamiento permanecían ocultos en la consola del desarrollador, lo que podía llevar a los usuarios a creer que su información se había guardado cuando no era así. Además, Claude no implementó pruebas automatizadas para confirmar que sus correcciones funcionaban correctamente.

3. El experimentado ingeniero de front-end se percató de una aplicación completamente diferente.

En la tercera ronda, le pedí a Claude que tratara el rastreador de gastos como si fuera un ingeniero front-end especializado en diseño responsivo y accesibilidad.

La exigencia: Actúa ahora como un ingeniero front-end experimentado, especializado en aplicaciones de consumo accesibles y con buena capacidad de respuesta.

Revisa tu aplicación actual de seguimiento de gastos desde la perspectiva de alguien que la usa en un teléfono, un teclado o una tecnología de asistencia. Mantén su funcionalidad y su identidad visual general, pero mejora su usabilidad y accesibilidad.

Antes de modificar el código, realice una breve revisión que abarque el comportamiento y la capacidad de respuesta en teléfonos móviles, la navegación mediante teclado, la usabilidad de los formularios, la accesibilidad para lectores de pantalla, el contraste de color, los estados de carga y error, las acciones destructivas y los controles confusos.

Luego, implemente las mejoras. Asegúrese de que cada campo de entrada y control interactivo tenga un nombre accesible, que los estados de enfoque sean claramente visibles, que los mensajes de verificación puedan ser anunciados por un lector de pantalla y que los detalles de los gastos transmitan información sin depender únicamente de barras de colores.

Esta fue la revisión más completa del experimento.

Claude señaló que la aplicación eliminaba el borde natural alrededor de los campos de entrada seleccionados sin proporcionar uno nuevo. En consecuencia, a quien navegara con el teclado le resultaría difícil ver el campo activo.

También se descubrió que las etiquetas visuales no estaban conectadas correctamente a sus campos de entrada correspondientes, que el campo de búsqueda dependía únicamente del texto de marcador de posición y que los errores de validación no estaban configurados para ser anunciados por los lectores de pantalla.

Claude restableció los indicadores de enfoque visual, vinculó las etiquetas a los controles de formulario, añadió descripciones para lectores de pantalla y aumentó el contraste de muchos elementos de texto gris claro. También hizo que la barra de búsqueda fuera más flexible en pantallas pequeñas y añadió etiquetas más descriptivas a los botones que solo contienen iconos.

Lo más importante es que este personaje descubrió un problema de eliminación que el depurador había pasado por alto. Claude reemplazó el botón de eliminar con un solo clic por un proceso de confirmación en dos pasos que requería que los usuarios eliminaran o conservaran la transacción.

No todas las afirmaciones eran perfectas. Claude describió 44 x 44 píxeles como el tamaño mínimo para el área táctil, pero solo amplió el botón principal de borrar a 36 x 36 píxeles. Esto cumple con el objetivo menor de WCAG 2.2 AA, pero no con la recomendación de 44 píxeles que mencionó.

Sin embargo, el cambio en el rol de Claude alteró claramente su perspectiva. El depurador comprobaba si la aplicación funcionaba, mientras que el ingeniero de interfaz examinaba si una persona real podría usarla cómodamente. Este experimento demuestra cómo un solo requisito puede influir significativamente en los resultados de Claude.

4. El ingeniero de rendimiento reconoció que la aplicación no necesitaba mucha ayuda.

Finalmente, le pedí a Claude que configurara un sistema de seguimiento de gastos para gestionar al menos 10,000 transacciones.

La exigencia: Ahora, actúe como ingeniero sénior de rendimiento, preparando este sistema de seguimiento de gastos para gestionar miles de transacciones.

Analice la implementación actual para detectar renderizado innecesario, cálculos redundantes, ordenación o filtrado ineficientes, cuellos de botella de almacenamiento, aumento de la memoria e interacciones que puedan ralentizarse a medida que aumenta el tamaño de los datos.

No des por sentado que hay un problema de rendimiento. Crea una forma realista de probar la aplicación con al menos 10 000 transacciones y establece una línea base para las operaciones críticas.

Implementa únicamente las mejoras justificadas por el análisis. Mantén la apariencia de la aplicación, las mejoras de accesibilidad y su funcionamiento actual. No afirmes que se ha producido una mejora en la velocidad a menos que la hayas medido o definido claramente como una mejora prevista.

Claude descubrió un cuello de botella particularmente importante. La aplicación creaba un nuevo objeto de formato de moneda cada vez que mostraba una cantidad. Con 10 000 filas, Claude midió que este proceso tardaba 349 milisegundos. Reutilizar un único formateador lo redujo a 5.2 milisegundos, lo que, según los cálculos de Claude, representa una mejora de 67 veces.

Claude también añadió una función de "virtualización de tablas", lo que significa que el navegador mostrará solo las transacciones visibles en la pantalla, en lugar de miles de filas a la vez. Las actualizaciones de búsqueda y almacenamiento se retrasaron una fracción de segundo para evitar costosas repeticiones tras cada pulsación de tecla o cambio rápido.

Claude incluso añadió botones que pueden generar 1,000, 10,000 o 50,000 transacciones de muestra para realizar pruebas de estrés.

Pero la parte más convincente del informe fue la admisión de Claude de que la mayoría de estas mejoras no eran necesarias para el propósito previsto de la aplicación.

Un hogar típico podría añadir entre 30 y 50 transacciones al mes. Incluso una década después, Claude concluyó que la aplicación original probablemente habría gestionado los datos resultantes sin problemas significativos. Aparte del almacenamiento en caché del formateador de moneda, la mayoría de las mejoras solo fueron útiles porque solicité específicamente compatibilidad con miles de transacciones.

Esta moderación (o autocontrol) parecía más "madura" y "profesional" que simplemente hacer cambios por el mero hecho de poder hacerlos.

Mi conclusión final

Considero que estas afirmaciones son sumamente efectivas, ya que cada una resalta claramente las fortalezas y debilidades de Claude. Cada rol ofrece una perspectiva única para la evaluación, lo cual me resultó muy útil y sin duda lo aplicaré en mis futuras reseñas de otras aplicaciones y sitios web.

Mientras que el ingeniero de depuración descubrió un comportamiento incorrecto, el ingeniero de interfaz encontró problemas de accesibilidad y usabilidad. Por otro lado, el ingeniero de rendimiento consideró las implicaciones del aumento del volumen de datos y reconoció cuándo la optimización era innecesaria.

La experiencia también demostró por qué utilizar una única exigencia general como «Preparar esto para la producción» podría no ser el mejor enfoque. Una sola revisión podría pasar por alto cuestiones importantes, incluso si la exigencia parece exhaustiva. Dividir el trabajo en fases más específicas le dio a Claude menos prioridades que abordar y facilitó la evaluación de sus resultados.

Ten en cuenta los límites de uso de la nube. La próxima vez, intentaré combinar las indicaciones para evitar alcanzar el máximo permitido.

---

---