Esta página explica como o estúdio corre.
Não é um disclaimer, é uma declaração de método.
Mais do que um método, é uma metodologia.
Nada daqui nasce de um prompt solto.
Design industrial, engenharia de processos e desenvolvimento de produto.
Três princípios governam tudo o que o estúdio produz.
Não é acessório, é infra-estrutura: a alavanca está na cadência — mais ciclos de teste no mesmo projecto.
O diretor valida a entrada, rápido; o utilizador fecha a validação, no fim, com prova de uso real.
Nada se registra para arquivo: a captura destila-se e optimiza o próximo output da IA.
O SME valida a entrada. O perito de domínio decide rápido — ideação e priorização — para acelerar o ciclo sem comités.
O utilizador fecha a validação. Por defeito, dois testes por ciclo: um de levantamento, antes de construir; um de validação, no fim. O contrato de ciclo pode ajustar a barra.
Quando o teste directo não é possível, o substituto é uso próprio documentado — e as hipóteses ficam marcadas para validação no lançamento, que as fecha em escala.
A fundação que dirige a execução é privada por princípio. O que se lança é o produto, aberto e documentado — a fundação não. Replicar o processo exigiria engenharia reversa ao entregável, e essa rota perde o conhecimento que foi segmentado e excluído do final: é a vantagem estrutural do estúdio, por isso é regra e não acidente.
É uma prática de trabalho em que alguém com visão e intenção dirige uma ferramenta com enorme capacidade de execução. O resultado é co-producido, mas a autoria criativa tem uma origem clara.
É parecido com um director criativo que trabalha com uma equipa de execução muito capaz, com uma diferença: esta equipa não tem iniciativa, nem gosto, nem visão. Trabalha dentro do espaço que eu defino.
A ideia nasce em mim: o conceito, o problema, a experiência.
A execução é delegada à IA: código, texto, estrutura, variantes.
O julgamento é meu: o que fica, o que se rejeita, o que se itera.
A responsabilidade também: quem assina o produto, responde por ele.
Em todos os projectos, a divisão de papéis é a mesma.
O que o produto é, que problema resolve, a quem se dirige, o que o diferencia — antes de existir linha de código.
Roadmap, prioridades, o que entra e o que fica de fora. O produto avança porque decido que avança e para porque decido que está pronto.
Paleta, layout, tipografia, hierarquia, tom de voz, sensação geral. A IA propõe; eu decido o que fica.
Em cada iteração testo, uso, critico e corrijo. Os bugs que encontro e os fluxos que rejeito ficam documentados na captura de trabalho.
Arquitectura, tecnologias, limites e trade-offs. Quando a IA propõe uma solução, sou eu a avaliar se serve o produto a longo prazo.
Traduz uma ideia, uma descrição ou uma correcção em algo concreto: código, texto, estrutura, regras.
Mais ciclos de teste no mesmo projecto — o que levaria dias a um programador a solo leva horas numa sessão dirigida.
Quando peço opções, gera alternativas. Só têm valor depois de eu as avaliar e escolher.
Estrutura e redige o que descrevo. A substância é minha; a formalização é dela.
Não tem visão, não sabe o que o produto deve ser, não tem gosto, não valida, não decide, não assume responsabilidade. Sem direcção humana clara, produz output genérico.
A IA é uma alavanca de cadência. O que levaria dias a um programador a solo leva horas numa sessão dirigida — e o ganho real não é só velocidade: são mais ciclos de teste no mesmo projecto.
Quem dirige não reescreve: decide, testando. E os artefactos do passo de idear servem duas vezes — são pensamento para mim e especificação para a IA. Um conceito que não se deixa diagramar não está claro o suficiente para dirigir execução.
E quanto mais o estúdio corre, mais o método serve para partilhar o conhecimento que gera.
O método tem marca genética das metodologias que o convergiram — Design Thinking no idear, gestão de produto no priorizar, Scrum e Kanban no construir, Lean Startup no fechar, docs-as-code no destilar — em modo dual-track: a descoberta contínua a alimentar a entrega incremental. O mercado cobre a mesma sequência com uma ferramenta paga por etapa. A suite nimble cobre-a de outra maneira: uma app por etapa, um espaço de dados, um operador.
| Etapa | Metodologia | Na suite nimble |
|---|---|---|
| 0 · Configurar | Contrato do engajamento / project charter | Ciclo · nova — ficha de ciclo fechável + painel de gates e métricas |
| 1 · Idear | Design Thinking / Double Diamond | Diagramico — cartão de conceito com non-goals obrigatório + diagrama v1 |
| 2 · Priorizar | Gestão de produto / priorização (RICE, WSJF, Kano) + backlog refinement | Roadmaps — taxonomia firme do estúdio, horizontes S/M/L, matriz com eixo de alavanca, apetite |
| 3 · Construir | Scrum (sprints, backlog) + Kanban (fluxo) + gestão de defeitos do XP | Taskboards — tarefa de uma frase + ficha de contexto de IA + nota de bugs |
| 4 · Validar | Lean Startup (Build–Measure–Learn) + Lean UX | Veredicto · nova — ledger de hipóteses falsificáveis: uma sessão, um sinal, um veredicto, uma acção |
| 5 · Lançar | Customer Development e release management | Finale · nova — checklist da régua do aberto + release derivado do ciclo + licenças do contrato |
| T · Ensina | docs-as-code, ADRs, Definition of Done | Captura · nova (CLI) + fundação privada — capturar já formaliza; o mapa alimenta o próximo ciclo |
A premissa de desenho: uma app só existe se o seu artefacto cruza um gate do ciclo; os dados ficam com o operador, em ficheiros, com exportação por defeito.
Esconder a IA não seria honesto para com clientes, parceiros ou público. E seria contraproducente: o valor do trabalho está na qualidade da direcção, não em esconder como foi feito.
Declarar o uso de IA não diminui o meu papel — clarifica-o. Quando se percebe o que a IA faz e o que não faz, a visão, a direcção e a validação ficam mais evidentes.
Um realizador não opera a câmara. Um arquitecto não assenta tijolos. Um director criativo não escreve o código.
A autoria é a visão, não a execução.
Não escrevo um prompt e publico o resultado. Cada output é iterado, testado, corrigido e validado várias vezes antes de ser produto.
Os outputs são gerados, não copiados de terceiros. Código, textos e estruturas são originais no contexto de cada projecto.
Não uso IA para fazer o trabalho que estaria a pagar a outra pessoa. É a minha ferramenta de produção, como o software de um designer ou o sintetizador de um músico.
Dirigir bem uma IA exige perceber de design, código, produto e experiência de utilizador. O meu background é design industrial, engenharia de processos e desenvolvimento de produto.
A IA não é uma pessoa, não tem direitos e não é co-autora em sentido jurídico. O produto é meu. A IA é uma ferramenta — sofisticada, mas ferramenta.
Qualquer produto ou documento que sai deste processo tem as mesmas quatro características.
O produto abre-se; a fundação fecha-se. Open source por defeito — MIT para o código, licença restritiva para o conteúdo autoral (música, fotografia, desenho, escrita). O que fica privado é o que faz o motor correr: os arneses, os mapas, o método em operação.
Lançar é ficar público — porque é o lançamento que realimenta o ciclo. Dirigido, validado e assumido.
Este texto pode ser citado, partilhado ou incluído na documentação dos meus projectos como declaração de método de trabalho.