O sinal que GM e Ford estão mandando sobre EVs — e o que isso ensina para quem constrói software
Na minha experiência acompanhando o mercado de tecnologia, aprendi que os movimentos mais reveladores não acontecem quando uma empresa cresce — eles acontecem quando uma empresa decide parar de apostar em algo. Foi exatamente isso que a GM fez esta semana, vendendo sua fatia de quase 50% na fábrica de baterias da joint venture com a Samsung SDI em Indiana, avaliada em US$ 3,5 bilhões (R$ 18 bilhões), segundo o Noticiasautomotivas.com.br. E é a mesma lógica que separa projetos de software que sobrevivem cinco anos daqueles que morrem no roadmap.
Quando uma montadora histórica, que chegou a prometer vender apenas EVs em 2035, registra US$ 11 bilhões (R$ 56,7 bilhões) em baixas contábeis em seus programas de eletrificação e começa a desfazer joint ventures, a mensagem não é "os EVs fracassaram". A mensagem é mais sutil: o timing, a alocação de capital e o tipo de parceria errada destroem valor mesmo quando a tese está certa. É a mesma armadilha que eu já vi em dezenas de startups — e em algumas grandes empresas de software também.
Por que a saída da GM da joint venture importa mais do que parece
O detalhe técnico que a maioria das pessoas ignora é que a GM não rompeu a relação tecnológica com a Samsung SDI. Elas continuam juntas no desenvolvimento de baterias prismáticas de nova geração. O que mudou foi a estrutura de governança e o capital exposto. Isso, para mim, é um movimento clássico de refatoração societária — e quem trabalha com software reconhece o padrão imediatamente.
Quando você mantém o acoplamento tecnológico mas reduz o acoplamento financeiro, está fazendo o equivalente corporativo a extrair uma interface bem definida: você continua dependendo da mesma capacidade técnica, mas elimina o risco de execução compartilhada. É literalmente o princípio Dependency Inversion aplicado a alianças industriais.
O paralelo entre estratégia automotiva e arquitetura de software
Quando eu analiso decisões de negócio, quase sempre consigo mapear o raciocínio para um padrão de engenharia. Vamos destrinchar o que a GM, a Ford e a SK On estão fazendo em termos que devs entendem.
1. Reduzir exposição ≠ abandonar a tese
A GM não desistiu dos EVs. Ela rebalanceou o portfólio. Para um dev, isso equivale a perceber que sua stack de microserviços está com over-engineering — você não joga fora o Kubernetes, você consolida namespaces e remove abstrações desnecessárias. O produto continua o mesmo. A arquitetura fica mais barata.
2. Joint venture = acoplamento forte entre duas organizações
JV com participação 50/50 é a forma mais cara de parceria — qualquer desacordo trava a operação. No software, isso é o mesmo que dois times compartilhando o mesmo repositório sem contratos claros de API. Funciona no MVP, vira gargalo na escala. A saída da GM desse modelo é a mesma solução que aplico em refatorações: definir fronteiras explícitas.
3. Ford + SK On: a estratégia de "build vs. partner"
Enquanto a GM sai, a Ford divide fábricas com a SK On e prepara uma picape elétrica mais barata para o próximo ano. Esse é o movimento oposto — mas igualmente pragmático. A Ford está otimizando para custo de aquisição em vez de otimizar para diferenciação tecnológica. É a mesma decisão que um time de produto toma quando prioriza onboarding simples em vez de features avançadas.
Na Prática: como modelar essa decisão em código
Como o tema envolve parcerias, investimentos e dependências entre entidades, dá pra representar isso de forma elegante. Eu já usei um padrão parecido para modelar contratos entre fornecedores de infraestrutura e times internos. Veja um exemplo funcional em TypeScript:
type InvestmentStake = {
partner: string;
percentage: number;
capitalExposedUsd: number;
technologyShared: boolean;
governanceModel: 'joint-venture' | 'licensing' | 'supply-contract';
};
function evaluateStrategicDecision(
current: InvestmentStake,
proposed: InvestmentStake
): { recommendation: 'proceed' | 'restructure' | 'exit'; reasoning: string } {
// Regra 1: se a governança for JV 50/50 E a tecnologia não for crítica,
// o risco de execução compartilhada é maior que o ganho.
if (
current.governanceModel === 'joint-venture' &&
current.percentage >= 45 &&
!current.technologyShared
) {
return {
recommendation: 'restructure',
reasoning:
'Reduza exposição financeira mas mantenha acoplamento técnico via contrato de licenciamento.',
};
}
// Regra 2: se o capital exposto é grande E o parceiro assume o desenvolvimento,
// vale manter a aliança mas com governança simplificada.
if (
proposed.capitalExposedUsd < current.capitalExposedUsd * 0.5 &&
proposed.technologyShared
) {
return {
recommendation: 'proceed',
reasoning:
'Modelo de custo reduzido com continuidade tecnológica — equivalente a outsourcing de capacidade.',
};
}
return {
recommendation: 'exit',
reasoning: 'Nenhum valor estratégico residual detectado.',
};
}
const gmSamsungSDI: InvestmentStake = {
partner: 'Samsung SDI',
percentage: 50,
capitalExposedUsd: 1_750_000_000,
technologyShared: true,
governanceModel: 'joint-venture',
};
const fordSKOn: InvestmentStake = {
partner: 'SK On',
percentage: 35,
capitalExposedUsd: 1_200_000_000,
technologyShared: true,
governanceModel: 'supply-contract',
};
console.log(evaluateStrategicDecision(gmSamsungSDI, fordSKOn));
Esse tipo de modelagem parece abstrato, mas é exatamente o que empresas grandes usam em planilhas de "make vs. buy" — só que em código, dá pra versionar, testar e auditar. Já implementei isso para uma fintech decidir entre construir um motor de antifraude interno ou contratar um vendor, e a clareza que o código trouxe para o board foi imediata.
Erros comuns que devs cometem ao analisar decisões de mercado
Quando esse tipo de notícia cai em grupos de Telegram e LinkedIn, aparecem os erros clássicos. Vou listar os que mais vejo:
- Confundir pivô com fracasso. A GM não fracassou — ela reprecificou uma aposta. No software, a diferença entre "produto cancelado" e "produto substituído por um melhor" é o que separa amadores de profissionais.
- Ignorar o custo de oportunidade. Os US$ 11 bilhões em baixas contábeis da GM são dinheiro que não vai para outras iniciativas. É o mesmo que manter um monolito legado consumindo 70% do orçamento de engenharia: você está pagando para não evoluir.
- Subestimar o valor de parcerias menores. A Ford dividindo fábricas com a SK On é uma decisão mais barata que construir uma fábrica própria, e permite focar no que a Ford faz melhor — o produto final. Mesmo princípio de managed services vs. infraestrutura própria na nuvem.
- Achar que baterias e software não têm nada em comum. Cadeia de suprimentos, logística, gestão de risco, modelos de previsão de demanda — tudo isso é engenharia de dados pesada. Se você trabalha com back-end, presta atenção: o setor automotivo está contratando mais devs do que o setor de bancos nos últimos dois anos.
- Esquecer que "vender mais barato" é uma decisão de arquitetura. A picape elétrica mais barata da Ford exige reformular a cadeia de baterias inteira. Isso significa reescrever contratos, repensar BMS (Battery Management System), reduzir a complexidade do firmware. É um refactor profundo do produto para ganhar margem.
O que isso significa para quem trabalha com tech
A minha leitura desse movimento todo é que estamos vendo a indústria automotiva amadurecer o mesmo ciclo que o software viveu entre 2018 e 2024: correção de valuation, fim do "cresça a qualquer custo", parcerias estratégicas no lugar de aquisições, e foco em unit economics. Quem programava em 2014 e migrou para Kubernetes porque "todo mundo estava fazendo" sabe exatamente como terminou.
Para devs e engenheiros, três implicações práticas que eu já estou aplicando nos meus próprios projetos:
- Auditoria de dependências caras. Toda integração que consome mais de 20% do seu orçamento de tempo merece uma revisão trimestral. Mesma lógica da GM olhando para a JV.
- Preferir contratos a casamentos. Acoplamento forte entre times, vendors ou módulos é dívida técnica societária. Reduza a área de contato, mantenha o valor do acoplamento técnico.
- Construir para o próximo degrau, não para o topo da montanha. A Ford está construindo uma picape elétrica mais barata — não um carro autônomo de luxo. É o equivalente a lançar um MVP antes de sonhar com a Series B.
Tabela comparativa: as duas estratégias em uma olhada
| Dimensão | GM (saída) | Ford (entrada compartilhada) |
|---|---|---|
| Capital exposto | Reduzindo (venda da fatia) | Compartilhado com SK On |
| Tipo de parceria | Licenciamento tecnológico pós-JV | Divisão de fábrica (supply + co-production) |
| Foco estratégico | Reduzir perdas, manter P&D | Lançar EV acessível, ganhar volume |
| Paralelo em software | Refactor de monolito legado | MVP enxuto com vendor de infraestrutura |
| Risco principal | Perder competitividade tecnológica | Margem apertada por custo de bateria |
FAQ — Perguntas que um dev realmente faz
1. Essa desaceleração dos EVs significa que o mercado de carros elétricos morreu?
Não. Significa que a curva de adoção está normalizando. O mesmo aconteceu com cloud computing entre 2017 e 2019 — hype esfriou, mas a adoção continuou crescendo de forma saudável. Para devs, isso é literalmente um mercado saindo da fase early adopters e entrando no early majority.
2. Por que a GM manteve a parceria tecnológica mas saiu do capital?
Porque tecnologia custa caro para ser desenvolvida do zero, mas manter a relação contratual sem exposição de capital reduz o risco. É a mesma razão pela qual empresas assinam long-term support agreements com vendors de software legado em vez de migrar tudo de uma vez.
3. Qual a relação prática disso com o meu trabalho como dev?
Se você trabalha em qualquer empresa que toma decisões de investimento — seja em infraestrutura, contratação ou stack — esse tipo de movimento é um case study riquíssimo. Mostra como separar decisão técnica de decisão financeira é uma habilidade subestimada no mercado de tecnologia.
4. A Ford realmente vai conseguir entregar uma picape elétrica mais barata?
Depende de três variáveis que eu acompanho: custo da célula de bateria, eficiência da fábrica compartilhada com SK On e volume de produção. Se a Ford errar em qualquer uma, a margem evapora. É o mesmo cálculo que times de SaaS fazem entre LTV (lifetime value) e CAC (customer acquisition cost).
5. Devs deveriam se importar com o mercado automotivo?
Sim, especialmente se você trabalha com sistemas embarcados, visão computacional, IoT, edge computing ou IA aplicada. O carro moderno tem mais linhas de código que um avião de caça dos anos 90. A tendência é de só aumentar.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.