fernanda mascheti

sou a Fernanda, educadora, pesquisadora e entusiasta de tudo que envolve computação. busco justiça social, equidade e uma educação arrebatadora. compartilho ideias que me inquietam, projetos em que estou mergulhada e reflexões sobre como a tecnologia organiza (ou desorganiza) a vida. Entre um parágrafo e outro, você pode esbarrar em temas como IA na educação, política pública, o trabalho hoje e no futuro, divagações sobre o que é possível imaginar quando pensamos fora da caixa. este espaço é minha tentativa de documentar o que aprendo, o que questiono e o que acredito que ainda podemos construir. um ponto importante! penso falando, falo de muita coisa de forma desordenada. às vezes faz sentido, às vezes não. aqui você encontra uma tentativa de organizar esse caos. [+]

Tag: currículo

  • Currículo não é destino

    Um currículo pode prometer “ensino por competências” com toda a boa intenção do mundo, e ainda assim fracassar, não porque a escola ensinou errado, mas porque nada depois da escola sabe reconhecer competência quando a vê.

    Um estudo que comparou política de ensino de ciência da computação em 15 países mostra o mecanismo de governança mais poderoso: o efeito washback, conceito emprestado de teste de idiomas (Alderson & Wall, 1993). Provas de alto risco moldam a prática de sala de aula independentemente do que o currículo formal diz. Mas o mesmo estudo, sem perceber, também revela um problema mais profundo do que “a prova manda mais que o currículo”: nenhuma das instituições envolvidas, escola, vestibular, mercado de trabalho, tem hoje um jeito real de avaliar competência de forma íntegra. Todas recorrem a proxies estreitos: qual linguagem de programação foi ensinada, qual conteúdo foi decorado, qual credencial foi obtida.

    O efeito washback, rápido

    Na Polônia, o texto curricular seguiu formalmente “neutro” quanto à linguagem de programação durante toda a transição. Mas quando a prova nacional (Matura) redesenhou suas tarefas para focar em processamento de dados, o Python virou a escolha dominante, sem que uma linha do currículo formal tivesse mudado. O Japão fez o oposto de propósito: criou um pseudocódigo próprio (DNCL) só para avaliação, desacoplando deliberadamente o ensino (livre para usar Python) da prova (neutra quanto à linguagem), para neutralizar esse mesmo efeito.

    Por que “seguir o mercado” não é a resposta

    O mesmo estudo nota que Python é favorecido na trilha geral por sua “acessibilidade e alinhamento com fluxos de trabalho de IA e ciência de dados”, ou seja, porque o mercado sinaliza que isso é suficiente agora. C++ fica reservado à trilha de elite, justificado pela profundidade algorítmica que exige, o que é real: aprender C++ tem uma curva mais exigente que aprender Python. Mas há uma camada que o estudo nomeia sem explorar: quem pode se dar ao luxo de aprender uma linguagem que o mercado não está pedindo de imediato?

    A resposta tem nome na sociologia da educação: capital, no sentido de Pierre Bourdieu. Bourdieu distinguia capital econômico (dinheiro convertível de imediato) de capital cultural (competências, credenciais, disposições que só se convertem em vantagem material depois, às vezes bem depois). Quem já tem segurança econômica acumulada pode investir tempo numa competência que “o mercado não está pedindo agora”, porque não depende do retorno imediato desse investimento para sustentar a própria vida. Quem não tem essa segurança precisa perseguir o que já é convertível, o que o mercado já sinaliza como empregável, agora.

    É por isso que Python-pra-todos e C++-pra-elite não é só uma divisão de dificuldade técnica. É uma divisão de quem pode se dar ao luxo de aprender algo além do que o mercado pede hoje, e quem não pode. A elite, boa parte dela, não segue o mercado porque tem ou cria o mercado, e pode dedicar tempo a uma competência que talvez só valha a pena daqui a cinco ou dez anos. A maioria segue o que “o mercado diz que é suficiente” porque não tem essa margem, precisa que o aprendizado vire emprego o quanto antes.

    Isso é o motivo pelo qual “alinhar educação ao mercado” é a resposta errada, mesmo sendo a mais intuitiva. O mercado muda rápido demais para ser bússola estável, e segui-lo cegamente na trilha geral (Python “porque é o que se usa agora”) reproduz a mesma divisão de classe que gerou o problema: quem tem capital acumulado se permite profundidade, quem não tem se contenta com suficiência.

    O problema real: ninguém sabe avaliar competência

    A pergunta que fica não é “como alinhar currículo, prova e mercado de trabalho”. É: como cada uma dessas três instituições constrói um jeito de avaliar competência de forma íntegra, que não dependa de conteúdo decorado (o problema clássico da escola), de qual linguagem foi ensinada (o problema que o estudo documenta), ou de credencial genérica (o problema clássico do mercado de trabalho)? Essa pergunta é mais difícil, e mais importante, do que escolher entre Python e C++. Nenhuma das três instituições parece ter resposta pronta para ela.

    Conclusão

    Currículo que promete “competência” sem que exista, em algum lugar do sistema, um jeito real de reconhecer competência quando ela aparece, é promessa vazia. O problema não é falta de alinhamento entre escola, prova e mercado. É que nenhuma das três, sozinha, sabe fazer a coisa que todas dizem que fazem.

    Fonte: Dumitran, A.M.; Popescu, I.M. "Programming Language Policy as an AI Literacy Equity Problem: A 15-Nation Comparative Analysis" (2026); Alderson, J.C.; Wall, D. "Does washback exist?" Applied Linguistics, 1993; Bourdieu, P. "The Forms of Capital." In J. Richardson (Ed.), Handbook of Theory and Research for the Sociology of Education, 1986.

  • Antes do modelo, o dado: a inversão pedagógica no ensino de inteligência artificial

    Um incomodo meu como professora na área da Computação e agora mais recente, ensinando sobre Inteligência Artificial, o de que existe uma sequência que se tornou quase canônica nos cursos do mercado. Basicamente, inicia assim, apresenta-se o problema, carrega-se um dataset, treina-se um modelo, avalia-se a acurácia. O dado aparece sempre como insumo, algo que já está dado, como o próprio nome sugere e o modelo como o objeto de interesse intelectual. Essa inversão tem consequências pedagógicas e epistemológicas que raramente são discutidas e que vou tentar nomeá-las.

    A tese é: quem não aprende a origem de uma solução não consegue reconhecer problemas novos, aprende a executar e não a criar.

    Uma aula sobre MongoDB

    Recentemente, meus estudantes do curso técnico em inteligência artificial estavam aprendendo banco de dados. Seguimos uma sequência deliberada: primeiro modelagem conceitual, depois estrutura relacional em MySQL e só então banco de dados não relacional com MongoDB. Na metade de uma aula sobre MongoDB, a maioria da turma já estava operando com segurança. Mas é claro, e isso não tem nada a ver com o MongoDB ser intuitivo ou bonitinho. É que, uma vez compreendida a rigidez dos bancos relacionais, a flexibilidade do não relacional faz sentido imediato. Os estudantes estavam aprendendo uma nova sintaxe E entendendo por que ela existe.

    Esse “por que da exostência” é muita coisa.

    O MongoDB não surgiu porque alguém quis simplificar a vida dos desenvolvedores. Surgiu porque o modelo relacional, criado para um mundo de dados estruturados e previsíveis, começou a encontrar seus limites diante de volumes massivos, dados heterogêneos e necessidade de escala horizontal. O NoSQL é uma resposta a um problema histórico (um problema sobretudo humano num contexto histórico específico). Quem aprende MongoDB sem ter aprendido SQL não sabe o que o MongoDB resolve e por isso não sabe quando ele é a resposta errada, nem consegue imaginar o que seria necessário quando nenhum dos dois for suficiente.

    Agora, inverta essa sequência, ensine NoSQL primeiro porque “é o mais usado em projetos de IA” e quando esse profissional precisar resolver problemas no futuro onde a solução adequada é um banco relacional você vai ver como será um caminho tortuoso.

    O mesmo problema, em escala maior

    A mesma coisa acontece com toda a área de Inteligência Artificial, uma arquitetura transformer não surgiu do nada. Surgiu das limitações das redes recorrentes para lidar com dependências de longo prazo em sequências. O mecanismo de atenção foi proposto como solução a um problema específico e documentado. O GPT é uma resposta a perguntas que pesquisadores levavam anos tentando responder. Quem aprende a usar modelos pré-treinados sem nenhuma noção de estrutura de dados, sem entender o que é um atributo, o que é uma relação, o que significa representar o mundo em formato tabular ou vetorial é um profissional que opera uma solução sem ter a menor ideia do problema que ela resolve. Uma incapacidade de perceber quando a ferramenta disponível é inadequada para o problema em mãos, e a incapacidade ainda maior de contribuir com o que ainda precisa ser construído.

    Um currículo que pula a fundação para chegar logo aos resultados impressionantes forma, sistematicamente, trabalhadores que sabem criar agentes de IA com ferramentas prontas, mas não conseguem treinar um modelo do zero, questionar a estrutura de um dataset, ou projetar arquiteturas para problemas que ainda não têm solução no mercado. A sequência de aprendizagem define o horizonte do que o profissional consegue imaginar fazer (no presente e no futuro). Se torna um profissional deslumbrado (ou maravilhado) pelas por todas as soluções tecnológicas que vê, entretanto, mesmo formado na área não é capaz de construir suas próprias soluções para problemas semelhantes ou nos quais quer resolver.

    Estrutura como teoria do mundo

    Aprender estrutura de dados não é aprender a programar melhor. É aprender que toda organização de informação implica uma teoria sobre o que existe, o que importa e o que pode ser comparado.

    Quando se define que um campo é do tipo VARCHAR(255), está-se tomando uma decisão sobre o que pode ser dito naquele espaço. Quando se normaliza uma tabela, está-se afirmando algo sobre quais relações são independentes entre si. Quando se escolhe uma chave primária, está-se definindo o que individualize uma entidade no mundo modelado.

    A própria noção de entidade, atributos, relacionamentos pressupõe escolhas de abstração escolhidas por pessoas (sejam as que programa, sejam as que administram o negócio).

    Essas decisões nunca são neutras. O banco de dados de uma clínica que armazena gênero como campo binário não é apenas um banco de dados tecnicamente limitado é um banco de dados que produz invisibilidade de diferentes pessoas. O sistema de avaliação escolar que registra apenas notas numéricas não capta o que não foi previsto como mensurável. A estrutura do dado é sempre uma ontologia operacional e ontologias têm política.

    Álvaro Vieira Pinto (2005), aponta que a alienação tecnológica começa quando o ser humano deixa de reconhecer nos artefatos o produto de suas próprias escolhas históricas. Ensinar estrutura de dados é, nesse sentido, um ato de desfetichização, mostrar que antes do modelo há uma tabela, antes da tabela há um modelo conceitual, antes do modelo conceitual há uma decisão sobre o que conta como real.

    Uma questão curricular com consequências

    O debate sobre o que ensinar primeiro em IA é uma questão sobre que tipo de profissional o mercado e a sociedade vão ter disponível para lidar com sistemas que já organizam crédito, saúde, educação e segurança pública. Ainda há um problema adicional no qual eu gosto de trazer com frequência e que agrava esse quadro: o sequestro da metodologia de projetos.

    A aprendizagem baseada em projetos (Project-Based Learning) tem estrutura definida. Parte de um problema autêntico, exige investigação, envolve colaboração e, sobretudo, requer reflexão contínua sobre o processo. O que uma parcela significativa dos cursos de tecnologia chama de “aprendizagem por projetos” é outra coisa. Entregar um projeto não é trabalhar com PBL. Uma pessoa pode construir um chatbot funcional sem ter passado por nenhuma das etapas que a metodologia pressupõe, sem ter formulado o problema, sem ter investigado alternativas, sem ter refletido sobre o que aprendeu no percurso.

    Essa confusão é bastante propícia nos currículos, ela busca nas teorias educacionais uma maneira de justificar a precarização da formação tecnológica, segue a mesma lógica que atravessa todo este ensaio: tomar o resultado como prova do processo. Assim como ensinar a usar um modelo pré-treinado é tratado como equivalente a ensinar inteligência artificial, entregar um projeto é tratado como equivalente a aprender por projetos. Em ambos os casos, estamos ocultando o percurso (as dores e as delícias do processo de aprender) e é no percurso que está a aprendizagem real.

    Thomas e Mergendoller (2000), ao sistematizar os elementos centrais do PBL fazem a distinção entre um projeto educativo de uma tarefa complexa apontando que é a centralidade da investigação sustentada e da reflexão sobre o processo. Sem isso, o projeto é apenas uma embalagem. E embalagens bonitas criam a aparência de profundidade onde existe apenas superfície.

    A diferença entre quem opera modelos prontos e quem entende a estrutura que os sustenta não é (somente) uma questão de soft skill versus hard skill. É uma questão de posição epistêmica, afinal, quem tem condições de questionar o que foi construído e de construir o que ainda não existe? Currículos que ensinam IA de trás para frente (do resultado para o fundamento, da ferramenta para o problema, do produto para o processo) são pedagogicamente preguiçosos e fazem uma escolha sobre quem vai ter autoridade técnica e intelectual sobre esses sistemas no futuro.