- Entre los ingenieros de software, hay en general dos posturas muy marcadas frente a los LLM
- Algunos creen que son una tecnología revolucionaria que sacudirá a la industria
- Otros los ven como un simple espejismo exagerado
- El autor siente personalmente que usa los LLM de forma útil, y presenta cómo los aprovecha de manera efectiva
Escribir código de producción
- Siempre usa la función de autocompletado de Copilot al escribir código
- La mayoría de las sugerencias de autocompletado corresponden a boilerplate repetitivo, como argumentos de funciones o tipos
- En su área principal de trabajo (por ejemplo, Ruby on Rails), considera que el código que escribe él mismo es mejor
- En áreas donde tiene menos especialización, acepta con más frecuencia la lógica sugerida por Copilot
- Ejemplo: cuando necesita hacer pequeños cambios tácticos en lenguajes como Golang o C
- Con ayuda de Copilot, entiende rápidamente la sintaxis y el estilo idiomático de lenguajes que conoce menos
- Como no tiene suficiente conocimiento especializado, siempre procura que un experto del área revise el resultado
- Así puede trabajar hasta cierto punto al nivel de un “intern inteligente”, pero pasar por un proceso de validación es indispensable
Escribir código de un solo uso
- Cuando escribe código de un solo uso que no se desplegará a producción, usa los LLM de forma mucho más activa
- En el caso de código que se ejecutará una sola vez con fines de investigación y luego se desechará, hay menos necesidad de mantenimiento
- Ejemplo: tomar datos públicos desde una API, clasificarlos y aplicar regex para hacer una validación simple
- En estos casos, comenta que pudo avanzar entre 2 y 4 veces más rápido gracias a los LLM
- Para escribir código de usar y tirar, los LLM son muy eficientes
Aprender áreas nuevas
- Lo considera el caso de uso más valioso: usar un LLM como un tutor bajo demanda
- Ejemplo: al aprender Unity por primera vez, hace preguntas constantemente a modelos como ChatGPT-4o
- No solo pregunta “¿Cómo funciona X?”, sino también preguntas de seguimiento como “¿Qué relación tiene X con Y?”
- También lo usa para verificar su comprensión, con preguntas como “¿Lo que entendí es correcto?”
- Durante el aprendizaje, copia y pega sus notas tal cual para que el modelo las revise
- Preocupación por las alucinaciones (hallucination)
- Siente que, desde GPT-3.5, las alucinaciones en general no han sido especialmente notorias
- Como la mayoría de las áreas que aprende en su día a día ya están bien establecidas, el riesgo de respuestas incorrectas fue bajo
- Hasta ahora, no le ha pasado aprender información incorrecta a través de un LLM
El arreglo final de bugs
- Cuando está realmente atascado, le muestra a Copilot o Claude el archivo completo y el mensaje de error para pedir ayuda
- En la mayoría de los casos, el LLM se confunde y no logra proponer una solución adecuada
- Aun así, hubo algunas ocasiones en que el LLM señaló algo que había pasado por alto y le ahorró tiempo
- Como el rendimiento no es tan bueno como esperaba, no insiste varias veces y suele preguntar solo una vez
Corregir typos y errores de lógica
- No hace que un LLM redacte por completo sus textos (ADRs, resúmenes técnicos, documentación interna, etc.)
- Considera que él mismo puede escribir con más claridad y no le gusta el estilo característico de los LLM
- A veces pega un borrador en un LLM para recibir feedback de gramática o corrección de typos
- El LLM detecta bien los errores ortográficos y, de vez en cuando, también propone perspectivas interesantes
- Más que iterar varias veces sobre sugerencias de edición, solo revisa una vez el feedback general sobre la estructura
Resumen
- Ámbitos en los que usa LLM
- “Autocompletado inteligente” con Copilot
- Cambios tácticos breves en áreas que conoce poco (con revisión obligatoria de un experto)
- Escritura de código de investigación de usar y tirar
- Hacer preguntas sin parar al aprender nuevas tecnologías o dominios
- Intentar resolver bugs como último recurso cuando se atasca
- Corregir de forma general ortografía, typos y errores de lógica en borradores de documentos en inglés
- Lo que todavía no hace con LLM
- Delegar la redacción completa de Pull Requests en áreas que conoce bien
- Escribir documentos técnicos enteros como ADRs
- Entender arquitecturas complejas dentro de codebases grandes
6 comentarios
¿Esto es... un ingeniero staff...?
Sí, definitivamente es un staff engineer de GitHub.
A mí tampoco me parece que esto sea de nivel staff engineer... más bien creo que encaja como nivel de asistente.
Hay un error de traducción en el título; no es "como un staff engineer", sino "como staff engineer".
👍!!
Opiniones de Hacker News
Como "staff engineer", los LLMs son muy deficientes para escribir código idiomático o enseñar, y más bien hacen que se invierta más tiempo en revisión de código. Usar LLMs para escribir código implica el riesgo de aprender malas prácticas y de volverse dependiente de la cantidad de código, del boilerplate y de resultados no deterministas. Los LLMs pueden ser útiles para generar ideas o explorar información no confiable, pero depender de la generación de código es una locura.
Al corregir bugs, hay una forma de usar Copilot adjuntando el archivo completo y pegando el mensaje de error para pedir ayuda. Los modelos de "reasoning" ofrecen resultados mucho mejores que esto, y si pegas toda la base de código y explicas el mensaje de error, a menudo encuentran la raíz del problema.
Los LLMs son útiles para código boilerplate o autocompletado, pero tienen límites en tareas complejas. Esto se debe a que no entienden la lógica de negocio. Sin embargo, son muy útiles para redactar rápidamente documentación corporativa.
Trabajo en GitHub y tengo experiencia participando directamente en Copilot.
Si usas un lenguaje con tipado estático y un buen IDE, la función de "smart auto complete" puede ser menos útil. La función de autocompletado de Intellij se siente, en la mayoría de los casos, como si te leyera la mente.
Una reflexión sobre por qué los ingenieros de software tienen sentimientos negativos hacia los LLMs. Muchas personas tienden a juzgarlos con criterios absolutos, y eso limita su capacidad de aprovechar la herramienta de forma efectiva.
Cómo usar IA para mantener proyectos de Python. Ayuda a convertir a Python métodos usados en otros lenguajes.
La experiencia de usar ChatGPT para escribir código utilitario fue buena. En revisión de código a menudo señala problemas menores, pero sigue siendo valioso cuando encuentra puntos de mejora.
Después de cambiar de VSCode a Cursor, el modo agente con Sonnet resulta impresionante. Si un desarrollador con experiencia lo guía, puede contribuir mucho a mejorar la productividad.
Uso LLMs para ayudar a corregir errores tipográficos y fallas lógicas en documentos. Ajusté Graphite Reviewer para que se enfoque en bugs y errores reales. La IA no es perfecta, pero es útil como herramienta de corrección de código.