Executando verificação de segurança...
5
KerubinDev
1 min de leitura ·

Cansei de IA que pensa por mim — então criei o AkitaLLM

Estou desenvolvendo um projeto open-source chamado AkitaLLM.

A ideia nasceu de uma frustração simples: a maioria das ferramentas com LLM hoje tenta “pensar por você”. Autocomplete demais, decisão implícita demais, pouca rastreabilidade e quase nenhum controle real.

O AkitaLLM vai na direção oposta.

Ele é uma ferramenta CLI, local-first, pensada para engenheiros de software, que força um fluxo explícito e auditável de uso de LLMs. Nada de “joga o prompt e reza”.

O pipeline é rígido e intencional:
Analyze → Plan → Execute → Validate

Cada etapa é separada, registrada e verificável.
A ideia é usar IA como ferramenta de engenharia, não como oráculo.

Alguns pontos centrais do projeto:

Orquestração de LLMs com foco em controle e previsibilidade

Diferença real entre análise, planejamento e execução

Integração com AST (Tree-sitter) para entender código de verdade

Validação por testes, diffs e rollback

Arquitetura extensível via plugins

Zero hype, zero “IA mágica”

O projeto ainda está evoluindo, mas já está no ar, versionado e aberto a críticas (inclusive as duras).

Se você também acha que IA deveria te forçar a pensar melhor — não pensar por você, talvez o AkitaLLM faça sentido pra você.

Repo: https://github.com/KerubinDev/AkitaLLM

PyPI: pip install akitallm

Feedback é bem-vindo.
Principalmente se for honesto.

Fonte: https://github.com/KerubinDev/AkitaLLM

Carregando publicação patrocinada...
3
1
2
MadrasLe

Projeto bem interessante e a motivação faz sentido, especialmente a ideia de tornar o uso de agentes mais explícito e auditável do que já é (plan/execute/validate, diffs, rollback etc).
Só um ponto importante: a instabilidade/imprevisibilidade de LLMs é algo muito difícil (quase impossível) de “resolver” apenas com camadas de wrapper/prompting em alto nível.
Na prática, o fator limitante costuma ser muito mais o modelo subjacente (como foi treinado, SFT/RLHF, alinhamento) do que o orchestration em cima.
Mesmo com temperature=0, existe não-determinismo em produção por efeitos de batching dinâmico, paralelismo e floating-point (FP16/BF16 etc). Determinismo real geralmente exige controle mais baixo na stack de inferência.
Acho que o valor do projeto está mais em boas práticas de engenharia (diffs explícitos) do que em tornar o LLM “determinístico”.
No geral, parabéns pela iniciativa só acho bom calibrar a promessa para não parecer que prompt/software layer resolve limitações fundamentais do modelo ou tornam ele determistico.

1
KerubinDev
  • Autor
    Autor

Concordo com a crítica. Não-determinismo real não é algo que se resolve no nível de prompting ou orchestration, especialmente quando entra batching, paralelismo e limitações numéricas do stack de inferência.
A proposta do Akita não é “tornar o LLM determinístico”, mas reduzir o espaço de comportamento implícito e tornar divergências observáveis, auditáveis e reversíveis no nível do sistema.
Em vez de tentar eliminar a instabilidade do modelo (o que é irrealista), o foco é:

estruturar explicitamente o processo de decisão,

registrar diffs e efeitos colaterais,

permitir rollback,

e identificar onde e quando o modelo saiu do esperado

Realmente acabei colocando ele como uma solução para isso, por que infelizmente esse é o melhor que podemos fazer por enquanto

Ou seja, o ganho está mais em engenharia e controle de falhas do que em prometer correções das limitações fundamentais do modelo. Se a comunicação sugeriu o contrário, vale mesmo ajustar.

2
theselegadev

estou fazendo um projeto de cli chamado duck, ele tem uma proposta de engenharia bem parecida com o seu projeto, a proposta é identificar padrões de design de código e criar artefatos/contratos para quando você for usar agentes para codar (vulgo vibe coding) o seu agente seja ele claude code, copilot etc, siga os padrões de código já definidos no projeto, assim forçando seu agente a não desviar do padrão de arquitetura usado na sua codebase. Ele tem um fluxo de pipeline onde ele recebe um diretório -> scann dos arquivos (tem que ser ts, js, jsx/tsx ignorando node_modules etc) -> file loader (lê o conteudo do arquivo e tamanho maximo) -> ast analyze (analisa ast do diretório e extrai informações importantes tipo imports, dependencias entre classes e func, layers, controllers, services etc) -> IR (modelo intermediário em formato json com as informações de padrão de código para um LLM analisar) -> LLM (LLM analisa modelo IR e define os padrões de arquitetura usado no código). Após esse processo vai ser gerado dois arquivos, um .md com linguagem natural para humanos lerem e terem um entendimento melhor do projeto e seus padrões e um em formato json para agentes de código usarem como contrato com todas as definições e padrão de código identificados e a serem seguidos pela a IA que está codando.
A inicio a ideia do projeto é identificar e definir padrões para quem esteja participando do projeto e segui-los (seja agente de ia ou humano). Estou usando a ideia de usar IA apenas como ferramenta de engenharia e nada de ficar jogando prompt e rezar igual vc citou kkkkkkkkk

1
KerubinDev
  • Autor
    Autor

Muito massa o duck. A proposta é bem alinhada com a do AkitaLLM: IA como ferramenta de engenharia, não “prompt e fé”.

Usar AST → IR como contrato explícito de arquitetura é uma ótima forma de evitar deriva quando entra agente ou dev novo. Resolve bem o problema do vibe coding saindo do padrão da codebase.

No AkitaLLM o foco é mais no processo (pipeline rígido, diffs, rollback, validação) do que em extrair padrões, mas são camadas bem complementares. Dá pra imaginar fácil o JSON do duck entrando como constraint dentro do fluxo do AkitaLLM.

E +1: LLM com contrato claro > autocomplete bonito gerando dívida técnica 😅

2
1
KerubinDev
  • Autor
    Autor

Hummmm gostei da ideia, vou deixar anotado e assim que conseguir vou começar a trabalhar nisso tambem
Eu até pensei que poderia dar algum problema, se for preciso eu mudo depois mas é mais uma homenagem para o Fabio Akita