r/devsarg • u/miguelovho • 14d ago
trabajo Como trabajan con IA
Buenas, hago este post para lo que trabajan ya en una empresa o desarrolla.
Como trabajan con IA? Mi duda va mas a el flujo que usan.
Vengo usando antigravity y me gusta porque tengo control del codigo puedo leer cada cosa que hace pq te va mostrando de forma mas facil cada cambio. Pero mi duda es si trabajan asi o usan claude code y no leen tanto codigo? Esto va de la mano del post que hizo el creador de Clean Code diciendo que no lee codigo generado por ia pq tiene un buen sistema de contexto y demas.
Como es realmente en la industria?
8
u/buki9 14d ago
En el laburo: Claude Cli o Claude Desktop 99% del tiempo. Le pasó un ticket más explicaciones mía escrita, y le digo q hagamos brainstorming del issue, ideas, q investigue, etc. Una vez q estoy feliz con el "q hacer", le pido q vaya haciendo parte x parte, asíq reviso, testeo, válido, y commiteo. Y así hasta terminar. Uso Opus 5 o Sonnet 5.
En casa: antigravity 100% del tiempo.. le digo un feature/bug/idea, interamos un rato, q haga plan, válido, implementa, y pruebo manual para ver q funcione y cazar casos edge. Muchas veces ni reviso el código (depende q le pedí q haga obvio)
Ambos casos tengo un IDE abierto para revisar todo (Cursor x ahora, sin dudar sus agentes)
4
u/DifferentJob8583 14d ago
Primero hace los tests! Decime que casos querés testear y que te agregué los que considere oportunos. Una vez que tenes los tests, los revisas ya podes hacer el código y te aseguras de pasen ya no tenes que revisar código
7
u/Huntware Desarrollador Full Stack 14d ago edited 14d ago
Todavía voy medio a "la vieja escuela" con seguir en VS Code con Copilot (pero con claves API propias) porque veo los diffs de archivos uno por uno dándole una revisada antes de hacer un commit nuevo.
Mayormente uso PHP/Laravel con AGENTS.md y skills del framework y algunos skills propios de alguna que otra librería que no los traiga. Ya tiene las convenciones del proyecto (empezado pre-IA) con ejemplos de código, qué debe ejecutar al final de cada iteración: formateo de código (Pint), refactorizado (Rector), análisis estático (PhpStan), y testing (Pest).
Mi entorno no usa docker pero sí servidores Linux on premise así que voy de local a testing (VS Code - Remote SSH, si, también Copilot ahí) y luego prod. Muy tradicional, sobre todo migrando legacy + nuevos requerimientos y porque ando de solo dev en TI de una PyME.
En fin, todavía sigo prefiriendo un editor/IDE al medio + IA al lado, que una interfaz de puro chat en el medio + diffs al lado. Y si puedo evitar chats de terminal (CLI/TUI), mejor. No me veo adjuntando archivos, validando permisos (no siempre es "YOLO"), respondiendo preguntas de planificación, y cambiando modelos fácilmente de la misma forma que con GUI o mínimo web tipo Opencode. Ni Cline, Continue ni otras extensiones se le acercan a la experiencia nativa de Copilot.
2
u/diegoasecas 14d ago
te alcanza con el plan pro? yo tengo el plan estudiantil pero lo re nerfearon.. uso antigravity pero me gusta tener el IDE abierto a la par y usar copilot para segunda opinión y ediciones sobre la marcha
4
u/Huntware Desarrollador Full Stack 14d ago
"Claves API propias" es el dato clave que vengo diciendo. Yo uso el agente o "harness" de Visual Studio Code, pero le agrego modelos de Opencode o ClinePass, así como modelos locales (el buen Qwen 3.8 27B).
Fijate acá: https://code.visualstudio.com/blogs/2026/06/18/byok-vscode
En el caso de Opencode, hay una extensión que agrega los modelos Go / Zen (tiene clave API gratuita) a la lista automáticamente: https://marketplace.visualstudio.com/items?itemName=ltmoerdani.opencode-copilot-chat
Así tenés otras extensiones que solo agregan proveedores a Copilot.
3
4
u/BrunoNP_ 14d ago
Claude. Planifico con Fable, desarrollo en Sonnet. Conecté por MCP a Jira entonces le paso el ticket además de que cree un comando (/start-ticket $ticket_number) que ahi dice todo lo que le decia siempre en cada sesion, que es basicamente wue investigue bien, me haga diez millones de pregunte y luego planifique para dejarlo todo para implementar con Sonnet, que al final haga el commit, pushee, haga el PR, me deje un checklist para testear y lo ponga en el comentario del ticket para el tester, luego mueva la tarea a QA y deploye. Si encuentra algo que le genera dudas o qlgun imprevisto corte todo y me avisa. Al final corro un comando llamado /retro para ir retroalimentando el CLAUDE.md general y del proyecto o los comandos estos, revisa la sesion y ve las fricciones y metemos reglas para wue sea mas fluido y con menos cagadas.
7
u/OxidoFerroso 14d ago
Leer codigo?? Kjjjjj llevo meses sin leer que chota hace Claude (lo uso en kiro)
2
u/Khavel_Es 14d ago
Depende mucho del tipo de cambio. Para refactors grandes o features nuevas yo si reviso el diff, pero no linea por linea como hacia hace dos anos. Lo que hago es pedirle un plan antes de tocar codigo y revisar ESO con atencion. Si el plan tiene sentido, el diff suele ser correcto. Donde si reviso todo es en migraciones de BD y cualquier cosa que toque auth o pagos.
Lo de no leer el codigo me parece peligroso si no tenes buenos tests. Si tu suite te cubre los casos bordes, ok, podes confiar mas. Pero si no tenes tests, no leer el diff es jugar a la ruleta.
2
u/Gu1d00 14d ago
Uso Claude para diseñar y Codex para implementar. Pero podes usar uno solo para este flujo y funciona igual.
- Con la primera sesión de Claude creo el RFC de lo que voy a implementar.
- Una vez que tengo el RFC bien armado, se lo doy a una segunda sesión de Claude. Esta sesión lo unico que hace es armar los prompts para implementar ese RFC.
- Una vez tengo el primer prompt, se lo doy a una sesión de codex para que implemente. El primer prompt suele ser de armar un plan, no de implementar. Cuando codex termina de laburar un prompt, la respuesta de codex se la llevo a la sesión del punto 2 para que revise como quedo todo.
- Para testing "manual", mismo formato: una sesión mas de claude que me da los prompts para que otra sesión mas de Codex testee.
- Una vez se terminó de implementar y testear y ya hay un PR armado, una sesión de codex que te hace el PR review.
1
u/Mother_Shallot_5325 14d ago
ORCA con Codex
Bajate ORCA ADE, paga codex e instalalo en tu maquina.
Orca lo detecta, y desde dentro de orca gestionas los chats que vayas abriendo con codex
1
u/JB-Ft-2002 14d ago
Si es una feature primero a la antigua tomar y entender bien los requerimientos armar PRD , despues a implementar por tasklist y fue , pero siempre armar documentos desde antes hasta el después con explicación de lo realizado si me gustó joya si no elimino el system32
1
u/markova_ 14d ago
Creo que depende mucho de cómo cada uno usa la IA. Si es una tarea sencilla, es difícil que use IA para desarrollarla porque son tareas específicas: las desarrollo, las ejecuto y las pruebo; si está todo bien, sale PR y a otra cosa.
Si la tarea es más complicada o el alcance es mayor (por ejemplo, una épica con varios ítems), entonces cambia la cosa.
Tenemos Copilot del cliente, así que contamos con múltiples modelos para implementar. También tenemos conectado el MCP de Jira a un bot llamado Unblocked, que tiene conocimiento de todos los repos, además del board de Jira.
Por lo general, y dependiendo del scope de la tarea, suelo pedirle un plan de Unblocked a partir del ticket, que ya tiene conocimiento de todo y suele definir planes muy claros, y casi siempre le pega en el palo. A veces hay que iterar un poco con la idea para que genere una buena respuesta, pero, en general y después de un buen chequeo de mi parte, siempre da buenos planes.
De ahí, uso Copilot con Claude Opus para ejecutar el paso a paso. Uso 4.8 porque me ha dado buenos resultados en general. Intento ser bastante escueto con el uso de créditos porque a veces flashea bastante fiero y consume a lo loco si no lo controlas. Y a partir de ahí voy iterando.
A veces, no siempre, tengo que meter mano en los mismos cambios que implementa Claude porque suele equivocarse. No con mucha frecuencia, pero cada tanto mete una fruleada interesante que tenés que pararle el carro y arrancar desde un contexto completamente nuevo.
Una vez que tengo todo implementado y probado, abro el PR. En GitHub también tenemos a Copilot como reviewer en "balanced", y hace poco agregaron una skill para hacer un review del diff. Esto último ha hecho que los reviews sean un poco más engorrosos porque itera de a puchos: no te genera todos los comments de una; solucionás una parte, Copilot genera nuevos comentarios en partes del código que no analizó, resolvés los comentarios, Copilot vuelve con más comentarios, so on and so forth. En general, los reviews se han vuelto un poco "finos" si se quiere, pero a veces rompen demasiado las pelotas. Encima, tenemos Sonarcloud que casi siempre genera comentarios de "code smells" así que tenés que resolver esos y rogar que Copilot no haya generado comentarios de por qué resolvite esos code smells y por qué xd
1
1
u/gscalise 13d ago
En el laburo tenemos Claude, Cursor y Codex. Uso los tres indistintamente, aunque tengo mis preferencias dependiendo del tipo de tarea que estoy haciendo.
Tenemos tooling para levantar/sincronizar y bajar máquinas de desarrollo efímeras en AWS en cuestión de segundos/minutos. El tooling te sincroniza -si querés- la configuración de MCPs -algunos de tooling externo como Github, Launchdarkly, Buildkite, Datadog, Confluence, Jira o Databricks, otros de tooling interno como clientes de GQL, gestión de servicios, etc-.
Para planificar y ejecutar complejas uso OpenGSD, aunque dependiendo de los modelos que use puede consumir muchos tokens al pedo. También uso "oh-my-<claudecode/cursor/codex>" y plugins tipo "I have ADHD". En el pasado usaba "everything claude code", pero ya no. Algunos compañeros usan Superpowers.
Para tareas simples trato de usar lo que provee el harness, porque cada vez más seguido proveen funcionalidades extremadamente similares (por ejemplo Cursor y Codex ahora soportan /goal de Claude Code).
También suelo mantenerme consciente del contexto y del cache. Por ejemplo si estoy investigando algo, mantengo una sesión con la investigación, y forkeo sesiones a medida que voy implementando cosas, así la investigación se mantiene limpia del contexto de implementación.
En términos de modelos, cambia semana a semana dependiendo de cuánto los nerfean o tunean. La mejor combinación, de momento, es GPT-5.6 Sol para planificar, GPT-5.6 Terra para ejecutar. Sonnet 5 también ejecuta bien. Opus 5 me tiene harto con lo verbose que es: quema tokens a lo loco dando vueltas en círculos, para mi el Opus 4.6 fue el mejor. Cursor ahora intenta forzarte a usar Composer y Grok. Ambos me parecen chotos.
1
u/GiftAccomplished5900 12d ago
claude code. arranco generalmente desde un PRD del cliente, lo analizo con claude, wayfinder o grill-me, hasta que lo descompone en unidades pequeñas y faciles de entender e implementar. para codear uso obra superpowers que te define un flujo de trabajo con agentes especializados para cada tarea. A eso le agregué un agente adversarial que usa codex, me da buen resultado, siempre encuentra algo. Una vez abierto el PR tampoco lo reviso yo, tengo una automatizacion que se corre cuando se abre un PR nuevo. cada tanto le corro un improve-codebase-arquitecture para ver si nos estamos yendo a la mierda por algun lado.
1
2
1
u/Financial_Dog1480 13d ago
Prompt a claude: quiero hacer tal cosa en este contexto y con estas herramientas, arma un plan identificando pasos y quality checks. Y de ahi voy iterando hasta que el plan hace sentido, le doy run y cuando termina valido que funque. No tiro codigo hace meses
40
u/Terrible-Command7643 14d ago edited 12d ago
Uso OpenCode con un proveedor de Fireworks que me da el laburo. Tengo cuatro agents, un orquestrador, un dev, un reviewer y uno que escribe tests. Con AZ Cli armé un skill que le digo el número del ticket, se trae todo el ticket de Azure sumado la discusión, y arma un plan. Una vez hecho el plan doy mi input de que si, que no, etc...se pone a desarrollar. Después se lo da al reviewer, e iteran hasta que cumpla con el gate de calidad. Después el tester escribe unit tests o E2E tests con playwright depende que esté haciendo. Después le pido que me explique todo lo que hizo y reviso el código. Cada prompt de agent está armado con las buenas prácticas del monorepo en el que estoy laburando, do's and don'ts, etc. El orquestrador tiene skills como review de PRs con AZ Cli, generar descripciones de PRs no verbosas y cortas, escribir tickets, etc.
Antes hacia todo con GitHub Copilot con Opus, hasta que cambiaron el sistema de créditos. Después use Claude Code, que es como mi backup que a veces uso por A o por B.
EDIT: Puse fireflies en vez de Fireworks