Latest / Entre Chaves / #257 Spec-driven development: o que muda no desenvolvimento de software

Transcript

#257 Spec-driven development: o que muda no desenvolvimento de software · Entre Chaves

0:02
Está começando mais um entre chaves, o seu podcast de
0:06
desenvolvimento de software, e hoje a gente vai falar sobre um
0:09
tema que está muito em alta. Quando a gente fala sobre
0:12
metodologias de desenvolvimento de software, a gente vai falar
0:16
sobre sdd, né? Que é o specch drive and
0:19
developent, né? Ou o desenvolvimento orientado
0:22
por especificações? Né, que é uma metodologia que
0:25
não é exatamente nova, né? Ela já existe, já tem um tempo,
0:30
mas que com as e agenerativas veio com mais força, né?
0:35
Atualmente mudando mesmo a forma da gente desenvolver software,
0:40
né? Daqui para frente e para falar
0:43
sobre isso, né? Estamos aqui com a Rafa, minha
0:47
companheira de bancada. E aí, pessoal, acho que vai ser
0:50
legal trazer esse assunto aqui hoje, até porque existem visões
0:52
contrárias, né? Alguns pontos?
0:54
Ainda não é um não. É um assunto totalmente, né?
0:57
Consolidado, né? Ainda tem muita polêmica, né,
0:59
envolvendo esse assunto, né? Pois é, então a gente trouxe
1:02
aqui especialistas para falar sobre o assunto.
1:05
Exatamente. Estamos aqui, então com o Breno.
1:08
Oi, pessoal, já veio aqui, né? 3 chaves outras vezes, né,
1:10
Breno? É um prazer estar aqui de novo
1:12
para falar desse tema assim, que é de muito bom interesse.
1:15
E estamos aqui também com o Givaldo.
1:17
Um prazer estar aqui de novo. Como você, Fernandinho e Rafa,
1:20
Breno, o pessoal que nos ouve e nos assiste, vamos lá que acho
1:23
que a discussão vai ser. Boa, exatamente como eu falei,
1:26
gente, na introdução é esse termo, né?
1:29
O espec drive in developer, né? Essa metodologia, ela não é uma
1:32
exatamente nova. Desde lá dos anos 90 já existe
1:36
muito essa vontade, né? Dos especialistas de traduzir
1:41
intenção para código, da gente conseguir descrever o
1:44
comportamento para uma ferramenta, para uma plataforma.
1:48
E ela mais ou menos automaticamente gerar o código
1:52
correspondente, né, que realiza aquele comportamento pra gente
1:56
em forma de software, né? Então essa vontade ela não é
2:00
nova, é e aí, né, com o tdd, com o bdd, que a gente vai falar um
2:05
pouco mais aqui também já foi. Foram novos passos em direção a
2:09
esse caminho, né, de descrever comportamento, de descrever
2:13
intenção, né? E tentar colocar o código.
2:18
Como secundário, vamos falar assim, né?
2:21
Mas é Oo código realmente sendo a consequência de um
2:25
comportamento. O fato é que essas práticas, né,
2:28
pdd, o bdd, elas já levaram muito a qualidade da engenharia,
2:32
mas hoje com AEAA gente tem a oportunidade de mudar, né?
2:36
Tanto a velocidade que a gente constrói software, quanto também
2:40
a qualidade, né? De talvez pela primeira vez, com
2:43
um pouco mais de certeza, né? Aproximar ainda mais a descrição
2:50
do comportamento com de fato o comportamento do software.
2:54
O sdd, eu acho que ele ele se propõe justamente a isso, e ele
2:57
e ele faz isso colocando a especificação como a rainha, né?
3:02
Como o principal, não mais o código.
3:05
Né? A especificação sendo o
3:07
principal artefato, né, de um projeto e o código sendo a pura
3:12
e simples consequência, né? Se eu sei descrever muito bem um
3:16
comportamento que eu quero que meu software tenha pronto, é
3:19
quase como se o software vai ter aquele comportamento,
3:23
invariavelmente. Então, assim, começando é esse
3:26
episódio. Eu queria que a gente até desse
3:29
um passo atrás, né? Já chamando vocês.
3:32
Pra falar um pouco um pouco mais sobre sdd, sobre o conceito, né,
3:36
sobre a metodologia em si, porque de fato assim, se a gente
3:40
for pensar, gente, até antes de ir, Ah, igual eu tava falando
3:42
aqui, a gente sempre quis escrever especificações boas,
3:46
né? Escrever especificação boas,
3:48
saber o desafio de saber o que meu software deve fazer, né?
3:53
Oo que o meu software deve fazer e não como.
3:57
Ele sempre foi um desafio para nós como empresa de ti, seja em
4:02
qualquer momento do da nossa história, né?
4:04
De software. Então, saber o que o software
4:08
deve fazer, ele sempre foi um desafio.
4:10
O que que agora é diferente? O que que o sdd de agora é
4:14
diferente de simplesmente escrever boas especificações?
4:18
Uma boa pergunta assim, né? Porque a gente vê que a gente já
4:20
teve desenvolvimento baseado em testes, a gente já teve
4:23
desenvolvimento baseado em comportamento.
4:26
E agora, o que que o sdd muda é exatamente o fato da gente ter
4:31
aí a generativa, auxiliando a gente nas etapas ali de de fluxo
4:35
mesmo, de de desenvolvimento. Então você gerar a especificação
4:39
com o auxílio da IA, que vai ser mais detalhista, vai te auxiliar
4:43
a encontrar gaps naquela especificação que você está
4:46
criando e, além disso, planejar o desenvolvimento, criar
4:50
artefatos que vão auxiliar ali a.
4:52
Execução de fato, que é a geração do código em si.
4:55
É até voltando um pouquinho no tempo, né?
4:58
A gente saiu do do waterforl, onde a gente documentava tudo,
5:02
documentava exaustivamente e é, isso era um problema, porque
5:07
isso é demandava 11 tempo muito grande.
5:11
E aí quando a gente partia para para execução do software, às
5:15
vezes o cenário já era outro, né?
5:17
As coisas começaram a mudar muito rápido, né?
5:20
No desenvolvimento de software também, a gente sempre.
5:22
Conviveu com um pouco de incerteza, de saber exatamente
5:25
Oo que se quer, qual que vai ser o resultado final das coisas.
5:28
E isso, né, levou AO atefor essa documentação exaustiva caindo
5:32
desuso, né? Vieram as metodologias ágeis.
5:34
O Breno citou aí, né, a gente tem o DDD, Oo, bdd, que ganharam
5:39
um pouco de força nessa época, porque com as metodologias ágeis
5:43
existiu também um pouco de confusão, né?
5:45
Da gente sair daquele cenário que a gente documentava tudo
5:48
exaustivamente e as pessoas começaram a confundir.
5:50
Metodologia ágil, com um desenvolvimento desordenado,
5:53
onde você não o ágil, fala de menos documentação, né?
5:56
Ninguém não fala de não documentar nada, né?
5:58
E a gente criar um cenário um pouco caótico, né?
6:01
EODDDEODDD amenizar um pouco isso.
6:03
Fernandinha citou na introdução, né?
6:04
O expectativa é que não é 11 metodologia.
6:09
Nova, né? E já existe há mais tempo, então
6:11
até algumas pessoas rotulam como 11 waterforl disfarçado, mas eu
6:15
acho que a grande, o grande aumento, né?
6:18
De de relevância do do do espec drive, agora se deve
6:22
principalmente AA inteligência artificial, que é um cenário
6:26
onde eu preciso detalhar um pouco mais.
6:28
Eu preciso delimitar um pouco mais as minhas Fronteiras ali, o
6:32
que eu quero fazer para que eu diminua as alucinações da e a,
6:36
né? Então, quando começou se a usar
6:38
e a para para gerar código, um dos principais desafios era
6:42
alucinação, falta de padrões e né, trazendo o os packdriving
6:47
para o jogo, né? Delimitando melhor ali.
6:49
O que você quer especificando melhor, o que está sendo feito?
6:52
Começou se a ter resultados mais.
6:56
Mais positivos, né? Com o uso de a para a geração de
6:59
código. Então eu acho que o grande
7:00
gatilho ali para adoção do SDD foi, né?
7:03
De fato, AO uso da a para para fazer código.
7:06
Como você bem pontuou, né? Acho que um dos principais
7:09
pontos aí de crítica ao spac reven development, é que ele
7:14
seria meio que um waterfool ali por ele dar esse foco na
7:18
documentação primeiro, né? E no manifesto ágil, um dos
7:20
princípios, fala. Software funcionando mais do que
7:24
documentação abrangente. Vocês veem isso como totalmente
7:27
o contraditório ao ágio ou vocês veem como vocês veem, um ponto
7:32
em comum? Assim, eu não vejo como
7:34
contraditório, porque o software funcionando, a geração de valor
7:38
final continua sendo o principal objetivo do processo.
7:43
É, mas o ágio, né? Ele fala em mais software
7:47
funcionando do que documentação abrangente.
7:49
E a gente não tá deixando de pensar nisso, né?
7:51
Um outro princípio do ágio é da gente conseguir se adaptar
7:55
rapidamente às necessidades, né? E se adaptar é aos contextos que
7:59
a gente tem. E 11 necessidade que a gente
8:01
passa a ter com adoção da IA, é delimitar melhor a especificar
8:05
um pouco mais. Então eu vejo isso como 11
8:08
complemento ali e né? Falando ainda sobre a questão do
8:12
ágio, AIA possibilita que possibilita que a gente gere o
8:16
código ainda mais rápido, que a gente coloca coisas em
8:18
produções. Em produção ainda mais rápido.
8:20
Então trazer essa etapa adicional de adicionar uma
8:24
especificação ali não vai é fazer com que o meu processo
8:28
fique lento, fique burocrático, que eu não consiga gerar valor
8:31
de fato ou que eu perca muito tempo planejando e isso conflite
8:36
com o timing que eu tenho para colocar alguma coisa, para
8:39
lançar algo, para colocar algo no mercado.
8:41
Eu concordo com isso. Assim, eu tava pensando sobre
8:44
isso, tava lendo algumas coisas aqui até antes do episódio.
8:47
Que é justamente, né? Quando a gente falava do do
8:49
waterforl, né, do método cascata de desenvolvimento, né?
8:52
O que que é? Como ele era, né?
8:53
Era ele tinha uma fase muito clara de especificação, né, onde
8:58
todo mundo juntava especificava. Né, exaustivamente como você bem
9:02
plantou ponto hoje. Desenhava aquele diagrama.
9:05
Fazia tudo, né? É justamente porque construir
9:07
sempre foi caro. A gente tinha que eu tenho que
9:09
lembrar isso sempre, né? Que construir era caro.
9:11
Então eu preciso especificar tudo no mínimo detalhe pra
9:14
quando eu entrar na minha fase de especificar de
9:16
desenvolvimento. Eu consegui ter tudo muito, né,
9:20
bem especificado, a ponto de conseguir desenvolver com mais
9:24
clareza e com menos falhas, né? E o ágio?
9:26
Ele veio justamente pra isso, que era assim, cara, é
9:28
impossível ser ir lá e especificar tudo um ano atrás e
9:32
desenvolver e achar que as coisas não mudam, né?
9:35
Achar que software é hard, né? Claro que não, ele é soft, né?
9:38
Então ele muda, ele transforma. Né, assim, enfim, eu acho que
9:43
esse era o waterforl. E por que que eu também concordo
9:45
com você que não é exatamente por isso que eu não acho que é
9:47
tão contraditório, porque por mais que a especificação, aqui
9:50
ela tem um protagonismo alto, né?
9:53
EEA? Gente fica querendo especificar
9:55
mais. Ainda assim, construir é rápido.
9:58
Você tem, né? Continua tendo as interações?
10:00
Curtas, né? Exatamente.
10:02
Ainda assim, na hora que eu, dado que eu estou satisfeito com
10:06
a minha especificação, é quase como apertar um botão e eu vou
10:09
construir. E se a construção não foi boa,
10:11
eu posso pedir de novo, e se não foi boa, eu peço de novo.
10:15
Eu mudo uma especificação e peço de novo.
10:17
Então por isso que eu acho que não é tão contraditório, mas ao
10:20
mesmo tempo é, é. É meio estranho você pensar
10:23
assim, que um dos das das grandes coisas do manifesto ágil
10:27
era justamente esse trecho que você falou, né?
10:29
Software funcionando então o meu ponto é, o software continuar
10:32
continuará funcionando rápido, só que agora com uma
10:35
documentação. Mais abrangente.
10:37
E eu acho que um negócio muito importante da sdd, que eu falei
10:40
no início, mas que a gente eu acho que vale a gente reforçar
10:42
aqui, é que a documentação, ela passa a ter um protagonismo.
10:46
Ela não é simplesmente uma especificação que até então a
10:50
gente usava, que era o auxílio para o desenvolvimento, né?
10:53
O que eu uso para desenvolver e a partir do momento que eu
10:57
desenvolvo, eu jogo fora minha especificação, porque afinal, o
11:00
software funcionando é o mais importante.
11:02
Agora não, agora é não. A especificação é tão importante
11:05
quanto o software, na verdade mais importante.
11:07
Então, se eu tenho uma mudança, eu vou mudar a minha
11:10
especificação e isso vai refletir uma mudança do software
11:13
por consequência. Mas tem uma outra coisa que
11:15
vocês que você falou, Givaldo, que eu queria também reforçar,
11:19
porque aqui no entra chave a gente também já falou muito
11:21
sobre esse conceito, né, que hoje a gente usa muito, começou
11:25
com o Vibe code, mas que os framors, que inclusive o Spike
11:28
kit, que é um do o framework do GitHub.
11:30
Que fala muito sobre sobre sdd acabou né?
11:34
Configurando um pouco mais, que é o negócio da gente ter 2
11:37
etapas muito claras de planejamento e execução.
11:40
Se a gente pensar que o cascata também tem 2 etapas muito
11:43
claras, só que o planejamento é muito grande e a execução é
11:46
muito grande aqui é quase como se a gente reduzisse tudo num
11:50
período de horas, né? Onde eu planejo e muito bem e
11:53
executo muito bem, mas dado pelo por esse conceito, né, de que se
11:57
eu planejo muito bem. Eu consigo dar muito mais
12:00
clareza de quais são os meus requisitos.
12:02
Eu eu consigo ter mais clareza, dar mais clareza para IA e ela
12:06
consegue executar muito mais facilmente, né?
12:09
Então acho que esse é um dos princípios muito importantes aí,
12:12
né? Do sdd, né?
12:14
De planejamento e execução, né? Bom, uma dúvida que eu tenho é
12:18
que a gente sabe que nem tudo. É nem tudo ali a prova de
12:22
falhas, né? Em algum momento ali você vai
12:24
estar numa situação onde o time está em crise, onde tem uma data
12:28
forte, 11 Deadline para ser cumprido.
12:30
EE uma, muitas dessas situações são onde as metodologias falham,
12:34
onde, por exemplo, eu vejo times.
12:36
É atuando que larga, né? Que larga, tipo xingal Rossi e
12:41
para dizer. E aí, e aí, quando?
12:44
Quando a gente está No No SDD, isso significaria ter uma forma
12:48
de, por exemplo, burlar, né? A especificação e ir direto no
12:51
código. E aí, né, aí se eu teria um
12:53
código dessincronizado ou existe uma forma de proteger o código,
12:58
né? É contra alterações que não
13:01
foram especificadas. É, Eu Acredito que isso pode
13:03
acontecer sim, né, né? Na tentativa ali de corrigir
13:06
alguma coisa, você pular a parte de especificar.
13:10
E direto na alteração ou no auto convite ali que muda um pouco o
13:14
que foi especificado, né? Mas acredito que a velocidade
13:18
que você conseguiria mexer na especificação iria tornar isso
13:21
possível sem precisar você ir direto, né?
13:24
Mas existe o risco. E um outro risco maior ainda do
13:27
que esse, acredito que é você especificar e pular etapa de
13:32
conferência, que eu acho que é essencial antes de você
13:35
executar. Porque tudo que você pede para
13:38
IA gerar, né? Você está gerando uma
13:39
especificação ali com o auxílio de a.
13:41
Se ela gerar alguma coisa, fazer um, o que seria tipo uma
13:44
alucinação ali da da IA na geração da especificação, você
13:48
vai gerar um código que não vai estar consistente com o que você
13:51
quer e aí vai ter que voltar atrás e isso vai gerar um
13:54
retrabalho. Que vai atrapalhar ainda mais
13:56
ali, naquela necessidade de entregar rápido, né?
13:59
Concordo com com isso que vocês acabaram de falar, né, que a
14:02
gente revisar e a gente fala muito isso aqui no entre chaves
14:05
é a coisa mais importante, né? Assim, revisar na especificação
14:09
e consequente hoje ainda revisar o código são são as coisas mais
14:12
importantes. E às vezes eu sou um pouco mais
14:14
otimista, talvez ou pessimista, né, dependendo do que vocês, de
14:18
qual que é a visão, né, que enfim, que as pessoas acreditam
14:22
que deveria ter, que deveríamos ter, né?
14:25
Mas no final das contas, eu acho que tudo é uma mudança de
14:27
mindset. Se enquanto mudar uma
14:29
especificação não for fácil o suficiente, esse negócio nunca
14:32
vai pegar. Então, assim, é no limite.
14:35
Na hora que se essa metodologia pegar de verdade, mudar uma
14:39
especificação deveria ser tão fácil quanto mudar um código.
14:43
Então, no limite, a pessoa não deveria querer mudar o código,
14:47
ela deveria querer mudar a especificação, já que ela está
14:50
nessa metodologia de de espectro, né?
14:54
É como quase como se o código fosse uma caixa preta.
14:56
EE assim, vai demorar mais eu entender o código, porque eu não
15:00
entendo ele quase vamos falar assim, né, gente?
15:03
Estou no limite. Óbvio que hoje a gente tem que
15:05
revisar código, a gente tem que saber o que que a gente está
15:06
colocando, a gente é responsável, então assim, né,
15:09
mas vamos colocar no limite ali de que realmente a
15:12
especificação, ela expressa 100% do comportamento do meu
15:14
software. Nesse limite eu não quero mais
15:17
revisar código, eu quero revisar especificação, e tem que ser
15:20
fácil fazer isso, porque senão. Os negócios não vai pegar esse
15:24
negócio, essa metodologia não vai funcionar.
15:26
Você tocou num ponto que eu acho interessante é que a gente tem
15:29
que considerar que OA especificação, ela está sendo
15:32
100% abrangente, mas e nos casos que são extremos assim, de
15:37
nuances que aparece só no código e você só percebe no momento da
15:41
implementação? Mas esse que é o negócio.
15:43
Mas é é esse que é muito doido mesmo.
15:46
Mas é muito doido assim, a complexidade, por favor, dêem
15:48
uma opinião suas também. Mas assim para mim é tipo isso é
15:51
como se assim. Essas coisas aí, elas vão
15:54
começar a ser meio que transparentes.
15:55
Assim, eu não vou saber uma coisa que vai estar só no
15:57
código, eu vou estar, eu vou saber o que que está na minha
16:00
especificação. Se a partir do momento que eu
16:02
confio 100% que a minha especificação produz bons
16:05
códigos, eu não preciso mais saber o que que está no código,
16:08
eu preciso saber o que está na especificação.
16:10
Mas já chegamos. Aí é outra história, aí é outra
16:14
história, mas é. Mas é como se é como se a gente
16:16
realmente estivesse adicionando uma camada de abstração.
16:19
Na nossa programação é quase como se o futebolasse quando
16:22
seria assim? Ah, agora, pra você corrigir um
16:24
bug, você você tem que olhar e saber a linguagem de máquina.
16:27
Você não tem, não. Você não precisa conferir se na
16:30
linguagem de máquina os bits estão certos, alocados
16:32
corretamente na posição da memória.
16:34
Não precisa, entendeu hoje isso? Esse é o ponto, seria como, se a
16:37
gente? Se hoje a gente está programando
16:41
a linguagem qualquer e a gente fosse lá nos nos, nos binários.
16:45
Lá nos ficar se conferindo, precisar as confinas, porque
16:48
você não acredita que o que você está produzindo é o correto,
16:52
entendeu? Só que aí, no limite, a gente
16:55
vai passar a acreditar que é correto.
16:56
Eu não vou precisar saber isso aí.
16:58
E aí só mais uma coisa antes de passar a palavra para vocês,
17:01
porque vocês que são os convidados, né?
17:03
Assim não. Mas é um assunto que eu gosto
17:04
muito. Mas no passado, quando eu eu
17:07
programava, há 500 anos atrás, tinha 11 framor, que é aqui que
17:11
a gente usava na dti, que tinha geração de código, nunca, nem
17:15
era. Não tinha nada a ver com LLM,
17:17
nada a ver com nada disso. Era só uma geração de código
17:19
totalmente determinística, mas que eu tinha um programinha que
17:23
eu entrava, IA lá modificava umas coisas e isso aqui gerava
17:27
um código. E tinha a hora que eu IA queria
17:30
ir lá no código e mudar isso aqui, porque às vezes era até
17:33
mais fácil do que ir no programa e ficar alterando.
17:36
Só que se eu fizesse isso, a minha próxima geração de código
17:39
é subrescrever o meu código que eu fiz, entendeu?
17:42
Tipo assim, ele IA, eu IA perder essa modificação.
17:46
Então eu tinha que ir aqui, e aí por isso que eu tô falando que
17:48
isso aqui tinha que ser muito fácil.
17:50
Tinha. Ir no programinha e mudar tinha
17:53
que ser muito fácil, porque senão eu IA lá no código e IA
17:56
ficar o tempo inteiro tendo esses problemas de sincronia,
17:59
sabe? Então assim é, esses problemas,
18:02
enfim, existem. E tem a opinião de vocês, por
18:04
favor. É só complementando, e pelo o
18:06
que o Givaldo falou, se esse processo falha e o código fica
18:10
dessincronizado, você teria uma manutenção.
18:12
Teria outra possibilidade que ele falou?
18:14
Né? Seria mais é trabalhoso de
18:16
qualquer. Forma, mas dentro disso que a
18:18
Fernandinha falou, né? De remeteu ao passado, né?
18:21
Tem alguns. Os autores que defendem que a
18:22
gente tá na quinta geração ali da forma como como se faz
18:26
código, né? Começou lá atrás com com os
18:28
assembles, né? A gente passou pra para as
18:31
linguagens de alto nível e a gente tá estaria no numa nova
18:34
geração agora que é a fonte ali é a especificação, né?
18:39
E o que é gerado ali vira vira commodity.
18:42
Tem até 11 artigo da toatorcs que ele categoriza, né?
18:47
AOO desenvolvimento orientado por especificação, né, que ele
18:50
fala de. Na primeira etapa, ali é um
18:53
primeiro nível de maturidade que seria o spechasa first, que é
18:57
quando você gera uma especificação, faz o código e
19:00
descarta aquela especificação. Segundo nível seria o
19:03
spechancore, que é onde a sua você faz e evolui aquela aquela
19:08
especificação e as suas né evoluções são são vão derivar
19:12
ali de atualizações Na Na especificação, mas você ainda
19:15
continua olhando para o código, o código continua tendo um papel
19:18
relevante, o terceiro nível. Que seria de fato, onde a sua
19:23
especificação é a sua total fonte da verdade.
19:27
Ali você trata o código gerado quase como um binário, como uma
19:30
caixa preta ali. E nessa ideia do que o Givaldo
19:33
falou também, né? É essas preocupações que a
19:36
gente, como desenvolvedor, sempre teve, elas continuam
19:40
existindo, principalmente porque a gente tá lidando com algumas
19:43
variáveis quando a gente tá usando esse essa metodologia,
19:46
que é o modelo que você vai usar para gerar o código.
19:49
O modelo de a, né? Se você pegar o modelo melhor
19:51
ali dos resultados, vão ser diferentes.
19:53
Você troca o modelo, né? Por exemplo, no meio do do
19:56
desenvolvimento do produto, isso geraria um impacto.
20:00
Muda completamente e isso vai muito para essa parte ali de
20:03
segurança. Como que você, como
20:05
desenvolvedor, vai garantir que o código está com o que você
20:08
especificou ali que deveria ter com relação à segurança, com
20:11
relação a, enfim, todas aquelas preocupações que a gente costuma
20:14
ter quando está olhando para o código.
20:16
Como que a gente vai ter isso agora?
20:18
Com foco na especificação, né? Então assim, eu particularmente
20:21
ainda acho que o código é essencial ali pra a gente
20:24
conferir esses detalhes importantes pra criar 11
20:27
software pronto pra produção. Vamos, vamos então entrar
20:30
justamente nessa Seara aí, né, da prática do do estado atual,
20:34
né? Porque hoje AA gente tem vários
20:36
framurx, várias coisas que implementam, vamos falar assim,
20:39
né? Essa metodologia de espec driven
20:41
development. Mas como o jowaldo até falou,
20:43
né, alguns nem estão No No nível de maturidade realmente.
20:49
Pegar essa essência da especificação.
20:51
Realmente isso é a fonte da verdade.
20:53
Mas né, às vezes estão nos níveis um pouco menores, né?
20:57
Mas já pelo menos começam a flertar com esse conceito.
21:01
Então como é que vocês veem assim que estão assim as
21:03
ferramentas, os frameurs, né? O estado atual do mercado em
21:07
relação a essa prática? Entre os frameurs, né, que a
21:10
gente mais tem utilizado aqui, né?
21:13
É estão o spec kit lá do do GitHub, curso ripper, o agente
21:19
OSE. Eu Acredito que esses frameworks
21:21
eles estão ali na No No nível ali do do spechancort né né?
21:26
Eles não são a especificação como como a fonte da verdade em
21:30
alguns cenários, até no specfourt que aquela não é, ele
21:35
não mantém aquela documentação centralizada e vai atualizando,
21:39
ela vai gerando novas especificações a medida que.
21:43
Que você vai vai evoluindo, mas não, não mantém aquilo ali, mas
21:47
não volta atualizando aquela aquela especificação, né?
21:50
Ele mantém uma documentação centralizada ali com com os
21:53
padrões, né, com roadmap, emissão do produto.
21:57
Mas né, ele não pega. Se você quer fazer uma
22:00
alteração, ele não pega. A especificação que você fez e
22:03
altera essa especificação vai gerar uma nova especificação.
22:06
É ele. Ele pega mais o princípio, né,
22:07
que é o que a gente tava falando aqui, de planejar e depois
22:10
executar, né? Quase como se fosse assim.
22:12
Pra eu executar bem, eu preciso planejar bem, então eu preciso
22:15
fazer uma especificação, mas dado que eu executei e essa
22:18
especificação morre, né? Como se fosse.
22:20
Mas ao mesmo tempo ele mantém essa essa essas especificações
22:23
né No No repositório né mencionado ou ele aqui o serve
22:27
de contexto pra pra pra futuras evoluções?
22:30
Então não diria que é um espec first onde ele usa a
22:33
especificação, depois descarta totalmente aquilo.
22:36
Mas também ainda não é 11. Está próximo ali, talvez, e
22:41
ainda um pouco distante do do spect as a source, que é onde
22:45
seria aquele cenário onde AA especificação é a única fonte da
22:49
verdade ali, né? Mas eu acho que nem o espec kit
22:51
assim, não sei. Posso estar errada, né?
22:53
Assim vocês falam a opinião suas, mas talvez é um dos
22:56
prêmios mais evoluídos, né? Que implementam, talvez um pouco
22:59
mais essa esse conceito, né? Do sdb.
23:03
Nem ele assim tá? Eu vejo ele como os pack
23:05
hancords ali próximo, bem próximo, mas se você for ser
23:09
muito preciosista ele algumas coisas ele ainda não não estão
23:13
presentes. Nele, o principal dele, né?
23:15
Não sei se todo mundo conhece que está nos ouvindo, mas o pack
23:17
kit, como eu falei né? O framewk do GitHub que trata de
23:20
sdd, né? Que implementa o sdd, ele tem
23:23
vários e vários comandos. Quando se ele se autodetermina,
23:26
né? Quando ele é se conceitua, ele
23:29
coloca como? Ele coloca como se ele fosse um
23:31
espectro asserce, né? Como se ele realmente mantivesse
23:35
as especificações como fonte de verdade.
23:37
Mas pelo menos até onde eu vi as últimas, as últimas
23:41
atualizações, ele ainda não respondia coisas muito básicas,
23:44
como por exemplo, e um sistema legado.
23:46
E aí eu tenho que eu tenho que criar especificação do sistema
23:49
inteiro para começar a mexer nele, fazer umas coisas muito
23:52
básicas, né, assim, e aí, né, realmente na hora que eu.
23:56
Altera 11 especificação, eu posso ir na especificação,
23:59
alterar. Mesmo que isso vai funcionar,
24:01
vai refletir no meu código é esse?
24:04
Essas 2 perguntas pra mim são básicas.
24:06
Eu acho que nenhum deles, pelo menos que eu conheço, já já
24:09
responderam, né? Vocês concordam com isso ou não?
24:12
Já tem coisa mais atual que eu estou perdendo?
24:15
Eu acho que nas experimentações que eu tive com algumas dessas
24:18
metodologias, desses premiworks, né?
24:20
O espec kit, ele é muito completo.
24:23
A partir do momento que você já tem a estrutura da arquitetura
24:27
bem definida, do seu projeto, da sua, da sua funcionalidade ali,
24:30
do que você está criando a partir de é a primeira etapa do
24:34
do spec kit, é o constitution, que seria você definir como vai
24:37
ser as coisas. Então ele é muito voltado,
24:40
talvez ali para um projeto novo. E eu tive um pouco de
24:43
dificuldade de aplicar isso em projetos já existentes.
24:46
E aí vendo, por exemplo, o kiro, né?
24:49
Como o kiro, como kiro funciona. Ele tem uma etapa de stream que
24:53
consegue analisar a arquitetura do do projeto de uma forma muito
24:56
eficaz e gera é artefatos ali de arquitetura, de design, de
25:01
padrões que são usados ali ao longo de todo o processo.
25:05
E o que o que dá para fazer, né? Você usar algumas é partes de
25:10
fremocos diferentes e consolidar isso no fluxo que vai te atender
25:13
da melhor forma. Isso também funciona.
25:15
Que foi o que eu já fiz, né? Para atender ali as minhas
25:18
necessidades, inclusive mexendo com projetos legais ou projetos
25:22
que já já existem ali. Então essa é uma sugestão até,
25:25
né? Que você definir arquitetura,
25:28
definir padrões e jogar isso no constitution das pack kits, isso
25:31
ajuda muito. Aí você consegue evoluir melhor
25:33
esse esse uso do do framework. Que é isso?
25:36
Como as coisas também estão muito novas, elas.
25:38
Ainda nos consolidaram mesmo, né?
25:40
Então é difícil ter realmente o qual você falou assim, né?
25:43
Uma coisa que é muito padronizada, muito correta, de
25:46
vai funcionar em todos os cenários, não vai mesmo não
25:49
assim, né aqui, mas mas em compensação eu acho que projetos
25:53
greenfield, que é o projeto novo, né?
25:56
Até aqui na dti a gente já tá com alguns times utilizando o
26:00
Spike kit, tendo bons resultados, né?
26:02
Então assim parece que é quando o projeto é novo.
26:06
Parece uma boa, né? Porque você já começa de cara já
26:09
mantendo a especificação, com uma alta qualidade, saudável
26:13
nessa relação, né? Saudável entre código e
26:16
especificação. E aí você vai talvez, né,
26:18
conseguindo ter uma coisa interessante ali, igual eu
26:21
falei, eu acho que essas, esses prêmios, essas plataformas,
26:24
esses produtos, eles ainda não respondem questões básicas assim
26:28
de projetos existentes, né? Assim, e como realmente essa
26:31
dinâmica acontece na prática mesmo.
26:34
Eu acho que a gente ainda tem um caminho para andar.
26:37
Eu acho que existe um conflito também quando você está
26:39
definindo arquitetura, design e padrões de um projeto existente
26:42
com o que você quer que aquilo se torne, que aí vai conflitar,
26:47
né? Aí ela vai sugerir melhores
26:48
padrões, às vezes, que vão em conflito direto com o que está
26:51
lá hoje. E o.
26:52
Código ele é fundamental também para isso funcionar, porque é
26:56
hoje as LMS que que a gente tem no mercado.
26:59
Elas dependem de ter contextos autocontidos e, principalmente,
27:03
quanto menor o contexto, melhor, né?
27:06
Se você tem um código limpo, um código sem acoplamento AIA, vai
27:09
funcionar muito bem, né? Agora, se você tem um código ali
27:13
todo acoplado ali, todo mal escrito, onde você vai precisar
27:17
de, por exemplo, a gente passar no contexto da IA vários
27:20
arquivos Pra Ela entender, uma simples funcionalidade não vai
27:24
dar. Certo, né?
27:25
É, a gente até já fez um episódio aqui, né?
27:27
Sobre o Dora. Que ele fala muito que no Dora o
27:30
relatório atual, né, de 2025, não é verdade, fala sobre AIA
27:34
ser um grande amplificador, né, que no final das contas é isso,
27:38
se o meu código tá mal escrito, é exatamente é difícil a gente,
27:44
e aí como você falou, né, quando a gente define, a gente quer
27:47
fazer um negócio bem feito, mas e aí, agora eu vou gerar um
27:50
código no padrão que o meu código tá, ou no um código com
27:55
os melhores padrões, né? As boas práticas de mercado.
27:58
Aí você fica nessa, assim como também quando você estivesse
28:00
desenvolvendo, você também teria talvez esse dilema, né?
28:02
Mas, enfim, é, é um são coisas mesmo que eu acho que ainda
28:07
temos dificuldades com os próprios framers, né?
28:10
E as próprias ferramentas atuais.
28:13
Né de SDD? Eu queria voltar até um pouco
28:15
sobre o espec, que especificamente, né?
28:17
É essa questão da evolução e da gente não tomar aquilo como uma
28:21
verdade absoluta, que já tá 100% consolidado.
28:24
É só olhar a quantidade de versões De Lá Pra Cá.
28:27
Assim, de quando surgiu todo dia, aparentemente surge uma
28:31
versão nova, então, assim. O que é bom e é ruim, né?
28:33
Tipo assim, é bom também porque a porque a comunidade abraçou
28:36
totalmente, né? É o prêmio que está atualizando
28:39
pra caramba. Mas tem essa parte ruim que quer
28:41
dizer assim, que ainda tem gaps, né, para serem.
28:44
Exatamente, e essa evolução, né? Até onde eu observei assim, é
28:48
muito voltada para criar guard railes durante o processo para
28:53
te auxiliar nessa revisão da especificação, que além de você
28:57
conseguir revisar o que ela tá criando, as etapas do próprio
29:00
framework que vão ali interagir com o que foi gerado, comparar,
29:04
criar checklist do que deveria ter e comparar depois o
29:07
resultado do código gerado com o que foi especificado.
29:10
Que isso é muito importante. E isso foi é até recente No No
29:14
espec kit, né? Então assim, essa evolução é
29:16
muito benéfica assim, e eu e eu vejo que vai ajudar demais assim
29:20
nessa nessa consolidação de fato desse framework.
29:23
Todo negócio, né? Todas essas evoluções, elas
29:26
ficam tentando justamente juntar.
29:28
Foi até o que eu falei no início, né?
29:29
A gente ter mais certeza que, dado um comportamento bem
29:34
especificado, eu consigo produzir um bom código.
29:38
E aí, o tempo inteiro a gente tá tentando lidar com esse dilema,
29:41
porque, no final das contas, às vezes vocês concordam comigo.
29:45
Hoje é muito difícil a gente falar o que que é uma boa
29:47
especificação. É muito subjetivo.
29:50
Eu trato uma boa especificação de um jeito, provavelmente a
29:53
Rafa trata de outro, provavelmente a minha boa
29:55
especificação pode até ter um padrão, né?
29:58
Um modelo, mas ela vai ter algumas informações e talvez a
30:02
da Rafa vai ter outros. E no final das contas, a gente
30:05
não chegou ainda uma consolidação, um conceito como
30:09
engenharia de software do que que é uma boa especificação,
30:12
dado que eu não sei o que que é uma boa especificação, é difícil
30:15
demais. De eu chegar e produzir um bom
30:18
código, porque o fato é o código, ele é determinístico o
30:21
código eu posso achar, eu posso achar o que eu quiser.
30:24
Mas se eu fizer um if e a Rafa fizer um if, a gente
30:26
provavelmente vai fazer Oo mesmo.
30:28
If se a gente está resolvendo o mesmo problema.
30:30
Agora, se eu estou escrevendo uma especificação, ela está
30:32
escrevendo uma especificação para o mesmo objetivo.
30:35
A gente pode escrever de milhões de formas diferentes.
30:38
Eu acho que o ponto seria a ambiguidade, né?
30:40
Eu acho que talvez a ambiguidade seria uma boa métrica para
30:44
exatamente, mas ainda subjetivo. Ô, Fernandinha, mas você trouxe
30:47
um bom ponto, você está falando sobre, né?
30:49
Que se você escrever uma especificação e a Rafa escrever
30:52
uma, as especificações vão ser diferentes, beleza.
30:55
Se vocês escreverem um hífen, vai ser igual.
30:57
Mas se vocês escreverem um software inteiro, ele pode gerar
31:00
o mesmo resultado. Mas o software vai ser
31:02
diferente? Não.
31:03
Não tem uma forma única de de desenvolver software, e isso
31:06
talvez, né? Contribui pra pra geração de
31:09
resultados tão diversos pela pelas pelas ias, porque elas
31:13
elas são treinadas, né? Os bilhões de parâmetros que
31:16
forem foram usados lá no treinamento dela.
31:18
Tem formas diferentes de fazer AA coisa também.
31:21
Então ela já tem uma característica não determinista
31:23
ali e isso eu acho que amplifica ainda mais essas.
31:26
Essas diferenças, essas nuances que vão que vão existir.
31:30
Mas o meu ponto é assim é que se a gente conseguisse, né?
31:32
Se a gente conseguisse estabelecer com muita certeza,
31:35
com muita objetividade, uma boa especificação e ter certeza que
31:39
essa boa especificação ela produz um bom código, pronto.
31:42
Aí meu desafio tá quase que resolvido, né?
31:45
Por mais que assim, às vezes eu vou, eu vou.
31:47
Se eu rodar aquela especificação 15 vezes, eu vou produzir 15
31:50
códigos diferentes por causa dessa, de tudo isso que a gente
31:53
tá falando, nunca vai ser um para um.
31:55
Mas se eu tiver certeza que uma boa especificação cria um bom
31:59
código, tá ótimo, né? Mas não é isso que a gente tem
32:02
hoje, por isso que a gente precisa ficar revisando, por
32:04
isso que a gente precisa, né, ter todos os cuidados.
32:07
A gente precisa não só revisar a especificação, a gente vai
32:10
precisar pra sempre, né? Pensando que o sdd vai ser a
32:13
metodologia que a gente vai seguir, né?
32:14
Revisar código pode ser que no limite a gente não precisa mais,
32:17
mas hoje a gente precisa porque afinal, né, enfim, somos
32:21
responsáveis e a gente ainda não confia.
32:23
É e no ponto que você falou? Das evoluções do dos framux
32:27
voltados para que eu gere cada vez mais uma uma especificação
32:30
que produza bom código, né? Eu acrescentaria, né?
32:33
Que reduza as as alucinações, né?
32:36
Minimize esse efeito do do, do não determinismo da ya para a
32:39
gente chegar justamente nesse ponto que você falou de Ah, eu
32:42
tenho a consciência aqui. Eu tenho a confiança de que se
32:45
eu passar uma boa especificação para a ya, o código gerado vai
32:49
ser confiável. Não preciso me preocupar em.
32:52
Tanto com a revisão de eu acho que isso é uma realidade talvez
32:55
um pouco distante. É, acho que essa ainda vai ser
32:57
bem distante. Tem 11.
32:59
Detalhe que vai bem nessa vertente da do código que vai
33:02
ser gerado a partir da da especificação, que é a primeira
33:05
etapa de especificação dele, né? Na maioria dos dos framers que a
33:09
gente tem hoje para para para a espec drib, a primeira etapa,
33:13
ela é muito focada na parte funcional da especificação, né?
33:16
Então é é criada de uma forma AAO artefato é criado de uma
33:20
forma. O que eu poderia definir EEO
33:23
ideal é que seja assim. A tecnologia é só depois que já
33:26
tiver especificado. Então eu não tô focando em
33:29
tecnologia, não tô focando em como que isso vai ser feito, em
33:32
qual linguagem que vai ser feito.
33:34
Eu tô focando em especificar o que eu quero, né?
33:37
Que é aquela ideia que a gente tinha de behavio.
33:39
Então assim é focar na intenção, e aí a aia consegue criar essa
33:44
especificação que vai poder ser usada.
33:46
Em qualquer tecnologia, você vai poder migrar isso depois muito
33:50
facilmente, então isso fica com uma documentação muito viva e
33:54
fácil de utilizar de vários formas.
33:57
E aí o desenvolvedor, né? Assim é a carga cognitiva dele.
34:01
Vai muito mais para esse lado, né?
34:02
Da intenção do software, né? Do que o software tem que fazer?
34:06
De qual é o comportamento dele. Do que pro como, de qual
34:10
linguagem ou de qual arquitetura, ou de como no
34:13
detalhe resolver aquele problema de negócio, né?
34:16
Então a gente fica muito mais sendo essa ponte, né?
34:19
Do negócio, que eu acho que é um negócio que a gente sempre teve
34:23
dificuldade na ti, né, que é aproximar o negócio, né, do
34:28
software, né, da tecnologia, como que a gente diminui essa
34:31
distância, né, entre quem conhece a intenção e quem produz
34:35
o código, né? A gente começa a tentar fazer
34:39
com que essas coisas aproximem mais, né?
34:41
E assim, e a gente se torne talvez como desenvolvedores,
34:45
muito mais essa ponte, né? Entre negócio e tecnologia do
34:49
que a gente era antes até, né? Eu acho assim.
34:51
Eu vejo com muito otimismo porque hoje já acontece isso nos
34:56
times da gente utilizar a linguagem natural para gerar
34:59
código, a gente já. Usa IA para nos ajudar Copilot.
35:04
Só que a sensação que eu tenho é que se sei lá se tem um time de
35:08
7 pessoas que estão desenvolvendo features com apoio
35:11
do Copilot, com apoio de IA. Essas pessoas, cada um deles
35:15
tem. Eles fazem prompt da a sua
35:18
maneira, então eles tem a sua forma única de conversar com a
35:20
IA. Que vai gerar.
35:22
É um resultado diferente pra todo mundo.
35:24
Então eu vejo como o espectro even development, uma forma de
35:27
você garantir que tá todo mundo falando a mesma língua com AIA.
35:32
Por isso que eu acho que é. Esse é o melhor caminho, né?
35:34
Pelo menos que eu vejo. Eu acho que é isso que eu tô até
35:37
falando início, né? Que é como sempre foi um desafio
35:40
antigo da gente, aproximar o comportamento da execução, né?
35:44
Do que que a gente realmente quer que o software faça.
35:47
É isso, assim é o bdd, o pdd. Eles sempre tentaram fazer isso,
35:51
né? Eles estavam tentando fazer
35:52
isso. Quando a gente fala de teste de
35:53
drive and development e de behavior drive and development,
35:56
né, era isso, Era Eu criar os testes primeiro antes do código,
36:01
para ter mais clareza de onde, quais são os meus pontos de
36:05
falha, da onde eu quero chegar, quais são os meus meus cenários
36:09
de sucesso, quais são os meus cenários de erro, para só assim
36:12
eu implementar o meu código OB rave ainda mais, né?
36:15
É eu ter. Clareza dos meus cenários
36:18
completos de comportamento, da onde eu quero ir pra depois
36:21
implementar o meu código. E eu vejo realmente o sdd é uma
36:24
como uma evolução, né? Dessas 2 coisas aí, sempre
36:28
buscando fazer essa aproximação entre negócio e ti, realmente a
36:32
gente, diminuindo esses gaps, diminuindo essas falhas de
36:35
comunicação que a gente tem, né? Sobre o bdd que você comentou,
36:40
é, parece muito em conceito, né? Até difícil a gente definir a
36:43
Fronteira do que que é um, do que que é outro.
36:45
Será que? Sdd é só um bdd com uso de a mas
36:49
assim até vocês me corrijam, se eu tiver errada, eu entendi
36:52
muito que no bdd é como se você tivesse usando linguagem natural
36:56
para explicar o sistema, um ser humano.
36:58
E no caso do sdd, você está impondo uma especificação ao
37:03
código, né? E não ao ser humano.
37:05
Vocês concordam com essa afirmação?
37:07
Eu concordo e inclusive acrescento que a parte do sdd
37:12
que se destaca assim com relação ao bdd.
37:14
É a quantidade de artefatos que ele gera que não é simplesmente
37:18
a parte de definição ali do que vai ser feito, da intenção ao
37:22
longo do processo de especificação.
37:24
Ele vai especificar parte de design, vai especificar parte de
37:28
arquitetura e vai criar Tarefas daquilo já.
37:31
Então, assim, ele vai destrinchar aquilo em etapas
37:35
muito bem detalhadas que talvez o bdd na mão, né?
37:38
Se a gente fosse construir aquilo ali na mão, definir
37:41
comportamento, a gente não IA. Destrinchar tão bem quanto aí a
37:44
faz hoje. Bom, gente, acho que é por isso.
37:47
Assim, achei muito legal o papo falando bastante aí de muitos,
37:51
muitos assuntos dentro do espectro drive, né?
37:53
Desde conceito até polêmicas. Foi muito massa e é isso aí,
37:58
então é isso. Então valeu demais, galera, todo
38:01
mundo que. Está aí nos ouvindo?
38:02
Até agora? Obrigado, pessoal.
38:04
Foi muito legal. É isso aí até.
38:05
A próxima? Tchau, tchau, até a próxima.