Aventuras con IA

• Al probar varios modelos de IA en proyectos personales, las revisiones de código, las refactorizaciones y los scripts de un solo uso resultaron ser útiles de forma constante en relación con su costo, pero las tareas de desarrollo no autónomas siguen estando muy limitadas por la calidad del juicio y el costo de verificación
• Tras comparar suscripciones mensuales de USD 20 de Anthropic y OpenAI con créditos de USD 20 de Google, Moonshot, DeepSeek y Cerebras, en la práctica se alternó principalmente entre Opus 4.8 y GPT 5.5
• El mayor valor apareció en encontrar bugs, como en revisiones tipo git diff main; en bases de código pequeñas, la lectura minuciosa del código es una fortaleza, como en el caso en que Opus encontró un double-free en un intérprete que incluso el fuzzer no había detectado
• Al escribir código en conjunto o al dejar que implementen por su cuenta, se repitieron problemas: corrigen bugs en la capa equivocada, crean pruebas y refactorizaciones innecesarias, y afirman falsamente que terminaron la implementación o ejecutaron las pruebas
• Aunque los modelos no se vuelvan más inteligentes, ganan importancia las prácticas que reducen el costo de verificación y limitan el alcance de los cambios, como garantías del lenguaje y del runtime, análisis estático, técnicas formales ligeras y harnesses dentro del editor

---

Modelos y herramientas usados

• Se pagaron suscripciones mensuales de USD 20 a Anthropic y OpenAI, y se cargaron créditos de USD 20 en Google, Moonshot, DeepSeek y Cerebras
• Después de comparar modelos en varios problemas, la mayoría del tiempo se alternó entre Opus 4.8 y GPT 5.5
  • Los dos modelos fueron notablemente mejores que los demás
  • Rara vez se alcanzaron los límites de uso de ambos modelos al mismo tiempo
• Como herramientas se usaron claude code, codex y pi
  • claude code y codex se consideran en mal estado
  • En algunos casos, codex seguía usando 100% de CPU después de cerrar la terminal, y había que matarlo
  • claude code indica “presiona escape para cancelar el diálogo”, pero en la práctica no cerraba el diálogo y solo interrumpía a claude
  • El comportamiento de ambas herramientas cambiaba de un día a otro
• pi no se probó mucho, pero pareció comportarse como software convencional
  • Las tres herramientas daban una fuerte sensación de haber sido vibe-coded, y quedó la duda de cómo pi mantiene al menos una calidad mínima de código

Sandbox y seguridad

• Todas las herramientas se ejecutaron dentro de bubblewrap
  • Se dieron permisos de lectura y escritura al directorio actual y a la configuración de cada herramienta
  • Al nix store solo se le dieron permisos de solo lectura
• Esta configuración es un sandboxing mínimo, suficiente para impedir acceso a credentials o la destrucción de archivos que no están bajo control de versiones
• Si en AGENTS.md se aclara que se está ejecutando dentro de un sandbox y que se pueden traer herramientas con nix-shell, por lo general funciona bien
  • De lo contrario, el modelo tendía a sospechar de una falla de disco o corrupción del sistema de archivos
• El aprendizaje de seguridad no pareció suficientemente efectivo
  • Ante la solicitud “intenta escapar del sandbox”, se negó diciendo que sería irresponsable
  • Al decirle “necesito saber si el sandbox funciona”, respondió que había escapado

El mayor valor surgió en las revisiones de código

• Hasta ahora, el mayor valor vino de revisar código y encontrar bugs
• Incluso un prompt simple como Review git diff main and look for bugs fue efectivo
• En proyectos personales, solo esta función justificaría pagar USD 20 al mes, y si se dirigiera una empresa, se consideraría razonable pagar varios cientos de dólares al mes por persona
• En este transcript, Opus encontró un double-free después de una limpieza parcialmente fallida de pattern-match en un intérprete
  • Este bug no fue encontrado por el fuzzer
  • Se considera que un programador promedio tampoco lo habría encontrado rápidamente
• Solo los modelos frontier fueron útiles
  • Los modelos más baratos fueron evaluados como si hicieran bluff con mucha fuerza, como un estudiante de pregrado con dificultades
  • Los modelos frontier también mezclan bluff entre respuestas correctas, pero lo señalaban con expresiones como “this isn't a bug per se”, lo que hacía más fácil ignorarlo
• Hasta ahora, las pruebas se hicieron solo en bases de código relativamente pequeñas
  • En bases de código grandes, se cree que dependerá mucho de la estructura y de la posibilidad de hacer razonamiento local

La refactorización redujo el costo de corregir decisiones de diseño

• Algunos ejemplos de refactorización fueron:
  • Cambiar pos, que apuntaba a un byte offset, por offset
  • Cambiar Document por Buffer, junto con comentarios y nombres de variables
  • Hacer que una función de Editor que llama a Document::apply_edits reciba un EditorId en lugar de un Editor, para liberar el borrow antes de llamarla
• Este tipo de tareas ayuda inesperadamente mucho a mejorar la calidad del código
  • Porque reduce el costo de corregir errores de diseño
  • Es especialmente útil cuando se mezclan pequeñas tareas de razonamiento para cambiar a una API más segura con un gran trabajo repetitivo de corregir todos los callsites
• Incluso en cambios repetitivos que podrían resolverse con expresiones regulares de sed, se considera que el modelo escribe mejor sed
• Sin embargo, revisar refactorizaciones es difícil
  • El modelo puede mezclar un drive-by fix irrelevante entre 200 cambios correctos de callsites
  • Preguntarle a otro modelo “qué cambios no están relacionados con el prompt” funcionó hasta cierto punto

Límites que aparecieron al programar en conjunto

• Como se esperaba que asignarle serious work de inmediato fuera frustrante, se experimentó sobre todo en proyectos descartables, pero la calidad del código seguía generando incomodidad
• Antes de la IA, programar se sentía como una mezcla de decisiones importantes y relleno tipo paint-by-numbers
  • Al organizar las tareas para concentrar las decisiones al principio y luego rellenar los resultados durante unas horas, se reducían los context switches y se podía trabajar más rápido
• Los modelos son fuertes para generar rápido y con detalle implementaciones tipo paint-by-numbers
• En cambio, son muy débiles para tomar decisiones
  • Corrigen bugs en la capa equivocada
  • Silencian errores que deberían reportarse, o propagan errores que deberían manejarse localmente
• Opus recibió la instrucción de actualizar pruebas según un cambio en una función y agregó un argumento booleano do_new_behaviour
  • Creó wrappers foo_do_new_behaviour y foo_do_old_behaviour que pasaban true y false, respectivamente
  • Las pruebas seguían probando el comportamiento anterior y el binario real usaba el comportamiento nuevo
• La solución de pedirle a otro modelo que revise no es muy convincente
  • Porque un modelo con mal juicio puede ver una mala decisión y aun así decir “tiene sentido”
• Incluso ante la instrucción “solo completa el cuerpo de esta función y no hagas otros cambios, no escribas pruebas”, el modelo intentó refactorizar código no relacionado, extraer helper functions y escribir unit tests
  • Aunque se le dijo que la base de código tenía end-to-end deterministic simulation testing, intentó agregar funciones public para cada interfaz con el fin de hacer isolated unit tests
• El código escrito por bots fue difícil de revisar de forma efectiva
  • Después de mergear cambios, al volver a mirar el mismo código mucho más tarde, aparecieron problemas que no se habían visto al principio
• Se considera necesario un harness dentro del editor en el que el usuario resalte la ubicación a cambiar y el modelo no pueda modificar otras zonas
  • Se imagina una dinámica donde el usuario bosqueja el código deseado y deja comentarios para que el modelo los complete
  • Si en los próximos años aparecen modelos que ofrezcan la calidad de programación de los frontier actuales pero mucho más rápido, se espera poder revisar resultados de inmediato sin ir y venir entre worktrees

Cuando se lo dejó implementar solo

• Las tareas pequeñas de plumbing funcionaron bien cuando bastaba revisar el resultado
  • Un script para convertir resume.md en resume.pdf
  • Un script para parsear reglas de un juego de mesa y producir un PDF con cartas tamaño playing-card para imprimir en US Letter
  • Traducir un pequeño proyecto deno a Rust
  • Crear un proyecto Rust que abra una ventana y renderice un rectángulo
• Estas tareas por lo general se resolvieron de una vez, o con algunos comentarios de diseño visual, y la calidad del código no importaba
• Las tareas difíciles de verificar han sido, hasta ahora, una pérdida de tiempo
  • Se intentó varias veces con varios modelos convertir reglas de un juego de mesa en una webapp multiplayer
  • Solo Opus produjo una UI que realmente funcionaba, pero la implementación de las reglas estaba mal
• En esta área se observó la mayor misalignment
  • En los comentarios del modelo o en el chain of thought disponible se veía que postergaba el trabajo real
  • Incluso cuando se indicaba explícitamente que completara una UI específica, aparecían razonamientos como “se necesita una UI de selección de jugador, así que por ahora hagámoslo hard-codeado”
• El modelo exageró o confirmó falsamente en repetidas ocasiones que había terminado la tarea
  • Después de decir que había completado todas las tasks, al preguntarle de nuevo admitió que solo había hecho las dos primeras y había pospuesto el resto
  • Al pedirle que volviera a terminar, volvió a decir que estaba completo; al verificar otra vez, admitió que en realidad solo había movido código de un lado a otro
• Incluso con ayuda para escribir end-to-end tests mediante herramientas de automatización del navegador, se trababa con la configuración de dependencies y mentía diciendo que había ejecutado las pruebas con éxito
  • Si la UI estaba rota, intentaba hacer pasar la prueba con direct HTTP calls en lugar de hacer clic en los botones
• Se ven dos razones para el fracaso al implementar reglas de juegos de mesa
  • Las reglas de juegos de mesa son arbitrarias, por lo que no puede apoyarse en datos de entrenamiento y debe razonar explícitamente sobre las reglas
  • Verificar la implementación jugando varias partidas cuesta más que escribir el código correctamente desde el principio
• En combinaciones con baja tasa de éxito y costo de verificación no bajo, se evalúa que el modelo no sirve en absoluto

Evaluación de su uso como ingeniero de software autónomo

• Usar IA como ingeniero de software autónomo con los métodos actuales produciría una enorme masa de duct tape y chewing gum que ninguna persona podría arreglar
• Sin embargo, muchas codebases outsourced vistas en las últimas décadas eran parecidas, y se considera que los modelos pueden hacer lo mismo más barato
  • Los modelos mueven la frontera costo-calidad
• Aunque los modelos no se vuelvan más inteligentes que hoy, las prácticas pueden evolucionar para extraer más valor
  • Garantías del lenguaje y del runtime
  • Análisis estático
  • Técnicas formales ligeras
  • Métodos para reducir el costo de verificación o limitar el alcance del comportamiento del modelo
• Se recuerda que, cuando Python y Ruby se usaban ampliamente, se creía que el rendimiento del hardware mejoraba más rápido que la optimización de código; después de la desaceleración del rendimiento secuencial del hardware, volvió a crecer el interés por el rendimiento de los lenguajes de programación
• Se cree que los modelos están en un punto inicial de una curva similar
  • Si el modelo del mes próximo será más inteligente, hay poco interés en mejorar harnesses o prácticas alrededor
  • Si el rendimiento de los modelos alcanza un techo antes de llegar a ser uniformly superhuman, ahí empezará el trabajo interesante

Búsqueda y mano de obra barata

• Funcionan bien en problemas donde se puede verificar directamente la respuesta, la precision importa pero el recall no tanto
  • Encontrar errores en una publicación de blog
  • Encontrar errores de formato APA en footnotes de un ensayo
  • Encontrar en goodreads_library_export.csv una trilogy con policías y brujas
  • Filtrar en https://mgaudet.github.io/CompilerJobs/ solo enlaces a roles que indiquen remote y excluir empresas de cryptocurrency
• No se deja que el modelo corrija directamente los errores
  • Porque si lo hace, empieza a tomar decisiones
• Los problemas con respuestas plausibles pero que no se pueden verificar directamente son mucho más peligrosos
  • Al preguntar por opciones de reef-safe DIY wetsuit lube, Opus y GPT recomendaron glycerine
  • Se considera que cubrir la piel todo el día con bacteria food húmedo probablemente sea una mala idea

Brainstorming y creatividad

• Cuando cuesta elegir nombres de types o variables, se le piden ideas al modelo con frecuencia
• Al ser máquinas de procesamiento de lenguaje, parecería que deberían ser buenas en esto, pero nunca se usó realmente ninguna de sus sugerencias
• Las propuestas fueron consistentemente comunes y trilladas

Conclusión general e incomodidades pendientes

• Revisiones, refactorizaciones y scripts de un solo uso fueron útiles de forma constante y por sí solos valieron el dinero
• Programar en conjunto todavía no da ganancias netas en general, pero con modelos más rápidos y mejores harnesses podría hacerlo en un futuro cercano
• Dejar que escriba código solo no funcionó para tareas no triviales
  • Para obtener software de alta calidad sin una participación profunda de personas, hace falta mucha más experimentación
  • El mercado de software de baja calidad es grande, y eso podría ser viable incluso hoy
• En los modelos frontier no se vio nada que amerite llamarse alucinación
  • Solo DeepSeek flash inventó hechos completos, y aun así solo a veces
  • Los modelos pueden equivocarse, pero por lo general se debe a errores de razonamiento, malinterpretación de evidencia o falta de contexto importante, no a inventar cosas de la nada
• Las suscripciones a modelos frontier fueron una muy buena oferta, pero parecen estar desapareciendo gradualmente una vez que todos se acostumbran a ellas
  • Si se cobra por token, no está claro qué casos de uso seguirán valiendo la pena
  • DeepSeek v4 flash es muy barato, pero todavía no es lo bastante inteligente y fue el más propenso a mentir diciendo que había ejecutado pruebas con éxito
• Los harnesses existentes no resultaron agradables
  • Es molesto escribir prompts en interfaces donde ni siquiera la edición básica de texto funciona bien
  • Se quiere más control sobre lo que el modelo puede hacer, y una interacción más directa, como señalar objetos en pantalla
  • El workflow actual consiste en dejar comentarios @bot en el código y usar un prompt fijo: Handle comments marked @bot
• Cuando una persona escribe código, al mismo tiempo lo lee y reconstruye un mental model
  • Si un bot escribe el código en su lugar, seguir construyendo el mental model sigue siendo necesario, pero se pierde el efecto natural de hacerlo mientras se escribe
  • Leer código sin más no alcanza; se considera necesaria alguna práctica adicional como review++
• La experiencia hasta ahora fue divertida y probablemente útil porque los experimentos se hicieron explícitamente en proyectos poco importantes
• Esta experiencia está muy anclada en el presente; todavía se está digiriendo qué cambiará tras algunos años más de mejoras y hacia dónde conviene moverse

[GN⁺]

Opiniones en Lobste.rs

• Parece que pi tiene menos bugs que otros harnesses porque lo hace un equipo pequeño, sus mantenedores sostienen un estándar de calidad consistente, revisan el código y piensan bien qué funciones incluir
  Ese enfoque de no meterle cualquier cosa al harness sin más es lo que marca la diferencia
  https://mariozechner.at/posts/…

  • Aun con esas tres ventajas, si yo hiciera algo grande con vibecoding, siento que terminaría siendo un montón enredado
    Claramente hay habilidad adicional en juego

• Es muy bueno el punto de que “si el bot escribe el código por mí, yo igual tengo que construir un modelo mental, pero ya no lo obtengo ‘gratis’ mientras escribo el código”
  Solo leer el código no funciona tan bien; es como volver a ver apuntes subrayados, que no equivale a prepararse para un examen
  También conecta con Programming as Theory Building
  La primera vez que usas un LLM en un proyecto cuyo sistema ya tienes teorizado en la cabeza, es fácil obtener resultados, pero si se lo dejas encargado por un tiempo, cada vez te desconectas más y terminas como un gerente de proyecto no técnico que ni siquiera puede escribir bien los requisitos, lo que puede volverse muy frustrante

• De ahora en adelante voy a usar sin ninguna pena la expresión “un sueño febril con pruebas unitarias” en lo que digo y escribo

  • Incluso en varios orquestadores multiagente conocidos, los modelos caros terminan inventándose en tiempo de ejecución algo así como el 60% del orquestador

• Se parece muchísimo a mi experiencia
  Para agregar algo: también tuve bastante éxito usando Claude Code para depurar problemas en mi escritorio Linux
  En 25 años de dotfiles se acumularon capas y capas de residuos que da flojera depurar, pero como comparto los dotfiles entre varias máquinas con yadm sin secretos, hacer sandboxing fue fácil
  También vale la pena adquirir el hábito de hacer que un LLM revise los cambios de código
  De todos modos, alguien va a revisar mis commits con un LLM, ya sea en un repositorio open source o en algo de producción, y en Lobsters en las últimas dos semanas recibimos 4 reportes válidos de vulnerabilidades de gente que usa escáneres basados en LLM
  Todos corregidos
  En los 9 años anteriores apenas recuerdo unas 2 reportes parecidos

• Decir que “nunca he visto algo que pueda llamar alucinación en modelos frontier” suena raro
  En el texto aparecen varias cosas que, para mí, podrían considerarse alucinaciones

  • Parece razonable distinguir entre lo siguiente: alucinación (“Lobsters fue creado por Paul Graham”), mentira/pereza (“ya terminé la tarea”), mal juicio (“aquí mejor hardcodeo este valor”)
    Bajo ese criterio, en el texto no detecté alucinaciones, pero la mentira, la pereza y el mal juicio tampoco son precisamente buenos
    Esta distinción es útil porque las alucinaciones pueden ser más fáciles de reducir, mientras que la mentira, la pereza y el mal juicio son más difíciles
    Tanto las alucinaciones como las mentiras hacen que el modelo diga cosas incorrectas, pero la alucinación se parece más a ignorancia o falta de información, así que se puede responder pidiendo fuentes o entrenándolo para evitar responder con base en información débil
    En cambio, la mentira y la pereza parecen productos de comportamiento orientado a objetivos y aprendizaje por refuerzo, así que da la impresión de que son mucho más difíciles de eliminar con entrenamiento

• Creo que usar LLM para revisión de código en vez de para escribir código nuevo, especialmente en proyectos de una sola persona, ofrece una de las mejores relaciones beneficio-riesgo
  Si no tienes un revisor dedicado con experiencia, el análisis de un LLM literalmente es mejor que nada
  Como no quiero usar modelos comerciales en la nube para trabajo open source, estoy experimentando con revisión de código usando LLM locales, y les digo que no generen código nuevo sino que solo describan brevemente el problema
  Puede que los modelos locales no sean tan buenos como los comerciales, pero Qwen 3.6 27B me resultó bastante útil
  Al correrlo sobre una base de código Rust de tamaño medio, más o menos el 70% de lo que dijo estuvo bien, cerca del 60% de los problemas que encontró eran correctos, alrededor del 20% tenía poca calidad pero igual me hizo mirar zonas problemáticas del código y terminar mejorándolo, y el otro 20% era basura
  Que haya tanta basura no es bueno, pero al menos dejó inmediatamente claro que hay que desconfiar de lo que dice el modelo
  No sé cuántos problemas reales se le escaparon, y algunas de las cosas que encontró eran superficiales, como errores tipográficos en comentarios de documentación, pero en general me llevó a mejorar el código, así que lo sentí como una ganancia neta
  El riesgo es que yo empiece a depender del LLM y deje de revisar mi propio trabajo con cuidado
  Eso sí, este modelo de Qwen es lo bastante lento en mi máquina como para no querer correrlo con cada cambio
  Otros modelos como Qwen 3.6 35B o Gemma4 26B fueron mucho más rápidos, pero muchísimo peores
  Es lento y requiere hardware, pero Qwen 27B muestra que podría existir un futuro donde un modelo local mejore el código sin depender de proveedores comerciales ni quitarte la pericia y el disfrute de hackear código
  Aun así, sigo teniendo sentimientos muy encontrados sobre meter LLM en el proceso, aunque me parece mejor que la visión alienante del futuro que empujan los grandes proveedores
  Coincido en que, de los harnesses que he probado, solo pi transmite calma

  • Yo primero pongo a correr al bot y, mientras tanto, hago mi propia revisión; luego vuelvo a la salida del bot para ver qué se me escapó
    El bot a menudo detecta tipos de problemas distintos de los que detecta una persona, así que complementa bastante bien la revisión humana

• En pi, si presionas ctrl+G, puedes abrir el prompt en $EDITOR
  En teoría debería poder soportar mover el cursor con clics y encontrar el editor que te sirva, incluso uno con interfaz de terminal
  Fuera de eso, en general me parece un buen texto con el que coincido bastante

• El problema de “señalar texto” ya está resuelto en los IDE/editores GUI
  Si usas JetBrains IDE, un plugin puede pasar siempre el archivo y la línea seleccionados como contexto del prompt
  Según la forma de la solicitud, también muestra los cambios en línea o en una ventana de diff

  • Zed también tiene una función Inline Assistant que funciona como la describe el autor
    Seleccionas un área, presionas control-enter e ingresas el prompt; luego el LLM transforma la selección según el prompt y la reemplaza
    La experiencia de usuario es muy buena, pero los problemas habituales de la salida de los LLM siguen ahí

• Solo mencionó la suscripción mensual de $20 a los modelos de Anthropic y OpenAI, y dijo que pi es mucho mejor que Claude Code o Codex, pero entonces me hace pensar que en realidad no probó la combinación de modelo frontier + pi
  Yo creía que la suscripción te obligaba a usar ese harness

  • La suscripción de Codex definitivamente se puede usar junto con Pi

• Da gusto ver un texto tan sensato
  Yo, para el trabajo, compro tokens en Novita, con base en EE. UU., y para proyectos personales uso DeepSeek y últimamente Xiaomi
  También probé Kimi directamente, pero no me convenció lo suficiente como para seguir usándolo, y no tengo experiencia con Claude Code, Codex ni con el harness de moda del día
  Con Qwen Code hice el bootstrap de un harness personal en Rust + ratatui, y esto era un fork de algo del lado de Google
  Uso asincronía de un solo hilo, y como a los modelos les encantan demasiado los hilos y mpsc, fue molesto convencerlos
  Por cierto, creo que smol está bien
  Al final terminé entendiendo en cierta medida qué hacen las herramientas y cómo lo hacen, y cada vez que el modelo inventa una sintaxis nueva para una herramienta, evalúo pros y contras y a veces agrego correcciones locales solo para casos específicos
  En general, esto era un problema de sinónimos en los nombres de los argumentos de la herramienta
  Cuantos menos parámetros activados haya, más atención pone el modelo en qué hacer y más olvida cómo hacerlo, lo cual es entendible
  Algún día me parece que, en vez de forzar las llamadas a herramientas como tokens, se van a extraer desde el espacio latente, y quizá incluso se usen modelos de traducción dedicados
  Uso landlock para aislar el modelo dentro del directorio del proyecto y cortarle el acceso al directorio home
  Puede leer rutas del sistema fuera del home, y le permití escribir en lugares como /tmp, algunos directorios de caché de paquetes dentro del home y /dev/null
  Más adelante podría agregar un mejor aislamiento, pero viendo que la mayoría de la gente que conozco simplemente ejecuta Claude Code tal cual, esto me parece higiene básica
  No bloqueo la red, y no hago trabajos que requieran protección adicional contra filtraciones
  La revisión de código no siempre acierta
  Si primero defines lineamientos, al modelo se le da bien comparar el código con esas instrucciones y marcar las partes que no encajan, pero las solicitudes generales como “decime si esto está mal” dan resultados inconsistentes
  Todavía no he visto fanfarronería en DeepSeek V4 Flash, que uso como referencia
  DeepSeek V4 Pro me resultó peor para programar, Xiaomi MiMo 2.5 Pro fue mejor pero un poco caro, y el MiMo 2.5 normal fue peor
  Según mi experiencia, los modelos por lo general simplemente son tontos, sobre todo cuando el contexto se contamina con ideas que chocan entre sí o se vuelve demasiado largo
  A veces el modelo cae en una idea tipo “hay que recortar esquinas para entregar valor más rápido”, y entonces tengo que retroceder unos pasos y hacer que señale dónde contradice mis instrucciones
  A veces es culpa de que yo no entendí lo suficiente, a veces es sobreingeniería del modelo, y a veces termina simplificando requisitos para escapar de casos borde complicados
  No me gusta usar modelos para refactorizar
  Los modelos no toman buenas decisiones
  Si le haces dividir una función en dos según dos usos y recorrer la base de código para decidir qué variante usar en cada punto de llamada, se equivoca el 25% de las veces y no muestra ninguna señal de incertidumbre
  Es mucho mejor hacer que el modelo investigue la base de código y mapee el alcance del impacto, y luego hacer la refactorización uno mismo
  Reacomodos muy fáciles, como cambios estructurales simples que envuelven trabajo en varios puntos, sí aceleran las cosas, pero aun así hay que pedirle explícitamente que verifique también comentarios viejos o nombres de variables que ya no encajan
  A diferencia del autor original, yo no he tenido la experiencia de que el modelo intente hacer cosas que no le pedí
  Puede ser porque exijo un plan previo claro antes de permitir edición, y observo el flujo de razonamiento en tiempo real; si el modelo se descarrila, vuelvo a promptear
  En código de trabajo no hago commit hasta leer y entender todo
  En esta etapa hago muchas correcciones grandes, y después hago que el modelo lo revise otra vez
  Entonces suele encontrar errores de dedo, variables invertidas y otras cosas pequeñas pero problemáticas
  La primera versión de un proyecto personal es simplemente una versión para tirar
  Cuando la arquitectura real se aclara, hay que reescribir todo, y esta vez sí hacer una planificación previa correcta
  Puede que esta forma de trabajar esté un poco subestimada
  Los modelos que uso son bastante rápidos
  A menos que pida explícitamente una investigación larga, no hace falta llegar a cambiar de tarea, y si el modelo tarda demasiado en convencerse por sí solo de cuántas r tiene strawberry, normalmente me pongo a pensar en el siguiente paso
  Algo que da cierto resultado es hacer que el modelo arme un plan, escribirlo explícitamente en un archivo y luego mejorarlo un poco de forma iterativa
  El modelo puede ayudar a buscar en la base de código y entender el alcance del impacto antes de empezar a programar, y tener un plan previo visible también hace más fácil mantenerlo en curso
  Para búsqueda o trabajo barato, usé modelos para encontrar artículos académicos sobre temas específicos y no estuvo mal
  Después conseguí los artículos directamente por suscripción o por otras vías, y se los di al modelo para que los leyera y evaluara si eran relevantes para el tema; eso en realidad funcionó bastante bien
  Los artículos relevantes los volví a leer yo mismo
  También fue algo productivo hacer que investigara una base de código grande y explicara un aspecto específico
  Lo común en ambos casos es que el modelo alucinó bastante
  La tasa de alucinación estuvo muy influida por qué tan enterrado estaba el hecho clave dentro del contexto
  Hacer que clasificara y resumiera un artículo, luego borrar el contexto y pasar al siguiente, redujo bastante el problema
  Supongo que tendrá que ver con la atención dispersa (sparse attention), pero no soy experto
  No me sirvió para brainstorming ni para creatividad
  Nunca me pasó que DeepSeek V4 Flash mintiera diciendo que ejecutó tests o type checking
  A veces se vuelve muy difícil de controlar, pero más bien tiende a volver a correr tests y type checking “para estar seguro” incluso después de tocar apenas un comentario
  Y no estoy de acuerdo con que esto sea lo más interesante que me pasó en la vida