mcv hace 5 días | siguiente [–]

Esto parece confirmar la sensación que tengo cuando uso demasiado la IA. Es fácil empezar, pero puedo sentir que mi cerebro se involucra menos con el problema de lo que estoy acostumbrado. Puede convertirse en una barrera para la comprensión real y me saca de mi estado de flow.

Recientemente trabajé en algo muy complejo que no creo que hubiera podido abordar tan rápido sin IA: un algoritmo de disposición jerárquica de grafos basado en el framework de Sugiyama, usando Brandes-Köpf para el posicionamiento de nodos. No tenía experiencia previa con eso (y entré claramente subestimando cuán complejo era), y la IA fue de enorme ayuda para obtener una comprensión básica del algoritmo, sus muchos pasos y sub-algoritmos, las interacciones sutiles y los supuestos no dichos que contiene. Pero dejar que escribiera el código real fue un error. Eso fue lo que me impidió entender las complejidades, involucrarme verdaderamente con el problema, lo que me llevó a seguir dependiendo de la IA para arreglar errores; pero en ese punto la IA claramente tampoco tenía una idea real de lo que estaba haciendo y solo empeoraba las cosas.

Así que, en lugar de dejar que la IA viera el código real, pasé del plugin Copilot del IDE a la app independiente Copilot 365, donde podía explicarme los principios detrás de cada paso, y yo depuraba y arreglaba el código y desarrollaba una comprensión real de lo que estaba pasando. Y finalmente volví a ese estado de flow al programar.

Así que no dejes que la IA se haga cargo de tu trabajo real, sino usala como una enciclopedia interactiva. Eso funciona mucho mejor para este tipo de problemas complejos.

responder

vidarh hace 5 días | padre | siguiente [–]

Mi “trabajo real” no es escribir código, sino resolver problemas. Escribir código simplemente ha sido, típicamente, la forma en que necesitaba resolver esos problemas.

Eso se ha ido desplazando cada vez más hacia “solo” revisar código y enfocarme en la arquitectura y los modelos de dominio.

Puedo dedicar más tiempo a mi trabajo real.

coldtea hace 5 días | raíz | padre | siguiente [–]

Mi “trabajo real” no es escribir código, sino resolver problemas

Resolvés suficientes problemas confiando en que la IA escriba el código como una caja negra, y con el tiempo tu comprensión de la programación va a empeorar, y no vas a entender qué debería estar haciendo la IA ni qué está haciendo mal —ni siquiera a nivel arquitectónico, salvo en trazos muy generales.

Uno termina como el típico gerente despistado que no tocó una computadora en 30 años. En ese punto habrá muy poca razón para que los verdaderos dueños del trabajo mantengan sus servicios.

La programación, en general, al depender de la experiencia enlatada del dataset de la IA, produce cada vez más “churn” de IA a partir del mismo código de entrenamiento disponible con el tiempo, estancando tanto a la programación como a la IA, con la dudosa esperanza de llegar a la Singularidad como única salida.

alchemism hace 5 días | raíz | padre | siguiente [–]

Sin embargo, la mayoría de las organizaciones existentes le pagan a la gente “que no ha tocado una computadora en 30 años” una cantidad bastante grande de dinero para que sigan resolviendo problemas, por alguna razón inescrutable… =)

tayo42 hace 5 días | raíz | padre | siguiente [–]

Ahora existe una carrera para que la gente se quede en ingeniería y gane más que su gerente.

biztos hace 4 días | raíz | padre | siguiente [–]

Esa “carrera” se vuelve cada vez más ilusoria cuanto más lejos caminás por ella.

austinshea hace 3 días | raíz | padre | siguiente [–]

No lo es, pero no es posible que te paguen así si tu trabajo no es un componente necesario del trabajo que le genera a la empresa un gran ingreso.

bakugo hace 5 días | raíz | padre | anterior | siguiente [–]

Que los managers estén sobrepagados y sobrevalorados es un fenómeno bien conocido, sí.

brookst hace 5 días | raíz | padre | siguiente [–]

Es tan viejo como el problema de los ICs extremadamente especializados que no tienen aprecio ni interés por nada fuera de su expertise estrecha (aunque profunda).

listenallyall hace 5 días | raíz | padre | anterior | siguiente [–]

Para ser justos, si lográs seguir empleado durante 30 años antes de que la gente determine que tus habilidades son subestándar, eso ya es mucho mejor que la mayoría. Pero en general estoy de acuerdo con tu punto.

drusepth hace 5 días | raíz | padre | anterior | siguiente [–]

Resolver suficientes problemas confiando en que la IA escriba el código como una caja negra…

Usar IA yo mismo y gestionar equipos casi exclusivamente usando IA me dejó claro este punto: no deberías depender de ella como una caja negra. Podés confiar en que escriba el código, pero (al menos por ahora) deberías seguir estando profundamente involucrado en la “resolución del problema” (es decir, decidir cómo arreglar el problema).

Una buena regla general que me ha funcionado bien es dedicar al menos 20 minutos refinando planes del agente por cada ~5 minutos de tiempo real de desarrollo del agente. YMMV según el alcance del plan (obviamente esto no aplica a arreglos pequeños y aplica aún más a alcances grandes).

tharkun__ hace 4 días | raíz | padre | siguiente [–]

Lo que encuentro más “iluminador” y también aterrador es ver gente con la que trabajé durante bastante tiempo y a la que respetaba por su conocimiento y habilidades empezar a repetir tonterías de la IA y a apagar el cerebro.

Una cosa es usar la IA como usarías a un junior dev que hace lo que le pedís o como un rubber duck. Es un juego completamente distinto si simplemente copiás y pegás lo que dice como si fuera verdad.

Y respecto a que esto obviamente no aplica a arreglos pequeños: ¡claro que aplica! Muchas veces la IA ha intentado “hacer trampa” para salir de situaciones, y ya ni siquiera es gracioso (compará con el post de ayer sobre el take-home test original de Anthropic, donde ellos mismos te advierten que no uses IA para resolverlo porque le gusta hacer trampa, como habilitar más de un core). Lo ha hecho tantas veces que a veces no confío en una respuesta de Claude que yo mismo todavía no entiendo del todo, y descarto una evaluación correcta como “otra pieza más de basura de IA”.

tcfhgj hace 4 días | raíz | padre | siguiente [–]

si simplemente copiás y pegás lo que dice como verdad

Es más difícil que nunca, porque Google está básicamente roto y el conocimiento se comparte mucho menos hoy en día; basta mirar Stack Overflow.

inglor_cz hace 5 días | raíz | padre | anterior | siguiente [–]

No me queda tan claro. Usemos una analogía. Muchas (¿la mayoría?) de las personas pueden distinguir un libro o una historia bien escrita de una mediocre o terrible, aunque la gran mayoría de los lectores nunca haya escrito uno en su vida.

Distinguir lo bueno de lo malo no necesariamente requiere la capacidad de crear.

coldtea hace 5 días | raíz | padre | siguiente [–]

Esta analogía respalda mi argumento, porque en ella, así como “la mayoría de la gente” son meros lectores (no solo no son escritores, tampoco están cerca del nivel de un editor o crítico competente), el programador se convierte en un mero usuario del programa final.

No solo sería una mala forma de llevar un negocio editorial en lo que respecta a escritura y edición (trabajando al nivel de comprensión de “la mayoría de la gente”), sino que incluso en el mejor de los casos, si fuera viable, el editor (o la empresa de software) podría simplemente despedir al especialista y conseguir algunos lectores/usuarios promedio para que den pulgar arriba o abajo a lo que se produzca.

KittenInABox hace 5 días | raíz | padre | anterior | siguiente [–]

No estoy del todo seguro de que eso sea cierto. Hay bastante controversia hoy en día sobre que libros que ahora son populares y queridos en realidad no están muy bien escritos. Escucho esta queja desde que Twilight era popular.

inglor_cz hace 5 días | raíz | padre | siguiente [–]

Seguro, pero un desarrollador profesional es (o debería ser) el equivalente a un lector y crítico más exigente, no solo cualquier cliente en una librería.

coldtea hace 5 días | raíz | padre | siguiente [–]

Exactamente lo que pienso.

vidarh hace 4 días | raíz | padre | anterior | siguiente [–]

No he leído Twilight, pero sí he leído algunos libros queridos y populares que están atrocísimamente mal escritos desde un punto de vista literario. Eso no significa que no sean populares por una razón.

Uno que sí leí, por curiosidad morbosa, es 50 Shades. Es basura absoluta en términos de calidad de escritura. Es trillado, lleno de clichés y extremadamente formulaico (y, de hecho, una fanfic reciclada de Twilight; si te preguntás por las referencias raras al hambre, esa es la razón). Pero si mirás por qué se volvió popular, podés notar que está extremadamente bien construido para su nicho.

Si no querés una “romance con multimillonario” (sí, es un nicho bien definido; hay una razón por la que Grey es descrito como tal) mezclado con el “peligro” de un vampiro transformado en hombre traumatizado con un lado oscuro, es fácil destrozarlo (yo no pude terminarlo; era horrible según los ejes que me importan). Pero como estudio de cómo fusionar impecablemente dos nichos populares dentro de uno de los grupos demográficos compradores de libros más grandes, con expectativas extremadamente predecibles y rígidas, está muy bien ejecutado.

Me cuesta aceptarlo como arte, pero como un tipo particular de oficio, es una obra maestra, aunque deteste ese oficio.

Sin duda también vas a encontrar basura mal ejecutada que se vuelve popular simplemente porque tuvo suerte y tocó una fibra, pero muchas veces me doy cuenta de que, si miro algo que no me gusta y me pregunto qué hizo que resonara con su audiencia, resulta que resonó porque fue construido para tocar exactamente las notas que esa audiencia específica quiere.

Al mismo tiempo, nunca fue el caso que las grandes obras literarias estuvieran aseguradas de tener éxito al publicarse. Moby Dick, por ejemplo, solo vendió 3.000 copias durante la vida de Melville (lo que me hace sentir mucho mejor sobre las ventas de mis propias novelas, aunque no tengo ninguna esperanza de popularidad póstuma) y fue una de sus novelas menos exitosas cuando se publicó. Muchísimos de los medios más populares de la época fueron olvidados hace tiempo por buenas razones. Y así terminamos con un sesgo de supervivencia hacia el pasado, donde vemos siglos de grandes clásicos que resistieron el paso del tiempo y nada de la basura, y los comparamos con basura y arte por igual del presente.

iso1631 hace 5 días | raíz | padre | anterior | siguiente [–]

Tengo muy poco conocimiento de cómo los transistores mueven unos y ceros fuera de los registros. Eso no me impide usarlos para resolver un problema.

La computación siempre ha sido abstracción. Pasamos de cablear a ensamblador, luego a C, luego a lenguajes que manejan memoria por vos —¿cómo diablos podés entender qué debería estar haciendo el compilador o qué está haciendo si no lidiás con punteros explícitos todos los días?

Traemos librerías cuando necesitamos código. No manejamos nuestra propia base de datos, usamos otra cosa y simplemente hacemos apt-get install mysql, pero luego pasamos a docker run o quizá lo invocamos con aws cli. ¿Quién sabe realmente qué hace Terraform cuando declaramos que queremos un recurso?

Pensaba el otro día en cómo abstracciones como AWS o Docker son similares a los LLM. Con AWS hacés clic en un par de botones y tenés un datastore; no sabés cómo construir una base de datos desde cero, ni lo necesitás. Por supuesto, “para construir una base de datos desde cero primero tenés que crear el universo”.

Algunas personas todavía escriben ensamblador a mano con gran beneficio, pero la gran mayoría no lo necesita para resolver problemas, y no puede hacerlo.

Esta reflexión venía de pensar qué hacemos si/cuando los datacenters de AWS no están disponibles. Nuestro personal generalmente es incapaz de trabajar en un entorno que no sea AWS. Algo que hemos cultivado deliberadamente durante años. AWS es una opción, o quizás deberíamos ejecutar un stack no-AWS que poseamos y controlemos completamente.

¿Depender de los LLM es fundamentalmente diferente de depender de AWS, de apt o de Java? ¿Es distinto de tercerizar? Te concentrás en tu competencia central, que es entender el problema y entregar una solución, no gestionar memoria o correr bases de datos. Esto conlleva riesgos —toda tercerización los tiene— y si tercerizar en un único proveedor que no entendés ni podés entender es un riesgo aceptable, ¿entonces por qué depender de los LLM no lo sería?