Skip to content

AI-Native Company — Operating System, Not Tool

Tese central: AI não é uma ferramenta que a empresa usa. AI é o sistema operativo sobre o qual a empresa corre. Cada decisão e processo flui através de uma camada inteligente que aprende continuamente. — Diana, partner YC (Abr 2026)

A inversão de framing

A maior parte das pessoas fala de AI em termos de produtividade — "torna engenheiros mais produtivos", "vamos adicionar Copilot aos workflows existentes". Diana argumenta que isto perde a mudança real:

"This framing misses the shift we're currently seeing, which is less about productivity boosts than entirely new capabilities."

A pessoa certa com tools AI agora consegue construir features que antes exigiam uma equipa inteira — ou eram simplesmente impossíveis.

Os 3 pilares do AI-native company

1. Closed-loop processes (em vez de open-loop)

Empresas tradicionais correm como open-loops: tomas uma decisão → executas → não mediste sistematicamente o resultado → não ajustaste o processo. Open-loops são inerentemente "lossy".

Um closed-loop é self-regulating: - Captura informação - Alimenta-a de volta a um sistema inteligente - Melhora o processo ao longo do tempo - Continuously monitors output + adjusts process to better meet stated goal

Implicação prática: cada processo importante na empresa deve ser capturado por um closed-loop AI-driven.

2. Queryable organization (toda a empresa legível para AI)

Para closed-loops funcionarem, toda a organização tem de estar legível à AI. Cada acção importante deve produzir um artefacto que a inteligência central da empresa possa consumir:

  • ✅ Gravar todas as meetings com AI notetaker
  • ✅ Minimizar DMs e emails ad-hoc (vão para canais visíveis)
  • ✅ Embedar agents em todos os comms channels
  • ✅ Custom dashboards para revenue, sales, engineering, hiring, ops — tudo

Princípio: dá ao modelo o contexto que darias a um empregado. Quando fazes isso, info deixa de estar fragmentada e manualmente interpretada — passa a ser auto-actualizada.

Exemplo concreto: Engineering Sprint Planning AI

Se tiveres um agent com acesso a: - Linear tickets (todos) - Slack engineering channels (todos) - Customer feedback (Pylon, GitHub, emails) - High-level plans em Notion / Google Docs - Sales call recordings - Daily stand-up recordings

Então o agent pode: - Analisar o que foi shipped no sprint anterior - Avaliar quão bem cumpriu necessidades reais dos clientes - Propor sprint plans muito mais previsíveis e accurate

Resultado reportado por equipas YC: sprint time cortado a metade, 10× output no mesmo tempo.

"The days of inch managers, status roll-ups that are super-lossy are gone. What used to require constant coordination becomes legible and crawlable by default."

3. Software Factories (evolução do TDD)

Se conheces TDD (test-driven development), software factories são a próxima evolução:

Humano escreve:
  - Spec (o que construir)
  - Tests (como validar sucesso)

AI agents:
  - Geram implementação
  - Iteram até os tests passarem

Humano:
  - Define o quê
  - Julga o output
  - NÃO escreve código manualmente

Exemplo extremo: Strong DM AI team — repos contêm zero código escrito à mão, apenas specs + scenario-based validations + test harnesses. Agents escrevem tests, iteram em código até atingir threshold probabilístico de satisfação.

"This is how you achieve the 1,000× engineer Steve Yegge talks about — by surrounding a single engineer with a system of agents that enables them to build things they would have never been able to build before."

A nova org chart: 3 employee archetypes (Jack Dorsey @ Block)

A hierarquia clássica deixa de fazer sentido. Em vez de mid-managers a fazer routing de informação:

Archetype Função Diferença vs old world
IC (Individual Contributor / Builder-Operator) Constrói e corre coisas directamente Já não é só engenheiros — toda a gente builds. Engenharia, ops, support, sales. Toda a gente vem a meetings com working prototypes, não pitch decks.
DRI (Directly Responsible Individual) Estratégia + customer outcomes Não é manager clássico. Uma pessoa, um outcome, no hiding.
AI-Founder Builds + coaches + leads by example Founder está na frente. Não delega "AI strategy" a alguém. Mostra à equipa o que massive capability gains parecem na prática.

"If your company is queryable, artifact-rich and legible to AI, you should have almost no human middleware."

Token-maxing, não headcount-maxing

A métrica de sucesso muda:

"Maximizing token usage, not headcount, will be the critical shift. The best companies will be the ones that are token-maxing."

Trade-off mental: uma pessoa com AI tools = equivalente a engineering team grande pre-AI. Logo: - Equipas dramaticamente leaner em engineering, design, HR, admin - Run an uncomfortably high API bill — está a substituir headcount muito mais caro

Por que startups têm vantagem (vs incumbents)

Startup Incumbent
Sem legacy systems Tem sistemas vivos a manter
Sem entrenched org chart Anos de SOPs a desfazer
Sem milhares de pessoas a retreinar Re-training en masse é trauma org
Pode designar systems + workflows + culture AI-native desde dia 1 Cada change ao core risca quebrar algo que já funciona
Pode operar 1000× mais rápido Vai a velocidade da org grande

Workaround para incumbents: spin up small internal skunkworks para construir AI-native systems separados do core. Mutiny é exemplo.

Conviction não pode ser outsourced

"You cannot outsource your conviction on the power of these tools. You need to develop it yourself by actually sitting with coding agents and using them until you start to break your own priors about what is now possible to build."

Tradução: o founder tem de fazer o trabalho com os tools até partir as próprias suposições sobre o que é possível. Não delegar.

Aplicação a Soilytix

Onde já estamos no caminho ✅

  • GHA pipelines (BD/PR/Blog/Cockpit) = closed-loops parciais — falta o "feedback into intelligence layer" automático
  • Cockpit Sheet = single source of truth para ad performance — base para queryable org
  • Reporting Agent V3 (May) = exactly this pattern aplicado ao reporting (Cleiton out of bottleneck)
  • Notion Commercial Board = artefactos legíveis por AI (cada ticket é estruturado, MCP-readable)

Onde temos gap óbvio ⚠️

Gap Estado actual AI-native equivalent
Meetings Não gravamos sistematicamente AI notetaker → Slack #soilytix-agent → searchable
DMs Slack DMs para tudo Mover para channels (#bd, #pr, #ops, #science)
Customer feedback Email + HubSpot tickets Centralizar em queryable layer
Sales call recordings Não temos Granola / Fireflies + transcript em Sheet
Sprint planning Manual no Notion Agent que lê tickets + Slack + reports + propõe

Token-maxing reality check (Apr 2026)

Soilytix corre actualmente: - ~€10/mo Anthropic (BD + PR + Blog pipelines) - ~€5/mo Perplexity - ~€115/mo total (Ahrefs + AI APIs + n8n)

Insight: estamos confortavelmente sub-token-maxing. Se houver 3-5 sítios onde +€50/mo Anthropic resolve um bottleneck humano de horas/semana, vale o trade. Identificar esses sítios em May.

3 archetypes mapping para Soilytix actual

Archetype Quem hoje
AI-Founder Cleiton — Head of Revenue + faz a engenharia GTM. ✅ no caminho.
DRI Bruno (CTO/Science), Julien (CCO/Strategy), Cleiton (Revenue) — claros
IC Próximas contratações devem vir como builder-operators (não só sales), comfortable com AI tools

Sources