- ChatGPT y los LLM locales se convirtieron, para programadores experimentados, en herramientas que reducen tareas desgastantes como explorar documentación, aprender APIs complejas y escribir programas descartables, más que en algo para escribir código en sí
- Los LLM no son una inteligencia sobrenatural, sino que interpolan de forma limitada dentro del espacio de sus datos de entrenamiento; aun así, en áreas con muchos datos de calidad, como la programación, son muy útiles como “tontos que saben mucho”
- En problemas cuyo resultado se puede verificar, como transformaciones de tensores en PyTorch, clientes BLE en Objective-C para macOS, interpretación de entradas y salidas de modelos ONNX o scripts de análisis de CSV, GPT-4 reduce mucho el tiempo de trabajo
- En tareas que requieren razonamiento complejo, como programación de sistemas en C e implementación de algoritmos, sus límites quedaron en evidencia al diseñar hashes para Bloom filters y al interpretar el formato de cuantización Q6_K de llama.cpp
- Si gran parte de la programación consiste en repetir patrones existentes con pequeñas variaciones, se vuelven más importantes la capacidad de usar bien los LLM y la de explicar los problemas con claridad
Por qué los programadores experimentados usan LLM
- El objetivo de usar LLM no se limita simplemente a escribir código más rápido
- Buscar documentación poco común
- Aprender APIs excesivamente complejas
- Escribir programas que se descartarán unas horas después
- Encargarse de detalles que no son intelectualmente interesantes
- A medida que Google se convirtió en un espacio de búsqueda con mucho spam, los LLM pasaron a ser una ruta alternativa para obtener rápidamente la información necesaria
- En código de alto nivel como Python aumentó el uso de LLM, pero en código C se usan mucho menos
- La diferencia importante está en distinguir cuándo usar un LLM acelera el trabajo y cuándo, por el contrario, lo vuelve más lento
- Los LLM, como Wikipedia o las clases de YouTube, ayudan mucho a las personas con voluntad, capacidad y disciplina, pero pueden tener límites para quienes van rezagados
Los LLM no son omniscientes ni simples loros
- El funcionamiento interno de las redes neuronales y los LLM sigue siendo bastante opaco
- Algunos expertos en IA subestimaron a los LLM describiéndolos como Markov chains avanzadas o sistemas que repiten variaciones de los datos de entrenamiento, pero esa visión de “loro” fue en gran medida abandonada frente a la evidencia
- Por el contrario, también es incorrecto atribuir a los LLM capacidades sobrenaturales que no existen en la realidad
- Los LLM pueden interpolar de forma limitada dentro del espacio formado por los datos que vieron durante el entrenamiento
- Pueden escribir programas que nunca vieron exactamente
- Pueden mezclar varias ideas que aparecen con frecuencia en los datos de entrenamiento
- Pueden fallar gravemente cuando se requiere razonamiento sutil
- Aun con estas limitaciones, los LLM pueden considerarse uno de los mayores logros en la historia de la IA
Un asistente de programación como “tonto que sabe mucho”
- Los LLM pueden producir razonamientos básicos y a menudo incorrectos, alucinaciones y hechos inexistentes
- Al mismo tiempo, en áreas con muchos datos de buena calidad, como la programación, funcionan como un savant con conocimientos enormes
- Pueden quedarse cortos como compañeros de pair programming, pero son útiles en una estructura donde el usuario hace preguntas y verifica las respuestas
- En el pasado, conocer algunos lenguajes, algoritmos clásicos y bibliotecas esenciales bastaba para hacer muchas cosas
- Hoy la explosión de frameworks, lenguajes y bibliotecas aumentó mucho la complejidad, y en ese entorno un “tonto que lo sabe todo” se vuelve un compañero útil
Casos de éxito en código de alto nivel e interpretación de datos
- Al pasar de Keras a PyTorch, el LLM ayudó a escribir el código necesario para la configuración del modelo sin tener que estudiar la documentación de PyTorch desde cero
- El usuario ya conocía conceptos como embedding o residual network
- Fue eficaz presentar con claridad la estructura del modelo requerida y las preguntas
- GPT-4 observó el modelo PyTorch y el formato de batch, y escribió código para hacer reshape del tensor de modo que coincidiera con la entrada de la red neuronal
- El usuario verificó en la CLI de Python que las dimensiones del tensor y el batch de datos coincidieran
- Al crear un cliente BLE para un dispositivo basado en ESP32, escribió rápidamente código Objective-C para usar APIs nativas de macOS
- Se consideró que, en general, los bindings Bluetooth multiplataforma no eran utilizables
- Fue necesario volver a tratar con la API BLE de Objective-C y con detalles de Objective-C usados mucho tiempo atrás
- El código final está en SerialBTE.m
- Aunque el LLM no escribió directamente la mayor parte del código, explicó la causa de los problemas y cómo resolverlos, acelerando mucho la escritura
- Este programa auxiliar ofrecía poco beneficio en relación con el esfuerzo, por lo que, sin ChatGPT, probablemente ni siquiera se habría intentado
Interpretación de modelos ONNX y escritura de programas descartables
- Al usar una convnet en formato ONNX con poca documentación, el LLM interpretó su funcionamiento a partir de los metadatos de entrada y salida, y de los valores de raw output de una imagen de prueba
- Al principio no se sabía el formato ni el tamaño de la imagen de entrada
- La salida no era una simple clasificación binaria, sino que estaba compuesta por cientos de valores
- ChatGPT supuso que la salida podía ser una normalized box que indicaba posibles zonas defectuosas dentro de la imagen y la probabilidad de defecto
- Tras algunas conversaciones se crearon un script de inference en Python y el código de conversión del tensor de entrada
- En los “programas descartables”, a veces se deja que el LLM escriba todo el código
- Para visualizar la loss curve durante el entrenamiento de una red neuronal pequeña, GPT-4 vio el formato CSV y generó plot.py
- Se le pidió que, al pasarle varios archivos CSV por línea de comandos, comparara la validation loss curve de cada experimento
- Todo el trabajo tomó 30 segundos
- También funcionó al primer intento un programa en pandas que leía un reporte CSV de AirBnB, agrupaba por apartamento, mes y año, y calculaba el alquiler mensual promedio considerando el costo de limpieza y la cantidad de noches hospedadas
- Como escribir este tipo de programas es aburrido y poco interesante, si el LLM se encarga de ellos el usuario puede enfocarse en tareas importantes
Límites observados en C y programación de sistemas
- Al escribir programas en C, el LLM se usa casi siempre solo como una forma más cómoda de documentación
- En programación de sistemas se requiere razonamiento complejo, y los LLM actuales fallan con frecuencia en ese punto
- Cuando se le pidió implementar un Bloom filter, GPT-4 recibió las condiciones de 100,000 elementos y una false positive probability máxima de 5%, pero no produjo una buena implementación
- Usó solo dos hash functions parecidas
- Le faltó la abstracción de crear K hashes suficientemente decorrelated a partir de la misma cadena
- Cuando se le pidió explícitamente crear N outputs decorrelated, propuso una hash function mejor
- GPT-4 pudo escribir una función hash más adecuada al separar el problema en partes pequeñas, pero no aplicó por sí mismo esa idea al diseño completo del Bloom filter
- Este resultado puede verse como el efecto combinado de una capacidad de razonamiento débil, falta de material específico del tema y una mezcla de material de baja calidad
Diferencias entre modelos locales y modelos grandes
- En problemas de programación de sistemas, la diferencia entre modelos pequeños y grandes es clara
- En el mismo problema de hash_id, Mixtral propuso sumar
hash_idal final del resultado del hash, lo que se evaluó como una muy mala solución - El resultado de ejecutar deepseek-coder 34B cuantizado a 4 bits en una MacBook M1 Max fue mejor
- El usuario dio la pista de que sumar
hash_idal final empeoraba la distribución - El modelo identificó que la suma simple podía ser la causa del problema
- Propuso alternativas para mezclar
hash_idmediante bitwise operation como XOR
- El usuario dio la pista de que sumar
- Este caso se acerca a identificar la causa de un problema y proponer una solución de una forma difícil de obtener solo con documentación o búsquedas en Google
- Sin embargo, para un programador de sistemas experimentado, en general los LLM todavía ofrecen muy pocas soluciones satisfactorias
Caso de interpretación del formato Q6_K de llama.cpp
- El proyecto ggufflib es una biblioteca para leer y escribir archivos en formato GGUF, usado por llama.cpp al cargar modelos cuantizados
- Por motivos de velocidad, la codificación de cuantización guarda los bits de cada quant de una forma compleja
- Al principio se intentó entender la codificación con ChatGPT, pero fue mucho más rápido hacer reverse engineering directamente del código de llama.cpp
- Aunque la función era lo bastante pequeña como para entrar en el context de GPT-4, el resultado de reconstruir la documentación del formato de datos a partir de la declaración de la estructura y la decoding function fue inútil
- Al pedirle una explicación del formato Q6_K, tampoco logró explicar con claridad cómo los lower/upper bits se guardan en
qlyqhsegún la posición del weight- Incluso cuando se le pidió una función explicativa con un método de almacenamiento más simple, los índices estaban mal
- También manejó mal la sign extension de 6-bit a 8-bit
- El trabajo terminó resolviéndose con papel y lápiz, lectura de código y seguimiento de los bits que extraía el decoder
- Se espera que este tipo de tarea también pueda volverse posible en unos meses con algo de scaling, sin necesidad de un gran avance
La naturaleza del trabajo de programación y la habilidad para usar LLM
- Gran parte de la programación actual consiste en repetir lo mismo con formas ligeramente distintas, y muchas veces no requiere razonamiento de alto nivel
- Los LLM son bastante fuertes en este tipo de programación repetitiva, pero el límite del tamaño del context sigue siendo una restricción importante
- Vale la pena preguntarse si, dentro de 5 o 10 años, seguirá siendo una buena posición dedicarse solo a escribir tipos de programas que los LLM pueden realizar en parte
- La capacidad de razonamiento de los LLM es débil e imperfecta, pero es difícil explicar los resultados observados si se los considera solo repetidores de palabras
- El objetivo de entrenamiento de predecir el siguiente token fuerza la creación de alguna forma de modelo abstracto, y ese modelo es débil, lleno de agujeros e incompleto
Por qué usar LLM ahora
- Hay pocas razones para no usar LLM en programación
- La capacidad de hacer las preguntas correctas a un LLM se convirtió en una habilidad importante
- La capacidad de explicar un problema con claridad es útil no solo con LLM, sino también al comunicarse con personas
- Muchos programadores pueden ser excelentes en un área específica, pero deficientes en comunicación
- En una situación en la que Google se volvió difícil de usar, los LLM también son útiles como documentación comprimida
- El valor práctico de los LLM está en que permiten aprender menos directamente ese “junk knowledge” como protocolos de comunicación ambiguos o detalles de bibliotecas complejas
1 comentarios
Opiniones de Hacker News
La clave es esta parte: “¿Podría haberlo hecho sin ChatGPT? Claro que habría sido posible, pero lo más interesante no es que me habría tomado más tiempo. La verdad es que, como no valía tanto la pena, ni siquiera lo habría intentado”.
En la asistencia para programar, el verdadero potencial de los LLM está en bajar la barrera de entrada para iniciar tareas nuevas, haciendo que cosas que se habrían quedado indefinidamente en la pila de proyectos futuros realmente se tomen y se terminen.
Internet y el open source tuvieron un efecto parecido: con el tiempo, proyectos que te interesaban pero que no hacías tú mismo terminaban siendo abordados por alguien que resolvía lo suficiente de un problema similar como para que pudieras reutilizarlo o adaptarlo, y eso produjo una explosión de apps y librerías útiles.
Coincido con el autor en que los LLM por sí solos no son tan capaces, pero para alguien con habilidades básicas y motivación funcionan como amplificadores.
Luego me doy cuenta de que se pueden hacer con mucho menos esfuerzo del esperado.
Intercambiar ideas con la persona adecuada puede tener un efecto similar, pero no hay alguien que, sin necesidad de conocer por completo el dominio del problema pero sí lo suficiente como para aportar algo significativo, esté disponible 24/7 a un clic.
Me ayudaron con algunas cosas, pero normalmente, cuando llego a un punto en el que no sé lo que estoy haciendo, el modelo tampoco parece saberlo mejor que yo.
Fuera de eso, me cuesta formular prompts más rápido que escribir el código directamente.
Me pregunto si soy yo el que no sabe usar estas herramientas.
Conocía bastante la librería ow2 asm, pero me ahorró mucho tiempo de buscar para recordar el formato exacto de los descriptores.
También me ayudó a entender por qué otras librerías de análisis estático no me servían lo suficiente debido a la forma en que manejan el estado.
Para mí, ChatGPT hace dos cosas: reduce búsquedas triviales en StackOverflow y exploración de código de librerías para responder preguntas específicas, y en la etapa de investigación previa al proyecto me ayuda a evaluar la viabilidad del enfoque que voy a tomar.
Cuando tienes TDAH severo, las tareas simples son las más difíciles, y hasta sacar la basura o abrir el correo puede ser casi imposible.
El diálogo en tu cabeza puede gritarte durante horas que simplemente hagas esa tarea, pero el cuerpo no responde.
A eso se le llama disfunción ejecutiva, pero en mi vida es un verdadero problema.
Que un LLM solo logre hacerte empezar ya es algo enorme.
En cuanto a programación, estoy totalmente de acuerdo.
El punto ideal para usar LLM es cuando ya sabes lo suficiente del tema como para verificar el resultado, y también lo suficiente como para explicar en detalle —idealmente de forma concisa— lo que quieres.
Te permite hacerlo más rápido, te lleva a hacer cosas que de otro modo no habrías hecho y ayuda mucho a crear programas pequeños pero valiosos que puedes desechar sin problema.
Otra área en la que me resultó muy útil fue la exploración de temas completamente nuevos, sean de programación o no.
Basta con decir que no sabes mucho, que no necesitas necesariamente detalles concretos, pero que quieres hablar de esto y que te ayude a ordenar tus ideas.
Es especialmente útil si eres alguien dispuesto a investigar más o hacer más preguntas a partir de lo que escuchas.
La puerta de entrada a muchos campos está en entender la terminología básica, escuchar qué distinciones hace la gente y por qué, y saber quiénes son las autoridades en el tema.
Puede terminar pinchando una y otra vez hasta producir un monstruo que no entiende, con tal de que compile.
Quien está aprendiendo necesita ayuda, pero la ayuda que da un LLM en forma de Copilot no es la adecuada.
Sería interesante entrenar un modelo tipo Copilot diseñado como un compañero que haga preguntas de aclaración y defina la solución junto contigo, en vez de intentar generar código a toda costa a partir de preguntas vagas o mal especificadas de un junior.
Cada vez me dio premisas sutilmente incorrectas o directamente alucinadas, y me hizo perder tiempo hasta que me di cuenta de que estaban mal.
Si no fuera por esa actitud de confianza injustificada en respuestas incorrectas, podría decir que no es mucho peor que hilar lo que ya sé; pero por ahora me parece bien como reemplazo de un rubber duck o de autocompletado.
Me gustaría entrar al sitio web de un lenguaje nuevo y tener un LLM con el que pueda conversar sobre su documentación y hacer preguntas para entenderla mejor.
Sería aún mejor si estuviera entrenado con ejemplos reales de código de ese lenguaje o framework, y pudiera ayudarme ahí mismo a escribir un programa o una función nueva.
Si además estuviera conectado a un REPL en línea y ayudara en línea, sería una ventaja aún mayor.
Creo que el aspecto más subestimado de los LLM es el rol de desarrollador que lo sabe todo, algo que el texto toca pero no aborda directamente.
Por más senior que sea un programador, tarde o temprano se enfrenta a tecnologías de las que casi no sabe nada.
Todos somos juniors en algún ámbito.
Incluso si eres un dios de Win32, C++ y COM, puedes quedarte atorado con los crípticos scripts de NSIS al empaquetar software.
Aunque hayas creado apps web durante 25 años y hayas formado parte del comité del lenguaje PHP, si te encargan implementar un estándar ISO críptico para comunicarse con redes de tarjetas de crédito, puede que nunca te hayas comunicado con redes de tarjetas de crédito a ese nivel.
Aunque hayas creado apps de iOS desde el primer iPhone, antes de eso apps para Mac, hayas trabajado varios años en Apple y te sepas de memoria la mayoría de las API de iOS e incluso hayas diseñado algunas, si te encargan implementar soporte para CalDAV en una app, puede que ni siquiera sepas qué es CalDAV.
En estas situaciones, un LLM puede ayudar y, aunque no pueda escribir todo el código por ti, al menos puede llevarte en la dirección correcta.
Después de llenarte la cabeza con otras tecnologías, llega un momento en que tienes que volver a recordar y repasar cosas que aprendiste antes pero que quedaron desplazadas por tecnologías nuevas.
Es una sensación extraña.
De forma natural vas siguiendo la mediana de lo que hace la empresa donde trabajas, hasta que te encuentras en una situación en la que piensas que hace “un buen rato” no tocas CSS.
Puede que necesites estudiar el fin de semana para recuperar la intuición sobre las dataclass de Python.
Si algo se puede encontrar en Google, es probable que un LLM lo encuentre más rápido, mejor y te lo organice.
Por suerte, para entonces probablemente yo ya esté jubilado.
Me sorprende la tendencia de “escribí la mayor parte del código copiando y pegando desde ChatGPT”.
Me sigue impactando que tanta gente tolere un flujo de trabajo tan doloroso.
El autor original claramente no es un principiante que programa por encima de sus conocimientos con GPT, sino un ingeniero experimentado.
Uno esperaría que alguien así se preocupara por el flujo de trabajo de programación y por la usabilidad y eficiencia de sus herramientas, pero aun así mucha gente tolera estar copiando y pegando código constantemente entre GPT y archivos locales.
Este flujo de trabajo frustrante fue lo que me llevó a crear aider al principio.
aider comparte tu repositorio git local con GPT para que el código nuevo y las modificaciones se apliquen directamente a los archivos.
También comparte con GPT el contexto de código relevante, de modo que pueda escribir código que se integre con el proyecto.
Así, no solo permite código aislado fácil de copiar y pegar, sino también contribuciones más sofisticadas.
En consecuencia, se convierte en un flujo de trabajo fluido de programación en pareja, donde GPT y yo editamos archivos juntos mientras conversamos.
https://github.com/paul-gauthier/aider
Pero ¿hay alguna forma de usarlo solo para conversar sobre el código?
Uso los LLM para conversar sobre las ventajas y desventajas de distintos enfoques o para destrabar problemas como con un patito de goma.
Para eso tengo que copiar el código, pero aider está enfocado en aplicar cambios, así que no me resultó muy adecuado para ese uso.
Por lo general, solo después de varias idas y vueltas sobre cuál es el enfoque correcto decido si aplicar un cambio o no.
Es el creador de Redis.
Si ya estás pagando la suscripción, tiene sentido copiar y pegar en vez de pagar un costo adicional por la API.
Además, cada persona tiene un criterio distinto sobre si la mejora de eficiencia vale lo suficiente como para depender del proyecto de otra persona, y esos proyectos también corren el riesgo de volverse pagos o quedar abandonados.
El primer archivo real con el que lo intenté era demasiado grande y explotó; el segundo archivo real seguía siendo demasiado grande.
Me sorprendió que aider aparentemente no pudiera dividir archivos grandes para ajustarlos al límite de tokens.
El límite de tokens de GPT no alcanza para archivos fuente tan grandes.
Si tengo que elegir el archivo en el que voy a trabajar y además hacerle cirugía para que GPT no vomite, no sé si me ahorra tiempo frente a usar Copilot en el IDE.
Al principio pensé que el aporte central de aider era manejar el problema de “tamaño del código ≫ límite de tokens”, pero parece que no era así.
Me gustaría volver a intentarlo, pero aider cae en la categoría desfavorable de “tener que encontrar un problema y una base de código lo bastante simples como para que aider pueda manejarlos”.
En cambio, Copilot y ChatGPT vienen todos los días a ayudarme justo donde estoy, con bases de código reales del trabajo real, incluyendo sus defectos.
Creo que, con sus funciones actuales, cubre muy bien los casos de uso de chat y confirmación.
Puede que los comentarios aquí no reflejen el alto nivel de satisfacción de la mayoría de los usuarios de software.
Aider ayuda a ejecutar en la práctica el caso de uso que antirez describe en el texto.
Especialmente a medida que uno mejora, como dice antirez, en hacerle las preguntas correctas al LLM.
Durante los últimos días estuve tratando de corregir un bug en una app cerrada para Mac.
Me gusta esa app, pero este bug me ha vuelto loco durante años.
Estaba bastante seguro de qué método de Objective-C causaba aproximadamente el bug, pero no sabía qué hacía ese método y la versión descompilada era un desastre sin sentido.
Sentía que me había topado con una pared.
Entonces metí en GPT-4 el ruido que escupió el descompilador y le pedí que lo convirtiera en una versión limpia.
El resultado no fue perfecto, pero pude ordenarlo, y al hacer swizzling de ese resultado en la app, parece que el bug desapareció.
Nunca encontré pasos para reproducirlo, pero normalmente para este momento ya habría ocurrido el problema.
Sin GPT-4, jamás habría podido hacerlo.
Claro, si reescribes por completo un fragmento de código, aunque uses un LLM sin entender qué hace, es poco probable que tenga el mismo bug que la implementación original.
Pero podría introducir otros bugs, y espero que nadie haga algo así en código donde las consecuencias de un bug sean importantes, como caídas del sistema o costos para clientes.
Este artículo me dejó totalmente impactado
Salvatore es uno de los ingenieros de software más capaces en actividad hoy
Él puede ver con toda claridad que esta supuesta herramienta es completamente inútil en su área de especialidad
Aun así, en vez de descartarla como un destornillador torcido e inadecuado, acepta la premisa de sus defensores de que hay que encontrarle alguna utilidad como sea
Como se aprende en una clase introductoria de macroeconomía, si una isla es superior produciendo el widget A, entonces, por pésima que sea la capacidad de la otra isla para producir B, surge una especialización en la que la isla A aprovecha a la isla B
Por eso es natural que la capacidad relativa de antirez en programación de sistemas empuje a los LLM hacia otras tareas de programación
Pero no existimos aislados
A nuestro alrededor hay muchísimos humanos que quieren desafíos técnicos y comida
Muchos de ellos tienen, o pueden adquirir, habilidades complementarias a las nuestras
Si trabajamos juntos, el resultado de la cooperación puede superar la suma de las partes
Tal vez un LLM pueda escribir código PyTorch mejor que antirez
Pero que tengas un destornillador viejo y torcido en el garaje no significa que tengas que usarlo
Quizá hoy convenga más ir a la ferretería
Porque la sintaxis exacta o la remodelación de tensores no me importan demasiado
Si es para uso personal, para crear y entrenar una convnet con mis imágenes, no necesito molestar a un experto en Torch
Si entiendo lo suficiente la convnet en sí, pero no conozco lo suficiente la sintaxis o los métodos de Torch, puedo hacerlo por mi cuenta
La alternativa es estudiar los detalles del manual de Torch, y el resultado sería el mismo
Lo importante en esta tarea no son los detalles de MLX, Keras o PyTorch, sino controlar los conceptos de aprendizaje automático
Ahora son útiles hasta cierto punto, pero cuesta decir que realmente lo sean, y tampoco te “quedas atrás” por no usarlos
Como todos los involucrados están haciendo todo lo posible por volverlos más capaces, cuando llegue ese día bastará con pedirles por prompt lo que quieras
No hace falta apurarse a exprimir algo a la fuerza de la generación actual, y por ahora muchas veces reducen la productividad en vez de aumentarla
Hasta me pregunto si leímos el mismo texto
Él mira una herramienta nueva que a otros les pareció interesante, encuentra formas de usarla que le resultan útiles y, al mismo tiempo, reconoce dónde no sirve
También fundamenta bastante bien ejemplos en los que sí le sirvió
No es una revelación especialmente revolucionaria para un desarrollador
Siempre usamos distintas herramientas, como lenguajes de programación, y cada una tiene fortalezas y debilidades
No veo por qué los LLM tendrían que ser tan distintos
Afirmar que no tienen ninguna fortaleza me parece tonto
¿Se puede hacer eso por menos de 20 dólares al mes?
Al empezar un proyecto nuevo hay un problema de impedancia
Al principio el trabajo está 0% terminado y hay que empezar por algún lado, sea un hello world, un archivo CMakeLists o un script de Python, y eso cuesta
Antes de ChatGPT/LLM tenía que sacar ese esfuerzo de mí mismo hasta la punta de los dedos
Ahora puedo encargárselo a ChatGPT
En realidad es menos eficiente y menos potente que “sentarme y hacerlo yo mismo”, pero elimina el costo de “decidir sentarme a hacerlo yo mismo”
De todos modos, sigue siendo copiar y machacar fragmentos tomados de búsquedas de código en GitHub, StackOverflow, publicaciones aleatorias de blogs, documentación, Discord, etc.
Después de algunos intentos y reintentos aparece un punto de partida del 5% del proyecto y, cuando por fin empieza a tomar forma, puedo trabajar de verdad
Al final voy copiando y pegando rápidamente las pruebas de concepto superficiales y basura que escupe ChatGPT, y cuando ya hay suficiente impulso paso a meterme yo directamente
Así que es más lento e ineficiente, y ChatGPT tampoco lo hace mejor que yo, pero es más fácil y no tengo que excavar tan hondo
Al final puedo aguantar mucho más en las partes realmente importantes del proyecto, el medio y el final, y no me quemo al principio
¿Estaba haciendo las preguntas correctas desde el principio? Y si no, ¿se puede rescatar ese trabajo de manera efectiva?
El costo hundido desaparece dentro de la suscripción de 20 dólares
Creo que la idea clave es esta parte: “tengo un problema, y si el LLM dice tonterías necesito poder saberlo rápido para verificarlo. En esos casos uso el LLM para acelerar la velocidad a la que obtengo el conocimiento necesario”
Una de las razones por las que la programación encaja especialmente bien con los LLM es que verificar la respuesta correcta suele ser trivial
Estoy experimentando con el concepto de evaluar si un LLM es la herramienta adecuada para una tarea
Algo así como graficar “qué tan importante es que la salida sea correcta” frente a “qué tan fácil es verificar si la salida es correcta”
Hacer con ChatGPT una lista de canciones en las que participó una artista mujer ganadora de un Emmy requiere tiempo para verificar la exactitud, pero la importancia también es baja y no pasa nada si hay algunos errores
¿Entonces el software no tiene ningún bug?
Son problemas en los que se hace difícil pensar la solución, pero es fácil verificar una solución posible
Y todos sabemos cómo se llama esa clase de problemas
El mundo ya está lleno de textos irrelevantes e inexactos, y sería mejor reducir su producción en vez de acelerarla
No hablo de ese ejemplo específico, sino de la idea en general
Uso ChatGPT como compañero de razonamiento para escribir código
Paso todo el día conversando con él para terminar el trabajo
La empresa aprobó Copilot, pero el autocompletado de Copilot fue una experiencia horrible
La empresa no aprobó Copilot Chat, que es lo que necesito
Aun así, me gustaría tener una herramienta similar que, en mi laptop, genere pruebas unitarias o comentarios de código sobre mi propio código
Claro, siempre con mis entradas y mi guía
Mis compañeros lo elogiaban mucho, así que pensé que quizá el raro era yo, pero me distraía muchísimo y lo desactivé a los pocos días
Se sentía como si alguien intentara terminar mis frases cuando yo todavía estaba hablando
Incluso cuando acertaba me irritaba, me rompía el flujo y se equivocaba muy seguido
[0] https://continue.dev/
[1] https://ollama.ai/
Hace unos días probé Codeninja
Si mal no recuerdo, no está ni cerca del 4 que corre el backend de Copilot, pero para datos sensibles que no deben salir al exterior es básicamente la única opción
O quizá se podría conseguir una instancia dedicada de OpenAI
Esta puede ser la parte más importante del artículo, y pensando en lo que se viene en 2024, es algo que no está de más repetir una y otra vez
“Entonces, ¿hasta qué punto los LLM tienen capacidad de razonamiento, o todo es puro humo? Como dirían los semiólogos, puede que a veces parezcan razonar porque el ‘significante’ da la impresión de un significado que en realidad no existe. Pero quienes han trabajado lo suficiente con LLM saben, aun aceptando sus límites, que eso por sí solo no alcanza para explicarlos. Su capacidad de mezclar cosas que ya vieron va mucho más allá de repetir palabras al azar. Aunque la mayor parte del entrenamiento se haya hecho durante el preentrenamiento prediciendo el siguiente token, ese objetivo obliga al modelo a construir alguna forma de modelo abstracto. Ese modelo es débil, tiene muchos huecos y es incompleto, pero si observamos lo que observamos, necesariamente debe existir. Si la certeza matemática es dudosa y hasta los máximos expertos suelen ubicarse en bandos opuestos, parece sensato confiar en lo que uno ve con sus propios ojos”