DEV Community: Matt Senter

The Post-IDE Era

Matt Senter — Mon, 14 Sep 2026 17:28:19 +0000

I just canceled my annual JetBrains subscription.

That would have been almost unthinkable for me a few years ago. IntelliJ and the rest of the JetBrains suite were exactly the kind of software I was happy to pay for: powerful, polished developer tools packed with features that made writing, navigating, refactoring, and debugging large codebases dramatically easier. For a long time, the IDE was where software development happened for me.

The problem is that I barely open one anymore.

It isn't because I stopped building software. If anything, I'm probably building more software than I ever have. The difference is that I increasingly don't interact with the codebase through an IDE at all. I work through Orgabot and other agent harnesses, where I describe what I want and let agents examine the repository, trace the relevant code, change files, run tests, fix failures, review the implementation, open pull requests, resolve conflicts, and keep going.

My primary programming interface has gradually shifted from a text editor full of source code to a conversation about intent. Natural language has become my coding language.

The IDE Was an Interface to Complexity

For decades, the IDE was the cockpit of software development. As codebases became larger and languages became more sophisticated, simple text editors were no longer enough. Developers needed symbol navigation, intelligent autocomplete, static analysis, refactoring tools, debugging, test runners, database explorers, version-control integration, dependency management, and dozens of other conveniences.

Products like IntelliJ became extraordinarily good at solving that problem, and when I was personally manipulating a codebase all day, those features were worth every penny. But from a higher level, an IDE is really a tool that helps a human understand and manipulate a large collection of source files.

Agentic development changes who is doing that manipulation.

The codebase is still there. The compiler is still there. Git, tests, linters, type systems, debuggers, package managers, and build systems haven't disappeared. What has changed is that I am increasingly not the one operating those tools directly. The agent is.

I Rarely Need to Look at the Code

That realization is what ultimately made me cancel JetBrains. I almost never open an IDE to "code" anymore. Sometimes I inspect a file because I'm curious about an implementation. Occasionally I make a tiny manual edit. I might look at a diff or trace something particularly strange.

But those situations are now exceptions rather than the primary workflow, and when all I need to do is inspect some text, a basic editor is perfectly adequate. I don't need several gigabytes of IDE and an annual software subscription for the handful of times I manually open a source file.

The overwhelming majority of the functionality I used to depend on inside IntelliJ still matters. I still want intelligent code navigation, refactoring, tests, static analysis, and code review. I just increasingly want the agent doing those things instead of me operating each tool myself.

The tools haven't disappeared. They've moved below the abstraction layer where I spend my time.

Natural Language Is Becoming a Programming Interface

Programming languages have always tried, to varying degrees, to make machines more understandable to humans. As we moved away from machine code and assembly, languages became progressively more semantic. We got variables with meaningful names, functions that read like actions, object-oriented structures that modeled real-world concepts, and declarative languages where we could increasingly describe what we wanted rather than every instruction required to accomplish it.

But they were still programming languages.

If you had told me 30 years ago that someday I would spend much of my day coding by speaking or typing plain English to a computer, I would have thought you were spewing science-fiction nonsense. Yet that's essentially what I do now.

Obviously English does not literally replace TypeScript, Python, Go, Java, or whatever language ultimately implements the system. My CPU isn't executing a paragraph I wrote to an agent. But that distinction is becoming less important from the human side of the stack.

Programming has always involved translating human intent into something a machine can execute, and over time we have repeatedly moved the human side of that translation upward in abstraction. Humans once manipulated machine instructions directly. Assembly gave those instructions names. Higher-level languages let us describe algorithms without caring about registers. Frameworks let us describe applications without implementing every primitive. Infrastructure-as-code let us describe entire environments rather than manually configuring servers.

Agents add another layer. Instead of expressing every implementation detail ourselves, we can increasingly express the desired outcome:

Add OAuth support for this provider.
Find why this API endpoint occasionally returns stale data and fix it.
Refactor these services so they share the same authorization layer.
Implement this GitHub epic and all of its sub-issues.
Review the resulting pull requests for security problems and merge them when they're ready.

Those are programming instructions. The output may ultimately be thousands of lines of conventional source code, but I didn't personally write most of those lines. I described the system I wanted, established constraints, evaluated the result, and let machines translate my intent into the languages they need.

Thirty years ago, the idea that plain English could sit at the top of a software-development stack sounded like science fiction. Now it's my normal workflow. Natural language isn't replacing programming languages underneath the system; it's becoming the programming language I use.

The Valuable Skill Was Never Really the Language

There is still enormous value in having experience with many programming languages. Knowing how different languages model types, concurrency, memory, state, interfaces, errors, and abstraction gives you a much better mental model for evaluating what an agent produces. That experience helps you recognize bad architecture, unnecessary complexity, brittle interfaces, and implementation choices that are likely to become problems later.

But I think the more important skill is experience building complex systems. Languages are ultimately a means to an end.

The hard parts of software development were never just remembering syntax or knowing which library call to make. The hard parts are deciding where boundaries belong, understanding how components should interact, anticipating failure modes, managing state, designing for change, making tradeoffs, debugging emergent behavior, and knowing when a seemingly reasonable implementation is going to collapse under real-world complexity.

Those skills survive the transition to agentic development, and they may become even more important. If an agent can produce competent TypeScript, Python, Go, Rust, or Java on demand, then fluency in a particular syntax becomes less scarce. What becomes more valuable is knowing what should be built, how it should fit together, what constraints matter, and whether the result is actually good.

That is also why I don't think the future belongs only to people who can prompt well. A clever prompt is not a substitute for engineering judgment. Someone with decades of experience building systems can look at an agent's plan and recognize that the boundaries are wrong, the data model will not scale, the security assumptions are weak, or the proposed architecture is solving the wrong problem entirely.

The agent can increasingly handle the translation from intent into implementation. The human still needs to understand the system.

That feels like the real shift to me: the programming language is moving farther down the stack, while architecture, judgment, orchestration, and systems thinking move farther up.

Cursor and Windsurf Don't Solve This Either

The obvious response is that maybe traditional IDEs are fading, but AI-native IDEs like Cursor and Windsurf are the future. I don't think so.

Cursor and Windsurf are still fundamentally IDEs. They assume that the center of software development is a human looking at source files, navigating a repository, selecting code, reviewing diffs, and interacting with AI from inside an editor. That already feels like an intermediate step.

If I am working through Orgabot or another agent harness, I don't need an AI-enhanced editor any more than I need a traditional one. I am not sitting there waiting for autocomplete, highlighting a function and asking AI to rewrite it, or manually hopping between files while an assistant watches over my shoulder.

I give the agent the job.

The agent can open the files, search the codebase, inspect dependencies, run commands, read test failures, modify twenty files, spin up sub-agents, review the resulting changes, and keep iterating until the task is complete. At that point, putting AI inside an IDE feels almost backwards.

The goal is not to make humans dramatically faster at editing code. The goal is to require humans to edit dramatically less code.

That distinction matters. Cursor and Windsurf may be better cockpits for AI-assisted programming, but the direction I'm moving in increasingly doesn't require a cockpit at all. The primary interface becomes the mission, issue, specification, or conversation. Source code is still critically important, but it becomes an artifact produced and manipulated underneath that interface rather than the place where I spend my day.

So when I canceled JetBrains, I didn't replace it with Cursor or Windsurf. I replaced the IDE with the agent.

I Don't Want to Be the Programmer Anymore

Orgabot pushed this one step further for me. When I use Orgabot to create an application or organization, I am not approaching the work as a software engineer with a better set of coding tools. I am approaching it from the CEO's perspective.

A CEO does not open a source file and fix a function. A CEO defines the objective, assigns responsibility, makes sure the right people or agents are working on it, reviews whether the result matches the goal, and changes the organization when the process breaks down.

The orchestration itself can also be delegated. A CEO might tell a CTO to deliver a product, and the CTO coordinates engineering, security, infrastructure, design, and review underneath that mandate. The CEO does not need to know which file contains the authentication middleware.

That is increasingly how I build software. I might say:

Build this product.
Fix this epic and all of its sub-issues.
Investigate why this system is failing and resolve the root cause.
Have security review the implementation before it ships.
Reduce the cost of this workflow without degrading quality.

Those instructions create work that eventually results in code, but code is several layers below the interface where I am operating.

That leads to a useful rule: if the CEO is reviewing or editing source code, there is probably a broken workflow somewhere underneath them.

Maybe the engineering agent failed. Maybe the review process is weak. Maybe the organization does not have the right role or skill. Maybe the escalation boundaries are wrong. Whatever the cause, the answer should not be to drag the CEO down into the implementation layer indefinitely. It should be to fix the system so that the organization can handle that work properly next time.

This is also why I have little interest in replacing IntelliJ with Cursor, Windsurf, or another AI IDE. Those tools make a programmer more effective inside the coding layer. Orgabot is trying to make the coding layer something I rarely need to enter at all.

The IDE May Be Becoming an Implementation Detail

This is why I think we're entering a post-IDE era.

That doesn't mean IDEs disappear tomorrow, and it doesn't even mean graphical code editors disappear. There will always be times when looking directly at source code is the best way to understand a problem. But I think the IDE is losing its position as the primary interface between programmer and software.

The agent harness is becoming that interface, and that creates an awkward strategic problem for traditional IDE companies and AI IDE companies alike. The obvious response has been to put AI inside the IDE: add a chat panel, add autocomplete, add an agent mode, let the AI modify several files at once.

Those are useful improvements, but I wonder whether they have the architecture backwards.

Maybe the future isn't an IDE with an agent inside it. Maybe it's an agent with an editor inside it.

The agent becomes the environment. The repository, terminal, browser, debugger, editor, tests, CI system, issue tracker, and deployment infrastructure are tools available to that environment when needed. Most of the time, the human stays one level above them.

I Didn't Cancel JetBrains Because JetBrains Got Worse

This distinction matters. JetBrains didn't lose me because IntelliJ became bad software. Quite the opposite. IntelliJ remains an astonishingly capable piece of engineering.

I canceled because my workflow changed so dramatically that I no longer need 99 percent of what it does, and that's a much bigger threat. The hardest competitive problem isn't when somebody builds a better version of your product. It's when the user's behavior changes enough that the product category itself becomes less important.

For years, I wanted the best possible environment for editing source code. Then I wanted the best possible environment for directing agents that edit source code. Increasingly, even that undersells where this is going.

I want the best possible environment for creating organizations of agents that can take responsibility, delegate work, review one another, escalate when necessary, and produce software without requiring me to descend into the implementation layer.

The IDE is not the center of that world. It is a tool one of the agents might use.

After years of living inside IDEs, I think I may have finally left them behind.

Microsoft hat das Konto meines Sohnes zurückgegeben. Es hätte keine 60.000 Aufrufe brauchen dürfen.

Matt Senter — Wed, 09 Sep 2026 14:20:10 +0000

Das Konto ist zurück. Der Wiederherstellungsprozess muss trotzdem funktionieren, wenn niemand Wichtiges zuschaut.

Vor ein paar Wochen habe ich darüber geschrieben, was passierte, nachdem das Microsoft-Konto meines Sohnes übernommen worden war. Die Kurzfassung war hässlich: Ein Angreifer übernahm die Kontrolle über das Konto, änderte die Wiederherstellungsinformationen, und Microsofts Kontowiederherstellungsprozess ließ mich versuchen zu beweisen, dass das Konto meines eigenen Kindes tatsächlich ihm gehört. Ich lieferte umfangreiche Beweise, folgte den Anweisungen, die Microsoft mir gab, und dann verschwand der Supportprozess praktisch.

Über diese Erfahrung habe ich in Microsofts Kontowiederherstellung ist Sicherheitstheater geschrieben. Dieser Beitrag bekam am Ende mehr als 60.000 Aufrufe.

Dann passierte etwas Interessantes. Jemand ziemlich weit oben bei Microsoft sah sich mein LinkedIn-Profil an. Ich bemerkte es, und am 1. September schickte ich ihm eine Nachricht und fragte ihn direkt: Sehen Sie sich mein Profil wegen meines Blogbeitrags an? Er sagte ja. Diese Nachricht änderte alles.

Der Zeitverlauf erzählt die Geschichte

Ich kontaktierte Microsoft wegen der Kontoübernahme zum ersten Mal am 13. August 2026.

Am 14. August schickte mir das ursprüngliche Supportteam dies:

Wenn Sie innerhalb der nächsten 7 Tage mit zusätzlichen Informationen auf diese E-Mail antworten, setze ich meine Untersuchung gerne fort.

Also tat ich genau das. Am 15. August, nur einen Tag später, antwortete ich mit einem Berg zusätzlicher Informationen und Beweise. Danach hörte ich nichts mehr: keine Rückfragen, keine Erklärung, keine Bestätigung, dass die Untersuchung weitergegangen war. Das Team hörte einfach auf, mit mir zu kommunizieren.

Dieses Schweigen dauerte bis zum 4. September, als ich endlich diese Antwort erhielt:

Diese Serviceanfrage wurde bereits gelöst und geschlossen. Wir helfen Ihnen gerne bei Ihrer neuen Anfrage; ich kann diese geschlossene Serviceanfrage jedoch nicht wieder öffnen. Sie müssen eine neue Serviceanfrage erstellen, indem Sie den Microsoft-Support kontaktieren, und jemand hilft Ihnen gerne weiter.

Das war erstaunlich. Mir war ausdrücklich gesagt worden, dass die Untersuchung fortgesetzt würde, wenn ich innerhalb von sieben Tagen mit weiteren Informationen antworte. Ich antwortete innerhalb eines Tages. Stattdessen wurde der Fall offenbar ohne mein Wissen geschlossen, und ich wurde fast drei Wochen lang ignoriert, bevor man mir sagte, ich solle von vorn anfangen.

Ich antwortete und wies auf den Widerspruch hin. Microsoft hatte mich um weitere Beweise gebeten, versprochen, weiter zu ermitteln, wenn ich sie innerhalb von sieben Tagen liefere, sie innerhalb eines Tages erhalten und das Ticket trotzdem stillschweigend geschlossen. Ich fragte nach dem Grund und bekam nie eine Antwort.

Dieser Teil der Geschichte bleibt völlig inakzeptabel. Menschen, die mit einer Kontoübernahme zu tun haben, sind ohnehin in einer belastenden Lage. Eine Untersuchung stillschweigend zu schließen, nachdem man jemandem ausdrücklich ein Zeitfenster für weitere Beweise eingeräumt hat, und dann nicht zu erklären, was passiert ist, ist nicht die Art, wie ein Sicherheits- oder Kundensupportprozess funktionieren sollte.

Unterdessen funktionierte LinkedIn besser als der Microsoft-Support

Während das ursprüngliche Supportteam noch schwieg, bemerkte ich am 1. September, dass ein Microsoft-Mitarbeiter ziemlich weit oben in der Organisation mein LinkedIn-Profil angesehen hatte. Angesichts des Zeitpunkts und der Aufmerksamkeit, die der ursprüngliche Blogbeitrag erhalten hatte, konnte ich mir den Grund ziemlich gut denken. Ich schrieb ihm direkt und fragte, ob er sich mein Profil wegen des Blogbeitrags ansehe. Er antwortete noch am selben Tag: ja.

Wir begannen, über LinkedIn zu kommunizieren, und er war außerordentlich hilfsbereit. Er brachte mich mit einem Eskalationsteam innerhalb von Microsoft in Kontakt, und der Wiederherstellungsprozess begann von Neuem. Strukturell unterschied sich der Eskalationsprozess nicht dramatisch von dem, was ich bereits durchgemacht hatte. Sie stellten Fragen, ich lieferte Beweise, und sie prüften Kontoinformationen, um den rechtmäßigen Eigentümer zu ermitteln.

Aber es gab einen gewaltigen Unterschied: Diesmal fühlte es sich an, als würde tatsächlich jemand die Beweise auswerten, die ich lieferte. Sie reagierten schnell, kommunizierten mit mir, stellten Rückfragen und schienen die Geschichte des Kontos und die von mir gelieferten Informationen zu berücksichtigen, statt den Fall wie eine binäre Checkliste zu behandeln.

Und am 7. September 2026 wurde das Konto wiederhergestellt. Sechs Tage, nachdem ich den Microsoft-Mitarbeiter auf LinkedIn kontaktiert hatte. Fünfundzwanzig Tage nach meinem ersten Kontakt mit dem Microsoft-Support. Juhu!

Das Eskalationsteam war hervorragend

Ich möchte in diesem Punkt deutlich sein, denn es wäre unfair, alle bei Microsoft über einen Kamm zu scheren. Die Menschen, die mir schließlich halfen, waren großartig. Der Microsoft-Mitarbeiter, mit dem ich über LinkedIn in Kontakt kam, war freundlich, reagierte schnell und wollte wirklich herausfinden, was passiert war. Das Eskalationsteam nahm die Situation ernst und kam am Ende zum richtigen Ergebnis.

Wir verbrachten sogar Zeit damit zu verstehen, wie das Konto überhaupt kompromittiert wurde. Das bleibt die größte unbeantwortete Frage. Da ich hauptsächlich Mac-Nutzer bin und bei weitem nicht so viel Zeit mit der Verwaltung von Windows-Rechnern verbringe, gab mir der Microsoft-Kontakt einige Vorschläge, wie ich den Computer meines Sohnes untersuchen könnte. Von dort aus nutzte ich ChatGPT, um deutlich tiefer zu gehen: den Windows-Rechner untersuchen, Sicherheitseinstellungen prüfen, nach Persistenzmechanismen suchen, verdächtige Software kontrollieren und nach Hinweisen suchen, dass der Computer selbst kompromittiert worden war.

Bisher habe ich nichts gefunden: keine offensichtliche Malware, kein eindeutiges Fernzugriffstool, keine Hinweise darauf, dass jemand dauerhaft Kontrolle über den Rechner hatte, und nichts, was die Übernahme sauber erklärt. Das macht irgendeine Form von Social Engineering immer wahrscheinlicher, auch wenn ich immer noch nicht beweisen kann, was genau passiert ist. Mein Sohn erinnert sich an nichts, was es offensichtlich erklären würde, und die verfügbaren Kontodaten haben mir nicht genug Informationen geliefert, um den Angriff schlüssig zu rekonstruieren. Ich grabe weiter.

Das Konto ist zurück. Und es ist jetzt viel schwerer zu stehlen.

Sobald wir wieder Zugriff hatten, habe ich das Konto erheblich abgesichert. Noch wichtiger: Mein Sohn und ich hatten ein langes und sehr direktes Gespräch über moderne Betrugsmaschen. Das ist etwas, das Eltern technisch versierter Kinder meiner Meinung nach unterschätzen können: Zu wissen, wie man Computer benutzt, ist nicht dasselbe wie feindseliges Verhalten im Internet zu verstehen.

Kinder verbringen enorm viel Zeit in Umgebungen, in denen Fremde sie routinemäßig auffordern:

Sich auf Websites anzumelden.
Discord-Servern beizutreten.
Mods oder Hilfsprogramme zu installieren.
QR-Codes zu scannen.
Spielkonten zu authentifizieren.
Bestätigungscodes einzugeben.
Links zu folgen, die per Chat geschickt werden.
Microsoft-, Google-, Steam-, Xbox-, Roblox- oder andere Identitäten mit Drittanbieterdiensten zu verknüpfen.

Die meisten dieser Interaktionen sind völlig legitim. Ein Angreifer braucht nur eine, die es nicht ist. Deshalb ändern wir, wie Authentifizierung bei uns zu Hause funktioniert. Mein Sohn wird für seine Zugangsdaten jetzt ausschließlich einen Passwortmanager verwenden. Wenn ein Passwort nicht im Passwortmanager ist, sollte er es nicht eintippen. Wenn der Passwortmanager eine Website nicht als zu den erwarteten Zugangsdaten gehörig erkennt, sollte das sofort ein Warnsignal sein, dass etwas nicht stimmt.

Das beseitigt Phishing oder Social Engineering nicht, aber es reduziert den manuellen Umgang mit Zugangsdaten drastisch und verkleinert unsere Angriffsfläche. Wir haben außerdem die Wiederherstellungsmechanismen und die Authentifizierung überall dort verschärft, wo es möglich war.

Aber es gibt hier ein größeres Problem

Natürlich bin ich mit dem Ergebnis zufrieden. Mein Sohn hat sein Konto zurück, die Leute im Eskalationsteam von Microsoft waren wirklich hilfreich, und jemand innerhalb von Microsoft hat sich genug um die Situation gekümmert, um sich persönlich einzuschalten. Aber ich komme immer wieder auf eine unbequeme Frage zurück: Was wäre passiert, wenn mein Blogbeitrag 60 Aufrufe statt 60.000 bekommen hätte?

Der normale Supportprozess:

13. August: Ich kontaktiere Microsoft.
14. August: Microsoft bittet mich um weitere Beweise und sagt ausdrücklich, dass weiter ermittelt wird, wenn ich innerhalb von sieben Tagen antworte.
15. August: Ich liefere umfangreiche zusätzliche Beweise.
15. August bis 4. September: Schweigen.
4. September: Microsoft teilt mir mit, dass der Fall bereits geschlossen wurde und ich von vorn anfangen muss.

Der Eskalationsprozess:

1. September: Ich bemerke, dass ein Microsoft-Mitarbeiter mein LinkedIn-Profil angesehen hat, und kontaktiere ihn.
1. September: Er antwortet und beginnt, mich mit den richtigen Leuten zu verbinden.
7. September: Microsoft stellt das Konto wieder her.

Der Eskalationsweg löste in sechs Tagen, was der gewöhnliche Supportprozess in mehr als drei Wochen nicht lösen konnte. Das ist die eigentliche Geschichte. Ich hatte zufällig eine Plattform. Die Geschichte verbreitete sich. Jemand bei Microsoft bemerkte sie, sah sich mein LinkedIn-Profil an, und ich bemerkte das zufällig. Ich kontaktierte ihn, er antwortete, er wusste, wen er intern ansprechen musste, und schließlich wurde das Konto wiederhergestellt.

Das ist eine bemerkenswert spezifische Kette von Ereignissen, und nichts davon hätte nötig sein dürfen. Die Beweise, die ich dem Eskalationsteam gab, waren nicht auf magische Weise anders, weil ein Microsoft-Mitarbeiter meinen Blogbeitrag gesehen hatte. Ich war immer noch derselbe Elternteil. Es war immer noch dasselbe Konto. Die Kontohistorie war immer noch dieselbe. Die Umstände der Übernahme waren immer noch dieselben. Was sich änderte, war, dass jemand bei Microsoft, der sich in der Organisation zurechtfindet, Interesse an dem Fall entwickelte.

Das beunruhigt mich weit mehr als die Frage, ob meine spezielle Geschichte ein Happy End hatte. Ein Sicherheits-Wiederherstellungssystem muss für die Person funktionieren, die keinen Blog hat, deren Geschichte nicht von 60.000 Menschen gelesen wird, die keinen Microsoft-Mitarbeiter auf LinkedIn finden kann und die nicht technisch versiert genug ist, Anmeldeverläufe und Sicherheitsereignisse zu rekonstruieren. Es muss funktionieren, wenn niemand Wichtiges zuschaut.

Kontowiederherstellung ist Teil des Sicherheitsmodells

Meine ursprüngliche Kritik an Microsofts Kontowiederherstellung hat sich im Kern nicht geändert. Kontowiederherstellung ist nicht bloß Kundensupport. Sie ist ein Sicherheitssystem. Unternehmen investieren enormen Entwicklungsaufwand, um die Eingangstür mit Passkeys, MFA, Verhaltensanalyse, Erkennung verdächtiger Anmeldungen, Geräte-Fingerprints, Risikobewertung und immer ausgefeilteren Authentifizierungssystemen zu schützen. Aber irgendwann verliert jemand den Zugang, und in diesem Moment wird der Kontowiederherstellungsprozess faktisch zum Authentifizierungssystem.

Er muss eine außerordentlich schwierige Frage beantworten: Wer sollte dieses Konto kontrollieren? Sie in die eine oder andere Richtung falsch zu beantworten, ist verheerend. Macht man die Wiederherstellung zu einfach, können Angreifer Konten über den Kundensupport stehlen. Macht man sie zu starr, können rechtmäßige Eigentümer Konten dauerhaft verlieren, die Jahre an Käufen, E-Mails, Dateien, Spielverläufen, Identitäten, Abonnements und Familiendaten enthalten können.

Das ist ein schwieriges technisches Problem. Aber „schwieriges Problem“ darf nicht zur Ausrede für ein System werden, in dem der beste Weg zu einer erfolgreichen Wiederherstellung darin besteht, genug öffentliche Aufmerksamkeit zu erzeugen, damit jemand Hochrangiges im Unternehmen auf einen aufmerksam wird.

Microsoft hat am Ende das Richtige getan

Ich möchte dieses Update anders beenden als das erste. Microsoft hat das Problem letztlich behoben. Die Menschen, die mir geholfen haben, waren professionell, einfühlsam und effektiv. Ich danke dem Microsoft-Mitarbeiter, der meinen Beitrag gesehen, einem Fremden auf LinkedIn geantwortet und persönlich geholfen hat, die Sache durch das Unternehmen zu lotsen. Ich danke dem Eskalationsteam, das die Beweise erneut geprüft und das Konto meines Sohnes wiederhergestellt hat. Dafür gebührt ihnen Anerkennung.

Aber die Tatsache, dass die Eskalation funktioniert hat, zeigt auch etwas Wichtiges: Das Konto war wiederherstellbar. Microsoft hatte genug Informationen, um festzustellen, dass mein Sohn der rechtmäßige Eigentümer ist. Das Problem war, den Fall vor einen Prozess zu bringen, der diese Feststellung treffen kann.

Das ist der Teil, den Microsoft noch beheben muss, denn der nächste Elternteil hat vielleicht keinen viralen Blogbeitrag. Und das Konto seines Kindes zurückzubekommen sollte keinen erfordern.

A Microsoft devolveu a conta do meu filho. Não deveria ter exigido 60.000 visualizações.

Matt Senter — Wed, 09 Sep 2026 14:19:23 +0000

A conta voltou. O processo de recuperação ainda precisa funcionar quando ninguém importante está olhando.

Há algumas semanas, escrevi sobre o que aconteceu depois que a conta Microsoft do meu filho foi tomada. A versão curta era feia: um invasor assumiu o controle da conta, alterou as informações de recuperação, e o processo de recuperação de conta da Microsoft me deixou tentando provar que a conta do meu próprio filho realmente pertencia a ele. Forneci provas extensas, segui as instruções que a Microsoft me deu, e então o processo de suporte simplesmente desapareceu.

Escrevi sobre essa experiência em A recuperação de contas da Microsoft é teatro de segurança. Aquele post acabou recebendo mais de 60.000 visualizações.

Então aconteceu algo interessante. Alguém em uma posição bastante alta na Microsoft visualizou meu perfil no LinkedIn. Eu percebi e, em 1º de setembro, mandei uma mensagem e perguntei diretamente: Você está olhando meu perfil por causa do meu post no blog? Ele disse que sim. Aquela mensagem mudou tudo.

A linha do tempo conta a história

Entrei em contato com a Microsoft pela primeira vez sobre a invasão da conta em 13 de agosto de 2026.

Em 14 de agosto, a equipe de suporte original me enviou isto:

Se você responder a este e-mail nos próximos 7 dias com informações adicionais, terei o maior prazer em continuar minha investigação.

Então fiz exatamente isso. Em 15 de agosto, apenas um dia depois, respondi com uma montanha de informações e provas adicionais. Depois disso, não ouvi mais nada: nenhuma pergunta de acompanhamento, nenhuma explicação, nenhuma confirmação de que a investigação havia continuado. A equipe simplesmente parou de se comunicar comigo.

Esse silêncio durou até 4 de setembro, quando finalmente recebi esta resposta:

Esta solicitação de serviço já foi resolvida e encerrada. Teremos prazer em ajudá-lo com sua nova solicitação; no entanto, não consigo reabrir esta solicitação de serviço encerrada. Você precisa criar uma nova solicitação de serviço entrando em contato com o Suporte da Microsoft, e alguém terá prazer em ajudá-lo.

Foi espantoso. Haviam me dito explicitamente que, se eu respondesse em sete dias com mais informações, a investigação continuaria. Respondi em um dia. Em vez disso, o caso aparentemente foi encerrado sem meu conhecimento, e fui ignorado por quase três semanas antes de me dizerem para começar de novo.

Respondi apontando a contradição. A Microsoft havia me pedido mais provas, prometido continuar investigando se eu as fornecesse em sete dias, recebeu tudo em um dia e, mesmo assim, encerrou o chamado em silêncio. Perguntei por quê e nunca recebi resposta.

Essa parte da história continua completamente inaceitável. Pessoas lidando com invasões de conta já estão em uma situação estressante. Encerrar uma investigação em silêncio depois de dizer explicitamente a alguém que ela tem um prazo para enviar mais provas, e depois não explicar o que aconteceu, não é assim que um processo de segurança ou de atendimento ao cliente deveria funcionar.

Enquanto isso, o LinkedIn funcionou melhor que o suporte da Microsoft

Enquanto a equipe de suporte original ainda estava em silêncio, percebi em 1º de setembro que um funcionário da Microsoft em posição bastante alta na organização havia visualizado meu perfil no LinkedIn. Dado o momento e a atenção que o post original havia recebido, eu tinha um bom palpite do motivo. Mandei uma mensagem direta perguntando se ele estava olhando meu perfil por causa do post. Ele respondeu no mesmo dia: sim.

Começamos a nos comunicar pelo LinkedIn, e ele foi extraordinariamente prestativo. Ele me conectou a uma equipe de escalonamento dentro da Microsoft, e o processo de recuperação recomeçou. Estruturalmente, o processo de escalonamento não foi dramaticamente diferente do que eu já havia passado. Eles faziam perguntas, eu fornecia provas, e eles analisavam as informações da conta para determinar a propriedade legítima.

Mas havia uma diferença enorme: desta vez, parecia que alguém estava realmente avaliando as provas que eu fornecia. Eles foram responsivos, se comunicaram comigo, fizeram perguntas de acompanhamento e pareciam considerar o histórico da conta e as informações que forneci, em vez de tratar o caso como uma lista de verificação binária.

E em 7 de setembro de 2026 a conta foi restaurada. Seis dias depois de eu contatar o funcionário da Microsoft no LinkedIn. Vinte e cinco dias depois do meu primeiro contato com o suporte da Microsoft. Eba!

A equipe de escalonamento foi excelente

Quero ser claro sobre esta parte, porque seria injusto colocar todos na Microsoft no mesmo saco. As pessoas que finalmente me ajudaram foram ótimas. O funcionário da Microsoft com quem me conectei pelo LinkedIn foi gentil, responsivo e genuinamente interessado em descobrir o que havia acontecido. A equipe de escalonamento tratou a situação com seriedade e, no fim, chegou ao resultado correto.

Até passamos um tempo tentando entender como a conta foi comprometida em primeiro lugar. Essa continua sendo a maior pergunta sem resposta. Como sou principalmente usuário de Mac e não passo nem de longe tanto tempo administrando máquinas Windows, o contato da Microsoft me deu algumas sugestões para investigar o computador do meu filho. A partir daí, usei o ChatGPT para ir consideravelmente mais fundo: examinar a máquina Windows, revisar configurações de segurança, procurar mecanismos de persistência, verificar softwares suspeitos e buscar evidências de que o próprio computador havia sido comprometido.

Até agora, não encontrei nada: nenhum malware óbvio, nenhuma ferramenta clara de acesso remoto, nenhuma evidência de que alguém tivesse controle persistente da máquina e nada que explique claramente a invasão. Isso torna alguma forma de engenharia social cada vez mais provável, embora eu ainda não consiga provar exatamente o que aconteceu. Meu filho não se lembra de ter feito nada que explique isso de forma óbvia, e os dados disponíveis da conta não me deram informações suficientes para reconstruir o ataque de maneira conclusiva. Continuo investigando.

A conta voltou. E agora é muito mais difícil de roubar.

Assim que recuperamos o acesso, reforcei consideravelmente a conta. Mais importante ainda, meu filho e eu tivemos uma conversa longa e muito direta sobre golpes modernos. Acho que pais de crianças tecnicamente sofisticadas podem subestimar isto: saber usar computadores não é a mesma coisa que entender o comportamento adversário na internet.

As crianças passam um tempo enorme em ambientes onde estranhos rotineiramente pedem que elas:

Façam login em sites.
Entrem em servidores do Discord.
Instalem mods ou utilitários.
Escaneiem códigos QR.
Autentiquem contas de jogos.
Digitem códigos de verificação.
Sigam links enviados por chat.
Conectem identidades da Microsoft, Google, Steam, Xbox, Roblox ou outras a serviços de terceiros.

A maioria dessas interações é perfeitamente legítima. Um invasor só precisa de uma que não seja. Então estamos mudando como a autenticação funciona na nossa casa. Meu filho agora vai usar um gerenciador de senhas exclusivamente para suas credenciais. Se uma senha não está no gerenciador de senhas, ele não deveria estar digitando. Se o gerenciador de senhas não reconhece um site como pertencente à credencial que ele espera usar, isso deve ser imediatamente um alerta de que algo está errado.

Isso não elimina phishing nem engenharia social, mas reduz drasticamente a quantidade de manuseio manual de credenciais e diminui nossa superfície de ataque. Também apertamos os mecanismos de recuperação e a autenticação sempre que possível.

Mas há um problema maior aqui

Obviamente estou feliz com o resultado. Meu filho recuperou a conta, as pessoas da equipe de escalonamento da Microsoft foram genuinamente prestativas, e alguém dentro da Microsoft se importou o suficiente com a situação para se envolver pessoalmente. Mas continuo voltando a uma pergunta desconfortável: O que teria acontecido se meu post tivesse recebido 60 visualizações em vez de 60.000?

O processo de suporte normal:

13 de agosto: entro em contato com a Microsoft.
14 de agosto: a Microsoft me pede mais provas e diz explicitamente que continuará investigando se eu responder em sete dias.
15 de agosto: forneço provas adicionais extensas.
15 de agosto a 4 de setembro: silêncio.
4 de setembro: a Microsoft me diz que o caso já havia sido encerrado e que preciso começar de novo.

O processo de escalonamento:

1º de setembro: percebo que um funcionário da Microsoft visualizou meu perfil no LinkedIn e entro em contato com ele.
1º de setembro: ele responde e começa a me conectar às pessoas certas.
7 de setembro: a Microsoft restaura a conta.

O caminho de escalonamento resolveu em seis dias o que o processo de suporte comum não conseguiu resolver em mais de três semanas. Essa é a verdadeira história aqui. Por acaso eu tinha uma plataforma. A história se espalhou. Alguém dentro da Microsoft notou, olhou meu perfil no LinkedIn, e por acaso eu percebi isso. Entrei em contato, ele respondeu, ele sabia com quem falar internamente, e a conta acabou sendo restaurada.

É uma cadeia de eventos notavelmente específica, e nada disso deveria ter sido necessário. As provas que dei à equipe de escalonamento não ficaram magicamente diferentes porque um funcionário da Microsoft viu meu post. Eu continuava sendo o mesmo pai. Continuava sendo a mesma conta. O histórico da conta continuava o mesmo. As circunstâncias da invasão continuavam as mesmas. O que mudou foi que alguém dentro da Microsoft, com capacidade de navegar pela organização, se interessou pelo caso.

Isso me preocupa muito mais do que se a minha história em particular teve um final feliz. Um sistema de recuperação de segurança precisa funcionar para a pessoa que não tem um blog, não tem 60.000 pessoas lendo sua história, não consegue encontrar um funcionário da Microsoft no LinkedIn e não tem conhecimento técnico suficiente para reconstruir históricos de login e eventos de segurança. Ele precisa funcionar quando ninguém importante está olhando.

A recuperação de conta faz parte do modelo de segurança

Minha crítica original à recuperação de contas da Microsoft não mudou fundamentalmente. Recuperação de conta não é apenas atendimento ao cliente. É um sistema de segurança. As empresas gastam um esforço enorme de engenharia protegendo a porta da frente com passkeys, MFA, análise comportamental, detecção de logins suspeitos, impressões digitais de dispositivos, pontuação de risco e sistemas de autenticação cada vez mais sofisticados. Mas em algum momento alguém perde o acesso, e nesse instante o processo de recuperação de conta se torna, na prática, o sistema de autenticação.

Ele precisa responder a uma pergunta extraordinariamente difícil: Quem deveria controlar esta conta? Errar em qualquer direção é desastroso. Torne a recuperação fácil demais e invasores podem roubar contas pelo atendimento ao cliente. Torne-a rígida demais e donos legítimos podem perder para sempre contas que podem conter anos de compras, e-mails, arquivos, histórico de jogos, identidades, assinaturas e dados da família.

É um problema difícil de engenharia. Mas "problema difícil" não pode virar desculpa para um sistema em que o melhor caminho para uma recuperação bem-sucedida é gerar atenção pública suficiente para que alguém sênior dentro da empresa note você.

A Microsoft acabou fazendo a coisa certa

Quero terminar esta atualização de forma diferente da primeira. A Microsoft finalmente resolveu o problema. As pessoas que me ajudaram foram profissionais, empáticas e eficazes. Agradeço ao funcionário da Microsoft que viu meu post, respondeu a um estranho no LinkedIn e ajudou pessoalmente a encaminhar isso dentro da empresa. Agradeço à equipe de escalonamento que revisitou as provas e restaurou a conta do meu filho. Eles merecem crédito por isso.

Mas o fato de o escalonamento ter funcionado também demonstra algo importante: a conta era recuperável. A Microsoft tinha informações suficientes para determinar que meu filho era o dono legítimo. O problema era levar o caso até um processo capaz de tomar essa decisão.

Essa é a parte que a Microsoft ainda precisa corrigir, porque o próximo pai ou mãe pode não ter um post viral. E recuperar a conta do seu filho não deveria exigir um.

Microsoftは息子のアカウントを返した。6万ビューが必要であってはならなかった。

Matt Senter — Wed, 09 Sep 2026 14:18:07 +0000

アカウントは戻ってきた。しかし復旧手続きは、重要な誰かが見ていないときにも機能しなければならない。

数週間前、息子のMicrosoftアカウントが乗っ取られた後に起きたことを書きました。短くまとめると、ひどい話でした。攻撃者がアカウントを掌握して復旧情報を書き換え、Microsoftのアカウント復旧手続きのせいで、私は自分の子どものアカウントが本当に本人のものだと証明しようと奔走することになりました。私は膨大な証拠を提出し、Microsoftの指示に従いましたが、その後サポートの手続きは事実上消えてしまいました。

その経験は「Microsoftのアカウント復旧はセキュリティの演出にすぎない」に書きました。あの記事は最終的に6万ビューを超えました。

そこで興味深いことが起きました。Microsoftのかなり上の立場の人が、私のLinkedInプロフィールを閲覧したのです。私はそれに気づき、9月1日にその人へメッセージを送って率直に尋ねました。私のブログ記事が理由でプロフィールを見ているのですか？ 答えはイエスでした。このメッセージがすべてを変えました。

タイムラインがすべてを物語る

アカウント乗っ取りについて最初にMicrosoftへ連絡したのは2026年8月13日でした。

8月14日、最初のサポートチームからこう送られてきました。

今後7日以内に追加情報を添えてこのメールに返信いただければ、喜んで調査を継続いたします。

そこで、まさにその通りにしました。わずか1日後の8月15日、私は山ほどの追加情報と証拠を返信しました。その後は何の音沙汰もありませんでした。追加の質問も、説明も、調査が継続しているという確認もありません。チームは単に私との連絡を絶ったのです。

その沈黙は9月4日まで続き、ようやくこんな返信が届きました。

このサービスリクエストはすでに解決済みとしてクローズされています。新しいリクエストについては喜んでサポートいたしますが、クローズされたサービスリクエストを再開することはできません。Microsoftサポートに連絡して新しいサービスリクエストを作成していただく必要があり、担当者が喜んで対応いたします。

驚くべきことでした。7日以内に追加情報を送れば調査を継続すると明確に言われていたのです。私は1日で返信しました。それなのにケースは私の知らないうちにクローズされ、3週間近く放置されたあげく、最初からやり直せと言われたのです。

私は返信し、この矛盾を指摘しました。Microsoftは私に追加の証拠を求め、7日以内に提出すれば調査を続けると約束し、1日で受け取り、それでも黙ってチケットを閉じたのです。理由を尋ねましたが、返答はありませんでした。

この部分は今でもまったく受け入れられません。アカウント乗っ取りに直面している人は、すでにストレスの大きい状況にいます。追加の証拠を提出できる期間があると明示しておきながら黙って調査を閉じ、何が起きたのか説明もしないというのは、セキュリティやカスタマーサポートの手続きとしてあってはならないことです。

その間、LinkedInのほうがMicrosoftサポートより役に立った

最初のサポートチームがまだ沈黙していた9月1日、Microsoftの組織内でかなり上の立場の社員が私のLinkedInプロフィールを閲覧したことに気づきました。タイミングと、元の記事が集めた注目を考えれば、理由はだいたい見当がつきました。私はその人に直接メッセージを送り、ブログ記事が理由で私のプロフィールを見ているのかと尋ねました。その日のうちに返事が来ました。イエスでした。

私たちはLinkedInでやり取りを始め、その人は驚くほど親身に助けてくれました。Microsoft社内のエスカレーションチームにつないでくれ、復旧手続きが再び動き出しました。構造的には、エスカレーションの手続きは私がすでに経験したものと劇的に違うわけではありませんでした。質問され、私が証拠を提出し、正当な所有者を判断するためにアカウント情報が確認される、という流れです。

しかし、ひとつ決定的な違いがありました。今回は、私が提出した証拠を誰かが実際に評価している、という手応えがあったのです。 対応は迅速で、こちらと連絡を取り、追加の質問をし、ケースを二択のチェックリストのように扱うのではなく、アカウントの履歴や私が提供した情報を考慮しているようでした。

そして2026年9月7日、アカウントは復旧しました。LinkedInでMicrosoftの社員に連絡してから6日後。最初にMicrosoftサポートに連絡してから25日後です。やった！

エスカレーションチームは素晴らしかった

この点ははっきりさせておきたいと思います。Microsoftの全員をひとくくりに批判するのは公平ではないからです。最終的に助けてくれた人たちは素晴らしかった。LinkedIn経由でつながったMicrosoftの社員は親切で、対応が早く、何が起きたのかを本気で突き止めようとしてくれました。エスカレーションチームは状況を真剣に受け止め、最終的に正しい結論にたどり着きました。

私たちはそもそもアカウントがどのように侵害されたのかを理解しようと時間を割きさえしました。これは今も最大の未解決の疑問です。私は主にMacユーザーで、Windowsマシンの管理にはそれほど時間を費やしていないため、Microsoftの担当者は息子のパソコンを調べるための提案をいくつかしてくれました。そこから私はChatGPTを使ってかなり深く掘り下げました。Windowsマシンの検査、セキュリティ設定の確認、永続化の仕組みの探索、不審なソフトウェアのチェック、そしてパソコン自体が侵害された証拠の捜索です。

今のところ、何も見つかっていません。明らかなマルウェアも、明確なリモートアクセスツールも、誰かがマシンを継続的に支配していた証拠も、乗っ取りをすっきり説明できるものも何もありません。そのため、何らかのソーシャルエンジニアリングだった可能性がますます高まっていますが、正確に何が起きたのかはまだ証明できていません。息子は原因を明らかに説明できるような行動を覚えておらず、入手できるアカウントデータも攻撃を決定的に再構成できるほどの情報を与えてくれません。私はまだ調べ続けています。

アカウントは戻った。そして今では、はるかに盗みにくくなっている。

アクセスを取り戻した後、私はアカウントを大幅に強化しました。それ以上に重要なのは、息子と現代の詐欺について長く、とても率直な話をしたことです。技術に詳しい子どもを持つ親は、この点を過小評価しがちだと思います。パソコンの使い方を知っていることと、インターネット上の敵対的な行動を理解していることは同じではありません。

子どもたちは、見知らぬ人から日常的に次のようなことを求められる環境で膨大な時間を過ごしています。

ウェブサイトにサインインする。
Discordサーバーに参加する。
Modやユーティリティをインストールする。
QRコードをスキャンする。
ゲームアカウントを認証する。
確認コードを入力する。
チャットで送られてきたリンクを開く。
Microsoft、Google、Steam、Xbox、Robloxなどのアカウントをサードパーティのサービスに連携する。

こうしたやり取りのほとんどはまったく正当なものです。攻撃者には、そうでないものが一つあれば十分です。そこで私たちは、家庭での認証のやり方を変えることにしました。息子はこれから、認証情報についてパスワードマネージャーだけを使うことにします。パスワードマネージャーに入っていないパスワードは、そもそも入力すべきではありません。パスワードマネージャーが、あるサイトを使おうとしている認証情報のものだと認識しなければ、それは即座に何かがおかしいという警告になるべきです。

これでフィッシングやソーシャルエンジニアリングがなくなるわけではありませんが、手作業で認証情報を扱う機会を劇的に減らし、攻撃対象領域を狭めます。可能な限り、復旧の仕組みと認証も引き締めました。

しかし、もっと大きな問題がある

結果には当然満足しています。息子はアカウントを取り戻し、Microsoftのエスカレーションチームの人たちは本当に助けになり、Microsoft社内の誰かがこの状況を気にかけて個人的に関わってくれました。それでも、私はひとつの居心地の悪い問いに何度も立ち返ってしまいます。もし私のブログ記事が6万ビューではなく60ビューだったら、どうなっていたのか？

通常のサポート手続き：

8月13日：Microsoftに連絡。
8月14日：Microsoftが追加の証拠を求め、7日以内に返信すれば調査を続けると明言。
8月15日：大量の追加証拠を提出。
8月15日から9月4日：沈黙。
9月4日：ケースはすでにクローズされており、最初からやり直す必要があるとMicrosoftから通告。

エスカレーションの手続き：

9月1日：Microsoftの社員がLinkedInプロフィールを閲覧したことに気づき、連絡。
9月1日：返信があり、適切な担当者につなぎ始めてくれる。
9月7日：Microsoftがアカウントを復旧。

通常のサポート手続きが3週間以上かけて解決できなかったことを、エスカレーションの経路は6日で解決しました。それこそが本当の話です。私にはたまたま発信の場がありました。話は広まりました。Microsoft社内の誰かがそれに気づき、私のLinkedInプロフィールを見て、私はたまたまそれに気づきました。私が連絡し、その人が返信し、社内で誰に連絡すべきかを知っていて、最終的にアカウントは復旧しました。

これは驚くほど特殊な出来事の連鎖であり、そのどれも本来は必要なかったはずです。私がエスカレーションチームに渡した証拠は、Microsoftの社員が私のブログ記事を見たからといって魔法のように変わったわけではありません。私は同じ親でした。同じアカウントでした。アカウントの履歴も同じでした。乗っ取りの状況も同じでした。変わったのは、組織の中を動き回れるMicrosoft社内の人物がこのケースに関心を持った、ということだけです。

私の話がハッピーエンドだったかどうかより、そのほうがはるかに気がかりです。セキュリティの復旧システムは、ブログを持たず、6万人に自分の話を読んでもらえず、LinkedInでMicrosoftの社員を見つけられず、ログイン履歴やセキュリティイベントを再構成できるほど技術に詳しくない人のためにも機能しなければなりません。重要な誰かが見ていないときにも機能しなければならないのです。

アカウント復旧はセキュリティモデルの一部である

Microsoftのアカウント復旧に対する私の当初の批判は、根本的には変わっていません。アカウント復旧は単なるカスタマーサポートではありません。セキュリティシステムです。企業はパスキー、多要素認証、行動分析、不審なログインの検知、デバイスフィンガープリント、リスクスコアリング、そしてますます高度化する認証システムで正面玄関を守るために、膨大なエンジニアリングの労力を注いでいます。しかし、いつかは誰かがアクセスを失い、その瞬間、アカウント復旧の手続きが事実上の認証システムになるのです。

それは、とてつもなく難しい問いに答えなければなりません。このアカウントを誰が管理すべきか？ どちらの方向に間違えても悲惨です。復旧を簡単にしすぎれば、攻撃者はカスタマーサポート経由でアカウントを盗めます。硬直的にしすぎれば、正当な所有者は、何年分もの購入履歴、メール、ファイル、ゲーム履歴、ID、サブスクリプション、家族のデータを含むかもしれないアカウントを永久に失いかねません。

これは難しいエンジニアリングの問題です。しかし「難しい問題」であることが、復旧を成功させる最善の道が、社内の偉い人に気づいてもらえるだけの世間の注目を集めることだ、というシステムの言い訳になってはなりません。

Microsoftは最終的に正しいことをした

この続報は、最初の記事とは違う形で締めくくりたいと思います。Microsoftは最終的に問題を解決しました。助けてくれた人たちはプロフェッショナルで、共感的で、有能でした。私の記事を見て、LinkedInで見知らぬ人に返信し、社内でこの件を進めるために個人的に力を貸してくれたMicrosoftの社員に感謝します。証拠を再検討し、息子のアカウントを復旧してくれたエスカレーションチームに感謝します。彼らはそのことで評価されるべきです。

しかし、エスカレーションがうまくいったという事実は、重要なことも示しています。このアカウントは復旧可能だったのです。 Microsoftには、息子が正当な所有者であると判断するのに十分な情報がありました。問題は、その判断ができる手続きの前にケースを届けることでした。

それこそがMicrosoftがまだ直さなければならない部分です。次の親には、バズったブログ記事はないかもしれないからです。そして、子どものアカウントを取り戻すのに、そんなものが必要であってはなりません。

Microsoft a rendu le compte de mon fils. Il n’aurait pas fallu 60 000 vues.

Matt Senter — Wed, 09 Sep 2026 14:17:03 +0000

Le compte est de retour. Le processus de récupération doit encore fonctionner quand personne d’important ne regarde.

Il y a quelques semaines, j’ai raconté ce qui s’est passé après le piratage du compte Microsoft de mon fils. La version courte était laide : un attaquant a pris le contrôle du compte, a changé ses informations de récupération, et le processus de récupération de compte de Microsoft m’a laissé tenter de prouver que le compte de mon propre enfant lui appartenait vraiment. J’ai fourni des preuves abondantes, suivi les instructions que Microsoft m’a données, puis le processus de support a tout simplement disparu.

J’ai raconté cette expérience dans La récupération de compte Microsoft est du théâtre sécuritaire. Cet article a fini par dépasser les 60 000 vues.

Puis quelque chose d’intéressant s’est produit. Quelqu’un d’assez haut placé chez Microsoft a consulté mon profil LinkedIn. Je l’ai remarqué, et le 1er septembre je lui ai envoyé un message pour lui demander directement : Regardez-vous mon profil à cause de mon article de blog ? Il a répondu oui. Ce message a tout changé.

La chronologie raconte l’histoire

J’ai contacté Microsoft pour la première fois au sujet du piratage du compte le 13 août 2026.

Le 14 août, l’équipe de support initiale m’a envoyé ceci :

Si vous répondez à cet e-mail dans les 7 prochains jours avec des informations supplémentaires, je serai ravi de poursuivre mon enquête.

C’est donc exactement ce que j’ai fait. Le 15 août, à peine un jour plus tard, j’ai répondu avec une montagne d’informations et de preuves supplémentaires. Puis plus rien : aucune question de suivi, aucune explication, aucune confirmation que l’enquête s’était poursuivie. L’équipe a tout simplement cessé de communiquer avec moi.

Ce silence a duré jusqu’au 4 septembre, quand j’ai enfin reçu cette réponse :

Cette demande de service a déjà été résolue et clôturée. Nous serons heureux de vous aider pour votre nouvelle demande ; cependant, je ne suis pas en mesure de rouvrir cette demande de service clôturée. Vous devez créer une nouvelle demande de service en contactant le support Microsoft, et quelqu’un se fera un plaisir de vous aider.

C’était stupéfiant. On m’avait explicitement dit que si je répondais dans les sept jours avec plus d’informations, l’enquête continuerait. J’ai répondu en un jour. Au lieu de cela, le dossier a apparemment été clôturé à mon insu, et j’ai été ignoré pendant près de trois semaines avant qu’on me dise de tout recommencer.

J’ai répondu en soulignant la contradiction. Microsoft m’avait demandé plus de preuves, avait promis de poursuivre l’enquête si je les fournissais sous sept jours, les avait reçues en un jour, puis avait discrètement fermé le ticket malgré tout. J’ai demandé pourquoi et je n’ai jamais eu de réponse.

Cette partie de l’histoire reste totalement inacceptable. Les personnes confrontées à un piratage de compte sont déjà dans une situation stressante. Clôturer discrètement une enquête après avoir explicitement dit à quelqu’un qu’il dispose d’un délai pour soumettre d’autres preuves, puis ne pas expliquer ce qui s’est passé, ce n’est pas ainsi qu’un processus de sécurité ou de support client devrait fonctionner.

Pendant ce temps, LinkedIn a mieux fonctionné que le support Microsoft

Alors que l’équipe de support initiale restait silencieuse, j’ai remarqué le 1er septembre qu’un employé de Microsoft assez haut placé dans l’organisation avait consulté mon profil LinkedIn. Vu le moment et l’attention qu’avait reçue l’article original, j’avais une assez bonne idée de la raison. Je lui ai écrit directement pour lui demander s’il regardait mon profil à cause de l’article. Il a répondu le jour même : oui.

Nous avons commencé à communiquer via LinkedIn, et il a été extraordinairement utile. Il m’a mis en relation avec une équipe d’escalade au sein de Microsoft, et le processus de récupération a redémarré. Structurellement, le processus d’escalade n’était pas radicalement différent de ce que j’avais déjà traversé. Ils posaient des questions, je fournissais des preuves, et ils examinaient les informations du compte pour déterminer la propriété légitime.

Mais il y avait une différence énorme : cette fois, on avait le sentiment que quelqu’un évaluait réellement les preuves que je lui donnais. Ils étaient réactifs, communiquaient avec moi, posaient des questions de suivi et semblaient tenir compte de l’historique du compte et des informations que je fournissais, au lieu de traiter le dossier comme une liste de contrôle binaire.

Et le 7 septembre 2026, le compte a été restauré. Six jours après avoir contacté l’employé de Microsoft sur LinkedIn. Vingt-cinq jours après mon premier contact avec le support Microsoft. Youpi !

L’équipe d’escalade a été excellente

Je tiens à être clair sur ce point, car il serait injuste de mettre tout Microsoft dans le même panier. Les personnes qui m’ont finalement aidé ont été formidables. L’employé de Microsoft avec qui je suis entré en contact via LinkedIn a été aimable, réactif et sincèrement désireux de comprendre ce qui s’était passé. L’équipe d’escalade a pris la situation au sérieux et a finalement abouti au bon résultat.

Nous avons même passé du temps à essayer de comprendre comment le compte avait été compromis au départ. Cela reste la plus grande question sans réponse. Comme je suis principalement utilisateur de Mac et que je passe beaucoup moins de temps à administrer des machines Windows, le contact chez Microsoft m’a donné quelques pistes pour examiner l’ordinateur de mon fils. À partir de là, j’ai utilisé ChatGPT pour aller nettement plus loin : examiner la machine Windows, passer en revue les paramètres de sécurité, chercher des mécanismes de persistance, vérifier la présence de logiciels suspects et chercher des preuves que l’ordinateur lui-même avait été compromis.

Jusqu’ici, je n’ai rien trouvé : aucun malware évident, aucun outil d’accès à distance clair, aucune preuve que quelqu’un avait un contrôle persistant de la machine, et rien qui explique proprement le piratage. Cela rend une forme d’ingénierie sociale de plus en plus probable, même si je ne peux toujours pas prouver exactement ce qui s’est passé. Mon fils ne se souvient pas avoir fait quoi que ce soit qui l’explique de façon évidente, et les données de compte disponibles ne m’ont pas donné assez d’informations pour reconstituer l’attaque de manière concluante. Je continue de creuser.

Le compte est de retour. Il est aussi beaucoup plus difficile à voler désormais.

Une fois l’accès récupéré, j’ai considérablement renforcé le compte. Plus important encore, mon fils et moi avons eu une longue conversation très directe sur les arnaques modernes. C’est quelque chose que les parents d’enfants techniquement à l’aise peuvent, je crois, sous-estimer : savoir utiliser des ordinateurs n’est pas la même chose que comprendre les comportements adverses sur internet.

Les enfants passent énormément de temps dans des environnements où des inconnus leur demandent régulièrement de :

Se connecter à des sites web.
Rejoindre des serveurs Discord.
Installer des mods ou des utilitaires.
Scanner des codes QR.
Authentifier des comptes de jeu.
Saisir des codes de vérification.
Suivre des liens envoyés par chat.
Connecter des identités Microsoft, Google, Steam, Xbox, Roblox ou autres à des services tiers.

La plupart de ces interactions sont parfaitement légitimes. Il suffit à un attaquant d’une seule qui ne l’est pas. Nous changeons donc la façon dont l’authentification fonctionne chez nous. Mon fils va désormais utiliser exclusivement un gestionnaire de mots de passe pour ses identifiants. Si un mot de passe n’est pas dans le gestionnaire, il ne devrait pas être en train de le taper. Si le gestionnaire ne reconnaît pas un site comme appartenant à l’identifiant qu’il s’attend à utiliser, cela doit immédiatement être un signal que quelque chose ne va pas.

Cela n’élimine ni le phishing ni l’ingénierie sociale, mais cela réduit fortement la manipulation manuelle des identifiants et notre surface d’attaque. Nous avons également renforcé les mécanismes de récupération et l’authentification partout où c’était possible.

Mais il y a un problème plus grand

Je suis évidemment content du résultat. Mon fils a retrouvé son compte, les membres de l’équipe d’escalade de Microsoft ont été sincèrement utiles, et quelqu’un chez Microsoft s’est suffisamment soucié de la situation pour s’impliquer personnellement. Mais je reviens sans cesse à une question inconfortable : Que se serait-il passé si mon article avait reçu 60 vues au lieu de 60 000 ?

Le processus de support normal :

13 août : je contacte Microsoft.
14 août : Microsoft me demande plus de preuves et dit explicitement qu’il poursuivra l’enquête si je réponds sous sept jours.
15 août : je fournis des preuves supplémentaires abondantes.
15 août au 4 septembre : silence.
4 septembre : Microsoft m’annonce que le dossier a déjà été clôturé et que je dois tout recommencer.

Le processus d’escalade :

1er septembre : je remarque qu’un employé de Microsoft a consulté mon profil LinkedIn et je le contacte.
1er septembre : il répond et commence à me mettre en relation avec les bonnes personnes.
7 septembre : Microsoft restaure le compte.

La voie d’escalade a réglé en six jours ce que le processus de support ordinaire n’a pas réussi à résoudre en plus de trois semaines. C’est ça, la vraie histoire. Il se trouve que j’avais une tribune. L’histoire s’est répandue. Quelqu’un chez Microsoft l’a remarquée, a consulté mon profil LinkedIn, et il se trouve que je l’ai remarqué. Je l’ai contacté, il a répondu, il savait qui contacter en interne, et le compte a fini par être restauré.

C’est un enchaînement d’événements remarquablement spécifique, et rien de tout cela n’aurait dû être nécessaire. Les preuves que j’ai données à l’équipe d’escalade n’étaient pas comme par magie différentes parce qu’un employé de Microsoft avait vu mon article. J’étais toujours le même parent. C’était toujours le même compte. L’historique du compte était toujours le même. Les circonstances du piratage étaient toujours les mêmes. Ce qui a changé, c’est qu’une personne chez Microsoft capable de naviguer dans l’organisation s’est intéressée au dossier.

Cela m’inquiète bien plus que la question de savoir si mon histoire particulière a eu une fin heureuse. Un système de récupération de sécurité doit fonctionner pour la personne qui n’a pas de blog, qui n’a pas 60 000 personnes lisant son histoire, qui ne peut pas trouver un employé de Microsoft sur LinkedIn et qui n’a pas les compétences techniques pour reconstituer des historiques de connexion et des événements de sécurité. Il doit fonctionner quand personne d’important ne regarde.

La récupération de compte fait partie du modèle de sécurité

Ma critique initiale de la récupération de compte Microsoft n’a pas fondamentalement changé. La récupération de compte n’est pas simplement du support client. C’est un système de sécurité. Les entreprises consacrent d’énormes efforts d’ingénierie à protéger la porte d’entrée avec des passkeys, la MFA, l’analyse comportementale, la détection de connexions suspectes, les empreintes d’appareils, le scoring de risque et des systèmes d’authentification de plus en plus sophistiqués. Mais un jour, quelqu’un perd l’accès, et à ce moment-là, le processus de récupération de compte devient de fait le système d’authentification.

Il doit répondre à une question extraordinairement difficile : Qui devrait contrôler ce compte ? Se tromper dans un sens ou dans l’autre est désastreux. Rendez la récupération trop facile et les attaquants peuvent voler des comptes via le support client. Rendez-la trop rigide et les propriétaires légitimes peuvent perdre définitivement des comptes qui contiennent parfois des années d’achats, d’e-mails, de fichiers, d’historique de jeu, d’identités, d’abonnements et de données familiales.

C’est un problème d’ingénierie difficile. Mais « problème difficile » ne peut pas devenir une excuse pour un système où le meilleur chemin vers une récupération réussie consiste à générer assez d’attention publique pour qu’un cadre de l’entreprise vous remarque.

Microsoft a fini par faire ce qu’il fallait

Je veux terminer cette mise à jour différemment de la première. Microsoft a finalement réglé le problème. Les personnes qui m’ont aidé ont été professionnelles, empathiques et efficaces. Je remercie l’employé de Microsoft qui a vu mon article, a répondu à un inconnu sur LinkedIn et a personnellement aidé à faire avancer ce dossier au sein de l’entreprise. Je remercie l’équipe d’escalade qui a réexaminé les preuves et restauré le compte de mon fils. Ils méritent d’en être crédités.

Mais le fait que l’escalade ait fonctionné démontre aussi quelque chose d’important : le compte était récupérable. Microsoft disposait d’assez d’informations pour déterminer que mon fils en était le propriétaire légitime. Le problème était de faire parvenir le dossier devant un processus capable de prendre cette décision.

C’est la partie que Microsoft doit encore corriger, parce que le prochain parent n’aura peut-être pas d’article viral. Et récupérer le compte de son enfant ne devrait pas en exiger un.

Microsoft 归还了我儿子的账户。这本不该需要 6 万次浏览。

Matt Senter — Wed, 09 Sep 2026 14:15:58 +0000

账户回来了。但恢复流程仍然必须在没有重要人物关注的时候也能正常运作。

几周前，我写了儿子的 Microsoft 账户被盗之后发生的事。简短版本很难看：攻击者控制了账户，更改了恢复信息，而 Microsoft 的账户恢复流程让我不得不去证明我自己孩子的账户确实属于他。我提供了大量证据，按照 Microsoft 给出的指示操作，然后支持流程实际上就消失了。

我在《Microsoft 的账户恢复只是安全表演》中写下了那段经历。那篇文章最终获得了超过 6 万次浏览。

接着，有趣的事情发生了。Microsoft 一位职位相当高的人查看了我的 LinkedIn 个人资料。我注意到了，并在 9 月 1 日给他发了一条消息，直接问他：你是因为我的博客文章才来看我的个人资料吗？他说是的。这条消息改变了一切。

时间线说明了一切

我第一次就账户被盗联系 Microsoft 是在 2026 年 8 月 13 日。

8 月 14 日，最初的支持团队给我发来了这样的话：

如果您在接下来的 7 天内回复此邮件并提供更多信息，我将非常乐意继续调查。

于是我照做了。8 月 15 日，也就是仅仅一天之后，我回复了大量的补充信息和证据。之后就再也没有消息了：没有后续提问，没有解释，也没有任何确认调查在继续的回应。团队干脆不再和我沟通了。

这种沉默一直持续到 9 月 4 日，我终于收到了这样的回复：

此服务请求已经处理并关闭。我们很乐意协助您处理新的请求；但是，我无法重新打开此已关闭的服务请求。您需要联系 Microsoft 支持创建一个新的服务请求，会有人乐意为您提供进一步帮助。

这太令人震惊了。他们明确告诉我，只要在七天内回复更多信息，调查就会继续。我在一天内就回复了。结果，案件显然在我不知情的情况下被关闭了，我被晾了将近三周，然后被告知要从头再来。

我回复并指出了这个矛盾。Microsoft 向我索要更多证据，承诺只要在七天内提供就会继续调查，一天内就收到了，却仍然悄悄关闭了工单。我问为什么，从未得到回应。

这部分故事仍然完全不可接受。遭遇账户被盗的人本来就处于压力之下。在明确告诉某人有一个提交更多证据的窗口之后悄悄关闭调查，然后又不解释发生了什么，这不是安全流程或客户支持流程应有的运作方式。

与此同时，LinkedIn 比 Microsoft 支持更管用

在最初的支持团队仍然沉默的时候，我在 9 月 1 日注意到，Microsoft 组织里一位职位相当高的员工查看了我的 LinkedIn 个人资料。考虑到时间点以及原文所获得的关注，我大致能猜到原因。我直接给他发消息，问他是不是因为那篇博客文章才来看我的资料。他当天就回复了：是的。

我们开始通过 LinkedIn 沟通，他给了我极大的帮助。他把我介绍给了 Microsoft 内部的一个升级处理团队，恢复流程重新启动。从结构上看，升级处理流程与我之前经历的并没有天壤之别。他们提问，我提供证据，他们审查账户信息以确定合法所有权。

但有一个巨大的区别：这一次，感觉真的有人在评估我提供的证据。他们回应及时，主动与我沟通，提出后续问题，并且看起来确实考虑了账户的历史和我提供的信息，而不是把这个案子当成一份非黑即白的清单来处理。

然后在 2026 年 9 月 7 日，账户恢复了。距离我在 LinkedIn 上联系那位 Microsoft 员工过去了六天。距离我第一次联系 Microsoft 支持过去了二十五天。太棒了！

升级处理团队非常出色

我想把这一部分说清楚，因为把 Microsoft 的每个人一概而论是不公平的。最终帮助我的人都很棒。我通过 LinkedIn 联系到的那位 Microsoft 员工友善、回应及时，并且真心想弄清楚发生了什么。升级处理团队认真对待了这件事，最终得出了正确的结果。

我们甚至花时间试图弄清楚账户最初是如何被攻破的。这仍然是最大的未解之谜。因为我主要使用 Mac，管理 Windows 机器的时间远没有那么多，这位 Microsoft 联系人给了我一些调查儿子电脑的建议。在此基础上，我用 ChatGPT 做了更深入的排查：检查这台 Windows 机器，审查安全设置，寻找持久化机制，检查可疑软件，并寻找电脑本身被入侵的证据。

到目前为止，我什么都没找到：没有明显的恶意软件，没有明确的远程访问工具，没有证据表明有人持续控制过这台机器，也没有任何能清楚解释这次劫持的东西。这让某种形式的社会工程攻击越来越有可能，尽管我仍然无法证明到底发生了什么。我儿子不记得自己做过任何能明显解释这件事的操作，现有的账户数据也没有给我足够的信息来确凿地还原攻击过程。我还在继续追查。

账户回来了。现在它也难偷得多了。

重新获得访问权限之后，我大幅加固了这个账户。更重要的是，我和儿子进行了一次很长、很直接的关于现代骗局的谈话。我认为技术娴熟的孩子的家长可能会低估这一点：会用电脑，并不等于理解互联网上的对抗性行为。

孩子们花大量时间待在这样的环境里，陌生人经常要求他们：

登录网站。
加入 Discord 服务器。
安装模组或工具。
扫描二维码。
验证游戏账户。
输入验证码。
点击聊天中发来的链接。
把 Microsoft、Google、Steam、Xbox、Roblox 或其他身份关联到第三方服务。

这些互动大多数是完全合法的。攻击者只需要其中一次不是。所以我们正在改变家里的认证方式。我儿子现在将只使用密码管理器来管理他的凭据。如果某个密码不在密码管理器里，他就不应该去输入它。如果密码管理器不认为某个网站属于他打算使用的那条凭据，那就应该立刻被视为出了问题的警告。

这并不能消除钓鱼或社会工程攻击，但它大幅减少了手动处理凭据的次数，缩小了我们的攻击面。我们还在所有可能的地方收紧了恢复机制和身份验证。

但这里有一个更大的问题

我显然对结果很满意。我儿子拿回了账户，Microsoft 升级处理团队的人真心帮了忙，而且 Microsoft 内部有人足够在意这件事，愿意亲自参与。但我一直回到一个令人不安的问题：如果我的博客文章只有 60 次浏览而不是 6 万次，会发生什么？

常规支持流程：

8 月 13 日：我联系 Microsoft。
8 月 14 日：Microsoft 要求我提供更多证据，并明确表示只要我在七天内回复就会继续调查。
8 月 15 日：我提供了大量补充证据。
8 月 15 日至 9 月 4 日：沉默。
9 月 4 日：Microsoft 告诉我案件早已关闭，我需要从头再来。

升级处理流程：

9 月 1 日：我注意到一位 Microsoft 员工查看了我的 LinkedIn 个人资料，并联系了他。
9 月 1 日：他回复了，并开始为我联系合适的人。
9 月 7 日：Microsoft 恢复了账户。

升级路径用六天解决了常规支持流程三周多都没能解决的问题。这才是真正的故事。我碰巧有一个平台。故事传开了。Microsoft 内部有人注意到了，看了我的 LinkedIn 个人资料，而我碰巧注意到了这一点。我联系了他，他回复了，他知道内部该找谁，最终账户得以恢复。

这是一条极其特定的事件链，而这一切本都不应该是必要的。我给升级处理团队的证据，并不会因为一位 Microsoft 员工看过我的博客文章就神奇地变得不同。我还是同一个父亲。还是同一个账户。账户历史还是一样的。劫持的情形还是一样的。变化的只是 Microsoft 内部一个有能力在组织里穿行的人对这个案子产生了兴趣。

比起我这个故事是否有一个圆满的结局，这一点更让我担忧。一个安全恢复系统必须为那些没有博客、没有 6 万人阅读他们的故事、找不到 LinkedIn 上的 Microsoft 员工、也不具备足够技术能力去还原登录历史和安全事件的人服务。它必须在没有重要人物关注的时候也能正常运作。

账户恢复是安全模型的一部分

我对 Microsoft 账户恢复的最初批评在根本上没有改变。账户恢复不仅仅是客户支持。它是一个安全系统。各家公司投入了巨大的工程精力，用通行密钥、多因素认证、行为分析、可疑登录检测、设备指纹、风险评分以及日益复杂的认证系统来守护前门。但终究会有人失去访问权限，而在那一刻，账户恢复流程实际上就变成了认证系统。

它必须回答一个极其困难的问题：谁应该控制这个账户？在任何一个方向上出错都是灾难性的。恢复太容易，攻击者就能通过客户支持窃取账户。恢复太死板，合法所有者就可能永久失去可能包含多年购买记录、邮件、文件、游戏历史、身份、订阅和家庭数据的账户。

这是一个困难的工程问题。但“问题很难”不能成为一个系统的借口，让成功恢复的最佳途径变成制造足够多的公众关注，好让公司里某位高层注意到你。

Microsoft 最终做了正确的事

我想用与第一篇不同的方式结束这次更新。Microsoft 最终解决了问题。帮助我的人专业、有同理心、也很有效率。我感谢那位看到我的文章、在 LinkedIn 上回复了一个陌生人并亲自帮忙在公司内部推进此事的 Microsoft 员工。我感谢重新审查证据并恢复了我儿子账户的升级处理团队。他们值得为此获得肯定。

但升级处理奏效这一事实也说明了一件重要的事：这个账户本来就是可以恢复的。Microsoft 掌握着足够的信息来判定我儿子是合法所有者。问题在于如何让这个案子送到一个有能力做出这种判定的流程面前。

这正是 Microsoft 仍然需要修复的部分，因为下一位家长可能没有一篇爆款博客文章。而找回你孩子的账户，本不应该需要一篇。

Microsoft devolvió la cuenta de mi hijo. No debería haber hecho falta 60.000 visitas.

Matt Senter — Wed, 09 Sep 2026 14:15:20 +0000

La cuenta ha vuelto. El proceso de recuperación todavía tiene que funcionar cuando nadie importante está mirando.

Hace unas semanas escribí sobre lo que ocurrió después de que secuestraran la cuenta de Microsoft de mi hijo. La versión corta era fea: un atacante se hizo con el control de la cuenta, cambió su información de recuperación, y el proceso de recuperación de cuentas de Microsoft me dejó intentando demostrar que la cuenta de mi propio hijo realmente le pertenecía. Aporté pruebas exhaustivas, seguí las instrucciones que Microsoft me dio, y entonces el proceso de soporte, en la práctica, desapareció.

Conté esa experiencia en La recuperación de cuentas de Microsoft es teatro de seguridad. Aquel artículo acabó superando las 60.000 visitas.

Entonces ocurrió algo interesante. Alguien con un cargo bastante alto en Microsoft vio mi perfil de LinkedIn. Me di cuenta, y el 1 de septiembre le envié un mensaje y le pregunté directamente: ¿Estás mirando mi perfil por mi artículo del blog? Dijo que sí. Ese mensaje lo cambió todo.

La cronología cuenta la historia

Contacté por primera vez con Microsoft por el secuestro de la cuenta el 13 de agosto de 2026.

El 14 de agosto, el equipo de soporte original me envió esto:

Si responde a este correo en los próximos 7 días con información adicional, estaré encantado de continuar mi investigación.

Así que hice exactamente eso. El 15 de agosto, apenas un día después, respondí con una montaña de información y pruebas adicionales. Después no supe nada más: ni preguntas de seguimiento, ni explicaciones, ni confirmación de que la investigación hubiera continuado. El equipo simplemente dejó de comunicarse conmigo.

Ese silencio duró hasta el 4 de septiembre, cuando por fin recibí esta respuesta:

Esta solicitud de servicio ya ha sido resuelta y cerrada. Estaremos encantados de ayudarle con su nueva solicitud; sin embargo, no puedo reabrir esta solicitud de servicio cerrada. Debe crear una nueva solicitud de servicio contactando con el soporte de Microsoft, y alguien le atenderá con gusto.

Fue asombroso. Me habían dicho explícitamente que si respondía en un plazo de siete días con más información, la investigación continuaría. Respondí en un día. En cambio, el caso se cerró al parecer sin que yo lo supiera, y me ignoraron durante casi tres semanas antes de decirme que empezara de cero.

Respondí señalando la contradicción. Microsoft me había pedido más pruebas, había prometido seguir investigando si las aportaba en siete días, las recibió en un día, y aun así cerró el ticket en silencio. Pregunté por qué y nunca obtuve respuesta.

Esa parte de la historia sigue siendo completamente inaceptable. Las personas que sufren un secuestro de cuenta ya están en una situación estresante. Cerrar una investigación en silencio después de decirle explícitamente a alguien que tiene un plazo para enviar más pruebas, y luego no explicar qué ocurrió, no es la forma en que debería funcionar un proceso de seguridad o de atención al cliente.

Mientras tanto, LinkedIn funcionó mejor que el soporte de Microsoft

Mientras el equipo de soporte original seguía en silencio, el 1 de septiembre noté que un empleado de Microsoft con un cargo bastante alto en la organización había visto mi perfil de LinkedIn. Dado el momento y la atención que había recibido el artículo original, tenía una buena idea de por qué. Le escribí directamente y le pregunté si estaba mirando mi perfil por el artículo. Respondió ese mismo día: sí.

Empezamos a comunicarnos por LinkedIn, y fue extraordinariamente útil. Me puso en contacto con un equipo de escalado dentro de Microsoft, y el proceso de recuperación volvió a empezar. Estructuralmente, el proceso de escalado no fue muy distinto del que ya había pasado. Hacían preguntas, yo aportaba pruebas, y revisaban la información de la cuenta para determinar quién era el propietario legítimo.

Pero había una diferencia enorme: esta vez, parecía que alguien realmente evaluaba las pruebas que le estaba dando. Fueron receptivos, se comunicaron conmigo, hicieron preguntas de seguimiento y parecían tener en cuenta el historial de la cuenta y la información que aporté, en lugar de tratar el caso como una lista de verificación binaria.

Y el 7 de septiembre de 2026 la cuenta fue restaurada. Seis días después de contactar con el empleado de Microsoft en LinkedIn. Veinticinco días después de contactar por primera vez con el soporte de Microsoft. ¡Yuju!

El equipo de escalado fue excelente

Quiero ser claro en este punto, porque sería injusto meter a todo Microsoft en el mismo saco. Las personas que finalmente me ayudaron fueron estupendas. El empleado de Microsoft con el que conecté a través de LinkedIn fue amable, receptivo y realmente interesado en entender qué había pasado. El equipo de escalado se tomó la situación en serio y al final llegó al resultado correcto.

Incluso dedicamos tiempo a intentar entender cómo se comprometió la cuenta en primer lugar. Esa sigue siendo la mayor pregunta sin respuesta. Como soy principalmente usuario de Mac y no paso ni de lejos tanto tiempo administrando máquinas Windows, el contacto de Microsoft me dio algunas sugerencias para investigar el ordenador de mi hijo. A partir de ahí, usé ChatGPT para profundizar bastante más: examinar la máquina Windows, revisar la configuración de seguridad, buscar mecanismos de persistencia, comprobar si había software sospechoso y buscar pruebas de que el propio ordenador hubiera sido comprometido.

Hasta ahora no he encontrado nada: ni malware evidente, ni una herramienta clara de acceso remoto, ni pruebas de que alguien tuviera control persistente de la máquina, ni nada que explique limpiamente el secuestro. Eso hace cada vez más probable alguna forma de ingeniería social, aunque sigo sin poder demostrar exactamente qué ocurrió. Mi hijo no recuerda haber hecho nada que lo explique de forma obvia, y los datos disponibles de la cuenta no me han dado suficiente información para reconstruir el ataque de manera concluyente. Sigo investigando.

La cuenta ha vuelto. Y ahora es mucho más difícil de robar.

Una vez recuperado el acceso, reforcé la cuenta considerablemente. Más importante aún, mi hijo y yo tuvimos una conversación larga y muy directa sobre las estafas modernas. Esto es algo que creo que los padres de niños con soltura técnica pueden subestimar: saber usar ordenadores no es lo mismo que entender el comportamiento adversario en internet.

Los niños pasan muchísimo tiempo en entornos donde desconocidos les piden habitualmente que:

Inicien sesión en sitios web.
Se unan a servidores de Discord.
Instalen mods o utilidades.
Escaneen códigos QR.
Autentiquen cuentas de juegos.
Introduzcan códigos de verificación.
Sigan enlaces enviados por chat.
Conecten identidades de Microsoft, Google, Steam, Xbox, Roblox u otras a servicios de terceros.

La mayoría de esas interacciones son perfectamente legítimas. A un atacante le basta con una que no lo sea. Así que estamos cambiando cómo funciona la autenticación en nuestra casa. Mi hijo va a usar ahora un gestor de contraseñas de forma exclusiva para sus credenciales. Si una contraseña no está en el gestor, no debería estar escribiéndola. Si el gestor de contraseñas no reconoce un sitio como perteneciente a la credencial que espera usar, eso debería ser de inmediato una señal de que algo va mal.

Eso no elimina el phishing ni la ingeniería social, pero reduce drásticamente la cantidad de manejo manual de credenciales y reduce nuestra superficie de ataque. También hemos reforzado los mecanismos de recuperación y la autenticación siempre que ha sido posible.

Pero aquí hay un problema mayor

Obviamente estoy contento con el resultado. Mi hijo tiene su cuenta de vuelta, las personas del equipo de escalado de Microsoft fueron realmente útiles, y alguien dentro de Microsoft se preocupó lo suficiente por la situación como para implicarse personalmente. Pero no dejo de volver a una pregunta incómoda: ¿Qué habría pasado si mi artículo hubiera tenido 60 visitas en lugar de 60.000?

El proceso de soporte normal:

13 de agosto: contacto con Microsoft.
14 de agosto: Microsoft me pide más pruebas y dice explícitamente que seguirá investigando si respondo en siete días.
15 de agosto: aporto abundantes pruebas adicionales.
15 de agosto a 4 de septiembre: silencio.
4 de septiembre: Microsoft me dice que el caso ya estaba cerrado y que tengo que empezar de cero.

El proceso de escalado:

1 de septiembre: noto que un empleado de Microsoft ha visto mi perfil de LinkedIn y le escribo.
1 de septiembre: responde y empieza a ponerme en contacto con las personas adecuadas.
7 de septiembre: Microsoft restaura la cuenta.

La vía de escalado resolvió en seis días lo que el proceso de soporte ordinario no logró resolver en más de tres semanas. Esa es la verdadera historia. Dio la casualidad de que yo tenía una plataforma. La historia se difundió. Alguien dentro de Microsoft se fijó, miró mi perfil de LinkedIn, y dio la casualidad de que yo lo noté. Le escribí, respondió, sabía a quién contactar internamente, y al final la cuenta fue restaurada.

Es una cadena de acontecimientos notablemente específica, y nada de ello debería haber sido necesario. Las pruebas que di al equipo de escalado no eran mágicamente distintas porque un empleado de Microsoft hubiera visto mi artículo. Yo seguía siendo el mismo padre. Seguía siendo la misma cuenta. El historial de la cuenta seguía siendo el mismo. Las circunstancias del secuestro seguían siendo las mismas. Lo que cambió fue que alguien dentro de Microsoft con capacidad para moverse por la organización se interesó por el caso.

Eso me preocupa mucho más que si mi historia en particular tuvo un final feliz. Un sistema de recuperación de seguridad tiene que funcionar para la persona que no tiene un blog, que no tiene 60.000 personas leyendo su historia, que no puede encontrar a un empleado de Microsoft en LinkedIn y que no tiene la formación técnica para reconstruir historiales de inicio de sesión y eventos de seguridad. Tiene que funcionar cuando nadie importante está mirando.

La recuperación de cuentas forma parte del modelo de seguridad

Mi crítica original a la recuperación de cuentas de Microsoft no ha cambiado en lo fundamental. La recuperación de cuentas no es simple atención al cliente. Es un sistema de seguridad. Las empresas dedican un enorme esfuerzo de ingeniería a proteger la puerta principal con passkeys, MFA, análisis de comportamiento, detección de inicios de sesión sospechosos, huellas de dispositivo, puntuación de riesgo y sistemas de autenticación cada vez más sofisticados. Pero en algún momento alguien pierde el acceso, y en ese instante el proceso de recuperación de cuentas se convierte, en la práctica, en el sistema de autenticación.

Tiene que responder a una pregunta extraordinariamente difícil: ¿Quién debería controlar esta cuenta? Equivocarse en cualquiera de las dos direcciones es desastroso. Si la recuperación es demasiado fácil, los atacantes pueden robar cuentas a través del soporte al cliente. Si es demasiado rígida, los propietarios legítimos pueden perder para siempre cuentas que contienen años de compras, correos, archivos, historial de juegos, identidades, suscripciones y datos familiares.

Es un problema de ingeniería difícil. Pero «problema difícil» no puede convertirse en excusa para un sistema en el que el mejor camino hacia una recuperación exitosa es generar suficiente atención pública para que alguien con peso dentro de la empresa se fije en ti.

Microsoft acabó haciendo lo correcto

Quiero terminar esta actualización de forma distinta a la primera. Microsoft finalmente resolvió el problema. Las personas que me ayudaron fueron profesionales, empáticas y eficaces. Agradezco al empleado de Microsoft que vio mi artículo, respondió a un desconocido en LinkedIn y ayudó personalmente a encauzar esto dentro de la empresa. Agradezco al equipo de escalado que volvió a revisar las pruebas y restauró la cuenta de mi hijo. Merecen reconocimiento por ello.

Pero el hecho de que el escalado funcionara también demuestra algo importante: la cuenta era recuperable. Microsoft tenía información suficiente para determinar que mi hijo era el propietario legítimo. El problema era conseguir que el caso llegara a un proceso capaz de tomar esa decisión.

Esa es la parte que Microsoft todavía tiene que arreglar, porque el siguiente padre puede no tener un artículo viral. Y recuperar la cuenta de tu hijo no debería requerir uno.

Microsoft Gave My Son’s Account Back. It Shouldn’t Have Taken 60,000 Views.

Matt Senter — Tue, 08 Sep 2026 15:43:12 +0000

The account is back. The recovery process still needs to work when nobody important is watching.

A few weeks ago, I wrote about what happened after my son’s Microsoft account was taken over. The short version was ugly: an attacker gained control of the account, changed its recovery information, and Microsoft’s account-recovery process left me trying to prove that my own child’s account actually belonged to him. I provided extensive evidence, followed the instructions Microsoft gave me, and then the support process effectively disappeared.

I wrote about that experience in Microsoft’s Account Recovery Is Security Theater. That post ended up getting more than 60,000 views.

Then something interesting happened. Someone fairly high up at Microsoft viewed my LinkedIn profile. I noticed, and on September 1 I sent him a message and asked him directly: Are you looking at my profile because of my blog post? He said yes. That message changed everything.

The Timeline Tells the Story

I first contacted Microsoft about the account takeover on August 13, 2026.

On August 14, the original support team sent me this:

If you reply to this email within the next 7 days with additional information, I will be more than happy to continue my investigation.

So I did exactly that. On August 15, just one day later, I replied with a mountain of additional information and evidence. Then I heard nothing: no follow-up questions, no explanation, and no acknowledgement that the investigation had continued. The team simply stopped communicating with me.

That silence lasted until September 4, when I finally received this response:

This service request has already been resolved and closed. We are happy to assist you with your new request; however, I am not be able to re-open this closed service request. You need to create a new service request by contacting Microsoft Support, and someone would be happy to assist you further.

That was astonishing. I had been explicitly told that if I responded within seven days with more information, the investigation would continue. I responded within one day. Instead, the case was apparently closed without my knowledge, and I was ghosted for nearly three weeks before being told to start over.

I replied and pointed out the contradiction. Microsoft had asked me for more evidence, promised to continue investigating if I supplied it within seven days, received it within one day, and then quietly closed the ticket anyway. I asked why and never received a response.

That part of this story remains completely unacceptable. People dealing with account takeovers are already in a stressful position. Quietly closing an investigation after explicitly telling someone they have a window to submit more evidence, then failing to explain what happened, is not how a security or customer-support process should operate.

Meanwhile, LinkedIn Worked Better Than Microsoft Support

While the original support team was still silent, I noticed on September 1 that a Microsoft employee fairly high up in the organization had viewed my LinkedIn profile. Given the timing and the attention the original blog post had received, I had a pretty good guess why. I messaged him directly and asked whether he was looking at my profile because of the blog post. He responded that same day: yes.

We started communicating over LinkedIn, and he was extraordinarily helpful. He connected me with an escalation team inside Microsoft, and the recovery process started again. Structurally, the escalation process was not dramatically different from what I had already gone through. They asked questions, I provided evidence, and they reviewed account information to determine legitimate ownership.

But there was one enormous difference: this time, it felt like someone was actually evaluating the evidence I was giving them. They were responsive, communicated with me, asked follow-up questions, and appeared to consider the history of the account and the information I supplied instead of treating the case like a binary checklist.

And on September 7, 2026, the account was restored. Six days after I contacted the Microsoft employee on LinkedIn. Twenty-five days after I first contacted Microsoft support. Weee!

The Escalation Team Was Excellent

I want to be clear about this part, because it would be unfair to paint everyone at Microsoft with the same brush. The people who eventually helped me were great. The Microsoft employee I connected with through LinkedIn was kind, responsive, and genuinely interested in figuring out what had happened. The escalation team treated the situation seriously and ultimately reached the correct outcome.

We even spent time trying to understand how the account was compromised in the first place. That remains the biggest unanswered question. Because I am primarily a Mac user and do not spend nearly as much time administering Windows machines, the Microsoft contact gave me some suggestions for investigating my son’s computer. From there, I used ChatGPT to go considerably deeper: examining the Windows machine, reviewing security settings, looking for persistence mechanisms, checking for suspicious software, and searching for evidence that the computer itself had been compromised.

So far, I have found nothing: no obvious malware, no clear remote-access tool, no evidence that someone had persistent control of the machine, and nothing that neatly explains the takeover. That makes some form of social engineering increasingly likely, although I still cannot prove exactly what happened. My son does not remember doing anything that obviously explains it, and the available account data has not given me enough information to reconstruct the attack conclusively. I am still digging.

The Account Is Back. It Is Also Much Harder to Steal Now.

Once we regained access, I hardened the account considerably. More importantly, my son and I had a long and very direct conversation about modern scams. This is something I think parents of technically sophisticated kids can underestimate: knowing how to use computers is not the same thing as understanding adversarial behavior on the internet.

Kids spend enormous amounts of time in environments where strangers routinely ask them to:

Sign into websites.
Join Discord servers.
Install mods or utilities.
Scan QR codes.
Authenticate game accounts.
Enter verification codes.
Follow links sent through chats.
Connect Microsoft, Google, Steam, Xbox, Roblox, or other identities to third-party services.

Most of those interactions are perfectly legitimate. An attacker only needs one that is not. So we are changing how authentication works in our house. My son is now going to use a password manager exclusively for his credentials. If a password is not in the password manager, he should not be typing it. If the password manager does not recognize a site as belonging to the credential he expects to use, that should immediately be a warning that something is wrong.

That does not eliminate phishing or social engineering, but it dramatically reduces the amount of credential handling that happens manually and reduces our attack surface. We have also tightened recovery mechanisms and authentication wherever possible.

But There Is a Bigger Problem Here

I am obviously happy with the outcome. My son has his account back, the people on Microsoft’s escalation team were genuinely helpful, and someone inside Microsoft cared enough about the situation to personally get involved. But I keep coming back to an uncomfortable question: What would have happened if my blog post had received 60 views instead of 60,000?

The normal support process:

August 13: I contact Microsoft.
August 14: Microsoft asks me for more evidence and explicitly says it will continue investigating if I respond within seven days.
August 15: I provide extensive additional evidence.
August 15–September 4: Silence.
September 4: Microsoft tells me the case had already been closed and I need to start over.

The escalation process:

September 1: I notice a Microsoft employee viewed my LinkedIn profile and contact him.
September 1: He responds and begins connecting me with the right people.
September 7: Microsoft restores the account.

The escalation path fixed in six days what the ordinary support process failed to resolve in more than three weeks. That is the real story here. I happened to have a platform. The story spread. Someone inside Microsoft noticed it, looked at my LinkedIn profile, and I happened to notice that. I contacted him, he responded, he knew whom to contact internally, and eventually the account was restored.

That is a remarkably specific chain of events, and none of it should have been necessary. The evidence I gave the escalation team was not magically different because a Microsoft employee had seen my blog post. I was still the same parent. It was still the same account. The account history was still the same. The circumstances of the takeover were still the same. What changed was that someone inside Microsoft with the ability to navigate the organization became interested in the case.

That concerns me far more than whether my particular story had a happy ending. A security recovery system has to work for the person who does not have a blog, does not have 60,000 people reading their story, cannot find a Microsoft employee on LinkedIn, and is not technical enough to reconstruct login histories and security events. It has to work when nobody important is watching.

Account Recovery Is Part of the Security Model

My original criticism of Microsoft account recovery has not fundamentally changed. Account recovery is not merely customer support. It is a security system. Companies spend enormous amounts of engineering effort protecting the front door with passkeys, MFA, behavioral analysis, suspicious-login detection, device fingerprints, risk scoring, and increasingly sophisticated authentication systems. But eventually somebody loses access, and at that moment the account-recovery process effectively becomes the authentication system.

It has to answer one extraordinarily difficult question: Who should control this account? Getting that wrong in either direction is disastrous. Make recovery too easy and attackers can steal accounts through customer support. Make recovery too rigid and legitimate owners can permanently lose accounts that may contain years of purchases, emails, files, gaming history, identities, subscriptions, and family data.

That is a hard engineering problem. But “hard problem” cannot become an excuse for a system where the best path to successful recovery is generating enough public attention that someone senior inside the company notices you.

Microsoft Did Eventually Do the Right Thing

I want to end this update differently than the first one. Microsoft ultimately fixed the problem. The people who helped me were professional, empathetic, and effective. I appreciate the Microsoft employee who saw my post, responded to a stranger on LinkedIn, and personally helped route this through the company. I appreciate the escalation team that revisited the evidence and restored my son’s account. They deserve credit for that.

But the fact that the escalation worked also demonstrates something important: the account was recoverable. Microsoft had enough information to determine that my son was the legitimate owner. The problem was getting the case in front of a process capable of making that determination.

That is the part Microsoft still needs to fix, because the next parent may not have a viral blog post. And recovering your child’s account should not require one.

Qual será a primeira linguagem de programação nativa para agentes?

Matt Senter — Sat, 05 Sep 2026 14:20:04 +0000

As linguagens de programação foram projetadas para que humanos instruíssem máquinas.

A sintaxe delas reflete essa história. Usamos nomes de variáveis legíveis, palavras-chave memorizáveis, indentação, comentários, arquivos, classes e abstrações que se encaixam em modelos mentais humanos. Erros de compilação são escritos para pessoas. A documentação é organizada para pessoas. Repositórios são estruturados para que pessoas consigam navegar por eles.

Mas as pessoas estão rapidamente deixando de ser responsáveis por escrever o código em si.

Pela Senternet, o estúdio de software onde construo produtos e experimento com desenvolvimento assistido por IA, hoje crio boa parte do meu software dirigindo agentes de codificação. Eu descrevo o que quero, reviso o resultado, testo o comportamento e mando o agente de volta para corrigir o que estiver errado. O agente ainda produz TypeScript, Python, SQL e outros códigos-fonte convencionais, mas isso parece cada vez mais um artefato do ecossistema existente do que uma exigência do trabalho.

O agente escreve código legível por humanos principalmente porque nossos compiladores, bibliotecas, sistemas operacionais, APIs, gerenciadores de pacotes e infraestrutura de implantação esperam isso.

Daí surge uma pergunta da qual não consigo me livrar:

Qual será a primeira linguagem de programação projetada sobretudo para agentes, e não para humanos?

Código legível por humanos está virando um formato intermediário

Na maior parte da história da computação, o código-fonte teve dois públicos.

O primeiro era o computador que iria compilá-lo ou interpretá-lo. O segundo era toda pessoa que talvez precisasse entendê-lo, depurá-lo, mantê-lo ou estendê-lo depois.

Esse segundo público moldou quase toda decisão importante de projeto de linguagem.

Python enfatiza legibilidade. Ruby tenta soar natural e expressivo. TypeScript acrescenta estrutura que ajuda grupos grandes a raciocinar sobre JavaScript. Rust torna explícitas a posse e a segurança de memória, para que quem desenvolve entenda e controle comportamentos que outras linguagens esconderiam.

São recursos valiosos porque, tradicionalmente, o recurso escasso tem sido a atenção humana.

A codificação agêntica muda essa economia.

Um agente não precisa de sintaxe fácil de digitar. Não precisa de palavras-chave fáceis de lembrar. Não precisa de uma linguagem que caiba num semestre ou numa estante de livros. Ele não se cansa ao percorrer um repositório enorme. Consegue processar representações que seriam tediosas, prolixas ou incompreensíveis para uma pessoa.

Ele pode se beneficiar de propriedades bem diferentes:

semântica sem ambiguidade
representação compacta em tokens
dependências e efeitos colaterais explícitos
transformações determinísticas
verificação formal
paralelização automática
diagnósticos legíveis por máquina
procedência embutida
compilação incremental
otimização específica para o hardware
expressão direta de restrições e testes

Quando os agentes se tornarem os autores principais do software, a legibilidade humana deixa de ser a restrição central de projeto.

Ela não fica sem valor. Ela vira uma interface gerada.

A representação nativa da máquina pode virar a fonte da verdade, enquanto os humanos recebem a visão mais útil no momento: uma explicação, um diagrama, uma especificação de comportamento, um relatório de segurança, um plano de testes ou até TypeScript gerado.

Código legível por humanos pode acabar não sendo mais fundamental do que a visão gráfica do esquema de um banco de dados.

Por que os agentes ainda escrevem Python e TypeScript

O maior obstáculo para qualquer linguagem nova não é a sintaxe dela.

É o ecossistema.

Uma linguagem nova precisa de compiladores, depuradores, bibliotecas, documentação, gerenciamento de pacotes, suporte em editores, ferramentas de implantação, análise de segurança e acesso às plataformas existentes. Quem desenvolve reluta em adotar uma linguagem que obrigue a reconstruir tudo o que já tem.

Os agentes não eliminam esse problema, mas podem reduzi-lo drasticamente.

Historicamente, uma linguagem nova também tinha de convencer milhões de pessoas a aprendê-la. Era preciso treinamento, exemplos, livros, apoio da comunidade e confiança suficiente para arriscar carreiras e empresas numa tecnologia desconhecida.

Um agente não precisa de meses de treinamento. Assim que um modelo ou sistema de codificação consegue produzir uma linguagem de forma confiável, todo usuário desse sistema ganha acesso a ela na hora.

Isso remove uma das maiores barreiras históricas à adoção de linguagens.

O problema do ecossistema continua, o que significa que a primeira linguagem agent-native bem-sucedida provavelmente não vai substituir Python, JavaScript, Rust e C++ de uma vez. Ela vai absorvê-los.

Pode compilar via LLVM, mirar WebAssembly, chamar interfaces C existentes, importar pacotes atuais e conversar com APIs estabelecidas. Pode começar como uma representação intermediária escondida sob um agente de codificação, e não como uma linguagem que desenvolvedores escolhem conscientemente.

A transição pode acontecer sem que a maioria perceba.

Partes disso já estão acontecendo

Ainda não existe uma linguagem de programação de uso geral, amplamente adotada, escrita e consumida sobretudo por agentes. Há, porém, vários projetos iniciais nessa direção.

Pesquisadores apresentaram o Quasar em 2025 como linguagem para ações de código executadas por agentes baseados em grandes modelos de linguagem. Agentes costumam gerar Python quando precisam chamar ferramentas ou montar fluxo de controle, mas os pesquisadores argumentaram que o Python carece das características de desempenho, segurança e confiabilidade necessárias para esse trabalho.

O Quasar acrescenta paralelização automática, rastreio de incerteza e mecanismos para validar ações potencialmente inseguras. Na implementação atual, o modelo escreve um subconjunto restrito de Python que é transpilado para Quasar. Os pesquisadores relataram redução de 42 por cento no tempo de execução quando a paralelização era possível e de 52 por cento nas interações de aprovação exigidas quando seus mecanismos de segurança se aplicavam.

O Quasar não é a forma final de uma linguagem agent-native. O agente ainda emite código parecido com Python. Mas ele deixa a pressão evidente: uma linguagem projetada para pessoas pode não ser o melhor modelo de execução para agentes.

Pel é outra linguagem experimental criada especificamente para orquestrar agentes de IA. Usa uma gramática mínima e enfatiza geração restrita, controle de capacidades, comunicação entre agentes, execução segura e paralelização automática.

Pel é influenciada por linguagens como Lisp, Elixir, Gleam e Haskell, mas seu projeto assume que a facilidade de geração confiável por um modelo é, ela própria, um recurso da linguagem.

Essa é uma mudança significativa de prioridades. Projetistas tradicionais perguntam se a sintaxe é compreensível para uma pessoa. Projetistas de linguagens agent-native talvez perguntem se um modelo consegue gerá-la de forma consistente, validá-la mecanicamente e se recuperar de erros sem intervenção humana.

Agentes de codificação também começam a mostrar que não precisam aprender linguagens desconhecidas do jeito que humanos aprendem.

Num estudo de 2026 sobre agentes de codificação lidando com linguagens esotéricas, os agentes de ponta frequentemente escreviam programas em Python que geravam e depuravam o código-alvo desconhecido. Quando os pesquisadores proibiram essa estratégia de metaprogramação, o desempenho caiu bastante.

Essa é uma forma primitiva, mas importante, do futuro que estou descrevendo.

Um agente consegue inferir uma representação-alvo, construir um gerador para ela, testar o resultado e revisar o gerador. Ele não precisa entender nem manter o código-alvo no sentido humano. A linguagem-alvo é apenas mais uma representação de máquina que ele pode manipular.

A primeira linguagem agent-native pode não parecer uma linguagem

Quando as pessoas imaginam uma nova linguagem de programação, geralmente imaginam uma nova sintaxe.

Essa pode ser a parte menos importante.

Uma linguagem agent-native poderia ser uma representação estruturada de:

comportamento desejado
interfaces
restrições
permissões
invariantes
testes
limites de recursos
metas de desempenho
políticas de segurança
modos de falha aceitáveis

O agente de codificação e o compilador poderiam decidir juntos como esses requisitos devem ser implementados.

Para uma carga de trabalho, o resultado pode ser código de máquina nativo. Para outra, WebAssembly. Para outra, um plano de consulta de banco, um kernel de GPU, uma função serverless ou uma composição de serviços existentes.

Pode não haver arquivo-fonte permanente correspondente à implementação.

O artefato durável seria a intenção e a evidência de que a implementação a satisfaz.

Isso sugere uma progressão em três estágios.

Estágio um: agentes escrevem linguagens de programação humanas

É onde estamos agora. Agentes produzem código que parece algo que um desenvolvedor humano poderia ter escrito.

Estágio dois: agentes escrevem representações intermediárias voltadas à máquina

Humanos revisam principalmente comportamento, testes, especificações, explicações geradas e mudanças de capacidades. A implementação subjacente perde importância na revisão de rotina.

Estágio três: agentes geram sistemas executáveis diretamente

A fonte da verdade passa a ser um conjunto de intenção, políticas, interfaces, restrições e evidências de verificação. O agente gera e regenera implementações executáveis conforme a necessidade.

Nesse ponto, perguntar em que linguagem uma aplicação está «escrita» pode deixar de fazer muito sentido.

Legível por humanos não significa auditável por humanos

O argumento mais forte contra esse futuro é que o código-fonte não serve apenas para escrever software.

Ele também serve para depurar, auditar, governar, revisar segurança, manter e responsabilizar.

Não dá para operar com segurança sistemas importantes cujo comportamento ninguém consegue inspecionar.

Mas código-fonte legível já é um substituto fraco para entendimento real. Uma aplicação moderna grande pode ter milhões de linhas de código próprio e depender de outros milhões via pacotes, arquivos gerados, serviços de nuvem, sistemas operacionais e firmware. Quase ninguém entende o sistema inteiro.

O código pode ser legível sem que o sistema seja compreensível.

Um sistema agent-native precisaria oferecer formas de inspeção mais fortes do que uma pilha de arquivos-fonte. Ele poderia gerar:

explicações de comportamentos específicos
mapas de movimentação de dados
provas de propriedades importantes
relatórios de permissões e capacidades
históricos de dependências
simulações de mudanças propostas
testes executáveis
registros do porquê de cada decisão
implementações legíveis por humanos quando necessário

A meta não deveria ser preservar código legível a qualquer custo.

A meta deveria ser preservar o controle humano.

Não são a mesma coisa.

O custo ambiental do código amigável para humanos

Há outra razão pela qual os agentes podem acabar indo além das linguagens de hoje: energia.

Um estudo de 2017 sobre eficiência energética em 27 linguagens de programação, muito citado, comparou tempo de execução, uso de memória e consumo de energia em dez problemas de referência.

Nos resultados normalizados, o Python consumiu cerca de 76 vezes mais energia que o C e exigiu cerca de 72 vezes mais tempo de execução. O Python ficou perto do fim da lista em eficiência energética.

Esse resultado costuma ser simplificado na afirmação de que o Python é uma das piores linguagens para o meio ambiente.

A realidade é mais complicada.

Uma reanálise de 2024 da eficiência energética de linguagens de programação concluiu que essas comparações podem confundir a linguagem com sua implementação, com a qualidade do programa de benchmark, com o número de núcleos ativos, com o comportamento das bibliotecas, com a atividade de memória e com outros detalhes de execução.

Depois de controlar esses fatores, os pesquisadores concluíram que a implementação da linguagem não teve efeito significativo sobre o consumo de energia além do tempo de execução.

A questão central não era que a sintaxe de uma linguagem de alguma forma consumisse mais eletricidade. Programas mais lentos geralmente usavam mais energia total porque o hardware ficava ativo por mais tempo.

Essa distinção não faz o problema sumir.

O Python padrão costuma ser bem mais lento que código compilado otimizado em trabalho computacionalmente intenso. Um programa que leva muito mais tempo para fazer a mesma coisa pode consumir muito mais energia, mesmo que o processador consuma potência num ritmo parecido enquanto executa.

A boa notícia é que a ineficiência não é inevitável.

Um estudo de 2025 sobre implementações compiladas de Python comparou o CPython com vários sistemas de compilação e otimização, incluindo PyPy, Numba, Codon, Cython, Nuitka, Mypyc e Pyston-lite.

Os pesquisadores descobriram que a compilação podia melhorar bastante tempo de execução, uso de memória e consumo de energia. Codon, PyPy e Numba produziram ganhos de velocidade e energia acima de 90 por cento em algumas das cargas testadas.

A conclusão mais precisa não é que o Python seja inerentemente destrutivo para o meio ambiente.

É que os humanos muitas vezes escolheram linguagens com base na produtividade humana, tratando a eficiência de execução como preocupação secundária.

O Python é bem-sucedido porque é legível, expressivo, tolerante e apoiado por um ecossistema enorme. Em muitas organizações, poupar tempo de quem desenvolve compensa gastar mais tempo de computação.

Os agentes não enfrentam o mesmo dilema.

Um agente de codificação não precisa de sintaxe amigável para continuar produtivo. Não precisa de uma linguagem fácil de ensinar, digitar ou lembrar. Ele poderia gerar uma representação escolhida para a carga específica, compilá-la para o hardware disponível, medir o resultado e trocá-la quando surgisse uma implementação mais eficiente.

O consumo de energia poderia virar uma propriedade de primeira classe da programação, em vez de uma otimização tentada depois que o software já foi escrito.

Isso importa porque os agentes não vão simplesmente substituir código humano linha a linha. É provável que aumentem o volume total de software produzido e executado.

Agentes podem gerar dezenas de implementações, rodar milhares de testes, criar programas descartáveis para tarefas isoladas e regenerar continuamente sistemas em funcionamento. A ineficiência que era tolerável quando o software era produzido devagar por humanos fica mais consequente quando máquinas podem gerar código quase ilimitado.

Por isso a primeira linguagem agent-native pode otimizar mais do que correção e velocidade. Ela poderia considerar:

consumo total de energia
frequência esperada de execução
processadores e aceleradores disponíveis
movimentação de memória
custo de compilação
a intensidade de carbono da eletricidade disponível
se uma carga pode ser adiada ou realocada
se uma implementação vai rodar uma vez ou bilhões de vezes

Pode não existir uma representação universalmente ótima.

Uma conversão de dados única pode favorecer o menor custo de compilação. Um serviço que deve atender bilhões de requisições pode justificar otimização nativa agressiva. Uma carga rodando num dispositivo a bateria pode priorizar energia sobre latência. Um job num data center poderia ser agendado conforme a disponibilidade de energia de menor carbono.

Um agente poderia tomar essas decisões automaticamente.

Talvez o erro ambiental não fosse deixar agentes escreverem código ilegível. Fosse obrigá-los a continuar escrevendo Python só porque humanos gostam de ler.

O que será do programador?

Nada disso significa que humanos param de construir software.

Significa que nosso trabalho sobe de nível.

Em vez de gastar a maior parte do tempo descrevendo passos de implementação numa sintaxe pensada para compiladores, vamos gastar mais tempo definindo:

o que o sistema deve realizar
o que ele nunca pode fazer
quais trade-offs são aceitáveis
quem pode acessar o quê
como o sucesso é medido
como as falhas devem ser tratadas
que evidências são exigidas antes da implantação

Isso ainda é programar.

De muitas formas, é programar mais diretamente do que traduzir manualmente essas decisões em laços, classes, funções e arquivos de configuração.

O papel de quem programa passa a ser menos produzir código-fonte e mais estabelecer intenção, restrições, arquitetura e julgamento. É mais uma razão pela qual eu sempre volto à ideia de que bom gosto é o gargalo assim que construir fica barato.

A parte difícil do desenvolvimento de software nunca foi digitar a sintaxe. A parte difícil era decidir o que deveria acontecer.

Os agentes estão removendo a camada de tradução.

Quem vai criá-la?

A primeira linguagem verdadeiramente agent-native talvez não seja lançada numa conferência de desenvolvedores.

Pode não ter um nome esperto, uma especificação pública nem uma comunidade debatendo sua sintaxe.

Ela pode surgir silenciosamente dentro de uma plataforma de agentes, como representação intermediária privada usada para planejar, gerar, verificar, otimizar e compilar software. Pode inicialmente mirar linguagens convencionais e cadeias de ferramentas existentes e, aos poucos, dispensar mais delas.

Quando os humanos a reconhecerem como linguagem de programação, os agentes talvez já estejam usando-a para escrever uma parcela relevante do software do mundo.

A vencedora não será necessariamente a linguagem que os humanos mais gostam de ler.

Será a representação que os agentes conseguirem usar para produzir os sistemas mais confiáveis, seguros, eficientes e verificáveis, ainda dando aos humanos controle significativo sobre o resultado.

Linguagens de programação foram inventadas para que humanos pudessem dizer aos computadores o que fazer.

A próxima pode ser inventada para que os computadores digam a si mesmos.

最初のエージェントネイティブなプログラミング言語は何になるか？

Matt Senter — Sat, 05 Sep 2026 14:19:27 +0000

プログラミング言語は、人間が機械に指示を与えるために設計された。

その構文には、その歴史が刻まれている。私たちは読みやすい変数名、覚えやすいキーワード、インデント、コメント、ファイル、クラス、そして人間の心的モデルに合う抽象を使う。コンパイラのエラーは人に向けて書かれている。ドキュメントは人のために編まれている。ソースリポジトリは、人がたどれるように構成されている。

だが人間は、実際のコードを書く役目から急速に退きつつある。

私が製品を作り、AI 支援の開発を試しているソフトウェアスタジオ Senternet では、いまや自分のソフトウェアの多くを、コーディングエージェントに指示することで作っている。欲しいものを述べ、結果を確認し、挙動を試し、まずいところは直させるためにエージェントへ差し戻す。エージェントはいまも TypeScript、Python、SQL といった従来のソースコードを出力するが、それはますます、この仕事に必要だからではなく、既存の生態系の名残であるように感じられてくる。

エージェントが人間に読めるコードを書いているのは、主として、私たちのコンパイラ、ライブラリ、OS、API、パッケージマネージャ、デプロイ基盤がそれを期待しているからだ。

そこから、頭を離れない問いが浮かぶ。

人間ではなくエージェントのために設計された最初のプログラミング言語は、どんなものになるのか。

人間に読めるコードは中間形式になりつつある

コンピューティングの歴史のほとんどにおいて、ソースコードには二つの読み手がいた。

一つは、それをコンパイルないし解釈する計算機。もう一つは、のちにそれを理解し、デバッグし、保守し、拡張する必要が生じるかもしれないすべての人間である。

この二つ目の読み手が、言語設計の主要な判断のほとんどを形づくってきた。

Python は読みやすさを重んじる。Ruby は自然で表現力豊かであろうとする。TypeScript は、大人数が JavaScript について考えを整理できるように構造を加える。Rust は所有権とメモリ安全性を明示し、他の言語なら隠してしまう挙動を開発者が理解し制御できるようにする。

これらが価値ある特徴なのは、稀少な資源が伝統的に人間の注意だったからだ。

エージェント的なコーディングは、その経済を変える。

エージェントは打ちやすい構文を必要としない。覚えやすいキーワードも要らない。一学期で教えられる言語も、本棚一つで説明できる言語も要らない。巨大なリポジトリを渡り歩いても疲れない。人にとっては退屈で、冗長で、理解しがたい表現でも処理できる。

エージェントが恩恵を受けるのは、まったく別の性質かもしれない。

曖昧さのない意味論
コンパクトなトークン表現
明示された依存関係と副作用
決定的な変換
形式検証
自動並列化
機械可読な診断
組み込みの来歴
インクリメンタルなコンパイル
ハードウェアに特化した最適化
制約とテストの直接的な表現

エージェントがソフトウェアの主たる書き手になれば、人間にとっての読みやすさは設計上の中心的制約ではなくなる。

無価値になるのではない。生成されるインターフェースになるのだ。

機械にとって自然な表現が真実の源となり、人間はその時々でいちばん役に立つ形の眺めを受け取る。説明でも、図でも、振る舞いの仕様でも、セキュリティ報告でも、テスト計画でも、あるいは生成された TypeScript でもいい。

人間に読めるコードは、いずれデータベーススキーマのグラフィカルな表示以上に根源的なものではなくなるかもしれない。

なぜエージェントはいまも Python と TypeScript を書くのか

新しい言語にとって最大の障害は、その構文ではない。

生態系である。

新しい言語には、コンパイラ、デバッガ、ライブラリ、ドキュメント、パッケージ管理、エディタ対応、デプロイの道具立て、セキュリティ解析、そして既存プラットフォームへの接続が要る。開発者は、いま持っているものをすべて作り直させる言語を採用したがらない。

エージェントはこの問題を消しはしないが、劇的に小さくするかもしれない。

歴史的に、新しい言語は何百万もの人にそれを学ぶよう説得しなければならなかった。開発者には訓練、実例、書籍、コミュニティの支え、そして未知の技術に自分のキャリアと会社を賭けるだけの確信が要った。

エージェントに数か月の訓練は要らない。あるモデルなりコーディングシステムなりが、ある言語を確実に生成できるようになれば、そのシステムの利用者は全員、ただちにその言語を手にする。

これは、言語の普及を阻んできた歴史的な最大級の壁の一つを取り除く。

生態系の問題は残る。つまり最初に成功するエージェント・ネイティブ言語は、おそらく Python、JavaScript、Rust、C++ を一挙に置き換えたりはしない。それらを吸収するのだ。

LLVM を通じてコンパイルし、WebAssembly を標的にし、既存の C インターフェースを呼び、いまのパッケージを取り込み、確立された API と話すかもしれない。開発者が意識して選ぶ言語としてではなく、コーディングエージェントの下に隠れた中間表現として始まるかもしれない。

その移行は、ほとんどの人が気づかないうちに起こりうる。

その一部はすでに起きている

主にエージェントによって書かれ、消費される、広く採用された汎用プログラミング言語は、まだ存在しない。だが、その方向へ動く初期のプロジェクトはいくつもある。

研究者たちは 2025 年、大規模言語モデルのエージェントが行うコードアクションのための言語として Quasar を発表した。エージェントはツールを呼んだり制御フローを組んだりする際、たいてい Python を生成する。しかし研究者たちは、この仕事に必要な性能・安全性・信頼性の特徴を Python は欠いていると論じた。

Quasar は自動並列化、不確実性の追跡、そして危険になりうる操作を検証する仕組みを加える。現在の実装では、モデルは制限された Python の部分集合を書き、それが Quasar へトランスパイルされる。研究者は、並列化が可能な場合に実行時間が 42 パーセント短縮され、そのセキュリティ機構が働く場合に必要な承認のやり取りが 52 パーセント減ったと報告している。

Quasar はエージェント・ネイティブ言語の最終形ではない。エージェントはいまも Python 風のコードを吐く。だが圧力のありかははっきり示している。人のために設計された言語が、エージェントにとって最良の実行モデルとは限らないのだ。

Pel は、AI エージェントのオーケストレーションのために作られたもう一つの実験的な言語である。最小限の文法を用い、制約付き生成、能力の制御、エージェント間通信、安全な実行、自動並列化に重きを置く。

Pel は Lisp、Elixir、Gleam、Haskell といった言語の影響を受けているが、その設計は、モデルが確実に生成しやすいということ自体が言語の機能である、という前提に立つ。

これは優先順位の意味ある転換だ。従来の言語設計者は、その構文が人に分かりやすいかを問う。エージェント・ネイティブ言語の設計者はおそらく、モデルがそれを一貫して生成でき、機械的に検証でき、人手を介さず誤りから立ち直れるかを問うだろう。

コーディングエージェントはまた、なじみのない言語を人間のように学ぶ必要がないことを示しはじめている。

エソテリックなプログラミング言語を扱うコーディングエージェントに関する 2026 年の研究では、先端のエージェントはしばしば、見慣れない対象コードを生成しデバッグするための Python プログラムを書いた。研究者がこのメタプログラミング戦略を禁じると、性能は大きく落ちた。

それは、私が描いている未来の原始的だが重要な一形態である。

エージェントは目標となる表現を推し量り、そのための生成器を作り、結果を試し、生成器を直せる。人間的な意味で対象コードを理解したり保守したりする必要はない。対象言語は、操作できるもう一つの機械表現にすぎないのだ。

最初のエージェント・ネイティブ言語は、言語に見えないかもしれない

新しいプログラミング言語を思い描くとき、人はたいてい新しい構文を思い描く。

それはおそらく、いちばん重要でない部分だ。

エージェント・ネイティブ言語は、次のものの構造化された表現でありうる。

望ましい振る舞い
インターフェース
制約
権限
不変条件
テスト
資源の上限
性能目標
セキュリティ方針
許容できる失敗の様式

それらの要件をどう実装すべきかは、コーディングエージェントとコンパイラが共同で決めればよい。

あるワークロードでは結果がネイティブの機械語になるかもしれない。別のものでは WebAssembly かもしれない。さらに別のものでは、データベースのクエリプラン、GPU カーネル、サーバーレス関数、あるいは既存サービスの組み合わせかもしれない。

実装に対応する恒久的なソースファイルは、存在しないかもしれない。

残る成果物は、意図と、その意図を実装が満たしているという証拠になるだろう。

ここには三段階の進み方が見える。

第一段階: エージェントが人間のプログラミング言語を書く

いま私たちがいるのがここだ。エージェントは、人間の開発者が書いたかもしれないような見た目のコードを産み出す。

第二段階: エージェントが機械向けの中間表現を書く

人間が主に見るのは、振る舞い、テスト、仕様、生成された説明、そして能力の変化である。日常的なレビューにおいて、下層の実装は重要でなくなっていく。

第三段階: エージェントが実行可能なシステムを直接生成する

真実の源は、意図、方針、インターフェース、制約、検証の証拠の集まりになる。エージェントは必要に応じて、実行可能な実装を生成し、また生成し直す。

その段階に至れば、あるアプリケーションが「何の言語で書かれているか」と問うことは、あまり意味をなさなくなるかもしれない。

人間に読めることは、人間に監査できることではない

この未来に対する最も強い反論は、ソースコードはソフトウェアを書くためだけに使われるのではない、というものだ。

それはデバッグ、監査、統治、セキュリティレビュー、保守、そして説明責任にも使われる。

誰も振る舞いを検分できない重要なシステムを、安全に運用することはできない。

だが読めるソースコードは、実際の理解の代用としてすでに心もとない。大規模な現代のアプリケーションは、自前のコードだけで数百万行に達し、パッケージ、生成ファイル、クラウドサービス、OS、ファームウェアを通じてさらに数百万行に依存している。システム全体を理解している者は、ほとんどいない。

コードが読めても、システムが分かるとは限らない。

エージェント・ネイティブなシステムは、ソースファイルの山より強力な検分の手段を用意する必要がある。たとえばこうしたものを生成できるだろう。

特定の振る舞いについての説明
データの流れの地図
重要な性質の証明
権限と能力の報告
依存関係の履歴
変更案のシミュレーション
実行可能なテスト
なぜその判断をしたのかの記録
必要なときには人間に読める実装

目標は、何が何でも読めるコードを守ることではないはずだ。

目標は、人間の制御を守ることであるはずだ。

この二つは同じではない。

人に優しいコードの環境的コスト

エージェントがいずれ今日のプログラミング言語を越えていくかもしれない、もう一つの理由がある。エネルギーだ。

広く引用される 27 のプログラミング言語のエネルギー効率に関する 2017 年の研究は、十のベンチマーク問題について実行時間、メモリ使用量、消費電力を比較した。

その正規化された結果では、Python は C のおよそ 76 倍のエネルギーを消費し、実行時間はおよそ 72 倍を要した。エネルギー効率において、Python は試験された言語のなかで下位に位置した。

この結果はしばしば、Python は環境にとって最悪のプログラミング言語の一つだ、という主張へと単純化されてきた。

実際はもっと込み入っている。

プログラミング言語のエネルギー効率に関する 2024 年の再分析は、こうした比較が、言語そのものと、その実装、ベンチマークプログラムの質、稼働しているコア数、ライブラリの挙動、メモリ活動、その他の実行上の細部とを混同しうることを見いだした。

それらの要因を統制したのち、研究者たちは、プログラミング言語の実装は実行時間を超えてエネルギー消費に有意な影響を与えていない、と結論づけた。

中心的な問題は、ある言語の構文がなぜか多くの電力を食う、ということではなかった。遅いプログラムは概して総エネルギーを多く使う。ハードウェアが長く動き続けるからだ。

この区別は問題を消し去りはしない。

計算量の多い仕事では、標準の Python は最適化されたコンパイル済みコードよりずっと遅いことが多い。同じ仕事に桁違いに長くかかるプログラムは、実行中のプロセッサの消費電力が同程度でも、桁違いに多くのエネルギーを使いうる。

よい知らせは、その非効率が避けがたいものではないということだ。

コンパイルされた Python 実装に関する 2025 年の研究は、CPython を PyPy、Numba、Codon、Cython、Nuitka、Mypyc、Pyston-lite といった複数のコンパイル・最適化系と比較した。

研究者たちは、コンパイルが実行時間、メモリ使用量、消費電力を大きく改善しうることを見いだした。試験された一部のワークロードでは、Codon、PyPy、Numba が 90 パーセントを超える速度とエネルギーの改善をもたらした。

より正確な結論は、Python が本質的に環境破壊的だ、ということではない。

人間はしばしば、人間の生産性を基準にプログラミング言語を選び、実行効率を二の次に扱ってきた、ということだ。

Python が成功しているのは、読みやすく、表現力があり、寛容で、巨大な生態系に支えられているからだ。多くの組織では、開発者の時間を節約することが、追加の計算時間を費やすに値する。

エージェントは同じ二律背反に直面しない。

コーディングエージェントは、生産的であり続けるために親切な構文を必要としない。教えやすく、打ちやすく、覚えやすい言語も要らない。特定のワークロードのために選んだ表現を生成し、手元のハードウェア向けにコンパイルし、結果を測り、より効率のよい実装が現れたら差し替えればいい。

エネルギー消費は、ソフトウェアを書き終えてから試みる最適化ではなく、プログラミングの第一級の性質になりうる。

これが重要なのは、エージェントが人の書いたコードを一行ずつ置き換えていくだけではないからだ。おそらく、生産され実行されるソフトウェアの総量そのものを押し上げる。

エージェントは何十もの実装を生成し、何千ものテストを走らせ、個別の作業のために使い捨てのプログラムを作り、動いているシステムを絶えず作り直せる。人間がゆっくり作っていた時代には許容できた非効率も、機械がほぼ無制限にコードを生成できるようになれば、重みを増す。

だから最初のエージェント・ネイティブ言語は、正しさと速さだけを最適化するのではないかもしれない。次のようなことも考慮しうる。

総エネルギー消費
想定される実行頻度
利用できるプロセッサとアクセラレータ
メモリの移動
コンパイルのコスト
利用できる電力の炭素強度
そのワークロードを遅らせたり移したりできるか
その実装が一度だけ動くのか、何十億回も動くのか

普遍的に最適な表現など存在しないかもしれない。

一度きりのデータ変換なら、コンパイルの手間が最小であることが好ましいだろう。何十億ものリクエストを捌く前提のサービスなら、攻めたネイティブ最適化に見合うだろう。バッテリー駆動の端末で動く仕事なら、遅延よりエネルギーを優先するかもしれない。データセンターで走るジョブなら、より低炭素な電力が使える時間帯に合わせて組めるだろう。

こうした判断を、エージェントは自動で下せる。

おそらく環境上の過ちは、エージェントに読めないコードを書かせることではない。人間が読むのを好むというだけの理由で、Python を書き続けさせることのほうだ。

プログラマはどうなるのか

以上のどれも、人間がソフトウェアを作らなくなることを意味しない。

私たちの仕事が上へ移る、ということだ。

コンパイラのために設計された構文で実装手順を記述することに大半の時間を費やす代わりに、こういったことを定めるのにより多くの時間を使うようになる。

そのシステムが何を成し遂げるべきか
何を決してしてはならないか
どのトレードオフなら受け入れられるか
誰が何にアクセスできるか
成功をどう測るか
失敗をどう扱うべきか
本番投入の前にどんな証拠が要るか

それもまたプログラミングである。

多くの意味でそれは、こうした判断をループやクラスや関数や設定ファイルへ手で翻訳するよりも、直接的なプログラミングだ。

プログラマの役割は、ソースコードを産み出すことより、意図と制約と設計と判断を打ち立てることに寄っていく。作ること自体が安くなったときセンスこそがボトルネックになる、という考えに私が何度も立ち返るのは、それも理由の一つだ。

ソフトウェア開発の難所は、構文を打ち込むことでは一度もなかった。難所は、何が起こるべきかを決めることだった。

エージェントは、その翻訳の層を取り除きつつある。

それは誰が作るのか

最初の真にエージェント・ネイティブな言語は、開発者向けカンファレンスで発表されはしないかもしれない。

気の利いた名前も、公開された仕様も、構文を論じるコミュニティも持たないかもしれない。

それは、ソフトウェアを計画し、生成し、検証し、最適化し、コンパイルするために使われる私的な中間表現として、あるエージェント基盤の内側に静かに現れるかもしれない。はじめは従来の言語と既存のツールチェーンを標的にし、そこから少しずつ、それらを迂回していくのかもしれない。

人間がそれをプログラミング言語だと認識するころには、エージェントはすでにそれを使って、世界のソフトウェアのかなりの部分を書いているかもしれない。

勝つのは、人間が読んでいちばん楽しい言語とは限らない。

最も信頼でき、安全で、効率がよく、検証可能なシステムをエージェントが産み出せて、なおかつ人間が結果に対する実質的な制御を保てる。そういう表現である。

プログラミング言語は、人間が計算機に何をすべきか伝えられるように発明された。

次のそれは、計算機が自分自身に伝えられるように発明されるのかもしれない。

Expansão de escopo na era da IA

Matt Senter — Fri, 04 Sep 2026 14:35:05 +0000

Encontrei uma nova maneira de evitar a coisa mais importante que eu deveria estar fazendo: melhorar o produto.

Não melhorar no sentido de lançá-lo, achar um cliente ou provar a ideia. Melhorar de mil jeitos minúsculos. Apertar o espaçamento. Reescrever o estado vazio. Adicionar um atalho de teclado. Ajustar a animação. Pedir a um agente de IA mais uma melhoria de bom gosto, ver aparecer um minuto depois e já identificar a próxima.

Cada ajuste é rápido. Cada ajuste parece produtivo. Juntos, conseguem me manter fora do caminho crítico por um tempo espantoso.

O aumento de escopo antes vinha com atrito

Aumento de escopo não é novidade. Produtos sempre acumularam requisitos. A versão antiga só era mais fácil de ver chegando. Uma funcionalidade nova significava uma reunião, uma estimativa, um chamado, um desenvolvedor, um ciclo de testes e mais uma conversa desconfortável sobre o prazo. O custo se anunciava sozinho.

A IA removeu boa parte desse atrito. Agora uma funcionalidade nova pode começar com seis palavras digitadas num prompt. Pode não haver estimativa nem mais ninguém na sala para perguntar se aquilo cabe. No tempo em que eu teria terminado de explicar a ideia a um colega, a primeira versão já está rodando.

É uma vantagem incrível. Também é uma armadilha. Quando o custo de começar parece zero, o velho instinto de parar e justificar simplesmente não dispara.

A frase perigosa é «já que estou aqui»

O padrão raramente começa com uma ideia obviamente ruim. Começa com algo razoável. Já que estou consertando este formulário, deveria melhorar a validação. Já que estou no código de validação, deveria escrever mensagens de erro melhores. Os erros ficariam bem com ícones. Os ícones expõem uma inconsistência no design system. Agora estou reorganizando componentes de que nenhum usuário jamais reclamou.

Cada decisão faz sentido isolada. É isso que torna o padrão difícil de resistir. Não há uma única escolha imprudente para apontar, apenas uma corrente de pequenas escolhas úteis que leva o projeto, em silêncio, para um lugar aonde ele não precisava ir.

A mesma coisa acontece fora do produto. É fácil passar uma tarde aperfeiçoando um logotipo, automatizando um relatório, reorganizando o CRM ou gerando vinte versões de uma landing page. O trabalho pode ser bom. Pode até ser necessário algum dia. Mas se o negócio precisa hoje de uma conversa com um cliente, nada disso é o trabalho.

Execução barata não torna a atenção barata

A IA baixou o custo de um ajuste. Não baixou o custo de escolher o ajuste, revisá-lo, encaixá-lo no resto do produto e carregar a complexidade extra depois. Acima de tudo, não tornou minha atenção infinita.

Esse é o custo que costumo ignorar. Uma mudança de dois minutos pode abrir um ramo de vinte minutos no meu raciocínio. Ela muda o que estou olhando e que problema meu cérebro está tentando resolver. Faça isso cinquenta vezes e o dia some, mesmo que o agente tenha escrito cada linha de código.

A velocidade piora isso de um jeito surpreendentemente agradável. Trabalho lento cria pontos naturais de parada. Trabalho rápido cria embalo. A recompensa instantânea de ver cada pedido concluído faz o próximo parecer quase de graça, como puxar a alavanca de um caça-níquel que sempre paga em interface polida. Não estou travado nem frustrado. Estou me divertindo, o que dificulta perceber que saí do rumo.

Trabalho divertido e trabalho importante não são a mesma lista

Eu amo a parte de construir. Suspeito que a maioria de quem constrói também ame. É concreta, responsiva e satisfatória. Você faz um pedido e a coisa muda na sua frente. O caminho crítico costuma ser bem menos divertido: decidir o que o produto é, lançá-lo antes de parecer pronto, pedir que alguém pague, ouvir o que não funciona e escolher o que não fazer.

A IA alarga a distância emocional entre esses dois tipos de trabalho. Ela deixa o trabalho divertido ainda mais rápido e recompensador. Não deixa uma conversa de vendas constrangedora menos constrangedora, nem uma escolha estratégica menos incerta.

Então manter o foco hoje exige mais do que um backlog. Exige honestidade sobre por que quero fazer a próxima coisa. É o trabalho mais importante ou é o lugar onde consigo a dose mais rápida de progresso visível?

Preciso de uma definição de pronto antes de começar

A defesa mais útil que encontrei é definir a linha de chegada antes de a construção ficar interessante. O que precisa ser verdade para esta versão sair? Que pergunta estou tentando responder? O que está explicitamente autorizado a continuar tosco?

Mantenho as respostas curtas. Se a meta é «um estranho consegue baixar o app e concluir a tarefa principal», então uma tela de configurações melhor não está no caminho crítico. Se a meta é «descobrir se alguém vai pagar», então mais uma semana de polimento é provavelmente um jeito sofisticado de evitar perguntar.

Ideias novas continuam sendo anotadas. Elas só não podem se declarar urgentes sozinhas. Coloco numa lista para depois e volto à linha de chegada definida. Depois que o marco é real, posso escolher uma rodada deliberada de polimento e aproveitá-la sem fingir que é outra coisa.

Contenção agora faz parte do ofício

Já escrevi que bom gosto é o gargalo quando todo mundo consegue construir. Contenção é uma expressão desse gosto. Não é só saber qual versão fica melhor. É saber que este problema não precisa de outra versão agora.

Conseguir fazer quase qualquer coisa rápido não me livra de priorizar. Torna a priorização mais importante. Toda ferramenta que remove uma restrição externa joga mais peso sobre a interna: a disciplina de sustentar uma direção, deixar boas ideias por fazer e parar quando o trabalho cumpriu seu propósito.

A IA deveria encurtar a distância entre uma ideia e seu resultado. Se eu deixo cada ajuste gostoso se enfiar no caminho, ela faz o contrário. O produto fica mais polido enquanto o lançamento não chega nem um pouco mais perto.

A pergunta que tento fazer com mais frequência

Antes de pedir mais uma mudança a um agente, tento parar e fazer uma pergunta menos empolgante: o que faria este produto ou este negócio avançar hoje?

Às vezes a resposta é mesmo o ajuste. Detalhes importam e não quero entregar trabalho desleixado. Mas muitas vezes a resposta é publicar a versão, mandar o e-mail, ligar para o cliente, escrever a proposta ou tomar a decisão em torno da qual venho circulando.

A era da IA dá a quem constrói uma alavanca extraordinária. Usá-la bem significa saber quando pisar no acelerador. Significa também manter a mão no volante.

AI時代のスコープクリープ

Matt Senter — Fri, 04 Sep 2026 14:34:27 +0000

自分がやるべき最も重要なこと、つまりプロダクトをよくすることを避けるための、新しい手口を手に入れた。

といっても、リリースにこぎ着け、顧客を見つけ、着想を証明するという意味でよくするのではない。千通りの些細なやり方でよくするのだ。余白を詰める。空状態の文言を書き直す。キーボードショートカットを足す。アニメーションを調整する。AI のコーディングエージェントにもう一つ趣味のよい改善を頼み、一分後にそれが現れるのを眺め、すぐさま次の粗を見つける。

どの微調整も速い。どの微調整も生産的に感じられる。そしてそれらが合わさると、驚くほど長いあいだ私をクリティカルパスの外に留めておける。

かつてのスコープクリープには摩擦があった

スコープクリープは新しい現象ではない。プロダクトは昔から要件を溜め込んできた。ただ、以前の版は近づいてくるのが見えやすかった。新しい機能とは、会議であり、見積もりであり、チケットであり、担当の開発者であり、テストの周回であり、締め切りについてのまた一つの気まずい会話だった。コストが自分から名乗りを上げてくれた。

AI はその摩擦の多くを取り除いた。いまや新しい機能は、プロンプトに六語ほど打ち込むところから始まりうる。見積もりもなければ、「これは本当に要るのか」と尋ねる相手も部屋にいないかもしれない。同僚に着想を説明し終えていたはずの時間には、もう最初の版が動いている。

それは途方もない強みだ。同時に罠でもある。着手のコストがゼロに感じられるとき、いったん立ち止まって正当化するという古い本能は、そもそも働かない。

危ないのは「ついでだから」という一言だ

この型は、あからさまに悪い思いつきから始まることはめったにない。もっともらしい何かから始まる。このフォームを直すついでに、バリデーションもよくしておこう。バリデーションのコードにいるついでに、エラーメッセージも整えよう。エラーにはアイコンがあったほうがいい。アイコンを置くと、デザインシステムの不整合が露わになる。気づけば、誰も不満を言ったことのないコンポーネントを組み直している。

一つ一つの判断は、単独で見れば筋が通っている。だからこの型は抗いがたい。名指しできる無謀な選択は一つもなく、あるのは有用な小さな選択の連なりだけで、それが静かにプロジェクトを、行く必要のなかった場所へ運んでいく。

同じことはプロダクトの外でも起きる。ロゴを磨き上げるのに午後をまるごと使う、レポートを自動化する、CRM を整理し直す、ランディングページを二十通り生成する。どれも簡単に起こる。その仕事は良いものかもしれないし、いずれ必要になるかもしれない。だが、事業が今日必要としているのが顧客との会話なら、そのどれもが本来の仕事ではない。

実行が安くなっても、注意は安くならない

AI は微調整のコストを下げた。だが、どの微調整をするかを選び、それを確認し、プロダクトの残りに馴染ませ、その後も増えた複雑さを背負い続けるコストは下げていない。そして何より、私の注意を無限にはしなかった。

私が見落としがちなのは、そのコストだ。二分の変更が、頭の中に二十分の枝道を開くことがある。それは私が見ているものを変え、脳が解こうとしている問題を変える。それを五十回やれば、たとえ一行残らずエージェントが書いたとしても、一日は消える。

速さは、驚くほど心地よい形で事態を悪くする。遅い仕事には自然な区切りができる。速い仕事は勢いを生む。依頼が片端から片づいていく即時の報酬は、次の依頼をほとんどただのように感じさせる。引けば必ず洗練された UI を吐き出すスロットマシンのレバーのように。私は詰まってもいないし、苛立ってもいない。楽しんでいる。だからこそ、進路を外れていることに気づきにくい。

楽しい仕事と大事な仕事は、同じ一覧ではない

私は作る部分が大好きだ。作る人の多くはそうだろうと思う。具体的で、反応があり、満足がある。依頼をすれば、目の前でものが変わる。クリティカルパスのほうは、たいていずっと楽しくない。このプロダクトが何であるかを決め、完成に見える前に世に出し、誰かに払ってくれと頼み、何が駄目かを聞かされ、何をやらないかを選ぶ。

AI は、この二種類の仕事のあいだの感情的な落差を広げる。楽しいほうの仕事をいっそう速く、いっそう報われるものにする。だが気まずい営業の会話を気まずくなくしてはくれないし、戦略上の判断の不確かさも減らしてはくれない。

だから集中を保つには、いまやバックログ以上のものが要る。次にこれをやりたいのはなぜか、そこに正直であることが要る。それは最も重要な仕事なのか、それとも目に見える進捗をいちばん早く得られる場所なのか。

始める前に「完了」の定義が要る

私が見つけた最も有用な守りは、開発が面白くなる前にゴールラインを引いておくことだ。この版を出すには、何が真であればよいのか。私はどの問いに答えようとしているのか。どこは粗いままでよいと明示的に認めるのか。

答えは短くしておく。目標が「見知らぬ人がアプリをダウンロードして主要なタスクを完了できること」なら、より良い設定画面はクリティカルパス上にない。目標が「誰かが金を払うかどうかを確かめること」なら、さらに一週間の磨き込みは、たぶん尋ねずに済ませるための洗練された手口だ。

新しい思いつきは、これまでどおり書き留める。ただ、自分で自分を「緊急」に任命することはできない。あとで見る一覧に置き、定義したゴールラインへ戻る。節目が本当に達成されたなら、意図した磨き込みの回を選び、それを何か別のものだと偽らずに楽しめばいい。

抑制はいまや技芸の一部だ

誰もが作れるようになったときセンスこそがボトルネックになる、と私は以前書いた。抑制は、そのセンスの一つの現れである。どの版がいちばん見栄えするかを知っていることだけではない。この問題にはいま、もう一つの版など要らないと知っていることだ。

ほとんど何でも素早く作れるからといって、優先順位づけから解放されるわけではない。むしろ優先順位づけの重みが増す。外的な制約を取り除く道具はどれも、内的な制約のほうに重さを移す。方向を保ち、良い思いつきを手つかずのまま残し、仕事がその目的を果たしたら止める、という規律である。

AI は、着想と結果のあいだの距離を縮めるはずのものだ。満足のいく微調整のすべてを途中に割り込ませてしまえば、それは逆に働く。プロダクトはより磨かれ、ローンチは一歩も近づかない。

もっと頻繁に問おうとしている問い

エージェントにもう一つ変更を頼む前に、私は立ち止まって、もっと心躍らない問いを立てようとしている。今日、このプロダクトなり事業なりを前に進めるのは何か。

答えが本当にその微調整であることもある。細部は大事だし、雑な仕事を出したくもない。だが多くの場合、答えはビルドを公開すること、メールを送ること、顧客に電話すること、提案を書くこと、あるいはずっと周りを回っていた決断を下すことだ。

AI の時代は、作る者に並外れた梃子を与える。それをうまく使うとは、いつアクセルを踏むかを知ることだ。そして、ハンドルから手を離さないことでもある。