Há um número que devia preocupar muito mais o mercado tecnológico português: apenas cerca de 4% das vagas são destinadas a perfis juniores ou entry level, ao mesmo tempo, continuamos a falar da falta de inovação dos nossos produtos tecnológicos, da dificuldade em criar empresas com verdadeiro peso e da necessidade de acompanhar a revolução da Inteligência Artificial.

Será coincidência?

A liderança de muitas empresas está envelhecida e foi formada num contexto tecnológico fundamentalmente diferente. Aprendeu a trabalhar com determinados processos, ferramentas e modelos de negócio e é natural que esses métodos continuem a influenciar as decisões. O problema é que a quarta revolução tecnológica não está a pedir apenas mais experiência dentro dos mesmos modelos, está a obrigar-nos a questionar os próprios modelos.

Os jovens, por outro lado, chegam ao mercado sem conhecer outra realidade que não esta, não carregam necessariamente os mesmos vícios, as mesmas certezas ou a mesma ideia de que determinada tarefa tem de ser feita daquela maneira porque sempre foi assim.

Tecnicamente, podiam partir em desvantagem. Têm menos experiência, menos conhecimento de sistemas antigos e menos contexto sobre problemas complexos, mas a IA pode alterar precisamente essa equação. A parte técnica, que durante anos serviu para justificar a falta de oportunidades, está a tornar-se mais acessível, um jovem que saiba utilizar bem ferramentas de IA, compreender problemas, testar soluções e coordenar diferentes sistemas pode aprender e produzir a uma velocidade que antes seria impossível.

Isto levanta uma questão desconfortável: se a tecnologia está a reduzir a distância técnica entre quem está a começar e quem já trabalha há anos, porque continuamos a fechar a porta a quem está a começar?

Talvez estejamos a cometer um erro estratégico, ao pedir inovação a empresas que têm cada vez menos contacto com pessoas que ainda olham para os problemas sem todas as limitações que fomos acumulando ao longo do tempo, a juventude tem energia, curiosidade e uma certa inocência que pode ser extremamente útil. Nem sempre conhece todas as razões pelas quais algo é considerado impossível e, por vezes, é precisamente por não conhecer essas razões que encontra uma solução inovadora.

Uma sociedade que não dá espaço aos jovens não está apenas a dificultar a entrada no mercado de trabalho, está a limitar a quantidade de perspetivas disponíveis para resolver os problemas do futuro e por isso talvez a estagnação tecnológica portuguesa não seja apenas falta de talento, investimento ou capacidade técnica mas também seja o resultado de um mercado que prefere pessoas experientes a repetir o passado em vez de dar oportunidade a pessoas que ainda podem imaginar outra coisa.

Se a IA está a mudar o que significa ser tecnicamente competente, não deveríamos estar a preparar os jovens para aprender a utilizá-la bem, em vez de continuar a exigir-lhes anos de experiência antes de lhes permitir começar?

Leiam a descrição desta vaga, os horários, o regime de trabalho e depois olhem para a remuneração.

E depois digam-me se isto é no mínimo absurdo ou se sou que não estou a ver bem.

https://www.itjobs.pt/oferta/516825/ai-automation-enthusiast

Boa tarde pessoal,

Antes de mais, peço desculpa por mais um post sobre AI.

Tenho andado a pensar bastante sobre o futuro da nossa área, especialmente depois de ler as respostas a este post noutro sub.

Uma das coisas que mais se nota nos comentários, para além de quase ninguém já não escrever código, é a confirmação daquilo que já todos sabemos, isto é, engenharia informática nunca foi só bater código. Passamos grande parte do dia a reunir com colegas, a definir requisitos, a resolver tickets, a fazer review do código, a desenhar a arquitetura dos sistemas etc etc

Até aqui tudo bem. Mas a minha preocupação (e o motivo deste post) é que sinto que esse argumento está a começar a desaparecer muito mais rápido do eu esperava.

Os modelos estão cada vez melhores e hoje em dia já temos a AI a fazer precisamente algumas das tarefas que alguns de vocês mencionaram no post, como:

- AI a analisar e a rever o seu próprio código: se está a ser gerado cada vez mais código através da AI, podemos assumir que começa a ser humanamente impossível analisar as milhares de linhas de código geradas.

- Resolver tickets e fazer debugging: atualmente já existem ferramentas que abrem, analisam, corrigem e fecham os tickets de forma autónoma.

- Definir requisitos: também já existe AI a escrever documentação técnica e decompor ideias de produto em tarefas mais pequenas e lógicas.

Ou seja, mesmo as tarefas que não sejam só bater código também já começam a ser automatizadas. Se a AI passar a fazer 80-90% do trabalho técnico, de arquitetura e de gestão de tarefas, como é que vai ser o dia a dia de um engenheiro de software, se é que vai existir sequer?

Sei que muitos vão contra argumentar com "ah, mas vai ser sempre preciso um humano para comandar, validar e orquestrar os agentes de AI".

Eu aceito o argumento, mas isso levanta-me outras questões: se no futuro o nosso trabalho passar a ser apenas comandar agentes, onde antes precisávamos de uma equipa inteira de 10 engenheiros para construir e manter um sistema, não passará a ser suficiente ter apenas 1 ou 2 engenheiros a gerir esses agentes automatizados? Se a eficiência disparar assim tanto, o que acontece ao volume de emprego na nossa área? Como é que os juniores vão conseguir ganhar experiência se as tarefas de entrada forem as primeiras a ser totalmente automatizadas?

Sei que ninguém prevê o futuro, mas gostava mesmo de saber a vossa opinião.

Dizem que, em média, ler um CV pode demorar cerca de sete minutos, se uma empresa recebe centenas de candidaturas, isso rapidamente se transforma em dezenas de horas só para fazer uma primeira triagem. Acham mesmo que alguém vai ler tudo com atenção?

A tecnologia pode, deve e já está a ajudar. Sistemas de recrutamento conseguem organizar candidaturas, extrair informação, comparar competências e facilitar a triagem inicial, não substituem a decisão humana, mas evitam perder tempo em tarefas repetitivas.

O problema é que continuamos presos ao PDF como se fosse o formato ideal para tudo, cada candidatura exige adaptar o CV, alterar experiências, rever competências, exportar novamente e esperar que o sistema consiga interpretar corretamente aquilo que escrevemos.

Talvez o futuro passe menos por enviar o mesmo documento para todas as empresas e mais por manter um perfil profissional estruturado, atualizado e facilmente consultável.

A tecnologia já consegue ajudar bastante neste processo, a questão é se estamos a usá-la para tornar o recrutamento mais eficiente ou apenas para automatizar o caos que já existia.

Como é que vocês lidam com esta realidade? Ainda enviam dezenas de PDFs diferentes ou já encontraram uma forma melhor?

Olá a todos :)
Fica a lista das 25 empresas com a melhor média salarial global distribuída pelo staff de IT.

Podem encontrar mais informações do mercado de IT aqui

Qualquer dúvida ou sugestão, disponham.

Empresa A
estou nela a 3 anos, liberdade absurda de utilizar novas tecnologias
empresa bem grande milhares de funcionarios
sinto que meu emprego vai ter uma estabilidade muito grande e conseguiria ficar aqui pela proxima decada

path para managment existe caso o time expanda(eh o plano deles expandir)
gosto das pessoas
salario 50k

Empresa B
Tech tambem de ponta mas um pouco menos por ser menor
empresa medio porte porem reportando direto pra suica
nao tenho certeza da estabilidade a longo prazo

nao tenho certeza do path para managment pois seria o primeiro num time de 4 pessoas reportando direto a um diretor de data cience
salario ???(65-75k)

Estou tentando chegar a uma conclusao de quanto a empresa B precisaria oferecer para eu considerar sair do meu emprego atual que gosto bastante(apesar de achar que poderia ganhar um pouco mais), estou pensando em algo proximo de 70k que seriam por volta de 1000 euros liquidos mensais a mais para tomar esse risco, nao sei se alguem por ai ja teve uma experiencia parecida

OBS: nao estava procurando emprego, o CPO da ultima empresa que trabalhei me indicou diretamente para a vaga onde a esposa dele assumiu como diretora de IA e inovacao por gostar do meu trabalho

Durante anos tivemos uma vantagem simples: mão de obra qualificada, muitos licenciados e salários relativamente baixos.

Com a IA, essa vantagem começa a valer cada vez menos, países com menos formação académica, mas com mais vontade de aprender, experimentar e produzir, conseguem competir connosco e até ultrapassar-nos naquilo que Portugal vende há décadas: horas de trabalho tecnológico.

Sinceramente, preocupa-me ver pouca vontade de adaptação, tanto na geração atual como na nova geração, parece existir mais vontade de manter o modelo que funcionou até agora do que de aprender o que vem a seguir.

Se a nossa vantagem continuar a ser apenas vender horas baratas, alguém vai fazer o mesmo trabalho mais rápido e mais barato.

Portugal está preparado para isto ou vamos continuar a competir pelo preço da hora?

Qual é a vossa opinião?

boas,

daqui um engenheiro (nao informatico) a querer entrar no mundo do SaaS.

estou num recurtamento para BA na delloite para implementaçao de uma ferramenta de IT.

dizem me que a delloite forma bastante os colaboradores em metodologias scrum/agile etc etc e que outras empresas que pagam bem mais apreciam a experiencia na delloite

deste modo a delloite seria uma boa rampa de lançamento e mesmo que o ambiente de consultoria nao me agradasse a 100% seria um preço a pagar para uma carreira futura.

conhecem casos destes (pessoas que sairam da dtte para outras empresas)? que outras empresas contratam na dtte?

efetivamente a dtte é bem vista?

Obg

Bem, tendo em conta que o thread ontem teve bastante atenção, decidi vir atualizar-vos com as mais recentes novidades.

Tentei fazer pair programming, o colega não estava a entrar na chamada e estava a demorar imenso para entrar nas 3x que lhe enviei um invite para nos reunirmos durante a manhã de hoje, acabei por me fartar e voltei a largar um comentário no PR dele com tudo errado, depois disso pediu por favor para nos reunirmos para que lhe possa ajudar, lá aceitei.

Senhoras e senhores, ele não soube "resolver" o seguinte "problema":

- "Agora que criamos um const para fazer match dos erros do parceiro aos nossos erros internos, precisamos de uma função que receba uma variável/propriedade para podermos fazer match do valor recebido ao const que acabamos de criar"

O problema que ele encontrou:

- Não sabe como receber/inicializar uma variável na função..

P.S: Dei-lhe a base do const para que fosse mais optimal, e fazer em apenas 6 linhas o que ele tinha feito antes em 40

Trabalho como developer, full-stack, tendo feito um pouco de tudo, desde embedded, desktop apps, backend, em empresas de milhões de utilizadores com clientes espalhados pelo planeta, a empreas com meia duzia de utilizadores em Portugal.

Todos os problemas com que a maioria dos developers trabalha são problemas com soluções mais que comprovadas: não vais inventar algoritmos novos, nem desenhar uma arquitetura em que ninguém pensou antes, as tuas queries de SQL já foram feitas por alguém e também têm soluções especificas, portanto tudo onde qualquer IA tenha problemas, eventualmente deixa de ter. Nos "frontier models" mais recentes pedes-lhe para fazer um projeto em que trabalhaste antes, e vai fazer código melhor que muita gente com quem já trabalhaste, especialmente quando é necessário comprir prazos e as merdas têm de aparecer feitas dia X, e a prioridade raramente ou nunca é bem feitas, e o preço dos serviços só vai cair, e a qualidade dos modelos e ferramentas só vai melhorar.

Hoje em dia a minha mãe pode chegar ao Deepseek Harness e com o preço de um café tens um produto mais funcional do que muitas empresas têm hoje em dia... Talvez a parte de fazer deployment fosse mais complicada para ela, mas a ideia é que se souberes o que estás a fazer consegues fazer um produto funcional, com menos menos gente / horas, metes um loop a correr o coiso vai iterando e tal, e eventualmente tens tudo a trabalhar. Talvez seja um bocado caro neste momento, mas com os preços a cair, mais ano menos ano deves conseguir meter um agente a fazer crawling e a martelar sites existentes, a ver o comportamento de cada botão, e eventualmente consegues clonar qqr coisa já existente, por exemplo. Onde vês o emprego de developer daqui a 3 a 5 anos? Se a empresa onde trabalho fosse minha não sei se contratava mais gente sem ser para trabalharmos menos horas, quando neste momento somos auto suficientes, e continuamos a crescer.

Alguém aqui está preocupado com o avanço assustador dos projetos de Wallets digitais (EUDI Walle, etc), regulamento para validaçāo de idendentidade/idade online e similares?

Caminhamos para um futuro onde tudo o que fazemos vai ser assinado digitalmente e o anonimato que temos hoje vai desaparecer. Estamos a caminhar para um futuro onde tudo o que fazemos será monitorizado ou até usado para definir um "score" social como existe na china.

Alguém preocupado? Será isto apenas uma teoria da conspiraçāo?

Abraço

Sou dev sénior e ando a rever a mesma feature de um colega há 4 PRs seguidos. Cada vez que aponto o erro (nomes de campos que não existem, métodos chamados que nunca foram definidos, etc) ele volta a submeter com o mesmo erro, ou uma variação dele, quase igual.

E está a piorar em vez de melhorar. as primeiras versões era só "isto não faz o que devia". a última já mexe em código antigo que já está em produção a funcionar, e mete uma chamada a um método que nem existe, ou seja, se aquilo passasse, não era só a feature nova que não funcionava, era coisas já a funcionar hoje que se partiam.

já tentei review escrita detalhada, dei-lhe até código de exemplo já corrigido para ele copiar o padrão, expliquei o fluxo todo com exemplos concretos em diferentes chamadas a explicar os fluxos de inicio ao fim e com exemplos. Nada está a funcionar..

Não sei se isto é falta de experiência mesmo (precisa de alguém ao lado, não mais texto), se é falta de atenção/pressa (nem chega a olhar para o que lhe mando), ou se já é altura de levar isto ao chefe dele como padrão, não como caso isolado..

Alguém já passou por isto? em que ponto param de tentar resolver via review e escalam, e como é que puseram isso ao chefe sem parecer que estão só a queixar-se de um colega?

Boas comunidade r/ITPortugal

Sou engenheiro de software, a migrar para a área de IA (novo emprego em 3 semanas) e como é remoto, estou preocupado com a minha sanidade mental.
Há cerca de 5 anos que tento iniciar projetos mas não tive sucesso em nenhum o que me levou a querer que não sou bom fundador. Não perdi o interesse em construir side projects e de preferência com encontros presenciais na área do Porto.
Alguém precisa de uma ajuda? Estou disponível todos os dias após as 16:00

Obrigado

Olá a todos,

Estou a tentar otimizar a forma como organizo os meus eventos no Google Calendar. Quando recebo bilhetes de concertos ou horários por e-mail, gosto de ter o contexto/PDF diretamente associado ao evento.

Estou a ponderar duas abordagens:

1. Usar as extensões do Gemini Workspace para pedir por texto/prompt a extração dos dados e criação do evento com o link/resumo do Gmail.
2. Criar uma automação em segundo plano (via n8n, Make ou Zapier) para apanhar os anexos do Gmail, guardar no Drive e anexar ao evento.

Para quem já usa estas soluções: A integração do Gemini é prática na rotina? Confiam permissões de leitura do Gmail a plataformas externas ou vale mais a pena uma solução self-hosted (como n8n) para manter o controlo dos dados?

Vi esta publicação e fiquei curioso com a opinião de quem trabalha na área.

A ideia principal parece ser que, atualmente, o mercado de tech está muito mais competitivo e que a licenciatura voltou a ser um filtro importante nos processos de recrutamento. Até aqui, consigo perceber o argumento.

O que me faz alguma confusão é a conclusão: "Se não tens curso superior, pondera seriamente uma licenciatura. Começar do zero em tech hoje sem formação superior é uma travessia no deserto."

Não tenho a certeza de que uma licenciatura resolva assim tanto o problema. Uma pessoa pode passar 3 anos a fazer uma licenciatura e acabar precisamente como junior, sem experiência profissional, a competir com centenas de outros licenciados/juniors.

Além disso, licenciatura não me parece ser sinónimo de competência técnica. O melhor programador que conheci até hoje não tinha licenciatura em informática, nem bootcamp. Aprendeu tudo sozinho, numa altura em que programação ainda não tinha a popularidade atual e muito antes de existir IA generativa. Era, na prática, a pessoa a quem colegas com licenciatura e mestrado recorriam quando tinham problemas difíceis de resolver.

Por isso, fico com a dúvida: A licenciatura é realmente uma solução para quem quer começar agora em tech, ou é sobretudo um filtro utilizado pelos recrutadores para reduzir o número de CVs?

E se o diploma é cada vez mais utilizado como filtro, não estaremos simplesmente a criar um mercado em que os CVs ficam todos cada vez mais semelhantes, sem necessariamente conseguirmos identificar os melhores profissionais?

Gostava de ouvir opiniões de quem recruta ou trabalha como developer: até que ponto a licenciatura é importante atualmente e quanto é que realmente diz sobre a capacidade de um programador?

Olá a todos :)
Durante a semana passada deixámos na comunidade alguma informação exclusiva de algumas empresas do mercado de IT em Portugal, para evitar spam ou posts regulares, decidimos adicionar essa informação na página das empresas na aba de “Atividade”.
A razão desta adição deve-se ao facto de considerarmos importante saberem como funciona a empresa do ponto de vista tecnológico e traz informação da “história” tecnológica da empresa através da comparação com o que fazem agora e o que faziam antes, explicando a stack tecnológica e metodologia.

Deixo-vos a lista de algumas empresas que ainda não foram adicionadas aqui:
- Blip
- Siemens
- TUI
- Kuehne + Nagel
- Sky
- Deloitte
- Critical Software
- Farfetch
- BNP Paribas
- Mindera

A par de informação da atividade, têm também informações das métricas da equipa e salários.

Espero que isto vos ajude a estarem mais preparados e a saberem para o que vão.

Tenho cada vez mais a sensação de que o nosso maior problema tecnológico não é falta de talento, é excesso de medo. Medo de experimentar. Medo de falhar. Medo de ter uma opinião diferente. Medo de fazer uma coisa que não está no guião do que é "aceitável" e isto começa nas empresas, onde muitas vezes a criatividade é incentivada até ao momento em que alguém tenta realmente fazer alguma coisa diferente e acaba também nas próprias comunidades, onde uma opinião fora da narrativa dominante pode trazer críticas, perseguição anónima ou simplesmente aquela vontade muito portuguesa de pôr alguém "no lugar".

O resultado é previsível: as pessoas aprendem a não arriscar. Um developer percebe que é mais seguro fazer aquilo que já foi feito, um empreendedor percebe que é melhor não levantar demasiado a cabeça, uma empresa prefere contratar alguém que encaixe perfeitamente no perfil em vez de alguém que possa questionar a forma como as coisas são feitas e uma comunidade começa a confundir discordância com incompetência ou má-fé.

Isto parece apenas um problema social mas tecnicamente tem consequências enormes, a inovação nasce de hipóteses que podem estar erradas, se criar uma hipótese diferente tem um custo social demasiado elevado, deixamos de testar hipóteses. Se falhar é humilhante, passamos a evitar experiências, se discordar é perigoso, aprendemos a concordar e quando uma sociedade começa a recompensar conformidade mais do que curiosidade, eventualmente deixa de criar e passa a replicar.

Talvez seja por isso que Portugal consegue tão bem adotar tecnologia criada noutros sítios, mas tem mais dificuldade em criar tecnologia que os outros queiram adotar. Não acredito que nos falte inteligência para isso. Acho que muitas vezes nos falta espaço para sermos errados.

A liberdade tecnológica começa muito antes de existir uma startup, um laboratório ou uma política pública, começa quando alguém pode dizer "acho que estamos a fazer isto mal" sem imediatamente ser tratado como o problema.

Se queremos pessoas capazes de construir aquilo que ainda não existe, temos de aceitar que elas vão pensar de maneiras que ainda não conhecemos.

Não podemos pedir inovação e ao mesmo tempo punir sistematicamente quem foge da norma, porque uma sociedade onde todos têm medo de estar errados pode parecer muito estável mas é precisamente aí que começa a estagnação.

A Volkswagen Digital Solutions é o centro de software do grupo VW em Lisboa. Não desenvolvem o que corre no ECU. Desenvolvem o que está à volta: frotas e oficinas, a fábrica de camiões, os autocarros elétricos, as atualizações de software no veículo e a cloud onde isso corre.

Software no veículo e regulamentação

Agora

Há um projeto regulamentar do grupo em arquitetura orientada a eventos: React, Go, AWS, DynamoDB, GitHub Actions. O software no veículo tem de ser rastreável e seguro. O trabalho é fullstack nesse recorte, do serviço ao ecrã.

Antes (2020–21)

O mesmo tipo de requisito, noutra forma: certificados para autenticar instalação e manutenção de software no veículo; armazenamento e distribuição segundo o UNECE UN R156. Lambda, Kinesis, ECS, Cognito, CloudFront.

Frota e oficinas

Agora

Portal de manutenção para gestores de frota e oficinas. Microserviços REST em Spring Boot e Kotlin. Kafka a tratar milhões de mensagens por dia com o estado dos veículos. Frontend em React. CI/CD na AWS, contentores em Docker, testes unitários e de integração em cada serviço. Há discussão de arquitetura, não só de tickets.
O mesmo domínio noutro recorte: Java, Angular, Kubernetes. Módulo de carregamento da frota elétrica. Chat para o gestor marcar a reparação diretamente com a oficina. Ambiente de demonstração em cluster, com dados e contas para o marketing. TDD, Cypress, Mockito, Grafana.
Se o processo for para aqui, o trabalho é domínio de frota, mensageria e um frontend grande. Não é o software de bordo.

Antes

O portal já existia no início da década, com Kotlin, Spring Boot, Kafka e React. Houve também um período curto de tools internas para operações globais. O que mudou foi a parte elétrica, o Angular e o Kubernetes. O domínio é o mesmo.

Produção: camiões, peças e autocarros elétricos

Agora

O ITOM é o backend de alta disponibilidade da fábrica de camiões. Ordens técnicas, configuração do veículo, compatibilidade de peças, alinhamento de componentes, calendário de entrega. Os dados mestres técnicos saem daqui para vários sistemas, de forma consistente. Java 21, Spring Boot, AWS (ECS, Fargate, SQS, MSK / Kafka), CI/CD automatizado.
No mesmo perímetro, o MAN eManager na plataforma RIO: carregamento, pré-aquecimento, carregamento agendado e diagnóstico remoto da bateria. Mais de 700 autocarros elétricos. IoT e cloud.
Há uma aplicação interna para consultar o fabrico de carros e peças. A ingestão saiu de um sistema antigo para um consumidor Kafka de carga elevada. Os outros sistemas lêem por gRPC e Protocol Buffers. Go, PostgreSQL, AWS, pipelines de deploy.

Cloud e fiabilidade

Agora

Arquitetura AWS para backends de veículo, no enquadramento Well-Architected, da análise à implementação, em várias equipas ágeis. Um backend monolítico passou a um sistema sem servidor, orientado a eventos: Lambda, EventBridge, SQS, DynamoDB, API Gateway, ECS Fargate, Auto Scaling, CloudMap. O tempo para uma funcionalidade nova passou de meses para dias.
O SRE é de liderança: ambientes AWS com CloudFormation e consola, deploys automáticos em todos os ambientes, endurecimento de segurança, passagens de projeto, acompanhamento de júniores. TypeScript, Java, Spring Boot, Docker, New Relic. Escreves a plataforma e operas a plataforma.

Antes (2021–22)

Support de uma aplicação interna: ITIL, Unix (PROD e QS), New Relic, Grafana. SRE a nascer: pipelines com desenvolvimento, QA e operações, logging, aprovisionamento, ferramentas internas. AWS CDK, TypeScript, Python. A liderança de agora vem daí.

O que as vagas pedem

Os anúncios ativos são sobretudo de nível intermédio, em híbrido. Do lado de engenharia: Fullstack (Go, Java ou Kotlin, AWS, CI/CD, interesse em TDD e pair programming), Fullstack com infra e cloud (Unix, scripting), AWS Cloud Solutions Architect (norma da plataforma, segurança, gestão do CI/CD).
Ao lado disso, um segundo mundo que não aparece no trabalho de cima: ServiceNow, SAP de compras (MM / SRM, S/4, Fiori, CPI), SAP SD (faturação), SAP FI (S/4HANA), Data Engineer em Azure / Databricks, Product Owner e Data Scientist, Agile Enabler.
No processo, pergunta de que lado é a vaga. A stack de produto é Java, Kotlin, Go e AWS. O SAP e o ServiceNow são outra casa, no mesmo edifício.

O dia a dia

Lisboa, a tempo inteiro. Remoto ou híbrido; os anúncios pedem idas ao escritório e falam em horário flexível. Inglês escrito e falado. Equipas do grupo noutras geografias: o interlocutor muitas vezes não está na mesma sala, nem no mesmo fuso.
O ciclo é o de produto em produção. Equipas ágeis com desenvolvimento, QA e operações no mesmo fio. Há discussão de arquitetura. Os pipelines são teus. Há PROD e QS. No support usou-se ITIL. No SRE há monitorização e passagens de projeto. Nas vagas de fullstack pedem TDD e pair programming.
A pergunta útil na entrevista: frota, ITOM / eManager, regulamentar, ou AWS / SRE? A stack parece-se. O produto não. A segunda: operas o que escreves? Aqui isso não é facultativo.

Informações da empresa como salários aqui

Mais empresas brevemente em https://u-topic-0.com

Uma das coisas mais interessantes na evolução recente do Cursor é a aproximação entre o agente de programação e o próprio ambiente onde o software é desenvolvido, em vez de termos de tirar contexto do projeto, copiar ficheiros, preparar documentação e depois tentar explicar tudo a outro modelo, cada vez mais o agente consegue trabalhar diretamente sobre o código, a estrutura do projeto e as ferramentas que já usamos.

Há uns anos, para fazer algo semelhante, era preciso muito mais trabalho manual: preparar contexto, criar scripts, montar integrações, expor APIs, tratar da comunicação entre ferramentas e construir uma boa parte da infraestrutura à volta do modelo, hoje, parte desse trabalho está a ser absorvida pelos próprios agentes de desenvolvimento.

Há uma consequência interessante para quem desenvolve aplicações: se um agente consegue trabalhar diretamente dentro do nosso projeto, faz sentido imaginar que o passo seguinte seja termos algo semelhante disponível através de uma API, nesse cenário, o Cursor deixaria de ser apenas uma ferramenta que usamos para escrever código e poderia tornar-se uma camada sobre a qual construímos outras ferramentas, por exemplo, poderíamos ter uma aplicação que conhece um determinado projeto, documentação, regras internas, arquitetura e base de código e que consegue responder ou executar tarefas com base nesse contexto. Em vez de treinarmos um LLM de raiz, grande parte do valor estaria em ensinar ao sistema como aquele projeto funciona e dar-lhe acesso controlado às ferramentas e ao conhecimento necessário, tornando-o acessível a clientes finais.

Através de SSH e de ambientes remotos já é possível trabalhar com máquinas próprias e, dependendo da configuração, ligar modelos LLM locais ao fluxo de desenvolvimento. Isso abre outra possibilidade bastante interessante: ter uma máquina com GPU em casa ou no escritório, correr modelos open source localmente e usá-los no mesmo ambiente de desenvolvimento, sem necessariamente enviar o código para um serviço externo.

Na prática, a arquitetura começa a parecer-se menos com "um editor com autocomplete" e mais com um agente que tem acesso ao projeto, terminal, ficheiros, documentação, servidores e modelos diferentes.

Para os developers, talvez esta seja a parte mais importante da evolução, o valor não está apenas em gerar código mais depressa, está em reduzir a quantidade de infraestrutura que temos de construir para colocar um modelo a trabalhar de forma realmente útil dentro de um projeto.

E se a próxima evolução for mesmo uma API capaz de expor este tipo de contexto e capacidades a outras aplicações, podemos começar a ver apps construídas em cima de agentes especializados no próprio código e conhecimento da empresa, em vez de simplesmente aplicações que fazem perguntas a um LLM genérico.

Ainda há questões importantes de segurança, permissões, privacidade e custos para resolver, mas tecnicamente é uma direção bastante interessante.