De Zero a Produto em 9 Dias: O Que Acontece Quando um Dev Usa IA de Verdade

Eu construí um software completo em 9 dias. Não um protótipo que vai pro lixo na semana seguinte. Um produto real, publicado no npm, com 2.023 testes passando, 23 releases e mais de 60 mil linhas de código efetivo. Eu e uma inteligência artificial. Do primeiro commit até o npm publish.

Sei que parece conversa de vendedor. Eu mesmo duvidaria se alguém me contasse isso há dois meses. Mas aconteceu, os dados estão todos públicos no GitHub, e neste artigo eu vou destrinchar exatamente como foi, sem romantizar nada.

O problema que me incomodava

Em março de 2026, ferramentas de IA para programação já existiam aos montes. Claude, Copilot, Cursor. Todo mundo usando. Mas tinha um negócio que me irritava: nenhuma dessas ferramentas resolvia a questão de como organizar o trabalho quando a IA é seu parceiro de código.

Pensa comigo: Jira, Linear, Trello. Todas essas ferramentas foram pensadas para times humanos que trabalham em sprints de duas semanas. Só que quando você programa com IA, o ritmo muda completamente. Você trabalha em ciclos de horas, não de semanas. As tarefas precisam de critérios claros que a IA consiga validar, e não daquelas estimativas vagas em “story points” que ninguém acerta.

Se você não é da área: Story points são uma forma de estimar esforço em times de desenvolvimento. Em vez de dizer “isso leva 3 dias”, o time dá uma nota abstrata (tipo 3, 5 ou 8) pra representar a complexidade. Na prática, é um chute educado.

Foi aí que surgiu a pergunta: e se eu criasse uma ferramenta de gestão feita sob medida para quem programa com IA?

A aposta que eu fiz

A ideia era ousada por dois motivos:

Construir a ferramenta usando a própria IA. O Claude/Copilot seria o copiloto de todo o desenvolvimento
Usar a ferramenta para gerenciar sua própria construção. Se ela conseguisse se autogerenciar, funcionaria para qualquer projeto

flowchart LR
    DEV[Dev define\narquitetura] --> CLAUDE[Claude/Copilot\nimplementa]
    CLAUDE --> MCPGRAPH[mcp-graph\ngerencia tasks]
    MCPGRAPH --> NEXT[next task\nrecomendada]
    NEXT --> DEV
    MCPGRAPH --> |acelera| CLAUDE

    style DEV fill:#2196f3,color:#fff
    style CLAUDE fill:#7c3aed,color:#fff
    style MCPGRAPH fill:#10b981,color:#fff
    style NEXT fill:#f59e0b,color:#000

E o que aconteceu foi curioso: quanto mais funcionalidades a ferramenta ganhava, mais rápido o próprio desenvolvimento ficava. Tipo uma bola de neve. Cada feature nova alimentava o ciclo seguinte.

Se você não é da área: MCP (Model Context Protocol) é um protocolo aberto que permite agentes de IA se conectarem a ferramentas externas. Pensa nele como um “USB” para inteligência artificial. Um padrão universal que permite plugar capacidades diferentes em qualquer agente compatível.

A jornada dia a dia

Dias 1-2: Quando tudo começou (30 commits)

Era madrugada de domingo, 01:16 da manhã. Eu não conseguia dormir pensando na arquitetura. Abri o terminal e mandei o primeiro commit. E olha, não foi um comecinho tímido não. Em 48 horas, o projeto já tinha:

Servidor MCP completo com 10 ferramentas
Parser que pegava documentos de requisitos e organizava em tarefas estruturadas
Banco de dados SQLite com migrações automáticas
Dashboard web com 5 abas (grafo visual, backlog, análise de código, base de conhecimento, insights)
API REST completa com CRUD
Sistema de eventos em tempo real via SSE
54 testes automatizados
Pipeline de CI no GitHub Actions

Se você não é da área: API REST é basicamente a linguagem que sistemas usam pra conversar pela internet. Quando seu app do celular busca dados num servidor, provavelmente está usando uma API REST. Já SSE (Server-Sent Events) permite que o servidor mande atualizações pro navegador em tempo real, sem o navegador ficar perguntando “e aí, tem novidade?” a cada segundo.

A primeira versão estável saiu no dia 9 mesmo. No dia seguinte já estava na v2.1.0.

O que tornou isso possível? Disciplina. Parece clichê, mas cada funcionalidade seguia um ciclo rígido: primeiro o teste, depois o código mínimo pra passar, depois refatorar. A IA não ficava “inventando moda”. Ela seguia instruções bem específicas que eu documentei num arquivo chamado CLAUDE.md. Sem isso, teria virado bagunça no segundo dia.

Dias 3-4: O dia mais maluco (40 commits)

11 de março. Esse foi o dia mais insano do projeto: 35 commits em 24 horas. Cinco versões lançadas.

E sabe o que é engraçado? Nesse momento, ao invés de sair adicionando mais coisa, eu fiz o oposto. Consolidei as ferramentas de 31 para 26. Menos botões, mais poder em cada um. É tipo quando você tem 5 controles remotos na sala e finalmente compra um universal.

Se você não é da área: Commit é como um “save” no desenvolvimento de software. Cada commit registra o que mudou no código com uma descrição. 35 commits num dia significa 35 alterações significativas salvas e documentadas.

Os marcos importantes foram:

v3.0.0: Mudança na identidade do pacote (no mundo do software a gente chama de “breaking change”, que é quando a atualização exige que quem já usa se adapte)
v4.0.0: Sistema de ciclo de vida completo. O projeto passa a saber em que fase cada tarefa está e cobra disciplina

Dias 5-6: A realidade bateu na porta (25 commits)

Sabe aquela euforia dos primeiros dias? Pois é, os dias 5 e 6 foram o banho de água fria. Lançar rápido é fácil. Lançar com qualidade é outra história.

Seis correções de bugs em sequência me mostraram problemas que nenhum teste unitário do mundo pegaria:

O Safari decidiu mostrar uma tela branca numa das abas. Só no Safari. Claro.
Ícones retornando erro 404. Simplesmente sumiam.
O dashboard não trocava de banco de dados quando eu mudava de projeto

Doeu no momento, mas cada bug desse me ensinou algo que evitou problemas maiores depois. Velocidade sem qualidade é só dívida técnica acumulando.

Se você não é da área: Teste unitário verifica se um pedacinho isolado do código funciona. Mas tem bug que só aparece quando o sistema roda de verdade, no navegador real, com dados reais. Por isso também existem testes de integração e testes end-to-end, que olham o sistema como um todo.

Dias 7-8: As coisas ficaram sérias (29 commits)

Aqui o projeto mudou de patamar. Em vez de ficar dependendo de ferramentas externas, comecei a internalizar tudo:

Motor de análise de código: Capaz de ler o código-fonte do projeto, mapear as relações entre arquivos e calcular o impacto de qualquer mudança. Antes de mexer numa função, o sistema já me dizia o que ia quebrar. Isso mudou tudo.

Sistema de memória nativo: Antes, o projeto dependia de um serviço externo pra “lembrar” decisões passadas. Agora isso rodava internamente, com busca inteligente integrada. Menos dependência, mais velocidade.

flowchart TB
    subgraph "Antes (v4.x)"
        A1[mcp-graph] --> A2[Serena MCP\nexterno]
        A1 --> A3[GitNexus MCP\nexterno]
    end

    subgraph "Depois (v5.1+)"
        B1[mcp-graph] --> B2[Native Memories\nembutido]
        B1 --> B3[Code Intelligence\nembutido]
    end

    style A2 fill:#f44336,color:#fff
    style A3 fill:#f44336,color:#fff
    style B2 fill:#10b981,color:#fff
    style B3 fill:#10b981,color:#fff
    style B1 fill:#4263eb,color:#fff
    style A1 fill:#4263eb,color:#fff

A v5.2.0 trouxe algo que me orgulhou bastante: contexto adaptativo por fase. Se você está implementando, o sistema prioriza exemplos de código. Se está revisando, prioriza análise de impacto. O contexto muda conforme o que você precisa naquele momento.

Dia 9: O sprint final (17 commits)

Último dia. Foco total em testes e qualidade:

391 novos testes num único dia. Cobertura saltou de 78% para 91%
Sistema de skills pra automatizar fluxos comuns
Dashboard de insights com detecção automática de gargalos

Se você não é da área: Cobertura de testes mede qual percentual do código tem verificação automática. 91% significa que quase tudo é testado. Acima de 80% já é considerado excelente na indústria.

xychart-beta
    title "Crescimento de Testes ao Longo dos 9 Dias"
    x-axis ["D1-2", "D3-4", "D5-6", "D7-8", "D9"]
    y-axis "Testes" 0 --> 2100
    line [54, 200, 600, 1632, 2023]
    bar [54, 200, 600, 1632, 2023]

Os números consolidados

Métrica	Valor
Duração total	9 dias, 7h47min
Commits	142
Releases (versões publicadas)	23
Código efetivo	~60.000 linhas
Testes	2.023 passando (100% green)
Cobertura de testes	91%
Ferramentas MCP	30
Rotas de API	20 endpoints
Dashboard	8+ abas
Média de commits por dia	15.8

Quando o código acontecia

xychart-beta
    title "Commits por Dia"
    x-axis ["9 mar", "10 mar", "11 mar", "12 mar", "13 mar", "14 mar", "15 mar", "16 mar", "17 mar", "18 mar"]
    y-axis "Commits" 0 --> 40
    bar [24, 6, 35, 5, 0, 17, 8, 20, 9, 17]

Olha o dia 13: zero commits. E não foi preguiça. Depois de 4 dias seguidos com 70 commits, meu cérebro pediu arrego. A IA não precisa descansar, mas eu preciso. E sabe o que aconteceu? Os 3 dias seguintes tiveram 45 commits com qualidade visivelmente melhor. O descanso fez parte do processo.

O horário que eu mais produzia

xychart-beta
    title "Commits por Hora do Dia"
    x-axis ["0h", "1h", "2h", "3h", "4h", "5h", "6h", "7h", "8h", "9h", "10h", "11h", "12h", "13h", "14h", "15h", "16h", "17h", "18h", "19h", "20h", "21h", "22h", "23h"]
    y-axis "Commits" 0 --> 25
    bar [8, 23, 5, 3, 2, 0, 0, 0, 1, 5, 8, 6, 4, 15, 15, 8, 6, 10, 5, 3, 4, 2, 3, 5]

23 commits à 1 da manhã. Nenhuma reunião, nenhuma notificação, nenhuma interrupção. Só eu, a IA e o terminal. Cada pessoa tem seu horário de pico e o meu, claramente, é de madrugada. A IA amplifica seus momentos produtivos, não inventa novos.

Quem fez o quê

pie title Commits por Autor
    "Diego Nogueira" : 118
    "github-actions[bot]" : 17
    "dependabot[bot]" : 4
    "Claude" : 3

83% dos commits saíram das minhas mãos. Todo código que a IA gerava passava por minha revisão antes de entrar. Os bots de automação cuidavam de releases e atualizações de segurança automaticamente.

As 23 releases no mapa

timeline
    title 23 Releases em 9 Dias
    section Dia 1 (9 mar)
        v2.0.0 : Core MCP + Parser + Dashboard
        v2.0.1 : Fix shebang
        v2.1.0 : All edge types active
    section Dia 3 (11 mar)
        v3.0.0 : npm scope rename (BREAKING)
        v4.0.0 : Lifecycle + dashboard (BREAKING)
        v4.1.0 : CI security pipeline
        v4.2.0 : Real-time logs tab
        v4.3.0 : Lifecycle auto-detection
    section Dia 4 (12 mar)
        v4.3.1 : Config path fix
    section Dia 5 (14 mar)
        v5.0.0 : npm scope migration (BREAKING)
    section Dia 6 (15 mar)
        v5.0.1 : Safari blank screen fix
        v5.0.2 : Favicon + canvas fix
        v5.0.3 : Dashboard bundle cleanup
        v5.0.4 : Runtime DB swap
        v5.0.5 : Benchmark calculation fix
    section Dia 7 (16 mar)
        v5.1.0 : Doctor command
        v5.1.1 : CI benchmark threshold
        v5.1.2 : CI timeout fix
        v5.1.3 : Release workflow fixes
        v5.1.4 : Release PAT fix
        v5.1.5 : Lifecycle strict mode
    section Dia 8 (17 mar)
        v5.2.0 : Knowledge mesh phase-aware
    section Dia 9 (18 mar)
        v5.3.0 : Skills system + Code Intel + Memories
        v5.4.0 : Test coverage 91%

Quando você olha o mapa, dá pra enxergar o ritmo natural do projeto:

Dia 1: Explosão de funcionalidades. Aquela energia do começo.
Dia 3: Duas mudanças estruturais grandes no mesmo dia. Arrumando a casa enquanto construía.
Dias 5-6: Seis releases só de correção. A realidade cobrando a conta da velocidade.
Dia 7: Cinco ajustes de infraestrutura de CI/CD. Chato, mas necessário.
Dias 8-9: Features avançadas e qualidade. O projeto amadurecendo.

O efeito bola de neve

Essa foi a parte mais legal de tudo. Cada funcionalidade que eu adicionava ao mcp-graph tornava o desenvolvimento da próxima funcionalidade mais rápido. Uma aceleração composta.

flowchart TD
    A[Dia 1: import_prd\nTransforma requisitos em tarefas] --> B[Dia 2: next task\nRecomenda a próxima tarefa]
    B --> C[Dia 3: context\nComprime contexto em 73%]
    C --> D[Dia 4: lifecycle\nGarante disciplina no processo]
    D --> E[Dia 5: knowledge store\nAcumula conhecimento]
    E --> F[Dia 7: Code Intelligence\nAnalisa impacto de mudanças]
    F --> G[Dia 8: knowledge mesh\nContexto adaptativo por fase]
    G --> H[Dia 9: skills system\nAutomação de fluxos]

    A --> |usado para\nconstruir| B
    B --> |usado para\nconstruir| C
    C --> |usado para\nconstruir| D

    style A fill:#2196f3,color:#fff
    style B fill:#4263eb,color:#fff
    style C fill:#7c3aed,color:#fff
    style D fill:#9c27b0,color:#fff
    style E fill:#e91e63,color:#fff
    style F fill:#f44336,color:#fff
    style G fill:#ff5722,color:#fff
    style H fill:#ff9800,color:#000

Pra dar um exemplo concreto:

Dia 1: O parser de requisitos já era usado para organizar as tarefas do próprio mcp-graph. Ele gerenciava a si mesmo desde o primeiro dia.
Dia 3: O compressor de contexto cortava 73% do volume de informação. A IA passou a processar muito mais por interação.
Dia 7: A análise de impacto verificava, antes de cada mudança, o que ia quebrar. Acabou aquele medo de mexer em algo e estourar outra coisa.
Dia 8: O contexto adaptativo entregava informação diferente conforme a fase. Implementando? Exemplos de código. Revisando? Análise de risco.

A ferramenta não só gerenciava o desenvolvimento. Ela acelerava o desenvolvimento. E quanto mais ela acelerava, mais features eu entregava pra ela acelerar ainda mais. Loop infinito positivo.

Comparando com projetos reais (sem IA)

Pra entender se esses números fazem sentido, comparei o mcp-graph com projetos open-source construídos antes da era da IA (pré-2015). Todos com dados públicos no GitHub.

Se você não é da área: LOC significa “Lines of Code” (linhas de código). É uma métrica simples que conta quantas linhas um projeto tem. Não é perfeita, porque uma linha pode ser trivial ou complexa, mas serve como referência de escala.

Quanto tempo cada projeto levou pra chegar na v1.0

xychart-beta
    title "Dias até primeira versão estável"
    x-axis ["mcp-graph", "Mocha", "Gulp", "PM2", "Webpack"]
    y-axis "Dias" 0 --> 800
    bar [9, 120, 150, 210, 730]

Projeto	O que faz	Tempo até v1.0	Devs	LOC aprox.
mcp-graph	CLI + API + Dashboard + grafo + IA	9 dias	1 (+IA)	~60k
Mocha	Framework de testes JS	~3-4 meses	1	~5-8k
Gulp	Automação de builds	~4-5 meses	1-2	~3-5k
PM2	Gerenciador de processos	~6-8 meses	1-2	~15-20k
Webpack	Bundler de módulos	~2 anos	1	~30-40k

Linhas de código por dia

xychart-beta
    title "LOC por dia efetivo de desenvolvimento"
    x-axis ["mcp-graph", "PM2", "Mocha", "Webpack", "Gulp"]
    y-axis "LOC/dia" 0 --> 7000
    bar [6600, 95, 75, 65, 35]

O número cru sugere um ganho de 60 a 100 vezes. Mas eu sei que comparação crua é injusta, então vou descontar os fatores que distorcem:

Fator	Desconto	Razão
Ferramentas modernas (2026 vs 2012)	/2.0	TypeScript, ESM, npm maduro, IDEs muito melhores
IA gera código mais verboso	/1.5	Nem toda linha gerada tem o mesmo peso de uma linha escrita na mão
Ritmo insustentável	/1.3	Eu trabalhei de madrugada, nos fins de semana. Isso não é replicável

Fazendo a conta honesta:

Ganho bruto: ~6.600 / ~80 = ~82x
Com descontos: 82 / (2.0 x 1.5 x 1.3) = 82 / 3.9 = ~21x

Faixa estimada: 15 a 30 vezes mais produtivo

Se você não é da área: COCOMO II é um modelo matemático que estima quanto tempo e quantas pessoas seriam necessárias para construir um software, baseado no tamanho do código. Segundo esse modelo, as ~60k linhas do mcp-graph levariam cerca de 174 pessoa-meses sem IA. Ou seja: um time de 5 pessoas trabalharia por quase 3 anos.

Mas peraí, os estudos não falam em ganho de 1.2-2x?

Sim. Estudos do GitHub, Google e McKinsey reportam ganhos de 1.2x a 2x com IA. Por que eu estou falando em 15-30x? Porque o contexto é completamente diferente:

Agente completo vs autocomplete. Ferramentas como Copilot sugerem linhas isoladas. Agentes como Claude implementam funcionalidades inteiras a partir de uma spec. É como comparar um corretor ortográfico com um ghostwriter.
O efeito meta-recursivo. A ferramenta gerencia o próprio desenvolvimento. Cada feature nova melhora o processo que a constrói. Ferramentas externas não criam esse loop.
Projeto novo, um dev sozinho. Zero reuniões. Zero overhead de comunicação. Zero code review externo. Eu decido, a IA implementa. Sem atrito.

Sendo honesto sobre as limitações

Eu preciso ser transparente aqui. Essa comparação tem problemas, e eu sei quais são:

Eras diferentes. Programar em 2012 era mais difícil por causa das ferramentas limitadas, não só por falta de IA.
Linhas de código não medem complexidade. 60k linhas do mcp-graph não se comparam com 60k linhas do Webpack. O Webpack resolve problemas algorítmicos muito mais difíceis.
Viés de sobrevivência. Estou comparando com projetos que deram certo. Milhares morreram antes da v1.0.
Ritmo que ninguém deveria manter. 23 commits à 1 da manhã não é estilo de vida saudável. Funciona por 9 dias, não por 9 meses.
Projeto do zero. Sem legado, sem usuários, sem compatibilidade com versões antigas. Qualquer projeto existente seria muito mais lento.
Qualidade de longo prazo é outra conversa. 9 dias de construção não se comparam com 10+ anos de manutenção.

Como eu evitei que a IA gerasse código ruim

Essa é a pergunta que mais me fazem. A resposta curta: uma metodologia que eu chamo de Anti-Vibe-Coding, baseada em Extreme Programming adaptada pro trabalho com IA.

Se você não é da área: XP (Extreme Programming) é uma metodologia que prioriza testes automatizados, entregas frequentes e código simples. TDD (Test-Driven Development) é uma prática do XP onde você escreve o teste antes do código. Primeiro você define o que espera, depois implementa até o teste passar.

O fluxo de cada tarefa passava por 8 fases:

graph LR
    A[ANALYZE\nRequisitos] --> D[DESIGN\nArquitetura]
    D --> P[PLAN\nDecompor tarefas]
    P --> I[IMPLEMENT\nTDD]
    I --> V[VALIDATE\nTestes completos]
    V --> R[REVIEW\nAnálise de impacto]
    R --> H[HANDOFF\nDocumentação]
    H --> L[LISTENING\nFeedback]
    L --> |novo ciclo| A

    style A fill:#2196f3,color:#fff
    style D fill:#7c3aed,color:#fff
    style P fill:#f59e0b,color:#000
    style I fill:#4caf50,color:#fff
    style V fill:#06b6d4,color:#fff
    style R fill:#ec4899,color:#fff
    style H fill:#10b981,color:#fff
    style L fill:#9e9e9e,color:#fff

No dia a dia, era assim:

next: pegar a próxima tarefa que o motor recomendava
context: receber um resumo comprimido com o que importava
Escrever teste que falha: o teste define o comportamento esperado
Código mínimo pra passar: só o necessário, nada mais
Refatorar: melhorar sem mudar comportamento
Marcar como feito: atualizar o status no grafo
Repetir

Nada de “deixa eu codar isso rapidinho”. A IA seguia o processo que eu documentei. E isso fez toda a diferença entre código que funciona e código que parece funcionar.

10 coisas que eu aprendi fazendo isso

1. IA não substitui arquitetura

Eu defino o QUE e o COMO. A IA executa. Toda vez que pedi pra ela “criar um sistema de X”, o resultado saiu genérico. Quando descrevi a arquitetura em detalhe (schemas, módulos, interfaces), o resultado saiu preciso.

2. Documentar padrões é o investimento que mais retorna

Cada hora que eu gastei documentando convenções e erros no CLAUDE.md economizou horas de correção. O arquivo cresceu de 20 pra 400+ linhas ao longo dos 9 dias. No dia 9, a IA quase não errava mais.

3. Com IA, testes importam mais, não menos

Sem testes, a IA gera código que “parece funcionar”. Com testes, gera código que comprovadamente funciona. Os 2.023 testes não eram burocracia. Eram a rede de segurança que me permitia ir rápido sem medo.

4. Descanso faz parte do processo

O dia de zero commits não foi fraqueza. Os 3 dias seguintes tiveram 45 commits melhores do que tudo que veio antes. Meu cérebro processa informação enquanto descansa. A IA não precisa parar, mas eu preciso.

5. Mudança grande com planejamento não assusta

Três breaking changes em 9 dias parece loucura. Mas cada uma veio com migração automática. O medo de mudar faz mais estrago do que a mudança em si.

6. Bug de produção ensina mais que feature nova

Os 6 hotfixes me mostraram coisas que teste unitário nunca pegaria: tela branca no Safari, ícone sumindo, banco de dados não trocando em runtime. Bug real é professor que não tem dó.

7. Simplificar é mais difícil que adicionar

Cortar de 31 pra 26 ferramentas não foi perda. Foi ganho. Cada ferramenta que sobrou ficou mais poderosa e mais fácil de usar.

8. Se você criou o sistema, confie nele

Usar a ferramenta pra gerenciar o próprio desenvolvimento só funciona se você respeita o que ela recomenda. Se o motor diz “faça X primeiro” e você ignora, o sistema perde sentido.

9. Conheça seus horários

23 commits à 1 da manhã. Zero entre 5h e 7h. Eu sou noturno. Você pode ser matutino. A IA amplifica seu ritmo natural, não cria um novo.

10. Automatize na terceira vez

Releases automáticas, segurança, testes multi-OS. Cada automação custou 30 minutos e economizou horas. A regra é simples: se fez 3 vezes na mão, automatize.

O que eu tiro de tudo isso

Não é que IA substitui desenvolvedor. É que IA muda o que um dev consegue fazer sozinho.

Eu não conseguiria escrever 60 mil linhas em 9 dias sem IA. Mas também não conseguiria com IA se eu não soubesse projetar sistemas, garantir qualidade, gerenciar complexidade e, principalmente, saber a hora de parar.

IA é um amplificador. Amplifica competência e amplifica incompetência. Quem sabe arquitetar constrói sistemas robustos muito mais rápido. Quem não sabe gera muito mais bagunça.

As ferramentas de amanhã vão ser construídas pela IA de hoje. Mas em todo esse ciclo, uma coisa não muda: alguém precisa decidir o que construir e por quê. Essa pessoa é o dev. A IA é o copiloto mais rápido e mais paciente que já existiu. Mas copiloto não é piloto.

Números finais

Início:        9 de março de 2026, 01:16 AM
Último commit: 18 de março de 2026, 09:03 AM
Duração:       9 dias, 7 horas, 47 minutos

142 commits | 23 releases | 461 arquivos | ~60k linhas efetivas
2.023 testes | 91% cobertura | 30 MCP tools | 20 API routes

1 desenvolvedor + 1 IA = 1 produto completo

Este estudo é baseado em dados reais extraídos do repositório mcp-graph-workflow. Todos os números foram verificados via git log, git shortlog e análise de código-fonte.