Resumo Técnico: Não Existem Dois Desenvolvedores que Pensem da Mesma Forma

Declaração do Problema

Embora os assistentes de programação conversacionais baseados em Grandes Modelos de Linguagem (LLMs) (por exemplo, o GitHub Copilot Chat) ofereçam benefícios significativos para a geração e compreensão de código, estudos recentes indicam que desenvolvedores individuais possuem necessidades diversas e enfrentam desafios únicos ao utilizar essas ferramentas. As ferramentas atuais falham frequentemente em apoiar plenamente a diversidade cognitiva — a variação nos estilos cognitivos, habilidades mentais e abordagens de resolução de problemas entre indivíduos. Essa falta de suporte manifesta-se como inequidades na adoção e eficácia entre diferentes níveis de experiência, gêneros e estilos de resolução de problemas. Existe uma lacuna crítica na compreensão de como esses fatores cognitivos moldam padrões de interação específicos e necessidades subjacentes durante a colaboração humano-IA.

Metodologia

Os autores realizaram um estudo de pensamento em voz alta (think-aloud) de métodos mistos envolvendo 27 engenheiros de software profissionais e estudantes. O estudo foi desenhado para maximizar a diversidade em experiência e estilos de resolução de problemas, embora a diversidade de gênero tenha sido limitada (4 participantes do sexo feminino).

• Participantes e Perfis: Os perfis cognitivos foram coletados via questionários pré-estudo medindo experiência (proficiência em programação, uso de assistente de IA) e estilos de resolução de problemas usando o framework GenderMag (abrangendo autoeficácia, motivação, estilo de aprendizagem, processamento de informação e atitude em relação ao risco).
• Tarefas: Os participantes completaram seis tarefas de alteração de código progressivamente difíceis dentro de uma base de código React (uma variante do TodoMVC). As três primeiras serviram como prática; as três finais foram tarefas completas.
• Interação: Os participantes utilizaram o GitHub Copilot Chat (dentro da IDE) para completar as tarefas. Eles foram instruídos a pensar em voz alta, narrando seu raciocínio, enquanto os pesquisadores gravavam tela, áudio e dados de telemetria.
• Análise de Dados:
  • Quantitativa (RQ1): Os autores empregaram modelagem de tópicos (Latent Dirichlet Allocation e Non-negative Matrix Factorization) em sequências de prompts anotadas para identificar distintos modos de interação. Os prompts foram codificados por intenção, contexto e estratégia.
  • Qualitativa (RQ2): Utilizando teoria fundamentada (grounded theory) (codificação aberta e axial) em transcrições de pensamento em voz alta e entrevistas pós-estudo, os autores identificaram indutivamente as necessidades subjacentes que impulsionam as interações.
  • Correlacional (RQ3): O estudo analisou as relações entre distribuições de modos de interação, perfis cognitivos (experiência e facetas do GenderMag) e percepções (Modelo de Aceitação de Tecnologia e NASA-TLX de carga cognitiva) usando a correlação de postos de Spearman.

Principais Contribuições

1. Cinco Modos de Interação: O estudo caracteriza cinco padrões distintos de interação que os desenvolvedores exibem com o Copilot Chat:
   • Navegador (Navigator): Usar o Copopit para localizar recursos de código ou estruturas de alto nível, frequentemente sem a contextualização adequada.
   • Piloto Automático (Autopilot): Tentar resolver tarefas inteiras de ponta a ponta com prompts de alto nível, dependendo fortemente do botão "aplicar" (apply).
   • Substituto (Deputy): Resolução de problemas colaborativa e incremental, onde o desenvolvedor e a IA trabalham juntos, envolvendo frequentemente pedidos de explicação e refinamento iterativo.
   • Técnico (Technician): Usar o Copilot para geração de código granular e de baixo nível ou detalhes de implementação, tipicamente envolvendo copiar e colar manual ou digitação.
   • Erudito (Scholar): Usar o Copilot para suporte de informação, explicação de código ou conhecimento geral, frequentemente envolvendo a colagem redundante de código.
2. Dez Necessidades Subjacentes: O estudo identifica dez necessidades centrais que impulsionam essas interações, incluindo as necessidades de Habilidade (Ability), Agência (Agency), Experimentação (Experimentation), Garantia (Assurance), Produtividade (Productivity), Facilidade (Ease), Aprendizado (Learning), Compreensão (Understanding), Delegação (Delegation) e Controle (Control).
3. Modelo Conceitual: Os autores propõem um modelo conceitual que vincula essas necessidades e modos de interação aos perfis cognitivos individuais (experiência e estilos de resolução de problemas) e fatores contextuais. O modelo ilustra como as necessidades podem reforçar ou competir entre si (por exemplo, a necessidade de facilidade pode aumentar a delegação, mas diminuir a necessidade de controle).

Resultados

• Diversidade de Interação: Os participantes exibiram alta diversidade nas distribuições de seus modos de interação. Embora o modo Substituto (Deputy) tenha sido o mais dominante entre as tarefas, houve variação significativa baseada nos perfis individuais.
• Correlações de Experiência: Uma maior experiência em programação e no domínio correlacionou-se com o aumento do uso do modo Técnico (Technician) e a diminuição dos modos Navegador (Navigator), Piloto Automático (Autopilot) e Substituto (Deputy). Isso sugere que desenvolvedores experientes migram da delegação para o controle.
• Estilos de Resolução de Problemas:
  • Motivação (usar a tecnologia por si só) correlacionou-se positivamente com o modo Técnico (Technician) e negativamente com os modos Erudito (Scholar) e Substituto (Deputy).
  • Processamento Seletivo de Informação correlacionou-se positivamente com os modos Navegador (Navigator) e Piloto Automático (Autopilot), sugerindo que esses usuários delegam para obter soluções aceitáveis em vez de buscar uma compreensão profunda.
  • Tolerância ao Risco mostrou correlações inesperadas, potencialmente indicando que, neste contexto, a tolerância ao risco relaciona-se ao medo de falhar ao criar uma solução manualmente, em vez do risco de usar a IA.
• Percepções e Carga:
  • O modo Piloto Automático (Autopilot) correlacionou-se com menor demanda mental percebida, apoiando a ligação entre delegação e facilidade.
  • O modo Técnico (Technician) correlacionou-se com significativamente maior demanda física, provavelmente devido à implementação manual de trechos de código.
  • O modo Erudito (Scholar), embora apoie a produtividade, correlacionou-se com maior esforço percebido, sugerindo que a necessidade de controle ou compreensão neste modo se sobrepõe ao desejo de facilidade.

Significância e Alegações

O artigo afirma que a diversidade cognitiva molda fundamentalmente como os desenvolvedores interagem com assistentes de programação. Os autores asseveram que:

• Soluções de tamanho único são insuficientes: Os desenvolvedores não interagem com LLMs de maneira uniforme; seu comportamento é impulsionado por uma interação complexa de necessidades (por exemplo, a tensão entre a necessidade de facilidade e a necessidade de controle) e perfis cognitivos.
• O contexto importa: O contexto profissional e a complexidade da tarefa impactam diretamente a ativação de necessidades específicas (por exemplo, a necessidade de garantia aumenta com a complexidade da tarefa).
• Implicações de Design: Para melhorar a inclusividade e a eficácia, pesquisadores e construtores de ferramentas devem considerar essas diversas necessidades. Isso envolve projetar assistentes que suportem modos de interação granulares (como o Técnico) juntamente com modos colaborativos (como o Substituto) e fornecer "affordances" claras para que os desenvolvedores entendam as capacidades e limitações da ferramenta.
• Direção de Pesquisa: O modelo conceitual fornece uma base para raciocinar sobre as interações desenvolvedor-IA e gerar hipóteses para trabalhos futuros, indo além de simples métricas de uso para entender o porquê por trás dos padrões de interação.

Os autores mantêm uma postura modesta, observando que seu estudo é exploratório e que links causais não foram estabelecidos definitivamente. Eles enfatizam que suas descobertas não devem ser interpretadas como padrões universais, mas sim como evidência das necessidades diversas e únicas que os desenvolvedores trazem para a engenharia de software assistida por IA.