Desenvolvimento em que a especificação orienta cada passo.
Descreve o que precisa por palavras suas. Nós transformamos isso numa especificação que lê e aprova, e numa estimativa de prazo e orçamento que cumprimos. Agentes de IA escrevem e testam o código, e programadores experientes supervisionam e respondem por cada linha. É o método por trás de tudo o que fazemos: sistemas para organizações, produtos para fundadores, automação e as equipas de desenvolvimento que acompanhamos.
A especificação é a origem. O código decorre dela.
Na maioria dos projetos a especificação é escrita uma vez e, um mês depois, já não descreve o sistema. A partir daí só o código sabe o que o sistema faz, e só quem o escreveu o consegue explicar. Connosco é ao contrário:
- Cada alteração entra primeiro na especificação, e só depois no código.
- Os agentes de IA desenvolvem a partir da especificação, por isso ela tem de ser rigorosa e atual.
- Os nomes no código correspondem à especificação, para que qualquer programador novo perceba o que está a ver.
- A especificação e o código mantêm-se atualizados e documentados até à entrega, e depois dela.
Da primeira conversa a um sistema a funcionar.
Conversa inicial
Uma hora, gratuita. No fim saberá o que percebemos, que perguntas estão em aberto e quanto custará a fase de especificação, a preço fixo.
Das conversas à especificação
As reuniões de especificação são gravadas, e a IA transforma-as em rascunhos. Fala por palavras suas, sem escrever documentos de requisitos.
Uma especificação em duas versões
Uma versão para si, para ler e aprovar. Outra para programadores e agentes, com tudo o que do livro de regras não sabia que devia pedir, escrito como notas “lembre-se de que”.
Aprovação e estimativa vinculativa
Aprova a especificação e recebe uma estimativa de prazo e orçamento com a qual nos comprometemos. A especificação é sua, mesmo que decida não continuar connosco.
Desenvolver e testar
Agentes de IA escrevem e testam o código, e programadores experientes supervisionam e respondem por cada linha. No DocsRobot, o nosso produto, um sistema de IA testa o produto todas as noites, em hebraico e em inglês, e abre os seus próprios relatórios de erros.
A entrega, e depois
Código e especificação atualizados e documentados, disponíveis a qualquer momento. Continue a manter connosco, ou com qualquer outra equipa.
Com o que exatamente nos comprometemos.
O nosso compromisso com prazo e orçamento aplica-se à especificação que aprovou. É isso que nos permite cumpri-lo, e que lhe permite verificá-lo.
- Quer mudar algo a meio? A alteração passa pela especificação, e vê o efeito no prazo e no orçamento antes de a aprovar, não depois.
- Porque é que a especificação é paga? Porque é a parte em que trabalhamos para si, não em que lhe vendemos. No fim tem um documento a partir do qual qualquer equipa pode trabalhar.
- Também no nosso produto: cada novo módulo do DocsRobot foi desenvolvido dentro do orçamento definido à partida.
O que nenhum cliente pediu, e está em todas as nossas especificações.
O livro de regras de desenvolvimento são centenas de regras acumuladas ao longo de décadas, organizadas por capítulos: UI/UX, segurança, desempenho e outros. Cada requisito é verificado contra ele. Uma regra relevante que não é óbvia entra na versão para programadores como uma nota “lembre-se de que”. Cinco exemplos, cada um com o que ganha e a própria regra:
Como testar algo que acontece uma vez por mês sem esperar um mês?
O que ganha: faturação mensal, um relatório semanal, um lembrete anual. Tudo totalmente testado antes do lançamento, não depois de passar o primeiro mês.
A regra: qualquer sistema com processos diários, semanais, mensais ou anuais corre num relógio de simulação que controlamos, não no relógio do servidor. Nos testes avançamos o relógio e vemos o que acontece.
Um duplo clique nunca cobra duas vezes.
O que ganha: sem clientes cobrados duas vezes e sem registos duplicados.
A regra: cada operação com efeitos secundários (criar um registo, cobrar, enviar um email, pedir uma assinatura) recebe uma Idempotency-Key. O servidor reserva a chave de forma atómica, guarda o hash do pedido com a resposta final e devolve essa mesma resposta em cada repetição. Mesma chave com outro conteúdo: 409.
Duas pessoas editam o mesmo registo. Nenhuma sobrepõe a outra em silêncio.
O que ganha: integridade dos dados no trabalho em equipa. O trabalho de ninguém desaparece sem que saiba.
A regra: cada registo editável tem uma versão exposta como cabeçalho ETag . Uma atualização tem de incluir If-Match com a versão que foi lida. Se o registo mudou entretanto: 412, e o utilizador recebe uma mensagem clara. Nunca um last-write-wins silencioso, nem perante processos em segundo plano.
Os dados de um cliente não podem chegar a outro cliente. Por construção.
O que ganha: isolamento ao nível da arquitetura, com um teste automático que corre em cada build.
A regra: num sistema multi-cliente a identidade do tenant vem apenas do token autenticado, nunca de um identificador enviado no body, num cabeçalho ou no URL. A filtragem é aplicada num único ponto central, por isso um filtro em falta é estruturalmente impossível. Testes automáticos com dois tenants confirmam que A não vê B através de nenhum endpoint.
Quando algo corre mal há um número de referência, e um fornecedor externo não deita o sistema abaixo.
O que ganha: um número de referência que leva ao quadro completo em minutos. E quando um fornecedor de pagamentos, um serviço de email ou um modelo de IA não responde, o sistema continua a funcionar em tudo o que não depende dele.
A regra: cada pedido recebe um correlationId que é anexado a cada linha de log e a cada chamada de saída, e mostrado ao utilizador num erro crítico. Cada chamada a um serviço externo é envolvida num retry com exponential backoff e jitter, apenas para erros em que repetir pode resultar, e num circuit breaker que abre após falhas consecutivas.
Parte da especificação, não um passo final.
ISO 27001
Temos certificação na norma internacional de gestão da segurança da informação.
OWASP Top 10
O desenvolvimento é verificado contra a lista de referência de riscos das aplicações web, como parte do livro de regras de desenvolvimento.
Testes de intrusão automáticos
Em projetos grandes corremos testes de intrusão automáticos, em vez de esperar por uma auditoria externa para descobrir um problema.
Reforço de servidores
Os servidores que montamos e gerimos são reforçados antes de entrarem em produção, não depois do primeiro incidente.
Onde o método se cruza consigo.
Software para organizações
Um sistema novo, a substituição de um sistema antigo mesmo sem código-fonte, ou IA dentro de um sistema existente.
Saber maisPara fundadores: do protótipo à produção
De uma ideia, ou de um protótipo encravado, a um produto que pode lançar e com que pode angariar investimento.
Saber maisModernização da equipa de desenvolvimento
O método, as ferramentas e o livro de regras, instalados na sua equipa de desenvolvimento, com acompanhamento prático.
Saber maisAutomação de processos
Ligar os sistemas que já tem, com o mesmo cuidado que pomos no software.
Saber maisAntes de começar
O que é Spec-Driven Development?
Quem escreve o código, a IA ou programadores?
E se quisermos mudar algo a meio?
E se decidirmos não continuar depois da especificação?
O que é uma nota “lembre-se de que” na especificação?
Com que tecnologias trabalham?
Uma hora. Sem compromisso.
No fim saberá o que percebemos, que perguntas estão em aberto e quanto custará a especificação. Se acharmos que não vale a pena construir, também o dizemos.
Ou diretamente: info [at] assemblyso.com
