Fundamentos que precisam permanecer fortes

5.1. Compreensão de código: semântica antes de memória

O engenheiro precisa ler um trecho e compreender o que ele faz, quais estados modifica, que suposições usa e como pode falhar. Isso exige familiaridade com tipos, escopo, mutabilidade, tratamento de erros, recursos, concorrência e modelo de execução da linguagem relevante ao seu trabalho.

Esse domínio permite selecionar o que investigar e quais controles exigir. Ele não pressupõe releitura humana integral de toda a produção dos agentes; a seção 7 descreve como distribuir verificação e atenção.

A IA pode produzir a sintaxe de uma rotina assíncrona. O julgamento necessário inclui perceber se o cancelamento é propagado, se uma tarefa fica órfã, se exceções se perdem e se recursos são liberados. Esses problemas exigem um modelo mental da execução.

Critério prático: diante de código novo, conseguir prever um comportamento importante, criar um caso que confirme ou refute a previsão e explicar o resultado. É possível usar IA na investigação; o entendimento precisa se tornar demonstrável.

O currículo CS2023, elaborado por ACM, IEEE-CS e AAAI, já distinguia a mudança de atividades da permanência dos fundamentos: maior abstração, compreensão, verificação e decomposição convivem com a necessidade de avaliar algoritmos e programas. É uma orientação curricular de especialistas, publicada em 2024, e não uma medição das capacidades atuais dos modelos. F14

5.2. Algoritmos, complexidade e representação

O estudo de algoritmos deve servir à escolha e à avaliação. Interessa reconhecer quando uma estrutura de dados muda a ordem de grandeza do custo, quando o volume torna uma implementação inviável e quando uma aproximação altera a resposta do produto.

Um engenheiro pode delegar a escrita de uma busca ou de uma ordenação e ainda precisar identificar que a composição de duas operações aparentemente simples criou um custo quadrático. Também precisa distinguir desempenho assintótico de custos concretos: alocação, rede, disco, cache, serialização e contenção podem determinar o comportamento observado.

Prioridade: entender classes de problemas e limites de recursos, usar medição e examinar casos adversos. A quantidade de algoritmos recitados de memória é um indicador muito limitado desse domínio.

5.3. Modelagem de dados e correção sob concorrência

Dados exigem atenção a significado, identidade, cardinalidade, invariantes, autorização, histórico e evolução de esquema. Uma consulta que executa sem erro pode duplicar registros em um join, misturar clientes ou contar a entidade errada. Uma transação pode ser válida sintaticamente e insuficiente para uma regra de negócio concorrente.

A documentação do PostgreSQL mostra, por exemplo, que o isolamento Read Committed trabalha com snapshots por comando e tem comportamentos específicos diante de atualizações concorrentes. A escolha de isolamento e de restrições precisa ser compatível com o invariante pretendido; “coloque em uma transação” não descreve toda a solução. F28

Critério prático: explicar o que acontece quando duas requisições chegam juntas, quando uma falha depois de gravar e quando uma migração precisa conviver com versões diferentes da aplicação.

5.4. Sistemas distribuídos e efeitos colaterais

Timeout, repetição, ordenação, consistência, filas, controle de carga e falhas parciais continuam sendo parte central de muitos sistemas. O engenheiro deve perceber que ausência de resposta não significa ausência de efeito.

A Amazon Builders’ Library descreve a idempotência como um contrato para permitir repetição de chamadas sem acrescentar o efeito indesejado, com identificação de intenção e tratamento explícito de solicitações repetidas. A habilidade relevante é definir esse contrato e verificar seu cumprimento, inclusive em concorrência. F29

Esse conhecimento também vale para agentes. Se uma ferramenta falha após enviar uma solicitação, tentar novamente pode duplicar uma ação. Ferramentas que expõem identificadores de operação, estados consultáveis e regras claras de repetição permitem recuperação mais confiável.

5.5. Arquitetura como definição de restrições úteis

Arquitetura deve tornar claras as responsabilidades, dependências e decisões difíceis de reverter. Em um ambiente com execução abundante, esses limites ajudam a impedir que soluções locais prejudiquem o conjunto.

Vale aprofundar contratos de APIs, separação de domínio e infraestrutura, compatibilidade, evolução de esquema e isolamento de componentes. O objetivo é permitir mudanças independentes e reduzir o conhecimento necessário para executar cada tarefa corretamente.

É igualmente necessário reconhecer abstração sem benefício. A IA pode produzir camadas, adaptadores e serviços rapidamente; o engenheiro deve exigir uma razão para sua existência. Uma arquitetura precisa responder a necessidades observadas ou restrições concretas. O grau de formalização deve acompanhar a duração e as consequências do sistema.

O tratamento de tempo, escala e escolhas em Software Engineering at Google ajuda a situar esse julgamento: construir software inclui sustentar sua capacidade de mudança ao longo do tempo. F35

5.6. Depuração como investigação causal

Depurar bem envolve formular hipóteses, buscar evidência que as discrimine e reduzir o problema. A IA amplia a capacidade de levantar causas, localizar código e preparar experimentos. Cabe ao engenheiro manter a investigação conectada ao fenômeno real.

Se uma requisição está lenta, é necessário separar espera de CPU, I/O, bloqueio, fila, rede e dependências. Acrescentar cache sem compreender a causa pode esconder o sintoma e introduzir inconsistência. A pergunta útil é qual observação mudaria a hipótese atual.

Exercício de domínio: antes de executar um experimento, prever qual sinal deve mudar se a hipótese estiver correta. Depois comparar previsão e observação. Isso ensina a reconhecer quando uma correção apenas deslocou o problema.

5.7. Operação e observabilidade

O sistema precisa ser compreensível em execução. Logs descrevem eventos; métricas permitem acompanhar comportamentos agregados; traces relacionam etapas de uma operação. OpenTelemetry oferece uma base comum para produzir e correlacionar esses sinais. F31

O engenheiro deve saber escolher os sinais relevantes, interpretar caudas de latência, distinguir erro de sucesso e relacionar uma alteração ao comportamento observado. O capítulo de monitoramento do Google SRE destaca latência, tráfego, erros e saturação, combinando observação interna e experiência externa. F32

Gerar um painel pode ser delegado. Saber se o painel responde à pergunta de operação continua sendo julgamento técnico. Isso inclui limitar dados sensíveis na telemetria e evitar métricas cuja cardinalidade torne a observação cara ou pouco utilizável.

5.8. Produto, domínio e experiência do usuário

Quanto mais fácil implementar uma ideia, maior a necessidade de escolher bem o problema. O engenheiro precisa compreender quem usa o sistema, qual tarefa está tentando realizar, quais restrições importam e como reconhecer melhora.

O framework HEART, apresentado por pesquisadores do Google, propõe traduzir objetivos de produto em sinais e métricas centrados no usuário. É uma referência para conectar engenharia a resultados observáveis. F37

Essa conexão exige competências concretas: conversar com usuários, observar uso, interpretar feedback, negociar escopo e avaliar acessibilidade. Uma tela pode parecer completa e ainda falhar na navegação por teclado, em estados de erro ou na compreensão de uma decisão importante. A IA pode explorar alternativas; os critérios de sucesso precisam representar pessoas reais.