Hay decisiones técnicas que no se justifican con una regla. Elegir una abstracción sobre otra. Decidir que un módulo debería partirse en dos, o que dos deberían ser uno. Nombrar algo de una manera que hace que todo el sistema se entienda mejor, sin poder articular del todo por qué ese nombre y no otro.

Son decisiones que funcionan. Que después el equipo reconoce como correctas. Pero que en el momento de tomarlas no tienen una demostración formal. Solo tienen algo más difícil de definir: gusto.

La palabra parece frívola para el software. Asociamos gusto con estética, con diseño visual, con lo subjetivo e idiosincrático. Pero en las entrañas de un sistema complejo (la forma de las abstracciones, dónde están los límites entre componentes, qué existe y qué no, cómo se nombran las cosas que todavía no tienen nombre) hay algo que funciona como gusto y que no se reduce ni a reglas ni a experiencia bruta. No es intuición mística. No es preferencia personal. Llamo gusto a la capa menos verbal y más sensible del criterio técnico: la capacidad de percibir forma, proporción y coherencia estructural antes de poder convertir esa percepción en regla. Se puede observar, distingue a ciertos profesionales, y se vuelve cada vez más relevante cuanto más código genera el copiloto.

Lo superficial y lo estructural

No toda complejidad en software es igual.

Hay una complejidad superficial que tiene respuestas codificables. Convenciones de nombrado, formateo, patrones conocidos, boilerplate. Un linter lo resuelve. Un copiloto lo resuelve mejor aún. Acá no hace falta gusto: hacen falta reglas. Y las reglas se automatizan.

Y hay una complejidad estructural que no tiene una respuesta correcta. Tiene un espacio de posibilidades donde varias opciones compilan, pasan tests y se ven razonables. Pero no todas son iguales. Una escala, otra no. Una se entiende dentro de seis meses, otra genera confusión cada vez que alguien la toca. Una respeta la integridad conceptual del sistema, otra la fragmenta sin que nadie lo note hasta que es tarde.

Un ejemplo. Estás partiendo un servicio monolítico. El copiloto sugiere separar por capa técnica: un servicio de API, otro de lógica de negocio, otro de persistencia. Compila, se despliega, los tests pasan. Pero alguien en el equipo propone partir por dominio: pagos por un lado, inventario por otro, usuarios por otro. Técnicamente más complejo de migrar, pero cada servicio resultante es autónomo y puede evolucionar sin coordinar con los demás. Ningún linter te dice cuál es mejor. Ninguna regla lo resuelve. Las dos opciones funcionan. Pero una deja al sistema preparado para crecer y la otra lo condena a cambios transversales con cada funcionalidad nueva. Lo que distingue a quien elige bien no es solo que sepa más. Es que percibe la forma que el sistema necesita.

El copiloto opera con fluidez notable en la capa superficial. En la estructural, genera opciones que parecen estructurales pero que fueron producidas, no elegidas. Propone tres arquitecturas en segundos. Las tres compilan. Las tres pasan los tests básicos. Pero solo una respeta las convenciones no escritas del equipo, solo una escala sin generar acoplamiento invisible, solo una va a ser mantenible cuando el contexto cambie.

La diferencia entre esas tres opciones puede ser invisible hoy y devastadora dentro de seis meses. Y lo que permite distinguirlas no es conocimiento (saber la respuesta), ni experiencia (haber visto algo parecido). Es algo más sutil: percibir hacia dónde ir cuando hay múltiples caminos que se ven equivalentes pero no lo son.

Eso es gusto.

Cómo se forma (y por qué parece seniority pero no lo es)

Si el gusto se forma con exposición, error y acumulación de juicio, suena peligrosamente a lo que cuestionamos al principio de esta serie: seniority como experiencia acumulada, las 10.000 horas de Gladwell. ¿Estamos dando una vuelta completa para volver al punto de partida?

No. Pero la distinción es importante.

Gusto no es experiencia. Es experiencia filtrada por tres disposiciones que ya sabemos que importan: curiosidad, pensamiento crítico y agencia.

Sin curiosidad, diez años de trabajo son diez años de exposición a los mismos patrones, las mismas decisiones estructurales, los mismos dominios. Eso no forma gusto. Forma hábito. El desarrollador que nunca exploró fuera de su territorio conocido no tiene gusto: tiene reflejos condicionados que funcionan en terreno familiar y fallan en terreno nuevo.

Sin pensamiento crítico, aceptás las soluciones estructurales que funcionaron antes sin preguntarte si son las correctas ahora. Replicás la arquitectura del proyecto anterior porque “funcionó”, sin evaluar si este contexto es distinto. Eso no es gusto. Es pattern matching: reconocimiento de patrones sin juicio sobre su aplicabilidad. Funciona hasta que el contexto cambia, y entonces falla silenciosamente.

Sin agencia, nunca tomás la decisión estructural vos mismo. Nunca vivís las consecuencias. Nunca descubrís, seis meses después, que aquella abstracción que parecía elegante generó una madeja de dependencias imposible de desenredar. Eso no forma juicio. Forma espectadores: personas que reconocen el buen diseño cuando lo ven, pero que nunca desarrollaron la capacidad de producirlo.

Gusto es lo que las tres disposiciones producen cuando se aplican a complejidad estructural a lo largo del tiempo. No es un cuarto pilar del seniority. Es el residuo de los tres primeros en acción. Si en los últimos artículos de esta serie el valor del oficio se desplazó de la producción al criterio, gusto es el nombre de la forma más sutil de ese criterio: la que no se puede codificar ni delegar.

Y se nota. Se nota en la persona que mira un pull request y dice “esto funciona pero no me cierra” antes de poder explicar por qué. Se nota en quien elige el nombre correcto para un concepto nuevo, el que hace que todo el equipo piense con más claridad. Se nota en quien descarta una solución que técnicamente resuelve el problema pero que introduce una complejidad que no se justifica. Se nota en quien planifica una reingeniería grande y secuencia los módulos en el orden correcto, ese orden que no sale de ningún diagrama pero que hace que cada paso habilite el siguiente en vez de bloquearlo. No pueden siempre articular la regla que están siguiendo. Porque no hay regla. Hay gusto.

Lo que el copiloto amenaza

Acá es donde la tensión se vuelve concreta.

El copiloto te da años de exposición superficial sin que ejerzas las tres disposiciones sobre decisiones estructurales. Podés usar un copiloto intensamente durante años y no desarrollar un gramo de gusto, porque nunca navegaste la complejidad estructural vos mismo. El copiloto te dio las respuestas antes de que hicieras las preguntas.

El mecanismo es sutil. No es que el copiloto tome decisiones malas. Es que te evita el proceso de tomar decisiones difíciles. Propone una arquitectura razonable y vos la aceptás porque se ve bien y el deadline aprieta. Genera una abstracción plausible y vos seguís adelante porque compila y no hay motivo obvio para rechazarla. Cada vez que eso pasa, te ahorraste un momento de incomodidad. Y cada momento de incomodidad que te ahorraste era una oportunidad de formar gusto.

Porque el gusto se forma tomando decisiones estructurales malas, viviendo sus consecuencias, y acumulando ese dolor como juicio. El desarrollador que eligió mal una abstracción y pasó tres meses peleando con las consecuencias no va a elegir mal de la misma manera otra vez. No porque aprendió una regla, sino porque incorporó algo que no tiene nombre técnico pero que funciona como un sexto sentido para la estructura.

Si el copiloto te ahorra las decisiones malas, también te ahorra el aprendizaje que esas decisiones producen.

La paradoja es precisa: la herramienta que más necesita gusto en quien la usa es la misma que dificulta su formación. El copiloto genera código que requiere evaluación estructural constante, pero reduce las oportunidades de practicar esa evaluación en carne propia. Necesitás gusto para usarlo bien, pero usarlo no te da gusto.

No es que el copiloto destruya el gusto. Es que no lo forma por defecto. Usado como contraste, como generador de alternativas que después obligás a comparar y justificar, puede incluso contribuir a afinarlo. Pero el flujo natural del trabajo asistido, el que no requiere esfuerzo deliberado, empuja en la dirección opuesta: aceptar lo que se ve razonable, avanzar, repetir.

Cultivar gusto

El gusto no se enseña con una lista. Si pudiera reducirse a reglas, sería ingeniería, no gusto. Pero hay condiciones que lo favorecen.

Tomar decisiones estructurales propias. Leer código ajeno forma parte del gusto, pero no alcanza. Hay que decidir, construir sobre esa decisión, y descubrir después si sostuvo el peso o se quebró. Eso requiere que no todo lo decida el copiloto. A veces, antes de pedirle al agente que proponga la arquitectura, conviene sentarse con el problema el tiempo suficiente para formar una intuición propia. Después podés contrastarla con lo que el copiloto sugiere. Pero el orden importa: primero tu juicio, después la máquina.

Sostener la incomodidad de no saber. El gusto se forma en el hueco antes de la respuesta: ese momento incómodo donde todavía no ves la solución pero sentís que te estás acercando. Si el copiloto llena ese hueco instantáneamente, el gusto no tiene espacio para crecer. No se trata de rechazar la herramienta, sino de no usarla como anestesia contra la incertidumbre.

Preguntarse “¿por qué esto y no otra cosa?” No solo “¿funciona?” sino “¿por qué esta abstracción?”, “¿por qué este límite acá y no allá?”, “¿qué estaría haciendo distinto alguien con mejor gusto que yo?”. Esas preguntas, aplicadas al código generado, son ejercicios de gusto. Son el equivalente a un músico que no solo toca las notas correctas sino que escucha por qué suenan así y si podrían sonar mejor.

Reconocer la zona donde las reglas no alcanzan. Si podés explicar completamente una decisión con reglas, no era gusto: era ingeniería. El gusto aparece donde las reglas se quedan cortas, donde dos opciones son equivalentes según cualquier métrica formal pero una es claramente mejor. Reconocer esa zona, habitar esa incertidumbre sin apurarse a resolverla, es parte de cultivarlo.

El gusto no es un lujo estético. No es una preferencia de los que tienen tiempo de sobra. Es lo que queda cuando la producción se automatiza y las reglas no alcanzan. Es juicio sedimentado, las tres disposiciones que definen seniority aplicadas al terreno más difícil del software: el que no tiene una respuesta correcta.

El copiloto nos da velocidad en la superficie. Gusto es lo que decide si esa velocidad construye algo que vale la pena.

¿Cuándo fue la última vez que tomaste una decisión técnica que no podías justificar del todo con reglas, pero sabías que era la correcta? ¿Cómo distinguís, en tu equipo, a alguien que tiene gusto de alguien que tiene experiencia?