Software Engineer. A stack é qualquer coisa, foco do trabalho gringo é produtividade, não te perguntam se sabe A ou B antes de passar uma demanda, não sendo um bocó você mexe em praticamente tudo de baixa plataforma. Também não tem diferenciação de papéis, o time tem um lead e pronto, não tem arquiteto e as diferenças de dev jr e sr são somente na hora de pagar. Cliente EUA.
Sou arquiteto e sim, basicamente não toco mais em código. A IA analisa tudo pra mim e fica tudo bem mais mastigado. Alterações de código também em geral elas fazem, mas ainda depende muito de uma análise bem feita e fazer diversos guard-rails, pq elas adoram alucinar, seguir numa solução míope ou então elas focam numa solução e só querem fazer aquilo, ai vc tem que ir pivotando ela pra outra. Em geral atualmente tenho muito mais trabalho que antes, antes eu demorava 2-3 dias numa análise, olhando código, entendendo tudo e etc, hoje em dia a análise fica pronta em 10-15 min, meu trabalho é entender e dar a solução e implementar, espaço de tempo muito menor, mas abre brecha pra muito mais cenários sendo trazidos pra mim.
Sim, em grande parte. Com o uso de IA, tenho escrito pouco código manualmente. Meu trabalho se concentra em planejar, direcionar e revisar o que ele entrega. Isso vale para arquitetura, frontend, backend, pesquisa e outras coisas, embora o orçamento para ferramentas e tokens seja, de fato, um fator relevante.
Apesar disso, não considero bom dispensar a revisão do código. Para ganhos expressivos de produtividade sem problemas posteriores, é melhor investir tempo em planejamento: especificações claras, decisões de arquitetura definidas e testes automatizados. Em tarefas simples, é possível ser mais flexível, mas em sistemas de produção, a revisão continua indispensável, pois a IA ainda comete erros sutis de lógica, segurança e desempenho com bastante convicção.
Para ilustrar de forma lúdica, peça a um modelo de ponta (como Opus, Fable ou Astra) que crie um jogo. O resultado surge rapidamente e, à primeira vista, parece um protótipo bonito e praticamente perfeito. Com o uso, porém, começam a aparecer falhas, e você passa a solicitar ajustes. Em certo ponto, o modelo encontra dificuldade em algumas demandas, e os ajustes se multiplicam até que se chegue ao resultado desejado, isso se chegar. Na minha experiência, esse padrão se repete: a primeira entrega impressiona, mas o último trecho do caminho concentra a maior parte do esforço. Cada correção também pode introduzir novos problemas, sobretudo à medida que o projeto cresce. Um jogo é um bom exemplo justamente porque os defeitos são visíveis de imediato. Em um sistema de backend, falhas equivalentes costumam ser silenciosas e só aparecem em produção, reforçando a importância do planejamento, dos testes e da revisão do código.
Atenção!
Você precisa estar logado para compartilhar promoções e avalições!
Atenção!
Você precisa estar logado para comentar ou responder!
sim
Em qual frente vc trabalha hoje? Agradeço se puder dar mais informações tipo stack, qual o país do cliente e etc...
Software Engineer. A stack é qualquer coisa, foco do trabalho gringo é produtividade, não te perguntam se sabe A ou B antes de passar uma demanda, não sendo um bocó você mexe em praticamente tudo de baixa plataforma. Também não tem diferenciação de papéis, o time tem um lead e pronto, não tem arquiteto e as diferenças de dev jr e sr são somente na hora de pagar. Cliente EUA.
Sou arquiteto e sim, basicamente não toco mais em código. A IA analisa tudo pra mim e fica tudo bem mais mastigado. Alterações de código também em geral elas fazem, mas ainda depende muito de uma análise bem feita e fazer diversos guard-rails, pq elas adoram alucinar, seguir numa solução míope ou então elas focam numa solução e só querem fazer aquilo, ai vc tem que ir pivotando ela pra outra. Em geral atualmente tenho muito mais trabalho que antes, antes eu demorava 2-3 dias numa análise, olhando código, entendendo tudo e etc, hoje em dia a análise fica pronta em 10-15 min, meu trabalho é entender e dar a solução e implementar, espaço de tempo muito menor, mas abre brecha pra muito mais cenários sendo trazidos pra mim.
Sim, em grande parte. Com o uso de IA, tenho escrito pouco código manualmente. Meu trabalho se concentra em planejar, direcionar e revisar o que ele entrega. Isso vale para arquitetura, frontend, backend, pesquisa e outras coisas, embora o orçamento para ferramentas e tokens seja, de fato, um fator relevante.
Apesar disso, não considero bom dispensar a revisão do código. Para ganhos expressivos de produtividade sem problemas posteriores, é melhor investir tempo em planejamento: especificações claras, decisões de arquitetura definidas e testes automatizados. Em tarefas simples, é possível ser mais flexível, mas em sistemas de produção, a revisão continua indispensável, pois a IA ainda comete erros sutis de lógica, segurança e desempenho com bastante convicção.
Para ilustrar de forma lúdica, peça a um modelo de ponta (como Opus, Fable ou Astra) que crie um jogo. O resultado surge rapidamente e, à primeira vista, parece um protótipo bonito e praticamente perfeito. Com o uso, porém, começam a aparecer falhas, e você passa a solicitar ajustes. Em certo ponto, o modelo encontra dificuldade em algumas demandas, e os ajustes se multiplicam até que se chegue ao resultado desejado, isso se chegar. Na minha experiência, esse padrão se repete: a primeira entrega impressiona, mas o último trecho do caminho concentra a maior parte do esforço. Cada correção também pode introduzir novos problemas, sobretudo à medida que o projeto cresce. Um jogo é um bom exemplo justamente porque os defeitos são visíveis de imediato. Em um sistema de backend, falhas equivalentes costumam ser silenciosas e só aparecem em produção, reforçando a importância do planejamento, dos testes e da revisão do código.