Ask HN: ¿Estás cansado tú también en esta era de la AI?
Ask HN: Are you tired too in this AI era?
Uso AI para corregir AI. Sé que suena ridículo, pero Claude Web funciona distinto que Claude Code: uso Claude Web/Chat para briefs, planificación y traspaso de trabajo a Code, que ejecuta mediciones y tests y me reporta hallazgos que realimento a Chat para un resumen. Aun así, Code sigue cometiendo errores arquitectónicos, aplica parches en lugar de diseñar bien y desprioriza casos, aunque es más fácil detectarlo que hacer una revisión línea por línea. La calidad la aseguro mapeando el flujo y el espacio de salida, con tests fijos que Code no puede modificar y un agente revisor independiente sin contexto que cuesta 20-30 minutos y ~200K tokens por ejecución. No es tan divertido como entrar a mano en problemas técnicos profundos, pero el uso de AI va menos de diversión y más de velocidad de salida.
Uso AI para corregir AI :D Sí, ya sé, suena ridículo, pero escúchame. Claude Web funciona de manera diferente a Claude Code. Uso Claude Web/Chat para briefs, una visión general del proyecto fuera del código/app, para planificar y pasar el trabajo a Code, incluidos los prompts. Code tiene la tarea de generar una vista detallada de lo que encontró, ejecutar mediciones y pruebas (diseñadas tanto por mí como por Chat) y reportar los hallazgos. Eso se realimenta a Chat y obtengo un resumen aproximado. Los errores se categorizan por su radio de impacto, etc. Finalmente hago una inmersión profunda en lo que cambió, qué tan bien lo está manejando, cuánto le está costando, uso de tokens, tiempo por revisión/prueba, etc. (por cierto, a Code se le encarga ejecutar una revisión independiente mediante un agente sin contexto sobre el código, lo que fácilmente me cuesta otros 20-30 minutos y ~200K tokens en mi proyecto actual, en cada ejecución). Todavía comete problemas arquitectónicos, intenta parchear y aplicar curitas en lugar de diseñar adecuadamente, sobrevalora/subvalora ciertos casos y asigna mal dónde debería estar el mayor foco, pero eso es relativamente más fácil de detectar y proponer una solución que hacer una revisión línea por línea del código. La calidad del código se asegura mapeando el flujo y el espacio de salida y teniendo pruebas fijas que Code no puede modificar para hacer pasar sus respuestas, más el revisor independiente que mencioné. No es tan divertido como entrar a mano en problemas técnicos profundos, claro. Pero el uso de AI va menos de diversión y más de velocidad de salida, así que úsala para lo que sirve, supongo :D
- ryandvm
Sí, estoy cansado; pero peor aún, soy infeliz.
Entiendo que a mucha gente le encanta gestionar equipos de agentes y ahora son mucho más productivos. Me alegro por ellos, de verdad. Al parecer nunca disfrutaron realmente de programar, aparecerán en masa en estos comentarios para decirte que lo que realmente disfrutaban era el resultado final.
Yo también soy más productivo, pero voy a ser honesto: realmente no estaba buscando más productividad. Estoy en un punto de mi vida en el que aumentar mi productividad no es, en absoluto, uno de mis objetivos personales.
Usar Claude Code todo el día es como ser un niño de ciencias al que le regalan un robot que construye con Legos. ¡Qué maravilla! Ahora no tienes que lidiar con todas las molestias de ensamblar Legos, simplemente le dices que quieres un castillo y ¡boom! ¡Qué época para estar vivo!
- martypitt
Son tiempos extraños.
Me siento increíblemente productivo. Estoy construyendo en una tarde lo que me habría llevado semanas. Paso todo mi tiempo en MRs revisando código, o en una terminal dando instrucciones.
He pasado de ser programador a ser ingeniero-arquitecto de producto. Me encanta programar, ME ENCANTA. Pero el rol ha mutado. Y, de hecho, me gusta mucho el nuevo rol. Me encanta estar centrado en el producto y preocuparme por la arquitectura; me sienta bien.
El código que produce Claude a menudo es limpio, pero terriblemente arquitecturado. Así que paso mucho tiempo revisando en detalle.
Pero la ansiedad... Dios, la ansiedad.
Trabajo en múltiples funcionalidades (generalmente 4-5 flujos de trabajo) de forma concurrente, así que estoy constantemente cambiando de contexto. Me preocupa cuánto tiempo dedico a cada tarea. ¿Estoy haciendo suficiente revisión de código? ¿Demasiada? ¿Muy poca?
¿Y las pruebas de clic? Nuestra cobertura de pruebas nunca ha sido mayor. ¿Debería poder fusionar estas funcionalidades sin más? ¿No era esa siempre la promesa de TDD: fusionar con confianza? Pero me parece un riesgo.
Y me muevo muy, muy rápido, pero asumo que mis competidores también. Eso me impulsa a ir más rápido. Automatizar más. Usar Claude en más lugares. Lo que genera más ansiedad: ¿estoy recortando demasiado? ¿Todo esto se va a desmoronar sobre mí?
Además, ¿todo en lo que estoy trabajando se volverá irrelevante? ¿Los clientes comprarán este producto o lo harán ellos mismos con vibe coding? ¿Tenemos siquiera un foso defensivo? Ansiedad. Más ansiedad.
Mis inversores también leen cosas constantemente. Me envían actualizaciones del mercado, em […]
- rhedak
Sí, es como si un fantasma me persiguiera diciéndome que necesito ser más productivo. Y si no uso mi límite semanal al menos al 90%, estoy desperdiciando dinero y tokens. ¿Debería quemar tokens sin fin? ¿Es eso un objetivo en sí mismo? ¿Dónde está la visión? ¿Estoy realmente construyendo algo que valga la pena?
- yulaow
Me sorprende cuánta gente aquí dice que revisa los resultados de múltiples agentes trabajando en diferentes PRs al mismo tiempo, cambiando constantemente de contexto entre ellos.
Yo me centro en uno solo, uso interacciones muy cortas a propósito porque quiero comprobar cada función directamente y no un archivo entero de 300 líneas o un PR de 2000 líneas solo al final. Probablemente voy más lento que la mayoría, pero siento que retengo el conocimiento de mi base de código casi tan bien como cuando era yo quien escribía el código directamente, y mis PRs reciben muy pocos comentarios de revisión.
Lo que más me cansa es cuando alguien me envía un PR para revisar y veo inmediatamente que lo han hecho completamente con vibe coding y simplemente me delegan el trabajo duro de corregir las tonterías escritas con un solo prompt sin interacciones. Lo peor es cuando le preguntas a alguien por qué implementó algo de esa manera y responde: "bueno, lo hizo Claude, realmente no lo pensé, ahora que lo leo sí que no tiene sentido".
- ghoshbishakh
Estoy muy cansado. Mantengo Pinggy, mi primera startup autofinanciada, y estoy construyendo Lumirank, mi siguiente proyecto. Pero cada día es una lucha por adaptarme a lo nuevo y a lo que están haciendo otros 20 competidores que surgieron ayer. Se escriben millones de líneas de código cada día, no puedo fusionar sin conocer la arquitectura y el flujo generales. Pero no puedo descansar. Todo el mundo está corriendo.
A veces siento que, por favor, alguien me dé un trabajo en el que pueda trabajar 12 horas al día, pero las otras 12 horas no tenga que pensar en lo que pasará mañana. Aun así sería menos estresante.
- sjdh76
Le digo que soy un chimpancé con un cerebro de 3 pulgadas, así que la complejidad más allá de la escala de chimpancé está prohibida a menos que se solicite. Y que aplique la teoría de la racionalidad limitada durante todas las interacciones con el chimpancé. Me cuida como a un animal de circo.
Le pido una lectura rápida del termómetro de complejidad cada vez que el agujero de conejo parece que va a explotar.
También me ha ayudado alejarme cada pocas horas y hacer cosas simples y sin sentido. Por ejemplo, voy a inspeccionar mis peces y plantas. Intento charlar con el gato, hacer que los demás hagan un pequeño baile, etc.
Tengo un sacerdote en la familia que tiene que lidiar con muchas cosas pesadas y problemas de la gente. Los entrenan para no dejarse absorber del todo y perderse. Él lo llama grounding. Simplemente cosas mundanas y simples para cambiar el foco de cualquier cosa pesada.
- sadilek
A medida que los agentes se vuelven más capaces, pueden asumir paquetes de trabajo más grandes sin microgestión. Mi conclusión de eso es: necesito elevarme en la jerarquía y trabajar más como un director de ingeniería que como un ingeniero. Durante unos días, reflexioné sobre cómo quiero trabajar.
Para mí, la conclusión fue: quiero un diseño espacial del trabajo en un lienzo por proyecto y videos de demostración narrados, como en una revisión de lanzamiento de una funcionalidad, donde yo, como "director de ingeniería", pueda decidir lanzar o dar retroalimentación para otra iteración. Entrada principalmente por voz. Así que es un poco como sentarse en una sala de reuniones con ingenieros entrando y saliendo.
Como el software es tan barato de construir hoy en día, creo que solo necesitas descubrir cómo quieres trabajar y luego construir el arnés para ese estilo de trabajo.
(Si quieres probar mi estilo, es gratis y de código abierto. Lo comparto porque estoy entusiasmado con lo divertido que es usarlo: https://github.com/sadilek/obeya)
- hypfer
Hacer cumplir los límites y decir que no se han vuelto más importantes que nunca, ahora que la violación de cualquiera de los dos está automatizada a velocidades sobrehumanas.
Por si sirve de algo, podría haber un lado positivo en esto. Gran parte de la disfunción en el estado actual de la tecnología puede (en mi opinión) rastrearse hasta la violación de límites.
Esto podría llevar a un cambio cultural. Aunque también podría ser solo un deseo por mi parte.
___
> Me encantaría escuchar tus consejos, pero que sigan siendo relevantes en esta era de la IA, para que mi jefe no me despida.
Si tu jefe te despide porque no multiplicaste tu rendimiento haciendo más trabajo en el mismo tiempo (sin que cambie tu compensación), eso no es tu culpa, sino simplemente tu empleador intentando exprimirte más y no funcionando.
Ten siempre eso en cuenta en estas discusiones.
Lo cual no quiere decir que no debas mejorar la eficiencia y todo eso, pero tiene que ser orgánico. Si se pide algo inorgánico, entonces el fallo (moral) es de quien lo pide y no de quien lo recibe.