Llevo más de 10 años diseñando interfaces para bancos y fintechs. Flujos de onboarding, pantallas de aprobación, dashboards de transacciones, apps de inversión. Trabajé con equipos de producto, equipos de ingeniería, gerentes de proyecto y reguladores. Pasé revisiones de usabilidad, auditorías de accesibilidad y presentaciones a stakeholders que no entienden por qué un botón debería decir una cosa y no otra.
En los últimos 6 meses construí un blog trilingüe completo con Claude como coding partner. Y en ese proceso adopté 6 prácticas profesionales que una década en la industria nunca me enseñó. No porque la IA sea mejor maestra que la experiencia. Porque la IA me obligó a hacer cosas que la cultura laboral había normalizado saltarse.
1. Preguntar el doble de lo que preguntaba antes
En un entorno corporativo, las preguntas se limitan al alcance del proyecto. ¿Cuál es el objetivo de la web? ¿Qué funcionalidades necesita? ¿Cuándo se entrega? Preguntas operativas que resuelven el qué pero no el hacia dónde.
Trabajando con IA, las preguntas se expandieron. Ya no pregunto solo cuál es el objetivo de la web. Pregunto hacia dónde va a evolucionar ese objetivo en 12 meses. Si ese objetivo cambia, ¿la arquitectura que estoy construyendo lo soporta o hay que reconstruir? ¿El stack que estoy eligiendo es una decisión técnica o una costumbre?
La IA no responde mejor cuando le haces preguntas superficiales. Responde mejor cuando le das contexto profundo. Eso me obligó a desarrollar contexto profundo antes de cada proyecto. Y ese hábito no desaparece cuando trabajo sin IA. Ahora le hago las mismas preguntas a los clientes.
2. Documentar pensando en que otros lo van a leer
En la industria, la documentación es un afterthought. Se escribe rápido, se escribe genérica, y se escribe para cumplir un requisito, no para que alguien la entienda. La frase "el código se documenta solo" la he escuchado decenas de veces.
Cuando trabajo con Claude, cada instrucción es documentación. Si no explico bien lo que quiero, el output es incorrecto. Y explicar bien significa bajar el idioma a conceptos básicos. No asumir que la IA sabe qué quiero decir con "hazlo responsive" o "optimiza el rendimiento." Significa especificar qué breakpoints, qué métricas, qué compromiso entre velocidad y funcionalidad.
El efecto secundario es que ahora documento todo pensando en que alguien sin mi contexto lo va a leer. No porque me lo pidan. Porque el hábito de explicar para la IA se transfirió a explicar para humanos. Mi documentación mejoró porque mi audiencia más exigente es una máquina que no infiere nada.
3. Explicar lo que hago a personas que no son técnicas
Mis informes a clientes solían ser técnicos. "Implementé JSON-LD con 5 entidades en @graph." "Optimicé el TTFB a 200ms." Correcto. Incomprensible para alguien que paga por un resultado de negocio, no por una métrica técnica.
Ahora paso todo por una capa de explicación para no técnicos. No porque la IA me lo haya sugerido. Porque el proceso de trabajar con IA me entrenó en traducir conceptos complejos a lenguaje simple. Si puedo explicarle a Claude qué quiero en una oración, puedo explicarle a un cliente qué hice en un párrafo.
El resultado práctico: recibo menos mensajes de clientes pidiendo que les explique lo que hice. Los informes se explican solos. Eso me ahorra horas por semana que antes gastaba en llamadas de aclaración.
4. Justificar decisiones técnicas con datos, no con costumbre
En un equipo de desarrollo, las decisiones técnicas muchas veces se toman por inercia. "Usamos React porque es lo que usamos." "El framework es Laravel porque el equipo lo conoce." "La base de datos es PostgreSQL porque siempre ha sido PostgreSQL." Son decisiones razonables pero raramente cuestionadas.
La IA me confronta con alternativas en cada decisión. Cuando le digo que voy a usar una tecnología, no asume que es la correcta. Pregunta (o debería preguntar, y si no pregunta, yo pregunto) por qué esa y no otra. ¿Qué necesita el cliente específicamente que justifique esa elección? ¿Hay algo más simple que resuelva el mismo problema?
Esto me forzó a dejar de elegir tecnologías por familiaridad y empezar a elegir por ajuste al problema. Mi blog corre en PHP vanilla no porque no conozca frameworks sino porque analicé lo que necesitaba y un framework era complejidad innecesaria para ese caso.
5. Expresarme con precisión, no con aproximación
En una reunión de trabajo, puedes decir "mejoremos la experiencia del usuario" y todos asienten. Nadie pregunta exactamente qué significa eso. La ambigüedad se resuelve con contexto compartido y suposiciones implícitas.
Con una IA, la ambigüedad produce output ambiguo. Si digo "mejora la UX", obtengo una lista genérica de best practices. Si digo "reduce el tiempo entre la primera interacción y la primera acción completada en el formulario de onboarding para usuarios mayores de 60 años", obtengo algo útil.
Eso me entrenó en precisión. Si la IA no me entiende con instrucciones vagas, un humano tampoco me entiende. Solo que el humano finge que sí. La IA me devuelve el resultado exacto de lo que dije, no de lo que quise decir. Eso es un espejo que la cultura laboral no tiene.
6. Cuestionar si algo funciona o simplemente no se ha roto todavía
En programación hay una frase que se repite en todos los equipos: "si funciona, no se toca." Es una regla de supervivencia. No muevas lo que no está roto. Pero esa regla también congela el conocimiento.
Cuando la IA genera código, a veces usa un patrón que no conozco. La primera reacción es ignorarlo si el output funciona. La segunda, la que adopté con el tiempo, es preguntar por qué usó ese patrón y no el que yo habría usado. Así como sumar es útil para un momento de la vida y luego sigue multiplicar, en el código que algo funcione no quiere decir que no exista algo mejor.
Los flags de json_encode (JSON_UNESCAPED_SLASHES y JSON_UNESCAPED_UNICODE) estaban en mi código porque Claude los puso. Funcionaban. Nunca los cuestioné. Cuando Abbey de freeCodeCamp me preguntó por qué importaban, descubrí que estaban previniendo bugs silenciosos en un blog trilingüe. No eran decoración. Eran la diferencia entre un JSON-LD funcional y uno que se rompía con acentos en español.
"Si funciona, no se toca" se convirtió en "funciona, pero ¿por qué funciona así y no de otra forma?"
Lo que esto dice sobre la industria
Ninguna de estas 6 prácticas es nueva. Preguntar profundo, documentar bien, comunicar para no técnicos, justificar decisiones, ser preciso al expresarse, y cuestionar lo que funciona. Son prácticas fundamentales que cualquier profesional senior debería tener.
Pero la cultura laboral de fintech y banca no las prioriza. Prioriza velocidad de entrega, cumplimiento de requisitos, y estabilidad sobre innovación. En ese contexto, la documentación se sacrifica, las preguntas profundas se perciben como pérdida de tiempo, y "si funciona no se toca" es una virtud, no un vicio.
La IA no me enseñó estas prácticas. Me obligó a adoptarlas porque son la única forma de obtener output de calidad de una herramienta que no infiere, no asume, y no finge entender lo que no le explicaste bien.
Eso no dice algo bueno sobre la IA. Dice algo preocupante sobre una industria que permitió que un profesional con 10 años de experiencia llegara hasta aquí sin ellas.