Hace poco estaba haciendo perpiamin tras acordar una implementación con un compañero.

Mi primer instinto fue escribir un comentario para que copailot hiciese el Código.

Hacemos un flatmap y el resultado se llama X en inglés, pero os hacéis la idea y me detuve.

Me sentí un poco ridículo por un momento, ni recordaba la sintaxis de un patrón que he usado cientos de veces.

Prácticamente en piloto automático, mis dedos se habían movido solos, preparando el terreno para que Copilot escribiese el Código.

Por mí ni lo pensé.

No decidí delegar mi cerebro por defecto.

Ya no se preparaba para resolver el problema, sino para simplemente describirlo.

Y en ese pequeño momento sentí un escalofrío o no sé si era ansiedad, no era pereza, era como un reflejo condicionado, como el perro de Pablo.

Pero para la programación, mi cerebro había sido sutilmente reconfigurado para ser el gestor de praps y no el solucionador de problemas.

Bueno, pues yo seguía en llamada con mi compañero.

En lugar de borrar el comentario y hacerlo, yo dejé que Copilot escribiese el Código.

Bueno, spoiler, lo hizo mal.

El resultado tenía un bug, era bastante sutil, pero bueno, tenía un bug y fue ahí cuando me mostró un poco de ansiedad.

La responsabilidad era mía, no tenía ni idea de la sintaxis ni como arreglarlo en ese momento y la habilidad se la había cedido a una herramienta y esa herramienta había fallado esto.

Me llevo a hacerme una pregunta que realmente me ha estado persiguiendo durante las últimas semanas y no sé muy bien la respuesta, como siempre, pero cuántos de mis pensamientos de programación son realmente míos y cuántos ya son el eco.

De la máquina con la que paso 8 horas al día.

Hola, yo soy Richard y estos programar es simple, hoy vamos a ir un poco más profundo de lo que nunca hemos ido.

¿Qué pasa cuando la herramienta que usas todos los días empieza a rediseñar la forma en la que piensas, no desde la ciencia ficción, sino desde esa pequeña pausa antes de escribir una línea de código?

Hoy hablamos de entrelazamiento cognitivo con la I a.

¿Y cómo podemos navegarlo sin perder la esencia de lo que somos?

Esta sensación no es solo mía, he hablado con varias personas y he escuchado muchas conversaciones sobre el tema y el patrón es el mismo.

La I a nos da una productividad increíble en el equipo en el que estés.

Seguro que hay tareas que antes tomaban un día entero, como crear, por ejemplo, un script de migración de datos.

Ahora se hacen en 30 minutos.

La ella conoce exactamente todos los esquemas que tienes en producción y los números son reales.

Esto está pasando, pero también hay un coste.

Había quedado el otro día con una persona con la que estudia en el grado superior y justamente me estaba hablando de que tenía tickets que quizás le duraban 3 días en resolver y que eso no estaba mal visto en su empresa.

Y le dije que de verdad probase cloud de Code, que es la herramienta que yo más utilizo ahora mismo.

Y no sé qué tal has leído porque no le he preguntado, así que es una buena acción que puedo tomar yo, pero sí que es verdad que creo que esas tareas por lo que me estuvo contando que duran 3, cuatro, 5 días, probablemente en menos de 3:04 las solucionas una vez tuvieses un setup.

Correcto, claro, pero claro, eso no es la preocupación.

Quiero decir, hacemos muchas tareas, está muy bien.

Pero sí que es verdad que creo que en manos equivocadas esa herramienta o en las mías, por ejemplo, esa misma herramienta te podría dar mucho código, que ni siquiera entendieses cosas, que quizás al programarlas tú mismo las entendieses, porque al final tienes un proceso de razonamiento.

Pero si utilizas cloud code y simplemente le dices, oye, implementa este ticket, te meto un mcp de jira, coges todo el contexto y simplemente lo solucionas.

Pues quizás te tiras más tiempo entendiendo lo que ha hecho la IA que pensando tu en una solución.

Y eso creo que de verdad es preocupante.

Piénsalo, es como usar una calculadora para una suma simple.

Lo haces por hábito, por velocidad, pero si lo haces siempre un día, al final intentas sumar de cabeza y dudas ese instante.

Esa es la atrofia del músculo mental.

Y en promoción esa duda puede ser la diferencia entre confianza y dependencia.

La verdad es que la atrofia de una habilidad técnica no es exactamente lo que me dio ese miedo y lo que me ha hecho grabar este podcast, sino lo que de verdad me inquietó.

Fue una funcionalidad que vi anunciar hace unos meses, la memoria persistente de chagpt, que parece una tontería.

Cuando lo anunciaron recuerdo que intenté acceder con una VPN.

Quería probar esa beta como fuese, pero bueno, al igual que otras funcionalidades de chagpt, no era simplemente un bloqueo regional, sino que estaba limitado a un grupo cerrado.

Ahora ya lo teneis todos y aunque yo ya no pago la suscripción, la idea me sigue pareciendo un punto de inflexión.

Y a ver si hablamos en términos técnicos.

Quizás simplemente un rag mal implementado en el que simplemente HGPT va accediendo a una base vectorial.

Pero según esto avance va a ser muy potente porque ya no hablamos de que simplemente recuerde un snippet de código.

Hablamos de que HGPT aprende con cada conversación que sabe tu side project.

Que puedes recordar cómo se llama tu perro o que la semana pasada lo llevaste al veterinario que aprende a darte las respuestas justo con el tono, la y la estructura que a TI te gusten.

Y lo mismo si le pides escribir un email.

Ya no hace falta que le estés corrigiendo y le digas, oye, no pongas best regards.

Y bueno, no sé si os ha pasado, pero sí que es verdad que cada vez que usabas chahípete para escribir un email.

Ponía hola, buenos días, espero que te encuentres bien en donde estés.

Quería decirte esto y esto y al final ponía siempre saludos y bueno, era bastante fácil.

Despotear que no habías dirigido en 2 minutos a ese email y bueno, creo que ahí está el verdadero peligro.

Mucho más allá de un bug en tu código, estamos creando voluntariamente una cámara de ico muy.

Personal, un asistente que nunca te va a llevar la contraria, que va a reforzar tus sesgos, que va a hacer que tu mundo, tus ideas y tus soluciones se hagan cada vez más pequeños y predecibles.

El problema ya no es si mi mente es mía cuando programo.

El problema es si mi visión del mundo sigue siendo mía, cuando el principal agente con el que dialogo ya sabe exactamente lo que quiero escuchar.

Es un confort peligrosísimo.

¿Entonces, si el riesgo es caer en una cámara de Eco, cómo colaboramos con la IA sin perdernos en ella?

He descubierto que la clave no es la resistencia pasiva, sino la colaboración consciente, ponerle reglas al juego.

Este es el flujo de trabajo que he empezado seguir primero y, lo más importante, planificar con la IIA como si fuese un compañero o un colega, no que te vaya a solucionar los problemas.

Esta es la más importante.

Antes de dejar que escriba código, planifico con ella.

Le presento el problema y le pido que me proponga una estructura o un enfoque que coja contexto.

La I a propone, pero yo dirijo la estrategia.

Segundo, es criticar lo que te propone.

Una vez tengo esta propuesta inicial, mi trabajo es actuar como un revisor crítico.

¿Le pregunto directamente, cómo vamos a testear esta parte de la aplicación?

¿Qué otros entrippoints podría tener esta funcionalidad?

¿Hay algún evento que mute los datos que nosotros usamos aquí, que has asumido sobre nuestros datos?

Que podría no ser cierto, lo usé como un sparring partner, no para encontrar los puntos ciegos del plan antes de que escriba.

Ni siquiera la primera línea del Código.

La code review como conexión humana sigue siendo.

Muy importante, ya os lo dije hace mucho tiempo, pero básicamente creo que ahora que el outwood de los desarrolladores es tan alto, la core review es más importante que nunca.

Es el momento y la oportunidad que tenemos de crear contexto compartido con nuestros compañeros, dado que no siempre hacemos per pero Amin es el momento para tener otro para de ojos.

Que realmente nos ayude a nuestro lado, que validen no solamente el código, sino también la lógica y la intención que había detrás de él.

No se trata de desconfiar de la herramienta, sino de integrarla en un flujo de trabajo donde el pensamiento crítico y la conexión humana siguen siendo las protagonistas.

Estas son las ideas que vienen de streamgramming y de todos estos movimientos de siempre.

Entonces sí.

Mi mente ya no es solamente mía, es un espacio compartido con una gente inteligente y eso me aterra y me fascina a partes iguales.

Pero esto nos obliga a tomar una decisión.

¿Podemos ser residentes en el mundo de la I a que nos construye un lugar cómodo, fácil y predecible, donde nuestras ideas simplemente rebotan en un espejo o podríamos elegir ser exploradores?

Un explorador usa las mejores herramientas a su disposición, pero nunca deja que la herramienta decida el mapa.

Un explorador busca activamente los bordes, las onas de conflicto, las ideas que no encajan en programación.

Ser un explorador significa celebrar la duda, no buscar la certeza inmediata, fomentar el debate con tus compañeros como el recurso más valioso que tenemos.

Y tratar a la I a como un trampolín para hacer preguntas más difíciles, no como una fuente de respuestas fáciles, porque al final el Código es la parte fácil y el complejo es asegurarnos de que el que piensa, el que duda y el que elige sigamos siendo nosotros.

¿Y hasta aquí llega la reflexión de esta semana, quería saber cómo a TI te afecta esto?

¿Has sentido como la I a empieza a predecir tus pensamientos?

¿Has empezado a depender en ella?

¿Qué haces tú para romper esa Cámara de Eco?

Me encantaría escucharte, así que tienes mi LinkedIn, ya lo sabes, tienes mi página web, remusrd.com y nada, escríbeme, Cuéntame, quiero que hablemos, quiero que haya una conversación y la próxima semana vamos a hablar de qué pasa con las herramientas en las empresas.

¿Por qué tu empresa tiene miedo a la I a?

Hasta entonces, muchísimas gracias por escuchar un abrazo, hasta luego.