você não é especialista em IA (e tudo bem)

Every week a new artificial intelligence expert shows up. There's a talk with "AI" in the title, a three-hour prompt engineering course, an influencer selling "AI for business" mentorships, a consultant who was in project management yesterday and is an "AI Strategist" today, a designer who now introduces themselves as an AI engineer, someone who only worked with Excel and is now a "Data Engineer," and the product owner who magically became a developer once coding agents went mainstream. Since 2023, it seems anyone who uses ChatGPT often has been handed authority on the subject.

They haven't earned it. I work with software and study AI on my own in an AI Engineering track. I can build some things, explain others, and have plenty left to learn, which is why I don't call myself an expert.

Changing careers and learning with new tools are legitimate. What bothers me is when the bio changes before the competence does, and that bio starts selling courses, guiding hiring, or deciding where a company will spend its money. I want to know what this person is an expert in and how I can check.

AI is much bigger than the chatbot

The name already appeared in the Dartmouth proposal, written in 1955 for a meeting in 1956. Search, planning, logic, machine learning, computer vision, language, and robotics are all part of the field. Much of it existed before a chat box became its best-known entry point.

Large language models, or LLMs, are one family of models within that history. Someone can know a great deal about putting these models into production and know little about robot control. Someone else can research computer vision without ever having built a coding agent. Both can have a real specialty.

When someone introduces themselves as an "AI expert," I look for that scope in their résumé or in a conversation about their work. It doesn't need to fit in full on a name badge, but I need to understand what the person knows. The broader the promise, the more work it takes to support it.

I'll tell that history in a separate post, in the same format as the cryptography one, starting with the people and ideas before getting to the acronyms. For now, I want to know what you can do with that knowledge and how far it supports what you claim.

using, integrating, and researching require different skills

Using tools, integrating models, and doing research are overlapping kinds of work. You can develop depth in one without going through all the others; the researcher doesn't automatically outrank the user at every task.

using a tool well

You can provide context, break down a task, review the output, and recognize when you need to check a source. A teacher may know how to use AI to prepare an activity and spot teaching mistakes that a model researcher would miss. A designer may have a much better workflow than the person who implemented the API.

Someone who masters that use has something to teach. If you've developed a good text revision process, you can teach a class on it. Offering advice on the safety of any AI system requires other knowledge, which hours of tool use don't automatically provide.

integrating models into systems

You connect the model to documents, tools, and services. RAG is one example: the system retrieves passages from a collection and supplies them as context for the answer. An agent adds the ability to take actions, within whatever the system allows.

The demo may fit in a few lines. The work grows when outdated documents, permissions, private data, delays, costs, and wrong answers enter the picture. Who can access which document? What happens if a search doesn't find the answer? Can the agent send a message without review? How do you undo an action?

Someone can spend years learning to evaluate and operate these systems without training a foundation model. Calling that specialty "just using an API" leaves out the work on evaluation, permissions, and production failures.

developing models and doing research

Choosing data, training or adapting a model, and investigating a hypothesis require other tools. Probability, statistics, linear algebra, and optimization help you understand what's being measured and what training is doing.

Running a training tutorial doesn't hand you the title either. You need to understand the choices, compare alternatives, and investigate why the result changed. Research also involves asking a question worth the experiment; not all training is research, and not all research requires training a new model.

The same person can work in all three areas, and I'd want to find out how much they know about the work they claim to master. Research experience alone doesn't teach you to operate a production system. Years of integration don't guarantee knowledge of training either.

the world moves on, and others are keeping up too

You're not the only person who discovered ChatGPT. You're not the only one using Claude Code, Antigravity, or AI agents. The person across the meeting table may also follow these tools, test the same models, and recognize the path you took to produce that deliverable. The world didn't stand still while you updated your bio.

Your client, interviewer, or the colleague who will maintain the system afterward may know how to do the same things, or do them better. If you present an automation as a secret nobody else can access, you're betting that nobody there knows what questions to ask. I'd be more interested in understanding your decisions than competing over who knows more tools.

An agent can help you build something you couldn't have built before. That opens up real possibilities. Judging whether that first version is useful still takes knowledge, and whoever takes responsibility for the delivery needs to check the result and explain their choices. If an unexpected question or a production failure comes up, you're the one who will have to answer for it.

Imagine delivering a dashboard built with an agent's help. You may have understood the business rules, processed the data, chosen useful metrics, and checked the numbers. That work still has value even if the client uses the same tool, because they're paying for the problem solved and the responsibility you take on. Now imagine the total is wrong and you can't explain why. If you sold that dashboard as proof of expertise in data engineering, you'll struggle to back up the promise.

People's circumstances vary too. Some lack access to the same tools or time to study them, some companies have no technical team, and some people are just starting. Teaching and implementing well can be legitimate services, even with publicly available tools. Sellers need to explain what they're offering. If the client knows little about the subject, that obligation is greater. Using their unfamiliarity to invent proprietary technology, hide limitations, or sell an ordinary result as an extraordinary guarantee is deceiving the client.

Knowing someone uses AI, on the other hand, doesn't make the work easy or free, or prove a lack of competence. An experienced professional can get a better result with the same agent because they choose the problem better, supply relevant context, and notice errors a beginner would miss. Just knowing the tool doesn't reliably tell you how someone else produced something either.

You don't need to narrate every autocomplete suggestion to be transparent. You need to be honest about authorship, ability, methods, and conditions that affect the client's decision. If the project prohibits sending data to an external service, you have to respect that restriction when using your tools. Connecting an API and saying you trained your own model is lying about the work you did. You can acknowledge using an agent and stand behind the quality of the delivery; hiding what you actually did compromises trust.

Learning early can open opportunities, but an advantage based only on knowing the app of the moment needs rebuilding as tools change and more people learn to use them. To keep offering good work, you'll need to understand the domain, learn to evaluate, and justify your decisions. Over time, you'll have deliveries other people can examine and use. Others following this change can also ask about that history and notice when it's missing.

Knowing how to use AI to be more productive matters too. You can save time and do work you couldn't do before. But some people use that ability to generate generic content in a pile of Markdown files, adding instructions they can't justify and presenting the volume as a major technical achievement.

If you need that pile to guide the agent but can't explain which instructions are necessary, when they apply, or whether they're helping, then you don't understand at least part of what you're doing. You keep accumulating rules, repetitions, and contradictions that can clutter the context and make the work you meant to simplify harder. Documenting a decision or a concrete constraint helps; asking the model for another generic manual for a task you don't yet understand doesn't resolve that lack of knowledge.

I want to know what this helped deliver. Did it solve a business problem? Help someone or make an open source maintainer's work easier? A small, verifiable improvement already counts. Filling a repository with text and announcing you've now "stopped being an open source parasite" doesn't demonstrate that value. Using free software doesn't make anyone a parasite, and publishing files doesn't remove the need to explain who benefits from them and how. The same scrutiny applies to the result the agent produces.

the demo worked. what does that prove?

Imagine a consultancy selling an assistant that answers questions about a company's internal policies. During the presentation, someone asks about vacation. The assistant retrieves a document, answers confidently, and shows a link. Everyone likes it.

What happens if the policy is outdated? If the question is ambiguous or the document is restricted to other employees? The example presented doesn't answer those questions yet.

I'd ask a few questions before buying the promise:

Which questions represent real use? Are there questions the documents can't answer, or only examples chosen to work?
Is the answer correct, and does the source actually support what it says? Showing a link isn't enough.
Who evaluated the errors? Did the system expose restricted information, invent a rule, or just phrase something awkwardly? Those errors have different consequences.
Compared to what? Would ordinary search, an FAQ page, or the current process already solve part of the problem?
What's the cost per resolved task, including review and correction? How long does it take? Who handles failures?

There's no universal number that answers all of this. "It's 95% accurate" needs to come with which cases were counted, what counted as correct, and how the other 5% failed. A punctuation mistake and an information leak can't disappear into the same average without an explanation.

You also need to separate the examples used to improve the system from those reserved for evaluating it. If I adjust the prompt until it answers every question on my list correctly and then use that same list as proof, I'm measuring a result I already used to guide the adjustments. The separation of training, validation, and test sets teaches this care in machine learning; it also matters when I'm adjusting a system around a ready-made model.

In a technical conversation, I'd ask how the person knew it improved and where the system still fails. I want to be able to examine that result, whatever framework they used.

what to look for in someone selling knowledge

I'd start with the scope and look for evidence that matches it. That might be a paper, code, a technical write-up, a lesson in which the person can handle questions, or a careful description of a system they operated. Confidential work exists; having no public repository doesn't disqualify anyone.

Even without exposing the client, it's often possible to discuss the problem, the decisions, the limits of your own involvement, and what you learned. If everything stays at "transformation," "revolution," and "exponential productivity," I still don't know what the person did.

I also pay attention to how they respond when the conversation goes off script. Do they distinguish what they observed from what they're assuming? Can they explain a choice without reciting acronyms? Do they revise a claim when faced with contrary evidence? Do they say when a problem falls outside their area?

Saying "the model thinks" can be shorthand in a conversation, without proving ignorance. The promise that "it understands your company, so you can trust it" uses the metaphor to justify trust. I'd ask what was tested and which limitations that sentence left out.

You can get this judgment wrong. Competent people can communicate badly, and unprepared people learn to say "it depends" at the right moment. That's why I'd go back to the person's work and what I can verify about it.

the title has consequences

A video about tools or a lesson on organizing your studies with a chatbot can help a lot of people. Someone with something useful to share doesn't need to wait until they've published a scientific paper.

The responsibility grows with the scope of the recommendation. Showing how you prepare a draft is one thing. Selling the promise that a company can dispense with human review, migrate data, or replace a team requires evidence and experience that match that decision.

A degree, professional experience, and independent study can contribute to that path. None of them gives you authority on everything that fits under "AI."

A product owner can learn to develop software, just as someone can move from design to engineering or from development to research. Changing your bio before learning the work is what bothers me. Someone changing careers will need to practice, make mistakes, and learn to answer for the work.

Not being an expert is the normal state of almost everyone on almost every subject. You can work, teach, and contribute while learning, as long as the description of what you offer is honest.

a project that teaches more than changing your bio

If you want to go deeper, choose a task small enough to finish and clear enough to evaluate, such as routing support messages to the right queue. Use public data or synthetic examples; learning doesn't require starting by exposing customer data.

Before choosing a model, define the categories and what to do with an ambiguous message. Set aside examples for developing the solution and others for a final evaluation. Compare it with something simple: keyword rules, a small classifier, or the manual process. The problem might not even need an LLM.

Then examine the errors. Does the system confuse two categories? Does it struggle with short messages? Does it confidently route a message that should be sent for review? If the most frequent class dominates the list, getting many cases right can hide the fact that the others are almost never recognized. A table showing correct predictions and confusions by category can teach more than an overall percentage.

Change one thing at a time and record the result. If you're using a ready-made model, investigate instructions, context, cost, and stability. If you want to understand training, logistic regression or a small network already offers plenty of work: data representation, the loss function, optimization, and generalization. Watching the loss fall is the beginning; seeing how the model performs on examples that didn't guide the adjustments is another part of learning.

Study the mathematics and read the work those questions require. When you encounter an equation you don't understand, try to connect it to the experiment. When reading a paper, look for the question, the comparison, and the conditions under which the result was obtained. Copying the conclusion without those conditions is a way to study while still selling too much certainty.

At the end, write down what you did, what you compared it with, where it improved, and where it failed. That already makes for a much more useful conversation than "I'm passionate about artificial intelligence." Repeat with problems in the same area until you can recognize patterns, anticipate difficulties, and explain decisions from accumulated experience.

I'm trying to learn that way, recording what I built and measured, including what didn't work and the questions left over. For now, that's what I can offer anyone who wants to evaluate my work.

before anyone takes this personally

This isn't an attack on anyone in particular. I don't have a list of names hidden in the draft, and I'm not demanding that everyone know everything. I'm learning and using these tools too. Now, if you read this far and felt personally offended because someone asked for evidence of the expertise you advertise, that's your problem. Maybe you're more concerned with looking like an expert than backing up the title.

It reminds me of the lamers and script kiddies from five-plus years ago who ran someone else's script and wanted to pass themselves off as hackers. Today's version asks an agent to build an application and starts selling expertise in architecture, security, and AI engineering without being able to explain what was done. Using other people's code has always been part of programming, just as using agents can be part of learning and working. The act starts when you borrow the result and make up the expertise to go with it.

If you're starting out, asking questions, and trying to understand what the tool did, keep going. I want more people to be able to build things. Just have the decency to say what you can do and admit when you need to learn. You can open the editor, study, and drop the act.

Toda semana aparece um novo especialista em inteligência artificial. Tem palestra com "IA" no título, curso de engenharia de prompt em três horas, influenciador vendendo mentoria de "IA para negócios", consultor que ontem era de gestão de projetos e hoje é "AI Strategist", designer que agora se apresenta como engenheiro de IA, alguém que só mexia com Excel e agora é "Data Engineer" e o PO que virou desenvolvedor por mágica depois que os agentes de coding se popularizaram. Desde 2023, parece que quem usa o ChatGPT com frequência ganhou autoridade no assunto.

Não ganhou. Eu trabalho com software e estudo IA por conta própria numa trilha de AI Engineering. Consigo construir algumas coisas, explicar outras e tenho um bocado que aprender, por isso não me chamo de especialista.

Mudar de área e aprender com ferramentas novas é legítimo. Me incomoda quando a mudança na biografia chega antes da competência, e essa biografia passa a vender curso, orientar contratação ou decidir onde uma empresa vai colocar dinheiro. Quero saber em que essa pessoa é especialista e como eu posso verificar.

IA é muito maior do que o chatbot

O nome já aparecia na proposta de Dartmouth, escrita em 1955 para um encontro em 1956. Busca, planejamento, lógica, aprendizado de máquina, visão computacional, linguagem e robótica fazem parte desse campo. Muito disso existia antes de uma caixa de conversa virar a porta de entrada mais conhecida.

Os grandes modelos de linguagem, ou LLMs, são uma família de modelos dentro dessa história. Uma pessoa pode conhecer muito sobre colocar esses modelos em produção e saber pouco sobre controle de robôs. Outra pode pesquisar visão computacional e nunca ter montado um agente de programação. As duas podem ter uma especialidade real.

Quando alguém se apresenta como "especialista em IA", procuro esse recorte no currículo ou na conversa sobre o trabalho. Não precisa caber inteiro no crachá, mas preciso conseguir entender o que a pessoa conhece. Quanto mais ampla a promessa, mais trabalho dá sustentá-la.

Vou contar essa história num post próprio, no mesmo formato do de criptografia, começando pelas pessoas e pelas ideias antes de chegar às siglas. Por enquanto, quero saber o que você consegue fazer com esse conhecimento e até onde ele sustenta o que você afirma.

usar, integrar e pesquisar exigem competências diferentes

Usar ferramentas, integrar modelos e fazer pesquisa são trabalhos que se cruzam. Dá pra ter profundidade em um deles sem percorrer todos os outros; o pesquisador não está automaticamente acima do usuário em qualquer tarefa.

usar bem uma ferramenta

Você consegue dar contexto, decompor uma tarefa, revisar a saída e perceber quando precisa conferir uma fonte. Um professor pode saber usar IA pra preparar uma atividade e reconhecer erros pedagógicos que um pesquisador de modelos deixaria passar. Um designer pode ter um processo de trabalho muito melhor do que o de quem implementou a API.

Quem domina esse uso tem o que ensinar. Se você desenvolveu um bom processo de revisão de texto, pode dar uma aula sobre ele. Oferecer consultoria sobre a segurança de qualquer sistema de IA exige outros conhecimentos, que as horas de uso da ferramenta não entregam automaticamente.

integrar modelos a sistemas

Você liga o modelo a documentos, ferramentas e serviços. RAG é um exemplo: o sistema busca trechos de uma base e os entrega como contexto para a resposta. Um agente acrescenta a possibilidade de executar ações, dentro do que o sistema permitir.

A demonstração pode caber em poucas linhas. O trabalho cresce quando entram documentos desatualizados, permissões, dados privados, demora, custo e respostas erradas. Quem pode acessar qual documento? O que acontece se uma busca não encontrar a resposta? O agente pode enviar uma mensagem sem revisão? Como desfazer uma ação?

Uma pessoa pode passar anos aprendendo a avaliar e operar esses sistemas sem treinar um modelo de base. Chamar essa especialidade de "só usar API" deixa de fora o trabalho com avaliação, permissões e falhas em produção.

desenvolver modelos e fazer pesquisa

Escolher dados, treinar ou ajustar um modelo e investigar uma hipótese exige outras ferramentas. Probabilidade, estatística, álgebra linear e otimização ajudam a entender o que está sendo medido e o que o treinamento está fazendo.

Rodar um tutorial de treinamento também não entrega o título. É preciso entender as escolhas, comparar alternativas e investigar por que o resultado mudou. Pesquisa ainda inclui formular uma pergunta que valha o experimento; nem todo treinamento é pesquisa, e nem toda pesquisa exige treinar um modelo novo.

A mesma pessoa pode atuar nas três frentes, e eu procuraria saber quanto ela conhece do trabalho que diz dominar. Experiência de pesquisa, por si só, não ensina a operar um sistema em produção. Anos de integração também não garantem conhecimento sobre treinamento.

o mundo anda, e outras pessoas também acompanham

Você não é o único que descobriu o ChatGPT. Não é só você que usa Claude Code, Antigravity ou agentes de IA. Quem está do outro lado da reunião também pode acompanhar essas ferramentas, testar os mesmos modelos e reconhecer o caminho que você usou para chegar naquela entrega. O mundo não ficou parado enquanto você atualizava a bio.

Seu cliente, quem te entrevista ou o colega que vai manter o sistema depois pode saber fazer as mesmas coisas, ou fazer melhor. Se você apresenta uma automação como um segredo inacessível aos demais, está apostando que ninguém ali sabe fazer perguntas. Eu teria mais interesse em entender suas decisões do que em disputar quem conhece mais ferramentas.

Um agente pode ajudar você a construir algo que antes não conseguiria. Isso abre possibilidades de verdade. Avaliar se aquela primeira versão serve ainda exige conhecimento, e quem assume a entrega precisa verificar o resultado e explicar suas escolhas. Se aparecer uma pergunta fora do roteiro ou um erro em produção, é você que vai ter de responder.

Imagine entregar um painel feito com ajuda de um agente. Você pode ter entendido as regras do negócio, tratado os dados, escolhido indicadores úteis e verificado os números. Esse trabalho continua valendo mesmo que o cliente use a mesma ferramenta, porque ele está pagando pelo problema resolvido e pela responsabilidade que você assume. Agora imagine que o total está errado e você não sabe explicar por quê. Se vendeu aquele painel como prova de que domina engenharia de dados, vai ter dificuldade para sustentar a promessa.

As condições também variam. Há gente sem acesso às mesmas ferramentas ou sem tempo para estudá-las, empresas sem equipe técnica e pessoas começando agora. Ensinar e implementar bem pode ser um serviço legítimo, mesmo com ferramentas disponíveis ao público. Quem vende precisa explicar o que está oferecendo. Se o cliente conhece pouco do assunto, a obrigação de explicar é maior. Usar essa falta de familiaridade para inventar uma tecnologia própria, esconder limitações ou vender um resultado comum como garantia extraordinária é enganar o cliente.

Saber que alguém usa IA, por outro lado, não torna o trabalho fácil ou gratuito, nem prova falta de competência. Um profissional experiente pode obter um resultado melhor com o mesmo agente porque escolhe melhor o problema, fornece contexto relevante e percebe erros que um iniciante deixaria passar. Só conhecer a ferramenta também não permite descobrir com segurança como outra pessoa produziu alguma coisa.

Você não precisa narrar cada sugestão de autocomplete para ser transparente. Precisa ser honesto sobre autoria, capacidade, método e condições que afetam a decisão do cliente. Se o projeto proíbe enviar dados a um serviço externo, você tem de respeitar essa restrição ao usar as ferramentas. Conectar uma API e dizer que treinou um modelo próprio é mentir sobre o trabalho feito. Dá pra assumir o uso de um agente e sustentar a qualidade da entrega; esconder o que você realmente fez compromete a confiança.

Aprender cedo pode abrir oportunidades, mas uma vantagem baseada só em conhecer o aplicativo da vez precisa ser refeita conforme as ferramentas mudam e mais gente aprende a usá-las. Para continuar oferecendo um bom trabalho, você vai precisar conhecer o domínio, aprender a avaliar e justificar suas decisões. Com o tempo, terá entregas que outras pessoas podem examinar e usar. Quem acompanha essa mudança também consegue perguntar por esse histórico e perceber quando ele está faltando.

Saber usar IA para ganhar produtividade também é importante. Você pode economizar tempo e conseguir fazer um trabalho que antes não conseguia. Mas tem gente usando essa capacidade para gerar conteúdo genérico num amontoado de arquivos Markdown, acrescentando instruções que não sabe justificar e apresentando o volume como se fosse uma grande realização técnica.

Se você precisa desse amontoado para orientar o agente, mas não consegue explicar quais instruções são necessárias, quando se aplicam ou se estão ajudando, então pelo menos parte do que está fazendo você não entende. Vai acumulando regras, repetições e contradições que podem poluir o contexto e dificultar o trabalho que pretendia facilitar. Documentar uma decisão ou uma restrição concreta ajuda; pedir ao modelo mais um manual genérico para uma tarefa que você ainda não compreendeu não resolve essa falta de conhecimento.

Eu quero saber o que isso permitiu entregar. Resolveu um problema do negócio? Ajudou alguém ou facilitou o trabalho de quem mantém um projeto de código livre? Uma melhoria pequena e verificável já conta. Encher um repositório de texto e anunciar que agora "deixou de ser um parasita do open source" não demonstra esse valor. Usar software livre não torna ninguém um parasita, e publicar arquivos não dispensa explicar quem se beneficia deles e como. A mesma cobrança vale para o resultado produzido pelo agente.

a demo funcionou. o que isso prova?

Imagine uma consultoria que vende um assistente para responder perguntas sobre as políticas internas de uma empresa. Na apresentação, alguém pergunta sobre férias. O assistente busca um documento, responde com segurança e mostra um link. Todo mundo gosta.

O que acontece se a política estiver desatualizada? Se a pergunta for ambígua ou o documento for restrito a outros funcionários? O exemplo apresentado ainda não responde a essas perguntas.

Eu faria algumas perguntas antes de comprar a promessa:

Quais perguntas representam o uso real? Há perguntas sem resposta nos documentos, ou só exemplos escolhidos para funcionar?
A resposta está correta e a fonte realmente sustenta o que foi dito? Mostrar um link não basta.
Quem avaliou os erros? O sistema expôs informação restrita, inventou uma regra ou apenas escreveu de um jeito estranho? Esses erros têm consequências diferentes.
Comparado com o quê? Uma busca comum, uma página de perguntas frequentes ou o processo atual já resolveria parte do problema?
Quanto custa por tarefa resolvida, contando revisão e correção? Quanto demora? Quem atende quando falha?

Não existe um número universal que responda tudo isso. "Acerta 95%" precisa vir acompanhado de quais casos entraram na conta, o que foi considerado acerto e como os outros 5% falharam. Um erro de pontuação e um vazamento de informação não podem desaparecer na mesma média sem explicação.

Também é preciso separar os exemplos usados para melhorar o sistema daqueles reservados para avaliá-lo. Se eu ajusto o prompt até acertar todas as perguntas da minha lista e depois uso a mesma lista como prova, estou medindo um resultado que eu já usei para orientar os ajustes. A separação entre treino, validação e teste ensina esse cuidado em aprendizado de máquina; ele também importa quando estou ajustando um sistema em volta de um modelo pronto.

Numa conversa técnica, eu perguntaria como a pessoa soube que melhorou e onde o sistema ainda falha. Quero conseguir examinar esse resultado, seja qual for o framework usado.

o que procurar em quem vende conhecimento

Eu começaria pelo recorte e procuraria evidência compatível com ele. Pode ser um artigo, código, um relato técnico, uma aula em que a pessoa sustenta as perguntas ou uma descrição cuidadosa de um sistema que operou. Trabalho sob confidencialidade existe; não ter um repositório público não desqualifica ninguém.

Mesmo sem expor o cliente, costuma ser possível conversar sobre o problema, as decisões, os limites da própria participação e o que foi aprendido. Se tudo fica em "transformação", "revolução" e "produtividade exponencial", eu continuo sem saber o que a pessoa fez.

Também presto atenção em como ela responde quando a conversa sai do roteiro. Ela distingue o que observou do que está supondo? Consegue explicar uma escolha sem recitar siglas? Revê uma afirmação diante de evidência contrária? Diz que aquele problema está fora da sua área?

Falar "o modelo pensa" pode ser uma abreviação numa conversa, sem provar desconhecimento. Já a promessa de que "ele entende sua empresa, então você pode confiar" usa a metáfora para justificar confiança. Eu perguntaria o que foi testado e quais limites aquela frase deixou de fora.

Dá pra errar esse julgamento. Gente competente também se comunica mal, e gente despreparada aprende a dizer "depende" na hora certa. Por isso eu voltaria ao trabalho da pessoa e ao que consigo verificar dele.

o título tem consequência

Um vídeo sobre ferramentas ou uma aula sobre como organizar estudos com um chatbot pode ajudar muita gente. Quem tem algo útil para compartilhar não precisa esperar publicar um artigo científico.

A responsabilidade aumenta com o alcance da recomendação. Mostrar como você prepara um rascunho é uma coisa. Vender a promessa de que uma empresa pode dispensar revisão humana, migrar dados ou substituir uma equipe exige evidências e experiência à altura dessa decisão.

O diploma, a experiência profissional e o estudo independente podem contribuir para essa trajetória. Nenhum deles dá autoridade sobre tudo que cabe debaixo de "IA".

O PO pode aprender a desenvolver, assim como alguém pode sair do design para a engenharia ou do desenvolvimento para a pesquisa. Trocar o título na biografia antes de aprender o trabalho é que me incomoda. Quem muda de profissão vai precisar praticar, errar e aprender a responder pelo trabalho.

Não ser especialista é o estado normal de quase todo mundo em quase todo assunto. Dá pra trabalhar, ensinar e contribuir enquanto se aprende, desde que a descrição do que você oferece seja honesta.

um projeto que ensina mais do que trocar a bio

Se você quer aprofundar, escolha uma tarefa pequena o suficiente para terminar e clara o suficiente para avaliar, como encaminhar mensagens de suporte para a fila certa. Use dados públicos ou exemplos sintéticos; aprender não exige começar expondo dados de clientes.

Antes de escolher o modelo, defina as categorias e o que fazer com uma mensagem ambígua. Separe exemplos para desenvolver a solução e outros para uma avaliação final. Compare com algo simples: regras por palavras-chave, um classificador pequeno ou o processo manual. Talvez o problema nem precise de um LLM.

Depois examine os erros. O sistema confunde duas categorias? Vai mal em mensagens curtas? Encaminha com confiança uma mensagem que deveria pedir revisão? Se a classe mais frequente domina a lista, acertar muitos casos pode esconder que as outras quase nunca são reconhecidas. Uma tabela mostrando os acertos e as confusões por categoria pode ensinar mais do que uma porcentagem geral.

Mude uma coisa por vez e registre o resultado. Se estiver usando um modelo pronto, investigue instruções, contexto, custo e estabilidade. Se quiser entender treinamento, uma regressão logística ou uma rede pequena já oferece bastante trabalho: representação dos dados, função de perda, otimização e generalização. Ver a perda cair é o começo; ver como o modelo se sai em exemplos que não orientaram os ajustes é outra parte do aprendizado.

Estude a matemática e leia os trabalhos que essas perguntas exigirem. Ao encontrar uma equação que você não entende, tente ligá-la ao experimento. Ao ler um artigo, procure a pergunta, a comparação e as condições em que o resultado foi obtido. Copiar a conclusão sem essas condições é um jeito de estudar e continuar vendendo certeza demais.

No fim, escreva o que você fez, contra o que comparou, onde melhorou e onde falhou. Isso já dá uma conversa muito mais útil do que "sou apaixonado por inteligência artificial". Repita em problemas do mesmo recorte até conseguir reconhecer padrões, antecipar dificuldades e explicar decisões com experiência acumulada.

Eu estou tentando aprender desse jeito, registrando o que construí e medi, inclusive o que não funcionou e as dúvidas que sobraram. Por enquanto, é isso que consigo oferecer a quem quiser avaliar meu trabalho.

e antes que alguém vista a carapuça

Isso não é um ataque a ninguém em particular. Não tenho uma lista de nomes escondida no rascunho nem estou cobrando que todo mundo saiba tudo. Eu também estou aprendendo e usando essas ferramentas. Agora, se você leu até aqui e se sentiu pessoalmente ofendido porque alguém pediu evidência da competência que você anuncia, aí o problema é seu. Talvez você esteja mais preocupado em parecer especialista do que em sustentar o título.

Me lembra os lammers e script kiddies de cinco e tantos anos atrás, que rodavam um script dos outros e já queriam posar de hacker. A versão atual pede para um agente montar uma aplicação e sai vendendo domínio de arquitetura, segurança e engenharia de IA sem conseguir explicar o que foi feito. Usar código dos outros sempre fez parte de programar, assim como usar agentes pode fazer parte de aprender e trabalhar. O personagem aparece quando você pega o resultado emprestado e inventa a própria competência junto.

Se você está começando, perguntando e tentando entender o que a ferramenta fez, segue o jogo. Eu quero ver mais gente conseguindo construir coisas. Só tenha a decência de dizer o que sabe fazer e de admitir quando precisa aprender. Dá pra abrir o editor, estudar e deixar o personagem de lado.

acompanhe os próximos textos

continue a leitura

a inteligência artificial não começou no ChatGPT