Ich habe keine einzige Codezeile geschrieben. Ich habe auch keine gelesen.

Das heißt aber nicht, dass ich die Produkte an die KI übergeben habe. Ich entschied immer noch, welche Probleme sie lösen sollten, definierte, wie die Systeme funktionieren sollten, beurteilte, welche Grenzen nicht überschritten werden durften, überprüfte, ob die Ergebnisse zuverlässig waren, und übernahm die Verantwortung für die endgültige Software. Was sich geändert hat, war einfach meine Schnittstelle zur Implementierung.

Dies zwang mich, eine Frage zu überdenken, die einst einfach schien: Wenn jemand den Code nicht mehr von Hand schreibt, aber dennoch das Werk definiert, über den Erfolg entscheidet und dafür verantwortlich bleibt, ist er dann immer noch der Autor der Software?

Diese Praxis beweist nicht, dass jede Software auf diese Weise erstellt werden kann. Es beweist nicht einmal, dass diese unveröffentlichten Produkte auf dem Markt erfolgreich sein werden. Aber für die Arten von Anwendungen, die wir erstellen, ist ein auf Codierungsagenten basierender Workflow nicht mehr nur eine Möglichkeit, schneller zu programmieren. Es wird zu einem technischen Ansatz, der Planung, Implementierung, Tests, Korrektur und Iteration unterstützen kann.

Die wichtige Änderung besteht nicht darin, dass „KI Code schreiben kann“. Früher war die Implementierung einer der seltensten Teile bei der Entwicklung von Software. jetzt beginnt es in den Hintergrund zu treten.

Was passiert aus der menschlichen Arbeit, wenn die Umsetzung nicht mehr das Geringste ist?

Das ist die Frage dieses Aufsatzes.

Die Grenzen der KI verschieben sich

KI war noch nie ein fester Begriff. Menschen neigen dazu, etwas KI zu nennen, während Computer es noch nicht zuverlässig können; Sobald die Fähigkeit ausgereift ist und in alltägliche Produkte Einzug hält, wird sie schnell zur gewöhnlichen Technologie und sieht nicht mehr wie KI aus.

Auch mein eigener Weg ist dieser Grenze gefolgt. In der Mittelschule und an der Universität habe ich an Robotern auf Rädern gearbeitet und dabei Sensoren und Feedback-Steuerung eingesetzt, um sie dazu zu bringen, Pfaden zu folgen, Hindernissen auszuweichen und sich in Formationen zu koordinieren. Während des Graduiertenstudiums habe ich Computer Vision studiert und bin gleichzeitig als einer der frühen Gründungsmitarbeiter der neu gegründeten SenseTime beigetreten. Ich habe dazu beigetragen, Gesichtserkennungs- und industrielle Bildverarbeitungstechnologien in groß angelegte Anwendungen zu integrieren, darunter Smartphones und Hochgeschwindigkeitszüge. Heutzutage haben universelle Stiftungsmodelle und die von ihnen angetriebenen Agenten die Grenzen erneut verschoben. Diese Systeme lösen nicht mehr nur isolierte Probleme. Sie beginnen, Ziele zu verstehen, Tools zu nutzen und weiterhin auf Feedback zu reagieren; Auch meine Arbeit hat sich auf diese Produkte konzentriert. Rückblickend übernehmen Maschinen von der Bewegungssteuerung über das Verstehen von Bildern bis hin zur Erledigung ganzer Aufgaben immer längere und umfassendere Arbeitsketten.

In diesem Aufsatz bezieht sich KI in erster Linie auf Agenten, die von allgemeinen Basismodellen gesteuert werden, wobei Coding-Agenten ein repräsentatives Beispiel sind. Ihre Entwicklung deutet auf die autonome Ausführung längerfristiger Aufgaben, eine schrittweise Selbstentwicklung und sogar auf die Fähigkeit hin, ihre eigenen Nachfolger auszubilden.

Im Jahr 2025 verwendete Andrej Karpathy „Vibe Coding“, um einen lockeren Programmierstil zu beschreiben: Sagen Sie der KI, was Sie wollen, akzeptieren Sie den generierten Code, geben Sie Fehlermeldungen zurück und vergessen Sie sogar, dass der Code überhaupt existiert. [1] Aber wenn man so weit gehen will, muss man eine Voraussetzung haben: Die Kosten des Scheiterns müssen gering sein. Für seriöse Produkte verwendeten wir damals noch Cursor. Menschliche Entwickler leiteten die Arbeit und blieben für den Code verantwortlich; Der Agent hat geholfen.

Anfang 2026 sahen wir, wie sich die Grenze wieder nach vorne verschob. Karpathy nannte die neue Arbeitsweise später „Agentic Engineering“: Entwickler nutzen KI nicht mehr nur zur Vervollständigung von Code, sondern organisieren und überwachen Agenten bei der Ausführung von Engineering-Aufgaben und behalten dabei die Verantwortung für Überprüfung und Qualität. [2] Der Name ist nicht wichtig. Entscheidend ist, dass die KI von der Bereitstellung einzelner Vorschläge zu einer nachhaltigen Aktion innerhalb von Einschränkungen übergeht.

Für einige Softwareentwickler werden natürliche Sprache und Dokumente bereits zu einer neuen Ebene für die Absichtsäußerung.

Code wird zu einem Zwischenartefakt

Die Geschichte der Informatik ist auch eine Geschichte der Hinzufügung von Abstraktionsebenen.

Der Mensch bediente Maschinen zunächst mit Schaltern und Patchkabeln. Dann kamen Maschinencode, Assembler und höhere Programmiersprachen. Jede neue Ebene verbarg einen Teil der darunter liegenden Komplexität und ermöglichte es den Menschen, näher an ihren Absichten zu arbeiten.

Codierungsagenten fügen der Softwareentwicklung eine neue Abstraktionsebene hinzu. Sie sind so etwas wie ein nichtdeterministischer Super-Compiler: Ein traditioneller Compiler übersetzt ein formal spezifiziertes Programm in Maschinenanweisungen, während ein Coding-Agent versucht, menschliche Absichten in Schnittstellen, Daten, Dienste und Code umzusetzen.

Der Unterschied ist wichtig. Die menschliche Sprache ist mehrdeutig. Anforderungen sind oft unvollständig und Einschränkungen können widersprüchlich sein. Ein Agent kann einen Satz nicht mechanisch in ein einziges korrektes Ergebnis übersetzen. Es muss den Zyklus Verständnis, Planung, Implementierung, Ausführung und Überprüfung durchlaufen.

Natürliche Sprache hat Programmiersprachen nicht ersetzt. Genauer gesagt werden natürliche Sprache und Dokumente zu einer Absichtsschicht, die von Menschen verwaltet wird, während Code zunehmend als Implementierungsmedium dient, das von Agenten generiert und verwaltet wird.

Das macht Code eher zu einem Zwischenartefakt, aber „mittelmäßig“ bedeutet nicht unwichtig. Code muss immer noch korrekt, sicher und wartbar sein. Möglicherweise muss es einfach nicht von einer Person Zeile für Zeile geschrieben und gelesen werden. Die meisten Programmierer überprüfen nicht den von einem Compiler ausgegebenen Maschinencode, bleiben aber für die Funktionsweise des Programms verantwortlich.

Das ändert, was wir klarstellen müssen.

Dokumentation war früher eine Erklärung von Code. In unserer Arbeit beginnt sich das Verhältnis umzukehren: Es wird mehr Code aus Dokumenten generiert und verifiziert. Warum das Produkt existiert, wie das System funktionieren sollte, welche Grenzen nicht überschritten werden dürfen und welche Beweise zeigen, dass es seine Anforderungen erfüllt – diese Dinge, die einmal als Anhänge zum Code behandelt wurden, werden zur Quelle der Software selbst.

Dann: „Reden ist billig. Zeig mir den Code.“

Jetzt: „Code ist günstig. Zeigen Sie mir das Dokument.“

Wenn Sie den Code nicht von Hand schreiben, werden die Anforderungen an den Ausdruck nicht verringert. Es erhöht sie. In der Vergangenheit konnte eine mehrdeutige Idee erst im Laufe eines langen Umsetzungsprozesses an die Oberfläche kommen und klarer werden. Jetzt kann ein Agent es schnell in ein funktionierendes, scheinbar vollständiges System verwandeln. Die Unklarheit ist nicht verschwunden. Es wurde lediglich in der Implementierung vergraben, wo es später als Fehler und Verluste zum Vorschein kommt.

KI erspart uns nicht den Zwang zum Nachdenken. Es macht es nur schwieriger, vage Vorstellungen hinter der Hektik der Umsetzung zu verbergen.

Die andere Hälfte von „Papier und Stift“

Im Jahr 2025 verglich Wang Jian KI mit dem „neuen Papier und Stift“ der Menschheit: nicht mit dem Gedanken selbst, sondern mit einer Erweiterung des menschlichen Denkens. [3] Ich mag diese Metapher.

Es enthält eine interessante historische Symmetrie. Im Jahr 1948 stellte sich Alan Turing einen Menschen vor, der mit Papier, Bleistift und Radiergummi ausgestattet war und einem Regelwerk folgte, dessen Verhalten als das einer Universalmaschine angesehen werden könnte. [4] Anschließend wurde mit Papier und Bleistift erklärt, wie eine Person eine Maschine simulieren könnte. Fast achtzig Jahre später scheint sich die Richtung umgekehrt zu haben. Die Maschine wird zum neuen Papier und Stift und hilft Menschen dabei, Absichten in lauffähige Welten zu entfalten.

Die Metapher erinnert mich auch an die Universität. Abgesehen vom Schlafen verbrachte ich wahrscheinlich ein Drittel meiner Zeit damit, zwischen Software und Hardware hin und her zu wechseln: Betriebssysteme zu installieren, Umgebungen zu konfigurieren, Tools zu erlernen, an Mikrocontrollern herumzubasteln, Radroboter zu debuggen und sie dazu zu bringen, sich in Formationen zu koordinieren, und Demos zu erstellen, die mich interessierten. Der Prozess hat mir Spaß gemacht, aber ich habe oft mehr Zeit mit der Vorbereitung als mit dem Schaffen verbracht – wie ein Maler, der ständig nach Papier sucht, Pigmente herstellt und Pinsel repariert.

KI als das neue Papier und den neuen Stift zu bezeichnen, bedeutet nicht, dass sie alles kann. Papier schreibt keinen Roman. Pigmente zeichnen kein gutes Bild und eine Kamera macht keinen guten Film. Werkzeuge senken die Ausdruckskosten, entscheiden aber nicht darüber, was es wert ist, ausgedrückt zu werden.

Kodiermittel sind weitaus aktiver als Papier und Stift. Sie machen Vorschläge, führen Aufgaben aus und treffen Entscheidungen in einem begrenzten Rahmen. Solange sie jedoch nicht die Verantwortung für den Zweck und die Folgen eines Werks übernehmen können, werden sie durch eine stärkere Beteiligung nicht automatisch zu Autoren.

Was mich interessiert, ist die andere Hälfte von „Neues Papier und Stift“:

Wenn wir neues Papier und neuen Stift haben, welche Art von Künstlern brauchen wir dann?

Das Zentrum für Software-Erstellung befindet sich auf dem Vormarsch

Die Idee, dass Programmierer Künstler sind, ist nicht neu.

Im Jahr 1974 erklärte Donald Knuth in „Computerprogrammierung als Kunst“, warum Programmieren Wissen, Können und Kreativität erfordert und wie sich damit Objekte von Schönheit herstellen lassen. [5] Im Jahr 2003 argumentierte Paul Graham in „Hackers and Painters“, dass sowohl Hacker als auch Maler Macher seien. Für Softwareentwickler sind Computer ein Ausdrucksmittel, genau wie Farbe für einen Maler oder Beton für einen Architekten. [6]

KI macht Programmierer nicht zum ersten Mal zu Künstlern. Es verändert sich dort, wo die Kunst hauptsächlich stattfindet.

Ein Großteil der Kunst eines Programmierers spielte sich früher im Code ab: ob ein Algorithmus genial, eine Abstraktion elegant oder ein System war, das in der Lage war, genügend Möglichkeiten mit möglichst wenig Struktur zu enthalten. Diese Art von Schönheit wird nicht verschwinden, weil Agenten da sind.

Doch je mehr Umsetzungsarbeit auf die Agenten verlagert wird, desto höher rückt das Zentrum der menschlichen Schöpfung nach oben. Die Kunst der Software wird zunehmend in der Arbeit als Ganzes zum Ausdruck kommen: welche Probleme man wählen muss, wessen Leben man verstehen muss, welche Ordnung man etablieren muss, auf welche Möglichkeiten man verzichten sollte, wie man auf Benutzer reagiert und wie die Arbeit in ihr Leben eintreten soll.

Schöpfung auf der Ebene von Produkt und Erfahrung gab es schon immer. Die Veränderung besteht darin, dass diese Anliegen zur Hauptaufgabe von mehr Softwareentwicklern werden können, wenn die Implementierung nicht mehr den größten Teil unserer Aufmerksamkeit in Anspruch nimmt.

Eleganter Code ist immer noch wichtig, aber Code war noch nie die ganze Schönheit einer Software. Software, die von Menschen und KI gemeinsam erstellt wird, sollte nicht nur als ein Haufen Codes betrachtet werden, der ausgeführt wird, sondern als ein vollständiges Softwarewerk.

Dies ist die Veränderung, die mit „neuen Künstlern“ impliziert wird.

Aus heutiger Sicht ähnelt die Rolle einer Kombination aus Produktmanager und Architekt: Sie fragt sowohl, was und für wen gemacht werden soll, als auch, wie das System Bestand haben kann und wo seine Grenzen liegen. Aber diese Titel reichen nicht aus. Der Autor von Software braucht außerdem Geschmack, Einfühlungsvermögen, die Fähigkeit, Kompromisse einzugehen und die Bereitschaft, Verantwortung für das Gesamtergebnis zu übernehmen.

„Künstler“ ist hier weder ein edlerer Titel noch beschreibt er unbedingt eine Person. Es ist die Rolle eines Autors, der für ein vollständiges Werk verantwortlich ist und ein Team es teilen kann.

Engineering lässt die Arbeit zuverlässig existieren. Kunst bestimmt, warum sie existiert und wie sie in das menschliche Leben eindringt.

Das Engineering wird nicht verschwinden und die Verantwortung kann nicht ausgelagert werden

Der neue Künstler schlägt keine gute Idee vor und wartet dann darauf, dass die KI alles andere fertigstellt.

Auch nachdem Papier und Stift weit verbreitet waren, erforderte das Schreiben noch eine Ausbildung; Nachdem Kameras weit verbreitet waren, erforderte die Fotografie immer noch Urteilsvermögen. Codierungsagenten senken die Implementierungskosten, lösen jedoch nicht automatisch Architektur, Sicherheit, Leistung, Qualität oder Wartung in komplexen Systemen.

Die Tatsache, dass ich keinen Code lese, bedeutet nicht, dass ich die technische Kontrolle aufgegeben habe. Die Kontrollpunkte haben sich geändert: von der zeilenweisen Überprüfung der Implementierung bis hin zur Definition von Systemzielen, Architekturprinzipien, Datengrenzen, Berechtigungsmodellen, Teststandards, Beobachtbarkeit und Akzeptanztestergebnissen.

Dadurch wird die Arbeit nicht weniger streng. Es setzt an anderer Stelle Strenge voraus. Decken die Tests die tatsächlichen Risiken ab? Zeigen die Laufzeitergebnisse, dass das System seine Einschränkungen erfüllt? Gibt es Beweise für die Erklärung des Agenten? Wenn eine Funktion ausgeführt wird, ist sie auch versandbereit? KI kann an jeder dieser Aufgaben beteiligt sein, aber letztendlich muss eine Person entscheiden, ob die Beweise vertrauenswürdig sind, und die Konsequenzen tragen, wenn sie falsch liegen.

In einigen Bereichen – darunter Infrastruktur, sicherheitskritische Systeme und Low-Level-Software – wird es weiterhin erforderlich sein, dass Mitarbeiter tief im Code arbeiten. Möglicherweise brauchen sie die kleine Anzahl von Menschen, die die unteren Schichten wirklich verstehen, mehr denn je. Eine neue Abstraktionsschicht löscht niemals die darunter liegenden Schichten. Durch Hochsprachen wurde Assembler nicht abgeschafft, und Cloud Computing hat Betriebssysteme nicht abgeschafft. Mit einer neuen Ebene können einfach mehr Entwickler vermeiden, jedes Mal, wenn sie etwas erstellen, jede untere Ebene zu durchlaufen.

Meine Entscheidung, keinen Code zu schreiben oder zu lesen, ist eine begrenzte Praxis und keine Regel für jedermann. Sein Wert besteht nicht darin, dass er beweist, dass Code veraltet ist. Es hilft mir zu erkennen, welche Teile der Arbeit immer noch nicht übergeben werden können, wenn Code nicht mehr die einzige Schnittstelle ist, über die Menschen Software steuern.

Das erste ist das Urteil. Das zweite ist Verantwortung.

Leistungsstärkere Werkzeuge können in größerem Maßstab auch zu Mittelmäßigkeit führen. Wenn die Implementierung billiger wird, erhalten wir möglicherweise zunächst mehr repetitive, grobe Software, die keinen wirklichen Bedarf deckt. Papier und Stift ergeben nicht automatisch Literatur. Codierungsagenten werden nicht automatisch eine Software-Renaissance bewirken.

KI beseitigt die Knappheit nicht. Es bewegt es.

Früher wurde die Softwareproduktion hauptsächlich durch Programmierkenntnisse, technische Ressourcen und Implementierungszeit eingeschränkt. Wenn diese Einschränkungen nachlassen, werden das Urteilsvermögen darüber, welche Probleme wichtig sind, die Produktintuition, das Systemverständnis, der Geschmack, das Verständnis für Menschen und die Bereitschaft, Verantwortung für Konsequenzen zu übernehmen, relativ selten.

Je billiger „wie man es macht“ wird, desto teurer wird „was man macht“.

Von Code-Autoren zu Software-Autoren

Bret Taylor zitierte eine Beobachtung von Arya Asemanfar: KI kann für Sie Entwürfe erstellen, aber Sie sind immer noch der Autor. [7] Addy Osmani hat die neue Rolle des Entwicklers als Architekt und Chefredakteur beschrieben. [8]

Ein Autor muss nicht jede Handlung ausführen, die ein Werk hervorbringt. Architekten legen nicht jeden Stein und Regisseure bedienen nicht jede Kamera an einem Filmset. Aber sie müssen wissen, was aus der Arbeit werden soll, beurteilen, ob sie gelingt, und die Verantwortung für die Arbeit als Ganzes übernehmen.

Die gleiche Veränderung vollzieht sich in der Software.

Früher haben wir den Autor von Software ermittelt, indem wir gefragt haben, wer den Code geschrieben hat. In Zukunft könnte die Urheberschaft zunehmend von einer anderen Reihe von Fragen abhängen: Wer hat das Problem definiert? Wer hat die Beschränkungen festgelegt? Wer hat die entscheidenden Kompromisse gemacht? Wer hat entschieden, dass die Arbeiten abgeschlossen waren? Und wer trägt die Verantwortung für das, was passiert, nachdem es auf die Welt gekommen ist?

Dadurch kann sich auch die wirtschaftliche Einheit der Software ändern. In der Vergangenheit musste ein Bedürfnis in der Regel von genügend Menschen geteilt werden, um die Entwicklung von Software dafür zu rechtfertigen. Wenn die Implementierungskosten weit genug sinken, kann der besondere Arbeitsablauf eines Teams, einer Familie oder sogar einer einzelnen Person eine eigene Software rechtfertigen. Nicht jeder muss Programmierer werden, aber mehr Menschen können Software-Autoren werden.

KI verschiebt mehr Implementierungsarbeit nach unten, während sie menschliche Kontrollpunkte und das Zentrum der Schöpfung um eine Abstraktionsebene nach oben verschiebt. Programmierer werden nicht länger nur Code-Autoren sein. Sie werden zunehmend zu Autoren kompletter Softwarewerke – die „neuen Künstler“ meine ich.

Das neue Papier und der neue Stift sind angekommen. Aber eine neue Renaissance wird nicht automatisch folgen. Es hängt nicht davon ab, wie viel Code-Agenten generieren können, sondern davon, ob wir das Urteilsvermögen – und die Bereitschaft, Verantwortung zu übernehmen – haben, um eine Frage zu beantworten, die schwieriger ist als „Wie kann es gemacht werden?“

Was ist es wert, geschaffen zu werden, und wie möchten wir, dass die Menschen es erleben?

Referenzen

[1] Andrej Karpathy, X-Beitrag zur Einführung von „Vibe Coding“, 02.02.2025.

[2] Andrej Karpathy, X-Beitrag mit dem Vorschlag „Agentic Engineering“, 04.02.2026.

[3] Liu Ningxin, „Wang Jian: Innovation kommt von ‚Unvollkommenheit‘ und ‚Grenzen überschreiten‘“, 21st Century Business Herald, 25.09.2025.

[4] Alan M. Turing, „Intelligent Machinery“, Bericht des National Physical Laboratory, 1948.

[5] Donald E. Knuth, „Computer Programming as an Art“, Communications of the ACM, 17(12), 1974, S. 667–673.

[6] Paul Graham, „Hackers and Painters“, Mai 2003.

[7] Bret Taylor, „KI ist Ihr Ghostwriter, aber Sie sind der Autor“, LinkedIn, 10.02.2026.

[8] Addy Osmani, Beyond Vibe Coding, O’Reilly Media, August 2025.

I did not write a single line of code. Nor did I read one.

But that does not mean I handed the products over to AI. I still decided which problems they should solve, defined how the systems should work, judged which boundaries could not be crossed, verified whether the results were reliable, and took responsibility for the final software. What changed was simply my interface with the implementation.

This forced me to reconsider a question that once seemed simple: if someone no longer writes code by hand, but still defines the work, decides whether it succeeds, and remains responsible for it, are they still the author of the software?

This practice does not prove that all software can be built this way. It does not even prove that these unreleased products will succeed in the market. But for the kinds of applications we build, a workflow centered on coding agents is no longer merely a way to program faster. It is becoming an engineering approach that can sustain planning, implementation, testing, correction, and iteration.

The important change is not that “AI can write code.” Implementation used to be one of the scarcest parts of creating software; now it is beginning to recede into the background.

When implementation is no longer the scarcest part, what becomes of human work?

That is the question of this essay.

The Boundary of AI Is Moving

AI has never been a fixed term. People tend to call something AI while computers cannot yet do it reliably; once the capability matures and enters everyday products, it quickly becomes ordinary technology and stops looking like AI.

My own path has followed this boundary as well. In middle school and university, I worked on wheeled robots, using sensors and feedback control to make them follow paths, avoid obstacles, and coordinate in formation. During graduate school, I studied computer vision while also joining the newly founded SenseTime as an early founding employee. I helped bring face liveness detection and industrial vision technologies into large-scale applications, including smartphones and high-speed rail. Today, general-purpose foundation models and the agents they power have pushed the boundary forward again. These systems no longer address only isolated problems. They are beginning to understand goals, use tools, and continue acting in response to feedback; my work has moved toward these products as well. Looking back, from controlling motion and understanding images to completing entire tasks, machines are taking on longer and more complete chains of work.

In this essay, then, AI refers primarily to agents driven by general-purpose foundation models, with coding agents as a representative example. Their development points toward autonomous execution of longer-horizon tasks, gradual self-evolution, and even the ability to train their own successors.

In 2025, Andrej Karpathy used “vibe coding” to describe a loose style of programming: tell AI what you want, accept the generated code, feed error messages back to it, and even forget that the code exists at all. [1] But letting go this far has one precondition: the cost of failure must be low. At the time, for serious products, we still used Cursor. Human developers led the work and remained responsible for the code; the agent assisted.

By early 2026, we saw the boundary move forward again. Karpathy later called the new way of working “agentic engineering”: developers no longer merely use AI to complete code, but organize and supervise agents as they carry out engineering tasks while retaining responsibility for review and quality. [2] The name is not important. What matters is that AI is moving from offering suggestions one at a time to sustained action within constraints.

For some software creators, natural language and documents are already becoming a new layer for expressing intent.

Code Is Becoming an Intermediate Artifact

The history of computing is also a history of adding abstraction layers.

People first operated machines with switches and patch cables. Then came machine code, assembly, and high-level programming languages. Each new layer concealed some of the complexity below and let people work closer to their intentions.

Coding agents add a new abstraction layer to software development. They are something like a nondeterministic super-compiler: a traditional compiler translates a formally specified program into machine instructions, while a coding agent tries to unfold human intent into interfaces, data, services, and code.

The difference matters. Human language is ambiguous. Requirements are often incomplete, and constraints can conflict. An agent cannot mechanically translate a sentence into a single correct result. It has to cycle through understanding, planning, implementation, execution, and verification.

Natural language has not replaced programming languages. More precisely, natural language and documents are becoming an intent layer maintained by people, while code increasingly serves as an implementation medium generated and maintained by agents.

That makes code more like an intermediate artifact, but “intermediate” does not mean unimportant. Code still has to be correct, secure, and maintainable. It simply may not need to be written and read line by line by a person. Most programmers do not inspect the machine code emitted by a compiler, but they remain responsible for what the program does.

This changes what we need to make clear.

Documentation used to be an explanation of code. In our work, the relationship is starting to reverse: more code is being generated and verified from documents. Why the product exists, how the system should work, which boundaries cannot be crossed, and what evidence shows that it meets its requirements—these things, once treated as attachments to the code, are becoming the source of the software itself.

Then: “Talk is cheap. Show me the code.”

Now: “Code is cheap. Show me the doc.”

Not writing code by hand does not lower the demands on expression. It raises them. In the past, an ambiguous idea had time to surface and become clearer over a long implementation process. Now an agent can quickly turn it into a working, seemingly complete system. The ambiguity has not disappeared. It has merely been buried in the implementation, where it will surface later as failures and losses.

AI does not spare us the need to think. It only makes it harder to hide vague ideas behind the busyness of implementation.

The Other Half of “Paper and Pen”

In 2025, Wang Jian compared AI to humanity’s “new paper and pen”: not thought itself, but an extension of human thought. [3] I like this metaphor.

It contains an interesting historical symmetry. In 1948, Alan Turing imagined a person equipped with paper, pencil, and eraser, following a set of rules, whose behavior could be regarded as that of a universal machine. [4] People then used paper and pencil to explain how a person might simulate a machine. Nearly eighty years later, the direction seems to have reversed. The machine is becoming the new paper and pen, helping people unfold intentions into worlds that can run.

The metaphor also reminds me of university. Aside from sleeping, I probably spent a third of my time moving back and forth between software and hardware: installing operating systems, configuring environments, learning tools, tinkering with microcontrollers, debugging wheeled robots and getting them to coordinate in formation, and building whatever demos interested me. I enjoyed the process, but I often spent more time preparing to create than creating—like a painter forever looking for paper, making pigments, and repairing brushes.

Calling AI the new paper and pen does not mean it can do everything. Paper does not write a novel. Pigment does not paint a good picture, and a camera does not make a good film. Tools lower the cost of expression, but they do not decide what is worth expressing.

Coding agents are far more active than paper and pen. They offer suggestions, execute tasks, and make choices within a limited scope. But until they can take responsibility for a work’s purpose and consequences, greater participation does not automatically make them authors.

What interests me is the other half of “new paper and pen”:

If we have new paper and pen, what kind of artists do we need?

The Center of Software Creation Is Moving Up

The idea that programmers are artists is not new.

In 1974, Donald Knuth explained in “Computer Programming as an Art” why programming requires knowledge, skill, and creativity, and how it can produce objects of beauty. [5] In 2003, Paul Graham argued in “Hackers and Painters” that hackers and painters are both makers. For software creators, computers are a medium of expression just as paint is for a painter or concrete for an architect. [6]

AI is not making programmers artists for the first time. It is changing where the art mainly happens.

Much of a programmer’s art used to happen inside the code: whether an algorithm was ingenious, an abstraction elegant, or a system able to contain enough possibilities with as little structure as possible. This kind of beauty will not disappear because agents have arrived.

But as more implementation work moves down to agents, the center of human creation moves up. The art of software will increasingly be expressed in the work as a whole: which problems to choose, whose lives to understand, what order to establish, which possibilities to forgo, how to respond to users, and how the work should enter their lives.

Creation at the level of product and experience has always existed. The change is that when implementation no longer consumes most of our attention, these concerns can become the main work of more software creators.

Elegant code still matters, but code has never been the whole of software’s beauty. Software made by people and AI together should not be seen merely as a pile of code that runs, but as a complete work of software.

This is the change implied by “new artists.”

In existing professional terms, the role resembles a combination of a product manager and an architect: asking both what should be made and for whom, and how the system can endure and where its boundaries lie. But those titles are not enough. The author of software also needs taste, empathy, the ability to make tradeoffs, and the willingness to take responsibility for the overall result.

“Artist” here is not a more noble title, nor does it necessarily describe one person. It is the role of an author responsible for a complete work, and a team can share it.

Engineering lets the work exist reliably. Art determines why it exists and how it enters human life.

Engineering Will Not Disappear, and Responsibility Cannot Be Outsourced

The new artist does not propose a good idea and then wait for AI to finish everything else.

Even after paper and pen became widespread, writing still required training; after cameras became widespread, photography still required judgment. Coding agents lower the cost of implementation, but they do not automatically solve architecture, security, performance, quality, or maintenance in complex systems.

The fact that I do not read code does not mean I have abandoned engineering control. The control points have changed: from inspecting implementation line by line to defining system goals, architectural principles, data boundaries, permission models, testing standards, observability, and acceptance-test results.

This does not make the work less strict. It places strictness elsewhere. Do the tests cover the real risks? Do the runtime results show that the system satisfies its constraints? Is there evidence for the agent’s explanation? If a feature runs, is it also ready to ship? AI can participate in each of these tasks, but a person must ultimately decide whether the evidence is trustworthy and bear the consequences of being wrong.

Some fields—including infrastructure, safety-critical systems, and low-level software—will continue to require people to work deep inside the code. They may need the small number of people who truly understand the lower layers more than ever. A new abstraction layer never erases the layers below it. High-level languages did not eliminate assembly, and cloud computing did not eliminate operating systems. A new layer simply lets more creators avoid traversing every lower layer each time they make something.

My decision not to write or read code is a bounded practice, not a rule for everyone. Its value is not that it proves code is obsolete. It helps me see which parts of the work still cannot be handed off when code is no longer the only interface through which people control software.

The first is judgment. The second is responsibility.

More powerful tools may also produce mediocrity at a larger scale. When implementation becomes cheaper, we may first get more repetitive, crude software that meets no real need. Paper and pen do not automatically produce literature. Coding agents will not automatically produce a software renaissance.

AI does not eliminate scarcity. It moves it.

Software production used to be constrained mainly by programming skill, engineering resources, and implementation time. As those constraints ease, judgment about which problems matter, product intuition, systems understanding, taste, an understanding of people, and the willingness to take responsibility for consequences become relatively scarcer.

As “how to make it” gets cheaper, “what to make” gets more expensive.

From Authors of Code to Authors of Software

Bret Taylor cited an observation by Arya Asemanfar: AI can draft for you, but you are still the author. [7] Addy Osmani has described the developer’s new role as architect and editor-in-chief. [8]

An author does not have to perform every action that produces a work. Architects do not lay every brick, and directors do not operate every camera on a film set. But they must know what the work should become, judge whether it succeeds, and take responsibility for the work as a whole.

The same change is happening in software.

We used to identify the author of software by asking who wrote the code. In the future, authorship may depend increasingly on a different set of questions: Who defined the problem? Who established the constraints? Who made the critical tradeoffs? Who decided that the work was complete? And who bears responsibility for what happens after it enters the world?

This may also change the economic unit of software. In the past, a need usually had to be shared by enough people to justify building software for it. When implementation costs fall far enough, the particular workflow of a team, a family, or even one person may warrant software of its own. Not everyone has to become a programmer, but more people can become authors of software.

AI pushes more implementation work downward while moving human control points and the center of creation up one abstraction layer. Programmers will no longer be merely authors of code. Increasingly, they will become authors of complete works of software—the “new artists” I mean.

The new paper and pen have arrived. But a new renaissance will not follow automatically. It depends not on how much code agents can generate, but on whether we have the judgment—and the willingness to take responsibility—to answer a question harder than “how can it be made?”

What is worth creating, and how do we want people to experience it?

References

[1] Andrej Karpathy, X post introducing “vibe coding”, 2025-02-02.

[2] Andrej Karpathy, X post proposing “agentic engineering”, 2026-02-04.

[3] Liu Ningxin, “Wang Jian: Innovation Comes from ‘Imperfection’ and ‘Crossing Boundaries’”, 21st Century Business Herald, 2025-09-25.

[4] Alan M. Turing, “Intelligent Machinery”, National Physical Laboratory report, 1948.

[5] Donald E. Knuth, “Computer Programming as an Art”, Communications of the ACM, 17(12), 1974, pp. 667–673.

[6] Paul Graham, “Hackers and Painters”, May 2003.

[7] Bret Taylor, “AI is your ghostwriter, but you are the author”, LinkedIn, 2026-02-10.

[8] Addy Osmani, Beyond Vibe Coding, O’Reilly Media, August 2025.

No escribí ni una sola línea de código. Tampoco leí una sola línea.

Pero eso no significa que entregara los productos a la IA. Aun así, decidí qué problemas debían resolver, definí cómo debían funcionar los sistemas, juzgué qué límites no podían cruzarse, verifiqué si los resultados eran fiables y asumí la responsabilidad del software final. Lo que cambió fue simplemente mi interfaz con la implementación.

Esto me obligó a reconsiderar una pregunta que antes parecía simple: si alguien ya no escribe código a mano, pero define el trabajo, decide si tiene éxito y sigue siendo responsable de él, ¿sigue siendo el autor del software?

Esta práctica no prueba que todo el software pueda construirse de esta manera. Ni siquiera prueba que estos productos inéditos tengan éxito en el mercado. Pero para los tipos de aplicaciones que creamos, un flujo de trabajo centrado en agentes de codificación ya no es simplemente una forma de programar más rápido. Se está convirtiendo en un enfoque de ingeniería que puede sustentar la planificación, implementación, prueba, corrección e iteración.

El cambio importante no es que "la IA pueda escribir código". La implementación solía ser una de las partes más escasas de la creación de software; ahora está empezando a pasar a un segundo plano.

Cuando la implementación ya no es la parte más escasa, ¿qué pasa con el trabajo humano?

Ésa es la cuestión de este ensayo.

La frontera de la IA se está moviendo

La IA nunca ha sido un término fijo. La gente tiende a llamar IA a aquello que las computadoras aún no pueden hacer de forma fiable; cuando una capacidad madura y llega a los productos cotidianos, pronto se convierte en tecnología ordinaria y deja de parecer IA.

Mi propio camino también ha seguido este límite. En la escuela secundaria y la universidad, trabajé con robots con ruedas, usando sensores y control de retroalimentación para hacerlos seguir caminos, evitar obstáculos y coordinar formación. Durante la escuela de posgrado, estudié visión por computadora y al mismo tiempo me uní a la recién fundada SenseTime como uno de los primeros empleados fundadores. Ayudé a llevar las tecnologías de visión industrial y detección de vida facial a aplicaciones a gran escala, incluidos teléfonos inteligentes y trenes de alta velocidad. Hoy en día, los modelos de fundaciones de propósito general y los agentes que impulsan han vuelto a ampliar los límites. Estos sistemas ya no abordan sólo problemas aislados. Están empezando a comprender los objetivos, utilizar herramientas y seguir actuando en respuesta a la retroalimentación; Mi trabajo también se ha movido hacia estos productos. Mirando hacia atrás, desde controlar el movimiento y comprender imágenes hasta completar tareas enteras, las máquinas están asumiendo cadenas de trabajo más largas y completas.

Entonces, en este ensayo, la IA se refiere principalmente a agentes impulsados por modelos básicos de propósito general, con los agentes codificadores como un ejemplo representativo. Su desarrollo apunta hacia la ejecución autónoma de tareas de horizontes más amplios, una autoevolución gradual e incluso la capacidad de capacitar a sus propios sucesores.

En 2025, Andrej Karpathy utilizó «vibe coding» para describir un estilo de programación flexible: decirle a la IA lo que se quiere, aceptar el código generado, devolverle los mensajes de error e incluso olvidar que el código existe. [1] Pero llegar tan lejos tiene una condición previa: el coste del fracaso debe ser bajo. En aquel momento, para productos serios, todavía usábamos Cursor. Los desarrolladores humanos dirigían el trabajo y seguían siendo responsables del código; el agente ayudaba.

A principios de 2026, vimos cómo la frontera avanzaba nuevamente. Más tarde, Karpathy llamó a la nueva forma de trabajar “ingeniería agencial”: los desarrolladores ya no solo usan IA para completar el código, sino que organizan y supervisan a los agentes mientras llevan a cabo tareas de ingeniería, manteniendo al mismo tiempo la responsabilidad de la revisión y la calidad. [2] El nombre no es importante. Lo que importa es que la IA está pasando de ofrecer sugerencias una por una a acciones sostenidas dentro de limitaciones.

Para algunos creadores de software, el lenguaje natural y los documentos ya se están convirtiendo en una nueva capa para expresar intenciones.

El código se está convirtiendo en un artefacto intermedio

La historia de la informática es también la historia de la adición de capas de abstracción.

Las primeras máquinas fueron operadas con interruptores y cables de conexión. Luego vinieron el código de máquina, el ensamblador y los lenguajes de programación de alto nivel. Cada nueva capa ocultaba parte de la complejidad que había debajo y permitía a las personas trabajar más cerca de sus intenciones.

Los agentes de codificación añaden una nueva capa de abstracción al desarrollo de software. Son algo así como un supercompilador no determinista: un compilador tradicional traduce un programa formalmente especificado en instrucciones de máquina, mientras que un agente codificador intenta desplegar la intención humana en interfaces, datos, servicios y código.

La diferencia importa. El lenguaje humano es ambiguo. Los requisitos suelen ser incompletos y las restricciones pueden entrar en conflicto. Un agente no puede traducir mecánicamente una frase en un único resultado correcto. Tiene que pasar por la comprensión, la planificación, la implementación, la ejecución y la verificación.

El lenguaje natural no ha sustituido a los lenguajes de programación. Más precisamente, el lenguaje natural y los documentos se están convirtiendo en una capa de intención mantenida por personas, mientras que el código sirve cada vez más como un medio de implementación generado y mantenido por agentes.

Eso hace que el código se parezca más a un artefacto intermedio, pero "intermedio" no significa que no sea importante. El código aún tiene que ser correcto, seguro y mantenible. Es posible que simplemente no sea necesario que una persona lo escriba y lea línea por línea. La mayoría de los programadores no inspeccionan el código de máquina emitido por un compilador, pero siguen siendo responsables de lo que hace el programa.

Esto cambia lo que debemos dejar claro.

La documentación solía ser una explicación del código. En nuestro trabajo, la relación está empezando a revertirse: se genera y verifica más código a partir de documentos. Por qué existe el producto, cómo debería funcionar el sistema, qué límites no se pueden cruzar y qué evidencia demuestra que cumple con sus requisitos: estas cosas, una vez tratadas como archivos adjuntos al código, se están convirtiendo en la fuente del software en sí.

Luego: "Hablar es barato. Muéstrame el código".

Ahora: "El código es barato. Muéstrame el documento".

No escribir código a mano no reduce las exigencias de expresión. Los levanta. En el pasado, una idea ambigua tenía tiempo de emerger y aclararse tras un largo proceso de implementación. Ahora un agente puede convertirlo rápidamente en un sistema funcional y aparentemente completo. La ambigüedad no ha desaparecido. Simplemente ha quedado enterrado en la implementación, donde saldrá a la luz más tarde como fracasos y pérdidas.

La IA no nos ahorra la necesidad de pensar. Sólo hace que sea más difícil ocultar ideas vagas detrás del ajetreo de la implementación.

La otra mitad de “papel y bolígrafo”

En 2025, Wang Jian comparó la IA con el “nuevo papel y bolígrafo” de la humanidad: no el pensamiento en sí, sino una extensión del pensamiento humano. [3] Me gusta esta metáfora.

Contiene una interesante simetría histórica. En 1948, Alan Turing imaginó a una persona equipada con papel, lápiz y goma de borrar, siguiendo una serie de reglas, cuyo comportamiento podría considerarse como el de una máquina universal. [4] Luego, la gente usó papel y lápiz para explicar cómo una persona podría simular una máquina. Casi ochenta años después, la dirección parece haberse invertido. La máquina se está convirtiendo en el nuevo papel y bolígrafo, ayudando a las personas a desarrollar sus intenciones en mundos que pueden funcionar.

La metáfora también me recuerda a la universidad. Aparte de dormir, probablemente pasaba un tercio de mi tiempo yendo y viniendo entre software y hardware: instalando sistemas operativos, configurando entornos, aprendiendo herramientas, jugando con microcontroladores, depurando robots con ruedas y haciendo que coordinaran información, y construyendo cualquier demostración que me interesara. Disfruté el proceso, pero a menudo pasaba más tiempo preparándome para crear que creando, como un pintor que siempre busca papel, crea pigmentos y repara pinceles.

Llamar a la IA el nuevo papel y lápiz no significa que pueda hacerlo todo. El papel no escribe una novela. Los pigmentos no pintan una buena imagen y una cámara no hace una buena película. Las herramientas reducen el costo de la expresión, pero no deciden qué vale la pena expresar.

Los agentes codificadores son mucho más activos que el papel y el bolígrafo. Ofrecen sugerencias, ejecutan tareas y toman decisiones dentro de un alcance limitado. Pero hasta que puedan asumir la responsabilidad del propósito y las consecuencias de una obra, una mayor participación no los convierte automáticamente en autores.

Lo que me interesa es la otra mitad de “papel y bolígrafo nuevos”:

Si tenemos papel y bolígrafo nuevos, ¿qué tipo de artistas necesitamos?

El centro de creación de software está avanzando

La idea de que los programadores son artistas no es nueva.

En 1974, Donald Knuth explicó en “La programación informática como arte” por qué la programación requiere conocimiento, habilidad y creatividad, y cómo puede producir objetos bellos. [5] En 2003, Paul Graham argumentó en “Hackers and Painters” que tanto los hackers como los pintores son creadores. Para los creadores de software, las computadoras son un medio de expresión como lo es la pintura para un pintor o el concreto para un arquitecto. [6]

La IA no está convirtiendo a los programadores en artistas por primera vez. Está cambiando donde ocurre principalmente el arte.

Gran parte del arte de un programador solía ocurrir dentro del código: ya fuera un algoritmo ingenioso, una abstracción elegante o un sistema capaz de contener suficientes posibilidades con la menor estructura posible. Este tipo de belleza no desaparecerá porque hayan llegado agentes.

Pero a medida que más trabajo de implementación desciende a los agentes, el centro de la creación humana asciende. El arte del software se expresará cada vez más en la obra en su conjunto: qué problemas elegir, qué vidas comprender, qué orden establecer, a qué posibilidades renunciar, cómo responder a los usuarios y cómo la obra debería entrar en sus vidas.

La creación a nivel de producto y experiencia siempre ha existido. El cambio es que cuando la implementación ya no consume la mayor parte de nuestra atención, estas preocupaciones pueden convertirse en el trabajo principal de más creadores de software.

El código elegante todavía importa, pero el código nunca ha sido toda la belleza del software. El software creado por personas e IA juntas no debe verse simplemente como un montón de código que se ejecuta, sino como un trabajo completo de software.

Este es el cambio que implican los “nuevos artistas”.

En términos profesionales actuales, el rol se asemeja a una combinación de gerente de producto y arquitecto: pregunta qué se debe hacer y para quién, cómo puede perdurar el sistema y dónde se encuentran sus límites. Pero esos títulos no son suficientes. El autor de software también necesita gusto, empatía, capacidad para hacer concesiones y voluntad de asumir la responsabilidad del resultado general.

“Artista” aquí no es un título más noble, ni necesariamente describe a una persona. Es el rol de un autor responsable de una obra completa, y un equipo puede compartirla.

La ingeniería permite que el trabajo exista de forma fiable. El arte determina por qué existe y cómo entra en la vida humana.

La ingeniería no desaparecerá y la responsabilidad no se puede subcontratar

El nuevo artista no propone una buena idea y luego espera a que la IA termine todo lo demás.

Incluso después de que el papel y el lápiz se generalizaran, la escritura todavía requería formación; Después de que las cámaras se generalizaron, la fotografía todavía requería criterio. Los agentes de codificación reducen el costo de implementación, pero no resuelven automáticamente la arquitectura, la seguridad, el rendimiento, la calidad o el mantenimiento en sistemas complejos.

El hecho de que no lea código no significa que haya abandonado el control de ingeniería. Los puntos de control han cambiado: desde inspeccionar la implementación línea por línea hasta definir objetivos del sistema, principios arquitectónicos, límites de datos, modelos de permisos, estándares de prueba, observabilidad y resultados de pruebas de aceptación.

Esto no hace que el trabajo sea menos estricto. Coloca el rigor en otra parte. ¿Las pruebas cubren los riesgos reales? ¿Los resultados del tiempo de ejecución muestran que el sistema satisface sus restricciones? ¿Existe evidencia para la explicación del agente? Si se ejecuta una función, ¿también está lista para enviarse? La IA puede participar en cada una de estas tareas, pero en última instancia, una persona debe decidir si la evidencia es confiable y asumir las consecuencias de estar equivocada.

Algunos campos, incluidos la infraestructura, los sistemas críticos para la seguridad y el software de bajo nivel, seguirán requiriendo que las personas trabajen profundamente dentro del código. Es posible que necesiten más que nunca un pequeño número de personas que realmente comprendan las capas inferiores. Una nueva capa de abstracción nunca borra las capas debajo de ella. Los lenguajes de alto nivel no eliminaron el ensamblador y la computación en la nube no eliminó los sistemas operativos. Una nueva capa simplemente permite que más creadores eviten atravesar cada capa inferior cada vez que crean algo.

Mi decisión de no escribir ni leer código es una práctica limitada, no una regla para todos. Su valor no es que demuestre que el código es obsoleto. Me ayuda a ver qué partes del trabajo aún no se pueden entregar cuando el código ya no es la única interfaz a través de la cual las personas controlan el software.

El primero es el juicio. El segundo es la responsabilidad.

Herramientas más poderosas también pueden producir mediocridad a mayor escala. Cuando la implementación se vuelve más barata, es posible que primero obtengamos software más repetitivo y tosco que no satisface ninguna necesidad real. El papel y el bolígrafo no producen literatura automáticamente. Los agentes codificadores no producirán automáticamente un renacimiento del software.

La IA no elimina la escasez. Solo la desplaza.

La producción de software solía estar limitada principalmente por las habilidades de programación, los recursos de ingeniería y el tiempo de implementación. A medida que esas limitaciones se alivian, el juicio sobre qué problemas importan, la intuición del producto, la comprensión de los sistemas, el gusto, la comprensión de las personas y la voluntad de asumir la responsabilidad de las consecuencias se vuelven relativamente más escasos.

A medida que “cómo hacerlo” se vuelve más barato, “qué hacer” se vuelve más caro.

De autores de código a autores de software

Bret Taylor citó una observación de Arya Asemanfar: La IA puede redactar por ti, pero tú sigues siendo el autor. [7] Addy Osmani ha descrito el nuevo papel del desarrollador como arquitecto y editor en jefe. [8]

Un autor no tiene que realizar todas las acciones que producen una obra. Los arquitectos no colocan todos los ladrillos y los directores no manejan todas las cámaras en un set de filmación. Pero deben saber en qué debería convertirse el trabajo, juzgar si tiene éxito y asumir la responsabilidad del trabajo en su conjunto.

El mismo cambio está ocurriendo en el software.

Solíamos identificar al autor del software preguntando quién escribió el código. En el futuro, la autoría puede depender cada vez más de un conjunto diferente de preguntas: ¿Quién definió el problema? ¿Quién estableció las restricciones? ¿Quién hizo las concesiones críticas? ¿Quién decidió que la obra estaba completa? ¿Y quién es responsable de lo que suceda después de su llegada al mundo?

Esto también puede cambiar la unidad económica del software. En el pasado, una necesidad generalmente tenía que ser compartida por suficientes personas para justificar la creación de software para ella. Cuando los costos de implementación caen lo suficiente, el flujo de trabajo particular de un equipo, una familia o incluso una persona puede justificar su propio software. No todo el mundo tiene que convertirse en programador, pero más personas pueden convertirse en autores de software.

La IA impulsa más trabajo de implementación hacia abajo mientras mueve los puntos de control humano y el centro de creación hacia arriba una capa de abstracción. Los programadores ya no serán meros autores de código. Cada vez más, se convertirán en autores de obras completas de software (me refiero a los “nuevos artistas”).

Han llegado el papel y el bolígrafo nuevos. Pero un nuevo renacimiento no se producirá automáticamente. No depende de cuánto código puedan generar los agentes, sino de si tenemos el criterio (y la voluntad de asumir la responsabilidad) para responder a una pregunta más difícil que "¿cómo se puede crear?".

¿Qué vale la pena crear y cómo queremos que la gente lo experimente?

Referencias

[1] Andrej Karpathy, publicación en X que presenta «vibe coding», 2 de febrero de 2025.

[2] Andrej Karpathy, X publicación que propone “ingeniería agentica”, 4 de febrero de 2026.

[3] Liu Ningxin, “Wang Jian: La innovación proviene de la ‘imperfección’ y el ‘cruce de límites’”, 21st Century Business Herald, 25 de septiembre de 2025.

[4] Alan M. Turing, “Maquinaria inteligente”, Informe del Laboratorio Nacional de Física, 1948.

[5] Donald E. Knuth, “La programación informática como arte”, Comunicaciones del ACM, 17(12), 1974, págs. 667–673.

[6] Paul Graham, “Hackers y pintores”, mayo de 2003.

[7] Bret Taylor, “La IA es tu escritor fantasma, pero tú eres el autor”, LinkedIn, 2026-02-10.

[8] Addy Osmani, Beyond Vibe Coding, O'Reilly Media, agosto de 2025.

Je n'ai pas écrit une seule ligne de code. Je n’en ai pas lu non plus.

Mais cela ne veut pas dire que j’ai confié les produits à l’IA. J'ai néanmoins décidé des problèmes à résoudre, défini comment les systèmes devaient fonctionner, jugé quelles limites ne pouvaient pas être franchies, vérifié si les résultats étaient fiables et pris la responsabilité du logiciel final. Ce qui a changé, c'est simplement mon interface avec l'implémentation.

Cela m'a obligé à reconsidérer une question qui paraissait simple autrefois : si quelqu'un n'écrit plus de code à la main, mais définit quand même le travail, décide de sa réussite et en reste responsable, est-il toujours l'auteur du logiciel ?

Cette pratique ne prouve pas que tous les logiciels peuvent être construits de cette façon. Cela ne prouve même pas que ces produits inédits réussiront sur le marché. Mais pour les types d’applications que nous construisons, un flux de travail centré sur les agents de codage n’est plus simplement un moyen de programmer plus rapidement. Cela devient une approche d'ingénierie capable de soutenir la planification, la mise en œuvre, les tests, la correction et l'itération.

Le changement important n’est pas que « l’IA puisse écrire du code ». La mise en œuvre était autrefois l’une des parties les plus rares de la création de logiciels ; maintenant, il commence à passer au second plan.

Lorsque la mise en œuvre n’est plus la partie la plus rare, que devient le travail humain ?

C'est la question de cet essai.

Les frontières de l’IA bougent

L’IA n’a jamais été un terme fixe. Les gens ont tendance à appeler quelque chose IA alors que les ordinateurs ne peuvent pas encore le faire de manière fiable ; Une fois que la capacité mûrit et entre dans les produits quotidiens, elle devient rapidement une technologie ordinaire et cesse de ressembler à l’IA.

Mon propre chemin a également suivi cette frontière. Au collège et à l'université, j'ai travaillé sur des robots à roues, en utilisant des capteurs et un contrôle par rétroaction pour leur faire suivre des chemins, éviter les obstacles et se coordonner en formation. Pendant mes études supérieures, j'ai étudié la vision par ordinateur tout en rejoignant la nouvelle société SenseTime en tant qu'un des premiers employés fondateurs. J'ai contribué à intégrer les technologies de détection de l'activité des visages et de vision industrielle dans des applications à grande échelle, notamment les smartphones et les trains à grande vitesse. Aujourd’hui, les modèles de fondation généralistes et les agents qu’ils alimentent ont encore repoussé la frontière. Ces systèmes ne répondent plus uniquement à des problèmes isolés. Ils commencent à comprendre les objectifs, à utiliser les outils et à continuer d'agir en réponse aux commentaires ; mon travail s'est également orienté vers ces produits. Avec le recul, depuis le contrôle du mouvement et la compréhension des images jusqu'à l'exécution de tâches entières, les machines assument des chaînes de travail plus longues et plus complètes.

Dans cet essai, l’IA fait donc principalement référence à des agents pilotés par des modèles de base à usage général, les agents de codage étant un exemple représentatif. Leur développement laisse présager une exécution autonome de tâches à plus long terme, une auto-évolution progressive et même la capacité de former leurs propres successeurs.

En 2025, Andrej Karpathy a utilisé le « vibe coding » pour décrire un style de programmation libre : dites à l’IA ce que vous voulez, acceptez le code généré, renvoyez-lui des messages d’erreur et oubliez même que le code existe. [1] Mais lâcher prise jusqu’ici a une condition préalable : le coût de l’échec doit être faible. A l’époque, pour les produits sérieux, on utilisait encore Cursor. Les développeurs humains ont dirigé le travail et sont restés responsables du code ; l’agent a aidé.

Début 2026, nous avons vu la frontière avancer à nouveau. Karpathy a ensuite qualifié cette nouvelle façon de travailler d'« ingénierie agent » : les développeurs n'utilisent plus simplement l'IA pour compléter le code, mais organisent et supervisent les agents lorsqu'ils effectuent des tâches d'ingénierie tout en conservant la responsabilité de l'examen et de la qualité. [2] Le nom n'a pas d'importance. Ce qui compte, c’est que l’IA passe de l’offre de suggestions une par une à une action soutenue dans le cadre de contraintes.

Pour certains créateurs de logiciels, le langage naturel et les documents constituent déjà une nouvelle couche d’expression d’intention.

Le code devient un artefact intermédiaire

L’histoire de l’informatique est aussi celle de l’ajout de couches d’abstraction.

Les gens ont d'abord utilisé des machines avec des commutateurs et des câbles de brassage. Viennent ensuite le code machine, l’assembleur et les langages de programmation de haut niveau. Chaque nouvelle couche masquait une partie de la complexité sous-jacente et permettait aux gens de travailler au plus près de leurs intentions.

Les agents de codage ajoutent une nouvelle couche d'abstraction au développement logiciel. Ils ressemblent en quelque sorte à un super-compilateur non déterministe : un compilateur traditionnel traduit un programme formellement spécifié en instructions machine, tandis qu'un agent de codage tente de déployer l'intention humaine en interfaces, données, services et code.

La différence compte. Le langage humain est ambigu. Les exigences sont souvent incomplètes et les contraintes peuvent entrer en conflit. Un agent ne peut pas traduire mécaniquement une phrase en un seul résultat correct. Il doit passer par la compréhension, la planification, la mise en œuvre, l’exécution et la vérification.

Le langage naturel n’a pas remplacé les langages de programmation. Plus précisément, le langage naturel et les documents deviennent une couche d'intention gérée par les utilisateurs, tandis que le code sert de plus en plus de support de mise en œuvre généré et maintenu par les agents.

Cela fait du code davantage un artefact intermédiaire, mais « intermédiaire » ne signifie pas sans importance. Le code doit toujours être correct, sécurisé et maintenable. Il n’est peut-être tout simplement pas nécessaire qu’une personne l’écrive et le lise ligne par ligne. La plupart des programmeurs n'inspectent pas le code machine émis par un compilateur, mais ils restent responsables de ce que fait le programme.

Cela change ce que nous devons clarifier.

La documentation était autrefois une explication du code. Dans notre travail, la relation commence à s'inverser : davantage de code est généré et vérifié à partir de documents. Pourquoi le produit existe, comment le système doit fonctionner, quelles limites ne peuvent être franchies et quelles preuves montrent qu'il répond à ses exigences : ces éléments, autrefois traités comme des pièces jointes au code, deviennent la source du logiciel lui-même.

Puis : "Parler ne coûte pas cher. Montre-moi le code."

Maintenant : "Le code ne coûte pas cher. Montrez-moi la doc."

Ne pas écrire de code à la main ne réduit pas les exigences d’expression. Cela les élève. Dans le passé, une idée ambiguë avait le temps de surgir et de se préciser au fil d’un long processus de mise en œuvre. Désormais, un agent peut rapidement le transformer en un système fonctionnel et apparemment complet. L'ambiguïté n'a pas disparu. Il a simplement été enterré dans la mise en œuvre, où il fera surface plus tard sous forme d’échecs et de pertes.

L’IA ne nous épargne pas le besoin de réfléchir. Cela ne fait que rendre plus difficile la dissimulation d’idées vagues derrière l’agitation de la mise en œuvre.

L'autre moitié de « Papier et stylo »

En 2025, Wang Jian a comparé l’IA au « nouveau papier et au nouveau stylo » de l’humanité : non pas la pensée elle-même, mais une extension de la pensée humaine. [3] J'aime cette métaphore.

Il contient une symétrie historique intéressante. En 1948, Alan Turing imaginait une personne équipée de papier, d'un crayon et d'une gomme, suivant un ensemble de règles, dont le comportement pouvait être considéré comme celui d'une machine universelle. [4] Les gens utilisaient ensuite du papier et un crayon pour expliquer comment une personne pouvait simuler une machine. Près de quatre-vingts ans plus tard, la tendance semble s’être inversée. La machine devient le nouveau papier et le nouveau stylo, aidant les gens à concrétiser leurs intentions dans des mondes qui peuvent fonctionner.

La métaphore me rappelle aussi l’université. En plus de dormir, j'ai probablement passé un tiers de mon temps à faire des allers-retours entre les logiciels et le matériel : installer des systèmes d'exploitation, configurer des environnements, apprendre des outils, bricoler des microcontrôleurs, déboguer des robots à roues et les faire coordonner en formation, et construire toutes les démos qui m'intéressaient. J'ai apprécié le processus, mais j'ai souvent passé plus de temps à me préparer à créer qu'à créer, comme un peintre toujours à la recherche de papier, à fabriquer des pigments et à réparer des pinceaux.

Appeler l’IA le nouveau papier et le nouveau stylo ne signifie pas qu’elle peut tout faire. Le papier n’écrit pas de roman. Les pigments ne donnent pas une bonne image et un appareil photo ne fait pas un bon film. Les outils réduisent le coût de l’expression, mais ils ne décident pas de ce qui vaut la peine d’être exprimé.

Les agents de codage sont bien plus actifs que le papier et le stylo. Ils proposent des suggestions, exécutent des tâches et font des choix dans un cadre limité. Mais tant qu’ils ne peuvent pas assumer la responsabilité du but et des conséquences d’une œuvre, une plus grande participation ne fait pas automatiquement d’eux des auteurs.

Ce qui m’intéresse, c’est l’autre moitié du « nouveau papier et stylo » :

Si nous avons du nouveau papier et un nouveau stylo, de quel genre d’artistes avons-nous besoin ?

Le centre de création de logiciels évolue

L’idée selon laquelle les programmeurs sont des artistes n’est pas nouvelle.

En 1974, Donald Knuth expliquait dans « Computer Programming as an Art » pourquoi la programmation nécessite des connaissances, des compétences et de la créativité, et comment elle peut produire des objets de beauté. [5] En 2003, Paul Graham affirmait dans « Hackers and Painters » que les hackers et les peintres sont tous deux des créateurs. Pour les créateurs de logiciels, les ordinateurs sont un moyen d’expression, tout comme la peinture l’est pour un peintre ou le béton pour un architecte. [6]

L’IA ne fait pas des programmeurs des artistes pour la première fois. Cela change là où l’art se produit principalement.

Une grande partie de l’art d’un programmeur se déroulait autrefois à l’intérieur du code : qu’il s’agisse d’un algorithme ingénieux, d’une abstraction élégante ou d’un système capable de contenir suffisamment de possibilités avec le moins de structure possible. Ce genre de beauté ne disparaîtra pas parce que les agents sont arrivés.

Mais à mesure que le travail de mise en œuvre se déplace vers les agents, le centre de la création humaine s’élève. L’art du logiciel s’exprimera de plus en plus dans l’œuvre dans son ensemble : quels problèmes choisir, quelles vies comprendre, quel ordre établir, à quelles possibilités renoncer, comment répondre aux utilisateurs et comment l’œuvre doit entrer dans leur vie.

La création au niveau du produit et de l'expérience a toujours existé. Le changement est que lorsque la mise en œuvre n’absorbe plus l’essentiel de notre attention, ces préoccupations peuvent devenir le travail principal d’un plus grand nombre de créateurs de logiciels.

Un code élégant est toujours important, mais le code n’a jamais été la seule beauté d’un logiciel. Les logiciels créés conjointement par des personnes et l’IA ne doivent pas être considérés simplement comme un tas de code qui s’exécute, mais comme une œuvre logicielle complète.

C’est le changement qu’impliquent les « nouveaux artistes ».

Dans les termes professionnels existants, le rôle ressemble à une combinaison de chef de produit et d'architecte : se demandant à la fois ce qui doit être fait et pour qui, comment le système peut durer et où se situent ses limites. Mais ces titres ne suffisent pas. L'auteur d'un logiciel a également besoin de goût, d'empathie, de capacité à faire des compromis et de volonté d'assumer la responsabilité du résultat global.

« Artiste » n'est pas ici un titre plus noble et ne décrit pas nécessairement une seule personne. C'est le rôle d'un auteur responsable d'une œuvre complète, et une équipe peut la partager.

L'ingénierie permet au travail d'exister de manière fiable. L'art détermine pourquoi il existe et comment il entre dans la vie humaine.

L'ingénierie ne disparaîtra pas et la responsabilité ne peut pas être externalisée

Le nouvel artiste ne propose pas de bonne idée et attend ensuite que l'IA termine tout le reste.

Même après la généralisation du papier et du stylo, l’écriture nécessitait toujours une formation ; Après la généralisation des appareils photo, la photographie exigeait encore du jugement. Les agents de codage réduisent le coût de mise en œuvre, mais ils ne résolvent pas automatiquement l'architecture, la sécurité, les performances, la qualité ou la maintenance des systèmes complexes.

Le fait que je ne lise pas le code ne signifie pas que j'ai abandonné le contrôle technique. Les points de contrôle ont changé : de l'inspection de la mise en œuvre ligne par ligne à la définition des objectifs du système, des principes architecturaux, des limites des données, des modèles d'autorisation, des normes de test, de l'observabilité et des résultats des tests d'acceptation.

Cela ne rend pas le travail moins strict. Cela place la rigueur ailleurs. Les tests couvrent-ils les risques réels ? Les résultats d'exécution montrent-ils que le système satisfait à ses contraintes ? Existe-t-il des preuves de l’explication de l’agent ? Si une fonctionnalité est exécutée, est-elle également prête à être livrée ? L’IA peut participer à chacune de ces tâches, mais l’individu doit en fin de compte décider si les preuves sont dignes de confiance et supporter les conséquences d’une erreur.

Certains domaines, notamment les infrastructures, les systèmes critiques pour la sécurité et les logiciels de bas niveau, continueront à nécessiter un travail approfondi dans le code. Ils auront peut-être plus que jamais besoin du petit nombre de personnes qui comprennent vraiment les couches inférieures. Un nouveau calque d'abstraction n'efface jamais les calques situés en dessous. Les langages de haut niveau n’ont pas éliminé l’assemblage, et le cloud computing n’a pas éliminé les systèmes d’exploitation. Une nouvelle couche permet simplement à davantage de créateurs d'éviter de parcourir chaque couche inférieure à chaque fois qu'ils créent quelque chose.

Ma décision de ne pas écrire ou lire de code est une pratique limitée, pas une règle pour tout le monde. Sa valeur n’est pas qu’il prouve que le code est obsolète. Cela m'aide à voir quelles parties du travail ne peuvent toujours pas être transférées lorsque le code n'est plus la seule interface par laquelle les gens contrôlent les logiciels.

Le premier est le jugement. La seconde est la responsabilité.

Des outils plus puissants peuvent également produire une médiocrité à plus grande échelle. Lorsque la mise en œuvre devient moins coûteuse, nous pouvons d’abord obtenir des logiciels plus répétitifs et rudimentaires qui ne répondent à aucun besoin réel. Le papier et le stylo ne produisent pas automatiquement de la littérature. Les agents de codage ne produiront pas automatiquement une renaissance du logiciel.

L’IA n’élimine pas la rareté. Elle ne fait que la déplacer.

La production de logiciels était auparavant principalement limitée par les compétences en programmation, les ressources d'ingénierie et le temps de mise en œuvre. À mesure que ces contraintes s’atténuent, le jugement sur les problèmes importants, l’intuition du produit, la compréhension des systèmes, le goût, la compréhension des personnes et la volonté d’assumer la responsabilité des conséquences deviennent relativement rares.

À mesure que « comment le fabriquer » devient moins cher, « quoi fabriquer » devient plus cher.

Des auteurs de code aux auteurs de logiciels

Bret Taylor a cité une observation d'Arya Asemanfar : l'IA peut rédiger pour vous, mais vous en êtes toujours l'auteur. [7] Addy Osmani a décrit le nouveau rôle du promoteur en tant qu’architecte et rédacteur en chef. [8]

Un auteur n’est pas obligé d’accomplir toutes les actions qui produisent une œuvre. Les architectes ne posent pas toutes les briques et les réalisateurs ne font pas fonctionner toutes les caméras d'un plateau de tournage. Mais ils doivent savoir ce que doit devenir l’œuvre, juger de sa réussite et assumer la responsabilité de l’œuvre dans son ensemble.

Le même changement se produit dans les logiciels.

Nous avions l'habitude d'identifier l'auteur d'un logiciel en demandant qui a écrit le code. À l’avenir, la paternité pourrait dépendre de plus en plus d’un ensemble différent de questions : qui a défini le problème ? Qui a établi les contraintes ? Qui a fait les compromis critiques ? Qui a décidé que les travaux étaient terminés ? Et qui porte la responsabilité de ce qui se passe après son entrée dans le monde ?

Cela peut également modifier l'unité économique du logiciel. Dans le passé, un besoin devait généralement être partagé par suffisamment de personnes pour justifier la création d'un logiciel correspondant. Lorsque les coûts de mise en œuvre diminuent suffisamment, le flux de travail particulier d'une équipe, d'une famille ou même d'une seule personne peut justifier son propre logiciel. Tout le monde n’est pas obligé de devenir programmeur, mais davantage de personnes peuvent devenir auteurs de logiciels.

L'IA pousse davantage de travail de mise en œuvre vers le bas tout en déplaçant les points de contrôle humain et le centre de création d'une couche d'abstraction. Les programmeurs ne seront plus de simples auteurs de code. De plus en plus, ils deviendront auteurs d’œuvres complètes de logiciels – je veux dire les « nouveaux artistes ».

Le nouveau papier et le nouveau stylo sont arrivés. Mais une nouvelle renaissance ne suivra pas automatiquement. Cela ne dépend pas de la quantité de code que les agents peuvent générer, mais de notre capacité de discernement (et de notre volonté d’assumer nos responsabilités) pour répondre à une question plus difficile que « comment cela peut-il être réalisé ? »

Qu’est-ce qui vaut la peine d’être créé et comment voulons-nous que les gens en fassent l’expérience ?

Références

[1] Andrej Karpathy, publication sur X présentant le « vibe coding », 02/02/2025.

[2] Andrej Karpathy, post X proposant « l'ingénierie agentique », 04/02/2026.

[3] Liu Ningxin, « Wang Jian : L'innovation vient de « l'imperfection » et du « franchissement des frontières » », 21st Century Business Herald, 25/09/2025.

[4] Alan M. Turing, « Intelligent Machinery », rapport du Laboratoire national de physique, 1948.

[5] Donald E. Knuth, « La programmation informatique en tant qu’art », Communications of the ACM, 17(12), 1974, pp. 667–673.

[6] Paul Graham, « Hackers and Painters », mai 2003.

[7] Bret Taylor, « L’IA est votre prête-plume, mais vous restez l’auteur », LinkedIn, 2026-02-10.

[8] Addy Osmani, Beyond Vibe Coding, O'Reilly Media, août 2025.

मैंने कोड की एक भी पंक्ति नहीं लिखी. न ही मैंने एक पढ़ा.

लेकिन इसका मतलब यह नहीं है कि मैंने उत्पाद एआई को सौंप दिये। मैंने फिर भी तय किया कि उन्हें कौन सी समस्याएँ हल करनी चाहिए, परिभाषित किया कि सिस्टम को कैसे काम करना चाहिए, निर्णय लिया कि कौन सी सीमाएँ पार नहीं की जा सकतीं, सत्यापित किया कि क्या परिणाम विश्वसनीय थे, और अंतिम सॉफ़्टवेयर की ज़िम्मेदारी ली। जो बदलाव आया वह केवल कार्यान्वयन के साथ मेरा इंटरफ़ेस था।

इसने मुझे उस प्रश्न पर पुनर्विचार करने के लिए मजबूर किया जो एक बार सरल लगता था: यदि कोई अब हाथ से कोड नहीं लिखता है, लेकिन फिर भी काम को परिभाषित करता है, यह तय करता है कि यह सफल होगा या नहीं, और इसके लिए ज़िम्मेदार है, तो क्या वे अभी भी सॉफ़्टवेयर के लेखक हैं?

यह अभ्यास यह साबित नहीं करता है कि सभी सॉफ़्टवेयर इस तरह से बनाए जा सकते हैं। इससे यह भी साबित नहीं होता कि ये अप्रकाशित उत्पाद बाज़ार में सफल होंगे। लेकिन हम जिस प्रकार के एप्लिकेशन बनाते हैं, उनके लिए कोडिंग एजेंटों पर केंद्रित वर्कफ़्लो अब केवल तेजी से प्रोग्राम करने का एक तरीका नहीं है। यह एक इंजीनियरिंग दृष्टिकोण बनता जा रहा है जो योजना, कार्यान्वयन, परीक्षण, सुधार और पुनरावृत्ति को बनाए रख सकता है।

महत्वपूर्ण परिवर्तन यह नहीं है कि "एआई कोड लिख सकता है।" कार्यान्वयन सॉफ़्टवेयर निर्माण के सबसे दुर्लभ भागों में से एक हुआ करता था; अब यह पृष्ठभूमि में जाने लगा है।

जब कार्यान्वयन अब सबसे दुर्लभ हिस्सा नहीं रह गया है, तो मानव कार्य का क्या होगा?

यही इस निबंध का प्रश्न है.

एआई की सीमा बढ़ रही है

AI कभी भी एक निश्चित शब्द नहीं रहा है। लोग किसी चीज़ को AI कहते हैं जबकि कंप्यूटर अभी तक इसे विश्वसनीय रूप से नहीं कर सकता है; एक बार जब क्षमता परिपक्व हो जाती है और रोजमर्रा के उत्पादों में प्रवेश कर जाती है, तो यह जल्दी ही सामान्य तकनीक बन जाती है और एआई की तरह दिखना बंद हो जाती है।

मेरा अपना मार्ग भी इसी सीमा का अनुसरण करता रहा है। मिडिल स्कूल और विश्वविद्यालय में, मैंने पहिये वाले रोबोटों पर काम किया, सेंसर और फीडबैक नियंत्रण का उपयोग करके उन्हें पथों का अनुसरण करने, बाधाओं से बचने और गठन में समन्वय करने के लिए प्रेरित किया। ग्रेजुएट स्कूल के दौरान, मैंने कंप्यूटर विज़न का अध्ययन किया और साथ ही नव स्थापित SenseTime में शुरुआती संस्थापक कर्मचारी के रूप में शामिल हुआ। मैंने स्मार्टफोन और हाई-स्पीड रेल सहित बड़े पैमाने के अनुप्रयोगों में चेहरे की जीवंतता का पता लगाने और औद्योगिक दृष्टि प्रौद्योगिकियों को लाने में मदद की। आज, सामान्य प्रयोजन के फाउंडेशन मॉडल और उनके द्वारा संचालित एजेंटों ने सीमा को फिर से आगे बढ़ा दिया है। ये प्रणालियाँ अब केवल पृथक समस्याओं का समाधान नहीं करतीं। वे लक्ष्यों को समझना शुरू कर रहे हैं, उपकरणों का उपयोग कर रहे हैं और फीडबैक के जवाब में कार्य करना जारी रख रहे हैं; मेरा काम इन उत्पादों की ओर भी बढ़ गया है। पीछे मुड़कर देखें, तो गति को नियंत्रित करने और छवियों को समझने से लेकर संपूर्ण कार्यों को पूरा करने तक, मशीनें काम की लंबी और अधिक संपूर्ण श्रृंखलाएं अपना रही हैं।

इस निबंध में, फिर, एआई मुख्य रूप से सामान्य प्रयोजन फाउंडेशन मॉडल द्वारा संचालित एजेंटों को संदर्भित करता है, जिसमें प्रतिनिधि उदाहरण के रूप में कोडिंग एजेंट होते हैं। उनका विकास दीर्घ-क्षितिज कार्यों के स्वायत्त निष्पादन, क्रमिक आत्म-विकास और यहां तक कि अपने स्वयं के उत्तराधिकारियों को प्रशिक्षित करने की क्षमता की ओर इशारा करता है।

2025 में, आंद्रेज कारपैथी ने प्रोग्रामिंग की एक ढीली शैली का वर्णन करने के लिए "वाइब कोडिंग" का उपयोग किया: एआई को बताएं कि आप क्या चाहते हैं, जेनरेट किए गए कोड को स्वीकार करें, त्रुटि संदेशों को वापस फ़ीड करें, और यहां तक कि यह भी भूल जाएं कि कोड मौजूद है। [1] लेकिन यहां तक जाने देने की एक पूर्व शर्त है: विफलता की लागत कम होनी चाहिए। उस समय, गंभीर उत्पादों के लिए, हम अभी भी कर्सर का उपयोग करते थे। मानव डेवलपर्स ने काम का नेतृत्व किया और कोड के लिए जिम्मेदार बने रहे; एजेंट ने सहायता की.

2026 की शुरुआत में, हमने सीमा को फिर से आगे बढ़ते देखा। करपैथी ने बाद में काम करने के नए तरीके को "एजेंट इंजीनियरिंग" कहा: डेवलपर्स अब केवल कोड को पूरा करने के लिए एआई का उपयोग नहीं करते हैं, बल्कि समीक्षा और गुणवत्ता की जिम्मेदारी बरकरार रखते हुए इंजीनियरिंग कार्यों को पूरा करने के लिए एजेंटों को व्यवस्थित और पर्यवेक्षण करते हैं। [2] नाम महत्वपूर्ण नहीं है। जो बात मायने रखती है वह यह है कि एआई एक समय में एक सुझाव देने से लेकर बाधाओं के भीतर निरंतर कार्रवाई की ओर बढ़ रहा है।

कुछ सॉफ़्टवेयर निर्माताओं के लिए, इरादे व्यक्त करने के लिए प्राकृतिक भाषा और दस्तावेज़ पहले से ही एक नई परत बन रहे हैं।

कोड एक मध्यवर्ती कलाकृति बनता जा रहा है

कंप्यूटिंग का इतिहास अमूर्त परतों को जोड़ने का इतिहास भी है।

लोगों ने पहले स्विच और पैच केबल वाली मशीनें संचालित कीं। फिर मशीन कोड, असेंबली और उच्च स्तरीय प्रोग्रामिंग भाषाएँ आईं। प्रत्येक नई परत ने नीचे दी गई कुछ जटिलताओं को छुपाया और लोगों को उनके इरादों के करीब काम करने दिया।

कोडिंग एजेंट सॉफ़्टवेयर विकास में एक नई अमूर्त परत जोड़ते हैं। वे एक गैर-नियतात्मक सुपर-कंपाइलर की तरह हैं: एक पारंपरिक कंपाइलर औपचारिक रूप से निर्दिष्ट प्रोग्राम को मशीन निर्देशों में अनुवादित करता है, जबकि एक कोडिंग एजेंट मानव इरादे को इंटरफेस, डेटा, सेवाओं और कोड में प्रकट करने का प्रयास करता है।

अंतर मायने रखता है. मानव भाषा अस्पष्ट है. आवश्यकताएँ अक्सर अधूरी होती हैं, और बाधाएँ टकराव पैदा कर सकती हैं। एक एजेंट यांत्रिक रूप से किसी वाक्य को एक सही परिणाम में अनुवादित नहीं कर सकता है। इसे समझ, योजना, कार्यान्वयन, निष्पादन और सत्यापन के माध्यम से चक्रित करना होगा।

प्राकृतिक भाषा ने प्रोग्रामिंग भाषाओं का स्थान नहीं लिया है। अधिक सटीक रूप से, प्राकृतिक भाषा और दस्तावेज़ लोगों द्वारा बनाए रखा जाने वाला एक इरादा परत बन रहे हैं, जबकि कोड तेजी से एजेंटों द्वारा उत्पन्न और बनाए रखा गया कार्यान्वयन माध्यम के रूप में कार्य करता है।

यह कोड को एक मध्यवर्ती आर्टिफैक्ट की तरह बनाता है, लेकिन "मध्यवर्ती" का मतलब महत्वहीन नहीं है। कोड को अभी भी सही, सुरक्षित और रखरखाव योग्य होना चाहिए। इसे किसी व्यक्ति द्वारा पंक्ति दर पंक्ति लिखने और पढ़ने की आवश्यकता नहीं हो सकती है। अधिकांश प्रोग्रामर कंपाइलर द्वारा उत्सर्जित मशीन कोड का निरीक्षण नहीं करते हैं, लेकिन प्रोग्राम जो करता है उसके लिए वे जिम्मेदार रहते हैं।

इससे वह बदल जाता है जिसे हमें स्पष्ट करने की आवश्यकता है।

दस्तावेज़ीकरण कोड की व्याख्या हुआ करता था। हमारे काम में, संबंध उल्टा होने लगा है: दस्तावेज़ों से अधिक कोड उत्पन्न और सत्यापित किया जा रहा है। उत्पाद क्यों मौजूद है, सिस्टम को कैसे काम करना चाहिए, किन सीमाओं को पार नहीं किया जा सकता है, और कौन से सबूत बताते हैं कि यह इसकी आवश्यकताओं को पूरा करता है - ये चीजें, जिन्हें एक बार कोड के साथ अनुलग्नक के रूप में माना जाता था, अब सॉफ्टवेयर का स्रोत बन रही हैं।

फिर: "बातचीत सस्ती है। मुझे कोड दिखाओ।"

अब: "कोड सस्ता है। मुझे दस्तावेज़ दिखाओ।"

हाथ से कोड न लिखने से अभिव्यक्ति की मांग कम नहीं होती है। यह उन्हें ऊपर उठाता है. अतीत में, एक अस्पष्ट विचार को लंबी कार्यान्वयन प्रक्रिया के बाद सामने आने और स्पष्ट होने का समय मिलता था। अब एक एजेंट इसे तुरंत एक कार्यशील, प्रतीत होने वाली पूर्ण प्रणाली में बदल सकता है। अस्पष्टता दूर नहीं हुई है. इसे केवल कार्यान्वयन में दबा दिया गया है, जहां यह बाद में विफलताओं और नुकसान के रूप में सामने आएगा।

एआई हमें सोचने की ज़रूरत से मुक्त नहीं करता। वह केवल कार्यान्वयन की व्यस्तता के पीछे अस्पष्ट विचारों को छिपाना कठिन बना देता है।

"कागज़ और कलम" का दूसरा भाग

2025 में, वांग जियान ने एआई की तुलना मानवता के "नए कागज और कलम" से की: स्वयं विचार नहीं, बल्कि मानव विचार का विस्तार। [3] मुझे यह रूपक पसंद है।

इसमें एक दिलचस्प ऐतिहासिक समरूपता शामिल है। 1948 में, एलन ट्यूरिंग ने नियमों के एक सेट का पालन करते हुए कागज, पेंसिल और रबर से लैस एक व्यक्ति की कल्पना की, जिसका व्यवहार एक सार्वभौमिक मशीन के समान माना जा सकता है। [4] तब लोगों ने यह समझाने के लिए कागज और पेंसिल का उपयोग किया कि कोई व्यक्ति किसी मशीन का अनुकरण कैसे कर सकता है। लगभग अस्सी साल बाद, दिशा उलट गई लगती है। मशीन नया कागज और कलम बन रही है, जो लोगों को चलने योग्य दुनिया में अपने इरादे प्रकट करने में मदद कर रही है।

यह रूपक मुझे विश्वविद्यालय की भी याद दिलाता है। सोने के अलावा, मैंने शायद अपना एक तिहाई समय सॉफ्टवेयर और हार्डवेयर के बीच इधर-उधर घूमने में बिताया: ऑपरेटिंग सिस्टम स्थापित करना, वातावरण कॉन्फ़िगर करना, उपकरण सीखना, माइक्रोकंट्रोलर के साथ छेड़छाड़ करना, पहिये वाले रोबोटों को डीबग करना और उन्हें गठन में समन्वय स्थापित करना, और जो भी डेमो मुझे रुचिकर लगे उसे बनाना। मैंने इस प्रक्रिया का आनंद लिया, लेकिन मैंने अक्सर रचना करने की तुलना में रचना की तैयारी में अधिक समय बिताया - जैसे एक चित्रकार हमेशा कागज की तलाश में रहता है, रंगद्रव्य बनाता है, और ब्रश की मरम्मत करता है।

एआई को नया कागज और कलम कहने का मतलब यह नहीं है कि यह सब कुछ कर सकता है। कागज उपन्यास नहीं लिखता. रंगद्रव्य अच्छी तस्वीर नहीं बनाता, और कैमरा अच्छी फिल्म नहीं बनाता। उपकरण अभिव्यक्ति की लागत कम करते हैं, लेकिन वे यह तय नहीं करते कि क्या व्यक्त करने लायक है।

कोडिंग एजेंट कागज और कलम की तुलना में कहीं अधिक सक्रिय हैं। वे सुझाव देते हैं, कार्य निष्पादित करते हैं और सीमित दायरे में चुनाव करते हैं। लेकिन जब तक वे किसी कार्य के उद्देश्य और परिणामों की जिम्मेदारी नहीं ले सकते, तब तक अधिक भागीदारी उन्हें स्वचालित रूप से लेखक नहीं बनाती।

मुझे "नए कागज़ और कलम" के दूसरे भाग में रुचि है:

यदि हमारे पास नया कागज और कलम है, तो हमें किस प्रकार के कलाकारों की आवश्यकता है?

सॉफ्टवेयर निर्माण का केंद्र आगे बढ़ रहा है

यह विचार कि प्रोग्रामर कलाकार हैं, नया नहीं है।

1974 में, डोनाल्ड नुथ ने "कंप्यूटर प्रोग्रामिंग एक कला के रूप में" में बताया कि प्रोग्रामिंग के लिए ज्ञान, कौशल और रचनात्मकता की आवश्यकता क्यों है, और यह कैसे सौंदर्य की वस्तुओं का उत्पादन कर सकता है। [5] 2003 में, पॉल ग्राहम ने "हैकर्स एंड पेंटर्स" में तर्क दिया कि हैकर्स और पेंटर्स दोनों निर्माता हैं। सॉफ़्टवेयर निर्माताओं के लिए, कंप्यूटर अभिव्यक्ति का एक माध्यम है जैसे किसी चित्रकार के लिए पेंट या किसी वास्तुकार के लिए कंक्रीट। [6]

एआई पहली बार प्रोग्रामर को कलाकार नहीं बना रहा है। यह वहां बदल रहा है जहां कला मुख्य रूप से घटित होती है।

एक प्रोग्रामर की अधिकांश कलाएँ कोड के अंदर घटित होती थीं: चाहे एक एल्गोरिथ्म सरल हो, एक अमूर्त सुरुचिपूर्ण हो, या एक प्रणाली जो यथासंभव कम संरचना के साथ पर्याप्त संभावनाओं को समाहित करने में सक्षम हो। इस तरह की सुंदरता गायब नहीं होगी क्योंकि एजेंट आ गए हैं।

लेकिन जैसे-जैसे अधिक कार्यान्वयन कार्य एजेंटों के पास जाता है, मानव निर्माण का केंद्र ऊपर की ओर बढ़ता है। सॉफ़्टवेयर की कला समग्र रूप से कार्य में व्यक्त की जाएगी: कौन सी समस्याएँ चुननी हैं, किसके जीवन को समझना है, क्या क्रम स्थापित करना है, कौन सी संभावनाएँ छोड़नी हैं, उपयोगकर्ताओं को कैसे प्रतिक्रिया देनी है, और कार्य को उनके जीवन में कैसे प्रवेश करना चाहिए।

उत्पाद और अनुभव के स्तर पर सृजन सदैव अस्तित्व में रहा है। परिवर्तन यह है कि जब कार्यान्वयन अब हमारा अधिकांश ध्यान नहीं लेता है, तो ये चिंताएँ अधिक सॉफ़्टवेयर निर्माताओं का मुख्य कार्य बन सकती हैं।

सुरुचिपूर्ण कोड अभी भी मायने रखता है, लेकिन कोड कभी भी सॉफ़्टवेयर की संपूर्ण सुंदरता नहीं रहा है। लोगों और एआई द्वारा मिलकर बनाए गए सॉफ़्टवेयर को केवल चलने वाले कोड के ढेर के रूप में नहीं देखा जाना चाहिए, बल्कि सॉफ़्टवेयर के संपूर्ण कार्य के रूप में देखा जाना चाहिए।

यह "नए कलाकारों" द्वारा निहित परिवर्तन है।

मौजूदा पेशेवर शब्दों में, भूमिका एक उत्पाद प्रबंधक और एक वास्तुकार के संयोजन से मिलती जुलती है: दोनों से पूछना कि क्या बनाया जाना चाहिए और किसके लिए, और सिस्टम कैसे सहन कर सकता है और इसकी सीमाएं कहां हैं। लेकिन ये शीर्षक पर्याप्त नहीं हैं. सॉफ्टवेयर के लेखक को स्वाद, सहानुभूति, समझौता करने की क्षमता और समग्र परिणाम की जिम्मेदारी लेने की इच्छा की भी आवश्यकता होती है।

यहां "कलाकार" कोई अधिक महान उपाधि नहीं है, न ही यह आवश्यक रूप से किसी एक व्यक्ति का वर्णन करता है। यह एक संपूर्ण कार्य के लिए जिम्मेदार लेखक की भूमिका है, और एक टीम इसे साझा कर सकती है।

इंजीनियरिंग कार्य को विश्वसनीय रूप से अस्तित्व में रहने देती है। कला यह निर्धारित करती है कि इसका अस्तित्व क्यों है और यह मानव जीवन में कैसे प्रवेश करती है।

इंजीनियरिंग ख़त्म नहीं होगी, और ज़िम्मेदारी को आउटसोर्स नहीं किया जा सकता

नया कलाकार एक अच्छा विचार प्रस्तावित नहीं करता है और फिर बाकी सब कुछ खत्म करने के लिए एआई की प्रतीक्षा करता है।

कागज और कलम के व्यापक हो जाने के बाद भी, लेखन के लिए अभी भी प्रशिक्षण की आवश्यकता थी; कैमरों के व्यापक हो जाने के बाद, फोटोग्राफी के लिए अभी भी निर्णय की आवश्यकता थी। कोडिंग एजेंट कार्यान्वयन की लागत को कम करते हैं, लेकिन वे जटिल प्रणालियों में वास्तुकला, सुरक्षा, प्रदर्शन, गुणवत्ता या रखरखाव को स्वचालित रूप से हल नहीं करते हैं।

तथ्य यह है कि मैं कोड नहीं पढ़ता इसका मतलब यह नहीं है कि मैंने इंजीनियरिंग नियंत्रण छोड़ दिया है। नियंत्रण बिंदु बदल गए हैं: कार्यान्वयन लाइन का निरीक्षण करने से लेकर सिस्टम लक्ष्यों, वास्तुशिल्प सिद्धांतों, डेटा सीमाओं, अनुमति मॉडल, परीक्षण मानकों, अवलोकन और स्वीकृति-परीक्षण परिणामों को परिभाषित करने तक।

इससे काम कम सख्त नहीं होता. यह अन्यत्र सख्ती बरतता है। क्या परीक्षण वास्तविक जोखिमों को कवर करते हैं? क्या रनटाइम परिणाम दिखाते हैं कि सिस्टम अपनी बाधाओं को पूरा करता है? क्या एजेंट के स्पष्टीकरण के लिए कोई सबूत है? यदि कोई सुविधा चलती है, तो क्या वह शिप करने के लिए भी तैयार है? एआई इनमें से प्रत्येक कार्य में भाग ले सकता है, लेकिन एक व्यक्ति को अंततः यह तय करना होगा कि क्या सबूत भरोसेमंद हैं और गलत होने के परिणाम भुगतने होंगे।

बुनियादी ढांचे, सुरक्षा-महत्वपूर्ण सिस्टम और निम्न-स्तरीय सॉफ़्टवेयर सहित कुछ क्षेत्रों में लोगों को कोड के अंदर गहराई से काम करने की आवश्यकता बनी रहेगी। उन्हें कम संख्या में ऐसे लोगों की आवश्यकता हो सकती है जो वास्तव में निचली परतों को पहले से कहीं अधिक समझते हैं। एक नई अमूर्त परत अपने नीचे की परतों को कभी नहीं मिटाती। उच्च-स्तरीय भाषाओं ने असेंबली को समाप्त नहीं किया, और क्लाउड कंप्यूटिंग ने ऑपरेटिंग सिस्टम को समाप्त नहीं किया। एक नई परत अधिक रचनाकारों को हर बार कुछ बनाते समय हर निचली परत को पार करने से बचने देती है।

कोड न लिखने या न पढ़ने का मेरा निर्णय एक बंधी हुई प्रथा है, यह हर किसी के लिए एक नियम नहीं है। इसका मूल्य यह नहीं है कि यह साबित करता है कि कोड अप्रचलित है। इससे मुझे यह देखने में मदद मिलती है कि काम के कौन से हिस्से अभी भी नहीं सौंपे जा सकते हैं जब कोड ही एकमात्र इंटरफ़ेस नहीं रह गया है जिसके माध्यम से लोग सॉफ़्टवेयर को नियंत्रित करते हैं।

पहला है निर्णय. दूसरी जिम्मेदारी है.

अधिक शक्तिशाली उपकरण भी बड़े पैमाने पर औसत दर्जे का उत्पादन कर सकते हैं। जब कार्यान्वयन सस्ता हो जाता है, तो हमें सबसे पहले अधिक दोहराव वाला, अपरिष्कृत सॉफ़्टवेयर मिल सकता है जो किसी वास्तविक आवश्यकता को पूरा नहीं करता है। कागज और कलम स्वतः ही साहित्य का निर्माण नहीं करते। कोडिंग एजेंट स्वचालित रूप से सॉफ़्टवेयर पुनर्जागरण उत्पन्न नहीं करेंगे।

एआई कमी को दूर नहीं करता; वह केवल उसे दूसरी जगह ले जाता है।

सॉफ़्टवेयर उत्पादन मुख्य रूप से प्रोग्रामिंग कौशल, इंजीनियरिंग संसाधनों और कार्यान्वयन समय से बाधित होता था। जैसे-जैसे वे बाधाएं कम होती जाती हैं, यह निर्णय करना कि कौन सी समस्याएं मायने रखती हैं, उत्पाद अंतर्ज्ञान, सिस्टम की समझ, स्वाद, लोगों की समझ और परिणामों की जिम्मेदारी लेने की इच्छा अपेक्षाकृत कम हो जाती है।

जैसे-जैसे "इसे कैसे बनाएं" सस्ता होता जाता है, "क्या बनाएं" अधिक महंगा होता जाता है।

कोड के लेखकों से लेकर सॉफ्टवेयर के लेखकों तक

ब्रेट टेलर ने आर्य असेमनफ़र के एक अवलोकन का हवाला दिया: एआई आपके लिए मसौदा तैयार कर सकता है, लेकिन आप अभी भी लेखक हैं। [7] एडी उस्मानी ने वास्तुकार और प्रधान संपादक के रूप में डेवलपर की नई भूमिका का वर्णन किया है। [8]

एक लेखक को हर वह कार्य नहीं करना पड़ता जो किसी कृति का निर्माण करता हो। आर्किटेक्ट हर ईंट नहीं रखते, और निर्देशक फिल्म सेट पर हर कैमरा संचालित नहीं करते। लेकिन उन्हें पता होना चाहिए कि काम क्या होना चाहिए, यह आकलन करना चाहिए कि क्या यह सफल होगा, और समग्र रूप से काम की जिम्मेदारी लेनी चाहिए।

यही बदलाव सॉफ्टवेयर में भी हो रहा है.

हम सॉफ़्टवेयर के लेखक की पहचान यह पूछकर करते थे कि कोड किसने लिखा है। भविष्य में, लेखकत्व प्रश्नों के विभिन्न सेटों पर निर्भर हो सकता है: समस्या को किसने परिभाषित किया? प्रतिबंध किसने स्थापित किये? महत्वपूर्ण समझौता किसने किया? किसने निर्णय लिया कि कार्य पूरा हो गया? और दुनिया में इसके प्रवेश के बाद जो होता है उसकी ज़िम्मेदारी कौन लेता है?

इससे सॉफ्टवेयर की आर्थिक इकाई भी बदल सकती है। अतीत में, सॉफ़्टवेयर निर्माण को उचित ठहराने के लिए किसी आवश्यकता को आम तौर पर पर्याप्त लोगों द्वारा साझा करना पड़ता था। जब कार्यान्वयन लागत काफी कम हो जाती है, तो एक टीम, एक परिवार या यहां तक कि एक व्यक्ति का विशेष वर्कफ़्लो अपने स्वयं के सॉफ़्टवेयर की गारंटी दे सकता है। हर किसी को प्रोग्रामर बनना ज़रूरी नहीं है, लेकिन अधिक लोग सॉफ़्टवेयर के लेखक बन सकते हैं।

एआई मानव नियंत्रण बिंदुओं और सृजन के केंद्र को एक अमूर्त परत पर ले जाते हुए अधिक कार्यान्वयन कार्य को नीचे की ओर धकेलता है। प्रोग्रामर अब केवल कोड के लेखक नहीं रहेंगे। तेजी से, वे सॉफ्टवेयर के संपूर्ण कार्यों के लेखक बन जाएंगे - मेरा मतलब है "नए कलाकार"।

नये कागज और कलम आ गये हैं। लेकिन एक नया पुनर्जागरण अपने आप नहीं आएगा। यह इस बात पर निर्भर नहीं करता है कि कितने कोड एजेंट उत्पन्न कर सकते हैं, बल्कि इस बात पर निर्भर करता है कि क्या हमारे पास किसी प्रश्न का उत्तर देने के लिए "यह कैसे बनाया जा सकता है?" से अधिक कठिन निर्णय और जिम्मेदारी लेने की इच्छा है।

क्या बनाने लायक है और हम कैसे चाहते हैं कि लोग इसका अनुभव करें?

संदर्भ

[1] आंद्रेज कारपैथी, “वाइब कोडिंग” का परिचय देने वाली एक्स पोस्ट, 2025-02-02।

[2] आंद्रेज कारपैथी, “एजेंटिक इंजीनियरिंग” का प्रस्ताव देने वाली एक्स पोस्ट, 2026-02-04।

[3] लियू निंगक्सिन, "वांग जियान: इनोवेशन 'अपूर्णता' और 'सीमाओं को पार करने' से आता है", 21वीं सदी बिजनेस हेराल्ड, 2025-09-25।

[4] एलन एम. ट्यूरिंग, "इंटेलिजेंट मशीनरी", राष्ट्रीय भौतिक प्रयोगशाला रिपोर्ट, 1948।

[5] डोनाल्ड ई. नुथ, "एक कला के रूप में कंप्यूटर प्रोग्रामिंग", एसीएम के संचार, 17(12), 1974, पीपी. 667-673।

[6] पॉल ग्राहम, "हैकर्स एंड पेंटर्स", मई 2003।

[7] ब्रेट टेलर, "एआई आपका घोस्ट राइटर है, लेकिन आप लेखक हैं", लिंक्डइन, 2026-02-10।

[8] एडी उस्मानी, वाइब कोडिंग से परे, ओ'रेली मीडिया, अगस्त 2025।

Saya tidak menulis satu baris kode pun. Saya juga tidak membacanya.

Namun bukan berarti saya menyerahkan produknya kepada AI. Saya tetap memutuskan masalah mana yang harus mereka selesaikan, menentukan cara kerja sistem, menilai batasan mana yang tidak dapat dilintasi, memverifikasi apakah hasilnya dapat diandalkan, dan bertanggung jawab atas perangkat lunak akhir. Yang berubah hanyalah antarmuka saya dengan implementasinya.

Hal ini memaksa saya untuk mempertimbangkan kembali pertanyaan yang tadinya tampak sederhana: jika seseorang tidak lagi menulis kode dengan tangan, namun tetap mendefinisikan pekerjaannya, memutuskan apakah berhasil, dan tetap bertanggung jawab, apakah mereka masih pembuat perangkat lunak tersebut?

Praktek ini tidak membuktikan bahwa semua perangkat lunak dapat dibangun dengan cara ini. Bahkan tidak membuktikan bahwa produk yang belum dirilis tersebut akan sukses di pasaran. Namun untuk jenis aplikasi yang kami buat, alur kerja yang berpusat pada agen pengkodean tidak lagi sekadar cara untuk memprogram lebih cepat. Hal ini menjadi pendekatan rekayasa yang dapat mempertahankan perencanaan, implementasi, pengujian, koreksi, dan iterasi.

Perubahan penting bukanlah “AI dapat menulis kode.” Implementasi dulunya merupakan salah satu bagian yang paling langka dalam pembuatan perangkat lunak; sekarang mulai surut ke latar belakang.

Ketika implementasi bukan lagi hal yang paling langka, apa jadinya pekerjaan manusia?

Itulah pertanyaan dari esai ini.

Batasan AI Sedang Bergerak

AI tidak pernah menjadi istilah yang pasti. Orang-orang cenderung menyebut sesuatu sebagai AI, sementara komputer belum dapat melakukannya dengan andal; begitu kemampuannya matang dan memasuki produk sehari-hari, teknologi tersebut dengan cepat menjadi teknologi biasa dan tidak lagi tampak seperti AI.

Jalanku sendiri juga mengikuti batasan ini. Di sekolah menengah dan universitas, saya mengerjakan robot beroda, menggunakan sensor dan kontrol umpan balik untuk membuat mereka mengikuti jalur, menghindari rintangan, dan berkoordinasi dalam formasi. Selama sekolah pascasarjana, saya mempelajari visi komputer sambil bergabung dengan SenseTime yang baru didirikan sebagai karyawan pendiri awal. Saya membantu menghadirkan teknologi deteksi keaktifan wajah dan visi industri ke dalam aplikasi berskala besar, termasuk ponsel pintar dan kereta berkecepatan tinggi. Saat ini, model yayasan serba guna dan agen yang mereka kuasai telah mendorong batasan tersebut kembali. Sistem ini tidak lagi hanya mengatasi masalah-masalah yang terisolasi. Mereka mulai memahami tujuan, menggunakan alat, dan terus bertindak sebagai respons terhadap umpan balik; pekerjaan saya telah beralih ke produk ini juga. Melihat ke belakang, mulai dari mengendalikan gerakan dan memahami gambar hingga menyelesaikan seluruh tugas, mesin menjalani rangkaian kerja yang lebih panjang dan lebih lengkap.

Oleh karena itu, dalam esai ini, AI terutama mengacu pada agen yang didorong oleh model dasar tujuan umum, dengan agen pengkodean sebagai contoh yang representatif. Perkembangan mereka mengarah pada pelaksanaan tugas-tugas yang lebih luas secara otonom, evolusi diri secara bertahap, dan bahkan kemampuan untuk melatih penerus mereka sendiri.

Pada tahun 2025, Andrej Karpathy menggunakan istilah “vibe coding” untuk menggambarkan gaya pemrograman yang longgar: memberi tahu AI apa yang Anda inginkan, menerima kode yang dihasilkan, mengembalikan pesan kesalahan kepadanya, dan bahkan melupakan keberadaan kode itu. [1] Namun, melepaskan kendali sejauh ini memiliki satu prasyarat: biaya kegagalan harus rendah. Saat itu, untuk produk serius, kami masih menggunakan Cursor. Pengembang manusia memimpin pekerjaan dan tetap bertanggung jawab atas kodenya; agen hanya membantu.

Pada awal tahun 2026, kita melihat perbatasan kembali bergerak maju. Karpathy kemudian menyebut cara kerja baru ini sebagai “rekayasa agen”: pengembang tidak lagi hanya menggunakan AI untuk menyelesaikan kode, namun mengatur dan mengawasi agen saat mereka menjalankan tugas teknis sambil tetap bertanggung jawab atas peninjauan dan kualitas. [2] Nama tidak penting. Yang penting adalah AI beralih dari memberikan saran satu per satu ke tindakan berkelanjutan dalam batasan.

Bagi beberapa pembuat perangkat lunak, bahasa dan dokumen alami telah menjadi lapisan baru untuk mengekspresikan maksud.

Kode Menjadi Artefak Perantara

Sejarah komputasi juga merupakan sejarah penambahan lapisan abstraksi.

Manusia pertama kali mengoperasikan mesin dengan sakelar dan kabel patch. Kemudian muncul kode mesin, bahasa assembly, dan bahasa pemrograman tingkat tinggi. Setiap lapisan baru menyembunyikan beberapa kompleksitas di bawah ini dan memungkinkan orang bekerja lebih dekat dengan tujuan mereka.

Agen pengkodean menambahkan lapisan abstraksi baru ke pengembangan perangkat lunak. Mereka adalah sesuatu seperti super-kompiler nondeterministik: kompiler tradisional menerjemahkan program yang ditentukan secara formal ke dalam instruksi mesin, sementara agen pengkodean mencoba mengungkap maksud manusia ke dalam antarmuka, data, layanan, dan kode.

Perbedaan itu penting. Bahasa manusia bersifat ambigu. Persyaratan seringkali tidak lengkap, dan batasan dapat menimbulkan konflik. Agen tidak dapat menerjemahkan kalimat secara mekanis menjadi satu hasil yang benar. Hal ini harus melalui siklus pemahaman, perencanaan, implementasi, pelaksanaan, dan verifikasi.

Bahasa alami belum menggantikan bahasa pemrograman. Lebih tepatnya, bahasa dan dokumen alami menjadi lapisan maksud yang dikelola oleh manusia, sementara kode semakin berfungsi sebagai media implementasi yang dihasilkan dan dikelola oleh agen.

Hal ini menjadikan kode lebih seperti artefak perantara, namun “perantara” bukan berarti tidak penting. Kode tetap harus benar, aman, dan dapat dipelihara. Ini mungkin tidak perlu ditulis dan dibaca baris demi baris oleh seseorang. Kebanyakan pemrogram tidak memeriksa kode mesin yang dikeluarkan oleh kompiler, namun mereka tetap bertanggung jawab atas apa yang dilakukan program tersebut.

Ini mengubah apa yang perlu kita perjelas.

Dokumentasi dulunya merupakan penjelasan kode. Dalam pekerjaan kami, hubungan tersebut mulai terbalik: semakin banyak kode yang dihasilkan dan diverifikasi dari dokumen. Mengapa produk itu ada, bagaimana sistem harus bekerja, batasan mana yang tidak dapat dilintasi, dan bukti apa yang menunjukkan bahwa produk tersebut memenuhi persyaratannya—hal-hal ini, yang dulu dianggap sebagai lampiran pada kode, menjadi sumber dari perangkat lunak itu sendiri.

Lalu: "Bicara itu murah. Tunjukkan kodenya."

Sekarang: "Kodenya murah. Tunjukkan dokumennya."

Tidak menulis kode dengan tangan tidak menurunkan tuntutan ekspresi. Itu membesarkan mereka. Di masa lalu, sebuah gagasan ambigu sempat muncul ke permukaan dan menjadi lebih jelas melalui proses implementasi yang panjang. Sekarang agen dapat dengan cepat mengubahnya menjadi sistem yang berfungsi dan tampak lengkap. Ambiguitasnya belum hilang. Hal ini hanya terkubur dalam implementasinya, yang nantinya akan muncul sebagai kegagalan dan kerugian.

AI tidak membebaskan kita dari kewajiban berpikir. AI hanya membuat gagasan yang kabur lebih sulit disembunyikan di balik kesibukan implementasi.

Separuh Bagian Lain dari “Kertas dan Pena”

Pada tahun 2025, Wang Jian membandingkan AI dengan “kertas dan pena baru” umat manusia: bukan pemikiran itu sendiri, melainkan perpanjangan dari pemikiran manusia. [3] Saya suka metafora ini.

Ini berisi simetri sejarah yang menarik. Pada tahun 1948, Alan Turing membayangkan seseorang yang dilengkapi kertas, pensil, dan penghapus, mengikuti serangkaian aturan, yang perilakunya dapat dianggap sebagai mesin universal. [4] Orang-orang kemudian menggunakan kertas dan pensil untuk menjelaskan bagaimana seseorang dapat mensimulasikan sebuah mesin. Hampir delapan puluh tahun kemudian, arahnya tampaknya berbalik. Mesin ini menjadi kertas dan pena baru, membantu orang mengungkapkan niat mereka ke dunia yang bisa dijalankan.

Metaforanya juga mengingatkan saya pada universitas. Selain tidur, saya mungkin menghabiskan sepertiga waktu saya bolak-balik antara perangkat lunak dan perangkat keras: menginstal sistem operasi, mengonfigurasi lingkungan, alat pembelajaran, mengutak-atik mikrokontroler, men-debug robot beroda dan membuat mereka berkoordinasi dalam formasi, dan membuat demo apa pun yang menarik minat saya. Saya menikmati prosesnya, namun sering kali saya menghabiskan lebih banyak waktu untuk mempersiapkan karya daripada mencipta—seperti seorang pelukis yang selalu mencari kertas, membuat pigmen, dan memperbaiki kuas.

Menyebut AI sebagai kertas dan pena baru tidak berarti AI dapat melakukan segalanya. Kertas tidak menulis novel. Pigmen tidak menghasilkan gambar yang bagus, dan kamera tidak menghasilkan film yang bagus. Alat-alat tersebut menurunkan biaya untuk berekspresi, namun tidak menentukan apa yang pantas untuk diungkapkan.

Agen pengkodean jauh lebih aktif daripada kertas dan pena. Mereka menawarkan saran, melaksanakan tugas, dan membuat pilihan dalam lingkup terbatas. Namun sampai mereka dapat mengambil tanggung jawab atas tujuan dan konsekuensi sebuah karya, partisipasi yang lebih besar tidak secara otomatis menjadikan mereka sebagai penulis.

Yang menarik minat saya adalah separuh “kertas dan pena baru” lainnya:

Jika kita mempunyai kertas dan pena baru, seniman seperti apa yang kita perlukan?

Pusat Pembuatan Perangkat Lunak Sedang Meningkat

Gagasan bahwa programmer adalah seniman bukanlah hal baru.

Pada tahun 1974, Donald Knuth menjelaskan dalam “Pemrograman Komputer sebagai Seni” mengapa pemrograman memerlukan pengetahuan, keterampilan, dan kreativitas, dan bagaimana hal itu dapat menghasilkan objek yang indah. [5] Pada tahun 2003, Paul Graham berpendapat dalam “Hackers and Painters” bahwa peretas dan pelukis sama-sama pembuat. Bagi pembuat perangkat lunak, komputer adalah media berekspresi seperti halnya cat bagi seorang pelukis atau beton bagi seorang arsitek. [6]

AI bukanlah yang pertama kali menjadikan programmer menjadi seniman. Hal ini mengubah tempat di mana seni biasanya terjadi.

Sebagian besar karya pemrogram biasanya terjadi di dalam kode: apakah suatu algoritme cerdik, abstraksinya elegan, atau suatu sistem mampu menampung cukup banyak kemungkinan dengan struktur sesedikit mungkin. Keindahan seperti ini tidak akan hilang karena agen sudah datang.

Namun seiring dengan semakin banyaknya pekerjaan implementasi yang diserahkan kepada agen, pusat penciptaan manusia pun ikut meningkat. Seni perangkat lunak akan semakin terekspresikan dalam karya secara keseluruhan: masalah mana yang harus dipilih, kehidupan siapa yang harus dipahami, tatanan apa yang harus dibangun, kemungkinan mana yang harus dilupakan, bagaimana menanggapi pengguna, dan bagaimana karya tersebut harus memasuki kehidupan mereka.

Penciptaan pada tingkat produk dan pengalaman selalu ada. Perubahannya adalah ketika implementasi tidak lagi menyita sebagian besar perhatian kita, kekhawatiran ini dapat menjadi pekerjaan utama bagi lebih banyak pembuat perangkat lunak.

Kode yang elegan tetap penting, namun kode tidak pernah menjadi keseluruhan keindahan perangkat lunak. Perangkat lunak yang dibuat oleh manusia dan AI bersama-sama tidak boleh dilihat hanya sebagai tumpukan kode yang berjalan, namun sebagai karya perangkat lunak yang utuh.

Inilah perubahan yang disiratkan oleh “artis baru”.

Dalam istilah profesional yang ada, peran tersebut menyerupai kombinasi manajer produk dan arsitek: menanyakan apa yang harus dibuat dan untuk siapa, serta bagaimana sistem dapat bertahan dan di mana letak batasannya. Namun gelar-gelar itu saja tidak cukup. Pembuat perangkat lunak juga membutuhkan selera, empati, kemampuan untuk mengambil pengorbanan, dan kemauan untuk bertanggung jawab atas hasil keseluruhan.

“Artis” di sini bukanlah gelar yang lebih mulia, juga tidak serta merta menggambarkan satu orang. Ini adalah peran seorang penulis yang bertanggung jawab atas sebuah karya yang lengkap, dan sebuah tim dapat membagikannya.

Teknik memungkinkan pekerjaan tetap ada. Seni menentukan mengapa ia ada dan bagaimana ia memasuki kehidupan manusia.

Rekayasa Tidak Akan Hilang, dan Tanggung Jawab Tidak Dapat Dialihdayakan

Artis baru tidak mengajukan ide bagus lalu menunggu AI menyelesaikan semuanya.

Bahkan setelah kertas dan pena tersebar luas, menulis masih memerlukan pelatihan; setelah kamera tersebar luas, fotografi masih memerlukan penilaian. Agen pengkodean menurunkan biaya implementasi, namun mereka tidak secara otomatis menyelesaikan arsitektur, keamanan, kinerja, kualitas, atau pemeliharaan dalam sistem yang kompleks.

Fakta bahwa saya tidak membaca kode tidak berarti saya telah mengabaikan kendali teknik. Titik kontrol telah berubah: dari memeriksa implementasi baris demi baris hingga menentukan tujuan sistem, prinsip arsitektur, batasan data, model izin, standar pengujian, kemampuan observasi, dan hasil pengujian penerimaan.

Hal ini tidak membuat pekerjaan menjadi kurang ketat. Ini menempatkan ketegasan di tempat lain. Apakah tes tersebut mencakup risiko sebenarnya? Apakah hasil runtime menunjukkan bahwa sistem memenuhi batasannya? Apakah ada bukti atas penjelasan agen tersebut? Jika suatu fitur berjalan, apakah fitur tersebut juga siap dikirimkan? AI dapat berpartisipasi dalam masing-masing tugas ini, namun seseorang pada akhirnya harus memutuskan apakah bukti tersebut dapat dipercaya dan menanggung konsekuensi jika melakukan kesalahan.

Beberapa bidang—termasuk infrastruktur, sistem yang sangat penting bagi keselamatan, dan perangkat lunak tingkat rendah—akan terus mengharuskan orang untuk bekerja jauh di dalam kode etik. Mereka mungkin membutuhkan sejumlah kecil orang yang benar-benar memahami lapisan bawah lebih dari sebelumnya. Lapisan abstraksi baru tidak pernah menghapus lapisan di bawahnya. Bahasa tingkat tinggi tidak menghilangkan perakitan, dan komputasi awan tidak menghilangkan sistem operasi. Lapisan baru memungkinkan lebih banyak pembuat konten menghindari melintasi setiap lapisan bawah setiap kali mereka membuat sesuatu.

Keputusan saya untuk tidak menulis atau membaca kode adalah praktik yang dibatasi, bukan aturan untuk semua orang. Nilainya bukan berarti membuktikan bahwa kode sudah usang. Ini membantu saya melihat bagian pekerjaan mana yang masih belum dapat diserahkan ketika kode tidak lagi menjadi satu-satunya antarmuka yang digunakan orang untuk mengontrol perangkat lunak.

Yang pertama adalah penghakiman. Yang kedua adalah tanggung jawab.

Alat yang lebih kuat juga dapat menghasilkan keadaan yang biasa-biasa saja dalam skala yang lebih besar. Ketika implementasi menjadi lebih murah, pertama-tama kita mungkin akan mendapatkan perangkat lunak yang lebih repetitif dan kasar yang tidak memenuhi kebutuhan nyata. Kertas dan pena tidak secara otomatis menghasilkan lektur. Agen pengkodean tidak akan secara otomatis menghasilkan kebangkitan perangkat lunak.

AI tidak menghapus kelangkaan; AI hanya memindahkannya.

Produksi perangkat lunak biasanya dibatasi terutama oleh keterampilan pemrograman, sumber daya teknik, dan waktu implementasi. Ketika kendala-kendala tersebut mereda, penilaian mengenai masalah mana yang penting, intuisi produk, pemahaman sistem, selera, pemahaman terhadap orang-orang, dan kemauan untuk mengambil tanggung jawab atas konsekuensi menjadi relatif lebih langka.

Ketika “cara membuatnya” menjadi lebih murah, “apa yang harus dibuat” menjadi lebih mahal.

Dari Penulis Kode hingga Penulis Perangkat Lunak

Bret Taylor mengutip pengamatan Arya Asemanfar: AI dapat membuat rancangan untuk Anda, tetapi Anda tetaplah penulisnya. [7] Addy Osmani menggambarkan peran baru pengembang sebagai arsitek dan pemimpin redaksi. [8]

Seorang pengarang tidak harus melakukan setiap tindakan yang menghasilkan sebuah karya. Arsitek tidak meletakkan setiap batu bata, dan sutradara tidak mengoperasikan setiap kamera di lokasi syuting. Namun mereka harus mengetahui apa yang seharusnya dilakukan dalam pekerjaan tersebut, menilai apakah pekerjaan tersebut berhasil, dan bertanggung jawab atas pekerjaan tersebut secara keseluruhan.

Perubahan yang sama juga terjadi pada perangkat lunak.

Kami biasa mengidentifikasi pembuat perangkat lunak dengan menanyakan siapa yang menulis kodenya. Di masa depan, kepenulisan mungkin semakin bergantung pada serangkaian pertanyaan berbeda: Siapa yang mendefinisikan masalahnya? Siapa yang menetapkan batasan tersebut? Siapa yang melakukan pengorbanan penting? Siapa yang memutuskan bahwa pekerjaan telah selesai? Dan siapa yang bertanggung jawab atas apa yang terjadi setelah ia lahir ke dunia?

Hal ini juga dapat mengubah unit ekonomi perangkat lunak. Di masa lalu, suatu kebutuhan biasanya harus dimiliki oleh cukup banyak orang untuk membenarkan pembuatan perangkat lunak untuk kebutuhan tersebut. Ketika biaya implementasi turun cukup jauh, alur kerja tertentu dari sebuah tim, sebuah keluarga, atau bahkan satu orang mungkin memerlukan perangkat lunaknya sendiri. Tidak semua orang harus menjadi programmer, namun lebih banyak orang bisa menjadi penulis perangkat lunak.

AI mendorong lebih banyak pekerjaan implementasi ke bawah sambil memindahkan titik kontrol manusia dan pusat penciptaan ke atas satu lapisan abstraksi. Pemrogram tidak lagi hanya menjadi pembuat kode. Semakin lama, mereka akan menjadi penulis karya perangkat lunak yang lengkap—maksud saya “seniman baru”.

Kertas dan pena baru telah tiba. Namun kebangkitan baru tidak akan terjadi secara otomatis. Hal ini tidak bergantung pada seberapa banyak agen kode dapat menghasilkan, namun pada apakah kita memiliki penilaian—dan kesediaan untuk mengambil tanggung jawab—untuk menjawab pertanyaan yang lebih sulit daripada “bagaimana hal itu dapat dilakukan?”

Apa yang layak diciptakan, dan bagaimana kita ingin orang-orang merasakannya?

Referensi

[1] Andrej Karpathy, postingan X yang memperkenalkan “vibe coding”, 02-02-2025.

[2] Andrej Karpathy, postingan X mengusulkan “rekayasa agen”, 04-02-2026.

[3] Liu Ningxin, “Wang Jian: Inovasi Berasal dari 'Ketidaksempurnaan' dan 'Melintasi Batas'”, 21st Century Business Herald, 25-09-2025.

[4] Alan M. Turing, "Mesin Cerdas", laporan Laboratorium Fisika Nasional, 1948.

[5] Donald E. Knuth, “Pemrograman Komputer sebagai Seni”, Komunikasi ACM, 17(12), 1974, hlm. 667–673.

[6] Paul Graham, “Peretas dan Pelukis”, Mei 2003.

[7] Bret Taylor, “AI adalah penulis untuk orang lain, tetapi Anda adalah penulisnya”, LinkedIn, 10-02-2026.

[8] Addy Osmani, Beyond Vibe Coding, O'Reilly Media, Agustus 2025.

Non ho scritto una sola riga di codice. Né ne ho letto uno.

Ma ciò non significa che abbia consegnato i prodotti all’IA. Ho comunque deciso quali problemi dovessero risolvere, definito come dovessero funzionare i sistemi, giudicato quali confini non potessero essere superati, verificato l’affidabilità dei risultati e assunto la responsabilità del software finale. A cambiare è stata soltanto la mia interfaccia con l’implementazione.

Questo mi ha costretto a riconsiderare una domanda che un tempo sembrava semplice: se qualcuno non scrive più il codice a mano, ma definisce ancora il lavoro, decide se riesce e ne rimane responsabile, è ancora l’autore del software?

Questa pratica non dimostra che tutto il software possa essere costruito in questo modo. Non dimostra nemmeno che questi prodotti inediti avranno successo sul mercato. Ma per il tipo di applicazioni che creiamo, un flusso di lavoro incentrato sugli agenti di codifica non è più semplicemente un modo per programmare più velocemente. Sta diventando un approccio ingegneristico in grado di sostenere la pianificazione, l'implementazione, il test, la correzione e l'iterazione.

Il cambiamento importante non è che “l’intelligenza artificiale può scrivere codice”. L'implementazione era una delle parti più scarse della creazione di software; ora sta cominciando a retrocedere in secondo piano.

Quando l’implementazione non sarà più la parte più scarsa, cosa ne sarà del lavoro umano?

Questa è la domanda di questo saggio.

Il confine dell’intelligenza artificiale si sta spostando

L’intelligenza artificiale non è mai stata un termine fisso. Le persone tendono a chiamare qualcosa IA finché i computer non riescono ancora a farlo in modo affidabile; quando una capacità matura ed entra nei prodotti di uso quotidiano, diventa rapidamente una tecnologia ordinaria e smette di sembrare intelligenza artificiale.

Anche il mio percorso ha seguito questo confine. Alle scuole medie e all'università ho lavorato su robot su ruote, utilizzando sensori e controllo del feedback per farli seguire percorsi, evitare ostacoli e coordinarsi nella formazione. Durante la scuola di specializzazione, ho studiato visione artificiale e allo stesso tempo sono entrato a far parte della neonata SenseTime come uno dei primi dipendenti fondatori. Ho contribuito a portare le tecnologie di rilevamento della vitalità dei volti e di visione industriale in applicazioni su larga scala, inclusi smartphone e treni ad alta velocità. Oggi, i modelli fondazionali generalisti e gli agenti da essi alimentati hanno nuovamente spinto in avanti il confine. Questi sistemi non affrontano più solo problemi isolati. Stanno iniziando a comprendere gli obiettivi, a utilizzare gli strumenti e a continuare ad agire in risposta al feedback; anche il mio lavoro si è spostato verso questi prodotti. Guardando indietro, dal controllo del movimento e dalla comprensione delle immagini al completamento di intere attività, le macchine stanno intraprendendo catene di lavoro più lunghe e complete.

In questo saggio, quindi, l’intelligenza artificiale si riferisce principalmente ad agenti guidati da modelli di base di carattere generale, con gli agenti di codifica come esempio rappresentativo. Il loro sviluppo punta verso l’esecuzione autonoma di compiti a lungo termine, una graduale autoevoluzione e persino la capacità di formare i propri successori.

Nel 2025, Andrej Karpathy ha utilizzato il “vibe coding” per descrivere uno stile di programmazione ampio: dì all’IA cosa vuoi, accetta il codice generato, restituiscigli messaggi di errore e dimentica persino che il codice esiste. [1] Ma lasciare andare così lontano ha una precondizione: il costo del fallimento deve essere basso. All'epoca, per i prodotti seri, utilizzavamo ancora Cursor. Gli sviluppatori umani guidavano il lavoro e rimanevano responsabili del codice; l'agente ha assistito.

All’inizio del 2026, abbiamo visto il confine spostarsi nuovamente in avanti. Karpathy in seguito chiamò il nuovo modo di lavorare “ingegneria degli agenti”: gli sviluppatori non utilizzano più semplicemente l’intelligenza artificiale per completare il codice, ma organizzano e supervisionano gli agenti mentre svolgono compiti di ingegneria mantenendo la responsabilità della revisione e della qualità. [2] Il nome non è importante. Ciò che conta è che l’intelligenza artificiale sta passando dall’offrire suggerimenti uno alla volta all’azione sostenuta entro limiti.

Per alcuni creatori di software, il linguaggio naturale e i documenti stanno già diventando un nuovo livello per esprimere le intenzioni.

Il codice sta diventando un artefatto intermedio

La storia dell’informatica è anche una storia di aggiunta di livelli di astrazione.

Per prima cosa le persone azionavano le macchine con interruttori e cavi patch. Poi sono arrivati il codice macchina, l’assembly e i linguaggi di programmazione di alto livello. Ogni nuovo livello nascondeva parte della complessità sottostante e consentiva alle persone di lavorare più vicino alle proprie intenzioni.

Gli agenti di codifica aggiungono un nuovo livello di astrazione allo sviluppo del software. Sono qualcosa come un supercompilatore non deterministico: un compilatore tradizionale traduce un programma formalmente specificato in istruzioni macchina, mentre un agente di codifica cerca di sviluppare l'intento umano in interfacce, dati, servizi e codice.

La differenza conta. Il linguaggio umano è ambiguo. I requisiti sono spesso incompleti e i vincoli possono entrare in conflitto. Un agente non può tradurre meccanicamente una frase in un unico risultato corretto. Deve passare attraverso la comprensione, la pianificazione, l’implementazione, l’esecuzione e la verifica.

Il linguaggio naturale non ha sostituito i linguaggi di programmazione. Più precisamente, il linguaggio naturale e i documenti stanno diventando uno strato di intenti gestito dalle persone, mentre il codice funge sempre più da mezzo di implementazione generato e gestito dagli agenti.

Ciò rende il codice più simile a un artefatto intermedio, ma “intermedio” non significa non importante. Il codice deve ancora essere corretto, sicuro e gestibile. Potrebbe non essere necessario scriverlo e leggerlo riga per riga da una persona. La maggior parte dei programmatori non controlla il codice macchina emesso da un compilatore, ma rimane responsabile di ciò che fa il programma.

Ciò cambia ciò che dobbiamo chiarire.

La documentazione era una spiegazione del codice. Nel nostro lavoro, la relazione sta iniziando a invertirsi: viene generato e verificato più codice dai documenti. Perché esiste il prodotto, come dovrebbe funzionare il sistema, quali confini non possono essere superati e quali prove dimostrano che soddisfa i suoi requisiti: queste cose, una volta trattate come allegati al codice, stanno diventando la fonte del software stesso.

Poi: "Parlare costa poco. Mostrami il codice".

Ora: "Il codice costa poco. Mostrami il documento".

Non scrivere il codice a mano non riduce le esigenze di espressione. Li solleva. In passato, un'idea ambigua aveva il tempo di emergere e diventare più chiara nel corso di un lungo processo di implementazione. Ora un agente può trasformarlo rapidamente in un sistema funzionante e apparentemente completo. L'ambiguità non è scomparsa. È stato semplicemente sepolto nell’implementazione, dove emergerà in seguito sotto forma di fallimenti e perdite.

L’intelligenza artificiale non ci risparmia la necessità di pensare. Rende solo più difficile nascondere idee vaghe dietro la frenesia dell’implementazione.

L’altra metà di “Carta e penna”

Nel 2025, Wang Jian ha paragonato l’intelligenza artificiale alla “nuova carta e penna” dell’umanità: non il pensiero in sé, ma un’estensione del pensiero umano. [3] Mi piace questa metafora.

Contiene un'interessante simmetria storica. Nel 1948 Alan Turing immaginò una persona dotata di carta, matita e gomma, che seguiva una serie di regole, il cui comportamento poteva essere considerato quello di una macchina universale. [4] Le persone hanno quindi utilizzato carta e matita per spiegare come una persona potrebbe simulare una macchina. Quasi ottant’anni dopo, la direzione sembra essersi invertita. La macchina sta diventando la nuova carta e penna, aiutando le persone a manifestare le proprie intenzioni in mondi che possono funzionare.

La metafora mi ricorda anche l'università. A parte dormire, probabilmente ho passato un terzo del mio tempo spostandomi avanti e indietro tra software e hardware: installando sistemi operativi, configurando ambienti, strumenti di apprendimento, armeggiando con microcontrollori, debuggando robot su ruote e facendoli coordinare in formazione, e costruendo qualunque demo mi interessasse. Mi è piaciuto il processo, ma spesso ho trascorso più tempo a prepararmi per creare che a creare, come un pittore che cerca sempre la carta, produce pigmenti e ripara i pennelli.

Chiamare l’intelligenza artificiale “la nuova carta e penna” non significa che possa fare tutto. La carta non scrive un romanzo. I pigmenti non dipingono una buona immagine e una macchina fotografica non produce una buona pellicola. Gli strumenti abbassano il costo dell’espressione, ma non decidono cosa vale la pena esprimere.

Gli agenti di codifica sono molto più attivi di carta e penna. Offrono suggerimenti, eseguono compiti e fanno scelte in un ambito limitato. Ma finché non riescono ad assumersi la responsabilità dello scopo e delle conseguenze di un’opera, una maggiore partecipazione non li rende automaticamente autori.

Ciò che mi interessa è l’altra metà di “carta e penna nuove”:

Se abbiamo carta e penna nuove, di che tipo di artisti abbiamo bisogno?

Il centro della creazione di software si sta espandendo

L’idea che i programmatori siano artisti non è nuova.

Nel 1974, Donald Knuth spiegò in “Computer Programming as an Art” perché la programmazione richiede conoscenza, abilità e creatività e come può produrre oggetti di bellezza. [5] Nel 2003, Paul Graham ha sostenuto in “Hackers and Painters” che gli hacker e i pittori sono entrambi creatori. Per i creatori di software, i computer sono un mezzo di espressione proprio come la pittura lo è per un pittore o il cemento per un architetto. [6]

L’intelligenza artificiale non sta rendendo i programmatori artisti per la prima volta. Sta cambiando dove l'arte si svolge principalmente.

Gran parte dell’arte di un programmatore si svolgeva all’interno del codice: se un algoritmo era ingegnoso, un’astrazione elegante o un sistema in grado di contenere abbastanza possibilità con la minima struttura possibile. Questo tipo di bellezza non scomparirà perché sono arrivati gli agenti.

Ma man mano che sempre più lavoro di implementazione si sposta verso gli agenti, il centro della creazione umana si sposta verso l’alto. L’arte del software si esprimerà sempre più nell’opera nel suo complesso: quali problemi scegliere, quali vite comprendere, quale ordine stabilire, a quali possibilità rinunciare, come rispondere agli utenti e come l’opera dovrebbe entrare nelle loro vite.

La creazione a livello di prodotto e di esperienza è sempre esistita. Il cambiamento è che quando l’implementazione non consuma più la maggior parte della nostra attenzione, queste preoccupazioni possono diventare il lavoro principale di un numero maggiore di creatori di software.

Il codice elegante conta ancora, ma il codice non è mai stato l’intera bellezza del software. Il software creato insieme da persone e intelligenza artificiale non dovrebbe essere visto semplicemente come una pila di codice che funziona, ma come un’opera software completa.

Questo è il cambiamento implicito nei “nuovi artisti”.

In termini professionali esistenti, il ruolo assomiglia a una combinazione tra un product manager e un architetto: chiedersi sia cosa dovrebbe essere realizzato e per chi, sia come il sistema può durare e dove si trovano i suoi confini. Ma quei titoli non bastano. L’autore del software ha bisogno anche di gusto, empatia, capacità di scendere a compromessi e disponibilità ad assumersi la responsabilità del risultato complessivo.

“Artista” qui non è un titolo più nobile, né descrive necessariamente una persona. È il ruolo di un autore responsabile di un'opera completa e un team può condividerlo.

L'ingegneria consente al lavoro di esistere in modo affidabile. L'arte determina perché esiste e come entra nella vita umana.

L'ingegneria non scomparirà e la responsabilità non potrà essere esternalizzata

Il nuovo artista non propone una buona idea per poi aspettare che l'IA finisca tutto il resto.

Anche dopo la diffusione di carta e penna, la scrittura richiedeva ancora formazione; dopo che le macchine fotografiche si sono diffuse, la fotografia richiedeva ancora un giudizio. Gli agenti di codifica riducono il costo di implementazione, ma non risolvono automaticamente l'architettura, la sicurezza, le prestazioni, la qualità o la manutenzione nei sistemi complessi.

Il fatto che non leggo codici non significa che abbia abbandonato il controllo ingegneristico. I punti di controllo sono cambiati: dall'ispezione dell'implementazione linea per linea alla definizione degli obiettivi del sistema, dei principi dell'architettura, dei limiti dei dati, dei modelli di autorizzazione, degli standard di test, dell'osservabilità e dei risultati dei test di accettazione.

Ciò non rende il lavoro meno rigoroso. Pone il rigore altrove. I test coprono i rischi reali? I risultati di runtime mostrano che il sistema soddisfa i suoi vincoli? Esistono prove a sostegno della spiegazione dell’agente? Se una funzionalità viene eseguita, è anche pronta per la spedizione? L’intelligenza artificiale può partecipare a ciascuno di questi compiti, ma alla fine è la persona che deve decidere se le prove sono affidabili e sopportare le conseguenze di eventuali errori.

Alcuni campi, tra cui infrastrutture, sistemi critici per la sicurezza e software di basso livello, continueranno a richiedere che le persone lavorino in profondità nel codice. Potrebbero aver bisogno più che mai del piccolo numero di persone che comprendono veramente gli strati inferiori. Un nuovo livello di astrazione non cancella mai i livelli sottostanti. I linguaggi di alto livello non hanno eliminato l’assembly e il cloud computing non ha eliminato i sistemi operativi. Un nuovo livello consente semplicemente a più creatori di evitare di attraversare ogni livello inferiore ogni volta che realizzano qualcosa.

La mia decisione di non scrivere o leggere codice è una pratica limitata, non una regola per tutti. Il suo valore non è dimostrare che il codice è obsoleto. Mi aiuta a vedere quali parti del lavoro non possono ancora essere trasferite quando il codice non è più l’unica interfaccia attraverso la quale le persone controllano il software.

Il primo è il giudizio. La seconda è la responsabilità.

Strumenti più potenti possono anche produrre mediocrità su scala più ampia. Quando l’implementazione diventa più economica, potremmo prima ottenere software più ripetitivo e rozzo che non soddisfa alcuna esigenza reale. Carta e penna non producono automaticamente letteratura. Gli agenti di codifica non produrranno automaticamente una rinascita del software.

L’intelligenza artificiale non elimina la scarsità. Lo muove.

La produzione di software era limitata principalmente dalle competenze di programmazione, dalle risorse ingegneristiche e dai tempi di implementazione. Man mano che questi vincoli si allentano, il giudizio su quali problemi siano importanti, l’intuizione del prodotto, la comprensione dei sistemi, il gusto, la comprensione delle persone e la volontà di assumersi la responsabilità delle conseguenze diventano relativamente scarsi.

Poiché “come farlo” diventa più economico, “cosa fare” diventa più costoso.

Da autori di codice ad autori di software

Bret Taylor ha citato un'osservazione di Arya Asemanfar: L'intelligenza artificiale può redigere per te, ma tu sei ancora l'autore. [7] Addy Osmani ha descritto il nuovo ruolo dello sviluppatore come architetto e redattore capo. [8]

Un autore non è obbligato a compiere ogni azione che produce un'opera. Gli architetti non posano ogni mattone e i registi non azionano ogni telecamera su un set cinematografico. Ma devono sapere cosa dovrebbe diventare il lavoro, giudicare se avrà successo e assumersi la responsabilità del lavoro nel suo insieme.

Lo stesso cambiamento sta avvenendo nel software.

Eravamo soliti identificare l'autore del software chiedendo chi ha scritto il codice. In futuro, la paternità potrebbe dipendere sempre più da una serie diversa di domande: chi ha definito il problema? Chi ha stabilito i vincoli? Chi ha effettuato i compromessi critici? Chi ha deciso che il lavoro era finito? E chi ha la responsabilità di ciò che accade dopo che è entrato nel mondo?

Ciò potrebbe anche cambiare l'unità economica del software. In passato, un'esigenza di solito doveva essere condivisa da un numero sufficiente di persone per giustificare la creazione di un software specifico. Quando i costi di implementazione scendono abbastanza, il particolare flusso di lavoro di un team, di una famiglia o anche di una sola persona può giustificare un software proprio. Non tutti devono diventare programmatori, ma più persone possono diventare autori di software.

L’intelligenza artificiale spinge più lavoro di implementazione verso il basso, spostando i punti di controllo umani e il centro della creazione verso l’alto di un livello di astrazione. I programmatori non saranno più semplici autori di codice. Diventeranno sempre più autori di opere software complete: i “nuovi artisti” intendo.

Sono arrivate la nuova carta e la penna. Ma un nuovo rinascimento non seguirà automaticamente. Non dipende da quanto codice gli agenti possono generare, ma dal fatto che abbiamo il giudizio – e la volontà di assumerci la responsabilità – di rispondere a una domanda più difficile di “come può essere realizzato?”

Cosa vale la pena creare e come vogliamo che le persone lo vivano?

Riferimenti

[1] Andrej Karpathy, post su X che introduce il “vibe coding”, 2025-02-02.

[2] Andrej Karpathy, post su X che propone l’“agentic engineering”, 2026-02-04.

[3] Liu Ningxin, "Wang Jian: L'innovazione deriva dall'imperfezione e dall'attraversamento dei confini", 21st Century Business Herald, 25-09-2025.

[4] Alan M. Turing, “Intelligent Machinery”, rapporto del National Physical Laboratory, 1948.

[5] Donald E. Knuth, “La programmazione come arte”, Comunicazioni dell'ACM, 17(12), 1974, pp. 667–673.

[6] Paul Graham, "Hackers and Painters", maggio 2003.

[7] Bret Taylor, "L'intelligenza artificiale è il tuo ghostwriter, ma tu sei l'autore", LinkedIn, 2026-02-10.

[8] Addy Osmani, Beyond Vibe Coding, O'Reilly Media, agosto 2025.

コードは一行も書かなかった。一行も読まなかった。

だからといって、プロダクトをAIに任せたわけではない。何を解決するのかを決め、システムがどう動くべきかを定義し、越えてはならない境界を判断し、結果が信頼できるかを確かめ、最後のソフトウェアに責任を負った。変わったのは、私と実装の間にあるインターフェースだけだった。

この経験から、以前は単純に思えた問いを考え直すことになった。コードを自分で書かなくても、作品を定義し、判断し、責任を負う人は、なおソフトウェアの作者なのだろうか。

この実践だけで、あらゆるソフトウェアを同じ方法で開発できるとは証明できない。未公開のプロダクトが市場で受け入れられることさえ、まだ証明していない。それでも、私たちが手がける種類のアプリケーションでは、Coding Agentは単にプログラミングを速くする補助ツールではなくなりつつある。計画、実装、テスト、修正、反復を続けるための、一つのエンジニアリングの道筋になり始めている。

重要な変化は、「AIがコードを書ける」ことではない。ソフトウェアをつくるうえで最も希少だったものの一つである実装が、少しずつ後景に退き始めたことだ。

実装がもはや最も希少な部分ではなくなったとき、人間の仕事は何になるのか。

本稿で考えたいのは、この問いである。

AIの境界は動いている

AIは、固定された言葉ではない。ある時代のコンピュータがまだ安定してできないことを、人はAIと呼びがちだ。能力が成熟し、日常のプロダクトに入ると、人はすぐにそれをAIだと思わなくなる。

私自身の歩みも、この境界に沿ってきた。中学と大学では、センサーとフィードバック制御を使い、経路追従、障害物回避、隊列協調を行う車輪型ロボットに取り組んだ。大学院ではコンピュータビジョンを研究する一方、創業間もないSenseTimeに初期の創業メンバーとして加わった。顔の生体検知や産業用ビジョンの技術を、スマートフォンや高速鉄道を含む大規模な用途へ展開する仕事に携わった。現在、汎用基盤モデルとそれが動かすAgentが、境界を再び前へ押し進めている。これらのシステムは、もはや個別の問題を解くだけではない。目標を理解し、ツールを使い、フィードバックに応じて行動を続け始めており、私の仕事もこうしたプロダクトへ移ってきた。振り返れば、動きを制御し、画像を理解し、タスク全体を完遂するまで、機械が担う仕事の連鎖は長く、より完全になり続けている。

したがって本稿でいうAIとは、主に汎用基盤モデルによって動くAgentを指し、Coding Agentはその代表例である。こうしたAgentは、より長い時間軸のタスクを自律的に実行し、徐々に自己進化し、さらには自らの後継を訓練する方向へ発展している。

2025年、Andrej Karpathyは「Vibe Coding」という言葉で、気軽な使い方を説明した。欲しいものをAIに伝え、生成されたコードを受け入れ、エラーが出ればAIに返し、コードの存在自体を忘れてもよいという方法である。[1] これは当時、私たちがAIを開発に使ってよいと考えていた範囲も正確に表していた。実験には使えるが、本格的なプロダクトを担わせるには足りなかった。

2026年の初め、その境界が動き始めたと私たちは感じた。Karpathyは後に、新しい働き方を「Agentic Engineering」と呼んだ。開発者はAIにコードを補完させるだけでなく、Agentを組織し、監督しながら、レビューと品質への責任を保つ。[2] 名前そのものは重要ではない。重要なのは、AIが一度ずつ提案する存在から、制約の中で継続して行動する存在へ変わり始めたことだ。

一部のソフトウェア制作者にとって、自然言語と文書はすでに、意図を表現する新しい言語になりつつある。

コードは中間生成物になりつつある

コンピュータの歴史は、抽象化の層を増やしてきた歴史でもある。

人は最初、スイッチや配線で機械を操作した。やがて機械語、アセンブリ言語、高級言語が生まれた。層が一つ増えるたびに、下の複雑さが隠され、人は自分の意図に近い場所で仕事ができるようになった。

Coding Agentは、もう一つの層を加える。それは不確実なスーパーコンパイラのようなものだ。従来のコンパイラは、形式が明確なプログラムを機械命令に変換する。Coding Agentは、人間の意図をインターフェース、データ、サービス、コードへ展開しようとする。

この違いは大きい。人間の言葉は曖昧で、要件はしばしば不完全であり、制約同士が衝突することもある。Agentは一つの文を機械的に唯一の正解へ変換できない。理解、計画、実行、動作、検証を繰り返すしかない。

自然言語がプログラミング言語に取って代わったわけではない。より正確には、自然言語と文書が人間の維持する意図の層になり、コードはAgentが生成・維持する実装媒体になりつつある。

その意味で、コードは中間生成物に近づく。しかし「中間」は「重要ではない」という意味ではない。コードは今後も、正しく、安全で、保守できなければならない。ただ、人間が一行ずつ書き、一行ずつ読む必要がなくなるかもしれない。多くのプログラマーはコンパイラが生成する機械語を確認しないが、プログラムの動作には責任を負う。

これは、何を明確に書くべきかを変える。

以前、文書はコードの説明であることが多かった。私たちの実践では、この関係が逆転し始めている。文書に基づいてコードが生成され、検証されることが増えた。プロダクトはなぜ存在するのか。システムはどう動くべきか。どの境界を越えてはならないのか。何をもって完成したと証明するのか。こうしたものが、本当の源になりつつある。

コードを自分で書かなくなっても、正確に表現する必要は減らない。むしろ増える。曖昧な考えは、以前なら長い実装の途中で行き詰まった。今ではAgentが、それを素早く、動くけれど間違ったシステムにしてしまう。

AIは、考えることを免除しない。実装の忙しさで、考えの曖昧さを隠しにくくするだけだ。

「紙とペン」のもう半分

2025年、王堅はAIを人類の「新しい紙とペン」にたとえた。思想そのものではなく、人間の思想を拡張するものだという。[3] 私はこの比喩が好きだ。

そこには興味深い歴史的な対称性がある。1948年、Alan Turingは、紙と鉛筆と消しゴムを持ち、一組の規則に厳密に従う人の行動を、万能機械のように見なせると考えた。[4] 当時、人は紙と鉛筆を使って、人間が機械を模倣する様子を説明した。80年近くたった今、向きが逆になったように見える。機械が新しい紙とペンとなり、人の意図を、動く世界へ展開するのを助け始めている。

この比喩から、大学時代も思い出す。睡眠を除けば、時間の三分の一ほどをソフトウェアいじりに使っていたと思う。OSをインストールし、環境を設定し、道具を学び、それから自分がつくりたいもののデモをつくった。その過程は楽しかったが、創造そのものより、創造の準備に多くの時間を使うことも多かった。紙を探し、顔料をつくり、筆を直し続ける画家のようだった。

AIを新しい紙とペンと呼ぶのは、何でもできるという意味ではない。紙は小説を書かず、顔料はよい絵を描かず、カメラはよい映画を撮らない。道具は表現のコストを下げるが、何を表現する価値があるかまでは決めてくれない。

Coding Agentは紙とペンよりはるかに能動的だ。提案し、タスクを実行し、限られた範囲で選択もする。しかし、作品の目的と結果に責任を負えないかぎり、参加が増えただけで作者になるわけではない。

私が関心を持つのは、「新しい紙とペン」のもう半分である。

新しい紙とペンがあるなら、どのような芸術家が必要になるのか。

芸術は一つ上の抽象化層へ移る

プログラマーが芸術家だという考えは、新しくない。

1974年、Donald Knuthは「Computer Programming as an Art」で、プログラミングになぜ知識、技能、創造性が必要なのか、そしてなぜ美しいものを生み出せるのかを説明した。[5] 2003年、Paul Grahamは「Hackers and Painters」で、ハッカーも画家も「ものをつくる人」だと論じた。ソフトウェア制作者にとって、コンピュータは画家にとっての絵の具、建築家にとってのコンクリートと同じ表現媒体である。[6]

AIがプログラマーを初めて芸術家にするのではない。芸術が主に生まれる場所を変えるのだ。

これまで、プログラマーの芸術の多くはコードの中にあった。アルゴリズムは巧妙か。抽象化は簡潔か。システムは少ない構造で十分な可能性を抱えられるか。この種の美は、Agentが登場しても消えない。

しかし、より多くの実装がAgentへ下りていけば、人間の創造の重心は上へ移る。ソフトウェアの芸術は、作品全体で起きることが増える。どの問題を選ぶのか。どのような人を理解するのか。どのような秩序をつくるのか。何を捨てるのか。ユーザーにどう応え、どのように生活へ入っていくのか。

プロダクトと体験の層での創造は、以前から存在した。変わるのは、実装が注意の大半を占めなくなれば、それがより多くのソフトウェア制作者にとって中心的な仕事になりうることだ。

コードの優雅さはこれからも重要だ。しかしコードは、ソフトウェアの美のすべてではない。人とAIが一緒につくるものを、動くコードの集まりとしてだけ見るべきではない。一つの完全なソフトウェア作品として見るべきだ。

これが、「新しい芸術家」が示す変化である。

既存の職業名で言えば、その役割はプロダクトマネージャーとアーキテクトを合わせたものに近い。何を誰のためにつくるかを問い、同時に、システムがどう長く成立し、境界がどこにあるかを問う。しかし、この二つの肩書だけでは足りない。ソフトウェアの作者には、審美眼、共感、取捨選択する力、そして全体の結果に対する責任も必要だ。

ここでいう「芸術家」は、より高貴な肩書ではない。一人の人間だけを指すとも限らない。完全な作品に責任を負う作者の役割であり、チームで共有することもできる。

工学は、作品が確かに存在できるようにする。芸術は、なぜそれが存在し、どう人の生活に入るのかを決める。

工学も責任も消えてはいない

新しい芸術家は、よいアイデアを一つ出し、残りをAIが終えるのを待てばよいわけではない。

紙とペンが普及しても、書く訓練は不要にならなかった。カメラが普及しても、写真に判断は不要にならなかった。Coding Agentは実装のコストを下げるが、複雑なシステムのアーキテクチャ、セキュリティ、性能、品質、保守を自動的に解決しない。

私がコードを読まないからといって、工学的な制御を捨てたわけではない。制御点が変わった。実装を一行ずつ調べることから、システムの目標、アーキテクチャ原則、データ境界、権限モデル、テスト基準、可観測性、受け入れ結果を定義することへ移った。

厳密さを弱めたのではない。厳密にする場所を変えたのだ。テストは本当のリスクを覆っているか。実行結果はシステムが制約を満たす証拠になっているか。Agentの説明には根拠があるか。機能が動くことは、出荷できることも意味するのか。AIはこれらのすべてに参加できるが、証拠を信頼できるかどうかを最後に判断し、間違った判断の結果を引き受けるのは人間である。

インフラストラクチャ、セーフティクリティカルなシステム、低レベルソフトウェアなど、一部の領域では、これからも人間がコードの深部に入る必要がある。下の層を本当に理解する少数の人は、以前より必要になるかもしれない。新しい抽象化層は、その下の層を消さない。高級言語はアセンブリを消さず、クラウドコンピューティングもOSを消さなかった。ただ、より多くの制作者が、何かをつくるたびにすべての下層を通り直す必要をなくした。

コードを書かず、読まないという私の選択は、境界を設けた実践であり、すべての人に当てはまる規則ではない。その価値は、コードが時代遅れだと証明することではない。コードが人間にとってソフトウェアを制御する唯一のインターフェースではなくなったとき、何をなお手放せないのかを見せてくれたことにある。

一つは判断であり、もう一つは責任である。

より強力な道具は、より大きな規模で凡庸さを生むかもしれない。実装が安くなれば、まず増えるのは、反復的で粗雑で、本当の需要を持たないソフトウェアかもしれない。紙とペンは自動的に文学を生まない。Coding Agentも自動的にソフトウェアのルネサンスを起こさない。

AIは希少性をなくさない。その場所を移す。

これまで、ソフトウェア生産の希少性の多くは、プログラミング能力、エンジニアリング資源、実装時間に集中していた。それらのコストが下がれば、問題を見極める力、プロダクトへの直感、システムの理解、審美眼、人への理解、そして結果に責任を負う意思が、相対的に希少になる。

「どうつくるか」が安くなるほど、「何をつくるか」は高くなる。

コードの作者から、ソフトウェア作品の作者へ

Bret Taylorは、Arya Asemanfarの言葉を紹介し、賛同した。AIは下書きをしてくれるが、作者はなお自分である。[7] Addy Osmaniは、開発者の新しい役割をアーキテクト兼戦略家と表現している。[8]

作者は、作品を生み出すすべての動作を自分でする必要はない。建築家はすべての煉瓦を積まず、映画監督は撮影現場のすべてのカメラを操作しない。それでも、作品が何になるべきかを知り、成立しているかを判断し、全体に責任を負わなければならない。

ソフトウェアにも、同じ変化が起きている。

以前、私たちは誰がコードを書いたかを見て、ソフトウェアの作者を判断することが多かった。これから作者性は、別の問いによって決まるようになるかもしれない。誰が問題を定義したのか。誰が制約を設けたのか。誰が重要な取捨選択をしたのか。誰が作品の完成を判断したのか。そして、現実世界に出たあとの結果を誰が引き受けるのか。

これは、ソフトウェアの経済単位も変えるかもしれない。以前は、十分に多くの人が共有する需要だけが、ソフトウェアをつくる理由になった。実装コストが十分に下がれば、一つのチーム、一つの家族、さらには一人だけのワークフローにも、専用のソフトウェアを持つ価値が生まれる。誰もがプログラマーになる必要はないが、より多くの人がソフトウェアの作者になれる。

私は3年前に起業し、2025年にDeepFlywheelを登記した。今回の実践は、その旅の始まりではない。最初からすべてを正しく理解していたと証明するものでもない。ただ、変わらず持ち続けてきた方向を、より明確にしてくれた。私たちがアプリケーションをつくるのは、モデルの能力を現実の人々の手に届けるのはアプリケーションであり、利用、信頼、支払いが最も正直なフィードバックを返すからだ。そのフィードバックを次の創造にどう取り込むかは、別の文章で考えたい。

本稿の結論は、もっと簡単に言える。

AIは、より多くの実装作業を下へ押し下げると同時に、人間の責任と創造の重心を一つ上の抽象化層へ押し上げる。プログラマーはコードの作者であるだけでなく、ますます完全なソフトウェア作品の作者になっていく。それが、私のいう「新しい芸術家」である。

新しい紙とペンは、すでに現れた。しかし新しいルネサンスは、自動的には訪れない。Agentがどれほど多くのコードを生成できるかではなく、私たちに判断力があるか、責任を引き受ける意思があるか、そして「どうつくるか」より難しい問いに答えられるかにかかっている。

何をつくる価値があり、人にどう感じてほしいのか。

参考文献

[1] Andrej Karpathy、「Vibe Coding」を紹介したX投稿、2025-02-02。

[2] Andrej Karpathy、「Agentic Engineering」を提案したX投稿、2026-02-04。

[3] 柳寧馨、「王堅：創新源于“不完美”与“跨界”」、『21世紀経済報道』、2025-09-25。

[4] Alan M. Turing、“Intelligent Machinery”、National Physical Laboratory report、1948年。

[5] Donald E. Knuth、“Computer Programming as an Art”、Communications of the ACM、17(12)、1974年、pp. 667–673。

[6] Paul Graham、“Hackers and Painters”、2003年5月。

[7] Bret Taylor、“AI is your ghostwriter, but you are the author”、LinkedIn、2026-02-10。

[8] Addy Osmani、Beyond Vibe Coding、O’Reilly Media、2025年8月。

저는 코드 한 줄도 작성하지 않았고, 한 줄도 읽지 않았습니다.

그렇다고 제품을 AI에게 넘겨준 것은 아닙니다. 어떤 문제를 해결할지 결정하고, 시스템이 어떻게 작동해야 하는지 정의하고, 넘지 말아야 할 경계를 판단하고, 결과를 신뢰할 수 있는지 검증하며, 최종 소프트웨어에 대한 책임을 지는 일은 여전히 제 몫이었습니다. 달라진 것은 구현과 상호작용하는 방식뿐이었습니다.

이 경험은 한때 단순해 보였던 질문을 다시 생각하게 했습니다. 더 이상 손으로 코드를 쓰지 않더라도 작품을 정의하고, 성공 여부를 판단하며, 끝까지 책임지는 사람은 여전히 소프트웨어의 저자일까요?

이 관행은 모든 소프트웨어가 이런 방식으로 구축될 수 있다는 것을 증명하지 않습니다. 아직 출시되지 않은 이들 제품이 시장에서 성공할 것이라는 점을 증명하는 것도 아니다. 그러나 우리가 구축하는 애플리케이션 유형의 경우 코딩 에이전트 중심의 워크플로는 더 이상 단순히 프로그래밍 속도를 높이는 방법이 아닙니다. 이는 계획, 구현, 테스트, 수정 및 반복을 지속할 수 있는 엔지니어링 접근 방식이 되고 있습니다.

중요한 변화는 “AI가 코드를 작성할 수 있다”는 것이 아니다. 구현은 소프트웨어 제작에서 가장 부족한 부분 중 하나였습니다. 이제 배경으로 물러나기 시작했습니다.

구현이 더 이상 가장 부족한 부분이 아니라면 인간의 작업은 어떻게 될까요?

이것이 바로 이 에세이의 질문입니다.

AI의 경계가 움직인다

AI는 결코 고정된 용어가 아니었습니다. 사람들은 무언가를 AI라고 부르는 경향이 있지만 컴퓨터는 아직 이를 안정적으로 수행할 수 없습니다. 기능이 성숙되어 일상 제품에 적용되면 빠르게 일반 기술이 되어 AI처럼 보이지 않게 됩니다.

내 길도 이 경계를 따라왔다. 중학교와 대학교에서는 센서와 피드백 제어를 사용하여 바퀴 달린 로봇이 경로를 따르고, 장애물을 피하고, 대형을 조정하도록 하는 작업을 했습니다. 저는 대학원 시절 컴퓨터 비전을 공부하면서 새로 창업한 SenseTime에 초기 창업사원으로 합류했습니다. 저는 얼굴 생체 인식 및 산업용 비전 기술을 스마트폰, 고속철도 등 대규모 애플리케이션에 적용하는 데 도움을 주었습니다. 오늘날 범용 기반 모델과 해당 모델이 지원하는 에이전트는 다시 한 번 경계를 확장했습니다. 이러한 시스템은 더 이상 고립된 문제만을 해결하지 않습니다. 그들은 목표를 이해하고, 도구를 사용하고, 피드백에 따라 계속해서 행동하기 시작했습니다. 내 작업도 이러한 제품쪽으로 옮겨졌습니다. 돌이켜보면 동작 제어와 이미지 이해부터 전체 작업 완료에 이르기까지 기계는 더 길고 더 완전한 작업 체인을 담당하고 있습니다.

따라서 이 에세이에서 AI는 주로 범용 기반 모델에 의해 구동되는 에이전트를 지칭하며, 코딩 에이전트가 대표적인 예입니다. 그들의 발전은 더 긴 범위의 작업을 자율적으로 실행하고, 점진적인 자기 진화를 이루고, 심지어 자신의 후임자를 훈련시키는 능력까지 지향합니다.

2025년 Andrej Karpathy는 “바이브 코딩”이라는 말로 느슨한 프로그래밍 방식을 설명했습니다. AI에게 원하는 것을 말하고, 생성된 코드를 받아들이고, 오류 메시지를 다시 건네며, 심지어 코드가 존재한다는 사실조차 잊는 방식입니다. [1] 다만 이렇게까지 맡기려면 실패 비용이 낮아야 한다는 전제가 있습니다. 당시 진지한 제품을 만들 때 우리는 여전히 Cursor를 사용했습니다. 인간 개발자가 작업을 주도하고 코드에 책임을 졌으며, 에이전트는 보조 역할을 했습니다.

2026년 초까지 우리는 경계가 다시 앞으로 나아가는 것을 보았습니다. Karpathy는 나중에 새로운 작업 방식을 "에이전트 엔지니어링"이라고 불렀습니다. 개발자는 더 이상 AI를 사용하여 코드를 완성하는 것이 아니라 검토 및 품질에 대한 책임을 유지하면서 엔지니어링 작업을 수행할 때 에이전트를 구성하고 감독합니다. [2] 이름은 중요하지 않습니다. 중요한 것은 AI가 한 번에 하나씩 제안을 제공하는 것에서 제약 조건 내에서 지속적인 조치를 취하는 것으로 이동하고 있다는 것입니다.

일부 소프트웨어 제작자에게 자연어와 문서는 이미 의도를 표현하는 새로운 레이어가 되고 있습니다.

코드는 중간 산출물이 되어가고 있다

컴퓨팅의 역사는 추상화 계층을 추가한 역사이기도 합니다.

사람들은 처음으로 스위치와 패치 케이블을 사용하여 기계를 작동했습니다. 그런 다음 기계어 코드, 어셈블리 및 고급 프로그래밍 언어가 나왔습니다. 각각의 새로운 레이어는 아래의 복잡성 중 일부를 숨기고 사람들이 자신의 의도에 더 가깝게 작업할 수 있도록 해줍니다.

코딩 에이전트는 소프트웨어 개발에 새로운 추상화 계층을 추가합니다. 이는 비결정적 슈퍼컴파일러와 같습니다. 기존 컴파일러는 공식적으로 지정된 프로그램을 기계 명령어로 변환하는 반면 코딩 에이전트는 인간의 의도를 인터페이스, 데이터, 서비스 및 코드로 전개하려고 합니다.

차이점이 중요합니다. 인간의 언어는 모호합니다. 요구 사항은 불완전한 경우가 많으며 제약 조건이 충돌할 수 있습니다. 에이전트는 문장을 하나의 올바른 결과로 기계적으로 번역할 수 없습니다. 이해, 계획, 구현, 실행 및 검증을 순환해야 합니다.

자연어는 프로그래밍 언어를 대체하지 못했습니다. 더 정확하게 말하면, 자연어와 문서는 사람이 유지 관리하는 의도 계층이 되고 있으며, 코드는 에이전트가 생성하고 유지 관리하는 구현 매체 역할을 점점 더 많이 하고 있습니다.

이는 코드를 중간 아티팩트에 더 가깝게 만들지만 "중간"이 중요하지 않다는 의미는 아닙니다. 코드는 여전히 정확하고 안전하며 유지 관리가 가능해야 합니다. 사람이 한 줄씩 쓰고 읽을 필요는 없을 수도 있습니다. 대부분의 프로그래머는 컴파일러가 내놓은 기계어 코드를 검사하지 않지만 프로그램이 수행하는 작업에 대한 책임은 그대로 유지합니다.

이로 인해 우리가 명확히 해야 할 사항이 변경되었습니다.

문서는 코드에 대한 설명이었습니다. 우리 작업에서는 관계가 역전되기 시작했습니다. 문서에서 더 많은 코드가 생성되고 확인됩니다. 제품이 존재하는 이유, 시스템이 어떻게 작동해야 하는지, 어떤 경계를 넘을 수 없는지, 요구 사항을 충족하는지 보여주는 증거는 무엇인지, 이러한 것들이 일단 코드에 대한 첨부 파일로 취급되면 소프트웨어 자체의 소스가 되고 있습니다.

과거에는 이렇게 말했습니다. “말은 싸다. 코드를 보여 달라.”

이제는 이렇게 말합니다. “코드는 싸다. 문서를 보여 달라.”

코드를 직접 쓰지 않는다고 해서 표현의 정확성이 덜 중요해지는 것은 아닙니다. 오히려 더 중요해집니다. 과거에는 모호한 생각이 긴 구현 과정에서 드러나고 명확해질 시간이 있었습니다. 이제 에이전트는 그 생각을 빠르게, 작동하지만 겉보기에만 완성된 시스템으로 만들 수 있습니다. 모호함은 사라지지 않습니다. 구현 속에 묻혔다가 나중에 실패와 손실로 드러날 뿐입니다.

AI는 우리를 생각하는 일에서 면제해 주지 않습니다. 구현의 분주함 뒤에 모호한 생각을 숨기기 어렵게 만들 뿐입니다.

'종이와 펜'의 나머지 절반

2025년 Wang Jian은 AI를 인류의 '새로운 종이와 펜'에 비유했습니다. 즉, 생각 자체가 아니라 인간 사고의 확장입니다. [3] 나는 이 비유를 좋아한다.

여기에는 흥미로운 역사적 대칭이 포함되어 있습니다. 1948년에 앨런 튜링(Alan Turing)은 종이, 연필, 지우개를 가지고 일련의 규칙을 따르는 사람의 행동을 보편적인 기계의 행동으로 간주할 수 있는 상상을 했습니다. [4] 그런 다음 사람들은 종이와 연필을 사용하여 사람이 기계를 시뮬레이션하는 방법을 설명했습니다. 거의 80년이 지난 지금, 방향은 역전된 것 같습니다. 기계는 새로운 종이와 펜이 되어 사람들이 실행 가능한 세계로 의도를 펼치도록 돕습니다.

그 비유는 나에게도 대학을 생각나게 한다. 잠을 자는 것 외에도 운영 체제 설치, 환경 구성, 도구 학습, 마이크로 컨트롤러 수정, 바퀴 달린 로봇 디버깅 및 대형 조정 작업, 관심 있는 모든 데모 구축 등 소프트웨어와 하드웨어 사이를 오가며 시간의 3분의 1을 소비했을 것입니다. 나는 그 과정을 즐겼지만 마치 화가가 끊임없이 종이를 찾고, 안료를 만들고, 붓을 고치는 것처럼 창조하는 것보다 창조를 준비하는 데 더 많은 시간을 소비했습니다.

AI를 새로운 종이와 펜이라고 부르는 것이 모든 것을 할 수 있다는 의미는 아닙니다. 종이는 소설을 쓰지 않습니다. 안료는 좋은 그림을 그릴 수 없고, 카메라는 좋은 필름을 만들지 못합니다. 도구는 표현 비용을 낮추지만 표현 가치가 무엇인지 결정하지는 않습니다.

코딩 에이전트는 종이와 펜보다 훨씬 더 활동적입니다. 그들은 제한된 범위 내에서 제안을 하고, 작업을 실행하고, 선택을 합니다. 그러나 작품의 목적과 결과에 대해 책임을 질 수 있을 때까지는 더 많은 참여가 자동으로 작가가 되는 것은 아닙니다.

제가 관심을 갖는 것은 "새 종이와 펜"의 나머지 절반입니다.

새로운 종이와 펜이 있다면 어떤 예술가가 필요할까요?

소프트웨어 창작의 중심이 위로 이동하고 있다

프로그래머가 예술가라는 생각은 새로운 것이 아닙니다.

1974년 도널드 커누스(Donald Knuth)는 "예술로서의 컴퓨터 프로그래밍"에서 프로그래밍에 지식, 기술, 창의성이 필요한 이유와 그것이 어떻게 아름다운 대상을 만들어낼 수 있는지 설명했습니다. [5] 2003년 폴 그레이엄(Paul Graham)은 “해커와 화가(Hackers and Painters)”에서 해커와 화가는 모두 제작자라고 주장했습니다. 화가에게 페인트를, 건축가에게 콘크리트를 사용하는 것과 마찬가지로 소프트웨어 제작자에게 컴퓨터는 표현의 매체입니다. [6]

AI가 처음으로 프로그래머를 예술가로 만드는 것은 아닙니다. 예술이 주로 이루어지는 곳이 바뀌고 있습니다.

프로그래머의 기예는 주로 코드 안에서 드러났습니다. 기발한 알고리즘, 우아한 추상화, 최소한의 구조로 충분한 가능성을 품는 시스템이 그 예입니다. 이런 아름다움은 에이전트가 등장했다고 사라지지 않습니다.

그러나 더 많은 구현 작업이 에이전트로 이동함에 따라 인간 창조의 중심이 위로 이동합니다. 소프트웨어 기술은 작업 전체에서 점점 더 많이 표현될 것입니다. 어떤 문제를 선택해야 하는지, 누구의 삶을 이해해야 하는지, 어떤 순서를 확립해야 하는지, 어떤 가능성을 포기해야 하는지, 사용자에게 어떻게 대응해야 하는지, 작업이 어떻게 사용자의 삶에 들어가야 하는지 등이 표현될 것입니다.

제품과 경험 수준의 창조는 항상 존재해 왔습니다. 변화는 구현이 더 이상 우리의 대부분의 관심을 소비하지 않을 때 이러한 문제가 더 많은 소프트웨어 제작자의 주요 작업이 될 수 있다는 것입니다.

우아한 코드는 여전히 중요하지만, 코드는 결코 소프트웨어의 아름다움의 전부가 아닙니다. 사람과 AI가 함께 만든 소프트웨어는 단순히 실행되는 코드 덩어리가 아니라 소프트웨어의 완전한 작품으로 보아야 합니다.

이것이 바로 '신인 아티스트'가 의미하는 변화이다.

기존 전문 용어로 볼 때 이 역할은 제품 관리자와 설계자의 조합과 비슷합니다. 즉, 무엇을 만들어야 하는지, 누구를 위해 만들어야 하는지, 시스템이 어떻게 지속될 수 있는지, 경계는 어디에 있는지 묻는 것입니다. 그러나 그 제목만으로는 충분하지 않습니다. 소프트웨어 작성자에게는 취향, 공감, 절충 능력, 전체 결과에 대한 책임을 지려는 의지도 필요합니다.

여기서 '예술가'는 더 고귀한 호칭도 아니고 반드시 한 사람을 지칭하는 것도 아니다. 완전한 작품을 책임지는 작가의 역할이고, 팀이 공유할 수 있는 역할이다.

엔지니어링을 통해 작업이 안정적으로 존재할 수 있습니다. 예술은 그것이 존재하는 이유와 그것이 인간의 삶에 어떻게 들어가는지를 결정합니다.

엔지니어링은 사라지지 않으며, 책임은 아웃소싱될 수 없습니다

신인 아티스트는 좋은 아이디어를 제안한 뒤 AI가 나머지 모든 것을 끝내기를 기다리지 않는다.

종이와 펜이 널리 보급된 후에도 글쓰기에는 여전히 훈련이 필요했습니다. 카메라가 널리 보급된 후에도 사진에는 여전히 판단이 필요했습니다. 코딩 에이전트는 구현 비용을 낮추지만 복잡한 시스템의 아키텍처, 보안, 성능, 품질 또는 유지 관리를 자동으로 해결하지는 않습니다.

내가 코드를 읽지 않는다는 사실이 내가 엔지니어링 통제를 포기했다는 의미는 아닙니다. 제어 지점이 변경되었습니다. 구현을 한 줄씩 검사하는 것에서 시스템 목표, 아키텍처 원칙, 데이터 경계, 권한 모델, 테스트 표준, 관찰 가능성 및 승인 테스트 결과를 정의하는 것까지 변경되었습니다.

그렇다고 작업의 엄격함이 줄어드는 것은 아닙니다. 엄격함이 놓이는 위치가 달라질 뿐입니다. 테스트가 실제 위험을 다루는가? 런타임 결과가 시스템이 제약을 충족한다는 사실을 보여 주는가? 에이전트의 설명을 뒷받침할 증거가 있는가? 기능이 작동한다면 실제로 출시할 준비도 되었는가? AI는 이 모든 작업에 참여할 수 있지만, 증거를 신뢰할 수 있는지 최종적으로 판단하고 오판의 결과를 감당하는 주체는 사람이어야 합니다.

인프라, 안전이 중요한 시스템, 하위 수준 소프트웨어를 포함한 일부 분야에서는 계속해서 사람들이 코드 내부에서 심층적으로 작업해야 합니다. 그 어느 때보다 하위 레이어를 진정으로 이해하는 소수의 사람들이 필요할 수도 있습니다. 새로운 추상화 레이어는 그 아래 레이어를 결코 지우지 않습니다. 고급 언어는 어셈블리를 제거하지 않았으며 클라우드 컴퓨팅은 운영 체제를 제거하지 않았습니다. 새로운 레이어를 사용하면 더 많은 제작자가 무언가를 만들 때마다 모든 하위 레이어를 통과하는 것을 피할 수 있습니다.

코드를 쓰거나 읽지 않기로 한 나의 결정은 제한된 관행이지 모든 사람에게 적용되는 규칙은 아닙니다. 그 가치는 코드가 쓸모없다는 것을 증명하는 것이 아닙니다. 코드가 더 이상 사람들이 소프트웨어를 제어하는 유일한 인터페이스가 아닌 경우 작업의 어떤 부분을 여전히 전달할 수 없는지 확인하는 데 도움이 됩니다.

첫째는 심판이다. 두 번째는 책임이다.

더 강력한 도구는 더 큰 규모로 평범함을 만들어낼 수도 있습니다. 구현 비용이 저렴해지면 먼저 실제 필요를 충족하지 못하는 더 반복적이고 조잡한 소프트웨어를 얻게 될 수 있습니다. 종이와 펜은 자동으로 문학을 생산하지 않습니다. 코딩 에이전트는 소프트웨어 르네상스를 자동으로 생성하지 않습니다.

AI는 희소성을 없애지 않습니다. 희소성의 위치를 옮길 뿐입니다.

소프트웨어 생산은 주로 프로그래밍 기술, 엔지니어링 자원 및 구현 시간에 의해 제한되었습니다. 이러한 제약이 완화됨에 따라 어떤 문제가 중요한지에 대한 판단, 제품 직관, 시스템 이해, 취향, 사람에 대한 이해, 결과에 대한 책임을 지려는 의지가 상대적으로 희소해집니다.

'어떻게 만들 것인가'가 저렴해질수록 '무엇을 만들 것인가'는 더 비싸진다.

코드 작성자에서 소프트웨어 작성자로

Bret Taylor는 Arya Asemanfar의 관찰을 인용했습니다. AI가 당신을 위해 초안을 작성할 수 있지만 여전히 작성자는 당신입니다. [7] Addy Osmani는 개발자의 새로운 역할을 설계자이자 편집장으로 설명했습니다. [8]

작가는 작품을 생산하는 모든 활동을 수행할 필요는 없습니다. 건축가는 모든 벽돌을 쌓지 않으며 감독은 영화 세트의 모든 카메라를 작동하지 않습니다. 하지만 그들은 그 일이 어떻게 되어야 하는지 알아야 하고, 그 일이 성공할지 판단해야 하며, 그 일 전체에 대해 책임을 져야 합니다.

소프트웨어에서도 동일한 변화가 일어나고 있습니다.

우리는 누가 코드를 작성했는지 물어봄으로써 소프트웨어 작성자를 식별하곤 했습니다. 미래에는 저자됨이 점점 더 다양한 질문에 의존하게 될 것입니다. 누가 문제를 정의했는가? 누가 제약 조건을 설정했습니까? 누가 중요한 절충안을 만들었습니까? 작업이 완료되었다고 누가 결정했습니까? 그리고 그것이 세상에 나온 후에 일어나는 일에 대한 책임은 누구에게 있습니까?

이는 또한 소프트웨어의 경제적 단위를 변경할 수도 있습니다. 과거에는 일반적으로 소프트웨어 구축을 정당화할 만큼 충분한 사람들이 요구 사항을 공유해야 했습니다. 구현 비용이 충분히 낮아지면 팀, 가족 또는 한 사람의 특정 작업 흐름이 자체 소프트웨어를 보증할 수 있습니다. 모든 사람이 프로그래머가 될 필요는 없지만 더 많은 사람이 소프트웨어 작성자가 될 수 있습니다.

AI는 더 많은 구현 작업을 아래로 밀어내는 동시에 인간 제어 지점과 생성 중심을 하나의 추상화 계층 위로 이동합니다. 프로그래머는 더 이상 단순한 코드 작성자가 아닙니다. 점점 더 그들은 완전한 소프트웨어 작품의 저작자가 될 것입니다. 즉, "신인 아티스트"가 될 것입니다.

새 종이와 펜이 도착했어요. 그러나 새로운 르네상스가 자동으로 따라오는 것은 아닙니다. 이는 에이전트가 얼마나 많은 코드를 생성할 수 있는지가 아니라 "어떻게 만들 수 있습니까?"보다 더 어려운 질문에 답할 판단과 책임을 지려는 의지가 있는지 여부에 달려 있습니다.

창조할 가치가 있는 것은 무엇이며 사람들이 그것을 어떻게 경험하기를 원합니까?

참고자료

[1] Andrej Karpathy, “바이브 코딩”을 소개하는 X 포스트, 2025-02-02.

[2] Andrej Karpathy, "에이전트 엔지니어링"을 제안하는 X 포스트, 2026-02-04.

[3] Liu Ningxin, “Wang Jian: 혁신은 '불완전함'과 '경계 교차'에서 비롯됩니다”, 21st Century Business Herald, 2025-09-25.

[4] Alan M. Turing, “지능형 기계”, 국립 물리 연구소 보고서, 1948년.

[5] Donald E. Knuth, “예술로서의 컴퓨터 프로그래밍”, Communications of the ACM, 17(12), 1974, pp. 667–673.

[6] 폴 그레이엄, “해커와 화가”, 2003년 5월.

[7] Bret Taylor, “AI는 당신의 대필가이지만, 저자는 당신이다”, LinkedIn, 2026-02-10.

[8] Addy Osmani, Vibe Coding을 넘어서, O'Reilly Media, 2025년 8월.

Não escrevi uma única linha de código. Nem li um.

Mas isso não significa que entreguei os produtos à IA. Ainda decidi quais problemas eles deveriam resolver, defini como os sistemas deveriam funcionar, julguei quais limites não poderiam ser ultrapassados, verifiquei se os resultados eram confiáveis e assumi a responsabilidade pelo software final. O que mudou foi simplesmente a minha interface com a implementação.

Isso me forçou a reconsiderar uma questão que antes parecia simples: se alguém não escreve mais código à mão, mas ainda define o trabalho, decide se ele será bem-sucedido e permanece responsável por ele, ainda será o autor do software?

Esta prática não prova que todo software possa ser construído desta forma. Nem sequer prova que estes produtos inéditos terão sucesso no mercado. Mas para os tipos de aplicativos que construímos, um fluxo de trabalho centrado em agentes de codificação não é mais apenas uma forma de programar mais rapidamente. Está se tornando uma abordagem de engenharia que pode sustentar planejamento, implementação, testes, correção e iteração.

A mudança importante não é que “a IA possa escrever código”. A implementação costumava ser uma das partes mais escassas da criação de software; agora está começando a ficar em segundo plano.

Quando a implementação não é mais a parte mais escassa, o que acontece com o trabalho humano?

Essa é a questão deste ensaio.

A fronteira da IA está mudando

IA nunca foi um termo fixo. As pessoas tendem a chamar algo de IA, enquanto os computadores ainda não conseguem fazê-lo de forma confiável; uma vez que a capacidade amadurece e entra nos produtos de uso diário, ela rapidamente se torna uma tecnologia comum e deixa de se parecer com IA.

Meu próprio caminho também seguiu esse limite. No ensino fundamental e na universidade, trabalhei com robôs com rodas, usando sensores e controle de feedback para fazê-los seguir caminhos, evitar obstáculos e coordenar a formação. Durante a pós-graduação, estudei visão computacional e também ingressei na recém-fundada SenseTime como um dos primeiros funcionários fundadores. Ajudei a trazer tecnologias de detecção de vivacidade facial e visão industrial para aplicações de grande escala, incluindo smartphones e trens de alta velocidade. Hoje, os modelos de fundação de uso geral e os agentes que eles capacitam empurraram os limites novamente. Estes sistemas já não abordam apenas problemas isolados. Eles estão começando a compreender os objetivos, a usar ferramentas e a continuar agindo em resposta ao feedback; meu trabalho também mudou para esses produtos. Olhando para trás, desde o controle do movimento e compreensão de imagens até a conclusão de tarefas inteiras, as máquinas estão assumindo cadeias de trabalho mais longas e completas.

Neste ensaio, portanto, a IA refere-se principalmente a agentes orientados por modelos básicos de uso geral, com agentes de codificação como exemplo representativo. O seu desenvolvimento aponta para a execução autónoma de tarefas num horizonte mais longo, para a autoevolução gradual e até para a capacidade de treinar os seus próprios sucessores.

Em 2025, Andrej Karpathy usou “vibe coding” para descrever um estilo flexível de programação: diga à IA o que você deseja, aceite o código gerado, envie-lhe mensagens de erro e até mesmo esqueça que o código existe. [1] Mas chegar até aqui tem uma pré-condição: o custo do fracasso deve ser baixo. Na época, para produtos sérios, ainda usávamos o Cursor. Os desenvolvedores humanos lideraram o trabalho e permaneceram responsáveis pelo código; o agente ajudou.

No início de 2026, vimos a fronteira avançar novamente. Mais tarde, Karpathy chamou a nova forma de trabalhar de “engenharia agentica”: os desenvolvedores não usam mais apenas a IA para completar o código, mas organizam e supervisionam os agentes à medida que realizam tarefas de engenharia, mantendo a responsabilidade pela revisão e qualidade. [2] O nome não é importante. O que importa é que a IA está a passar da oferta de sugestões, uma de cada vez, para uma ação sustentada dentro de restrições.

Para alguns criadores de software, a linguagem natural e os documentos já estão se tornando uma nova camada para expressar intenções.

O código está se tornando um artefato intermediário

A história da computação é também uma história de adição de camadas de abstração.

As pessoas primeiro operaram máquinas com interruptores e cabos patch. Depois vieram o código de máquina, o assembly e as linguagens de programação de alto nível. Cada nova camada ocultava parte da complexidade abaixo e permitia que as pessoas trabalhassem mais perto de suas intenções.

Os agentes de codificação adicionam uma nova camada de abstração ao desenvolvimento de software. Eles são algo como um supercompilador não determinístico: um compilador tradicional traduz um programa formalmente especificado em instruções de máquina, enquanto um agente de codificação tenta desdobrar a intenção humana em interfaces, dados, serviços e código.

A diferença importa. A linguagem humana é ambígua. Os requisitos costumam ser incompletos e as restrições podem entrar em conflito. Um agente não pode traduzir mecanicamente uma frase em um único resultado correto. Tem que passar por compreensão, planejamento, implementação, execução e verificação.

A linguagem natural não substituiu as linguagens de programação. Mais precisamente, a linguagem natural e os documentos estão a tornar-se uma camada de intenção mantida pelas pessoas, enquanto o código serve cada vez mais como um meio de implementação gerado e mantido pelos agentes.

Isso torna o código mais parecido com um artefato intermediário, mas “intermediário” não significa sem importância. O código ainda precisa ser correto, seguro e passível de manutenção. Simplesmente pode não precisar ser escrito e lido linha por linha por uma pessoa. A maioria dos programadores não inspeciona o código de máquina emitido por um compilador, mas permanece responsável pelo que o programa faz.

Isso muda o que precisamos deixar claro.

A documentação costumava ser uma explicação do código. Em nosso trabalho, a relação está começando a se inverter: mais código está sendo gerado e verificado a partir de documentos. Por que o produto existe, como o sistema deve funcionar, quais limites não podem ser ultrapassados e quais evidências mostram que ele atende aos seus requisitos – essas coisas, uma vez tratadas como anexos ao código, estão se tornando a fonte do próprio software.

Depois: "Falar é fácil. Mostre-me o código."

Agora: "O código é barato. Mostre-me o documento."

Não escrever código manualmente não diminui as demandas de expressão. Isso os levanta. No passado, uma ideia ambígua teve tempo de surgir e se tornar mais clara ao longo de um longo processo de implementação. Agora, um agente pode transformá-lo rapidamente em um sistema funcional e aparentemente completo. A ambiguidade não desapareceu. Foi apenas enterrado na implementação, onde surgirá mais tarde como falhas e perdas.

A IA não nos poupa da necessidade de pensar. Isso apenas torna mais difícil esconder ideias vagas por trás da agitação da implementação.

A outra metade de “papel e caneta”

Em 2025, Wang Jian comparou a IA ao “novo papel e caneta” da humanidade: não o pensamento em si, mas uma extensão do pensamento humano. [3] Gosto dessa metáfora.

Ele contém uma simetria histórica interessante. Em 1948, Alan Turing imaginou uma pessoa equipada com papel, lápis e borracha, seguindo um conjunto de regras, cujo comportamento poderia ser considerado o de uma máquina universal. [4] As pessoas então usaram papel e lápis para explicar como uma pessoa poderia simular uma máquina. Quase oitenta anos depois, a direção parece ter se invertido. A máquina está se tornando o novo papel e caneta, ajudando as pessoas a desdobrar intenções em mundos que podem funcionar.

A metáfora também me lembra a universidade. Além de dormir, provavelmente passei um terço do meu tempo alternando entre software e hardware: instalando sistemas operacionais, configurando ambientes, aprendendo ferramentas, mexendo em microcontroladores, depurando robôs com rodas e fazendo com que eles se coordenassem em formação, e construindo quaisquer demonstrações que me interessassem. Gostei do processo, mas muitas vezes passei mais tempo preparando-me para criar do que criando – como um pintor que está sempre procurando papel, fazendo pigmentos e consertando pincéis.

Chamar a IA de novo papel e caneta não significa que ela possa fazer tudo. O papel não escreve um romance. O pigmento não pinta uma boa imagem e uma câmera não faz um bom filme. As ferramentas reduzem o custo da expressão, mas não decidem o que vale a pena expressar.

Os agentes de codificação são muito mais ativos do que papel e caneta. Eles oferecem sugestões, executam tarefas e fazem escolhas dentro de um escopo limitado. Mas até que possam assumir a responsabilidade pelo propósito e pelas consequências de uma obra, uma maior participação não os torna automaticamente autores.

O que me interessa é a outra metade do “novo papel e caneta”:

Se tivermos papel e caneta novos, de que tipo de artistas precisamos?

O centro de criação de software está subindo

A ideia de que programadores são artistas não é nova.

Em 1974, Donald Knuth explicou em “Computer Programming as an Art” porque a programação requer conhecimento, habilidade e criatividade, e como pode produzir objetos belos. [5] Em 2003, Paul Graham argumentou em “Hackers and Painters” que hackers e pintores são ambos criadores. Para os criadores de software, os computadores são um meio de expressão, assim como a tinta é para um pintor ou o concreto para um arquiteto. [6]

A IA não está transformando programadores em artistas pela primeira vez. Está mudando onde a arte acontece principalmente.

Grande parte da arte de um programador costumava acontecer dentro do código: seja um algoritmo engenhoso, uma abstração elegante ou um sistema capaz de conter possibilidades suficientes com o mínimo de estrutura possível. Esse tipo de beleza não desaparecerá porque os agentes chegaram.

Mas à medida que mais trabalho de implementação passa para os agentes, o centro da criação humana sobe. A arte do software será cada vez mais expressa no trabalho como um todo: que problemas escolher, que vidas compreender, que ordem estabelecer, que possibilidades renunciar, como responder aos utilizadores e como o trabalho deve entrar nas suas vidas.

A criação ao nível do produto e da experiência sempre existiu. A mudança é que quando a implementação não consumir mais a nossa atenção, essas preocupações podem se tornar o principal trabalho de mais criadores de software.

O código elegante ainda é importante, mas o código nunca foi toda a beleza do software. O software feito por pessoas e IA em conjunto não deve ser visto apenas como uma pilha de código em execução, mas como um trabalho completo de software.

Esta é a mudança implícita nos “novos artistas”.

Em termos profissionais existentes, o papel assemelha-se a uma combinação de gestor de produto e arquiteto: perguntando o que deve ser feito e para quem, e como o sistema pode resistir e onde estão os seus limites. Mas esses títulos não são suficientes. O autor do software também precisa de bom gosto, empatia, capacidade de fazer concessões e disposição para assumir a responsabilidade pelo resultado geral.

“Artista” aqui não é um título mais nobre, nem descreve necessariamente uma pessoa. É papel de um autor responsável por uma obra completa, e uma equipe pode compartilhá-la.

A engenharia permite que o trabalho exista de forma confiável. A arte determina por que existe e como entra na vida humana.

A engenharia não desaparecerá e a responsabilidade não poderá ser terceirizada

O novo artista não propõe uma boa ideia e depois espera que a IA termine todo o resto.

Mesmo depois da difusão do papel e da caneta, a escrita ainda exigia treinamento; depois que as câmeras se espalharam, a fotografia ainda exigia julgamento. Os agentes de codificação reduzem o custo de implementação, mas não resolvem automaticamente a arquitetura, a segurança, o desempenho, a qualidade ou a manutenção em sistemas complexos.

O fato de eu não ler código não significa que abandonei o controle de engenharia. Os pontos de controle mudaram: desde a inspeção da implementação linha por linha até a definição de objetivos do sistema, princípios de arquitetura, limites de dados, modelos de permissão, padrões de teste, observabilidade e resultados de testes de aceitação.

Isso não torna o trabalho menos rigoroso. Coloca rigor em outro lugar. Os testes cobrem os riscos reais? Os resultados do tempo de execução mostram que o sistema satisfaz suas restrições? Existem evidências para a explicação do agente? Se um recurso for executado, ele também estará pronto para ser enviado? A IA pode participar em cada uma destas tarefas, mas uma pessoa deve, em última análise, decidir se as provas são fiáveis e suportar as consequências de estar errada.

Alguns campos – incluindo infraestrutura, sistemas críticos de segurança e software de baixo nível – continuarão a exigir que as pessoas trabalhem profundamente no código. Eles podem precisar do pequeno número de pessoas que realmente entendem as camadas inferiores, mais do que nunca. Uma nova camada de abstração nunca apaga as camadas abaixo dela. As linguagens de alto nível não eliminaram o assembly e a computação em nuvem não eliminou os sistemas operacionais. Uma nova camada simplesmente permite que mais criadores evitem atravessar todas as camadas inferiores cada vez que fazem algo.

Minha decisão de não escrever ou ler código é uma prática limitada, não uma regra para todos. Seu valor não é provar que o código é obsoleto. Isso me ajuda a ver quais partes do trabalho ainda não podem ser entregues quando o código não é mais a única interface através da qual as pessoas controlam o software.

O primeiro é o julgamento. A segunda é a responsabilidade.

Ferramentas mais poderosas também podem produzir mediocridade em maior escala. Quando a implementação se torna mais barata, podemos primeiro obter software mais repetitivo e rudimentar que não atende a nenhuma necessidade real. Papel e caneta não produzem literatura automaticamente. Os agentes de codificação não produzirão automaticamente um renascimento do software.

A IA não elimina a escassez. Apenas a desloca.

A produção de software costumava ser limitada principalmente pela habilidade de programação, recursos de engenharia e tempo de implementação. À medida que essas restrições diminuem, o julgamento sobre quais problemas são importantes, a intuição do produto, a compreensão dos sistemas, o gosto, a compreensão das pessoas e a disposição para assumir a responsabilidade pelas consequências tornam-se relativamente mais escassos.

À medida que “como fazer” fica mais barato, “o que fazer” fica mais caro.

De autores de código a autores de software

Bret Taylor citou uma observação de Arya Asemanfar: A IA pode redigir para você, mas você ainda é o autor. [7] Addy Osmani descreveu a nova função do desenvolvedor como arquiteto e editor-chefe. [8]

Um autor não precisa realizar todas as ações que produzem uma obra. Os arquitetos não colocam todos os tijolos e os diretores não operam todas as câmeras de um set de filmagem. Mas devem saber o que o trabalho deverá tornar-se, avaliar se terá êxito e assumir a responsabilidade pelo trabalho como um todo.

A mesma mudança está acontecendo no software.

Costumávamos identificar o autor do software perguntando quem escreveu o código. No futuro, a autoria poderá depender cada vez mais de um conjunto diferente de questões: Quem definiu o problema? Quem estabeleceu as restrições? Quem fez as compensações críticas? Quem decidiu que o trabalho estava concluído? E quem é o responsável pelo que acontece depois que ele entra no mundo?

Isto também pode alterar a unidade económica do software. No passado, uma necessidade geralmente precisava ser compartilhada por um número suficiente de pessoas para justificar a construção de software para ela. Quando os custos de implementação caem o suficiente, o fluxo de trabalho específico de uma equipe, de uma família ou mesmo de uma pessoa pode justificar seu próprio software. Nem todo mundo precisa se tornar programador, mas mais pessoas podem se tornar autores de software.

A IA empurra mais trabalho de implementação para baixo enquanto move os pontos de controle humano e o centro da criação para uma camada de abstração. Os programadores não serão mais apenas autores de código. Cada vez mais, eles se tornarão autores de obras completas de software – quero dizer, os “novos artistas”.

Chegaram o novo papel e caneta. Mas um novo renascimento não se seguirá automaticamente. Não depende de quanto código os agentes podem gerar, mas se temos o julgamento – e a vontade de assumir responsabilidade – para responder a uma pergunta mais difícil do que “como isso pode ser feito?”

O que vale a pena criar e como queremos que as pessoas experimentem isso?

Referências

[1] Andrej Karpathy, X post apresentando “vibe coding”, 02/02/2025.

[2] Andrej Karpathy, X post propondo “engenharia agentica”, 04/02/2026.

[3] Liu Ningxin, “Wang Jian: A inovação vem da ‘imperfeição’ e ‘cruzando limites’”, 21st Century Business Herald, 25/09/2025.

[4] Alan M. Turing, “Intelligent Machinery”, relatório do National Physical Laboratory, 1948.

[5] Donald E. Knuth, “Programação de Computadores como uma Arte”, Communications of the ACM, 17(12), 1974, pp. 667–673.

[6] Paul Graham, “Hackers e Pintores”, maio de 2003.

[7] Bret Taylor, “AI é seu ghostwriter, mas você é o autor”, LinkedIn, 2026-02-10.

[8] Addy Osmani, Beyond Vibe Coding, O’Reilly Media, agosto de 2025.

Я не написал ни одной строки кода. И не прочитал ни одной.

Но это не значит, что я передал продукты ИИ. Я по-прежнему решал, какие проблемы они должны решить, определял, как должны работать системы, определял, какие границы нельзя пересекать, проверял достоверность результатов и брал на себя ответственность за финальное программное обеспечение. Что изменилось, так это мой интерфейс с реализацией.

Это заставило меня пересмотреть вопрос, который когда-то казался простым: если кто-то больше не пишет код вручную, но по-прежнему определяет работу, решает, увенчается ли она успехом, и остается за нее ответственным, остается ли он автором программного обеспечения?

Эта практика не доказывает, что все программное обеспечение может быть построено таким образом. Это даже не доказывает, что эти неизданные продукты будут иметь успех на рынке. Но для тех приложений, которые мы создаем, рабочий процесс, основанный на агентах кодирования, больше не является просто способом более быстрого программирования. Это становится инженерным подходом, который может поддерживать планирование, внедрение, тестирование, исправление и итерацию.

Важное изменение заключается не в том, что «ИИ может писать код». Раньше реализация была одной из самых дефицитных частей создания программного обеспечения; сейчас оно начинает отходить на второй план.

Когда реализация перестанет быть самой дефицитной частью, что станет с человеческим трудом?

Это вопрос данного эссе.

Граница ИИ движется

ИИ никогда не был фиксированным термином. Люди склонны называть что-то искусственным интеллектом, тогда как компьютеры пока не могут сделать это надежно; как только эта возможность созреет и станет частью повседневных продуктов, она быстро станет обычной технологией и перестанет выглядеть как ИИ.

Мой собственный путь также проходил по этой границе. В средней школе и университете я работал над колесными роботами, используя датчики и систему управления с обратной связью, чтобы заставить их следовать по маршруту, избегать препятствий и координировать свои действия. В аспирантуре я изучал компьютерное зрение, а также присоединился к недавно основанной компании SenseTime в качестве одного из первых сотрудников. Я помог внедрить технологии определения живости лиц и промышленного зрения в крупномасштабные приложения, включая смартфоны и высокоскоростные железные дороги. Сегодня универсальные модели фундаментов и агенты, которыми они управляют, снова раздвинули границы. Эти системы больше не решают только отдельные проблемы. Они начинают понимать цели, использовать инструменты и продолжать действовать в ответ на обратную связь; моя работа также была направлена на эти продукты. Оглядываясь назад, можно сказать, что от управления движением и понимания изображений до выполнения целых задач машины берут на себя более длинные и полные цепочки работы.

Таким образом, в этом эссе термин «ИИ» относится в первую очередь к агентам, управляемым базовыми моделями общего назначения, а агенты кодирования являются показательным примером. Их развитие указывает на автономное выполнение долгосрочных задач, постепенное саморазвитие и даже на способность обучать своих преемников.

В 2025 году Андрей Карпати использовал термин «вайб-кодинг», чтобы описать свободный стиль программирования: сообщите ИИ, чего вы хотите, примите сгенерированный код, верните ему сообщения об ошибках и даже забудьте о существовании самого кода. [1] Но зайти так далеко можно лишь при одном условии: цена неудачи должна быть низкой. В то время для серьёзных продуктов мы всё ещё использовали Cursor. Разработчики руководили работой и оставались ответственными за код; агент лишь помогал.

К началу 2026 года мы увидели, что граница снова сдвинулась вперед. Позже Карпати назвал новый способ работы «агентной разработкой»: разработчики больше не просто используют ИИ для завершения кода, но организуют и контролируют агентов во время выполнения ими инженерных задач, сохраняя при этом ответственность за проверку и качество. [2] Имя не имеет значения. Важно то, что ИИ переходит от предложений по одному к устойчивым действиям в рамках ограничений.

Для некоторых создателей программного обеспечения естественный язык и документы уже становятся новым слоем выражения намерений.

Код становится промежуточным артефактом

История вычислений — это также история добавления уровней абстракции.

Люди сначала управляли машинами с помощью переключателей и патч-кабелей. Затем появился машинный код, ассемблер и языки программирования высокого уровня. Каждый новый уровень скрывал часть сложности, расположенной ниже, и позволял людям работать ближе к своим намерениям.

Агенты кодирования добавляют новый уровень абстракции в разработку программного обеспечения. Они представляют собой что-то вроде недетерминированного суперкомпилятора: традиционный компилятор преобразует формально заданную программу в машинные инструкции, в то время как агент кодирования пытается воплотить человеческие намерения в интерфейсы, данные, сервисы и код.

Разница имеет значение. Человеческий язык неоднозначен. Требования часто неполны, а ограничения могут противоречить друг другу. Агент не может механически перевести предложение в единственный правильный результат. Он должен пройти через понимание, планирование, реализацию, исполнение и проверку.

Естественный язык не заменил языки программирования. Точнее, естественный язык и документы становятся слоем намерений, поддерживаемым людьми, в то время как код все чаще служит средой реализации, создаваемой и поддерживаемой агентами.

Это делает код скорее промежуточным артефактом, но «промежуточный» не означает неважный. Код по-прежнему должен быть корректным, безопасным и поддерживаемым. Возможно, его просто не нужно писать и читать построчно человеку. Большинство программистов не проверяют машинный код, сгенерированный компилятором, но они несут ответственность за то, что делает программа.

Это меняет то, что нам нужно прояснить.

Документация раньше была объяснением кода. В нашей работе отношения начинают меняться: на основе документов генерируется и проверяется больше кода. Почему продукт существует, как должна работать система, какие границы нельзя пересекать и какие доказательства показывают, что он соответствует своим требованиям — эти вещи, которые когда-то рассматривались как приложения к коду, становятся источником самого программного обеспечения.

Затем: "Разговоры дешевы. Покажите мне код".

Теперь: "Код стоит дешево. Покажите мне документацию".

Отсутствие написания кода вручную не снижает требований к выражению. Это их воспитывает. В прошлом неоднозначная идея успевала всплывать и проясняться в ходе длительного процесса реализации. Теперь агент может быстро превратить ее в работающую, казалось бы, законченную систему. Неясность не исчезла. Оно просто было похоронено в ходе реализации, где оно всплывет позже в виде неудач и потерь.

ИИ не избавляет нас от необходимости думать. Это только усложняет прятать смутные идеи за суетой реализации.

Другая половина «Бумаги и ручки»

В 2025 году Ван Цзянь сравнил ИИ с «новой бумагой и ручкой» человечества: не мыслью как таковой, а продолжением человеческой мысли. [3] Мне нравится эта метафора.

В нем заключена интересная историческая симметрия. В 1948 году Алан Тьюринг представил человека, вооружённого бумагой, карандашом и ластиком, следующего набору правил, поведение которого можно рассматривать как поведение универсальной машины. [4] Затем люди использовали бумагу и карандаш, чтобы объяснить, как человек может моделировать машину. Почти восемьдесят лет спустя направление, похоже, изменилось. Машина становится новой бумагой и ручкой, помогая людям воплощать намерения в миры, которые могут работать.

Метафора также напоминает мне об университете. Помимо сна, я, вероятно, тратил треть своего времени, переключаясь между программным и аппаратным обеспечением: устанавливая операционные системы, настраивая среду, инструменты обучения, возясь с микроконтроллерами, отлаживая колесных роботов и заставляя их координировать свои действия, а также создавая все, что меня интересовало. Мне нравился процесс, но я часто тратил больше времени на подготовку, чем на создание — как художник, вечно ищущий бумагу, изготавливающий пигменты и ремонтирующий кисти.

Назвать ИИ новой бумагой и ручкой не означает, что он может все. Бумага не пишет роман. Пигмент не создает хорошей картины, а камера не снимает хорошую пленку. Инструменты снижают стоимость выражения, но они не решают, что стоит выражать.

Агенты кодирования гораздо более активны, чем бумага и ручка. Они предлагают предложения, выполняют задачи и делают выбор в ограниченных рамках. Но до тех пор, пока они не смогут взять на себя ответственность за цель и последствия произведения, более широкое участие не сделает их автоматически авторами.

Меня интересует другая половина «новой бумаги и ручки»:

Если у нас есть новая бумага и ручка, какие художники нам нужны?

Центр создания программного обеспечения перемещается вверх

Идея о том, что программисты — это художники, не нова.

В 1974 году Дональд Кнут объяснил в книге «Компьютерное программирование как искусство», почему программирование требует знаний, навыков и творчества и как оно может создавать прекрасные объекты. [5] В 2003 году Пол Грэм в книге «Хакеры и художники» утверждал, что и хакеры, и художники являются творцами. Для создателей программного обеспечения компьютеры являются средством выражения, точно так же, как краска для художника или бетон для архитектора. [6]

ИИ не впервые делает программистов художниками. Меняется то, где в основном происходит искусство.

Большая часть творчества программиста раньше заключалась внутри кода: будь то гениальный алгоритм, элегантная абстракция или система, способная содержать достаточно возможностей с минимально возможной структурой. Такая красота не исчезнет с приходом агентов.

Но по мере того, как большая часть работы по реализации переходит к агентам, центр человеческого творчества перемещается вверх. Искусство программного обеспечения будет все больше выражаться в работе в целом: какие проблемы выбирать, чью жизнь понимать, какой порядок установить, от каких возможностей отказаться, как реагировать на пользователей и как работа должна войти в их жизнь.

Творчество на уровне продукта и опыта существовало всегда. Изменение заключается в том, что когда реализация больше не будет отнимать большую часть нашего внимания, эти проблемы могут стать основной работой большего числа создателей программного обеспечения.

Элегантный код по-прежнему имеет значение, но он никогда не был всей красотой программного обеспечения. Программное обеспечение, созданное совместно людьми и ИИ, следует рассматривать не просто как кучу работающего кода, а как целостную программу.

Это изменение, подразумеваемое «новыми художниками».

В существующих профессиональных терминах эта роль напоминает комбинацию менеджера по продукту и архитектора: они спрашивают, что и для кого должно быть сделано, а также как система может выжить и где проходят ее границы. Но этих титулов недостаточно. От автора программного обеспечения также нужен вкус, эмпатия, умение идти на компромисс и готовность брать на себя ответственность за общий результат.

«Художник» здесь не является более благородным титулом и не обязательно описывает одного человека. Это роль автора, ответственного за всю работу, и команда может поделиться ею.

Инженерное обеспечение обеспечивает надежное существование работы. Искусство определяет, почему оно существует и как входит в жизнь человека.

Инженерное дело не исчезнет, а ответственность нельзя будет передать на аутсорсинг

Новый художник не предлагает хорошую идею, а затем ждет, пока ИИ доделает все остальное.

Даже после того, как бумага и ручка получили широкое распространение, письмо по-прежнему требовало обучения; после того, как фотоаппараты получили широкое распространение, фотография все еще требовала суждений. Агенты кодирования снижают стоимость внедрения, но они не решают автоматически вопросы архитектуры, безопасности, производительности, качества или обслуживания в сложных системах.

Тот факт, что я не читаю код, не означает, что я отказался от инженерного контроля. Точки контроля изменились: от проверки реализации построчно до определения целей системы, архитектурных принципов, границ данных, моделей разрешений, стандартов тестирования, наблюдаемости и результатов приемочных испытаний.

Это не делает работу менее строгой. Это устанавливает строгость в другом месте. Покрывают ли тесты реальные риски? Показывают ли результаты времени выполнения, что система удовлетворяет своим ограничениям? Есть ли доказательства объяснения агента? Если функция работает, готова ли она к выпуску? ИИ может участвовать в каждой из этих задач, но в конечном итоге человек должен решить, заслуживают ли доказательства доверия и нести ответственность за ошибки.

Некоторые области, включая инфраструктуру, критически важные для безопасности системы и низкоуровневое программное обеспечение, по-прежнему будут требовать от людей глубокой работы над кодом. Им может понадобиться небольшое количество людей, которые действительно понимают нижние уровни, больше, чем когда-либо. Новый уровень абстракции никогда не стирает слои, находящиеся под ним. Языки высокого уровня не устранили ассемблер, а облачные вычисления не устранили операционные системы. Новый уровень просто позволяет большему количеству авторов избегать прохождения каждого нижнего уровня каждый раз, когда они что-то создают.

Мое решение не писать и не читать код — это ограниченная практика, а не правило для всех. Его ценность не в том, что он доказывает, что код устарел. Это помогает мне увидеть, какие части работы все еще нельзя передать, когда код больше не является единственным интерфейсом, через который люди управляют программным обеспечением.

Первое – это осуждение. Второе – это ответственность.

Более мощные инструменты могут также производить посредственность в большем масштабе. Когда реализация станет дешевле, мы можем сначала получить более повторяющееся, сырое программное обеспечение, не отвечающее реальной потребности. Бумага и ручка не производят литературу автоматически. Агенты кодирования не приведут автоматически к возрождению программного обеспечения.

ИИ не устраняет дефицит. Он лишь перемещает его.

Раньше производство программного обеспечения ограничивалось главным образом навыками программирования, инженерными ресурсами и временем внедрения. По мере того, как эти ограничения ослабевают, суждения о том, какие проблемы имеют значение, интуиция продукта, понимание систем, вкус, понимание людей и готовность брать на себя ответственность за последствия становятся относительно скудными.

По мере того, как «как это сделать» становится дешевле, «что делать» становится дороже.

От авторов кода к авторам программного обеспечения

Брет Тейлор процитировал наблюдение Арьи Асеманфар: ИИ может рисовать за вас, но автором по-прежнему остаетесь вы. [7] Адди Османи описал новую роль разработчика как архитектора и главного редактора. [8]

Автору не обязательно выполнять все действия, в результате которых создается произведение. Архитекторы не закладывают каждый кирпичик, а режиссеры не используют каждую камеру на съемочной площадке. Но они должны знать, какой должна стать работа, судить, увенчается ли она успехом, и брать на себя ответственность за работу в целом.

Те же изменения происходят и в программном обеспечении.

Раньше мы определяли автора программного обеспечения, спрашивая, кто написал код. В будущем авторство может все больше зависеть от другого набора вопросов: кто определил проблему? Кто установил ограничения? Кто пошел на критические компромиссы? Кто решил, что работа завершена? И кто несет ответственность за то, что происходит после его появления в мире?

Это также может изменить экономическую единицу программного обеспечения. В прошлом необходимость обычно должна была разделяться достаточным количеством людей, чтобы оправдать создание программного обеспечения для нее. Когда затраты на внедрение упадут достаточно сильно, конкретный рабочий процесс команды, семьи или даже одного человека может потребовать создания собственного программного обеспечения. Не каждый должен стать программистом, но авторами программного обеспечения может стать больше людей.

ИИ переносит большую часть работы по реализации вниз, одновременно перемещая человеческие контрольные точки и центр творения на один уровень абстракции вверх. Программисты больше не будут просто авторами кода. Все чаще они становятся авторами полных произведений программного обеспечения — я имею в виду «новых художников».

Прибыли новая бумага и ручка. Но новый ренессанс не последует автоматически. Это зависит не от того, сколько кода могут сгенерировать агенты, а от того, хватит ли у нас рассудительности — и готовности взять на себя ответственность — ответить на вопрос сложнее, чем «как это можно сделать?»

Что стоит создавать и как мы хотим, чтобы люди это испытали?

Ссылки

[1] Андрей Карпати, пост в X о «вайб-кодинге», 2 февраля 2025 г.

[2] Андрей Карпати, пост в X с предложением «агентной инженерии», 4 февраля 2026 г.

[3] Лю Нинсинь, «Ван Цзянь: инновации происходят из “несовершенства” и “пересечения границ”», 21st Century Business Herald, 25 сентября 2025 г.

[4] Алан М. Тьюринг, «Интеллектуальная техника», отчет Национальной физической лаборатории, 1948 год.

[5] Дональд Э. Кнут, «Компьютерное программирование как искусство», Communications of the ACM, 17(12), 1974, стр. 667–673.

[6] Пол Грэм, «Хакеры и художники», май 2003 г.

[7] Брет Тейлор, «ИИ — ваш писатель-призрак, но вы — автор», LinkedIn, 10 февраля 2026 г.

[8] Адди Османи, Beyond Vibe Coding, O’Reilly Media, август 2025 г.

Tôi không viết một dòng mã nào. Tôi cũng không đọc một dòng nào.

Nhưng điều đó không có nghĩa là tôi giao sản phẩm cho AI. Tôi vẫn quyết định sản phẩm cần giải quyết vấn đề gì, xác định hệ thống phải hoạt động ra sao, phán đoán những ranh giới không được vượt qua, kiểm chứng độ tin cậy của kết quả và chịu trách nhiệm về phần mềm cuối cùng. Điều thay đổi chỉ là cách tôi tương tác với khâu triển khai.

Điều này buộc tôi phải xem xét lại một câu hỏi từng có vẻ đơn giản: nếu ai đó không còn viết mã bằng tay nữa nhưng vẫn xác định công việc, quyết định xem nó có thành công hay không và vẫn chịu trách nhiệm về nó, thì họ có còn là tác giả của phần mềm không?

Thực tiễn này không chứng minh rằng tất cả phần mềm đều có thể được xây dựng theo cách này. Nó thậm chí còn không chứng minh được rằng những sản phẩm chưa được tung ra thị trường này sẽ thành công trên thị trường. Nhưng đối với các loại ứng dụng chúng tôi xây dựng, quy trình làm việc tập trung vào tác nhân mã hóa không còn chỉ là cách để lập trình nhanh hơn nữa. Nó đang trở thành một phương pháp tiếp cận kỹ thuật có thể duy trì việc lập kế hoạch, thực hiện, thử nghiệm, sửa chữa và lặp lại.

Thay đổi quan trọng không phải là “AI có thể viết mã”. Triển khai từng là một trong những phần khan hiếm nhất trong quá trình tạo ra phần mềm; bây giờ nó đang bắt đầu lùi dần vào nền.

Khi việc triển khai không còn là phần khan hiếm nhất, công việc của con người sẽ ra sao?

Đó là câu hỏi của bài viết này.

Ranh giới của AI đang chuyển động

AI chưa bao giờ là một thuật ngữ cố định. Mọi người có xu hướng gọi một thứ gì đó là AI trong khi máy tính vẫn chưa thể thực hiện được điều đó một cách đáng tin cậy; một khi khả năng này đã trưởng thành và đi vào các sản phẩm hàng ngày, nó sẽ nhanh chóng trở thành công nghệ thông thường và không còn giống AI nữa.

Con đường riêng của tôi cũng đi theo ranh giới này. Ở trường cấp hai và đại học, tôi đã nghiên cứu về robot có bánh xe, sử dụng cảm biến và điều khiển phản hồi để khiến chúng đi theo đường đi, tránh chướng ngại vật và phối hợp trong đội hình. Trong thời gian học sau đại học, tôi đã nghiên cứu về thị giác máy tính đồng thời tham gia SenseTime mới thành lập với tư cách là nhân viên sáng lập ban đầu. Tôi đã giúp đưa các công nghệ nhận diện sự sống của khuôn mặt và thị giác công nghiệp vào các ứng dụng quy mô lớn, bao gồm cả điện thoại thông minh và đường sắt tốc độ cao. Ngày nay, các mô hình nền tảng có mục đích chung và các tác nhân mà chúng hỗ trợ đã đẩy ranh giới về phía trước một lần nữa. Các hệ thống này không còn chỉ giải quyết các vấn đề riêng lẻ nữa. Họ bắt đầu hiểu mục tiêu, sử dụng các công cụ và tiếp tục hành động để đáp lại phản hồi; công việc của tôi cũng hướng tới những sản phẩm này. Nhìn lại, từ việc điều khiển chuyển động và hiểu hình ảnh đến hoàn thành toàn bộ nhiệm vụ, máy móc đang đảm nhận chuỗi công việc dài hơn và hoàn thiện hơn.

Vì vậy, trong bài luận này, AI chủ yếu chỉ các tác nhân được vận hành bởi mô hình nền tảng đa dụng, trong đó Coding Agent là một ví dụ tiêu biểu. Hướng phát triển của chúng là tự chủ thực hiện những nhiệm vụ dài hơi hơn, dần tự tiến hóa, thậm chí có khả năng huấn luyện thế hệ kế nhiệm của chính mình.

Năm 2025, Andrej Karpathy dùng “vibe coding” để mô tả một cách lập trình khá tùy hứng: nói cho AI biết bạn muốn gì, chấp nhận mã nó tạo ra, đưa thông báo lỗi trở lại cho nó, thậm chí quên luôn sự tồn tại của mã. [1] Nhưng mức độ buông tay ấy có một điều kiện tiên quyết: chi phí của thất bại phải thấp. Khi đó, với những sản phẩm nghiêm túc, chúng tôi vẫn dùng Cursor. Lập trình viên con người dẫn dắt công việc và chịu trách nhiệm về mã; tác nhân chỉ hỗ trợ.

Đến đầu năm 2026, chúng ta lại thấy ranh giới tiến về phía trước. Karpathy sau này gọi cách làm việc mới là “kỹ thuật tác nhân”: các nhà phát triển không còn chỉ đơn thuần sử dụng AI để hoàn thiện mã mà còn tổ chức và giám sát các tác nhân khi họ thực hiện các nhiệm vụ kỹ thuật trong khi vẫn giữ trách nhiệm đánh giá và chất lượng. [2] Cái tên không quan trọng. Điều quan trọng là AI đang chuyển từ đưa ra từng đề xuất một sang hành động bền vững trong giới hạn.

Đối với một số người sáng tạo phần mềm, ngôn ngữ tự nhiên và tài liệu đã trở thành một lớp mới để thể hiện ý định.

Mã đang trở thành một sản phẩm trung gian

Lịch sử của điện toán cũng là lịch sử của việc thêm các lớp trừu tượng.

Người ta lần đầu tiên vận hành máy móc bằng công tắc và cáp nối. Sau đó là mã máy, hợp ngữ và ngôn ngữ lập trình cấp cao. Mỗi lớp mới che giấu một số sự phức tạp bên dưới và cho phép mọi người làm việc gần hơn với ý định của họ.

Coding Agent bổ sung một lớp trừu tượng mới cho quá trình phát triển phần mềm. Chúng giống như một siêu trình biên dịch bất định: trình biên dịch truyền thống chuyển một chương trình được đặc tả hình thức thành lệnh máy, còn Coding Agent cố gắng triển khai ý định của con người thành giao diện, dữ liệu, dịch vụ và mã.

Sự khác biệt quan trọng. Ngôn ngữ của con người thật mơ hồ. Các yêu cầu thường không đầy đủ và các ràng buộc có thể xung đột. Tác nhân không thể dịch một cách máy móc một câu thành một kết quả chính xác duy nhất. Nó phải xoay vòng thông qua việc hiểu, lập kế hoạch, thực hiện, thực hiện và xác minh.

Ngôn ngữ tự nhiên chưa thay thế được ngôn ngữ lập trình. Chính xác hơn, ngôn ngữ tự nhiên và tài liệu đang trở thành một lớp ý định được duy trì bởi con người, trong khi mã ngày càng đóng vai trò là phương tiện triển khai được tạo ra và duy trì bởi các tác nhân.

Điều đó làm cho mã giống một tạo phẩm trung gian hơn, nhưng “trung gian” không có nghĩa là không quan trọng. Mã vẫn phải chính xác, an toàn và có thể bảo trì. Đơn giản là nó có thể không cần phải được một người viết và đọc từng dòng một. Hầu hết các lập trình viên không kiểm tra mã máy do trình biên dịch phát ra, nhưng họ vẫn chịu trách nhiệm về những gì chương trình thực hiện.

Điều này thay đổi những gì chúng ta cần làm rõ.

Tài liệu từng là một lời giải thích về mã. Trong công việc của chúng tôi, mối quan hệ đang bắt đầu đảo ngược: nhiều mã hơn đang được tạo và xác minh từ các tài liệu. Tại sao sản phẩm tồn tại, hệ thống phải hoạt động như thế nào, ranh giới nào không thể vượt qua và bằng chứng nào cho thấy sản phẩm đáp ứng các yêu cầu của nó—những thứ này, một khi được coi là phần đính kèm với mã, sẽ trở thành nguồn của chính phần mềm.

Sau đó: "Nói thì rẻ. Cho tôi xem mã."

Bây giờ: "Mã rẻ tiền. Cho tôi xem tài liệu."

Không viết mã bằng tay không làm giảm yêu cầu về cách diễn đạt. Nó còn làm yêu cầu ấy cao hơn. Trước đây, một ý tưởng mơ hồ có thời gian bộc lộ và trở nên rõ ràng hơn trong quá trình triển khai kéo dài. Giờ đây, tác nhân có thể nhanh chóng biến nó thành một hệ thống chạy được và có vẻ hoàn chỉnh. Sự mơ hồ không biến mất; nó chỉ bị chôn trong phần triển khai rồi xuất hiện về sau dưới dạng lỗi và tổn thất.

AI không miễn cho chúng ta khỏi việc suy nghĩ. Nó chỉ khiến ta khó che giấu những ý tưởng mơ hồ sau sự bận rộn của khâu triển khai.

Nửa còn lại của “Giấy và Bút”

Vào năm 2025, Wang Jian đã so sánh AI với “giấy và bút mới” của nhân loại: không phải bản thân suy nghĩ mà là một phần mở rộng của suy nghĩ con người. [3] Tôi thích phép ẩn dụ này.

Nó chứa đựng một sự đối xứng lịch sử thú vị. Năm 1948, Alan Turing tưởng tượng một người được trang bị giấy, bút chì và tẩy, tuân theo một bộ quy tắc, hành vi của người này có thể được coi là hành vi của một cỗ máy vạn năng. [4] Sau đó, người ta sử dụng giấy và bút chì để giải thích cách một người có thể mô phỏng một chiếc máy. Gần tám mươi năm sau, hướng đi dường như đã đảo ngược. Chiếc máy đang trở thành loại giấy và bút mới, giúp con người bộc lộ những ý định trong những thế giới có thể chạy được.

Phép ẩn dụ cũng làm tôi nhớ đến trường đại học. Ngoài việc ngủ, có lẽ tôi đã dành một phần ba thời gian của mình để di chuyển qua lại giữa phần mềm và phần cứng: cài đặt hệ điều hành, cấu hình môi trường, công cụ học tập, mày mò bộ vi điều khiển, gỡ lỗi cho robot có bánh xe và khiến chúng phối hợp thành đội hình cũng như xây dựng bất kỳ bản demo nào mà tôi quan tâm. Tôi rất thích quá trình này, nhưng tôi thường dành nhiều thời gian hơn để chuẩn bị sáng tạo hơn là sáng tạo—giống như một họa sĩ mãi mãi tìm kiếm giấy, tạo bột màu và sửa bút vẽ.

Gọi AI là giấy và bút mới không có nghĩa là nó có thể làm được mọi thứ. Giấy không viết tiểu thuyết. Sắc tố không vẽ ra một bức tranh đẹp, và một chiếc máy ảnh không tạo ra một bộ phim hay. Các công cụ làm giảm chi phí biểu đạt nhưng chúng không quyết định được điều gì đáng biểu đạt.

Tác nhân mã hóa hoạt động tích cực hơn nhiều so với giấy và bút. Họ đưa ra các đề xuất, thực hiện nhiệm vụ và đưa ra các lựa chọn trong phạm vi giới hạn. Nhưng cho đến khi họ có thể chịu trách nhiệm về mục đích và hậu quả của tác phẩm thì việc tham gia nhiều hơn không tự động khiến họ trở thành tác giả.

Điều khiến tôi quan tâm là nửa còn lại của “giấy và bút mới”:

Nếu chúng ta có giấy và bút mới, chúng ta cần loại nghệ sĩ nào?

Trung tâm sáng tạo phần mềm đang phát triển

Ý tưởng cho rằng lập trình viên là nghệ sĩ không phải là mới.

Năm 1974, Donald Knuth đã giải thích trong cuốn “Lập trình máy tính như một nghệ thuật” tại sao lập trình đòi hỏi kiến thức, kỹ năng và sự sáng tạo cũng như cách nó có thể tạo ra những đồ vật đẹp mắt. [5] Năm 2003, Paul Graham lập luận trong cuốn “Hackers and Painters” rằng tin tặc và họa sĩ đều là những nhà sản xuất. Đối với những người sáng tạo phần mềm, máy tính là phương tiện biểu đạt cũng giống như sơn dành cho họa sĩ hay bê tông dành cho kiến trúc sư. [6]

AI không phải thứ lần đầu biến lập trình viên thành nghệ sĩ. Nó đang thay đổi nơi nghệ thuật chủ yếu diễn ra.

Phần lớn nghệ thuật của một lập trình viên từng nằm trong mã: một thuật toán khéo léo, một phép trừu tượng thanh nhã, hay một hệ thống chứa đủ khả năng với ít cấu trúc nhất có thể. Vẻ đẹp này sẽ không biến mất chỉ vì các tác nhân đã xuất hiện.

Nhưng khi ngày càng nhiều công việc triển khai được giao cho các tác nhân, trung tâm sáng tạo của con người sẽ chuyển lên cao hơn. Nghệ thuật của phần mềm sẽ ngày càng được thể hiện trong toàn bộ tác phẩm: chọn vấn đề nào, thấu hiểu cuộc sống của ai, thiết lập trật tự nào, từ bỏ những khả năng nào, phản hồi người dùng ra sao và tác phẩm sẽ đi vào đời sống của họ như thế nào.

Sự sáng tạo ở cấp độ sản phẩm và kinh nghiệm luôn tồn tại. Sự thay đổi là khi việc triển khai không còn chiếm phần lớn sự chú ý của chúng ta nữa thì những mối quan tâm này có thể trở thành công việc chính của nhiều người sáng tạo phần mềm hơn.

Mã tao nhã vẫn quan trọng, nhưng mã chưa bao giờ là vẻ đẹp hoàn chỉnh của phần mềm. Phần mềm do con người và AI cùng nhau tạo ra không nên chỉ được coi là một đống mã chạy mà còn là một tác phẩm phần mềm hoàn chỉnh.

Đây là sự thay đổi được ngụ ý bởi “nghệ sĩ mới”.

Theo thuật ngữ chuyên môn hiện tại, vai trò này giống như sự kết hợp giữa người quản lý sản phẩm và kiến trúc sư: hỏi cả những gì nên làm và cho ai, cũng như cách hệ thống có thể tồn tại và ranh giới của nó nằm ở đâu. Nhưng những danh hiệu đó là chưa đủ. Tác giả của phần mềm cũng cần có khiếu thẩm mỹ, sự đồng cảm, khả năng đánh đổi và sẵn sàng chịu trách nhiệm về kết quả chung.

“Nghệ sĩ” ở đây không phải là một danh hiệu cao quý hơn, cũng không nhất thiết phải chỉ một người. Đó là vai trò của tác giả chịu trách nhiệm về một tác phẩm hoàn chỉnh và một nhóm có thể chia sẻ nó.

Kỹ thuật cho phép công việc tồn tại một cách đáng tin cậy. Nghệ thuật quyết định tại sao nó tồn tại và nó đi vào đời sống con người như thế nào.

Kỹ thuật sẽ không biến mất và trách nhiệm không thể được thuê ngoài

Người nghệ sĩ mới không đề xuất ý tưởng hay rồi đợi AI làm xong mọi việc còn lại.

Ngay cả sau khi giấy và bút đã trở nên phổ biến, việc viết vẫn cần được đào tạo; sau khi máy ảnh trở nên phổ biến, nhiếp ảnh vẫn cần có sự phán xét. Tác nhân mã hóa làm giảm chi phí triển khai nhưng chúng không tự động giải quyết kiến trúc, bảo mật, hiệu suất, chất lượng hoặc bảo trì trong các hệ thống phức tạp.

Việc tôi không đọc mã không có nghĩa là tôi đã từ bỏ việc kiểm soát kỹ thuật. Các điểm kiểm soát đã thay đổi: từ kiểm tra từng dòng triển khai đến xác định mục tiêu hệ thống, nguyên tắc kiến trúc, ranh giới dữ liệu, mô hình cấp phép, tiêu chuẩn kiểm tra, khả năng quan sát và kết quả kiểm tra chấp nhận.

Điều đó không làm công việc bớt nghiêm ngặt; nó đặt sự nghiêm ngặt ở một nơi khác. Kiểm thử có bao quát những rủi ro thực tế không? Kết quả khi chạy có cho thấy hệ thống thỏa mãn các ràng buộc không? Lời giải thích của tác nhân có bằng chứng hỗ trợ không? Một tính năng chạy được đã thực sự sẵn sàng để phát hành chưa? AI có thể tham gia từng việc này, nhưng cuối cùng con người phải quyết định bằng chứng có đáng tin hay không và gánh chịu hậu quả nếu quyết định sai.

Một số lĩnh vực—bao gồm cơ sở hạ tầng, hệ thống quan trọng về an toàn và phần mềm cấp thấp—sẽ tiếp tục yêu cầu mọi người làm việc sâu bên trong mã. Họ có thể cần một số ít người thực sự hiểu các tầng thấp hơn hơn bao giờ hết. Lớp trừu tượng mới không bao giờ xóa các lớp bên dưới nó. Ngôn ngữ cấp cao không loại bỏ việc lắp ráp và điện toán đám mây không loại bỏ hệ điều hành. Lớp mới chỉ đơn giản là cho phép nhiều người sáng tạo hơn tránh phải duyệt qua mọi lớp thấp hơn mỗi khi họ tạo nội dung nào đó.

Quyết định không viết hoặc đọc mã của tôi là một thực tế có giới hạn, không phải là quy tắc cho tất cả mọi người. Giá trị của nó không phải là nó chứng tỏ mã đã lỗi thời. Nó giúp tôi biết được phần nào của công việc vẫn chưa thể được chuyển giao khi mã không còn là giao diện duy nhất để mọi người kiểm soát phần mềm.

Đầu tiên là sự phán xét. Thứ hai là trách nhiệm.

Những công cụ mạnh mẽ hơn cũng có thể tạo ra sự tầm thường ở quy mô lớn hơn. Khi việc triển khai trở nên rẻ hơn, trước tiên chúng ta có thể nhận được nhiều phần mềm thô sơ, lặp đi lặp lại, không đáp ứng được nhu cầu thực sự. Giấy và bút không tự động tạo ra văn học. Các tác nhân mã hóa sẽ không tự động tạo ra sự phục hưng của phần mềm.

AI không xóa bỏ sự khan hiếm. Nó chỉ chuyển sự khan hiếm sang chỗ khác.

Việc sản xuất phần mềm trước đây bị hạn chế chủ yếu bởi kỹ năng lập trình, nguồn lực kỹ thuật và thời gian triển khai. Khi những hạn chế đó giảm bớt, khả năng phán đoán về vấn đề nào là quan trọng, trực giác về sản phẩm, sự hiểu biết về hệ thống, sở thích, sự hiểu biết về con người và sự sẵn sàng chịu trách nhiệm về hậu quả trở nên tương đối khan hiếm.

Khi “làm như thế nào” trở nên rẻ hơn thì “làm cái gì” sẽ đắt hơn.

Từ tác giả mã đến tác giả phần mềm

Bret Taylor đã trích dẫn một quan sát của Arya Asemanfar: AI có thể soạn thảo cho bạn, nhưng bạn vẫn là tác giả. [7] Addy Osmani đã mô tả vai trò mới của nhà phát triển là kiến trúc sư và tổng biên tập. [8]

Tác giả không nhất thiết phải thực hiện mọi hành động tạo nên tác phẩm. Kiến trúc sư không đặt từng viên gạch và đạo diễn không vận hành mọi máy quay trên phim trường. Nhưng họ phải biết công việc sẽ trở thành như thế nào, đánh giá liệu nó có thành công hay không và chịu trách nhiệm về toàn bộ công việc.

Sự thay đổi tương tự đang diễn ra trong phần mềm.

Chúng tôi thường xác định tác giả của phần mềm bằng cách hỏi ai đã viết mã. Trong tương lai, quyền tác giả có thể ngày càng phụ thuộc vào một loạt câu hỏi khác: Ai là người xác định vấn đề? Ai đã thiết lập những hạn chế? Ai đã thực hiện sự đánh đổi quan trọng? Ai quyết định rằng công việc đã hoàn thành? Và ai chịu trách nhiệm về những gì xảy ra sau khi nó xâm nhập vào thế giới?

Điều này cũng có thể thay đổi đơn vị kinh tế của phần mềm. Trước đây, nhu cầu thường phải được chia sẻ bởi đủ số người để có thể xây dựng phần mềm cho nhu cầu đó. Khi chi phí triển khai giảm đủ thấp, quy trình làm việc cụ thể của một nhóm, một gia đình hoặc thậm chí một người có thể đảm bảo phần mềm của riêng mình. Không phải ai cũng phải trở thành lập trình viên, nhưng sẽ có nhiều người hơn có thể trở thành tác giả của phần mềm.

AI đẩy công việc triển khai xuống dưới nhiều hơn trong khi di chuyển các điểm kiểm soát của con người và trung tâm sáng tạo lên một lớp trừu tượng. Các lập trình viên sẽ không còn đơn thuần là tác giả của mã nữa. Càng ngày họ càng trở thành tác giả của những tác phẩm phần mềm hoàn chỉnh - ý tôi là “những nghệ sĩ mới”.

Giấy và bút mới đã về. Nhưng một thời kỳ phục hưng mới sẽ không tự động diễn ra. Nó không phụ thuộc vào số lượng mã mà tác nhân có thể tạo ra mà phụ thuộc vào việc liệu chúng ta có khả năng phán đoán - và sẵn sàng chịu trách nhiệm - để trả lời một câu hỏi khó hơn “làm thế nào nó có thể được tạo ra?”

Điều gì đáng tạo ra và chúng ta muốn mọi người trải nghiệm nó như thế nào?

Tài liệu tham khảo

[1] Andrej Karpathy, Bài đăng trên X giới thiệu “vibe coding”, 2025-02-02.

[2] Andrej Karpathy, Bài đăng X đề xuất “kỹ thuật tác nhân”, 2026-02-04.

[3] Liu Ningxin, “Wang Jian: Sự đổi mới đến từ 'Sự không hoàn hảo' và 'Vượt qua ranh giới'", 21st Century Business Herald, 2025-09-25.

[4] Alan M. Turing, “Máy móc thông minh”, báo cáo của Phòng thí nghiệm Vật lý Quốc gia, 1948.

[5] Donald E. Knuth, “Lập trình máy tính như một nghệ thuật”, Truyền thông của ACM, 17(12), 1974, trang 667–673.

[6] Paul Graham, “Tin tặc và họa sĩ”, tháng 5 năm 2003.

[7] Bret Taylor, “AI là người chấp bút cho bạn, nhưng bạn mới là tác giả”, LinkedIn, 2026-02-10.

[8] Addy Osmani, Beyond Vibe Coding, O'Reilly Media, tháng 8 năm 2025.

我一行代码也没有写，也没有读。

但这不等于我把产品交给了 AI。我仍然决定它们要解决什么问题，定义系统怎样工作，判断哪些边界不可突破，验证结果是否可靠，并对最终的软件负责。改变的只是我与实现之间的界面。

这件事迫使我重新思考一个过去看似简单的问题：一个人如果不再亲手写代码，却仍然定义作品、判断它是否成立并为其负责，他还是软件的作者吗？

这段实践不能证明所有软件都可以这样开发。它甚至还不能证明这些尚未发布的产品最终会获得市场认可。但至少在我们所做的这类应用中，以 Coding Agent 为核心的工作方式已经不只是提高编程效率的辅助手段，而开始成为一条可以持续规划、实现、测试、修正和迭代的工程路径。

真正重要的变化并不是“AI 会写代码了”。真正的变化是，实现曾是软件创造中最稀缺的环节之一，如今正在逐渐退到幕后。

当实现不再是最稀缺的部分，人的工作会变成什么？

这才是本文想讨论的问题。

AI 的边界正在移动

AI 从来不是一个固定不变的名词。人们往往把计算机还不能稳定完成的事情称为 AI；一项能力一旦成熟、可靠并进入日常产品，很快就会被视为普通技术，不再显得像 AI。

我的经历也恰好沿着这条边界展开。中学和大学时，我做轮式机器人，依靠传感器和反馈控制实现循迹、避障与协同编队；研究生期间，我研究计算机视觉，同时作为早期创始员工加入刚刚起步的商汤科技，参与把人脸活体检测、工业视觉等技术带进智能手机、高速铁路等大规模应用。今天，通用大模型及其驱动的 Agent 又把边界向前推了一步。这类系统不再只解决单点问题，而开始理解目标、调用工具，并在反馈中持续行动；我的工作也随之转向这类产品。回头看，从控制运动、理解图像到执行完整任务，机器所能承担的任务链越来越长，也越来越完整。

因此，本文所说的 AI，主要指由通用大模型驱动的 Agent，Coding Agent 是其中的典型代表。这类 Agent 的发展方向是自主执行更长程的任务，并逐步实现自我演化，甚至训练出自己的下一代版本。

2025 年，Andrej Karpathy 用“氛围编程”（Vibe Coding）描述一种随性的编程方式：告诉 AI 想要什么，接受生成的代码，遇到错误就把报错信息交还给它，甚至可以忘记代码本身。[1] 但这种放手有一个前提：失败的代价足够低。当时，面对严肃产品，我们仍使用 Cursor，由人主导开发并对代码负责，Agent 只作辅助。

到了 2026 年初，我们观察到这条边界再次向前移动。Karpathy 后来把新的工作方式称为 Agentic Engineering：开发者不再只是用 AI 补全代码，而是组织和监督 Agent 完成工程任务，同时保留审查与质量责任。[2] 名称本身并不重要。重要的是，AI 开始从一次次给出建议，变成能够在约束下持续行动。

眼下已经发生的事情是：对一部分软件创造者而言，自然语言和文档正在成为一种新的意图表达层。

代码正在成为中间产物

计算机的发展史，也是一部不断增加抽象层的历史。

人们先用开关和插线操作机器，后来有了机器码、汇编语言和高级语言。每增加一层抽象，下面一层的复杂性就被封装起来，人也离自己的意图更近一点。

Coding Agent 为软件开发增加了一个新的抽象层。它有些像一台不那么确定的超级编译器：传统编译器把形式明确的程序转化为机器指令，Coding Agent 则尝试把人的意图展开为界面、数据、服务和代码。

两者的差别很重要。人类语言天然含混，需求经常残缺，约束也可能彼此冲突。Agent 不能把一句话机械地翻译成唯一结果，只能在理解、规划、实现、运行和验证之间反复循环。

所以，自然语言没有取代编程语言。更准确地说，自然语言和文档正在成为人维护的意图层，代码则越来越像由 Agent 生成和维护的实现载体。

代码因此更像中间产物，但“中间”并不意味着不重要。它仍然必须正确、安全、可维护，只是不一定再由人逐行写出和阅读。就像大多数程序员不需要查看编译器生成的机器码，但仍然要为程序的行为负责。

这改变了我们应该把什么写清楚。

过去，文档经常只是代码的说明。在我们的实践中，这层关系开始倒过来：代码越来越多地依据文档被生成和验证。产品为什么存在，系统怎样工作，哪些边界不可突破，什么证据可以证明它满足要求——这些过去常被视为代码附属物的内容，正在成为真正的源头。

过去是：“Talk is cheap. Show me the code.”

现在是：“Code is cheap. Show me the doc.”

不再亲手写代码，并没有降低表达的要求，反而要求我们表达得更加准确。过去，一个含混的想法还会在漫长的实现过程中逐渐暴露、逐渐澄清；现在，Agent 会迅速把它变成一个能够运行、看似完整的系统。含混并没有消失，只是被埋进了实现，直到日后以故障和损失的形式显现。

AI 没有让人免于思考。它只是让人更难以用实现的忙碌掩盖想法的含混。

“纸和笔”的下半句

2025 年，王坚把 AI 比作人类“新的纸和笔”：它不是思想本身，而是人类思想的一种延伸。[3] 我很认同这个比喻。

它带着一种有趣的历史对称。1948 年，图灵曾设想，一个人拿着纸、铅笔和橡皮，严格遵循一组规则，他的行为就可以被看作一台通用机器。[4] 那时，人们借助纸和笔解释人怎样模拟机器。近八十年后，方向似乎反了过来：机器正在成为新的纸和笔，帮助人把意图展开为可以运行的世界。

这个比喻也让我想起大学时的生活。除了睡觉，我大概有三分之一的时间都在软件和硬件之间来回折腾：安装操作系统、配置环境、学习工具，也摆弄单片机、调试轮式机器人，让它们协同编队，再做一些自己想做的演示。那个过程很有乐趣，但我也常常把更多时间花在准备创造上，而不是创造本身。就像一个画家总在寻找纸张、制作颜料和修理画笔。

说 AI 是新的纸和笔，并不是说它无所不能。纸不会自动写出小说，颜料不会自动画出好画，相机也不会自动拍出好电影。工具降低了表达成本，却不替创作者决定什么值得表达。

Coding Agent 比纸笔主动得多。它会提出建议、执行任务，也会在一定范围内作出选择。但只要它不能为作品的目的和后果承担责任，它就不会因为参与得更多而自动成为作者。

真正令我感兴趣的，是“新的纸和笔”的下半句：

如果有了新的纸和笔，我们需要什么样的艺术家？

软件创作的重心正在上移

“程序员是艺术家”不是一个新说法。

1974 年，Donald Knuth 在《作为艺术的计算机程序设计》中讨论编程为何既需要知识、技巧和创造力，也能产生具有美感的对象。[5] 2003 年，Paul Graham 在《黑客与画家》中提出，黑客与画家都是“创造东西的人”；对软件创造者而言，计算机就像颜料之于画家、混凝土之于建筑师，是一种表达媒介。[6]

所以，AI 并没有让程序员第一次成为艺术家。它改变的是艺术主要发生在哪里。

过去，程序员的艺术很大一部分发生在代码内部：一个算法是否精巧，一组抽象是否简洁，一个系统是否以尽可能少的结构容纳了足够多的可能性。这种美不会因为 Agent 出现而消失。

但当更多实现工作下沉到 Agent，人的创作重心会向上移动。软件的艺术将更多地体现在整个作品中：选择什么问题，理解怎样的人，建立什么秩序，舍弃哪些可能，怎样回应用户，又以什么方式进入人的生活。

产品和体验层面的创造早已存在。变化在于，当实现不再占据大部分注意力，这些工作可能成为更多软件创造者的主要工作。

代码的优雅仍然重要，但代码从来不是软件之美的全部。人与 AI 共同完成的软件，也不应只被看作一堆能够运行的代码，而应被看作一个完整的软件作品。

这就是“新的艺术家”所指向的变化。

如果用现有的职业语言近似描述，这个角色有些像产品经理和架构师的结合：既追问做什么、为谁而做，也追问系统怎样长期成立、边界在哪里。但这两个称呼还不够。软件的作者还需要审美、同理心、取舍能力，以及对整体结果负责的意愿。

这里的“艺术家”不是更高贵的职位，也不一定是某一个人。它是一种对完整作品负责的作者角色，也可以由一个团队共同承担。

工程让作品可靠地存在；艺术决定它为什么存在，以及怎样进入人的生活。

工程不会消失，责任不能外包

新的艺术家并不是提出一个好点子，然后等 AI 把剩下的事情做完。

纸笔普及以后，写作仍然需要训练；相机普及以后，摄影仍然需要判断。Coding Agent 降低了实现门槛，却没有自动解决复杂系统中的架构、安全、性能、质量和维护问题。

我不读代码，也不意味着我放弃了工程控制。控制点发生了变化：从逐行检查实现，转向明确系统目标、架构原则、数据边界、权限模型、测试标准、可观测性和验收结果。

这不是把严格变成宽松，而是把严格放在不同的地方。测试是否覆盖了真正的风险？运行结果能否证明系统满足约束？Agent 给出的解释是否有证据支持？一个功能能够运行，是否也意味着它值得交付？AI 可以参与这些工作，但最终必须由人判断证据是否可信，并承担判断错误的后果。

有些领域——例如基础设施、安全关键系统和底层软件——仍会长期要求人深入代码，甚至比过去更需要少数真正理解底层的人。新的抽象层从来不会消灭下面的层。高级语言没有消灭汇编，云计算也没有消灭操作系统。它只是让更多创造者不必在每一次创造中重新穿过所有底层。

我选择不写也不读代码，是一项有边界的实践，不是一条适用于所有人的规则。它的价值不在于证明代码已经过时，而在于帮助我看清：当代码不再是人控制软件的唯一界面，哪些工作仍然不能被交出去。

答案首先是判断，其次是责任。

更强的工具也可能带来更大规模的平庸。实现成本下降以后，我们很可能先得到更多重复、粗糙、没有真实需求的软件。纸和笔不会自动带来文学，Coding Agent 也不会自动带来软件的文艺复兴。

AI 没有消除稀缺性，它只是转移了稀缺性。

过去，软件生产的瓶颈主要在于编程能力、工程资源和实现时间。随着这些约束减弱，问题判断力、产品直觉、系统认知、审美、对人的理解，以及为后果负责的意愿，就会变得相对更加稀缺。

当“怎样做成”越来越便宜，“究竟做什么”就会变得越来越昂贵。

从代码的作者到软件作品的作者

Bret Taylor 曾引用 Arya Asemanfar 的一个概括：AI 可以替你起草，但你仍然是作者。[7] Addy Osmani 则把开发者的新角色描述为架构师和主编。[8]

作者并不等于亲手完成作品中的每一个动作。建筑师不亲手砌下每一块砖，导演也不操作片场里的每一台摄影机。但他们必须知道作品要成为什么，能够判断它是否成立，并对作品整体负责。

软件正在发生同样的变化。

过去，我们常常用“谁写了代码”来识别软件的作者。以后，作者身份可能越来越取决于另一组问题：谁定义问题，谁建立约束，谁作出关键取舍，谁判断作品已经完成，又由谁承担它进入现实世界之后的后果。

这还可能改变软件的经济单位。过去，通常只有足够多人共享的需求，才值得被开发成一套软件。当实现成本大幅下降，一个团队、一个家庭，甚至一个人的特殊工作流，也可能值得拥有自己的软件。未来未必人人都要成为程序员，但更多人可以成为软件的作者。

AI 把越来越多的实现工作向下推，也把人的控制点和创作重心向上推了一个抽象层。程序员将不再只是代码的作者，而会越来越成为软件作品的作者——这就是我所说的“新的艺术家”。

新的纸和笔已经出现。但新的文艺复兴不会因此自动到来。它不取决于 Agent 能生成多少代码，而取决于我们是否有判断力，也是否愿意承担责任，回答一个比“怎样做成”更困难的问题：

什么值得被创造，我们又希望人怎样感受它？

参考资料

[1] Andrej Karpathy，介绍“Vibe Coding”的 X 帖子，2025-02-02。

[2] Andrej Karpathy，提出“Agentic Engineering”的 X 帖子，2026-02-04。

[3] 柳宁馨，《王坚：创新源于“不完美”与“跨界”》，《21世纪经济报道》，2025-09-25。

[4] Alan M. Turing，“Intelligent Machinery”，National Physical Laboratory report，1948。

[5] Donald E. Knuth，“Computer Programming as an Art”，Communications of the ACM，17(12)，1974，pp. 667–673。

[6] Paul Graham，“Hackers and Painters”，2003-05。

[7] Bret Taylor，“AI is your ghostwriter, but you are the author”，LinkedIn，2026-02-10。

[8] Addy Osmani，Beyond Vibe Coding，O’Reilly Media，2025-08。

我一行程式碼也沒有寫，也沒有讀。

但這不等於我把產品交給 AI了。我仍然決定它們要解決什麼問題，定義系統怎麼運作，判斷哪些邊界不可突破，驗證結果是否可靠，並對最終的軟體負責。改變的只是我與實現之間的介面。

這件事迫使我重新思考一個過去看似簡單的問題：一個人如果不再親手寫程式碼，卻仍然定義作品、判斷它是否成立並為其負責，他還是軟體的作者嗎？

這段實踐不能證明所有軟體都可以這樣開發。它甚至還不能證明這些尚未發布的產品最終會獲得市場認可。但至少在我們所做的這類應用中，以 Coding Agent 為核心的工作方式已經不只是提高程式效率的輔助手段，而開始成為一條可以持續規劃、實現、測試、修正和迭代的工程路徑。

真正重要的改變並不是「AI 會寫程式了」。真正的改變是，實現曾是軟體創造中最稀缺的環節之一，如今正逐漸退到幕後。

當實現不再是最稀缺的部分，人的工作會變成什麼？

這才是本文想討論的問題。

AI 的邊界正在移動

AI 從來不是一個固定不變的名詞。人們往往把電腦還不能穩定完成的事情稱為 AI；一項能力一旦成熟、可靠並進入日常產品，很快就會被視為普通技術，不再顯得像 AI。

我的經歷也恰好沿著這條邊界展開。中學和大學時，我做輪式機器人，依靠感測器和回饋控制實現循跡、避障與協同編隊；研究生期間，我研究電腦視覺，同時作為早期創始員工加入剛起步的商湯科技，參與把人臉活體檢測、工業視覺等技術帶進智慧型手機、高速鐵路等大規模應用。今天，通用大模型及其驅動的 Agent 又把邊界向前推了一步。這類系統不再只解決單點問題，而開始理解目標、呼叫工具，並在回饋中持續行動；我的工作也隨之轉向這類產品。回頭看，從控制運動、理解影像到執行完整任務，機器所能承擔的任務鏈越來越長，也越來越完整。

因此，本文所說的 AI，主要指由通用大模型驅動的 Agent，Coding Agent 是其中的典型代表。這類 Agent 的發展方向是自主執行更長程的任務，逐步實現自我演化，甚至訓練出自己的下一代版本。

2025 年，Andrej Karpathy 用「氛圍程式設計」（Vibe Coding）描述一種隨性的程式設計方式：告訴 AI 想要什麼，接受產生的程式碼，遇到錯誤就把報錯訊息交還給它，甚至可以忘記程式碼本身。 [1] 但這種放手有個前提：失敗的代價夠低。當時，面對嚴肅產品，我們仍使用 Cursor，由人主導開發並對程式碼負責，Agent 只作輔助。

到了 2026 年初，我們觀察到這條邊界再次向前移動。 Karpathy 後來把新的工作方式稱為 Agentic Engineering：開發者不再只是用 AI 補全程式碼，而是組織和監督 Agent 完成工程任務，同時保留審查與品質責任。 [2] 名稱本身並不重要。重要的是，AI 開始從一次次給予建議，變成能夠在限制下持續行動。

眼下已經發生的事情是：對一部分軟體創造者而言，自然語言和文件正在成為一種新的意圖表達層。

程式碼正在成為中間產物

計算機的發展史，也是一部不斷增加抽象層的歷史。

人們先用開關和插線操作機器，後來有了機器碼、組合語言和高階語言。每增加一層抽象，下面一層的複雜性就被封裝起來，人也離自己的意圖更近一點。

Coding Agent 為軟體開發增加了一個新的抽象層。它有些像是一台不那麼確定的超級編譯器：傳統編譯器把形式明確的程式轉化為機器指令，Coding Agent 則試著把人的意圖展開為介面、資料、服務和程式碼。

兩者的差異很重要。人類語言天然含混，需求經常殘缺，約束也可能彼此衝突。 Agent 不能把一句話機械地翻譯成唯一結果，只能在理解、規劃、實現、運作和驗證之間反覆循環。

所以，自然語言沒有取代程式語言。更準確地說，自然語言和文件正在成為人類維護的意圖層，程式碼則越來越像由 Agent 產生和維護的實作載體。

代碼因此更像中間產物，但“中間”並不意味著不重要。它仍然必須正確、安全、可維護，但不一定再由人逐行寫出和閱讀。就像大多數程式設計師不需要查看編譯器產生的機器碼，但仍然要為程式的行為負責。

這改變了我們應該把什麼寫得清楚。

過去，文檔經常只是程式碼的說明。在我們的實踐中，這層關係開始倒過來：程式碼越來越多地依據文件被產生和驗證。產品為什麼存在，系統怎麼運作，哪些邊界不可突破，什麼證據可以證明它滿足要求──這些過去常被視為代碼附屬物的內容，正在成為真正的源頭。

過去是：“Talk is cheap. Show me the code.”

現在是：“Code is cheap. Show me the doc.”

不再親手寫程式碼，並沒有降低表達的要求，反而要求我們表達得更精確。過去，一個含混的想法還會在漫長的實現過程中逐漸暴露、逐漸澄清；現在，Agent 會迅速把它變成一個能夠運作、看似完整的系統。含混並沒有消失，只是被埋進了實現，直到日後以故障和損失的形式顯現。

AI 沒有讓人免於思考。它只是讓人更難以實現的忙碌掩蓋想法的含混。

「紙和筆」的下半句

2025 年，王堅把 AI 比喻為人類「新的紙和筆」：它不是思想本身，而是人類思想的一種延伸。 [3] 我很認同這個比喻。

它帶著一種有趣的歷史對稱。 1948 年，圖靈曾設想，一個人拿著紙、鉛筆和橡皮，嚴格遵循一組規則，他的行為就可以被看作一台通用機器。 [4] 那時，人們用紙筆解釋人怎麼模擬機器。近八十年後，方向似乎反了過來：機器正在成為新的紙和筆，幫助人們將意圖展開為可以運作的世界。

這個比喻也讓我想起大學時的生活。除了睡覺，我大概有三分之一的時間都在軟體和硬體之間來回折騰：安裝作業系統、配置環境、學習工具，也擺弄單片機、調試輪式機器人，讓它們協同編隊，再做一些自己想做的演示。那個過程很有樂趣，但我也常常把更多時間花在準備創作上，而不是創作本身。就像一個畫家總是在尋找紙張、製作顏料和修理畫筆。

說 AI 是新的紙和筆，並不是說它無所不能。紙不會自動寫出小說，顏料不會自動畫出好畫，相機也不會自動拍出好電影。工具降低了表達成本，卻不替創作者決定什麼值得表達。

Coding Agent 比紙筆主動許多。它會提出建議、執行任務，也會在一定範圍內做出選擇。但只要它不能為作品的目的和後果承擔責任，它就不會因為參與更多而自動成為作者。

真正令我感興趣的，是「新的紙和筆」的下半句：

如果有了新的紙和筆，我們需要什麼樣的藝術家？

軟體創作的重心正在上移

「程式設計師是藝術家」不是一個新說法。

1974 年，Donald Knuth 在《作為藝術的電腦程式設計》中討論程式設計為何既需要知識、技巧和創造力，也能產生具有美感的物件。 [5] 2003 年，Paul Graham 在《駭客與畫家》中提出，駭客與畫家都是「創造東西的人」；對軟體創造者而言，電腦就像顏料之於畫家、混凝土之於建築師，是一種表達媒介。 [6]

所以，AI 並沒有讓程式設計師第一次成為藝術家。它改變的是藝術主要發生在哪裡。

過去，程式設計師的藝術很大一部分發生在程式碼內部：一個演算法是否精巧，一組抽像是否簡潔，一個系統是否以盡可能少的結構容納了足夠的可能性。這種美不會因為 Agent 出現而消失。

但當更多實現工作下沉到 Agent，人的創作重心會向上移動。軟體的藝術將更體現在整部作品中：選擇什麼問題，理解怎樣的人，建立什麼秩序，捨棄哪些可能，怎樣回應用戶，又以什麼方式進入人的生活。

產品和體驗層面的創造早已存在。變化在於，當實現不再佔據大部分注意力，這些工作可能成為更多軟體創造者的主要工作。

程式碼的優雅仍然重要，但程式碼從來不是軟體之美的全部。人與 AI 共同完成的軟體，也不應只被看作一堆能夠運作的程式碼，而應被視為一個完整的軟體作品。

這就是「新的藝術家」所指向的改變。

如果用現有的職業語言近似描述，這個角色有些像是產品經理和架構師的結合：既追問做什麼、為誰而做，也追問系統怎樣長期成立、邊界在哪裡。但這兩個稱呼還不夠。軟體的作者還需要美感、同理心、取捨能力，以及對整體結果負責的意願。

這裡的「藝術家」不是更高貴的職位，也不一定是某一個人。它是一種對完整作品負責的作者角色，也可以由一個團隊共同承擔。

工程讓作品可靠地存在；藝術決定它為什麼存在，以及如何進入人的生活。

工程不會消失，責任不能外包

新的藝術家並不是提出一個好點子，然後等 AI 把剩下的事情做完。

紙筆普及以後，寫作仍需要訓練；相機普及以後，攝影仍需要判斷。 Coding Agent 降低了實現門檻，卻沒有自動解決複雜系統中的架構、安全性、效能、品質和維護問題。

我不讀程式碼，也不代表我放棄了工程控制。控制點發生了變化：從逐行檢查實現，轉向明確系統目標、架構原則、資料邊界、權限模型、測試標準、可觀測性和驗收結果。

這不是把嚴格變成寬鬆，而是把嚴格放在不同的地方。測試是否涵蓋了真正的風險？運行結果能否證明系統滿足約束？ Agent 所給的解釋是否有證據支持？一個功能能夠運行，是否也意味著它值得交付？ AI 可以參與這些工作，但最終必須由人們判斷證據是否可信，並承擔判斷錯誤的後果。

有些領域——例如基礎設施、安全關鍵系統和底層軟體——仍會長期要求人們深入程式碼，甚至比過去更需要少數真正理解底層的人。新的抽象層從來不會消滅下面的層。高階語言沒有消滅彙編，雲端運算也沒有消滅作業系統。它只是讓更多創造者不必在每一次創造中重新穿過所有底層。

我選擇不寫也不讀程式碼，是一項有邊界的實踐，不是一條適用於所有人的規則。它的價值不在於證明程式碼已經過時，而是幫助我看清楚：當程式碼不再是人控制軟體的唯一介面，哪些工作仍然不能被交出去。

答案首先是判斷，其次才是責任。

更強的工具也可能帶來更大規模的平庸。實現成本下降以後，我們很可能會先得到更多重複、粗糙、沒有真實需求的軟體。紙和筆不會自動帶來文學，Coding Agent 也不會自動帶來軟體的文藝復興。

AI 沒有消除稀缺性，它只是轉移了稀缺性。

過去，軟體生產的瓶頸主要在於程式設計能力、工程資源和實現時間。隨著這些限制減弱，問題判斷力、產品直覺、系統認知、美感、對人的理解，以及為後果負責的意願，就會變得相對更加稀缺。

當「怎麼做成」越來越便宜，「究竟做什麼」就會變得越來越昂貴。

從程式碼的作者到軟體作品的作者

Bret Taylor 曾經引用 Arya Asemanfar 的一個概括：AI 可以替你起草，但你仍然是作者。 [7] Addy Osmani 則是把開發者的新角色描述為架構師和主編。 [8]

作者並不等於親手完成作品中的每一個動作。建築師不親手砌下每一塊磚，導演也不操作片場裡的每台攝影機。但他們必須知道作品要成為什麼，能夠判斷它是否成立，並對作品整體負責。

軟體正在發生同樣的變化。

過去，我們常常用「誰寫了程式碼」來辨識軟體的作者。以後，作者身分可能越來越取決於另一組問題：誰定義問題，誰建立約束，誰作出關鍵取捨，誰判斷作品已經完成，又由誰承擔它進入現實世界之後的後果。

這也可能改變軟體的經濟單位。過去，通常只有足夠多人共享的需求，才值得被開發成一套軟體。當實現成本大幅下降，一個團隊、一個家庭，甚至一個人的特殊工作流程，也可能值得擁有自己的軟體。未來未必人人都要成為程式設計師，但更多人可以成為軟體的作者。

AI 把越來越多的實現工作向下推，也把人的控制點和創作重心向上推了一個抽象層。程式設計師將不再只是程式碼的作者，而會越來越成為軟體作品的作者——這就是我所說的「新的藝術家」。

新的紙和筆已經出現。但新的文藝復興不會因此自動到來。它不取決於 Agent 能產生多少程式碼，而取決於我們是否有判斷力，也是否願意承擔責任，回答一個比「怎麼做成」更困難的問題：

什麼值得被創造，我們又希望人怎麼感受它？

參考資料

[1] Andrej Karpathy，介紹「Vibe Coding」的 X 貼文，2025-02-02。

[2] Andrej Karpathy，提出「Agentic Engineering」的 X 貼文，2026-02-04。

[3] 柳寧馨，《王堅：創新源自「不完美」與「跨界」》，《21世紀經濟報道》，2025-09-25。

[4] Alan M. Turing，“Intelligent Machinery”，National Physical Laboratory report，1948。

[5] Donald E. Knuth，“Computer Programming as an Art”，Communications of the ACM，17(12)，1974，pp. 667–673。

[6] Paul Graham，“Hackers and Painters”，2003-05。

[7] Bret Taylor，“AI is your ghostwriter, but you are the author”，LinkedIn，2026-02-10。

[8] Addy Osmani，Beyond Vibe Coding，O’Reilly Media，2025-08。

Bevor wir es veröffentlichten, wusste ich bereits, dass es nicht gut genug war.

Seine Benutzeroberfläche war nicht ausgefeilt, die Interaktionen fühlten sich noch nicht natürlich an und der Funktionsablauf war unvollständig. Wir konnten viele der Probleme erkennen, ohne auf das Feedback der Benutzer warten zu müssen. Noch beunruhigender ist, dass diese Probleme nicht voneinander zu trennen sind. Schnittstelle, Benutzererfahrung, funktionale Vollständigkeit, Zuverlässigkeit und Wartbarkeit mussten alle gleichzeitig funktionieren, bevor daraus ein vollständiges Produkt entstehen konnte.

Aber wir hatten gerade Monate damit verbracht, eine Reihe von Startup-Methoden zu erlernen: Kunden frühzeitig treffen, in kleinen Schritten vorgehen und schnell iterieren. Obwohl wir mit dem Produkt unzufrieden waren, waren wir dennoch der Meinung, dass wir es zuerst veröffentlichen sollten.

UBenutzer brachten schnell viele Probleme zur Sprache. Eine beträchtliche Anzahl davon war uns bereits vor der Veröffentlichung bekannt. Ihr Feedback wurde zum Ausgangspunkt für die Veränderung, die wir in der zweiten Jahreshälfte vorgenommen haben.

Rückblickend teilte dieser Betatest das Jahr 2025 in zwei Hälften. In der ersten Hälfte haben wir MagicGourd weiter ausgebaut, in der Hoffnung, seine Magie endlich zum Vorschein zu bringen. Mitte des Jahres haben wir eine Idee in Sayso extrahiert, sie schnell umgesetzt und den Benutzern präsentiert. In der zweiten Jahreshälfte konzentrierten wir uns darauf, unsere Produktfähigkeiten weiter auszubauen, statt weiterhin der Veröffentlichungsgeschwindigkeit nachzujagen. Der Ausgangspunkt für all dies war Anfang des Jahres, als wir Investitionen von MiraclePlus erhielten und uns seinem Accelerator anschlossen.

Am Ende des Jahres hatten wir diesen Dolch immer noch nicht hergestellt. Aber wir begannen zu verstehen: Eine Klingenspitze allein ist kein Dolch.

Ein Interview, an dem ich nicht teilnehmen wollte

Zu Beginn des Jahres 2025 hatte ich nicht vor, Geld zu sammeln.

Im Jahr 2024 hatten wir die meiste Zeit damit verbracht, MagicGourd zu entwickeln und 27 Versionen zu veröffentlichen. Unsere begrenzten Spendenversuche hatten zu nichts geführt, und das Produkt war immer noch weit von dem „echten zweiten Gehirn“ entfernt, das wir uns vorgestellt hatten. Aber ich habe den Prozess des Aufbaus sehr genossen.

Ich dachte, wir könnten in sehr kleinem Maßstab weitermachen und Schritt für Schritt vorankommen, ohne überstürzt Investitionen tätigen zu müssen.

Kehan hat meine Meinung geändert. Er sagte mir, dass es beim Fundraising nicht unbedingt nur um Geld gehe. Der MiraclePlus Accelerator, seine Mentoren und seine Alumni könnten uns auch über einen viel längeren Zeitraum helfen.

Da war die Bewerbungsfrist bereits abgelaufen. Aber ich wollte die Empfehlung von Kehan nicht ungenutzt lassen, also reichte ich trotzdem eine Bewerbung ein und beschrieb kurz, wie ich mir ein echtes zweites Gehirn vorstellte.

Dieses Interview fand im MiraclePlus-Büro in Peking statt. Während ich wartete, sah ich auf einem Bildschirm mehrere Interviewvorschläge: Die Antworten sollten einfach, direkt und wahrheitsgemäß sein.

In dem Interview ein Jahr zuvor hatte ich unbewusst nach den Antworten gesucht, die Investoren hören wollten. Als sie unsere Ideen wiederholt in Frage stellten, machte ich mir Sorgen, dass meine Antworten nicht gut genug waren. Weil ich die Leute am Tisch respektierte, konnte ich sogar anfangen, an meinem eigenen Urteilsvermögen zu zweifeln.

Diesmal hatte ich es nicht so eilig.

Nach einem ganzen Jahr der Entwicklung im Jahr 2024 befanden wir uns immer noch im Wasser, kämpften aber nicht mehr so sehr wie unmittelbar nach dem Sprung ins Wasser. Ich habe nicht versucht zu beweisen, dass ich Recht haben muss, und ich hatte keine ausgefeilten Antworten vorbereitet. Ich habe einfach gesagt, was ich wirklich dachte.

Dr. Lu Qi fragte, was ich von SenseTime halte. Ich sagte, dass ich dem Unternehmen zuallererst zutiefst dankbar bin, weil ich dort eine entscheidende Phase des Wachstums und der Transformation durchgemacht habe. Um die Einführung von ChatGPT herum reagierte SenseTime möglicherweise etwas langsam, da ein großes Schiff schwer zu wenden ist. Aber bis 2025 sah ich, dass sich die Lage schnell ändern würde, und ich glaubte, dass eine bessere Ära für SenseTime anbrechen würde.

Dann fragte er, was ich von DeepSeek halte. Meine Antwort war ein Wort: Kosten. Ich habe es damals nicht näher ausgeführt. Ich glaubte einfach, dass sich die Kosten direkt auf das Ausmaß auswirken würden, in dem eine Technologie in die reale Welt gelangen könnte.

Das Interview verlief reibungsloser, als ich erwartet hatte. Vielleicht weil ich nicht mehr verzweifelt auf ein bestimmtes Ergebnis hoffte, fiel es mir leichter, einfach zu sprechen.

Später investierte MiraclePlus in uns und wir schlossen uns dem Accelerator an.

Wir wollten, dass die Magie endlich erscheint

Wenn das Ziel im Jahr 2024 darin bestand, zuerst den Kürbis herzustellen, dann wollten wir Anfang 2025, dass seine Magie endlich zum Vorschein kommt.

Im Jahr 2024 waren wir konzentriert geblieben und haben die MagicGourd-Version 0.27 fertiggestellt. Es half den Menschen, auf Webseiten, Online-PDFs und Videos zu markieren, was sie bewegte, die aufkommenden Gedanken aufzuzeichnen und alles über die Zeit hinweg zu bewahren.

Aber es war immer noch näher an einem Container. Es konnte die Aufzeichnungen einer Person sammeln und verwalten, sie jedoch nicht wirklich verstehen, geschweige denn jemandem dabei helfen, unvollendete Gedanken aufzudecken.

Als wir für 2025 planten, haben wir uns ein viel größeres Ziel gesetzt. Wir würden uns nicht mehr mit dem Hinzufügen von Funktionen zufrieden geben. Wir wollten einen echten Schritt in Richtung des wahren zweiten Gehirns machen, das wir uns vorgestellt hatten.

Wir wollten die langfristigen Aufzeichnungen einer Person verstehen, über verschiedene Zeiten und unterschiedliche Inhalte verstreute Zusammenhänge finden, verstehen, was der Benutzer in diesem Moment dachte, und Absichten erkennen, die er noch nicht klar ausgedrückt hatte.

Das Ziel war aufregend. Es lag auch weit außerhalb des Rahmens, den wir damals bewältigen konnten.

Im ersten Halbjahr haben wir enorme Anstrengungen in die Entwicklung gesteckt. Das Problem war nicht der Mangel an harter Arbeit, sondern die Menge an Dingen, die auf einmal gelöst werden mussten. Jeder Schritt vorwärts brachte weitere Fragen zu Tage. Der Umfang wurde immer größer, während sich unser Entwicklungstempo immer weiter verlangsamte. Ein halbes Jahr verging, und wir hatten den Benutzern immer noch nicht den wichtigsten Wert dargelegt.

Nachdem wir dem MiraclePlus Accelerator beigetreten waren, hörten wir immer wieder ein Wort: sharp.

Mein Mentor im Accelerator, Peter, sagte uns wiederholt, dass ein Startup einen Dolch und kein Schweizer Taschenmesser herstellen sollte.

Als das erste Halbjahr zu Ende ging, begannen wir zu glauben, dass das Problem darin bestand, dass das Produkt zu groß geworden war. Wenn wir nicht auf einmal ein echtes zweites Gehirn aufbauen könnten, sollten wir dessen wichtigstes Element extrahieren und daraus ein Produkt machen, das klein, schnell und cool ist.

Damals dachten wir, das sei die Bedeutung eines Dolches.

Ein zweites Gehirn sollte Absichten verstehen, die noch nicht ausgesprochen wurden

Wir haben wiederholt gefragt, was in einem zweiten Gehirn am wichtigsten ist.

Die Antwort, die wir schließlich fanden, war, die Absicht zu verstehen.

Ein gewöhnliches Informationstool beginnt normalerweise mit dem, was der Benutzer bereits eingegeben hat. Wenn ein Benutzer einen Satz schreibt, kann er ihn überarbeiten. Wenn der Benutzer eine Frage stellt, kann er antworten. Wenn der Benutzer einen Artikel speichert, kann er ihn zusammenfassen.

Doch viele menschliche Absichten kommen zu Beginn nicht klar zum Ausdruck. Manchmal haben wir nur ein vages Gefühl dafür, dass etwas wichtig ist, ohne zu wissen, was uns wirklich interessiert. Manchmal stehen wir kurz davor, jemanden zu treffen, der wichtig ist, und haben viele Informationen im Kopf, wissen aber nicht, was es am meisten wert ist, gesagt zu werden. Manchmal kennen wir das Gefühl, das wir ausdrücken wollen, finden aber nicht die richtigen Worte.

Wenn ein zweites Gehirn den aktuellen Kontext des Benutzers mit diesen unausgesprochenen Absichten kombinieren könnte, würde es mehr tun, als nur vorhandene Informationen zu verarbeiten. Es würde beginnen, an dem Prozess teilzunehmen, durch den eine Person einen Ausdruck oder ein Urteil bildet.

Basierend auf dieser Idee haben wir Mitte des Jahres ein Produkt namens Sayso konzipiert.

Anhand des aktuellen Kontexts der Person würde es ihr helfen zu erkennen, was sie als nächstes sagen könnte. Wir wollten nicht, dass die KI über die wahren Absichten eines Benutzers entscheidet. Wir wollten, dass es mögliche Richtungen bietet, anhand derer der Benutzer erkennen kann, was er tatsächlich ausdrücken möchte.

Dieser Bedarf tritt in vielen realen Situationen auf. Bevor man eine wichtige Person trifft oder ein wichtiges Gespräch beginnt, mangelt es den Menschen oft nicht an Gesprächsstoff. Das Problem besteht darin, zu wissen, welcher Teil einer großen Informationsmenge in diesem Moment am wichtigsten ist.

Sayso hat versucht, das große Ziel, die impliziten Absichten einer Person zu verstehen, in einer konkreten Aufgabe zusammenzufassen: den gegenwärtigen Kontext der Person zu nutzen, um Absichten aufzudecken, die sie noch nicht geäußert hatte.

Wir dachten, wir hätten endlich einen Dolch in der riesigen Idee eines zweiten Gehirns gefunden.

Wir haben „Klein“ mit „Scharf“ verwechselt

Mitte des Jahres sind wir von einem großen auf ein kleines Produkt umgestiegen und unsere Entwicklungsgeschwindigkeit hat sich spürbar erhöht.

Aber während dieser Umstellung beschränkte sich unser Verständnis eines Dolches noch auf seine äußere Form.

Wir dachten, die Verkleinerung des Produkts würde es zu einem Dolch machen. Wir dachten, weniger Funktionen machen es zu einem Dolch. Später verwechselten wir Neuheit und Entwicklungsgeschwindigkeit auch mit Schärfe: Wenn sich ein Produkt neu anfühlte, schnell gebaut werden konnte und die Benutzer schnell erreichen konnte, schien es der richtigen Antwort näher zu sein als das Schweizer Taschenmesser, das wir gebaut hatten.

Mitte des Jahres haben wir Sayso in kürzester Zeit aufgebaut und den Beta-Nutzern zur Verfügung gestellt.

Ihr Feedback zeigte uns, dass einige Leute wirklich Hilfe brauchten, sich vor einem wichtigen Meeting oder Gespräch auszudrücken, und dass sie verstehen konnten, wie wichtig es ist, Absichten aus dem Kontext zu erkennen. Dies war ein erster Beweis dafür, dass das Problem, auf das wir abzielten, real war und nicht nur eine Idee, die neuartig klang.

Aber das Produkt selbst funktionierte nicht.

Eine KI-Demo zum Verstehen von Absichten muss möglicherweise nur anhand einiger sorgfältig vorbereiteter Beispiele zu einem überraschenden Ergebnis führen. Ein echtes Produkt musste den Benutzern zeigen, welchen Kontext sie bereitstellen sollten, ihnen helfen zu verstehen, warum es bestimmte Vorschläge machte, und es ihnen ermöglichen, diese Vorschläge auf natürliche Weise zu bearbeiten, auszuwählen oder abzulehnen.

Die Benutzeroberfläche musste Vertrauen schaffen. Die Interaktionen könnten keine neue Belastung schaffen. Die Funktionen mussten den Benutzer während der gesamten Aufgabe unterstützen. Gleichzeitig musste das System zuverlässig sein und leicht zu warten und zu verbessern sein.

Keines dieser Dinge war für sich genommen notwendigerweise außerhalb unserer Grenzen. Die Schwierigkeit bestand darin, alle innerhalb eines begrenzten Zeitraums gleichzeitig gut genug zu machen.

Benutzer konnten Probleme schnell erkennen, wir konnten sie jedoch nicht beide schnell und gut lösen. Manchmal haben wir eine Funktion auf Kosten des Gesamterlebnisses fertiggestellt. Manchmal haben wir einen Teil des Erlebnisses verbessert und gleichzeitig die Wartung des zugrunde liegenden Systems erschwert. Manchmal konnte die Kernkompetenz bereits demonstriert werden, aber der Benutzer konnte die gesamte Reise immer noch nicht reibungslos abschließen.

Der Betatest war nicht bedeutungslos. Dadurch konnten wir zumindest bestätigen, dass ein Bedarf bestand.

Aber das Vorhandensein eines Bedarfs bedeutet nicht, dass ein Produkt funktioniert. Ein funktionierendes Produkt bedeutet nicht, dass ein Markt funktioniert.

Da die Qualität der Implementierung zwischen den Benutzern und dem Kernwert stand, hatten wir nicht wirklich getestet, ob Sayso diesen Wert dauerhaft liefern kann, geschweige denn, ob genügend Menschen ihn im Laufe der Zeit nutzen möchten.

Wir haben vielleicht das Problem gesehen, das der Dolch durchdringen sollte, aber es fehlte uns immer noch die Fähigkeit, diese Erkenntnis in einen Dolch umzuwandeln, den jemand tatsächlich benutzen könnte.

Das Auge konnte sehen, aber die Hand konnte noch nicht erschaffen

Nach der Veröffentlichung von Sayso führten wir das Problem zunächst auf eine unzureichende Iterationsgeschwindigkeit zurück. Da uns Benutzer Feedback gegeben hatten, schien die Antwort darin zu liegen, in kleinen Schritten weiterzumachen und das Produkt schneller zu ändern.

Aber wir stellten bald fest, dass Geschwindigkeit nicht das einzige Problem war.

Bevor wir das Produkt auf den Markt brachten, wussten wir bereits, dass es nicht gut war. Viele der Probleme im Nutzer-Feedback waren nicht über unser eigenes Ermessen hinausgegangen. Was uns fehlte, war nicht das Auge, um ein gutes von einem schlechten Produkt zu unterscheiden, sondern die Hand, die dieses Urteil schnell in ein Produkt umsetzen konnte.

Das Auge konnte bereits sehen. Die Hand konnte noch nicht herstellen.

Das bedeutete nicht, dass alles, was wir über Produkte im Jahr 2024 gelernt hatten, falsch war.

Im gesamten Jahr 2025 blieb MagicGourd online und wurde gewartet. Neue Funktionen kamen langsamer an, aber der bestehende Dienst lief weiter. Bis Ende des Jahres hatte MagicGourd rund 3.000 Nutzer und die Rückmeldungen waren insgesamt weiterhin positiv. Uns war im Laufe des Jahres kein Verlust oder eine Beschädigung von Benutzerdaten bekannt.

Im Jahr 2024 hatten wir gelernt, wie man eine Demo in Software umwandelt, die im Laufe der Zeit funktionieren kann: wie man mit Synchronisierung, Datenschutz, Kompatibilität und Fehlern umgeht; wie man einen Dienst aufrechterhält, auf den echte Benutzer angewiesen sind; und wie man Verantwortung für die Daten übernimmt, die eine Person über viele Jahre hinweg ansammelt.

Diese Fähigkeiten waren immer noch wichtig. Sie machten MagicGourd zu mehr als nur einer Demonstration und ermöglichten es uns, gegenüber bestehenden Benutzern weiterhin Verantwortung zu übernehmen, auch wenn die Geschwindigkeit neuer Funktionen nachließ.

Aber das Jahr 2025 hat eine weitere Ebene der Leistungsfähigkeit offenbart.

Wir waren immer noch nicht gut darin, einen Bedarf in eine klare Produktdefinition umzuwandeln. Wir waren nicht gut darin, in kurzer Zeit eine ausgefeilte und natürliche Benutzeroberfläche und einen Interaktionsfluss zu schaffen. Auch konnten wir Erfahrung, Funktionalität, Zuverlässigkeit und Wartbarkeit nicht zuverlässig auf einmal in Einklang bringen.

Wir verfügten über algorithmisches Fachwissen und systemtechnische Fähigkeiten. Wenn eine Idee auftauchte, konnten wir ihren technischen Kern schnell umsetzen. Aber funktionierende Technologie bedeutete nicht, dass es sich um ein funktionierendes Produkt handelte. Echte Produktstärke bedeutete, viele Urteile, die sich gegenseitig einschränken, zu etwas zu komprimieren, das der Benutzer als einfach, klar und vollständig empfand.

Zu Beginn der zweiten Jahreshälfte mussten wir schließlich zugeben, dass unsere Produktfähigkeiten unsere Ambitionen noch nicht unterstützen konnten.

Zuerst lernen, wie man die Klinge schärft

Wir haben die zweite Jahreshälfte als einen Zeitraum für den Aufbau von Kapazitäten definiert.

Die Entscheidung fiel uns schwer. Gegen Ende des ersten Halbjahres hatten wir gerade große Anstrengungen unternommen, um zu verstehen, warum wir unsere Kunden frühzeitig treffen sollten. In der zweiten Hälfte haben wir jedoch beschlossen, nicht mehr jedes unfertige Produkt vor den Nutzern zu platzieren und erst einmal zu lernen, wie man Produkte gut baut.

Oberflächlich betrachtet sah es so aus, als würde man sich innerhalb des Unternehmens vom Markt zurückziehen. Aber das Problem, das wir lösen wollten, konnte nicht nur der Markt beantworten.

Nutzer konnten uns mitteilen, ob ein Bedarf real war, ob das Produkt einen Mehrwert schaffte und ob sie es weiterhin nutzen wollten. Aber selbst wenn wir die Benutzeroberfläche als unvollendet betrachten würden, bereits wüssten, dass ein Interaktionsfluss unvollständig sei, oder wüssten, dass Zuverlässigkeitsprobleme den Kernwert verschleiern würden, würde die Weitergabe des Produkts an Benutzer keine nützlicheren Informationen über die zentrale Frage liefern.

Der Markt sollte uns helfen, unbekannte Fragen zu beantworten und nicht Antworten zu wiederholen, die wir bereits kannten.

Also begannen wir, uns immer wieder mit Produkten zu befassen, die wir wirklich bewunderten. Wir haben ihre Struktur, ihr visuelles Design und ihre Interaktionen aufgeschlüsselt und gefragt, warum jedes Detail auf eine bestimmte Art und Weise gehandhabt wurde. Durch genaue Studien und Neuimplementierungen verwandelten wir Urteile, die wir sehen konnten, in Dinge, die wir selbst gemacht hatten. Anschließend haben wir die Unterschiede verglichen und es erneut versucht, bis wir verstanden haben, warum sich diese hervorragenden Produkte einfach, natürlich und vollständig anfühlen.

Beim genauen Studium ging es nicht darum, die Oberfläche eines Produkts zu kopieren oder nach einer Antwort zu suchen, die wir unverändert mitnehmen konnten. Es ähnelte eher der Übung, durch die jemand Malerei, Musik oder Kalligraphie lernt: Zuerst das Auge trainieren, um den Unterschied zu erkennen, dann die Hand nach und nach aufholen lassen und erst dann diese Fähigkeit auf ein eigenes Problem anwenden.

Die Produktfähigkeit beinhaltet eine Menge stillschweigendes Wissen wie dieses. Eine Idee zu verstehen oder auch nur das Produkt eines anderen genau zu bewerten, bedeutet nicht, dass wir selbst über die entsprechenden Fähigkeiten verfügen. Nur durch die Umwandlung von Urteilen in Schnittstellen, Interaktionen und Systeme durch wiederholte konkrete Entscheidungen könnte diese Fähigkeit wirklich Teil des Teams werden.

Bis zum Jahresende konnten wir immer noch nicht beweisen, dass wir in der Lage waren, dauerhaft hervorragende Produkte zu entwickeln. Aber Mitte des Jahres hatten wir nur das vage Gefühl, dass „dieses Produkt nicht gut ist“. Am Ende könnten wir dieses Urteil in spezifischere Fragen aufteilen: Wie Informationen organisiert werden sollten, wie eine Interaktion ablaufen sollte, wie visuelle Details das Ganze unterstützen sollten und wie sich Systembeschränkungen auf das Erlebnis auswirken würden. Wir könnten diese Fähigkeiten dann nacheinander durch Zerlegung, genaues Studium, Neuimplementierung und Neuaufbau trainieren.

Diese Änderungen waren weiterhin nur Ergebnisse der internen Praxis und konnten den Test durch echte Benutzer nicht ersetzen. Was wir sagen konnten, war, dass wir begonnen hatten, einen konkreteren Weg zum Üben zu finden und dass der Abstand zwischen unseren Augen und unseren Händen begonnen hatte, kleiner zu werden.

Beim Fundraising geht es nicht nur um Geld

Rückblickend bestätigte sich langsam, was Kehan zu Beginn des Jahres geäußert hatte.

Es war wichtig, Investitionen zu erhalten, aber MiraclePlus gab uns nicht nur Geld. Die Anleitung durch Mentoren und Gespräche mit Kollegen würden nicht unbedingt sofort zu Nutzern, Einnahmen oder einem erfolgreichen Produkt führen. Bis zum Jahresende konnte ich nicht sagen, dass diese Beziehungen zu direkten Ergebnissen geführt hatten. Aber Peters Dolch-Metapher hatte bereits Einzug in die Art und Weise gehalten, wie wir jeden Tag Produkte bewerteten.

Es zwang uns immer wieder dazu, unsere Produkte noch einmal zu überprüfen. Immer wenn ich glaubte, es verstanden zu haben, zeigte mir die spätere Übung, dass ich nur einen Teil verstanden hatte.

Zuerst dachte ich, es bedeute, das riesige zweite Gehirn in etwas Kleineres zu zerlegen. Später dachte ich, klein, schnell und cool bedeutet scharf. Später wurde mir noch klar, dass ein echter Dolch allein deshalb nicht funktionierte, weil er klein war. Es musste ein vollständiges Produkterlebnis auf ein bestimmtes Problem konzentriert werden.

Der Beschleuniger war für uns nicht der Hammer, aber er half uns früher zu erkennen, warum das Ding in unseren Händen noch kein Dolch war.

Das bedeutet, dass es beim Fundraising nicht nur um Geld geht. Es liefert vielleicht keine unmittelbare Antwort, aber es kann die Art und Weise verändern, wie wir Fragen stellen, uns selbst bewerten und weiter lernen.

Wahre Schärfe erfordert auch Vollständigkeit

Ende 2025 hatte ich ein anderes Verständnis von einem Dolch als zu Beginn des Jahres.

Einblick in das Problem des Benutzers war die Klingenspitze. Interaktion, Schnittstelle und Produkterlebnis bildeten den Vorsprung. Funktionelle Vollständigkeit war der Körper der Klinge. Zuverlässigkeit und Wartbarkeit waren wie der Griff und ermöglichten es jemandem, ihn wirklich zu halten und zu verwenden.

Eine einzelne scharfe Spitze könnte höchstens zu einer beeindruckenden Demonstration werden. Es war noch kein Dolch, den jemand tatsächlich benutzen konnte.

Vollständigkeit bedeutete nicht, alles in das Produkt zu stecken. Ein Schweizer Taschenmesser kann viele Probleme lösen, geht aber möglicherweise nicht tief genug auf eines davon ein.

Wahre Vollständigkeit bedeutete, die gesamte Reise, die der Benutzer benötigte, rund um einen Kernwert abzuschließen. Jeder Teil des Produkts musste auf dasselbe Problem hinweisen und die anderen Teile unterstützen, anstatt mehr Funktionen zu verwenden, um die Tatsache zu verbergen, dass das Kernproblem ungelöst blieb.

Im Jahr 2023 verließ ich SenseTime und sprang in den nächsten Fluss. Im Jahr 2024 stellten wir den Kürbis her und begannen zu verstehen, warum ein Produkt im Laufe der Zeit funktionieren musste. Im Jahr 2025 wollten wir, dass die Magie endlich erscheint, und wir versuchten auch, das riesige zweite Gehirn in einen Dolch zu zerlegen.

Der Zauber war noch nicht da und Sayso war noch kein funktionierendes Produkt. Auch wenn wir jetzt den Bedarf erkannten, fehlte uns immer noch die Fähigkeit, es schnell und gut zu bauen.

Aber im Laufe des Jahres erkannten wir zumindest genauer, was uns fehlte.

Unser Streben nach Schärfe hatte uns nicht dazu gebracht, Vollständigkeit, Zuverlässigkeit oder langfristige Verantwortung aufzugeben. Wir begannen auch zu verstehen, dass es nicht bedeutete, Kunden frühzeitig zu treffen, um ihnen ein Produkt zu geben, von dem wir bereits wussten, dass es schlecht war, und dass eine schnelle Iteration nicht bedeutete, nur auf Entwicklungsgeschwindigkeit zu achten.

Bis heute haben wir diesen Dolch noch nicht vollständig entwickelt.

Wir haben gerade erst begonnen zu lernen, wie man ihn schärft.

Eine Klingenspitze allein ist noch kein Dolch.

Before we released it, I already knew it was not good enough.

Its interface lacked polish, the interactions did not yet feel natural, and the functional flow was incomplete. We could see many of the problems without waiting for user feedback. More troublingly, these problems could not be separated from one another. The interface, user experience, functional completeness, reliability, and maintainability all had to work at the same time before they could form a complete product.

But we had just spent months absorbing a set of startup methods: meet customers early, move in small steps, and iterate quickly. So even though we were dissatisfied with the product, we still believed we should release it first.

Users quickly raised many issues. We had known about a substantial number of them before the release. Their feedback became the starting point for the change we made in the second half of the year.

Looking back, that beta test divided 2025 into two halves. During the first half, we continued building MagicGourd, hoping to make its magic finally appear. In the middle of the year, we extracted one idea into Sayso, built it quickly, and put it in front of users. In the second half, instead of continuing to chase release speed, we turned to building our product capabilities. The starting point for all of this came at the beginning of the year, when we received investment from MiraclePlus and joined its accelerator.

By the end of the year, we still had not made that dagger. But we had begun to understand: a blade tip alone is not a dagger.

An Interview I Had Not Planned to Attend

At the beginning of 2025, I had no plan to raise money.

In 2024, we had spent most of our time building MagicGourd and released 27 versions. Our limited fundraising attempts had led nowhere, and the product was still far from the “true second brain” we envisioned. But I deeply enjoyed the process of building it.

I thought we could continue at a very small scale, moving forward one step at a time without rushing to take investment.

Kehan changed my mind. He told me that fundraising was not necessarily only about money. The MiraclePlus accelerator, its mentors, and its alumni could also help us over a much longer period.

By then, the application deadline had already passed. But I did not want to let Kehan’s recommendation go to waste, so I submitted an application anyway, briefly describing how I thought about a true second brain.

This interview took place at the MiraclePlus office in Beijing. While I waited, I saw several interview suggestions on a screen: answers should be simple, direct, and truthful.

In the interview a year earlier, I had unconsciously searched for the answers investors wanted to hear. When they repeatedly challenged our ideas, I worried that my answers were not good enough. Because I respected the people across the table, I could even begin to doubt my own judgment.

This time, I was not in such a hurry.

After a full year of development in 2024, we were still in the water, but no longer struggling as we had just after jumping in. I did not try to prove that I must be right, and I had not prepared heavily polished answers. I simply said what I genuinely thought.

Dr. Lu Qi asked what I thought of SenseTime. I said that, first of all, I was deeply grateful to the company, because I had gone through a crucial period of growth and transformation there. Around the arrival of ChatGPT, SenseTime may have been slightly slow to respond because a large ship is difficult to turn. But by 2025, I could see it changing quickly, and I believed a better era for SenseTime was arriving.

He then asked what I thought of DeepSeek. My answer was one word: cost. I did not elaborate at the time. I simply believed that cost would directly affect the scale at which a technology could enter the real world.

The interview went more smoothly than I had expected. Perhaps because I was no longer desperate for a particular outcome, it became easier to speak simply.

Later, MiraclePlus invested in us, and we joined the accelerator.

We Wanted the Magic to Finally Appear

If the goal in 2024 had been to make the gourd first, then at the beginning of 2025 we wanted its magic to finally appear.

In 2024, we had stayed sharply focused and completed MagicGourd version 0.27. It helped people mark what moved them on webpages, online PDFs, and videos, record the thoughts that arose, and preserve all of it over time.

But it was still closer to a container. It could collect and manage a person’s records, but it could not truly understand them, much less help someone discover thoughts that remained unfinished.

So when we planned for 2025, we set ourselves a much larger goal. We would no longer be satisfied with adding features. We wanted to take a real step toward the true second brain we had imagined.

We wanted to understand a person’s long-term records, find connections scattered across different times and different pieces of content, understand what the user was thinking at that moment, and recognize intentions they had not yet clearly expressed.

The goal was exciting. It was also far beyond the scope we could manage at the time.

During the first half of the year, we devoted enormous effort to development. The problem was not a lack of hard work, but the number of things that had to be solved at once. Every step forward exposed more questions. The scope kept expanding, while our development pace kept slowing. Half a year passed, and we still had not put the most important value in front of users.

After entering the MiraclePlus accelerator, we kept hearing one word: sharp.

My mentor in the accelerator, Peter, repeatedly told us that a startup should make a dagger, not a Swiss Army knife.

As the first half of the year drew to a close, we began to think the problem was that the product had become too large. If we could not build a true second brain all at once, we should extract its most important element and turn that into a product that was small, fast, and cool.

At the time, we thought that was what a dagger meant.

A Second Brain Should Understand Intentions Not Yet Spoken

We repeatedly asked what mattered most in a second brain.

The answer we eventually found was understanding intention.

An ordinary information tool usually begins with what the user has already entered. If a user writes a sentence, it can revise it. If the user asks a question, it can answer. If the user saves an article, it can summarize it.

But many human intentions are not clearly expressed at the beginning. Sometimes we have only a vague sense that something matters without knowing what we truly care about. Sometimes we are about to meet someone important and have a great deal of information in mind, but do not know what is most worth saying. Sometimes we know the feeling we want to express but cannot find the right words.

If a second brain could combine the user’s current context with these unspoken intentions, it would do more than process existing information. It would begin to participate in the process through which a person forms an expression or judgment.

Based on this idea, we conceived a product called Sayso in the middle of the year.

Using the person’s current context, it would help them see what they might say next. We did not want AI to decide a user’s true intention for them. We wanted it to offer possible directions from which the user could recognize what they actually wanted to express.

This need appears in many real situations. Before meeting an important person or beginning an important conversation, people are often not short of things to say. The problem is knowing which part of a large amount of information matters most at that moment.

Sayso tried to compress the large goal of understanding a person’s implicit intentions into one concrete task: use the person’s present context to uncover intentions they had not yet expressed.

We thought we had finally found a dagger inside the vast idea of a second brain.

We Mistook “Small” for “Sharp”

In the middle of the year, we moved from a large product to a small one, and our development speed increased noticeably.

But during this shift, our understanding of a dagger was still limited to its outward form.

We thought making the product smaller made it a dagger. We thought fewer features made it a dagger. Later, we also mistook novelty and development speed for sharpness: if a product felt new, could be built quickly, and could reach users quickly, it seemed closer to the right answer than the Swiss Army knife we had been building.

In the middle of the year, we built Sayso in a very short time and gave it to beta users.

Their feedback showed us that some people really did need help expressing themselves before an important meeting or conversation, and that they could understand the value of discovering intentions from context. This offered early evidence that the problem we were targeting was real, rather than merely an idea that sounded novel.

But the product itself did not work.

An AI demo about understanding intention might only need to produce a surprising result in a few carefully prepared examples. A real product had to show users what context to provide, help them understand why it offered particular suggestions, and let them naturally edit, choose, or reject those suggestions.

The interface had to inspire trust. The interactions could not create a new burden. The features had to support the user through the entire task. At the same time, the system had to be reliable and remain easy to maintain and improve.

None of these things, taken individually, was necessarily beyond us. The difficulty was making all of them good enough at the same time within a limited period.

Users could identify problems quickly, but we could not resolve them both quickly and well. Sometimes we completed a feature at the expense of the overall experience. Sometimes we improved one part of the experience while making the underlying system harder to maintain. Sometimes the core capability could already be demonstrated, but the user still could not complete a full journey smoothly.

The beta test was not meaningless. It at least allowed us to confirm that the need existed.

But the existence of a need does not mean that a product works. A working product does not mean that a market works.

Because the quality of the implementation stood between users and the core value, we had not truly tested whether Sayso could deliver that value consistently, much less whether enough people would want to use it over time.

We may have seen the problem the dagger should pierce, but we still lacked the ability to turn that insight into a dagger someone could actually use.

The Eye Could See, but the Hand Could Not Yet Make

After releasing Sayso, we initially attributed the problem to insufficient iteration speed. Users had given us feedback, so the answer seemed to be continuing to move in small steps and changing the product faster.

But we soon discovered that speed was not the only problem.

Before releasing the product, we had already known it was not good. Many of the problems in the user feedback had not exceeded our own judgment. What we lacked was not the eye to distinguish a good product from a bad one, but the hand that could quickly turn that judgment into a product.

The eye could already see. The hand could not yet make.

This did not mean that everything we had learned about products in 2024 was wrong.

Throughout 2025, MagicGourd remained online and maintained. New features arrived more slowly, but the existing service continued to run. By the end of the year, MagicGourd had around 3,000 users, and the feedback remained positive overall. We were not aware of any user data being lost or corrupted during the year.

In 2024, we had learned how to turn a demo into software that could operate over time: how to handle synchronization, privacy, compatibility, and failures; how to maintain a service that real users depended on; and how to take responsibility for data a person might accumulate over many years.

Those capabilities still mattered. They made MagicGourd more than a demonstration, and they allowed us to remain responsible to existing users even as the pace of new features slowed.

But 2025 exposed another layer of capability.

We were still not good at turning a need into a clear product definition. We were not good at creating a polished and natural interface and interaction flow in a short time. Nor could we reliably balance experience, functionality, reliability, and maintainability at once.

We had algorithmic expertise and systems engineering ability. When an idea appeared, we could quickly implement its technical core. But working technology did not mean a working product. Real product strength meant compressing many judgments that constrained one another into something the user experienced as simple, clear, and complete.

As we entered the second half of the year, we finally admitted that our product capabilities could not yet support our ambition.

First Learn How to Sharpen the Blade

We defined the second half of the year as a period for building capabilities.

The decision was difficult. Late in the first half, we had just invested a great deal of effort in understanding why we should meet customers early. In the second half, however, we decided to stop rushing every unfinished product in front of users and first learn how to build products well.

On the surface, this looked like retreating from the market back inside the company. But the problem we wanted to solve was not one that only the market could answer.

Users could tell us whether a need was real, whether the product created value, and whether they wanted to keep using it. But if even we considered the interface unpolished, already knew that an interaction flow was incomplete, or knew that reliability problems would obscure the core value, giving the product to users would not produce more useful information about the central question.

The market should help us answer unknown questions, not repeat answers we already knew.

So we began repeatedly studying products we genuinely admired. We broke down their structure, visual design, and interactions, asking why every detail had been handled in a particular way. Through close studies and reimplementations, we turned judgments we could see into things we had made ourselves. We then compared the differences and tried again, until we understood why these excellent products felt simple, natural, and complete.

Close study was not about copying a product’s surface or searching for an answer we could carry away unchanged. It was more like the practice through which someone learns painting, music, or calligraphy: first train the eye to tell the difference, then let the hand gradually catch up, and only then apply that ability to a problem of one’s own.

Product capability contains a great deal of tacit knowledge like this. Understanding an idea, or even accurately evaluating someone else’s product, does not mean we possess the capability ourselves. Only by turning judgments into interfaces, interactions, and systems through repeated concrete choices could that capability truly become part of the team.

By the end of the year, we still could not prove that we were able to build excellent products consistently. But in the middle of the year, all we could do was vaguely feel that “this product is not good.” By the end, we could break that judgment into more specific questions: how information should be organized, how an interaction should progress, how visual details should support the whole, and how system constraints would affect the experience. We could then train these abilities one by one through decomposition, close study, reimplementation, and rebuilding.

These changes were still only the results of internal practice and could not replace the test of real users. What we could say was that we had begun to form a more concrete way to practice, and that the distance between our eyes and our hands had begun to narrow.

Fundraising Is Not Only About Money

Looking back, the point Kehan had made at the beginning of the year was being confirmed, slowly.

Receiving investment was important, but money was not all that MiraclePlus gave us. Guidance from mentors and conversations with peers would not necessarily turn immediately into users, revenue, or a successful product. By the end of the year, I could not say that these relationships had produced direct results. But Peter’s dagger metaphor had already entered the way we evaluated products every day.

It kept forcing us to reexamine our products. Whenever I thought I understood it, later practice showed me that I had understood only one part.

At first, I thought it meant breaking the vast second brain into something smaller. Later, I thought small, fast, and cool meant sharp. Later still, I realized that a real dagger did not work merely because it was small. It had to concentrate a complete product experience on one specific problem.

The accelerator did not make the dagger for us, but it helped us see sooner why the thing in our hands was not yet one.

That is what it means to say that fundraising is not only about money. It may not provide an immediate answer, but it can change how we ask questions, evaluate ourselves, and continue learning.

True Sharpness Also Requires Completeness

By the end of 2025, my understanding of a dagger was different from what it had been at the beginning of the year.

Insight into the user’s problem was the blade tip. Interaction, interface, and product experience formed the edge. Functional completeness was the body of the blade. Reliability and maintainability were like the handle, allowing someone to truly hold and use it.

A single sharp point could at most become an impressive demo. It was not yet a dagger someone could actually use.

Completeness did not mean putting everything into the product. A Swiss Army knife can solve many problems, but it may not go deeply enough into any one of them.

True completeness meant completing the entire journey the user needed around one core value. Every part of the product had to point toward the same problem and support the other parts, rather than using more features to hide the fact that the core problem remained unsolved.

In 2023, I left SenseTime and jumped into the next river. In 2024, we made the gourd and began to understand why a product had to work over time. In 2025, we wanted the magic to finally appear, and we also tried to break the vast second brain down into a dagger.

The magic had not yet appeared, and Sayso had not yet become a working product. Even though we could now see the need, we still lacked the ability to build it both quickly and well.

But over the course of the year, we at least came to see more accurately what we lacked.

Our pursuit of sharpness had not made us abandon completeness, reliability, or long-term responsibility. We were also beginning to understand that meeting customers early did not mean giving them a product we already knew was poor, and that rapid iteration did not mean pursuing development speed alone.

As of today, we have not yet made that fully formed dagger.

We have only begun learning how to sharpen it.

A blade tip alone is not a dagger.

Antes de lanzarlo, ya sabía que no era lo suficientemente bueno.

Su interfaz carecía de pulido, las interacciones aún no parecían naturales y el flujo funcional estaba incompleto. Podríamos ver muchos de los problemas sin esperar los comentarios de los usuarios. Lo más preocupante es que estos problemas no se pueden separar unos de otros. La interfaz, la experiencia del usuario, la integridad funcional, la confiabilidad y la capacidad de mantenimiento tenían que funcionar al mismo tiempo antes de que pudieran formar un producto completo.

Pero acabábamos de pasar meses absorbiendo un conjunto de métodos de inicio: conocer a los clientes temprano, avanzar en pequeños pasos e iterar rápidamente. Entonces, aunque no estábamos satisfechos con el producto, todavía creíamos que debíamos lanzarlo primero.

Los usuarios señalaron rápidamente muchos problemas. Ya conocíamos una parte considerable de ellos antes del lanzamiento. Sus comentarios se convirtieron en el punto de partida del cambio que hicimos en la segunda mitad del año.

Mirando hacia atrás, esa prueba beta dividió 2025 en dos mitades. Durante la primera mitad, continuamos construyendo MagicGourd, con la esperanza de que finalmente apareciera su magia. A mediados de año, extrajimos una idea en Sayso, la creamos rápidamente y la presentamos a los usuarios. En la segunda mitad, en lugar de seguir persiguiendo la velocidad de lanzamiento, nos dedicamos a desarrollar las capacidades de nuestro producto. El punto de partida de todo esto llegó a principios de año, cuando recibimos inversión de MiraclePlus y nos sumamos a su aceleradora.

A finales de año todavía no habíamos hecho esa daga. Pero habíamos empezado a comprender que una punta por sí sola no es una daga.

Una entrevista a la que no había planeado asistir

A principios de 2025, no tenía ningún plan para recaudar dinero.

En 2024, habíamos pasado la mayor parte de nuestro tiempo construyendo MagicGourd y lanzamos 27 versiones. Nuestros limitados intentos de recaudación de fondos no habían conducido a ninguna parte y el producto aún estaba lejos del “verdadero segundo cerebro” que imaginamos. Pero disfruté profundamente el proceso de construcción.

Pensé que podíamos continuar a una escala muy pequeña, avanzando paso a paso sin apresurarnos a buscar inversión.

Kehan me hizo cambiar de opinión. Me dijo que recaudar fondos no tenía por qué tratarse únicamente de dinero. La aceleradora de MiraclePlus, sus mentores y sus exalumnos también podrían ayudarnos durante mucho más tiempo.

Para entonces, la fecha límite de solicitud ya había pasado. Pero no quería desperdiciar la recomendación de Kehan, así que envié una solicitud de todos modos, describiendo brevemente cómo pensaba acerca de un verdadero segundo cerebro.

Esta entrevista tuvo lugar en la oficina de MiraclePlus en Beijing. Mientras esperaba, vi varias sugerencias de entrevistas en una pantalla: las respuestas deben ser simples, directas y veraces.

En la entrevista del año anterior, inconscientemente había buscado las respuestas que los inversores querían escuchar. Cuando cuestionaron repetidamente nuestras ideas, me preocupé de que mis respuestas no fueran lo suficientemente buenas. Debido a que respetaba a las personas que estaban al otro lado de la mesa, incluso podía comenzar a dudar de mi propio juicio.

Esta vez, no tenía tanta prisa.

Después de un año completo de desarrollo en 2024, todavía estábamos en el agua, pero ya no teníamos dificultades como lo hicimos justo después de saltar. No intenté demostrar que debía tener razón y no había preparado respuestas muy pulidas. Simplemente dije lo que realmente pensaba.

El Dr. Lu Qi me preguntó qué pensaba de SenseTime. Dije que, en primer lugar, estaba profundamente agradecido con la empresa, porque allí había pasado por un período crucial de crecimiento y transformación. Alrededor de la llegada de ChatGPT, es posible que SenseTime haya tardado un poco en responder porque es difícil girar un barco grande. Pero para 2025, pude ver que esto cambiaría rápidamente y creí que estaba llegando una era mejor para SenseTime.

Luego me preguntó qué pensaba de DeepSeek. Mi respuesta fue una palabra: costo. No di más detalles en ese momento. Simplemente creía que el costo afectaría directamente la escala a la que una tecnología podría ingresar al mundo real.

La entrevista transcurrió mejor de lo que esperaba. Quizás porque ya no estaba desesperado por un resultado en particular, se volvió más fácil hablar con sencillez.

Más tarde, MiraclePlus invirtió en nosotros y nos unimos al acelerador.

Queríamos que la magia finalmente apareciera

Si el objetivo de 2024 había sido hacer primero la calabaza, a principios de 2025 queríamos que su magia apareciera por fin.

En 2024 mantuvimos un enfoque muy definido y completamos la versión 0.27 de MagicGourd. El producto ayudaba a las personas a marcar aquello que las conmovía en páginas web, PDF en línea y vídeos, registrar los pensamientos que surgían y conservarlo todo a lo largo del tiempo.

Pero aún estaba más cerca de un contenedor. Podía recopilar y gestionar los registros de una persona, pero no podía comprenderlos realmente, y mucho menos ayudar a alguien a descubrir pensamientos que permanecían sin terminar.

Entonces, cuando planificamos para 2025, nos fijamos una meta mucho más grande. Ya no estaríamos satisfechos con agregar funciones. Queríamos dar un paso real hacia el verdadero segundo cerebro que habíamos imaginado.

Queríamos comprender los registros a largo plazo de una persona, encontrar conexiones dispersas en diferentes momentos y diferentes contenidos, comprender lo que el usuario estaba pensando en ese momento y reconocer intenciones que aún no habían expresado claramente.

El objetivo era emocionante. También estaba mucho más allá del alcance que podíamos gestionar en ese momento.

Durante la primera mitad del año, dedicamos un enorme esfuerzo al desarrollo. El problema no era la falta de trabajo duro, sino la cantidad de cosas que había que resolver a la vez. Cada paso adelante exponía más preguntas. El alcance siguió ampliándose, mientras que nuestro ritmo de desarrollo siguió desacelerando. Pasó medio año y todavía no habíamos presentado el valor más importante a los usuarios.

Después de ingresar al acelerador MiraclePlus, seguíamos escuchando una palabra: sharp.

Mi mentor en la aceleradora, Peter, nos dijo repetidamente que una startup debía fabricar una daga, no una navaja suiza.

A medida que la primera mitad del año llegaba a su fin, comenzamos a pensar que el problema era que el producto se había vuelto demasiado grande. Si no podíamos construir un verdadero segundo cerebro de una sola vez, deberíamos extraer su elemento más importante y convertirlo en un producto que fuera pequeño, rápido y genial.

En ese momento, pensábamos que eso era lo que significaba una daga.

Un segundo cerebro debería comprender las intenciones aún no expresadas

Preguntamos repetidamente qué era lo más importante en un segundo cerebro.

La respuesta que finalmente encontramos fue comprender la intención.

Una herramienta de información ordinaria generalmente comienza con lo que el usuario ya ha ingresado. Si un usuario escribe una oración, puede revisarla. Si el usuario hace una pregunta, puede responder. Si el usuario guarda un artículo, puede resumirlo.

Pero muchas intenciones humanas no se expresan claramente al principio. A veces sólo tenemos una vaga sensación de que algo importa sin saber qué es lo que realmente nos importa. A veces estamos a punto de conocer a alguien importante y tenemos una gran cantidad de información en mente, pero no sabemos qué es más digno de decir. A veces sabemos el sentimiento que queremos expresar pero no podemos encontrar las palabras adecuadas.

Si un segundo cerebro pudiera combinar el contexto actual del usuario con estas intenciones tácitas, haría más que procesar la información existente. Comenzaría a participar en el proceso a través del cual una persona forma una expresión o juicio.

Basándonos en esta idea, concebimos un producto llamado Sayso a mediados de año.

Utilizando el contexto actual de la persona, le ayudaría a ver qué podría decir a continuación. No queríamos que la IA decidiera por el usuario cuál era su verdadera intención. Queríamos que ofreciera posibles direcciones entre las que el usuario pudiera reconocer lo que realmente quería expresar.

Esta necesidad aparece en muchas situaciones reales. Antes de conocer a una persona importante o comenzar una conversación importante, a la gente a menudo no le faltan cosas que decir. El problema es saber qué parte de una gran cantidad de información es más importante en ese momento.

Sayso intentó comprimir el gran objetivo de comprender las intenciones implícitas de una persona en una tarea concreta: utilizar el contexto actual de la persona para descubrir intenciones que aún no había expresado.

Pensamos que finalmente habíamos encontrado una daga dentro de la vasta idea de un segundo cerebro.

Confundimos “pequeño” con “afilado”

A mediados de año, pasamos de un producto grande a uno pequeño, y nuestra velocidad de desarrollo aumentó notablemente.

Pero durante este cambio, nuestra comprensión de una daga todavía se limitaba a su forma exterior.

Pensábamos que hacer el producto más pequeño lo convertía en una daga. Pensábamos que tener menos funciones lo convertía en una daga. Más tarde también confundimos la novedad y la velocidad de desarrollo con el filo: si un producto parecía nuevo, podía construirse rápidamente y llegar pronto a los usuarios, parecía estar más cerca de la respuesta correcta que la navaja suiza que habíamos estado construyendo.

A mediados de año, creamos Sayso en muy poco tiempo y se lo dimos a los usuarios beta.

Sus comentarios nos mostraron que algunas personas realmente necesitaban ayuda para expresarse antes de una reunión o conversación importante y que podían comprender el valor de descubrir intenciones a partir del contexto. Esto ofreció una primera evidencia de que el problema que abordábamos era real y no sólo una idea que sonaba novedosa.

Pero el producto en sí no funcionó.

Un demo de IA sobre la comprensión de la intención sólo tendría que producir un resultado sorprendente en unos pocos ejemplos cuidadosamente preparados. Un producto real debía mostrar a los usuarios qué contexto aportar, ayudarles a comprender por qué ofrecía determinadas sugerencias y permitirles editarlas, elegirlas o rechazarlas de forma natural.

La interfaz tenía que inspirar confianza. Las interacciones no podían crear una nueva carga. Las funciones debían ayudar al usuario durante toda la tarea. Al mismo tiempo, el sistema tenía que ser fiable y fácil de mantener y mejorar.

Ninguna de estas cosas, tomadas individualmente, estaba necesariamente fuera de nuestro alcance. La dificultad era lograr que todos fueran lo suficientemente buenos al mismo tiempo en un período limitado.

Los usuarios podían identificar problemas rápidamente, pero nosotros no podíamos resolverlos a la vez con rapidez y calidad. A veces completábamos una función a costa de la experiencia general. A veces mejorábamos una parte de la experiencia mientras hacíamos que el sistema subyacente fuera más difícil de mantener. A veces la capacidad principal ya podía demostrarse, pero el usuario aún no podía completar todo el recorrido sin dificultades.

La prueba beta no carecía de sentido. Al menos nos permitió confirmar que existía la necesidad.

Pero la existencia de una necesidad no significa que un producto funcione. Un producto que funciona no significa que un mercado funcione.

Debido a que la calidad de la implementación se interpuso entre los usuarios y el valor central, no habíamos probado realmente si Sayso podía ofrecer ese valor de manera consistente, y mucho menos si suficientes personas querrían usarlo con el tiempo.

Es posible que hayamos visto el problema que la daga debería perforar, pero todavía nos faltaba la capacidad de convertir esa información en una daga que alguien pudiera realmente use.

El ojo podía ver, pero la mano aún no podía hacer

Después de lanzar Sayso, inicialmente atribuimos el problema a una velocidad de iteración insuficiente. Los usuarios nos habían dado su opinión, por lo que la respuesta parecía ser seguir avanzando en pequeños pasos y cambiar el producto más rápido.

Pero pronto descubrimos que la velocidad no era el único problema.

Antes de lanzar el producto, ya sabíamos que no era bueno. Muchos de los problemas en los comentarios de los usuarios no excedieron nuestro propio juicio. Lo que nos faltaba no era el ojo para distinguir un producto bueno de uno malo, sino la mano que pudiera convertir rápidamente ese juicio en un producto.

El ojo ya podía ver. La mano aún no podía hacerlo.

Esto no significaba que todo lo que habíamos aprendido sobre los productos en 2024 fuera incorrecto.

Durante 2025, MagicGourd permaneció en línea y mantenido. Las nuevas funciones llegaron más lentamente, pero el servicio existente continuó funcionando. A finales de año, MagicGourd tenía alrededor de 3.000 usuarios y, en general, la respuesta siguió siendo positiva. No tuvimos conocimiento de que se perdiera o corrompiera ningún dato de usuario durante el año.

En 2024 aprendimos a convertir un demo en software capaz de funcionar a lo largo del tiempo: cómo gestionar la sincronización, la privacidad, la compatibilidad y los fallos; cómo mantener un servicio del que dependían usuarios reales; y cómo asumir la responsabilidad por los datos que una persona podría acumular durante muchos años.

Esas capacidades seguían siendo importantes. Hicieron que MagicGourd fuera más que una demostración y nos permitieron seguir respondiendo ante los usuarios existentes incluso cuando se ralentizó el ritmo de las nuevas funciones.

Pero 2025 expuso otra capa de capacidad.

Todavía no éramos buenos para convertir una necesidad en una definición clara de producto. No éramos buenos creando una interfaz pulida y natural y un flujo de interacción en poco tiempo. Tampoco podíamos equilibrar de manera confiable la experiencia, la funcionalidad, la confiabilidad y la capacidad de mantenimiento al mismo tiempo.

Teníamos experiencia en algorítmica y capacidad de ingeniería de sistemas. Cuando aparecía una idea, podíamos implementar rápidamente su núcleo técnico. Pero una tecnología funcional no significaba un producto funcional. La verdadera fortaleza del producto significó comprimir muchos juicios que se limitaban entre sí en algo que el usuario experimentaba como simple, claro y completo.

Cuando entramos en la segunda mitad del año, finalmente admitimos que las capacidades de nuestro producto aún no podían respaldar nuestra ambición.

Primero, aprenda a afilar la cuchilla

Definimos la segunda mitad del año como un período para desarrollar capacidades.

La decisión fue difícil. A finales del primer semestre, acabábamos de invertir un gran esfuerzo en comprender por qué debíamos reunirnos con los clientes lo antes posible. En la segunda mitad, sin embargo, decidimos dejar de presentar cada producto sin terminar a los usuarios y primero aprender cómo construir bien los productos.

En la superficie, esto parecía una retirada del mercado hacia el interior de la empresa. Pero el problema que queríamos resolver no era uno que sólo el mercado pudiera responder.

Los usuarios podían decirnos si una necesidad era real, si el producto generaba valor y si querían seguir utilizándolo. Pero si incluso nosotros considerábamos que la interfaz carecía de pulido, ya sabíamos que un flujo de interacción estaba incompleto o que los problemas de fiabilidad ocultarían el valor central, entregar el producto a los usuarios no aportaría información más útil sobre la cuestión principal.

El mercado debería ayudarnos a responder preguntas desconocidas, no repetir respuestas que ya sabíamos.

Entonces comenzamos a estudiar repetidamente productos que realmente admirábamos. Desglosamos su estructura, diseño visual e interacciones, preguntando por qué cada detalle se había manejado de una manera particular. A través de estudios minuciosos y reimplementaciones, convertimos los juicios que podíamos ver en cosas que habíamos creado nosotros mismos. Luego comparamos las diferencias y lo intentamos de nuevo, hasta que entendimos por qué estos excelentes productos parecían simples, naturales y completos.

Un estudio minucioso no se trataba de copiar la superficie de un producto o buscar una respuesta que pudiéramos conservar sin cambios. Se parecía más a la práctica mediante la cual alguien aprende pintura, música o caligrafía: primero entrena el ojo para notar la diferencia, luego deja que la mano lo alcance gradualmente y sólo entonces aplica esa habilidad a un problema propio.

La capacidad del producto contiene una gran cantidad de conocimiento tácito como este. Comprender una idea, o incluso evaluar con precisión el producto de otra persona, no significa que nosotros mismos poseamos la capacidad. Sólo convirtiendo los juicios en interfaces, interacciones y sistemas a través de elecciones concretas repetidas podría esa capacidad convertirse realmente en parte del equipo.

Al final del año, todavía no podíamos demostrar que éramos capaces de crear productos excelentes de manera consistente. Pero a mediados de año, lo único que pudimos hacer fue sentir vagamente que “este producto no es bueno”. Al final, podríamos dividir ese juicio en preguntas más específicas: cómo debería organizarse la información, cómo debería progresar una interacción, cómo los detalles visuales deberían respaldar el conjunto y cómo las limitaciones del sistema afectarían la experiencia. Luego podríamos entrenar estas habilidades una por una mediante descomposición, estudio detallado, reimplementación y reconstrucción.

Estos cambios todavía eran solo el resultado de la práctica interna y no podían reemplazar las pruebas de usuarios reales. Lo que podíamos decir era que habíamos empezado a formar una forma más concreta de practicar y que la distancia entre nuestros ojos y nuestras manos había comenzado a reducirse.

La recaudación de fondos no se trata sólo de dinero

Mirando hacia atrás, lo que Kehan había planteado a principios de año se estaba confirmando, poco a poco.

Recibir inversión fue importante, pero dinero no fue todo lo que nos dio MiraclePlus. La orientación de los mentores y las conversaciones con pares no necesariamente se traducirían inmediatamente en usuarios, ingresos o un producto exitoso. Al final del año, no podía decir que estas relaciones hubieran producido resultados directos. Pero la metáfora de la daga de Peter ya había entrado en la forma en que evaluamos los productos todos los días.

Seguía obligándonos a examinar de nuevo nuestros productos. Cada vez que pensaba que lo entendía, la práctica posterior me demostraba que sólo había comprendido una parte.

Al principio pensé que significaba dividir el vasto segundo cerebro en algo más pequeño. Más tarde pensé que pequeño, rápido y atractivo significaba afilado. Más tarde aún comprendí que una daga real no funciona sólo por ser pequeña: tiene que concentrar una experiencia de producto completa en un problema específico.

El acelerador no fue la daga para nosotros, pero nos ayudó a ver antes por qué lo que teníamos en las manos aún no lo era.

Eso es lo que significa decir que la recaudación de fondos no se trata solo de dinero. Puede que no proporcione una respuesta inmediata, pero puede cambiar la forma en que hacemos preguntas, nos evaluamos y continuamos aprendiendo.

El verdadero filo también exige integridad

A finales de 2025, mi comprensión de una daga era diferente de lo que había sido a principios de año.

La idea fue conocer el problema del usuario. La interacción, la interfaz y la experiencia del producto formaron la ventaja. La integridad funcional era el cuerpo de la espada. La confiabilidad y la facilidad de mantenimiento eran como el mango, permitiendo que alguien realmente lo sostuviera y lo usara.

Una sola punta afilada podría convertirse, como mucho, en un demo impresionante. Todavía no era una daga que alguien pudiera utilizar.

La integridad no significaba ponerlo todo en el producto. Una navaja suiza puede resolver muchos problemas, pero es posible que no profundice lo suficiente en ninguno de ellos.

La verdadera integridad significaba completar todo el viaje que el usuario necesitaba en torno a un valor fundamental. Cada parte del producto tenía que apuntar al mismo problema y respaldar a las demás partes, en lugar de utilizar más funciones para ocultar el hecho de que el problema principal seguía sin resolver.

En 2023 dejé SenseTime y salté al siguiente río. En 2024 hicimos la calabaza y empezamos a comprender por qué un producto tenía que funcionar a lo largo del tiempo. En 2025 queríamos que la magia apareciera por fin y también intentamos reducir el vasto segundo cerebro a una daga.

La magia aún no había aparecido y Sayso aún no se había convertido en un producto funcional. Aunque ahora podíamos ver la necesidad, todavía nos faltaba la capacidad de construirla rápida y bien.

Pero en el transcurso del año, al menos llegamos a ver con mayor precisión lo que nos faltaba.

Nuestra búsqueda del filo no nos había hecho abandonar la integridad, la fiabilidad ni la responsabilidad a largo plazo. También empezábamos a comprender que conocer pronto a los clientes no significaba entregarles un producto que ya sabíamos deficiente, y que iterar con rapidez no significaba perseguir únicamente la velocidad de desarrollo.

A día de hoy, todavía no hemos fabricado esa daga completamente formada.

Apenas hemos empezado a aprender a afilarla.

Una punta por sí sola no es una daga.

Avant de le publier, je savais déjà qu'il n'était pas assez bon.

Son interface manquait de finition, les interactions ne semblaient pas encore naturelles et le flux fonctionnel était incomplet. Nous avons pu constater de nombreux problèmes sans attendre les commentaires des utilisateurs. Plus troublant encore, ces problèmes ne pouvaient être séparés les uns des autres. L'interface, l'expérience utilisateur, l'exhaustivité fonctionnelle, la fiabilité et la maintenabilité devaient tous fonctionner en même temps avant de pouvoir former un produit complet.

Mais nous venions de passer des mois à absorber un ensemble de méthodes de démarrage : rencontrer les clients tôt, avancer par petites étapes et itérer rapidement. Ainsi, même si nous n'étions pas satisfaits du produit, nous pensions toujours que nous devrions le publier en premier.

Les utilisateurs ont rapidement soulevé de nombreux problèmes. Nous en connaissions déjà une part importante avant la sortie. Leurs commentaires sont devenus le point de départ du changement que nous avons opéré au second semestre.

Avec le recul, ce test bêta a divisé 2025 en deux moitiés. Au cours du premier semestre, nous avons continué la construction de MagicGourd, en espérant faire enfin apparaître sa magie. Au milieu de l'année, nous avons extrait une idée dans Sayso, l'avons construite rapidement et l'avons présentée aux utilisateurs. Au second semestre, au lieu de continuer à rechercher la vitesse de sortie, nous nous sommes tournés vers le renforcement des capacités de nos produits. Le point de départ de tout cela s'est produit au début de l'année, lorsque nous avons reçu un investissement de MiraclePlus et avons rejoint son accélérateur.

À la fin de l'année, nous n'avions toujours pas fabriqué ce poignard. Mais nous avions commencé à comprendre qu'une pointe seule ne fait pas un poignard.

Une interview à laquelle je n'avais pas prévu d'assister

Au début de 2025, je n'avais pas prévu de collecter des fonds.

En 2024, nous avions passé la plupart de notre temps à construire MagicGourd et publié 27 versions. Nos tentatives limitées de collecte de fonds n’avaient mené nulle part et le produit était encore loin d’être le « véritable deuxième cerveau » que nous envisagions. Mais j'ai profondément apprécié le processus de construction.

Je pensais que nous pouvions continuer à très petite échelle, en avançant étape par étape sans nous précipiter pour lever des fonds.

Kehan m'a fait changer d'avis. Il m'a dit que la collecte de fonds n'était pas nécessairement seulement une question d'argent. L'accélérateur MiraclePlus, ses mentors et ses anciens élèves pourraient également nous aider sur une période beaucoup plus longue.

À ce moment-là, la date limite de candidature était déjà passée. Mais je ne voulais pas laisser la recommandation de Kehan se perdre, alors j'ai quand même soumis une candidature, décrivant brièvement comment je pensais à un véritable deuxième cerveau.

Cette interview a eu lieu au bureau de MiraclePlus à Pékin. Pendant que j'attendais, j'ai vu plusieurs suggestions d'entretien sur un écran : les réponses devaient être simples, directes et véridiques.

Lors de l'entretien d'un an plus tôt, j'avais inconsciemment cherché les réponses que les investisseurs voulaient entendre. Lorsqu’ils remettaient en question nos idées à plusieurs reprises, je craignais que mes réponses ne soient pas assez bonnes. Parce que je respectais les gens autour de la table, je pouvais même commencer à douter de mon propre jugement.

Cette fois, je n'étais pas si pressé.

Après une année complète de développement en 2024, nous étions toujours dans l'eau, mais nous ne luttions plus comme nous l'avions juste après nous être lancés. Je n'ai pas essayé de prouver que je devais avoir raison et je n'avais pas préparé de réponses très précises. J'ai simplement dit ce que je pensais sincèrement.

Le Dr Lu Qi m'a demandé ce que je pensais de SenseTime. J'ai dit que, tout d'abord, j'étais profondément reconnaissant envers l'entreprise, car j'y avais traversé une période cruciale de croissance et de transformation. Aux alentours de l'arrivée de ChatGPT, SenseTime a peut-être été légèrement lent à réagir car un gros navire est difficile à faire tourner. Mais d’ici 2025, je voyais la situation changer rapidement et je pensais qu’une ère meilleure pour SenseTime arrivait.

Il m’a ensuite demandé ce que je pensais de DeepSeek. Ma réponse était un mot : coût. Je n'ai pas précisé à l'époque. Je croyais simplement que le coût affecterait directement l'échelle à laquelle une technologie pourrait entrer dans le monde réel.

L'entretien s'est déroulé plus facilement que prévu. Peut-être parce que je n'étais plus désespéré d'un résultat particulier, il est devenu plus facile de parler simplement.

Plus tard, MiraclePlus a investi en nous et nous avons rejoint l'accélérateur.

Nous voulions que la magie apparaisse enfin

Si l'objectif de 2024 avait été de fabriquer d'abord la gourde, au début de 2025 nous voulions que sa magie apparaisse enfin.

En 2024, nous sommes restés extrêmement concentrés et avons terminé la version 0.27 de MagicGourd. Le produit aidait les gens à marquer ce qui les avait touchés sur des pages web, des PDF en ligne et des vidéos, à consigner les pensées qui surgissaient et à conserver le tout au fil du temps.

Mais c'était encore plus proche d'un conteneur. Il pouvait collecter et gérer les dossiers d’une personne, mais il ne pouvait pas vraiment les comprendre, et encore moins aider quelqu’un à découvrir des pensées restées inachevées.

Ainsi, lorsque nous avons planifié 2025, nous nous sommes fixés un objectif beaucoup plus vaste. Nous ne nous contenterions plus d’ajouter des fonctionnalités. Nous voulions faire un véritable pas vers le véritable deuxième cerveau que nous avions imaginé.

Nous voulions comprendre les enregistrements à long terme d'une personne, trouver des connexions dispersées à travers différentes époques et différents éléments de contenu, comprendre ce que pensait l'utilisateur à ce moment-là et reconnaître les intentions qu'il n'avait pas encore clairement exprimées.

Le but était excitant. C'était également bien au-delà de ce que nous pouvions gérer à l'époque.

Au cours du premier semestre, nous avons consacré d'énormes efforts au développement. Le problème n’était pas le manque de travail acharné, mais le nombre de problèmes à résoudre en même temps. Chaque pas en avant révélait davantage de questions. Le champ d'application n'a cessé de s'étendre, tandis que notre rythme de développement a continué de ralentir. Six mois se sont écoulés et nous n'avions toujours pas mis la valeur la plus importante devant les utilisateurs.

Après être entré dans l'accélérateur MiraclePlus, nous n'arrêtions pas d'entendre un mot : sharp.

Mon mentor dans l'accélérateur, Peter, nous a répété qu'une startup devait fabriquer un poignard, pas un couteau suisse.

À la fin du premier semestre, nous avons commencé à penser que le problème était que le produit était devenu trop volumineux. Si nous ne pouvions pas construire un véritable deuxième cerveau d’un seul coup, nous devrions extraire son élément le plus important et le transformer en un produit petit, rapide et cool.

À l'époque, nous pensions que c'était ce que signifiait un poignard.

Un deuxième cerveau devrait comprendre les intentions pas encore exprimées

Nous avons demandé à plusieurs reprises ce qui comptait le plus dans un deuxième cerveau.

La réponse que nous avons finalement trouvée était de comprendre l'intention.

Un outil d'information ordinaire commence généralement par ce que l'utilisateur a déjà saisi. Si un utilisateur écrit une phrase, il peut la réviser. Si l'utilisateur pose une question, il peut y répondre. Si l'utilisateur enregistre un article, il peut le résumer.

Mais de nombreuses intentions humaines ne sont pas clairement exprimées au départ. Parfois, nous n’avons qu’un vague sentiment que quelque chose compte, sans savoir ce qui nous tient vraiment à cœur. Parfois, nous sommes sur le point de rencontrer quelqu’un d’important et avons beaucoup d’informations en tête, mais nous ne savons pas ce qui vaut le plus la peine d’être dit. Parfois, nous connaissons le sentiment que nous voulons exprimer mais nous ne trouvons pas les mots justes.

Si un deuxième cerveau pouvait combiner le contexte actuel de l’utilisateur avec ces intentions tacites, il ferait plus que traiter les informations existantes. Il commencerait à participer au processus par lequel une personne forme une expression ou un jugement.

Sur la base de cette idée, nous avons conçu un produit appelé Sayso au milieu de l'année.

En utilisant le contexte actuel de la personne, le produit l'aiderait à voir ce qu'elle pourrait dire ensuite. Nous ne voulions pas que l'IA décide à la place de l'utilisateur de sa véritable intention. Nous voulions qu'elle propose des directions possibles dans lesquelles l'utilisateur pourrait reconnaître ce qu'il voulait réellement exprimer.

Ce besoin apparaît dans de nombreuses situations réelles. Avant de rencontrer une personne importante ou d’entamer une conversation importante, les gens ne manquent souvent pas de choses à dire. Le problème est de savoir quelle partie d’une grande quantité d’informations est la plus importante à ce moment-là.

Sayso a essayé de résumer le vaste objectif de comprendre les intentions implicites d'une personne en une seule tâche concrète : utiliser le contexte actuel de la personne pour découvrir les intentions qu'elle n'avait pas encore exprimées.

Nous pensions avoir enfin trouvé un poignard dans la vaste idée d'un deuxième cerveau.

Nous avons confondu « petit » et « affûté »

Au milieu de l'année, nous avons déménagé d'un gros produit à un petit, et notre vitesse de développement a sensiblement augmenté.

Mais au cours de ce changement, notre compréhension d'un poignard se limitait encore à sa forme extérieure.

Nous pensions que rendre le produit plus petit en faisait un poignard. Nous pensions que moins de fonctionnalités en faisaient un poignard. Plus tard, nous avons aussi confondu la nouveauté et la vitesse de développement avec le tranchant : si un produit semblait nouveau, pouvait être construit rapidement et atteindre vite les utilisateurs, il paraissait plus proche de la bonne réponse que le couteau suisse que nous avions construit.

Au milieu de l'année, nous avons construit Sayso en très peu de temps et l'avons donné aux utilisateurs bêta.

Leurs retours nous ont montré que certaines personnes avaient vraiment besoin d'aide pour s'exprimer avant une réunion ou une conversation importante, et qu'elles pouvaient comprendre l'intérêt de découvrir les intentions à partir du contexte. Cela a fourni une première preuve que le problème que nous ciblions était réel, plutôt qu’une simple idée qui semblait nouvelle.

Mais le produit lui-même n'a pas fonctionné.

Une démo d'IA sur la compréhension de l'intention n'aurait peut-être besoin que de produire un résultat surprenant à partir de quelques exemples soigneusement préparés. Un vrai produit devait montrer aux utilisateurs quel contexte fournir, les aider à comprendre pourquoi il proposait certaines suggestions et leur permettre de modifier, choisir ou rejeter naturellement ces suggestions.

L'interface devait inspirer confiance. Les interactions ne pouvaient pas créer un nouveau fardeau. Les fonctionnalités devaient accompagner l'utilisateur tout au long de la tâche. Dans le même temps, le système devait être fiable et rester facile à entretenir et à améliorer.

Aucune de ces choses, prise individuellement, ne nous dépassait nécessairement. La difficulté était de les rendre tous suffisamment bons en même temps dans un laps de temps limité.

Les utilisateurs pouvaient identifier les problèmes rapidement, mais nous ne parvenions pas à les résoudre à la fois vite et bien. Parfois, nous achevions une fonctionnalité au détriment de l'expérience globale. Parfois, nous améliorions une partie de l'expérience tout en rendant le système sous-jacent plus difficile à maintenir. Parfois, la capacité principale pouvait déjà être démontrée, mais l'utilisateur ne pouvait toujours pas parcourir sans heurts l'ensemble du parcours.

Le test bêta n'était pas dénué de sens. Cela nous a au moins permis de confirmer que le besoin existait.

Mais l'existence d'un besoin ne signifie pas qu'un produit fonctionne. Un produit fonctionnel ne signifie pas qu'un marché fonctionne.

Parce que la qualité de la mise en œuvre se situait entre les utilisateurs et la valeur fondamentale, nous n'avions pas vraiment testé si Sayso pouvait fournir cette valeur de manière cohérente, et encore moins si suffisamment de personnes voudraient l'utiliser au fil du temps.

Nous avions peut-être vu le problème que le poignard devait percer, mais nous n'avions toujours pas la capacité de transformer cette idée en un poignard que quelqu'un pourrait réellement utiliser.

L'œil pouvait voir, mais la main ne pouvait pas encore créer

Après avoir publié Sayso, nous avons initialement attribué le problème à une vitesse d'itération insuffisante. Les utilisateurs nous avaient fait part de leurs commentaires, la réponse semblait donc être de continuer à avancer par petites étapes et de changer de produit plus rapidement.

Mais nous avons vite découvert que la vitesse n'était pas le seul problème.

Avant de lancer le produit, nous savions déjà qu'il n'était pas bon. La plupart des problèmes signalés dans les commentaires des utilisateurs n’ont pas dépassé notre propre jugement. Ce qui nous manquait, ce n'était pas l'œil pour distinguer un bon produit d'un mauvais, mais la main qui pouvait rapidement transformer ce jugement en produit.

L'œil pouvait déjà voir. La main ne pouvait pas encore fabriquer.

Cela ne voulait pas dire que tout ce que nous avions appris sur les produits en 2024 était faux.

Tout au long de 2025, MagicGourd est resté en ligne et maintenu. Les nouvelles fonctionnalités sont arrivées plus lentement, mais le service existant a continué à fonctionner. À la fin de l’année, MagicGourd comptait environ 3 000 utilisateurs et les retours restaient globalement positifs. Nous n'avions connaissance d'aucune perte ou corruption de données utilisateur au cours de l'année.

En 2024, nous avions appris comment transformer un Demo en un logiciel capable de fonctionner dans le temps : comment gérer la synchronisation, la confidentialité, la compatibilité et les pannes ; comment maintenir un service dont dépendaient les vrais utilisateurs ; et comment assumer la responsabilité des données qu'une personne pourrait accumuler pendant de nombreuses années.

Ces capacités restaient importantes. Elles ont fait de MagicGourd plus qu'une démonstration et nous ont permis de rester responsables envers les utilisateurs existants, même lorsque le rythme des nouvelles fonctionnalités a ralenti.

Mais 2025 a exposé une autre couche de capacités.

Nous n'étions toujours pas doués pour transformer un besoin en une définition claire du produit. Nous n’étions pas doués pour créer une interface et un flux d’interaction soignés et naturels en peu de temps. Nous ne pouvions pas non plus équilibrer de manière fiable l'expérience, la fonctionnalité, la fiabilité et la maintenabilité à la fois.

Nous avions une expertise algorithmique et une capacité en ingénierie système. Lorsqu’une idée apparaissait, nous pouvions rapidement mettre en œuvre son noyau technique. Mais une technologie fonctionnelle ne signifiait pas un produit fonctionnel. La véritable force d'un produit signifiait compresser de nombreux jugements qui se contraignaient les uns les autres en quelque chose que l'utilisateur ressentait comme simple, clair et complet.

Alors que nous entrions dans la seconde moitié de l'année, nous avons finalement admis que les capacités de nos produits ne pouvaient pas encore soutenir notre ambition.

Apprenez d'abord à affûter la lame

Nous avons défini le second semestre comme une période de renforcement des capacités.

La décision a été difficile. À la fin du premier semestre, nous venions d'investir beaucoup d'efforts pour comprendre pourquoi nous devions rencontrer les clients plus tôt. Au cours du second semestre, cependant, nous avons décidé d'arrêter de précipiter chaque produit inachevé devant les utilisateurs et d'apprendre d'abord à bien construire des produits.

En surface, cela ressemblait à un retrait du marché au sein de l'entreprise. Mais le problème que nous voulions résoudre n’était pas un problème auquel seul le marché pouvait répondre.

Les utilisateurs pouvaient nous dire si un besoin était réel, si le produit créait de la valeur et s'ils souhaitaient continuer à l'utiliser. Mais même si nous considérions l'interface comme imparfaite, si nous savions déjà qu'un flux d'interaction était incomplet ou si nous savions que des problèmes de fiabilité obscurciraient la valeur fondamentale, donner le produit aux utilisateurs ne produirait pas d'informations plus utiles sur la question centrale.

Le marché devrait nous aider à répondre à des questions inconnues, et non à répéter des réponses que nous connaissions déjà.

Nous avons donc commencé à étudier à plusieurs reprises les produits que nous admirions véritablement. Nous avons décomposé leur structure, leur conception visuelle et leurs interactions, en nous demandant pourquoi chaque détail avait été traité d'une manière particulière. Grâce à des études approfondies et à des réimplémentations, nous avons transformé les jugements que nous pouvions voir en choses que nous avions formulées nous-mêmes. Nous avons ensuite comparé les différences et réessayé, jusqu'à comprendre pourquoi ces excellents produits semblaient simples, naturels et complets.

Une étude approfondie ne consistait pas à copier la surface d’un produit ou à rechercher une réponse que nous pourrions emporter telle quelle. Cela ressemblait davantage à la pratique par laquelle quelqu'un apprend la peinture, la musique ou la calligraphie : d'abord entraîner l'œil à faire la différence, puis laisser la main rattraper progressivement son retard, et ensuite seulement appliquer cette capacité à son propre problème.

La capacité du produit contient une grande quantité de connaissances tacites comme celle-ci. Comprendre une idée, ou même évaluer avec précision le produit de quelqu’un d’autre, ne signifie pas que nous en possédons nous-mêmes la capacité. Ce n'est qu'en transformant les jugements en interfaces, en interactions et en systèmes grâce à des choix concrets répétés que cette capacité pourrait véritablement faire partie de l'équipe.

À la fin de l'année, nous ne pouvions toujours pas prouver que nous étions capables de créer d'excellents produits de manière cohérente. Mais en milieu d’année, tout ce que nous pouvions faire, c’était vaguement sentir que « ce produit n’est pas bon ». À la fin, nous pourrions diviser ce jugement en questions plus spécifiques : comment les informations doivent être organisées, comment une interaction doit progresser, comment les détails visuels doivent soutenir l'ensemble et comment les contraintes du système affecteraient l'expérience. Nous pourrions ensuite entraîner ces capacités une par une par décomposition, étude approfondie, réimplémentation et reconstruction.

Ces changements n'étaient encore que le résultat de la pratique interne et ne pouvaient pas remplacer le test des utilisateurs réels. Ce que nous pouvions dire, c'est que nous avions commencé à former une manière plus concrète de pratiquer et que la distance entre nos yeux et nos mains avait commencé à se rétrécir.

La collecte de fonds n'est pas seulement une question d'argent

Avec le recul, le point soulevé par Kehan au début de l'année se confirmait lentement.

Recevoir des investissements était important, mais l'argent n'était pas tout ce que MiraclePlus nous donnait. Les conseils de mentors et les conversations avec des pairs ne se transformeraient pas nécessairement immédiatement en utilisateurs, en revenus ou en produit à succès. À la fin de l’année, je ne pouvais pas dire que ces relations avaient produit des résultats directs. Mais la métaphore du poignard de Peter était déjà entrée dans la façon dont nous évaluions les produits chaque jour.

Cela nous obligeait sans cesse à réexaminer nos produits. Chaque fois que je pensais l'avoir compris, la pratique ultérieure m'a montré que je n'en avais compris qu'une partie.

Au début, je pensais que cela signifiait réduire le vaste deuxième cerveau à quelque chose de plus petit. Plus tard, j'ai pensé que petit, rapide et séduisant signifiait affûté. Plus tard encore, j'ai compris qu'un vrai poignard ne fonctionne pas simplement parce qu'il est petit : il doit concentrer une expérience produit complète sur un problème précis.

L'accélérateur n'a pas fait le poignard pour nous, mais il nous a aidé à comprendre plus tôt pourquoi l'objet entre nos mains n'en était pas encore un.

C'est ce que signifie dire que la collecte de fonds n'est pas seulement une question d'argent. Cela ne fournit peut-être pas de réponse immédiate, mais cela peut changer la façon dont nous posons des questions, nous évaluons et continuons à apprendre.

Le véritable tranchant exige aussi la complétude

À la fin de 2025, ma compréhension d'un poignard était différente de ce qu'elle avait été au début de l'année.

La compréhension du problème de l'utilisateur était la pointe. L'interaction, l'interface et l'expérience produit formaient le tranchant. La complétude fonctionnelle était le corps de la lame. La fiabilité et la maintenabilité constituaient la poignée, permettant à quelqu'un de vraiment la tenir et de l'utiliser.

Une seule pointe affûtée pourrait tout au plus devenir une démo impressionnante. Ce ne serait pas encore un poignard que quelqu'un pourrait réellement utiliser.

La complétude ne signifiait pas tout mettre dans le produit. Un couteau suisse peut résoudre de nombreux problèmes sans aller assez loin dans aucun d'entre eux.

La véritable complétude signifiait achever tout le parcours dont l'utilisateur avait besoin autour d'une valeur centrale. Chaque partie du produit devait viser le même problème et soutenir les autres, au lieu d'utiliser davantage de fonctionnalités pour masquer le fait que le problème principal restait irrésolu.

En 2023, j'ai quitté SenseTime et j'ai sauté dans la rivière suivante. En 2024, nous avons fabriqué la gourde et commencé à comprendre pourquoi un produit devait fonctionner dans le temps. En 2025, nous voulions que la magie apparaisse enfin, et nous avons également essayé de briser le vaste deuxième cerveau en un poignard.

La magie n'était pas encore apparue et Sayso n'était pas encore devenu un produit fonctionnel. Même si nous en voyions désormais le besoin, nous n'avions toujours pas la capacité de le construire rapidement et correctement.

Mais au cours de l'année, nous sommes au moins parvenus à voir plus précisément ce qui nous manquait.

Notre quête du tranchant ne nous a pas fait abandonner la complétude, la fiabilité ni la responsabilité à long terme. Nous commencions aussi à comprendre que rencontrer tôt les clients ne signifiait pas leur offrir un produit dont nous savions déjà qu'il était médiocre, et qu'itérer rapidement ne signifiait pas rechercher uniquement la vitesse de développement.

À ce jour, nous n'avons pas encore fabriqué ce poignard entièrement formé.

Nous avons seulement commencé à apprendre à l'affûter.

Une pointe à elle seule n'est pas un poignard.

इसे जारी करने से पहले, मुझे पहले से ही पता था कि यह पर्याप्त अच्छा नहीं था।

इसके इंटरफ़ेस में पॉलिश की कमी थी, इंटरैक्शन अभी तक स्वाभाविक नहीं लग रहा था, और कार्यात्मक प्रवाह अधूरा था। हम उपयोगकर्ताओं की प्रतिक्रिया की प्रतीक्षा किए बिना कई समस्याएं देख सकते हैं। अधिक परेशानी की बात यह है कि इन समस्याओं को एक-दूसरे से अलग नहीं किया जा सकता है। पूर्ण उत्पाद बनाने से पहले इंटरफ़ेस, उपयोगकर्ता अनुभव, कार्यात्मक पूर्णता, विश्वसनीयता और रखरखाव सभी को एक ही समय में काम करना पड़ता था।

लेकिन हमने स्टार्टअप विधियों के एक सेट को आत्मसात करने में कई महीने बिताए थे: ग्राहकों से जल्दी मिलना, छोटे कदमों में आगे बढ़ना और तेजी से पुनरावृत्ति करना। इसलिए भले ही हम उत्पाद से असंतुष्ट थे, फिर भी हमारा मानना था कि हमें इसे पहले जारी करना चाहिए।

Users ने तुरंत कई मुद्दे उठाए। हम रिलीज से पहले ही उनमें से काफी संख्या के बारे में जान चुके थे। उनकी प्रतिक्रिया वर्ष की दूसरी छमाही में हमारे द्वारा किए गए बदलाव का शुरुआती बिंदु बन गई।

पीछे मुड़कर देखें तो उस बीटा परीक्षण ने 2025 को दो हिस्सों में बाँट दिया। पहली छमाही में हमने MagicGourd पर काम जारी रखा और उम्मीद की कि उसका जादू आखिरकार सामने आएगा। वर्ष के मध्य में हमने एक विचार को अलग कर Sayso बनाया, उसे तेजी से तैयार किया और उपयोगकर्ताओं के सामने रखा। दूसरी छमाही में रिलीज़ की गति के पीछे भागने के बजाय हमने अपनी उत्पाद-निर्माण क्षमता विकसित करनी शुरू की। इन सबकी शुरुआत वर्ष के आरंभ में हुई, जब हमें MiraclePlus से निवेश मिला और हम उसके एक्सेलेरेटर से जुड़े।

वर्ष के अंत तक, हमने अभी भी वह खंजर नहीं बनाया था। लेकिन हमने समझना शुरू कर दिया था: केवल ब्लेड की नोक खंजर नहीं है।

एक साक्षात्कार जिसमें मैंने भाग लेने की योजना नहीं बनाई थी

2025 की शुरुआत में, मेरी पैसे जुटाने की कोई योजना नहीं थी।

2024 में, हमने अपना अधिकांश समय MagicGourd के निर्माण में बिताया और 27 संस्करण जारी किए। हमारे सीमित धन उगाहने के प्रयास कहीं नहीं गए थे, और उत्पाद अभी भी "सच्चे दूसरे मस्तिष्क" से बहुत दूर था जिसकी हमने कल्पना की थी। लेकिन मैंने इसके निर्माण की प्रक्रिया का भरपूर आनंद लिया।

मैंने सोचा कि हम निवेश में जल्दबाजी किए बिना एक-एक कदम आगे बढ़ते हुए बहुत छोटे पैमाने पर काम जारी रख सकते हैं।

Kehan ने मेरा मन बदल दिया। उन्होंने मुझसे कहा कि धन उगाहना जरूरी नहीं कि केवल पैसे के बारे में हो। MiraclePlus एक्सेलेरेटर, इसके गुरु और इसके पूर्व छात्र भी हमें लंबी अवधि में मदद कर सकते हैं।

तब तक, आवेदन की समय सीमा पहले ही बीत चुकी थी। लेकिन मैं Kehan की अनुशंसा को व्यर्थ नहीं जाने देना चाहता था, इसलिए मैंने वैसे भी एक आवेदन जमा किया, जिसमें संक्षेप में बताया गया कि मैंने एक सच्चे दूसरे मस्तिष्क के बारे में कैसे सोचा।

यह इंटरव्यू बीजिंग स्थित MiraclePlus कार्यालय में हुआ था। प्रतीक्षा करते समय मैंने स्क्रीन पर कुछ साक्षात्कार सुझाव देखे: उत्तर सरल, सीधे और सच्चे होने चाहिए।

एक साल पहले साक्षात्कार में, मैंने अनजाने में उन उत्तरों की खोज की थी जो निवेशक सुनना चाहते थे। जब उन्होंने बार-बार हमारे विचारों को चुनौती दी, तो मुझे चिंता हुई कि मेरे उत्तर पर्याप्त अच्छे नहीं थे। क्योंकि मैं मेज पर मौजूद लोगों का सम्मान करता था, इसलिए मुझे अपने फैसले पर भी संदेह होने लगा था।

इस बार, मैं इतनी जल्दी में नहीं था।

2024 में विकास के पूरे एक साल के बाद, हम अभी भी पानी में थे, लेकिन अब उतना संघर्ष नहीं कर रहे थे जितना हमने कूदने के बाद किया था। मैंने यह साबित करने की कोशिश नहीं की कि मुझे सही होना चाहिए, और मैंने बहुत परिष्कृत उत्तर तैयार नहीं किए थे। मैंने बस वही कहा जो मैंने वास्तव में सोचा था।

डॉ. Lu Qi ने पूछा कि मैं SenseTime के बारे में क्या सोचता हूँ। मैंने कहा कि सबसे पहले मैं कंपनी का बहुत आभारी हूँ, क्योंकि वहाँ मैंने विकास और बदलाव का एक निर्णायक दौर देखा। ChatGPT के आने के आसपास SenseTime की प्रतिक्रिया शायद कुछ धीमी रही हो—बड़े जहाज को मोड़ना कठिन होता है। लेकिन 2025 तक मुझे तेज बदलाव दिखाई दे रहा था और विश्वास था कि SenseTime के लिए बेहतर समय आ रहा है।

फिर उन्होंने पूछा कि मैं DeepSeek के बारे में क्या सोचता हूँ। मेरा उत्तर एक शब्द था: लागत। मैंने उस समय विस्तार से नहीं बताया। मेरा मानना था कि लागत सीधे उस पैमाने को प्रभावित करेगी जिस पर कोई तकनीक वास्तविक दुनिया में प्रवेश कर सकती है।

साक्षात्कार मेरी अपेक्षा से अधिक सुचारू रूप से चला। शायद इसलिए कि मैं अब किसी विशेष परिणाम के लिए उत्सुक नहीं था, सरलता से बोलना आसान हो गया।

बाद में, MiraclePlus ने हम में निवेश किया, और हम एक्सेलेरेटर में शामिल हो गए।

हम चाहते थे कि जादू अंततः प्रकट हो

यदि 2024 में लक्ष्य पहले लौकी बनाना था, तो 2025 की शुरुआत में हम चाहते थे कि इसका जादू आखिरकार सामने आए।

2024 में हमने बहुत केंद्रित रहकर MagicGourd संस्करण 0.27 पूरा किया। इससे लोग वेबपेजों, ऑनलाइन PDF और वीडियो में उन अंशों को चिह्नित कर सकते थे जिन्होंने उन्हें छुआ, उठने वाले विचारों को दर्ज कर सकते थे और उन्हें लंबे समय तक सुरक्षित रख सकते थे।

लेकिन यह अभी भी एक कंटेनर के करीब था। यह किसी व्यक्ति के रिकॉर्ड एकत्र और प्रबंधित कर सकता है, लेकिन यह वास्तव में उन्हें समझ नहीं सकता है, किसी को अधूरे रह गए विचारों को खोजने में तो बिल्कुल भी मदद नहीं कर सकता है।

इसलिए जब हमने 2025 की योजना बनाई, तो हमने अपने लिए बहुत बड़ा लक्ष्य निर्धारित किया। हम अब सुविधाएँ जोड़ने से संतुष्ट नहीं होंगे। हम उस सच्चे दूसरे मस्तिष्क की ओर एक वास्तविक कदम उठाना चाहते थे जिसकी हमने कल्पना की थी।

हम किसी व्यक्ति के दीर्घकालिक रिकॉर्ड को समझना चाहते थे, अलग-अलग समय और सामग्री के विभिन्न हिस्सों में बिखरे हुए कनेक्शन ढूंढना चाहते थे, यह समझना चाहते थे कि उपयोगकर्ता उस पल में क्या सोच रहा था, और उन इरादों को पहचानना चाहता था जो उन्होंने अभी तक स्पष्ट रूप से व्यक्त नहीं किए हैं।

गोल रोमांचक था. यह उस दायरे से भी कहीं आगे था जिसे हम उस समय प्रबंधित कर सकते थे।

वर्ष की पहली छमाही के दौरान, हमने विकास के लिए जबरदस्त प्रयास किए। समस्या कड़ी मेहनत की कमी नहीं थी, बल्कि उन चीज़ों की संख्या थी जिन्हें एक ही बार में हल करना था। हर कदम आगे बढ़ने पर और अधिक प्रश्न उजागर होते गए। दायरा बढ़ता गया, जबकि हमारी विकास गति धीमी होती गई। आधा साल बीत गया, और हमने अभी भी उपयोगकर्ताओं के सामने सबसे महत्वपूर्ण मूल्य नहीं रखा है।

MiraclePlus एक्सेलेरेटर में प्रवेश करने के बाद हम एक शब्द बार-बार सुनते रहे: sharp।

एक्सेलेरेटर में मेरे गुरु Peter ने हमें बार-बार कहा कि एक स्टार्टअप को स्विस आर्मी चाकू नहीं, बल्कि एक खंजर बनाना चाहिए।

जैसे-जैसे वर्ष की पहली छमाही समाप्त होने लगी, हमने सोचना शुरू कर दिया कि समस्या यह थी कि उत्पाद बहुत बड़ा हो गया था। यदि हम एक बार में एक सच्चा दूसरा मस्तिष्क नहीं बना सकते, तो हमें इसका सबसे महत्वपूर्ण तत्व निकालना चाहिए और उसे एक ऐसे उत्पाद में बदलना चाहिए जो छोटा, तेज़ और अच्छा हो।

उस समय, हमने सोचा था कि खंजर का मतलब यही था।

दूसरे मस्तिष्क को उन इरादों को समझना चाहिए जो अभी तक नहीं बोले गए हैं

हमने बार-बार पूछा कि दूसरे मस्तिष्क में सबसे ज्यादा क्या मायने रखता है।

अंततः हमें जो उत्तर मिला वह इरादे को समझना था।

एक सामान्य सूचना उपकरण आम तौर पर उपयोगकर्ता द्वारा पहले ही दर्ज की गई जानकारी से शुरू होता है। यदि कोई उपयोगकर्ता कोई वाक्य लिखता है तो वह उसे संशोधित कर सकता है। यदि उपयोगकर्ता कोई प्रश्न पूछता है, तो यह उत्तर दे सकता है। यदि उपयोगकर्ता किसी लेख को सहेजता है, तो वह उसका सारांश प्रस्तुत कर सकता है।

लेकिन कई मानवीय इरादे शुरुआत में स्पष्ट रूप से व्यक्त नहीं होते हैं। कभी-कभी हमें केवल यह अस्पष्ट एहसास होता है कि कुछ मायने रखता है, बिना यह जाने कि हम वास्तव में किसकी परवाह करते हैं। कभी-कभी हम किसी महत्वपूर्ण व्यक्ति से मिलने जा रहे होते हैं और हमारे मन में बहुत सारी जानकारी होती है, लेकिन हम नहीं जानते कि सबसे अधिक कहने योग्य क्या है। कभी-कभी हम उस भावना को जानते हैं जिसे हम व्यक्त करना चाहते हैं लेकिन सही शब्द नहीं मिल पाते।

यदि दूसरा मस्तिष्क उपयोगकर्ता के वर्तमान संदर्भ को इन अनकहे इरादों के साथ जोड़ सकता है, तो यह मौजूदा जानकारी को संसाधित करने से कहीं अधिक काम करेगा। यह उस प्रक्रिया में भाग लेना शुरू कर देगा जिसके माध्यम से कोई व्यक्ति अभिव्यक्ति या निर्णय बनाता है।

इस विचार के आधार पर, वर्ष के मध्य में हमने Sayso नामक उत्पाद की कल्पना की।

व्यक्ति के वर्तमान संदर्भ का उपयोग करने से उन्हें यह देखने में मदद मिलेगी कि वे आगे क्या कह सकते हैं। हम नहीं चाहते थे कि एआई किसी उपयोगकर्ता के वास्तविक इरादे का फैसला करे। हम चाहते थे कि यह संभावित दिशा-निर्देश प्रदान करे जिससे उपयोगकर्ता पहचान सके कि वे वास्तव में क्या व्यक्त करना चाहते हैं।

यह आवश्यकता कई वास्तविक स्थितियों में प्रकट होती है। किसी महत्वपूर्ण व्यक्ति से मिलने या कोई महत्वपूर्ण बातचीत शुरू करने से पहले अक्सर लोगों के पास कहने के लिए चीजों की कमी नहीं होती है। समस्या यह जानने की है कि उस समय बड़ी मात्रा में जानकारी का कौन सा हिस्सा सबसे अधिक मायने रखता है।

Sayso ने किसी व्यक्ति के निहित इरादों को समझने के बड़े लक्ष्य को एक ठोस कार्य में समेटने की कोशिश की: व्यक्ति के वर्तमान संदर्भ से उन इरादों को उजागर करना जिन्हें उसने अभी तक व्यक्त नहीं किया था।

हमने सोचा कि हमें अंततः दूसरे मस्तिष्क के विशाल विचार के अंदर एक खंजर मिल गया है।

हमने "छोटे" को "तेज" समझ लिया

वर्ष के मध्य में, हम एक बड़े उत्पाद से एक छोटे उत्पाद की ओर चले गए, और हमारी विकास गति में उल्लेखनीय वृद्धि हुई।

लेकिन इस बदलाव के दौरान, खंजर के बारे में हमारी समझ अभी भी इसके बाहरी रूप तक ही सीमित थी।

हमने सोचा कि उत्पाद को छोटा बनाने से यह खंजर बन जाएगा। हमने सोचा कि कम सुविधाओं ने इसे एक खंजर बना दिया है। बाद में, हमने नवीनता और विकास की गति को भी तीक्ष्णता समझ लिया: यदि कोई उत्पाद नया लगता है, जल्दी बनाया जा सकता है, और उपयोगकर्ताओं तक जल्दी पहुंच सकता है, तो यह हमारे द्वारा बनाए जा रहे स्विस आर्मी चाकू की तुलना में सही उत्तर के करीब लगता है।

वर्ष के मध्य में हमने बहुत कम समय में Sayso बनाया और उसे बीटा उपयोगकर्ताओं को दिया।

उनकी प्रतिक्रिया ने हमें दिखाया कि कुछ लोगों को वास्तव में एक महत्वपूर्ण बैठक या बातचीत से पहले खुद को अभिव्यक्त करने में मदद की ज़रूरत थी, और वे संदर्भ से इरादों की खोज के मूल्य को समझ सकते थे। इसने प्रारंभिक साक्ष्य प्रस्तुत किया कि जिस समस्या को हम लक्षित कर रहे थे वह वास्तविक थी, न कि केवल एक विचार जो नया लगता था।

लेकिन उत्पाद स्वयं काम नहीं करता था।

इरादे को समझने के बारे में एक एआई डेमो को केवल कुछ सावधानीपूर्वक तैयार किए गए उदाहरणों में आश्चर्यजनक परिणाम देने की आवश्यकता हो सकती है। एक वास्तविक उत्पाद को उपयोगकर्ताओं को यह दिखाना था कि उन्हें कौन सा संदर्भ प्रदान करना है, उन्हें यह समझने में मदद करनी थी कि उसने विशेष सुझाव क्यों दिए, और उन्हें स्वाभाविक रूप से उन सुझावों को संपादित करने, चुनने या अस्वीकार करने देना था।

इंटरफ़ेस को विश्वास को प्रेरित करना था। आपसी मेलजोल से कोई नया बोझ पैदा नहीं हो सका. सुविधाओं को पूरे कार्य के दौरान उपयोगकर्ता का समर्थन करना था। साथ ही, सिस्टम को विश्वसनीय होना चाहिए और इसे बनाए रखना और सुधारना आसान होना चाहिए।

इनमें से कोई भी चीज़, व्यक्तिगत रूप से, आवश्यक रूप से हमसे परे नहीं थी। कठिनाई उन सभी को एक ही समय में सीमित अवधि के भीतर पर्याप्त रूप से अच्छा बनाने की थी।

उपयोगकर्ता समस्याओं को तुरंत पहचान सकते थे, लेकिन हम उन्हें जल्दी और अच्छी तरह से हल नहीं कर सके। कभी-कभी हमने समग्र अनुभव की कीमत पर एक फीचर पूरा किया। कभी-कभी हमने अंतर्निहित प्रणाली को बनाए रखना कठिन बनाते हुए अनुभव के एक हिस्से में सुधार किया। कभी-कभी मूल क्षमता का प्रदर्शन पहले ही किया जा सकता था, लेकिन उपयोगकर्ता फिर भी पूरी यात्रा सुचारू रूप से पूरी नहीं कर पाता।

बीटा परीक्षण निरर्थक नहीं था. इसने कम से कम हमें यह पुष्टि करने की अनुमति दी कि आवश्यकता अस्तित्व में थी।

लेकिन आवश्यकता के अस्तित्व का मतलब यह नहीं है कि कोई उत्पाद काम करता है। एक कार्यशील उत्पाद का मतलब यह नहीं है कि एक बाज़ार कार्यशील है।

क्योंकि कार्यान्वयन की गुणवत्ता उपयोगकर्ताओं और मूल मूल्य के बीच आ रही थी, हमने वास्तव में यह नहीं परखा था कि Sayso उस मूल्य को लगातार दे सकता है या नहीं, और यह तो और भी नहीं कि पर्याप्त लोग समय के साथ उसका उपयोग करना चाहेंगे या नहीं।

हमने वह समस्या देखी होगी जिसे खंजर से छेदना चाहिए, लेकिन हमारे पास अभी भी उस अंतर्दृष्टि को खंजर में बदलने की क्षमता नहीं है जिसका कोई वास्तव में उपयोग कर सके।

आँख देख सकती है, परन्तु हाथ अभी तक नहीं बना सकता

Sayso को जारी करने के बाद हमने शुरुआत में समस्या का कारण पुनरावृत्ति की कम गति को माना। उपयोगकर्ताओं ने प्रतिक्रिया दी थी, इसलिए उत्तर छोटे कदमों से आगे बढ़ना और उत्पाद को तेजी से बदलना लगता था।

लेकिन हमें जल्द ही पता चला कि गति ही एकमात्र समस्या नहीं थी।

उत्पाद जारी करने से पहले ही हमें पता चल गया था कि यह अच्छा नहीं है। उपयोगकर्ता प्रतिक्रिया में कई समस्याएं हमारे अपने निर्णय से आगे नहीं बढ़ी थीं। हमारे पास अच्छे उत्पाद को बुरे उत्पाद से अलग करने वाली आंख की कमी नहीं थी, बल्कि उस हाथ की कमी थी जो उस निर्णय को तुरंत उत्पाद में बदल सकता था।

आंख पहले से ही देख सकती थी। हाथ अभी तक नहीं बना सका।

इसका मतलब यह नहीं है कि 2024 में हमने उत्पादों के बारे में जो कुछ भी सीखा था वह गलत था।

पूरे 2025 में MagicGourd ऑनलाइन रहा और उसका रखरखाव जारी रहा। नई सुविधाएँ धीमी गति से आईं, लेकिन मौजूदा सेवा चलती रही। वर्ष के अंत तक MagicGourd के लगभग 3,000 उपयोगकर्ता थे और प्रतिक्रिया कुल मिलाकर सकारात्मक रही। हमें वर्ष के दौरान किसी उपयोगकर्ता डेटा के खोने या दूषित होने की जानकारी नहीं मिली।

2024 में, हमने सीखा था कि एक डेमो को ऐसे सॉफ़्टवेयर में कैसे बदला जाए जो समय के साथ काम कर सके: सिंक्रनाइज़ेशन, गोपनीयता, अनुकूलता और विफलताओं को कैसे संभालें; उस सेवा को कैसे बनाए रखा जाए जिस पर वास्तविक उपयोगकर्ता निर्भर थे; और एक व्यक्ति द्वारा कई वर्षों में जमा किए गए डेटा की जिम्मेदारी कैसे ली जाए।

वे क्षमताएं अभी भी मायने रखती हैं। उन्होंने MagicGourd को एक प्रदर्शन से कहीं अधिक बना दिया, और उन्होंने हमें नई सुविधाओं की गति धीमी होने पर भी मौजूदा उपयोगकर्ताओं के प्रति जिम्मेदार बने रहने की अनुमति दी।

लेकिन 2025 ने क्षमता की एक और परत उजागर की।

हम अभी भी किसी आवश्यकता को स्पष्ट उत्पाद परिभाषा में बदलने में अच्छे नहीं थे। हम कम समय में एक परिष्कृत और प्राकृतिक इंटरफ़ेस और इंटरैक्शन प्रवाह बनाने में अच्छे नहीं थे। न ही हम एक साथ अनुभव, कार्यक्षमता, विश्वसनीयता और रखरखाव को विश्वसनीय रूप से संतुलित कर सकते हैं।

हमारे पास एल्गोरिथम विशेषज्ञता और सिस्टम इंजीनियरिंग क्षमता थी। जब कोई विचार सामने आया, तो हम उसके तकनीकी मूल को तुरंत लागू कर सके। लेकिन कार्यशील प्रौद्योगिकी का मतलब कार्यशील उत्पाद नहीं था। वास्तविक उत्पाद की ताकत का मतलब कई निर्णयों को संपीड़ित करना है जो एक दूसरे को सरल, स्पष्ट और पूर्ण के रूप में अनुभव करने वाले उपयोगकर्ता के लिए बाध्य करते हैं।

जैसे ही हमने वर्ष की दूसरी छमाही में प्रवेश किया, हमने अंततः स्वीकार किया कि हमारी उत्पाद क्षमताएं अभी तक हमारी महत्वाकांक्षा का समर्थन नहीं कर सकती हैं।

सबसे पहले ब्लेड को तेज़ करना सीखें

हमने वर्ष की दूसरी छमाही को क्षमताओं के निर्माण की अवधि के रूप में परिभाषित किया।

निर्णय कठिन था। पहली छमाही के अंत में, हमने यह समझने में काफी प्रयास किया था कि हमें ग्राहकों से जल्दी क्यों मिलना चाहिए। हालाँकि, दूसरी छमाही में, हमने उपयोगकर्ताओं के सामने हर अधूरे उत्पाद को उछालना बंद करने का फैसला किया और पहले यह सीखा कि उत्पादों को अच्छी तरह से कैसे बनाया जाए।

सतह पर, यह कंपनी के अंदर बाजार से पीछे हटने जैसा लग रहा था। लेकिन जिस समस्या को हम हल करना चाहते थे वह ऐसी नहीं थी जिसका उत्तर केवल बाज़ार ही दे सके।

उपयोगकर्ता हमें बता सकते हैं कि क्या कोई ज़रूरत वास्तविक थी, क्या उत्पाद ने मूल्य बनाया था, और क्या वे इसका उपयोग जारी रखना चाहते थे। लेकिन अगर हम इंटरफ़ेस को बिना पॉलिश वाला मानते हैं, पहले से ही जानते थे कि इंटरैक्शन प्रवाह अधूरा था, या जानते थे कि विश्वसनीयता की समस्याएं मूल मूल्य को अस्पष्ट कर देंगी, तो उपयोगकर्ताओं को उत्पाद देने से केंद्रीय प्रश्न के बारे में अधिक उपयोगी जानकारी नहीं मिलेगी।

बाज़ार को हमें अज्ञात प्रश्नों का उत्तर देने में मदद करनी चाहिए, न कि उन उत्तरों को दोहराने की जो हम पहले से जानते थे।

इसलिए हमने उन उत्पादों का बार-बार अध्ययन करना शुरू किया जिनकी हम वास्तव में प्रशंसा करते थे। हमने उनकी संरचना, विज़ुअल डिज़ाइन और इंटरैक्शन को तोड़ दिया, और पूछा कि प्रत्येक विवरण को एक विशेष तरीके से क्यों संभाला गया था। गहन अध्ययन और पुनः कार्यान्वयन के माध्यम से, हमने उन निर्णयों को बदल दिया जिन्हें हम उन चीजों में देख सकते थे जो हमने स्वयं बनाए थे। फिर हमने अंतरों की तुलना की और फिर से प्रयास किया, जब तक हमें समझ नहीं आया कि ये उत्कृष्ट उत्पाद सरल, प्राकृतिक और संपूर्ण क्यों लगे।

करीबी अध्ययन किसी उत्पाद की सतह की नकल करने या ऐसे उत्तर की खोज करने के बारे में नहीं था जिसे हम अपरिवर्तित ले जा सकें। यह उस अभ्यास की तरह था जिसके माध्यम से कोई पेंटिंग, संगीत, या सुलेख सीखता है: पहले आंख को अंतर बताने के लिए प्रशिक्षित करें, फिर हाथ को धीरे-धीरे पकड़ने दें, और उसके बाद ही उस क्षमता को किसी की समस्या पर लागू करें।

उत्पाद क्षमता में इस तरह का बहुत सारा गुप्त ज्ञान समाहित होता है। किसी विचार को समझना, या यहां तक कि किसी और के उत्पाद का सटीक मूल्यांकन करना, इसका मतलब यह नहीं है कि हमारे पास स्वयं क्षमता है। बार-बार ठोस विकल्पों के माध्यम से निर्णयों को इंटरफेस, इंटरैक्शन और सिस्टम में बदलने से ही वह क्षमता वास्तव में टीम का हिस्सा बन सकती है।

वर्ष के अंत तक, हम अभी भी यह साबित नहीं कर सके कि हम लगातार उत्कृष्ट उत्पाद बनाने में सक्षम थे। लेकिन वर्ष के मध्य में, हम केवल यह महसूस कर सकते थे कि "यह उत्पाद अच्छा नहीं है।" अंत में, हम उस निर्णय को और अधिक विशिष्ट प्रश्नों में तोड़ सकते हैं: जानकारी को कैसे व्यवस्थित किया जाना चाहिए, बातचीत कैसे आगे बढ़नी चाहिए, दृश्य विवरण को संपूर्ण समर्थन कैसे देना चाहिए, और सिस्टम की बाधाएं अनुभव को कैसे प्रभावित करेंगी। फिर हम इन क्षमताओं को एक-एक करके विघटन, गहन अध्ययन, पुन: कार्यान्वयन और पुनर्निर्माण के माध्यम से प्रशिक्षित कर सकते हैं।

ये परिवर्तन अभी भी केवल आंतरिक अभ्यास के परिणाम थे और वास्तविक उपयोगकर्ताओं के परीक्षण का स्थान नहीं ले सकते थे। हम जो कह सकते थे वह यह था कि हमने अभ्यास करने का एक अधिक ठोस तरीका बनाना शुरू कर दिया था, और हमारी आँखों और हमारे हाथों के बीच की दूरी कम होनी शुरू हो गई थी।

धन उगाहना केवल पैसे के बारे में नहीं है

पीछे मुड़कर देखें तो, Kehan ने वर्ष की शुरुआत में जो बात कही थी, उसकी धीरे-धीरे पुष्टि हो रही थी।

निवेश मिलना महत्वपूर्ण था, लेकिन पैसा वह सब नहीं था जो MiraclePlus ने हमें दिया। सलाहकारों का मार्गदर्शन और साथियों से बातचीत जरूरी नहीं कि तुरंत उपयोगकर्ताओं, राजस्व या सफल उत्पाद में बदल जाए। वर्ष के अंत तक मैं नहीं कह सकता था कि इन संबंधों ने सीधे परिणाम दिए थे। लेकिन Peter का खंजर वाला रूपक हमारे रोज़ उत्पादों का मूल्यांकन करने के तरीके में शामिल हो चुका था।

यह हमें अपने उत्पादों की दोबारा जांच करने के लिए मजबूर करता रहा। जब भी मैंने सोचा कि मैं इसे समझ गया हूं, बाद में अभ्यास से मुझे पता चला कि मैं केवल एक भाग ही समझ पाया हूं।

सबसे पहले, मैंने सोचा कि इसका मतलब विशाल दूसरे मस्तिष्क को किसी छोटी चीज़ में तोड़ना है। बाद में, मैंने सोचा कि छोटा, तेज़ और ठंडा का मतलब तेज़ होता है। बाद में मुझे एहसास हुआ कि असली खंजर सिर्फ इसलिए काम नहीं करता क्योंकि वह छोटा था। इसे संपूर्ण उत्पाद अनुभव को एक विशिष्ट समस्या पर केंद्रित करना था।

एक्सीलेटर ने हमारे लिए खंजर नहीं बनाया, लेकिन इससे हमें जल्दी ही यह देखने में मदद मिली कि हमारे हाथ में जो चीज़ है वह अभी तक एक क्यों नहीं हुई है।

कहने का तात्पर्य यह है कि धन उगाहना केवल पैसे के बारे में नहीं है। यह तत्काल उत्तर नहीं दे सकता है, लेकिन यह हमारे प्रश्न पूछने, स्वयं का मूल्यांकन करने और सीखना जारी रखने के तरीके को बदल सकता है।

सच्ची तीक्ष्णता के लिए पूर्णता की भी आवश्यकता होती है

2025 के अंत तक, खंजर के बारे में मेरी समझ साल की शुरुआत में जो थी उससे अलग थी।

उपयोगकर्ता की समस्या की समझ धार की नोक थी। इंटरैक्शन, इंटरफ़ेस और उत्पाद अनुभव धार बनाते थे। कार्यात्मक पूर्णता ब्लेड का शरीर थी। विश्वसनीयता और रख-रखाव उसकी मूठ और आधार की तरह थे, जिनसे कोई उसे सचमुच पकड़कर उपयोग कर सके।

सिर्फ एक तेज नोक अधिक से अधिक प्रभावशाली डेमो बन सकती है; वह अभी ऐसा खंजर नहीं है जिसे कोई वास्तव में उपयोग कर सके।

पूर्णता का मतलब उत्पाद में सब कुछ डालना नहीं था। स्विस सेना का चाकू कई समस्याओं का समाधान कर सकता है, लेकिन यह उनमें से किसी एक में भी पर्याप्त गहराई तक नहीं जा सकता है।

सच्ची पूर्णता का मतलब उपयोगकर्ता के लिए आवश्यक संपूर्ण यात्रा को एक मूल मूल्य के आसपास पूरा करना है। उत्पाद के प्रत्येक भाग को एक ही समस्या की ओर इशारा करना था और अन्य भागों का समर्थन करना था, न कि इस तथ्य को छिपाने के लिए अधिक सुविधाओं का उपयोग करना कि मुख्य समस्या अनसुलझा रही।

2023 में मैंने SenseTime छोड़ा और अगली नदी में छलांग लगाई। 2024 में हमने लौकी बनाई और समझना शुरू किया कि किसी उत्पाद को समय की कसौटी पर क्यों टिकना पड़ता है। 2025 में हम चाहते थे कि जादू आखिरकार प्रकट हो, और हमने विशाल दूसरे मस्तिष्क को एक खंजर में ढालने की भी कोशिश की।

जादू अभी तक प्रकट नहीं हुआ था और Sayso भी अभी कार्यशील उत्पाद नहीं बन पाया था। अब हम आवश्यकता देख सकते थे, फिर भी हमारे पास उसे जल्दी और अच्छी तरह बनाने की क्षमता नहीं थी।

लेकिन वर्ष के दौरान, हम कम से कम अधिक सटीक रूप से देख पाए कि हमारे पास क्या कमी थी।

तीक्ष्णता की हमारी खोज ने हमें पूर्णता, विश्वसनीयता या दीर्घकालिक जिम्मेदारी को त्यागने के लिए बाध्य नहीं किया है। हम यह भी समझने लगे थे कि ग्राहकों से जल्दी मिलने का मतलब उन्हें वह उत्पाद देना नहीं है जिसके बारे में हम पहले से ही जानते थे कि वह खराब है, और उस तेजी से पुनरावृत्ति का मतलब केवल विकास की गति को आगे बढ़ाना नहीं है।

आज तक, हमने अभी तक वह पूरी तरह से तैयार खंजर नहीं बनाया है।

हमने अभी यह सीखना शुरू किया है कि इसे कैसे तेज किया जाए।

सिर्फ नोक से खंजर नहीं बनता।

Sebelum kami merilisnya, saya sudah tahu itu tidak cukup baik.

Antarmukanya kurang sempurna, interaksinya belum terasa alami, dan alur fungsinya tidak lengkap. Kami dapat melihat banyak masalah tanpa menunggu tanggapan pengguna. Yang lebih memprihatinkan lagi, permasalahan-permasalahan tersebut tidak dapat dipisahkan satu sama lain. Antarmuka, pengalaman pengguna, kelengkapan fungsi, keandalan, dan pemeliharaan semuanya harus bekerja pada saat yang sama sebelum dapat membentuk produk yang lengkap.

Namun kami baru saja menghabiskan waktu berbulan-bulan untuk mempelajari serangkaian metode startup: bertemu pelanggan lebih awal, bergerak dalam langkah-langkah kecil, dan mengulanginya dengan cepat. Jadi meskipun kami tidak puas dengan produk tersebut, kami tetap yakin bahwa kami harus merilisnya terlebih dahulu.

Pengguna dengan cepat mengemukakan banyak masalah. Kami telah mengetahui sejumlah besar dari mereka sebelum rilis. Masukan mereka menjadi titik awal perubahan yang kami lakukan di paruh kedua tahun ini.

Melihat ke belakang, pengujian beta tersebut membagi tahun 2025 menjadi dua bagian. Selama paruh pertama, kami terus membangun MagicGourd, berharap keajaibannya akhirnya muncul. Pada pertengahan tahun, kami mengekstrak satu ide ke Sayso, membangunnya dengan cepat, dan menyajikannya kepada pengguna. Pada paruh kedua, alih-alih mengejar kecepatan rilis, kami beralih ke pengembangan kemampuan produk. Titik awal dari semua ini terjadi pada awal tahun, ketika kami menerima investasi dari MiraclePlus dan bergabung dengan akseleratornya.

Sampai akhir tahun, kami masih belum membuat keris itu. Namun kami mulai memahami: ujung pisau saja bukanlah sebuah belati.

Wawancara yang Tidak Saya Rencanakan untuk Hadiri

Pada awal tahun 2025, saya tidak memiliki rencana untuk menggalang dana.

Pada tahun 2024, kami menghabiskan sebagian besar waktu kami untuk membangun MagicGourd dan merilis 27 versi. Upaya penggalangan dana kami yang terbatas tidak membuahkan hasil, dan produk tersebut masih jauh dari “otak kedua” yang kami bayangkan. Tapi saya sangat menikmati proses membangunnya.

Saya pikir kami dapat melanjutkannya dalam skala yang sangat kecil, bergerak maju selangkah demi selangkah tanpa terburu-buru mengambil investasi.

Kehan berubah pikiran. Dia mengatakan kepada saya bahwa penggalangan dana tidak selalu hanya tentang uang. Akselerator MiraclePlus, mentornya, dan alumninya juga dapat membantu kami dalam jangka waktu yang lebih lama.

Pada saat itu, batas waktu pendaftaran telah berlalu. Namun saya tidak ingin menyia-nyiakan rekomendasi Kehan, jadi saya tetap mengajukan lamaran, menjelaskan secara singkat bagaimana pendapat saya tentang otak kedua yang sebenarnya.

Wawancara ini berlangsung di kantor MiraclePlus di Beijing. Sementara saya menunggu, saya melihat beberapa saran wawancara di layar: jawaban harus sederhana, langsung, dan jujur.

Dalam wawancara setahun sebelumnya, saya secara tidak sadar mencari jawaban yang ingin didengar investor. Ketika mereka berulang kali menantang gagasan kami, saya khawatir jawaban saya tidak cukup baik. Karena saya menghormati orang-orang di seberang meja, saya bahkan mulai meragukan penilaian saya sendiri.

Kali ini, saya tidak terburu-buru.

Setelah setahun penuh pengembangan pada tahun 2024, kami masih berada di dalam air, namun tidak lagi mengalami kesulitan seperti yang kami alami setelah terjun ke dalamnya. Saya tidak mencoba membuktikan bahwa saya pasti benar, dan saya belum menyiapkan jawaban yang sangat matang. Saya hanya mengatakan apa yang sebenarnya saya pikirkan.

Dr Lu Qi bertanya apa pendapat saya tentang SenseTime. Saya katakan, pertama-tama, saya sangat berterima kasih kepada perusahaan, karena saya telah melalui masa pertumbuhan dan transformasi yang krusial di sana. Menjelang hadirnya ChatGPT, SenseTime mungkin agak lambat merespons karena kapal besar sulit untuk berbelok. Namun pada tahun 2025, saya dapat melihatnya berubah dengan cepat, dan saya yakin era yang lebih baik bagi SenseTime akan tiba.

Dia kemudian bertanya apa pendapat saya tentang DeepSeek. Jawaban saya hanya satu kata: biaya. Saya tidak menjelaskan lebih lanjut pada saat itu. Saya hanya percaya bahwa biaya akan secara langsung mempengaruhi skala di mana suatu teknologi dapat memasuki dunia nyata.

Wawancara berjalan lebih lancar dari yang saya harapkan. Mungkin karena saya tidak lagi putus asa untuk mendapatkan hasil tertentu, maka menjadi lebih mudah untuk berbicara secara sederhana.

Kemudian, MiraclePlus berinvestasi pada kami, dan kami bergabung dengan akselerator.

Kami Ingin Keajaiban Akhirnya Muncul

Jika sasaran pada tahun 2024 adalah membuat labu terlebih dahulu, maka pada awal tahun 2025 kami ingin keajaibannya akhirnya muncul.

Pada tahun 2024, kami tetap fokus dan menyelesaikan MagicGourd versi 0.27. Ini membantu orang menandai apa yang menggerakkan mereka di halaman web, PDF online, dan video, mencatat pemikiran yang muncul, dan menyimpan semuanya dari waktu ke waktu.

Tetapi itu masih lebih dekat dengan sebuah wadah. Ia dapat mengumpulkan dan mengelola catatan seseorang, namun ia tidak dapat benar-benar memahaminya, apalagi membantu seseorang menemukan pemikiran yang masih belum selesai.

Jadi ketika kami merencanakan tahun 2025, kami menetapkan tujuan yang jauh lebih besar. Kami tidak lagi puas dengan penambahan fitur. Kami ingin mengambil langkah nyata menuju otak kedua yang kami bayangkan.

Kami ingin memahami catatan jangka panjang seseorang, menemukan koneksi yang tersebar di berbagai waktu dan konten berbeda, memahami apa yang dipikirkan pengguna pada saat itu, dan mengenali niat yang belum mereka ungkapkan dengan jelas.

Tujuannya sangat menarik. Hal ini juga jauh melampaui kemampuan kami saat itu.

Selama paruh pertama tahun ini, kami mencurahkan upaya besar untuk pembangunan. Masalahnya bukan kurangnya kerja keras, tapi banyaknya hal yang harus diselesaikan sekaligus. Setiap langkah maju memunculkan lebih banyak pertanyaan. Cakupannya terus meluas, sementara laju perkembangan kami terus melambat. Setengah tahun telah berlalu, dan kami masih belum memberikan nilai terpenting kepada pengguna.

Setelah memasuki akselerator MiraclePlus, kami terus mendengar satu kata: sharp.

Mentor saya di bidang akselerator, Peter, berulang kali memberi tahu kami bahwa sebuah startup harus membuat belati, bukan pisau Swiss Army.

Ketika paruh pertama tahun ini hampir berakhir, kami mulai berpikir bahwa masalahnya adalah produk tersebut menjadi terlalu besar. Jika kita tidak dapat membangun otak kedua sekaligus, kita harus mengekstrak elemen terpentingnya dan mengubahnya menjadi produk yang kecil, cepat, dan keren.

Pada saat itu, kami mengira itulah arti belati.

Otak Kedua Harus Memahami Niat yang Belum Terucap

Kami berulang kali menanyakan apa yang paling penting dalam otak kedua.

Jawabannya akhirnya kami dapatkan ditemukan adalah pemahaman niat.

Alat informasi biasa biasanya dimulai dengan apa yang sudah dimasukkan pengguna. Jika pengguna menulis sebuah kalimat, ia dapat merevisinya. Jika pengguna mengajukan pertanyaan, ia dapat menjawab. Jika pengguna menyimpan artikel, ia dapat meringkasnya.

Namun banyak niat manusia yang tidak diungkapkan dengan jelas di awal. Kadang-kadang kita hanya mempunyai perasaan samar-samar bahwa sesuatu itu penting tanpa mengetahui apa yang benar-benar kita pedulikan. Kadang-kadang kita akan bertemu seseorang yang penting dan memikirkan banyak informasi, tetapi tidak tahu apa yang paling pantas untuk dikatakan. Terkadang kita mengetahui perasaan yang ingin kita ungkapkan tetapi tidak dapat menemukan kata-kata yang tepat.

Jika otak kedua dapat menggabungkan konteks pengguna saat ini dengan niat tak terucapkan ini, otak kedua akan melakukan lebih dari sekadar memproses informasi yang ada. Ia akan mulai berpartisipasi dalam proses di mana seseorang membentuk ekspresi atau penilaian.

Berdasarkan ide ini, kami merancang produk bernama Sayso pada pertengahan tahun.

Dengan menggunakan konteks orang tersebut saat ini, hal ini akan membantu mereka melihat apa yang akan mereka katakan selanjutnya. Kami tidak ingin AI menentukan niat sebenarnya dari pengguna terhadap mereka. Kami ingin ini menawarkan kemungkinan arah sehingga pengguna dapat mengenali apa yang sebenarnya ingin mereka ungkapkan.

Kebutuhan ini muncul dalam banyak situasi nyata. Sebelum bertemu orang penting atau memulai percakapan penting, orang sering kali kehabisan kata-kata. Masalahnya adalah mengetahui bagian mana dari sejumlah besar informasi yang paling penting pada saat itu.

Sayso mencoba memampatkan tujuan besar untuk memahami niat tersirat seseorang ke dalam satu tugas nyata: menggunakan konteks orang tersebut saat ini untuk mengungkap niat yang belum mereka ungkapkan.

Kami pikir kami akhirnya menemukan belati di dalam gagasan luas tentang otak kedua.

Kami Mengira “Kecil” Berarti “Tajam”

Di pertengahan tahun, kami beralih dari produk besar ke produk kecil, dan kami kecepatan pengembangan meningkat secara nyata.

Namun selama peralihan ini, pemahaman kita tentang keris masih terbatas pada bentuk luarnya.

Kami pikir memperkecil produk akan membuatnya menjadi sebuah belati. Kami pikir lebih sedikit fitur menjadikannya sebuah belati. Belakangan, kami juga salah mengartikan kebaruan dan kecepatan pengembangan sebagai ketajaman: jika suatu produk terasa baru, dapat dibuat dengan cepat, dan dapat menjangkau pengguna dengan cepat, hal tersebut tampaknya lebih mendekati jawaban yang tepat dibandingkan pisau Swiss Army yang telah kami buat.

Di pertengahan tahun, kami membangun Sayso dalam waktu yang sangat singkat dan memberikannya kepada pengguna beta.

Masukan mereka menunjukkan kepada kita bahwa beberapa orang benar-benar membutuhkan bantuan untuk mengekspresikan diri mereka sebelum pertemuan atau percakapan penting, dan bahwa mereka dapat memahami pentingnya menemukan niat dari konteks. Hal ini memberikan bukti awal bahwa masalah yang kami targetkan adalah nyata, bukan sekedar ide yang terdengar baru.

Tetapi produk itu sendiri tidak berhasil.

Demo AI tentang memahami niat mungkin hanya perlu memberikan hasil yang mengejutkan dalam beberapa contoh yang disiapkan dengan cermat. Produk nyata harus menunjukkan kepada pengguna konteks apa yang harus diberikan, membantu mereka memahami mengapa produk menawarkan saran tertentu, dan membiarkan mereka mengedit, memilih, atau menolak saran tersebut secara alami.

Antarmuka harus menginspirasi kepercayaan. Interaksi tersebut tidak boleh menimbulkan beban baru. Fitur-fitur tersebut harus mendukung pengguna melalui seluruh tugas. Pada saat yang sama, sistem tersebut harus dapat diandalkan dan tetap mudah dipelihara dan ditingkatkan.

Tak satu pun dari hal-hal ini, jika dilihat secara individual, berada di luar jangkauan kita. Kesulitannya adalah membuat semuanya cukup baik pada saat yang sama dalam jangka waktu terbatas.

Pengguna dapat mengidentifikasi masalah dengan cepat, namun kami tidak dapat menyelesaikannya dengan cepat dan baik. Terkadang kami menyelesaikan suatu fitur dengan mengorbankan pengalaman keseluruhan. Terkadang kami meningkatkan satu bagian dari pengalaman sekaligus membuat sistem yang mendasarinya lebih sulit dipertahankan. Terkadang kemampuan inti sudah dapat didemonstrasikan, namun pengguna masih belum dapat menyelesaikan perjalanan penuh dengan lancar.

Tes beta bukannya tidak berarti. Setidaknya hal ini memungkinkan kami untuk memastikan bahwa kebutuhan tersebut ada.

Tetapi adanya kebutuhan tidak berarti bahwa suatu produk berfungsi. Produk yang berfungsi tidak berarti pasar berhasil.

Karena kualitas implementasi berada di antara pengguna dan nilai inti, kami belum benar-benar menguji apakah Sayso dapat memberikan nilai tersebut secara konsisten, apalagi apakah cukup banyak orang yang ingin menggunakannya seiring berjalannya waktu.

Kami mungkin telah melihat masalah yang harus ditusuk oleh belati, namun kami masih kekurangan kemampuan untuk mengubah wawasan tersebut menjadi belati yang benar-benar dapat digunakan seseorang.

Mata Bisa Melihat, tetapi Tangan Belum Bisa Membuat

Setelah merilis Sayso, awalnya kami mengaitkan masalah tersebut dengan kecepatan iterasi yang tidak memadai. Pengguna telah memberi kami umpan balik, sehingga jawabannya sepertinya terus bergerak dalam langkah-langkah kecil dan mengubah produk lebih cepat.

Tetapi kami segera menemukan bahwa kecepatan bukanlah satu-satunya masalah.

Sebelum merilis produk, kami sudah mengetahui bahwa produk tersebut tidak bagus. Banyak masalah dalam masukan pengguna tidak melebihi penilaian kami sendiri. Yang kurang dari kita bukanlah mata yang bisa membedakan produk bagus dan jelek, tapi tangan yang bisa dengan cepat mengubah penilaian itu menjadi sebuah produk.

Mata sudah bisa melihat. Tangan belum bisa membuat.

Ini tidak berarti bahwa semua yang kami pelajari tentang produk di tahun 2024 salah.

Sepanjang tahun 2025, MagicGourd tetap online dan terpelihara. Fitur-fitur baru hadir lebih lambat, namun layanan yang ada tetap berjalan. Pada akhir tahun, MagicGourd memiliki sekitar 3.000 pengguna, dan tanggapan secara keseluruhan tetap positif. Kami tidak mengetahui adanya data pengguna yang hilang atau rusak sepanjang tahun.

Pada tahun 2024, kami telah mempelajari cara mengubah demo menjadi perangkat lunak yang dapat beroperasi seiring waktu: cara menangani sinkronisasi, privasi, kompatibilitas, dan kegagalan; bagaimana mempertahankan layanan yang diandalkan oleh pengguna sebenarnya; dan bagaimana bertanggung jawab atas data yang mungkin dikumpulkan seseorang selama bertahun-tahun.

Kemampuan tersebut tetap penting. Hal ini menjadikan MagicGourd lebih dari sekedar demonstrasi, dan memungkinkan kami untuk tetap bertanggung jawab kepada pengguna yang sudah ada bahkan ketika kecepatan fitur-fitur baru melambat.

Tetapi tahun 2025 memperlihatkan lapisan kemampuan lain.

Kami masih belum pandai mengubah kebutuhan menjadi definisi produk yang jelas. Kami tidak pandai menciptakan antarmuka dan alur interaksi yang halus dan alami dalam waktu singkat. Kami juga tidak dapat menyeimbangkan pengalaman, fungsionalitas, keandalan, dan pemeliharaan secara bersamaan.

Kami memiliki keahlian algoritmik dan kemampuan rekayasa sistem. Ketika sebuah ide muncul, kami dapat dengan cepat mengimplementasikan inti teknisnya. Namun teknologi yang berfungsi tidak berarti produk yang berfungsi. Kekuatan produk yang nyata berarti memadukan banyak penilaian yang membatasi satu sama lain menjadi sesuatu yang dirasakan pengguna secara sederhana, jelas, dan lengkap.

Saat memasuki paruh kedua tahun ini, kami akhirnya mengakui bahwa kemampuan produk kami belum dapat mendukung ambisi kami.

Pertama Pelajari Cara Mengasah Pisau

Kami mendefinisikan paruh kedua tahun ini sebagai periode untuk membangun kemampuan.

Keputusan ini sulit. Di penghujung paruh pertama, kami baru saja menginvestasikan banyak upaya untuk memahami mengapa kami harus menemui pelanggan lebih awal. Namun, pada paruh kedua, kami memutuskan untuk berhenti menampilkan setiap produk yang belum selesai secara terburu-buru di depan pengguna dan terlebih dahulu mempelajari cara membuat produk dengan baik.

Di permukaan, hal ini tampak seperti mundur dari pasar di dalam perusahaan. Namun masalah yang ingin kami selesaikan bukanlah masalah yang hanya bisa dijawab oleh pasar.

Pengguna dapat memberi tahu kami apakah suatu kebutuhan itu nyata, apakah produk tersebut menciptakan nilai, dan apakah mereka ingin terus menggunakannya. Namun jika kita menganggap antarmukanya tidak sempurna, sudah mengetahui bahwa alur interaksi tidak lengkap, atau mengetahui bahwa masalah keandalan akan mengaburkan nilai inti, memberikan produk kepada pengguna tidak akan menghasilkan informasi yang lebih berguna tentang pertanyaan utama.

Pasar seharusnya membantu kita menjawab pertanyaan yang tidak kita ketahui, bukan mengulangi jawaban yang sudah kita ketahui.

Jadi kami mulai berulang kali mempelajari produk yang benar-benar kami kagumi. Kami menguraikan struktur, desain visual, dan interaksinya, menanyakan mengapa setiap detail ditangani dengan cara tertentu. Melalui studi mendalam dan penerapan ulang, kami mengubah penilaian yang kami lihat menjadi sesuatu yang kami buat sendiri. Kami kemudian membandingkan perbedaannya dan mencoba lagi, hingga kami memahami mengapa produk unggulan ini terasa sederhana, alami, dan lengkap.

Studi mendalam bukan berarti meniru tampilan suatu produk atau mencari jawaban yang dapat kita peroleh tanpa perubahan. Ini lebih seperti praktik yang dilakukan seseorang untuk belajar melukis, musik, atau kaligrafi: pertama-tama latih mata untuk membedakannya, kemudian biarkan tangan perlahan-lahan mengejar ketinggalan, dan baru kemudian menerapkan kemampuan itu pada permasalahannya sendiri.

Kapabilitas produk mengandung banyak pengetahuan diam-diam seperti ini. Memahami sebuah ide, atau bahkan mengevaluasi produk orang lain secara akurat, tidak berarti kita sendiri yang memiliki kemampuan tersebut. Hanya dengan mengubah penilaian menjadi antarmuka, interaksi, dan sistem melalui pilihan konkret yang berulang-ulang, kemampuan tersebut dapat benar-benar menjadi bagian dari tim.

Hingga akhir tahun, kami masih belum bisa membuktikan bahwa kami mampu membangun produk unggulan secara konsisten. Namun di pertengahan tahun, yang bisa kami lakukan hanyalah samar-samar merasa bahwa “produk ini tidak bagus”. Pada akhirnya, kita dapat memecah penilaian tersebut menjadi pertanyaan-pertanyaan yang lebih spesifik: bagaimana informasi harus diorganisasikan, bagaimana suatu interaksi harus berkembang, bagaimana detail visual harus mendukung keseluruhan, dan bagaimana batasan sistem akan mempengaruhi pengalaman. Kita kemudian dapat melatih kemampuan ini satu per satu melalui dekomposisi, studi mendalam, implementasi ulang, dan pembangunan kembali.

Perubahan tersebut masih sebatas hasil praktik internal dan belum bisa menggantikan pengujian pengguna sebenarnya. Apa yang bisa kami katakan adalah bahwa kami sudah mulai membentuk cara berlatih yang lebih konkrit, dan jarak antara mata dan tangan kami sudah mulai menyempit.

Penggalangan Dana Bukan Hanya Tentang Uang

Melihat ke belakang, poin yang dibuat Kehan di awal tahun mulai terkonfirmasi, secara perlahan.

Menerima investasi memang penting, tetapi bukan hanya uang yang diberikan MiraclePlus kepada kami. Bimbingan dari mentor dan percakapan dengan rekan kerja tidak serta merta menghasilkan pengguna, pendapatan, atau produk yang sukses. Pada akhir tahun, saya tidak dapat mengatakan bahwa hubungan ini telah membuahkan hasil langsung. Namun metafora Peter telah memasuki cara kami mengevaluasi produk setiap hari.

Hal ini terus memaksa kami untuk memeriksa ulang produk kami. Setiap kali saya berpikir saya memahaminya, latihan selanjutnya menunjukkan bahwa saya hanya memahami satu bagian.

Pada awalnya, saya pikir itu berarti memecah otak kedua yang besar menjadi sesuatu yang lebih kecil. Belakangan saya pikir kecil, cepat, dan keren berarti tajam. Belakangan, saya menyadari bahwa belati asli tidak berfungsi hanya karena ukurannya yang kecil. Itu harus memusatkan pengalaman produk yang lengkap pada satu masalah tertentu.

Akselerator tidak membuat belati bagi kami, namun membantu kami melihat lebih cepat mengapa benda yang ada di tangan kami belum menjadi satu.

Artinya, penggalangan dana bukan hanya soal uang. Ini mungkin tidak memberikan jawaban langsung, tetapi dapat mengubah cara kita mengajukan pertanyaan, mengevaluasi diri, dan terus belajar.

Ketajaman Sejati Juga Membutuhkan Kelengkapan

Pada akhir tahun 2025, pemahaman saya tentang keris sudah berbeda dengan awal tahun.

Wawasan terhadap masalah pengguna adalah ujung pisaunya. Interaksi, antarmuka, dan pengalaman produk menjadi keunggulannya. Kelengkapan fungsional adalah badan bilahnya. Keandalan dan pemeliharaan seperti pegangan, memungkinkan seseorang untuk benar-benar memegang dan menggunakannya.

Satu titik tajam paling banyak bisa menjadi demo yang mengesankan. Itu belum menjadi belati yang bisa digunakan seseorang.

Kelengkapan tidak berarti memasukkan segalanya ke dalam produk. Pisau Swiss Army dapat menyelesaikan banyak masalah, namun mungkin tidak cukup mendalam untuk mengatasi salah satu masalah tersebut.

Kelengkapan sejati berarti menyelesaikan seluruh perjalanan yang dibutuhkan pengguna dengan satu nilai inti. Setiap bagian dari produk harus menunjukkan masalah yang sama dan mendukung bagian lainnya, daripada menggunakan lebih banyak fitur untuk menyembunyikan fakta bahwa masalah inti masih belum terpecahkan.

Pada tahun 2023, saya meninggalkan SenseTime dan terjun ke sungai berikutnya. Pada tahun 2024, kami membuat labu tersebut dan mulai memahami mengapa suatu produk harus berfungsi seiring waktu. Pada tahun 2025, kami ingin keajaiban itu akhirnya muncul, dan kami juga mencoba memecah otak kedua yang sangat besar itu menjadi sebuah belati.

Keajaiban belum muncul, dan Sayso belum menjadi produk yang berfungsi. Meskipun saat ini kami dapat melihat kebutuhannya, kami masih kekurangan kemampuan untuk membangunnya dengan cepat dan baik.

Namun sepanjang tahun ini, setidaknya kami dapat melihat secara lebih akurat kekurangan kami.

Pengejaran kami terhadap ketajaman tidak membuat kami mengabaikan kelengkapan, keandalan, atau tanggung jawab jangka panjang. Kami juga mulai memahami bahwa menemui pelanggan lebih awal tidak berarti memberi mereka produk yang kami tahu buruk, dan bahwa iterasi yang cepat tidak berarti mengejar kecepatan pengembangan saja.

Sampai hari ini, kami belum membuat belati yang sepenuhnya terbentuk.

Kami baru mulai mempelajari cara mengasahnya.

Ujung pisau saja bukanlah belati.

Prima di rilasciarlo, sapevo già che non era abbastanza buono.

La sua interfaccia mancava di rifinitura, le interazioni non sembravano ancora naturali e il flusso funzionale era incompleto. Abbiamo potuto vedere molti dei problemi senza attendere il feedback degli utenti. Ancora più preoccupante è il fatto che questi problemi non potevano essere separati l’uno dall’altro. L'interfaccia, l'esperienza utente, la completezza funzionale, l'affidabilità e la manutenibilità dovevano funzionare tutte contemporaneamente prima di poter formare un prodotto completo.

Ma avevamo appena trascorso mesi ad assorbire una serie di metodi di avvio: incontrare i clienti in anticipo, procedere a piccoli passi e iterare rapidamente. Quindi, anche se non eravamo soddisfatti del prodotto, credevamo comunque di doverlo rilasciare prima.

Gli utenti hanno subito sollevato molti problemi. Ne conoscevamo un numero considerevole prima del rilascio. Il loro feedback è diventato il punto di partenza per il cambiamento che abbiamo apportato nella seconda metà dell’anno.

Guardando indietro, quel beta test ha diviso il 2025 in due metà. Durante la prima metà abbiamo continuato a costruire MagicGourd, sperando di far finalmente apparire la sua magia. A metà anno, abbiamo estratto un'idea in Sayso, l'abbiamo sviluppata rapidamente e l'abbiamo presentata agli utenti. Nella seconda metà, invece di continuare a inseguire la velocità di rilascio, ci siamo concentrati sullo sviluppo delle capacità del nostro prodotto. Il punto di partenza di tutto questo è arrivato all’inizio dell’anno, quando abbiamo ricevuto investimenti da MiraclePlus e abbiamo aderito al suo acceleratore.

Alla fine dell’anno non avevamo ancora realizzato quel pugnale. Ma avevamo iniziato a capire: la punta di una lama da sola non è un pugnale.

Un'intervista a cui non avevo programmato di partecipare

All'inizio del 2025, non avevo intenzione di raccogliere fondi.

Nel 2024, avevamo dedicato la maggior parte del nostro tempo a sviluppare MagicGourd e a rilasciare 27 versioni. I nostri limitati tentativi di raccolta fondi non avevano portato a nulla e il prodotto era ancora lontano dal “vero secondo cervello” che avevamo immaginato. Ma mi è piaciuto moltissimo il processo di costruzione.

Pensavo che avremmo potuto continuare su scala molto piccola, andando avanti un passo alla volta senza affrettarci a investire.

Kehan ha cambiato idea. Mi ha detto che la raccolta fondi non era necessariamente solo una questione di soldi. L'acceleratore MiraclePlus, i suoi mentori e i suoi ex-alunni potrebbero aiutarci anche per un periodo molto più lungo.

A quel punto il termine per la presentazione delle domande era già scaduto. Ma non volevo che il consiglio di Kehan andasse sprecato, quindi ho presentato comunque la domanda, descrivendo brevemente come pensavo ad un vero secondo cervello.

Questa intervista ha avuto luogo presso l'ufficio MiraclePlus a Pechino. Mentre aspettavo, ho visto diversi suggerimenti per l'intervista su uno schermo: le risposte dovrebbero essere semplici, dirette e veritiere.

Nell'intervista di un anno prima, avevo inconsciamente cercato le risposte che gli investitori volevano sentire. Quando mettevano ripetutamente in discussione le nostre idee, temevo che le mie risposte non fossero abbastanza buone. Poiché rispettavo le persone al tavolo, potevo persino iniziare a dubitare del mio stesso giudizio.

Questa volta non avevo tanta fretta.

Dopo un anno intero di sviluppo nel 2024, eravamo ancora in acqua, ma non più in difficoltà come avevamo subito dopo esserci tuffati. Non ho provato a dimostrare che dovevo avere ragione e non avevo preparato risposte molto precise. Ho semplicemente detto quello che pensavo sinceramente.

Il dottor Lu Qi mi ha chiesto cosa pensavo di SenseTime. Dissi che, innanzitutto, ero profondamente grato all'azienda, perché lì avevo vissuto un periodo cruciale di crescita e trasformazione. Intorno all’arrivo di ChatGPT, SenseTime potrebbe essere stata leggermente lenta nel rispondere perché una grande nave è difficile da virare. Ma entro il 2025, potevo vedere che le cose sarebbero cambiate rapidamente e credevo che stesse arrivando un’era migliore per SenseTime.

Poi mi ha chiesto cosa pensavo di DeepSeek. La mia risposta è stata una sola parola: costo. Non ho approfondito in quel momento. Credevo semplicemente che i costi avrebbero influenzato direttamente la portata con cui una tecnologia avrebbe potuto entrare nel mondo reale.

Il colloquio si è svolto più agevolmente di quanto mi aspettassi. Forse perché non ero più alla disperata ricerca di un risultato particolare, è diventato più facile parlare in modo semplice.

Più tardi, MiraclePlus ha investito in noi e ci siamo uniti all'acceleratore.

Volevamo che la magia apparisse finalmente

Se l'obiettivo nel 2024 era stato quello di realizzare prima la zucca, all'inizio del 2025 volevamo che la sua magia apparisse finalmente.

Nel 2024 eravamo rimasti fortemente concentrati e abbiamo completato la versione 0.27 di MagicGourd. Aiutava le persone a contrassegnare ciò che le muoveva su pagine web, PDF online e video, a registrare i pensieri che emergevano e a preservarli tutti nel tempo.

Ma era ancora più vicino a un contenitore. Potrebbe raccogliere e gestire i record di una persona, ma non potrebbe capirli veramente, tanto meno aiutare qualcuno a scoprire pensieri rimasti incompiuti.

Quindi, quando abbiamo pianificato il 2025, ci siamo posti un obiettivo molto più ampio. Non saremmo più soddisfatti di aggiungere funzionalità. Volevamo fare un vero passo avanti verso il vero secondo cervello che avevamo immaginato.

Volevamo comprendere le registrazioni a lungo termine di una persona, trovare connessioni sparse in tempi diversi e diversi contenuti, capire cosa stava pensando l'utente in quel momento e riconoscere le intenzioni che non aveva ancora espresso chiaramente.

L'obiettivo era entusiasmante. Era anche ben oltre la portata che potevamo gestire in quel momento.

Durante la prima metà dell'anno abbiamo dedicato enormi sforzi allo sviluppo. Il problema non era la mancanza di duro lavoro, ma il numero di cose che dovevano essere risolte in una volta. Ogni passo avanti esponeva nuove domande. L’ambito ha continuato ad espandersi, mentre il nostro ritmo di sviluppo ha continuato a rallentare. Sono passati sei mesi e non avevamo ancora presentato agli utenti il valore più importante.

Dopo essere entrati nell'acceleratore MiraclePlus, continuavamo a sentire una parola: sharp.

Il mio mentore nell'acceleratore, Peter, ci ha ripetutamente detto che una startup dovrebbe produrre un pugnale, non un coltellino svizzero.

Verso la fine della prima metà dell'anno abbiamo cominciato a pensare che il problema fosse che il prodotto fosse diventato troppo grande. Se non potessimo costruire un vero secondo cervello tutto in una volta, dovremmo estrarre il suo elemento più importante e trasformarlo in un prodotto piccolo, veloce e interessante.

All'epoca, pensavamo che questo significasse un pugnale.

Un secondo cervello dovrebbe comprendere le intenzioni non ancora pronunciate

Ci siamo chiesti ripetutamente cosa contasse di più in un secondo cervello.

La risposta è che noi alla fine si scoprì che era comprensiva dell'intenzione.

Un normale strumento informativo inizia solitamente con ciò che l'utente ha già inserito. Se un utente scrive una frase, può rivederla. Se l'utente fa una domanda, può rispondere. Se l'utente salva un articolo, può riassumerlo.

Ma molte intenzioni umane all’inizio non sono chiaramente espresse. A volte abbiamo solo la vaga sensazione che qualcosa sia importante senza sapere cosa ci sta veramente a cuore. A volte stiamo per incontrare una persona importante e abbiamo molte informazioni in mente, ma non sappiamo cosa vale la pena dire. A volte conosciamo il sentimento che vogliamo esprimere ma non riusciamo a trovare le parole giuste.

Se un secondo cervello potesse combinare il contesto attuale dell’utente con queste intenzioni inespresse, farebbe di più che elaborare le informazioni esistenti. Inizierebbe a partecipare al processo attraverso il quale una persona forma un'espressione o un giudizio.

Sulla base di questa idea, a metà anno abbiamo concepito un prodotto chiamato Sayso.

Utilizzando il contesto attuale della persona, la aiuterebbe a vedere cosa potrebbe dire dopo. Non volevamo che l’intelligenza artificiale decidesse le vere intenzioni di un utente nei suoi confronti. Volevamo che offrisse possibili indicazioni da cui l'utente potesse riconoscere ciò che realmente voleva esprimere.

Questa esigenza si manifesta in molte situazioni reali. Prima di incontrare una persona importante o di iniziare una conversazione importante, spesso alle persone non mancano le cose da dire. Il problema è sapere quale parte di una grande quantità di informazioni conta di più in quel momento.

Sayso ha cercato di comprimere il grande obiettivo di comprendere le intenzioni implicite di una persona in un compito concreto: utilizzare il contesto attuale della persona per scoprire intenzioni che non aveva ancora espresso.

Pensavamo di aver finalmente trovato un pugnale all'interno della vasta idea di un secondo cervello.

Abbiamo scambiato “piccolo” per “affilato”

A metà anno, siamo passati da un prodotto grande a uno piccolo, e la nostra velocità di sviluppo è aumentata notevolmente.

Ma durante questo cambiamento, la nostra comprensione di un pugnale era ancora limitata alla sua forma esteriore.

Pensavamo che rimpicciolire il prodotto lo rendesse un pugnale. Pensavamo che meno caratteristiche lo rendessero un pugnale. In seguito, abbiamo anche scambiato la novità e la velocità di sviluppo con la nitidezza: se un prodotto sembrava nuovo, poteva essere costruito rapidamente e poteva raggiungere rapidamente gli utenti, sembrava più vicino alla risposta giusta rispetto al coltellino svizzero che stavamo costruendo.

A metà anno, abbiamo costruito Sayso in brevissimo tempo e lo abbiamo dato agli utenti beta.

Il loro feedback ci ha mostrato che alcune persone avevano davvero bisogno di aiuto per esprimersi prima di un incontro o di una conversazione importante e che potevano comprendere l’importanza di scoprire le intenzioni dal contesto. Ciò offrì la prima prova che il problema che stavamo affrontando era reale, piuttosto che semplicemente un'idea che sembrava nuova.

Ma il prodotto in sé non funzionava.

Una dimostrazione di intelligenza artificiale sulla comprensione delle intenzioni potrebbe dover produrre un risultato sorprendente solo con alcuni esempi attentamente preparati. Un prodotto reale doveva mostrare agli utenti quale contesto fornire, aiutarli a capire perché offriva suggerimenti particolari e consentire loro di modificare, scegliere o rifiutare in modo naturale tali suggerimenti.

L'interfaccia doveva ispirare fiducia. Le interazioni non potrebbero creare un nuovo onere. Le funzionalità dovevano supportare l'utente durante l'intera attività. Allo stesso tempo, il sistema doveva essere affidabile e facile da manutenere e migliorare.

Nessuna di queste cose, prese singolarmente, era necessariamente al di là delle nostre capacità. La difficoltà stava nel renderli tutti sufficientemente buoni contemporaneamente entro un periodo limitato.

Gli utenti potevano identificare rapidamente i problemi, ma non riuscivamo a risolverli rapidamente e bene. A volte completavamo una funzionalità a scapito dell'esperienza complessiva. A volte abbiamo migliorato una parte dell'esperienza rendendo al contempo più difficile la manutenzione del sistema sottostante. A volte le funzionalità principali potrebbero già essere dimostrate, ma l'utente non è ancora in grado di completare un viaggio completo senza problemi.

Il beta test non è stato privo di significato. Ci ha almeno permesso di confermare che il bisogno esisteva.

Ma l'esistenza di un bisogno non significa che un prodotto funzioni. Un prodotto funzionante non significa che un mercato funziona.

Poiché la qualità dell'implementazione si frapponeva tra gli utenti e il valore fondamentale, non avevamo veramente testato se Sayso fosse in grado di fornire quel valore in modo coerente, tanto meno se un numero sufficiente di persone volesse utilizzarlo nel tempo.

Potremmo aver notato il problema che il pugnale dovrebbe perforare, ma ci mancava ancora la capacità di trasformare questa intuizione in un pugnale che qualcuno potesse effettivamente usare.

L'occhio poteva vedere, ma la mano non poteva ancora creare

Dopo aver rilasciato Sayso, inizialmente abbiamo attribuito il problema a una velocità di iterazione insufficiente. Gli utenti ci avevano fornito feedback, quindi la risposta sembrava essere continuare a muoversi a piccoli passi e cambiare il prodotto più velocemente.

Ma presto abbiamo scoperto che la velocità non era l'unico problema.

Prima di rilasciare il prodotto, sapevamo già che non era buono. Molti dei problemi riscontrati nel feedback degli utenti non hanno superato il nostro giudizio. Ciò che ci mancava non era l'occhio per distinguere un buon prodotto da uno cattivo, ma la mano che trasformasse velocemente quel giudizio in un prodotto.

L'occhio sapeva già vedere. La mano non poteva ancora fare.

Ciò non significa che tutto ciò che avevamo imparato sui prodotti nel 2024 fosse sbagliato.

Per tutto il 2025, MagicGourd è rimasta online e mantenuta. Le nuove funzionalità sono arrivate più lentamente, ma il servizio esistente ha continuato a funzionare. Alla fine dell’anno MagicGourd contava circa 3.000 utenti e il feedback è rimasto nel complesso positivo. Non eravamo a conoscenza di dati utente persi o danneggiati durante l'anno.

Nel 2024 avevamo imparato come trasformare una demo in un software in grado di funzionare nel tempo: come gestire la sincronizzazione, la privacy, la compatibilità e i guasti; come mantenere un servizio da cui dipendevano gli utenti reali; e come assumersi la responsabilità dei dati che una persona potrebbe accumulare nel corso di molti anni.

Queste capacità erano ancora importanti. Hanno reso MagicGourd più di una semplice dimostrazione e ci hanno permesso di rimanere responsabili nei confronti degli utenti esistenti anche quando il ritmo delle nuove funzionalità rallentava.

Ma il 2025 ha messo in luce un altro livello di capacità.

Non eravamo ancora bravi a trasformare un bisogno in una chiara definizione di prodotto. Non eravamo bravi a creare un'interfaccia raffinata e naturale e un flusso di interazione in breve tempo. Né potremmo bilanciare in modo affidabile esperienza, funzionalità, affidabilità e manutenibilità allo stesso tempo.

Avevamo competenze algoritmiche e capacità di ingegneria dei sistemi. Quando appariva un'idea, potevamo implementarne rapidamente il nucleo tecnico. Ma una tecnologia funzionante non significava un prodotto funzionante. La vera forza del prodotto significava comprimere molti giudizi che si vincolavano a vicenda in qualcosa che l'utente sperimentava come semplice, chiaro e completo.

Quando siamo entrati nella seconda metà dell'anno, abbiamo finalmente ammesso che le nostre capacità di prodotto non potevano ancora sostenere la nostra ambizione.

Prima impara come affilare la lama

Abbiamo definito la seconda metà dell'anno come un periodo di sviluppo delle capacità.

La decisione è stata difficile. Verso la fine del primo semestre avevamo investito moltissimi sforzi per capire perché avremmo dovuto incontrare i clienti in anticipo. Nella seconda metà, tuttavia, abbiamo deciso di smettere di presentare affrettatamente ogni prodotto non finito davanti agli utenti e di imparare prima a costruire bene i prodotti.

In superficie, sembrava come ritirarsi dal mercato e rientrare all'interno dell'azienda. Ma il problema che volevamo risolvere non era un problema a cui solo il mercato potesse rispondere.

Gli utenti potevano dirci se un bisogno era reale, se il prodotto creava valore e se volevano continuare a utilizzarlo. Ma se anche considerassimo l’interfaccia non rifinita, sapessimo già che un flusso di interazione era incompleto, o sapessimo che i problemi di affidabilità avrebbero oscurato il valore fondamentale, dare il prodotto agli utenti non produrrebbe informazioni più utili sulla domanda centrale.

Il mercato dovrebbe aiutarci a rispondere a domande sconosciute, non a ripetere risposte che già conoscevamo.

Così abbiamo iniziato a studiare ripetutamente i prodotti che ammiravamo sinceramente. Ne abbiamo analizzato la struttura, il design visivo e le interazioni, chiedendoci perché ogni dettaglio fosse stato gestito in un modo particolare. Attraverso studi approfonditi e reimplementazioni, abbiamo trasformato i giudizi che potevamo vedere in cose che avevamo creato noi stessi. Abbiamo quindi confrontato le differenze e riprovato, finché non abbiamo capito perché questi eccellenti prodotti sembravano semplici, naturali e completi.

Lo studio approfondito non consisteva nel copiare la superficie di un prodotto o nel cercare una risposta che potessimo portare via immutata. Era più simile alla pratica attraverso la quale qualcuno impara la pittura, la musica o la calligrafia: prima allena l’occhio a distinguere, poi lascia che la mano raggiunga gradualmente il livello, e solo dopo applica quell’abilità a un proprio problema.

La capacità del prodotto contiene una grande quantità di conoscenza tacita come questa. Comprendere un’idea, o anche valutare accuratamente il prodotto di qualcun altro, non significa che ne possediamo noi stessi la capacità. Solo trasformando i giudizi in interfacce, interazioni e sistemi attraverso scelte concrete e ripetute, quella capacità potrebbe diventare veramente parte della squadra.

Alla fine dell’anno non eravamo ancora in grado di dimostrare di essere in grado di costruire prodotti eccellenti in modo coerente. Ma a metà anno, tutto ciò che potevamo fare era vagamente sentire che “questo prodotto non è buono”. Alla fine, potremmo suddividere quel giudizio in domande più specifiche: come dovrebbero essere organizzate le informazioni, come dovrebbe progredire un’interazione, come i dettagli visivi dovrebbero supportare il tutto e come i vincoli del sistema influenzerebbero l’esperienza. Potremmo quindi allenare queste abilità una per una attraverso la scomposizione, lo studio approfondito, la reimplementazione e la ricostruzione.

Questi cambiamenti erano ancora solo il risultato della pratica interna e non potevano sostituire i test degli utenti reali. Quello che potremmo dire è che abbiamo iniziato a creare un modo più concreto di praticare e che la distanza tra i nostri occhi e le nostre mani ha cominciato a ridursi.

La raccolta fondi non è solo una questione di soldi

Guardando indietro, il punto sottolineato da Kehan all'inizio dell'anno si stava lentamente confermando.

Ricevere investimenti era importante, ma il denaro non era tutto ciò che MiraclePlus ci dava. La guida dei mentori e le conversazioni con i colleghi non si trasformerebbero necessariamente immediatamente in utenti, entrate o in un prodotto di successo. Alla fine dell’anno non potevo dire che queste relazioni avessero prodotto risultati diretti. Ma la metafora del pugnale di Peter era già entrata nel modo in cui valutavamo i prodotti ogni giorno.

Continuava a costringerci a riesaminare i nostri prodotti. Ogni volta che pensavo di averlo capito, la pratica successiva mi ha dimostrato che ne avevo capito solo una parte.

All'inizio pensavo che significasse spezzare il vasto secondo cervello in qualcosa di più piccolo. Più tardi, ho pensato che piccolo, veloce e bello significasse acuto. Più tardi ancora mi resi conto che un vero pugnale non funzionava solo perché era piccolo. Doveva concentrare un'esperienza di prodotto completa su un problema specifico.

L'acceleratore non ha creato la daga per noi, ma ci ha aiutato a capire prima perché la cosa nelle nostre mani non lo era ancora.

Questo significa dire che la raccolta fondi non è solo una questione di soldi. Potrebbe non fornire una risposta immediata, ma può cambiare il modo in cui poniamo domande, valutiamo noi stessi e continuiamo ad apprendere.

Essere davvero affilati richiede anche completezza

Entro la fine del 2025, la mia comprensione di un pugnale era diversa da quella che era all'inizio dell'anno.

L'intuizione del problema dell'utente era la punta della lama. L'interazione, l'interfaccia e l'esperienza del prodotto hanno costituito il vantaggio. La completezza funzionale era il corpo della lama. Affidabilità e manutenibilità erano come la maniglia, che permetteva a qualcuno di impugnarla e usarla davvero.

Un singolo punto acuto potrebbe al massimo diventare una dimostrazione impressionante. Non era ancora un pugnale che qualcuno potesse effettivamente usare.

Completezza non significava mettere tutto nel prodotto. Un coltellino svizzero può risolvere molti problemi, ma potrebbe non approfondire nessuno di essi.

La vera completezza significava completare l’intero percorso di cui l’utente aveva bisogno attorno a un valore fondamentale. Ogni parte del prodotto doveva puntare allo stesso problema e supportare le altre parti, invece di utilizzare più funzionalità per nascondere il fatto che il problema principale rimaneva irrisolto.

Nel 2023 ho lasciato SenseTime e mi sono tuffato nel fiume successivo. Nel 2024 abbiamo realizzato la zucca e abbiamo iniziato a capire perché un prodotto dovesse funzionare nel tempo. Nel 2025, volevamo che la magia apparisse finalmente e abbiamo anche provato a ridurre l'enorme secondo cervello in un pugnale.

La magia non era ancora apparsa e Sayso non era ancora diventata un prodotto funzionante. Anche se ora ne vedevamo la necessità, ci mancava ancora la capacità di costruirlo rapidamente e bene.

Ma nel corso dell'anno, siamo almeno arrivati a vedere con maggiore precisione ciò che ci mancava.

La nostra ricerca della nitidezza non ci ha fatto abbandonare la completezza, l’affidabilità o la responsabilità a lungo termine. Stavamo anche iniziando a capire che incontrare i clienti in anticipo non significava offrire loro un prodotto che già sapevamo essere scadente, e che un'iterazione rapida non significava solo perseguire la velocità di sviluppo.

A oggi, non abbiamo ancora realizzato quel pugnale completamente formato.

Abbiamo solo iniziato a imparare come affilarlo.

Una punta della lama da sola non è un pugnale.

リリースする前から、それが十分ではないことはわかっていました。

そのインターフェイスは洗練されておらず、インタラクションはまだ自然に感じられず、機能フローは不完全でした。ユーザーからのフィードバックを待たずに多くの問題を確認することができました。さらに厄介なことに、これらの問題は互いに切り離すことができませんでした。完全な製品を形成するには、インターフェイス、ユーザー エクスペリエンス、機能の完全性、信頼性、保守性がすべて同時に機能する必要がありました。

しかし、私たちは、顧客に早く会い、小さなステップで進み、迅速に反復するという一連のスタートアップ方法を吸収するのに数か月を費やしたところです。そのため、製品に不満はありましたが、それでも最初にリリースする必要があると信じていました。

ユーザーはすぐに多くの問題を提起しました。私たちはリリース前にそれらのかなりの数について知っていました。彼らのフィードバックは、私たちが今年下半期に行った変更の出発点となりました。

振り返ってみると、あのベータ テストは 2025 年を 2 つの半分に分けました。前半は、MagicGourd の魔法がついに現れることを期待して構築を続けました。今年の半ばに、私たちは 1 つのアイデアを Sayso に抽出し、迅速に構築してユーザーの前に発表しました。後半では、リリース速度を追い続けるのではなく、製品機能の構築に目を向けました。これらすべての出発点は、私たちが MiraclePlus から投資を受け、そのアクセラレータに参加した年の初めに起こりました。

年末までに、私たちはまだその短剣を作成していませんでした。しかし、私たちは理解し始めていました。チップだけでは短剣ではありません。

参加する予定はなかったインタビュー

2025 年の初めには、資金を集める計画はありませんでした。

2024 年、私たちは MagicGourd の構築にほとんどの時間を費やし、27 のバージョンをリリースしました。私たちの限られた資金調達の試みは何の成果も得られず、その製品は私たちが思い描いていた「真の第二の脳」からはまだ程遠いものでした。しかし、私はそれを構築するプロセスを深く楽しみました。

投資を急ぐことなく、非常に小規模で継続して、一度に一歩ずつ前進できると思いました。

Kehan は私の考えを変えました。彼は、募金活動は必ずしもお金だけが目的ではないと私に言いました。 MiraclePlus アクセラレーター、その指導者、卒業生も、さらに長期間にわたって私たちを助けてくれるでしょう。

その時点で、申請期限はすでに過ぎていました。しかし、Kehan の推薦を無駄にしたくなかったので、真の第 2 の脳について私がどのように考えているかを簡単に説明して、とにかく応募しました。

このインタビューは、北京の MiraclePlus オフィスで行われました。待っている間、画面にいくつかのインタビューに関する提案が表示されました。答えはシンプル、直接的、真実である必要があります。

1 年前のインタビューでは、私は無意識のうちに投資家が聞きたい答えを探していました。彼らが私たちのアイデアに繰り返し異議を唱えたとき、私は自分の答えが十分ではないのではないかと心配しました。私はテーブルの向かい側の人々を尊重していたので、自分の判断を疑い始めることさえありました。

今回は、それほど急いでいませんでした。

2024 年に丸 1 年間の開発を行った後、私たちはまだ水の中にいましたが、飛び込んだ直後のように苦労することはもうありませんでした。私は自分が正しいはずであることを証明しようとしたわけではありませんし、非常に洗練された答えを準備していませんでした。ただ純粋に思ったことを言っただけです。

Lu Qi 博士は、SenseTime についてどう思うかと尋ねました。私はまず、会社に深く感謝していると言いました。なぜなら、私はそこで成長と変革の重要な時期を経験したからです。ChatGPT の登場前後、大型船は方向転換が難しいように、SenseTime の反応も少し遅かったかもしれません。しかし 2025 年には急速な変化が見え、SenseTime により良い時代が来ると信じていました。

次に彼は、DeepSeek についてどう思うかと尋ねました。私の答えは一言、「コスト」でした。その時は詳しくは説明しませんでした。私は単に、コストがテクノロジーを現実世界に導入できる規模に直接影響すると信じていました。

面接は予想していたよりもスムーズに進みました。特定の結果を求めなくなったせいか、シンプルに話しやすくなりました。

その後、MiraclePlus が投資し、アクセラレーターに加わりました。

ついに魔法が現れることを望んでいた

2024 年の目標が最初にひょうたんを作ることであったなら、2025 年の初めにはその魔法がついに現れることを望みました。

2024 年、私たちは焦点を絞って MagicGourd バージョン 0.27 を完成させました。これは、ウェブページ、オンライン PDF、動画の中で心を動かされた箇所をマークし、浮かんだ考えを記録し、そのすべてを長期にわたって保存できる製品でした。

しかし、それはまだコンテナに近かったのです。個人の記録を収集して管理することはできますが、それを真に理解することはできず、ましてや誰かが未完成のままの考えを発見するのに役立つことはできません。

したがって、2025 年の計画を立てたとき、私たちはさらに大きな目標を設定しました。機能を追加するだけでは満足できなくなります。私たちは、私たちが想像していた真の第二の脳に向けて本当の一歩を踏み出したかったのです。

私たちは、人の長期的な記録を理解し、さまざまな時代やさまざまなコンテンツに点在するつながりを見つけ、その瞬間にユーザーが考えていることを理解し、ユーザーがまだ明確に表現していなかった意図を認識したいと考えていました。

その目標は刺激的でした。それはまた、当時私たちが管理できる範囲をはるかに超えていました。

今年の前半、私たちは開発に多大な労力を費やしました。問題は勤勉さが足りないことではなく、一度に解決しなければならないことがたくさんあったことです。一歩前進するたびに、さらに多くの疑問が明らかになりました。開発のペースは遅くなり続けましたが、範囲は拡大し続けました。半年が経過しましたが、私たちはまだ最も重要な価値をユーザーの前に置いていませんでした。

MiraclePlus のアクセラレーターに入ってから、私たちは「sharp」という言葉を繰り返し耳にしました。

アクセラレータの私の指導者である Peter は、スタートアップはスイスアーミーナイフではなく短剣を作るべきだと繰り返し言いました。

今年の前半は、閉じると、問題は製品が大きくなりすぎたことにあると考え始めました。真の第 2 の脳を一度に構築できない場合は、その最も重要な要素を抽出して、小さく、速く、クールな製品に変える必要があります。

当時、私たちは短剣の意味するものだと考えていました。

第二の脳は、まだ語られていない意図を理解すべきだ

私たちは、第 2 の脳で最も重要なことは何かと繰り返し問いました。

最終的に見つけた答えは、理解することでした意図.

通常の情報ツールは通常、ユーザーがすでに入力した内容から始まります。ユーザーが文章を書いたら、修正することができます。ユーザーが質問すると、答えることができます。ユーザーが記事を保存すると、その記事を要約することができます。

しかし、人間の意図の多くは、最初は明確に表現されていません。私たちは、自分が本当に大切にしていることが何かを知らずに、何かが重要であるという漠然とした感覚しか持たないことがあります。大切な人に会おうとしていて、たくさんの情報を頭の中に持っているのに、何を言うのが最も価値があるのかわからない場合があります。表現したい感情はわかっていても、適切な言葉が見つからないことがあります。

第二の脳がユーザーの現在の状況とこれらの暗黙の意図を組み合わせることができれば、既存の情報を処理する以上のことができるでしょう。それは、人が表現や判断を形成するプロセスに参加し始めることになります。

このアイデアに基づいて、私たちは今年半ばに Sayso という製品を考案しました。

人の現在のコンテキストを使用することで、彼らが次に何を言うかを理解するのに役立ちます。私たちは、AI にユーザーの真の意図を判断してほしくありませんでした。ユーザーが実際に表現したいことを認識できるような方向性を提供できるようにしたいと考えました。

このニーズは多くの実際の状況で現れます。重要な人に会う前、または重要な会話を始める前に、人々は言うべきことが不足することがよくあります。問題は、その瞬間に大量の情報のどの部分が最も重要かを知ることです。

Sayso は、人の暗黙の意図を理解するという大きな目標を 1 つの具体的なタスクに圧縮しようとしました。つまり、その人の現在の状況を使用して、その人がまだ表現していない意図を明らかにすることです。

私たちは、第二の脳という広大なアイデアの中についに短剣を見つけたと思いました。

私たちは「小さい」を「シャープ」

今年の半ばに大型製品から小型製品へ移行し、開発スピードが目に見えて上がりました。

しかし、この変化の間、私たちの短剣に対する理解は依然としてその外観形状に限定されていました。

製品を小さくすれば短剣になると考えました。機能を減らせば短剣になると考えました。その後は、目新しさや開発速度まで鋭さと取り違えました。新しく見え、素早く作れ、すぐにユーザーへ届けられる製品なら、これまで作っていたスイスアーミーナイフより正解に近いように思えたのです。

今年の半ばに、私たちは Sayso を非常に短期間で構築し、ベータ ユーザーに提供しました。

彼らのフィードバックは、一部の人々が以前に自分自身を表現するのに本当に助けを必要としていたことを私たちに示しました。重要な会議や会話であり、文脈から意図を発見することの価値を理解できたということです。これは、私たちがターゲットとしていた問題が、単なる斬新に聞こえるアイデアではなく、現実のものであるという初期の証拠を提供しました。

しかし、製品自体は機能しませんでした。意図を理解するための

意図理解の AI デモなら、入念に用意したいくつかの例で驚く結果を出すだけで十分かもしれません。しかし実際の製品は、どのようなコンテキストを与えるべきかを示し、なぜその提案が出たのかを理解できるようにし、提案を自然に編集、選択、拒否できるようにする必要がありました。

インターフェースは信頼を呼び起こす必要がありました。相互作用によって新たな負担が生じることはありません。機能はタスク全体を通じてユーザーをサポートする必要がありました。同時に、システムは信頼性が高く、保守と改善が容易である必要があります。

これらのことはどれも、個別に考えても、必ずしも私たちを超えたものではありませんでした。難しかったのは、限られた期間内ですべてを同時に十分に優れたものにすることでした。

ユーザーはすぐに問題を見つけられましたが、私たちはそれを速く、しかも良く解決することができませんでした。全体の体験を犠牲にして機能を完成させることもあれば、体験の一部を改善する代わりに基盤システムを保守しにくくすることもありました。中核となる能力をすでに実演できても、ユーザーが一連の操作を最後まで滑らかに完了できないこともありました。

ベータ テストは無意味ではありませんでした。これにより、少なくともニーズが存在することを確認できました。

しかし、ニーズの存在は製品が機能することを意味するものではありません。製品が機能するということは、市場が機能するという意味ではありません。

実装の品質はユーザーと核となる価値との間にあったため、Sayso がその価値を一貫して提供できるかどうか、ましてや長期にわたって十分な数の人々がそれを使用したいと思うかどうかを実際にはテストしていませんでした。

短剣が突き刺すべき問題は見えていたかもしれませんが、その洞察を誰かが実際に使用できる短剣に変える能力がまだ不足していました。

目には見えていても、手ではまだ作れなかった

Sayso をリリースした後、私たちは当初、この問題の原因は反復速度の不十分さにあると考えていました。ユーザーからフィードバックが寄せられていたため、解決策は、小さなステップで継続して製品をより速く変更することであるように見えました。

しかし、速度だけが問題ではないことがすぐにわかりました。

製品をリリースする前から、それが良くないことはわかっていました。ユーザーからのフィードバックに含まれる問題の多くは、当社独自の判断を超えるものではありませんでした。私たちに欠けていたのは、良品と不良品を見極める目ではなく、その判断を素早く製品に変える手でした。

目はすでに見えていました。その手はまだ作ることができませんでした。

これは、2024 年に製品について学んだすべてが間違っていたという意味ではありません。

2025 年を通じて、MagicGourd はオンラインのままで維持されました。新しい機能の到着はさらに遅くなりましたが、既存のサービスは引き続き実行されました。年末までに、MagicGourd のユーザーは約 3,000 名となり、フィードバックは全体的に好意的なままでした。年間を通じてユーザー データの紛失や破損は確認されていませんでした。

2024 年、私たちはデモを時間の中で動き続けるソフトウェアへ変える方法を学びました。同期、プライバシー、互換性、障害をどう扱うか。実際のユーザーが頼るサービスをどう維持するか。そして、一人の人が何年もかけて蓄積するデータにどう責任を持つかです。

こうした能力は今も重要でした。それが MagicGourd を単なるデモ以上のものにし、新機能の追加が遅くなっても、既存のユーザーに対する責任を果たし続けられるようにしたのです。

しかし、2025 年には、さらなる機能の層が明らかになりました。

私たちは、ニーズを明確な製品定義に変えることがまだ上手ではありませんでした。私たちは、洗練された自然なインターフェイスとインタラクション フローを短時間で作成するのが苦手でした。また、エクスペリエンス、機能性、信頼性、保守性のバランスを同時に確実にとることもできません。

私たちはアルゴリズムの専門知識とシステムエンジニアリングの能力を持っていました。アイデアが現れたら、その技術的コアをすぐに実装できました。しかし、実用的な技術は実用的な製品を意味するものではありませんでした。本当の製品の強みとは、互いに制約し合う多くの判断を、ユーザーがシンプル、明確、完全なものとして体験できるものに圧縮することを意味しました。

今年の下半期に入ったとき、私たちは最終的に、当社の製品能力がまだ当社の目標をサポートできないことを認めました。

まずは刃の研ぎ方を学びましょう

私たちは今年の下半期を能力を構築する期間と定義しました。

決断は困難でした。上半期後半、私たちは顧客に早く会う必要がある理由を理解するために多大な労力を費やしたばかりでした。しかし、後半では、未完成の製品をすべてユーザーの前で急ぐのをやめ、まず製品を適切に構築する方法を学ぶことにしました。

表面的には、これは市場から社内に撤退するように見えました。しかし、私たちが解決したいと思っていた問題は、市場だけが答えられる問題ではありませんでした。

ユーザーは、ニーズが本物かどうか、製品が価値を生み出しているかどうか、そしてそれを使い続けたいかどうかを教えてくれました。しかし、たとえ私たちがインターフェイスが洗練されていないと考えていたとしても、インタラクション フローが不完全であることをすでに知っていたとしても、あるいは信頼性の問題が核心的な価値を曖昧にすることを知っていたとしても、ユーザーに製品を提供しても、中心となる質問についてより有益な情報は得られません。

市場は、私たちがすでに知っている答えを繰り返すのではなく、未知の質問に答えるのに役立つはずです。

そこで、私たちは心から賞賛する製品を繰り返し研究し始めました。私たちはその構造、ビジュアルデザイン、インタラクションを分析し、あらゆる細部がなぜ特定の方法で処理されているのかを尋ねました。綿密な研究と再実装を通じて、私たちは目に見えた判断を自分たちで作ったものに変えました。そして、なぜこれらの優れた製品がシンプルで自然で完成度が高いと感じられるのかを理解するまで、違いを比較し、再試行しました。

綿密な研究とは、製品の表面をコピーしたり、そのまま持ち運べる答えを探したりすることではありません。それは、誰かが絵画、音楽、または書道を学ぶ練習に似ていました。最初に違いを見分ける目を訓練し、次に徐々に手を追いつけ、その後初めてその能力を自分自身の問題に適用します。

製品の機能には、このような多くの暗黙知が含まれています。アイデアを理解したり、他人の製品を正確に評価したりしても、私たち自身がその能力を持っていることを意味するわけではありません。具体的な選択を繰り返し、判断をインターフェイス、インタラクション、システムに変えることによってのみ、その機能を真にチームの一部にすることができます。

年末までに、優れた製品を一貫して構築できることをまだ証明できませんでした。しかし、今年の半ばになって、漠然と「この商品はダメだ」と感じることしかできませんでした。最終的には、その判断を、情報をどのように整理するか、インタラクションをどのように進めるか、視覚的な詳細が全体をどのようにサポートするか、システムの制約がエクスペリエンスにどのように影響するかなど、より具体的な質問に分割できるようになりました。その後、分解、綿密な研究、再実装、再構築を通じて、これらの能力を 1 つずつトレーニングすることができました。

これらの変更は依然として内部実践の結果にすぎず、実際のユーザーのテストに代わるものではありませんでした。言えることは、より具体的な練習方法が見えてきて、目と手の距離が縮まり始めたということです。

資金調達はお金だけではない

振り返ってみると、Kehanが年の初めに述べた点が、ゆっくりと確認されつつありました。

投資を受けることは重要でしたが、MiraclePlus が私たちに与えてくれたのはお金だけではありませんでした。メンターからの指導や同僚との会話は、必ずしもすぐにユーザー、収益、または製品の成功につながるとは限りません。年末までに、これらの関係が直接的な結果をもたらしたとは言えませんでした。しかし、Peter の短剣の比喩は、私たちが毎日製品を評価する方法にすでに組み込まれていました。

それは、私たちに製品の再検討を強制し続けました。理解したと思っても、後で練習してみると、理解できたのは一部分だけだったことがわかりました。

最初は、広大な第二の脳を小さなものに切り分けることだと思っていました。後には、小さく、速く、格好いいことが鋭さだと考えました。さらにその後、本物の短剣は小さいだけでは役に立たないと気づきました。一つの具体的な問題に、完全な製品体験を集中させなければならなかったのです。

加速器は私たちのために短剣を作ってくれませんでしたが、それは私たちが手にしているものがまだ短剣ではない理由をより早く理解するのに役立ちました。

資金調達はお金だけに関するものではないと言うのは、これが意味します。すぐには答えは得られないかもしれませんが、質問の仕方、自分自身を評価する方法、学習を続ける方法は変わる可能性があります。

本当の鋭さには、完全さも必要だ

2025 年末、短剣に対する私の理解は年初とは変わっていました。

ユーザーの問題に対する洞察が切っ先です。インタラクション、インターフェース、製品体験が刃を形づくります。機能の完全さが刀身です。信頼性と保守性は柄と芯のようなもので、そこで初めて誰かが実際に握り、使うことができます。

鋭い切っ先が一つあるだけなら、せいぜい印象的なデモにはなれても、誰かが実際に使える短剣にはまだなりません。

完成度というのは、全てを注ぎ込むことではない。スイス アーミー ナイフは多くの問題を解決できますが、そのどれか 1 つを十分に深く掘り下げることができない可能性があります。

本当の完全さとは、一つの中核価値をめぐって、ユーザーに必要な一連の体験を最後まで成立させることです。製品のすべての部分が同じ問題を指し、互いを支えなければなりません。機能を増やして、中核の問題が未解決であることを覆い隠すのではありません。

2023 年、私は SenseTime を離れ、次の川へ飛び込みました。2024 年、私たちはひょうたんを作り、なぜ製品が時間の中で成立しなければならないのかを理解し始めました。2025 年、私たちは魔法を本当に現そうとし、広大な第二の脳を一振りの短剣へ切り分けようともしました。

魔法はまだ出現しておらず、Sayso はまだ実用的な製品になっていませんでした。必要性が見えてきたとはいえ、それを迅速かつ適切に構築する能力がまだ不足していました。

しかし、この 1 年を通じて、少なくとも自分たちに何が欠けているのかがより正確にわかるようになりました。

鋭さを追求しても、完全さ、信頼性、長期的な責任を捨てたわけではありません。また、顧客に早く会うことは、すでに良くないと分かっている製品を渡すことではなく、素早い反復は開発速度だけを追うことではないとも理解し始めました。

今も私たちは、完成したあの短剣をまだ作れていません。

ようやく、その研ぎ方を学び始めたところです。

切っ先だけでは、まだ短剣ではありません。

출시하기 전에 이미 충분하지 않다는 것을 알고 있었습니다.

인터페이스가 세련되지 않았고 상호 작용이 아직 자연스럽지 않았으며 기능적 흐름이 불완전했습니다. 사용자 피드백을 기다리지 않고도 많은 문제를 확인할 수 있었습니다. 더욱 문제는 이러한 문제들이 서로 분리될 수 없다는 점입니다. 인터페이스, 사용자 경험, 기능적 완성도, 신뢰성, 유지 관리 가능성이 모두 동시에 작동해야 완전한 제품이 만들어질 수 있었습니다.

그러나 우리는 초기에 고객을 만나고, 작은 단계로 움직이고, 빠르게 반복하는 일련의 시작 방법을 흡수하는 데 몇 달을 보냈습니다. 그래서 우리는 제품이 만족스럽지 못하더라도 먼저 출시해야 한다고 믿었습니다.

사용자들은 빠르게 많은 문제를 제기했습니다. 우리는 출시 전에 상당수의 제품에 대해 알고 있었습니다. 그들의 피드백은 하반기 우리가 만들어낸 변화의 출발점이 되었습니다.

되돌아보면, 그 베타 테스트는 2025년을 두 부분으로 나누었습니다. 상반기 동안 우리는 MagicGourd의 마법이 마침내 나타나기를 바라며 계속해서 MagicGourd를 구축했습니다. 한 해 중반에 우리는 하나의 아이디어를 Sayso으로 추출하여 신속하게 구축하여 사용자 앞에 선보였습니다. 하반기에는 출시 속도를 계속 추구하는 대신 제품 역량을 구축하는 데 주력했습니다. 이 모든 것의 출발점은 우리가 MiraclePlus로부터 투자를 받고 그 액셀러레이터에 합류한 연초였습니다.

연말까지 우리는 아직 그 단검을 만들지 못했습니다. 그러나 우리는 블레이드 팁만으로는 단검이 아니라는 것을 이해하기 시작했습니다.

참석할 계획이 없었던 인터뷰

2025년 초에는 돈을 모을 계획이 없었습니다.

2024년에 우리는 MagicGourd를 구축하는 데 대부분의 시간을 보냈고 27개 버전을 출시했습니다. 우리의 제한된 모금 시도는 아무 성과도 거두지 못했고, 제품은 우리가 상상했던 "진정한 제2의 두뇌"와도 여전히 거리가 멀었습니다. 하지만 나는 그것을 만드는 과정을 매우 즐겼습니다.

성급하게 투자하지 않고도 아주 작은 규모로 계속해서 한 걸음씩 전진할 수 있을 거라 생각했습니다.

Kehan이 제 생각을 바꾸었습니다. 그는 투자 유치가 반드시 돈에 관한 것만은 아니라고 말했습니다. MiraclePlus 액셀러레이터와 그 멘토, 동문들도 훨씬 더 오랜 시간 우리를 도울 수 있었습니다.

그때는 이미 지원 마감일이 지난 뒤였습니다. 하지만 Kehan의 추천을 헛되게 하고 싶지 않아, 진정한 제2의 두뇌에 대한 제 생각을 간단히 적어 지원서를 제출했습니다.

이번 인터뷰는 베이징의 MiraclePlus 사무실에서 진행됐습니다. 기다리는 동안 화면에서 몇 가지 면접 조언을 보았습니다. 답변은 간단하고 직접적이며 진실해야 한다는 내용이었습니다.

1년 전 인터뷰에서 나는 무의식적으로 투자자들이 듣고 싶어하는 답변을 검색했습니다. 그들이 우리의 생각에 반복적으로 이의를 제기했을 때 나는 내 대답이 충분하지 않을까 걱정했습니다. 나는 테이블 건너편의 사람들을 존중했기 때문에 나 자신의 판단조차 의심하기 시작할 수 있었습니다.

이번에는 그렇게 서두르지 않았습니다.

2024년 1년간의 개발 후에도 우리는 여전히 물속에 있었지만 뛰어들었을 때처럼 더 이상 어려움을 겪지 않았습니다. 저는 제가 옳았음에 틀림없다는 것을 증명하려고 하지 않았고, 철저하게 세련된 답변을 준비하지 않았습니다. 저는 그냥 제가 진심으로 생각한 것을 말했을 뿐입니다.

Lu Qi 박사는 SenseTime을 어떻게 생각하느냐고 물었습니다. 저는 그곳에서 성장과 변화의 결정적인 시기를 보냈기에 무엇보다 회사에 깊이 감사한다고 답했습니다. ChatGPT가 등장할 무렵에는 큰 배가 방향을 바꾸기 어렵듯 SenseTime의 대응도 다소 느렸을 수 있습니다. 하지만 2025년에는 빠른 변화를 볼 수 있었고, SenseTime에 더 좋은 시대가 오고 있다고 믿었습니다.

그는 이어서 DeepSeek을 어떻게 생각하느냐고 물었습니다. 제 답은 한 단어, 비용이었습니다. 당시에는 더 설명하지 않았습니다. 비용이 기술이 현실 세계에 들어갈 수 있는 규모에 직접 영향을 준다고 믿었기 때문입니다.

인터뷰는 예상보다 순조롭게 진행되었습니다. 더 이상 특정한 결과를 간절히 바라지 않아서인지 간단하게 말하면 더 쉬워졌습니다.

이후 MiraclePlus가 우리에게 투자했고, 우리는 액셀러레이터에 합류했습니다.

우리는 마침내 마법이 나타나기를 원했습니다

2024년의 목표가 조롱박을 먼저 만드는 것이었다면, 2025년 초에 마침내 그 마법이 나타나기를 바랐습니다.

2024년에는 매우 집중해서 MagicGourd 버전 0.27을 완성했습니다. 사용자는 웹페이지, 온라인 PDF, 동영상에서 마음을 움직인 대목을 표시하고, 떠오른 생각을 기록해 오랫동안 보존할 수 있었습니다.

그러나 여전히 컨테이너에 더 가깝습니다. 누군가의 기록을 수집하고 관리할 수는 있지만, 그 기록을 진정으로 이해할 수는 없으며, 하물며 아직 끝나지 않은 생각을 발견하는 데 도움을 줄 수도 없습니다.

그래서 우리는 2025년을 계획할 때 훨씬 더 큰 목표를 세웠습니다. 우리는 더 이상 기능 추가에 만족하지 않을 것입니다. 우리는 우리가 상상했던 진정한 제2의 두뇌를 향해 실질적인 발걸음을 내딛고 싶었습니다.

우리는 사람의 장기적인 기록을 이해하고, 다양한 시간과 콘텐츠에 흩어진 연결점을 찾고, 그 순간 사용자가 무슨 생각을 하고 있는지 이해하고, 아직 명확하게 표현하지 못한 의도를 인식하고 싶었습니다.

목표는 흥미로웠습니다. 이는 당시 우리가 관리할 수 있는 범위를 훨씬 넘어서는 일이기도 했습니다.

상반기 동안 우리는 개발에 많은 노력을 기울였습니다. 문제는 노력이 부족한 것이 아니라, 한꺼번에 해결해야 할 일이 너무 많다는 점이었습니다. 앞으로 나아갈 때마다 더 많은 질문이 노출되었습니다. 범위는 계속 확장되었지만 개발 속도는 계속 느려졌습니다. 반년이 지났지만 우리는 여전히 사용자 앞에 가장 중요한 가치를 제시하지 못했습니다.

MiraclePlus 액셀러레이터에 들어간 뒤 우리는 한 단어를 계속 들었습니다. 바로 sharp였습니다.

액셀러레이터에서 저를 지도한 Peter는 스타트업은 스위스 아미 나이프가 아니라 단검을 만들어야 한다고 거듭 말했습니다.

상반기가 끝나갈수록 제품이 너무 커진 게 문제라는 생각이 들었습니다. 진정한 제2의 두뇌를 단번에 만들 수 없다면, 그것의 가장 중요한 요소를 추출하여 작고 빠르고 멋진 제품으로 만들어야 합니다.

당시 우리는 그것이 단검의 의미라고 생각했습니다.

두 번째 뇌는 아직 말하지 않은 의도를 이해해야 합니다

저희는 제2의 두뇌에서 가장 중요한 것이 무엇인지 거듭 물었습니다.

답변 우리는 결국 이해 의도를 발견했습니다.

일반적인 정보 도구는 일반적으로 사용자가 이미 입력한 내용으로 시작됩니다. 사용자가 문장을 쓰면 이를 수정할 수 있습니다. 사용자가 질문하면 답변할 수 있습니다. 사용자가 기사를 저장하면 기사를 요약할 수 있습니다.

그러나 많은 인간의 의도는 처음에는 명확하게 표현되지 않습니다. 때때로 우리는 우리가 진정으로 관심을 갖는 것이 무엇인지 알지 못한 채 무언가가 중요하다는 막연한 느낌만 가질 때가 있습니다. 때로 우리는 중요한 사람을 만나려고 하고 많은 정보를 염두에 두고 있지만 가장 말할 가치가 있는 것이 무엇인지 모릅니다. 때때로 우리는 표현하고 싶은 느낌이 무엇인지 알지만 적절한 단어를 찾을 수 없습니다.

두 번째 두뇌가 사용자의 현재 상황과 무언의 의도를 결합할 수 있다면 기존 정보를 처리하는 것 이상의 일을 할 것입니다. 사람이 표현이나 판단을 형성하는 과정에 참여하기 시작하는 것입니다.

이 아이디어를 바탕으로 우리는 올해 중반에 Sayso이라는 제품을 구상했습니다.

그 사람의 현재 상황을 사용하면 그들이 다음에 무슨 말을 할지 파악하는 데 도움이 될 것입니다. 우리는 AI가 사용자의 진정한 의도를 결정하는 것을 원하지 않았습니다. 우리는 사용자가 실제로 표현하고 싶은 것이 무엇인지 인식할 수 있는 가능한 방향을 제시하고 싶었습니다.

이러한 요구는 실제 상황에서 많이 나타납니다. 중요한 사람을 만나기 전이나 중요한 대화를 시작하기 전, 사람들은 할 말이 부족하지 않은 경우가 많다. 문제는 그 엄청난 양의 정보 중 어느 부분이 그 순간에 가장 중요한지 아는 것입니다.

Sayso은 사람의 암시적 의도를 이해한다는 큰 목표를 하나의 구체적인 작업으로 압축하려고 했습니다. 즉, 사람의 현재 상황을 사용하여 아직 표현하지 않은 의도를 밝혀내는 것입니다.

우리는 마침내 제2의 두뇌라는 광대한 아이디어 속에서 단검을 발견했다고 생각했습니다.

우리는 “작은 것”을 “날카로운 것”으로 착각했다

올해 중반에 우리는 대형 제품에서 소형으로 전환했습니다. 하나, 개발 속도가 눈에 띄게 향상되었습니다.

그러나 이러한 변화 동안 단검에 대한 우리의 이해는 여전히 외형적인 형태에만 국한되었습니다.

우리는 제품을 더 작게 만들면 단검이 된다고 생각했습니다. 우리는 기능이 적어서 단검이 된다고 생각했습니다. 나중에 우리는 또한 참신함과 개발 속도를 예리함으로 착각했습니다. 제품이 새롭다고 느껴지고, 빨리 만들어질 수 있고, 사용자에게 빨리 도달할 수 있다면 그것이 우리가 만들어왔던 스위스 군용 칼보다 정답에 더 가까워 보였습니다.

올해 중순에 우리는 아주 짧은 시간에 Sayso을 구축하여 베타 사용자에게 제공했습니다.

그들의 피드백을 통해 어떤 사람들은 중요한 회의나 대화 전에 자신을 표현하는 데 정말로 도움이 필요하며 맥락에서 의도를 발견하는 것의 가치를 이해할 수 있다는 사실이 드러났습니다. 이는 우리가 목표로 삼고 있던 문제가 단지 참신하게 들리는 아이디어가 아니라 실제라는 초기 증거를 제공했습니다.

그러나 제품 자체는 작동하지 않았습니다.

의도를 이해하는 방법에 대한 AI 데모는 신중하게 준비된 몇 가지 예에서만 놀라운 결과를 생성하면 됩니다. 실제 제품은 사용자에게 어떤 컨텍스트를 제공해야 하는지 보여주고, 특정 제안을 제공한 이유를 이해하도록 돕고, 자연스럽게 해당 제안을 편집, 선택 또는 거부할 수 있도록 해야 했습니다.

인터페이스는 신뢰를 불러일으켜야 했습니다. 상호작용은 새로운 부담을 야기할 수 없습니다. 기능은 전체 작업을 통해 사용자를 지원해야 했습니다. 동시에 시스템은 안정적이어야 하고 유지 관리 및 개선이 쉬워야 했습니다.

개별적으로 볼 때 이러한 것 중 어느 것도 반드시 우리를 넘어서는 것은 아닙니다. 제한된 기간 내에 모두 동시에 충분히 좋은 상태로 만드는 것이 어려웠습니다.

사용자는 문제를 빠르게 식별할 수 있었지만 우리는 문제를 빠르고 잘 해결할 수 없었습니다. 때때로 우리는 전반적인 경험을 희생하면서 기능을 완성했습니다. 때때로 우리는 기본 시스템을 유지 관리하기 어렵게 만드는 동시에 경험의 한 부분을 개선했습니다. 때로는 핵심 기능이 이미 시연되었을 수도 있지만 사용자는 여전히 전체 여정을 원활하게 완료할 수 없습니다.

베타 테스트는 의미가 없었습니다. 최소한 그 필요성이 존재한다는 것을 확인할 수 있었습니다.

그러나 필요성이 존재한다고 해서 제품이 작동한다는 의미는 아닙니다. 작동하는 제품이 시장이 작동한다는 것을 의미하지는 않습니다.

구현의 품질이 사용자와 핵심 가치 사이에 있기 때문에 Sayso이 해당 가치를 일관되게 제공할 수 있는지 여부는 물론 시간이 지남에 따라 충분한 사람들이 이를 사용하기를 원하는지 여부를 실제로 테스트하지 않았습니다.

우리는 단검이 뚫어야 하는 문제를 보았지만, 그 통찰력을 누군가가 실제로 사용할 수 있는 단검으로 바꾸는 능력이 여전히 부족했습니다.

눈에는 보였지만 손으로는 아직 만들지 못했다

Sayso을 출시한 후 우리는 처음에 그 문제를 반복 속도가 부족하기 때문이라고 생각했습니다. 사용자들이 피드백을 주었기 때문에 계속해서 조금씩 움직이며 제품을 더 빠르게 바꾸는 것이 답인 것 같았습니다.

그러나 우리는 곧 속도만이 문제가 아니라는 것을 깨달았습니다.

우리는 제품을 출시하기 전부터 좋지 않다는 것을 이미 알고 있었습니다. 사용자 피드백의 많은 문제는 우리의 판단을 벗어나지 않았습니다. 우리에게 부족한 것은 좋은 제품과 나쁜 제품을 구별하는 눈이 아니라, 그 판단을 빠르게 제품으로 바꿀 수 있는 손이었습니다.

눈은 이미 볼 수 있었습니다. 손은 아직 만들 수 없습니다.

그렇다고 해서 우리가 2024년 제품에 대해 배운 모든 것이 틀렸다는 의미는 아닙니다.

2025년 내내 MagicGourd는 온라인 상태를 유지하고 유지 관리했습니다. 새로운 기능은 더 느리게 도착했지만 기존 서비스는 계속해서 실행되었습니다. 연말까지 MagicGourd의 사용자는 약 3,000명에 달했으며 피드백은 전반적으로 긍정적이었습니다. 우리는 해당 연도 동안 사용자 데이터가 손실되거나 손상된 사실을 알지 못했습니다.

2024년에 우리는 데모를 시간이 지나도 작동할 수 있는 소프트웨어로 바꾸는 방법, 즉 동기화, 개인 정보 보호, 호환성 및 오류를 처리하는 방법을 배웠습니다. 실제 사용자가 의존하는 서비스를 유지하는 방법; 그리고 개인이 수년에 걸쳐 축적할 수 있는 데이터에 대해 책임을 지는 방법.

이러한 기능은 여전히 중요합니다. 이는 MagicGourd를 단순한 데모 이상으로 만들었고 새로운 기능의 속도가 느려지더라도 기존 사용자에 대한 책임을 유지할 수 있게 해주었습니다.

그러나 2025년에는 또 다른 기능 계층이 노출되었습니다.

우리는 여전히 요구 사항을 명확한 제품 정의로 전환하는 데 능숙하지 않았습니다. 우리는 단시간에 세련되고 자연스러운 인터페이스와 상호 작용 흐름을 만드는 데 능숙하지 않았습니다. 또한 경험, 기능성, 신뢰성 및 유지 관리 가능성의 균형을 동시에 안정적으로 유지할 수도 없습니다.

우리는 알고리즘에 대한 전문성과 시스템 엔지니어링 능력을 갖고 있었습니다. 아이디어가 떠오르면 그 기술적인 핵심을 신속하게 구현할 수 있었습니다. 그러나 작동하는 기술이 작동하는 제품을 의미하는 것은 아닙니다. 진정한 제품의 강점이란 서로를 제약하는 많은 판단을 사용자가 경험하는 단순하고 명확하며 완전한 것으로 압축하는 것을 의미합니다.

올해 하반기에 접어들면서 우리는 마침내 우리의 제품 역량이 아직 우리의 야망을 뒷받침할 수 없다는 것을 인정했습니다.

먼저 칼날을 가는 법을 배우다

우리는 하반기를 역량 강화의 시기로 정의했습니다.

결정은 어려웠습니다. 상반기 후반에는 고객을 조기에 만나야 하는 이유를 이해하기 위해 많은 노력을 기울였습니다. 하지만 후반부에는 미완성 제품을 사용자들 앞에서 서두르지 않고 먼저 제품을 잘 만드는 방법을 배우기로 결정했습니다.

표면적으로 이는 회사 내부의 시장에서 후퇴하는 것처럼 보였습니다. 하지만 우리가 해결하고 싶었던 문제는 시장만이 답할 수 있는 문제가 아니었습니다.

사용자는 실제 요구 사항이 있는지, 제품이 가치를 창출하는지, 계속 사용하고 싶은지 여부를 알 수 있습니다. 그러나 인터페이스가 다듬어지지 않은 것으로 간주하거나, 상호 작용 흐름이 불완전하다는 것을 이미 알고 있거나, 신뢰성 문제로 핵심 가치가 모호해진다는 것을 알고 있었다면 제품을 사용자에게 제공하더라도 핵심 질문에 대한 더 유용한 정보를 생성할 수는 없을 것입니다.

시장은 우리가 이미 알고 있는 답변을 반복하는 것이 아니라 알려지지 않은 질문에 답하는 데 도움을 주어야 합니다.

그래서 우리는 진심으로 존경하는 제품을 반복적으로 연구하기 시작했습니다. 우리는 그들의 구조, 시각적 디자인, 상호 작용을 분석하여 왜 모든 세부 사항이 특정 방식으로 처리되었는지 물었습니다. 면밀한 연구와 재구현을 통해 우리는 눈에 보이는 판단을 스스로 내린 것으로 바꾸었습니다. 그런 다음 이러한 우수한 제품이 왜 단순하고 자연스러우며 완전하다고 느껴지는지 이해할 때까지 차이점을 비교하고 다시 시도했습니다.

면밀한 연구는 제품의 표면을 복사하거나 변함없이 가지고 다닐 수 있는 답을 찾는 것이 아닙니다. 그것은 누군가가 그림, 음악, 서예를 배우는 연습에 더 가깝습니다. 먼저 차이를 구별할 수 있도록 눈을 훈련시킨 다음, 손이 점차 따라잡도록 하고, 그런 다음 그 능력을 자신의 문제에 적용하십시오.

제품의 성능에는 이와 같은 암묵적 지식이 많이 포함되어 있습니다. 아이디어를 이해하고, 심지어 다른 사람의 제품을 정확하게 평가한다고 해서 우리 자신이 그 능력을 갖고 있다는 의미는 아닙니다. 반복되는 구체적인 선택을 통해 판단을 인터페이스, 상호 작용 및 시스템으로 전환해야만 해당 기능이 진정으로 팀의 일부가 될 수 있습니다.

연말까지 우리는 여전히 우수한 제품을 지속적으로 구축할 수 있었다는 것을 증명할 수 없었습니다. 하지만 올해 중반에 우리가 할 수 있었던 것은 막연하게 "이 제품은 좋지 않다"는 느낌뿐이었습니다. 결국 우리는 판단을 좀 더 구체적인 질문, 즉 정보를 어떻게 구성해야 하는지, 상호 작용이 어떻게 진행되어야 하는지, 시각적 세부 사항이 전체를 어떻게 지원해야 하는지, 시스템 제약이 경험에 어떻게 영향을 미치는지 등으로 나눌 수 있습니다. 그런 다음 분해, 면밀한 연구, 재구현 및 재구축을 통해 이러한 능력을 하나씩 훈련할 수 있습니다.

이러한 변경 사항은 여전히 내부 실습의 결과일 뿐이며 실제 사용자의 테스트를 대체할 수는 없습니다. 우리가 말할 수 있는 것은 좀 더 구체적인 실천 방식이 형성되기 시작했고, 눈과 손 사이의 거리가 좁아지기 시작했다는 것입니다.

투자 유치는 돈만의 문제가 아니다

돌이켜보면 Kehan이 연초에 했던 말은 조금씩 확인되고 있었습니다.

투자를 받는 일은 중요했지만, 돈이 MiraclePlus가 우리에게 준 전부는 아니었습니다. 멘토의 지도와 동료들과의 대화가 곧바로 사용자, 매출, 성공한 제품으로 이어지는 것은 아닙니다. 연말까지 이런 관계가 직접적인 성과를 만들었다고 말할 수는 없었습니다. 하지만 Peter의 단검 비유는 이미 우리가 매일 제품을 평가하는 방식에 들어와 있었습니다.

그것은 우리가 계속해서 제품을 재검토하도록 강요했습니다. 내가 그것을 이해했다고 생각할 때마다 나중에 연습을 해보니 내가 한 부분만 이해했다는 것이 드러났습니다.

처음에는 광대한 두 번째 뇌를 더 작은 것으로 쪼개는 것을 의미한다고 생각했습니다. 나중에는 작고 빠르며 쿨하다는 게 날카롭다는 뜻이라고 생각했어요. 나중에 나는 진짜 단검이 단순히 작다는 이유만으로 작동하지 않는다는 것을 깨달았습니다. 하나의 특정 문제에 완전한 제품 경험을 집중해야 했습니다.

가속기는 우리를 위해 단검을 만들어주지는 않았지만, 우리 손에 있는 것이 왜 아직 단검이 아닌지 더 빨리 알 수 있도록 도와주었습니다.

이것이 바로 모금이 단지 돈에 관한 것이 아니라는 것을 의미하는 것입니다. 즉각적인 답변을 제공할 수는 없지만 질문하고, 자신을 평가하고, 계속 학습하는 방식을 바꿀 수 있습니다.

진정한 날카로움에는 완전함도 필요하다

2025년 말까지 단검에 대한 나의 이해는 연초와 달라졌습니다.

사용자의 문제에 대한 통찰력은 블레이드 팁이었습니다. 상호작용, 인터페이스, 제품 경험이 엣지를 형성했습니다. 기능적 완성도는 블레이드의 본체였습니다. 신뢰성과 유지 관리성은 누군가가 실제로 잡고 사용할 수 있도록 해주는 손잡이와 같았습니다.

날카로운 끝 하나만으로는 기껏해야 인상적인 데모가 될 수 있을 뿐, 누군가가 실제로 사용할 수 있는 단검은 아직 아니었습니다.

완전함은 제품에 모든 것을 담는 것을 의미하지 않습니다. 스위스 군용 칼은 많은 문제를 해결할 수 있지만 그 중 어느 하나에도 충분히 깊이 들어가지 못할 수도 있습니다.

진정한 완전성은 하나의 핵심 가치를 중심으로 사용자에게 필요한 전체 여정을 완료하는 것을 의미했습니다. 핵심 문제가 해결되지 않은 채 남아 있다는 사실을 숨기기 위해 더 많은 기능을 사용하기보다는 제품의 모든 부분이 동일한 문제를 가리키고 다른 부분을 지원해야 했습니다.

2023년, 저는 SenseTime를 떠나 다음 강으로 뛰어들었습니다. 2024년에 우리는 조롱박을 만들고 왜 제품이 시간이 지남에 따라 작동해야 하는지 이해하기 시작했습니다. 2025년에 우리는 마침내 마법이 나타나길 바랐고, 광대한 두 번째 뇌를 단검으로 분해하려고도 했습니다.

마법은 아직 나타나지 않았고, Sayso도 아직 제대로 작동하는 제품이 되지 못했습니다. 이제 필요는 볼 수 있었지만, 그것을 빠르고도 훌륭하게 만들어 낼 능력은 여전히 부족했습니다.

그러나 1년이 지나면서 최소한 우리에게 부족한 것이 무엇인지 더 정확하게 알게 되었습니다.

선명함을 추구한다고 해서 완전성, 신뢰성 또는 장기적인 책임을 포기하는 것은 아닙니다. 또한 우리는 고객을 일찍 만났다고 해서 우리가 이미 알고 있던 형편없는 제품을 그들에게 주는 것이 아니며, 빠른 반복이 개발 속도만 추구하는 것을 의미하지 않는다는 것을 이해하기 시작했습니다.

현재까지 우리는 아직 그 완전한 형태의 단검을 만들지 못했습니다.

우리는 그것을 가는 방법을 배우기 시작했을 뿐입니다.

칼끝만으로는 아직 단검이 아닙니다.

Antes de lançá-lo, eu já sabia que não era bom o suficiente.

Sua interface carecia de polimento, as interações ainda não pareciam naturais e o fluxo funcional estava incompleto. Pudemos ver muitos dos problemas sem esperar pelo feedback do usuário. O mais preocupante é que estes problemas não podiam ser separados uns dos outros. A interface, a experiência do usuário, a integridade funcional, a confiabilidade e a capacidade de manutenção tiveram que funcionar ao mesmo tempo antes que pudessem formar um produto completo.

Mas tínhamos acabado de passar meses absorvendo um conjunto de métodos de inicialização: conhecer os clientes antecipadamente, avançar em pequenos passos e iterar rapidamente. Portanto, embora estivéssemos insatisfeitos com o produto, ainda acreditávamos que deveríamos lançá-lo primeiro.

Os usuários levantaram rapidamente muitas questões. Já conhecíamos uma parte considerável delas antes do lançamento. O feedback deles se tornou o ponto de partida para a mudança que fizemos na segunda metade do ano.

Olhando para trás, aquele teste beta dividiu 2025 em duas metades. Durante o primeiro semestre, continuamos construindo MagicGourd, na esperança de fazer sua magia finalmente aparecer. No meio do ano, extraímos uma ideia do Sayso, construímo-la rapidamente e a colocamos na frente dos usuários. No segundo semestre, em vez de continuar buscando a velocidade de lançamento, passamos a desenvolver as capacidades de nossos produtos. O ponto de partida para tudo isso veio no início do ano, quando recebemos investimento da MiraclePlus e aderimos à sua aceleradora.

Até o final do ano, ainda não havíamos feito aquela adaga. Mas começamos a entender: uma ponta por si só não é uma adaga.

Uma entrevista que eu não planejava participar

No início de 2025, eu não tinha planos de arrecadar dinheiro.

Em 2024, passamos a maior parte do nosso tempo construindo MagicGourd e lançando 27 versões. Nossas tentativas limitadas de arrecadação de fundos não levaram a lugar nenhum, e o produto ainda estava longe do “verdadeiro segundo cérebro” que imaginávamos. Mas gostei muito do processo de construção.

Achei que poderíamos continuar em uma escala muito pequena, avançando um passo de cada vez, sem pressa em fazer investimentos.

Kehan me fez mudar de ideia. Ele me disse que captar investimento não precisava ser apenas uma questão de dinheiro. O acelerador da MiraclePlus, seus mentores e seus ex-alunos também poderiam nos ajudar por muito mais tempo.

Até então, o prazo de inscrição já havia expirado. Mas eu não queria desperdiçar a recomendação de Kehan, então enviei uma inscrição de qualquer maneira, descrevendo brevemente como pensei sobre um verdadeiro segundo cérebro.

Esta entrevista ocorreu no escritório MiraclePlus em Pequim. Enquanto esperava, vi diversas sugestões de entrevista em uma tela: as respostas deveriam ser simples, diretas e verdadeiras.

Na entrevista do ano anterior, eu havia inconscientemente procurado as respostas que os investidores queriam ouvir. Quando desafiaram repetidamente as nossas ideias, fiquei preocupado com a possibilidade de as minhas respostas não serem suficientemente boas. Como eu respeitava as pessoas do outro lado da mesa, poderia até começar a duvidar do meu próprio julgamento.

Desta vez, não estava com tanta pressa.

Depois de um ano inteiro de desenvolvimento em 2024, ainda estávamos na água, mas não estávamos mais lutando como tínhamos logo após entrar. Eu simplesmente disse o que realmente pensava.

Dr. Lu Qi perguntou o que eu achava de SenseTime. Disse que, antes de mais nada, estava profundamente grato à empresa, pois ali passei por um período crucial de crescimento e transformação. Perto da chegada do ChatGPT, o SenseTime pode ter demorado um pouco para responder porque um navio grande é difícil de virar. Mas em 2025, pude ver que isso estava mudando rapidamente e acreditei que uma era melhor para SenseTime estava chegando.

Ele então perguntou o que eu achava de DeepSeek. Minha resposta foi uma palavra: custo. Eu não elaborei na época. Eu simplesmente acreditava que o custo afetaria diretamente a escala em que uma tecnologia poderia entrar no mundo real.

A entrevista foi mais tranquila do que eu esperava. Talvez porque eu não estivesse mais desesperado por um determinado resultado, ficou mais fácil falar com simplicidade.

Depois, MiraclePlus investiu em nós e aderimos ao acelerador.

Queríamos que a magia finalmente aparecesse

Se o objetivo de 2024 tinha sido fazer primeiro a cabaça, no início de 2025 queríamos que sua magia finalmente aparecesse.

Em 2024, mantivemos um foco muito claro e concluímos a versão 0.27 do MagicGourd. O produto ajudava as pessoas a marcar o que as tocava em páginas da web, PDFs online e vídeos, registrar os pensamentos que surgiam e preservar tudo isso ao longo do tempo.

Mas ainda estava mais perto de um contêiner. Poderia coletar e gerenciar os registros de uma pessoa, mas não poderia entendê-los verdadeiramente, muito menos ajudar alguém a descobrir pensamentos que permaneceram inacabados.

Portanto, quando planejamos para 2025, estabelecemos para nós mesmos uma meta muito maior. Não ficaríamos mais satisfeitos em adicionar recursos. Queríamos dar um verdadeiro passo em direção ao verdadeiro segundo cérebro que havíamos imaginado.

Queríamos entender os registros de longo prazo de uma pessoa, encontrar conexões espalhadas por diferentes épocas e diferentes conteúdos, entender o que o usuário estava pensando naquele momento e reconhecer intenções que ele ainda não havia expressado claramente.

O objetivo era emocionante. Também estava muito além do escopo que podíamos gerenciar na época.

Durante o primeiro semestre do ano, dedicamos um enorme esforço ao desenvolvimento. O problema não era a falta de trabalho duro, mas a quantidade de coisas que precisavam ser resolvidas de uma vez. Cada passo adiante expôs mais questões. O escopo continuou se expandindo, enquanto nosso ritmo de desenvolvimento continuou desacelerando. Meio ano se passou e ainda não havíamos colocado o valor mais importante diante dos usuários.

Depois de entrar no acelerador MiraclePlus, continuamos ouvindo uma palavra: sharp.

Meu mentor no acelerador, Peter, nos disse repetidamente que uma startup deveria fazer uma adaga, não um canivete suíço.

À medida que o primeiro semestre do ano chegava ao fim, começamos a pensar que o problema era que o produto havia se tornado muito grande. Se não pudéssemos construir um verdadeiro segundo cérebro de uma só vez, deveríamos extrair seu elemento mais importante e transformá-lo em um produto que fosse pequeno, rápido e legal.

Na época, pensávamos que era isso que uma adaga significava.

Um segundo cérebro deve entender as intenções ainda não ditas

Perguntamos repetidamente o que era mais importante em um segundo cérebro.

A resposta que finalmente encontramos foi compreender a intenção.

Uma ferramenta de informação comum geralmente começa com o que o usuário já inseriu. Se um usuário escrever uma frase, ele poderá revisá-la. Se o usuário fizer uma pergunta, ele poderá responder. Se o usuário salvar um artigo, ele poderá resumi-lo.

Mas muitas intenções humanas não são claramente expressas no início. Às vezes, temos apenas uma vaga sensação de que algo é importante, sem saber com o que realmente nos importamos. Às vezes estamos prestes a conhecer alguém importante e temos muitas informações em mente, mas não sabemos o que vale mais a pena dizer. Às vezes, sabemos o sentimento que queremos expressar, mas não conseguimos encontrar as palavras certas.

Se um segundo cérebro pudesse combinar o contexto atual do usuário com essas intenções não expressas, faria mais do que processar as informações existentes. Ele começaria a participar do processo pelo qual uma pessoa forma uma expressão ou julgamento.

Com base nessa ideia, concebemos um produto chamado Sayso no meio do ano.

Usando o contexto atual da pessoa, o produto a ajudaria a ver o que poderia dizer a seguir. Não queríamos que a IA decidisse a verdadeira intenção do usuário. Queríamos que ela oferecesse possíveis direções nas quais o usuário pudesse reconhecer o que realmente queria expressar.

Essa necessidade aparece em muitas situações reais. Antes de conhecer uma pessoa importante ou iniciar uma conversa importante, muitas vezes as pessoas não têm falta de coisas para dizer. O problema é saber qual parte de uma grande quantidade de informação é mais importante naquele momento.

Sayso tentou comprimir o grande objetivo de compreender as intenções implícitas de uma pessoa em uma tarefa concreta: usar o contexto atual da pessoa para descobrir intenções que ela ainda não havia expressado.

Pensamos que finalmente tínhamos encontrado uma adaga dentro da vasta ideia de um segundo cérebro.

Confundimos “Pequeno” com “Afiado”

No meio do ano, nós passamos de um produto grande para um pequeno e nossa velocidade de desenvolvimento aumentou visivelmente.

Mas durante essa mudança, nossa compreensão de uma adaga ainda estava limitada à sua forma externa.

Pensamos que tornar o produto menor o transformaria em uma adaga. Achamos que menos recursos o tornavam uma adaga. Mais tarde, também confundimos novidade e velocidade de desenvolvimento com precisão: se um produto parecia novo, podia ser construído rapidamente e chegar logo aos usuários, parecia mais próximo da resposta certa do que o canivete suíço que estávamos construindo.

No meio do ano, construímos o Sayso em um tempo muito curto e o entregamos aos usuários beta.

O feedback mostrou que algumas pessoas realmente precisavam de ajuda para se expressar antes de uma reunião ou conversa importante e conseguiam compreender o valor de descobrir intenções a partir do contexto. Isso ofereceu evidências iniciais de que o problema que buscávamos resolver era real, e não apenas uma ideia que parecia nova.

Mas o produto em si não funcionou.

Um demo de IA sobre compreensão de intenção talvez só precisasse produzir um resultado surpreendente em alguns exemplos cuidadosamente preparados. Um produto real tinha que mostrar aos usuários qual contexto fornecer, ajudá-los a entender por que oferecia sugestões específicas e permitir que editassem, escolhessem ou rejeitassem essas sugestões de modo natural.

A interface tinha que inspirar confiança. As interações não poderiam criar um novo fardo. Os recursos deveriam apoiar o usuário durante toda a tarefa. Ao mesmo tempo, o sistema tinha que ser confiável e fácil de manter e melhorar.

Nenhuma dessas coisas, tomadas individualmente, estava necessariamente além de nós. A dificuldade era fazer com que todos fossem bons o suficiente ao mesmo tempo, dentro de um período limitado.

Os usuários conseguiam identificar os problemas rapidamente, mas não conseguíamos resolvê-los ao mesmo tempo com rapidez e qualidade. Às vezes concluíamos um recurso às custas da experiência geral. Às vezes melhorávamos uma parte da experiência e tornávamos o sistema subjacente mais difícil de manter. Às vezes a capacidade principal já podia ser demonstrada, mas o usuário ainda não conseguia completar uma jornada inteira sem problemas.

O teste beta não foi sem sentido. Pelo menos permitiu-nos confirmar que a necessidade existia.

Mas a existência de uma necessidade não significa que um produto funcione. Um produto funcional não significa que um mercado funcione.

Como a qualidade da implementação estava entre os usuários e o valor central, não testamos realmente se Sayso poderia fornecer esse valor de forma consistente, muito menos se um número suficiente de pessoas gostaria de usá-lo ao longo do tempo.

Talvez tivéssemos visto o problema que a adaga deveria perfurar, mas ainda não tínhamos a capacidade de transformar esse insight em uma adaga que alguém pudesse realmente usar.

O olho podia ver, mas a mão ainda não conseguia fazer

Depois de lançar Sayso, inicialmente atribuímos o problema à velocidade de iteração insuficiente. Os usuários nos deram feedback, então a resposta parecia continuar avançando em pequenos passos e mudando o produto mais rapidamente.

Mas logo descobrimos que a velocidade não era o único problema.

Antes de lançar o produto, já sabíamos que ele não era bom. Muitos dos problemas no feedback do usuário não excederam nosso próprio julgamento. O que nos faltou não foi o olho para distinguir um produto bom de um produto ruim, mas a mão que pudesse rapidamente transformar esse julgamento em um produto.

O olho já podia ver. A mão ainda não conseguiu fazer.

Isso não significa que tudo o que aprendemos sobre os produtos em 2024 estava errado.

Ao longo de 2025, MagicGourd permaneceu online e mantido. Novos recursos chegaram mais lentamente, mas o serviço existente continuou funcionando. No final do ano, MagicGourd tinha cerca de 3.000 usuários e o feedback permaneceu positivo em geral. Não tínhamos conhecimento de nenhum dado de usuário perdido ou corrompido durante o ano.

Em 2024, aprendemos como transformar um Demo em um software que pudesse operar ao longo do tempo: como lidar com sincronização, privacidade, compatibilidade e falhas; como manter um serviço do qual os usuários reais dependiam; e como assumir a responsabilidade pelos dados que uma pessoa pode acumular ao longo de muitos anos.

Essas capacidades ainda importavam. Eles tornaram MagicGourd mais do que uma Demonstração e nos permitiram permanecer responsáveis para com os usuários existentes, mesmo com a desaceleração do ritmo de novos recursos.

Mas 2025 expôs outra camada de capacidade.

Ainda não éramos bons em transformar uma necessidade em uma definição clara de produto. Não éramos bons em criar uma interface e um fluxo de interação polidos e naturais em pouco tempo. Nem poderíamos equilibrar de forma confiável experiência, funcionalidade, confiabilidade e facilidade de manutenção ao mesmo tempo.

Tínhamos conhecimento em algoritmos e capacidade de engenharia de sistemas. Quando surgia uma ideia, podíamos implementar rapidamente o seu núcleo técnico. Mas tecnologia funcional não significava um produto funcional. A força real do produto significava comprimir muitos julgamentos que restringiam uns aos outros em algo que o usuário considerava simples, claro e completo.

Ao entrarmos no segundo semestre do ano, finalmente admitimos que os recursos de nossos produtos ainda não poderiam apoiar nossa ambição.

Primeiro aprenda como afiar a lâmina

Definimos o segundo semestre do ano como um período para desenvolver capacidades.

A decisão foi difícil. No final do primeiro semestre, havíamos investido muito esforço para entender por que deveríamos atender os clientes com antecedência. No segundo semestre, porém, decidimos parar de apressar cada produto inacabado na frente dos usuários e primeiro aprender como construir bem os produtos.

Superficialmente, isso parecia uma retirada do mercado de volta para dentro da empresa. Mas o problema que queríamos resolver não era um problema que só o mercado pudesse responder.

Os usuários podiam nos dizer se uma necessidade era real, se o produto criava valor e se queriam continuar a usá-lo. Mas, se até nós considerávamos a interface pouco polida, já sabíamos que um fluxo de interação estava incompleto ou que problemas de confiabilidade esconderiam o valor central, entregar o produto aos usuários não produziria informações mais úteis sobre a questão central.

O mercado deveria nos ajudar a responder perguntas desconhecidas, e não a repetir respostas que já conhecíamos.

Então começamos a estudar repetidamente produtos que realmente admirávamos. Detalhamos sua estrutura, design visual e interações, perguntando por que cada detalhe foi tratado de uma maneira específica. Através de estudos minuciosos e reimplementações, transformamos julgamentos que podíamos ver em coisas que nós mesmos fizemos. Em seguida, comparamos as diferenças e tentamos novamente, até entendermos por que esses produtos excelentes pareciam simples, naturais e completos.

O estudo detalhado não se tratava de copiar a superfície de um produto ou de buscar uma resposta que pudéssemos levar inalterada. Era mais como a prática pela qual alguém aprende pintura, música ou caligrafia: primeiro treinar o olho para perceber a diferença, depois deixar a mão alcançá-la gradualmente e só então aplicar essa habilidade a um problema próprio.

A capacidade do produto contém uma grande quantidade de conhecimento tácito como este. Compreender uma ideia, ou mesmo avaliar com precisão o produto de outra pessoa, não significa que possuímos essa capacidade. Somente transformando julgamentos em interfaces, interações e sistemas por meio de repetidas escolhas concretas é que essa capacidade poderia realmente se tornar parte da equipe.

No final do ano, ainda não conseguíamos provar que éramos capazes de construir produtos excelentes de forma consistente. Mas no meio do ano, tudo o que podíamos fazer era sentir vagamente que “este produto não é bom”. No final, poderíamos dividir esse julgamento em questões mais específicas: como a informação deveria ser organizada, como uma interação deveria progredir, como os detalhes visuais deveriam apoiar o todo e como as restrições do sistema afetariam a experiência. Poderíamos então treinar essas habilidades uma por uma por meio de decomposição, estudo minucioso, reimplementação e reconstrução.

Essas mudanças ainda eram apenas resultados da prática interna e não podiam substituir o teste de usuários reais. O que podíamos dizer era que tínhamos começado a formar uma forma mais concreta de praticar e que a distância entre os nossos olhos e as nossas mãos tinha começado a diminuir.

A angariação de fundos não se trata apenas de dinheiro

Olhando para trás, o ponto que Kehan tinha defendido no início do ano estava a ser confirmado, lentamente.

Receber investimento foi importante, mas dinheiro não foi tudo o que MiraclePlus nos deu. A orientação de mentores e as conversas com colegas não se transformariam necessariamente imediatamente em usuários, receitas ou em um produto de sucesso. No final do ano, não poderia dizer que estas relações tivessem produzido resultados diretos. Mas a metáfora da adaga de Peter já havia entrado na forma como avaliamos os produtos todos os dias.

Continuou nos forçando a reexaminar nossos produtos. Sempre que pensei ter entendido, a prática posterior me mostrou que eu havia entendido apenas uma parte.

No início, pensei que isso significava reduzir o vasto segundo cérebro a algo menor. Mais tarde, pensei que pequeno, rápido e atraente significava afiado. Mais tarde ainda, percebi que uma adaga de verdade não funcionava apenas por ser pequena. Ela tinha que concentrar uma experiência completa de produto em um problema específico.

O acelerador não fez a adaga para nós, mas nos ajudou a ver mais cedo por que a coisa em nossas mãos ainda não era uma.

Isso é o que significa dizer que arrecadação de fundos não é apenas uma questão de dinheiro. Pode não fornecer uma resposta imediata, mas pode mudar a forma como fazemos perguntas, nos avaliamos e continuamos aprendendo.

A verdadeira precisão também exige integridade

No final de 2025, meu entendimento de uma adaga era diferente do que era no início do ano.

A compreensão do problema do usuário era a ponta. A interação, a interface e a experiência do produto formavam o fio. A integridade funcional era o corpo da lâmina. A confiabilidade e a facilidade de manutenção eram como o cabo, permitindo que alguém realmente a segurasse e usasse.

Uma única ponta afiada poderia, no máximo, se tornar um demo impressionante. Ainda não era uma adaga que alguém pudesse realmente usar.

Completude não significava colocar tudo no produto. Um canivete suíço pode resolver muitos problemas, mas pode não se aprofundar o suficiente em nenhum deles.

A verdadeira completude significava completar toda a jornada que o usuário precisava em torno de um valor central. Cada parte do produto tinha que apontar para o mesmo problema e dar suporte às outras partes, em vez de usar mais recursos para esconder o fato de que o problema central permanecia sem solução.

Em 2023, deixei SenseTime e pulei no próximo rio. Em 2024, fizemos a cabaça e começamos a entender porque um produto tinha que funcionar com o tempo. Em 2025, queríamos que a magia finalmente aparecesse e também tentamos quebrar o vasto segundo cérebro em uma adaga.

A magia ainda não havia aparecido e Sayso ainda não havia se tornado um produto funcional. Embora agora pudéssemos ver a necessidade, ainda não tínhamos a capacidade de construí-la de forma rápida e adequada.

Mas ao longo do ano, pelo menos passamos a ver com mais precisão o que nos faltava.

Nossa busca por precisão não nos fez abandonar a integridade, a confiabilidade ou a responsabilidade de longo prazo. Também estávamos começando a entender que encontrar os clientes cedo não significava entregar a eles um produto que já sabíamos ser ruim, e que a iteração rápida não significava buscar apenas velocidade de desenvolvimento.

Até hoje, ainda não fabricamos aquela adaga totalmente formada.

Nós apenas começamos a aprender a afiá-la.

Uma ponta por si só não é uma adaga.

Прежде чем мы его выпустили, я уже знал, что он недостаточно хорош.

Интерфейсу не хватало полировки, взаимодействие еще не казалось естественным, а пользовательский сценарий был неполным. Многие проблемы мы видели, не дожидаясь отзывов. Еще тревожнее было то, что их нельзя отделить друг от друга: интерфейс, пользовательский опыт, функциональная завершенность, надежность и сопровождаемость должны работать одновременно, чтобы сложиться в полноценный продукт.

Но мы только что потратили несколько месяцев на освоение набора методов запуска: встречаться с клиентами на ранней стадии, двигаться небольшими шагами и быстро выполнять итерации. Поэтому, даже несмотря на то, что мы были недовольны продуктом, мы все равно считали, что нам следует выпустить его первым.

Пользователи быстро подняли множество вопросов. О значительном их количестве мы знали еще до релиза. Их отзывы стали отправной точкой для изменений, которые мы внесли во второй половине года.

Оглядываясь назад, можно сказать, что бета-тест разделил 2025 год на две половины. В первой половине мы продолжали создавать MagicGourd, надеясь, что его магия наконец-то проявится. В середине года мы выделили одну идею, превратили ее в Sayso, быстро создали продукт и показали его пользователям. Во второй половине, вместо того чтобы продолжать гоняться за скоростью выпуска, мы занялись развитием продуктовых навыков. Отправной точкой всего этого стало начало года, когда мы получили инвестиции от MiraclePlus и присоединились к его акселератору.

К концу года мы так и не сделали этот кинжал. Но мы начали понимать: одно острие — еще не кинжал.

Интервью, которое я не планировал посещать

В начале 2025 года у меня не было планов по сбору денег.

В 2024 году мы потратили большую часть времени на создание MagicGourd и выпустили 27 версий. Наши ограниченные попытки по сбору средств ни к чему не привели, и продукт все еще был далек от того «настоящего второго мозга», который мы себе представляли. Но мне очень понравился процесс его создания.

Я думал, что мы могли бы продолжать в очень небольших масштабах, продвигаясь вперед шаг за шагом, не торопясь с инвестициями.

Kehan изменил мою точку зрения. Он сказал, что привлечение инвестиций — это не обязательно только деньги. Акселератор MiraclePlus, его наставники и выпускники могли бы помогать нам гораздо дольше.

К тому времени срок подачи заявок уже прошел. Но я не хотел, чтобы рекомендация Kehan пропала зря, поэтому я все равно подал заявку, кратко описав, как я думаю об истинном втором мозге.

Это интервью проходило в офисе MiraclePlus в Пекине. Пока я ждал, я увидел на экране несколько предложений по интервью: ответы должны быть простыми, прямыми и правдивыми.

В интервью годом ранее я неосознанно искал ответы, которые инвесторы хотели услышать. Когда они неоднократно подвергали сомнению наши идеи, я беспокоился, что мои ответы были недостаточно хорошими. Поскольку я уважал людей за столом, я мог даже начать сомневаться в своем собственном суждении.

На этот раз я не так спешил.

После целого года разработки в 2024 году мы все еще были в воде, но уже не боролись так, как сразу после прыжка. Я не пытался доказать, что я прав, и не подготовил тщательно отточенных ответов. Я просто сказал то, что искренне думал.

Доктор Lu Qi спросил, что я думаю о SenseTime. Я сказал, что прежде всего глубоко благодарен компании, потому что пережил там переломный период роста и трансформации. На рубеже появления ChatGPT SenseTime, возможно, реагировал немного медленнее: большому кораблю трудно изменить курс. Но к 2025 году я видел быстрые перемены и верил, что для SenseTime наступает лучшая эпоха.

Затем он спросил, что я думаю о DeepSeek. Мой ответ был одним словом: стоимость. Я тогда не уточнил. Я просто верил, что стоимость напрямую повлияет на масштаб, в котором технология может войти в реальный мир.

Интервью прошло более гладко, чем я ожидал. Возможно, потому, что я больше не нуждался в конкретном результате, мне стало легче говорить просто.

Позже MiraclePlus инвестировал в нас, и мы присоединились к акселератору.

Мы хотели, чтобы волшебство наконец появилось

Если целью 2024 года было сначала сделать тыкву-горлянку, то в начале 2025-го мы хотели, чтобы ее волшебство наконец проявилось.

В 2024 году мы сохраняли предельный фокус и завершили версию 0.27 MagicGourd. Она помогала людям отмечать тронувшие их фрагменты на веб-страницах, в онлайн-PDF и видео, записывать возникающие мысли и сохранять все это надолго.

Но это все же было ближе к контейнеру. Он мог собирать записи человека и управлять ими, но не мог их по-настоящему понять, а тем более помочь кому-то обнаружить мысли, которые остались незавершенными.

Поэтому, когда мы планировали 2025 год, мы ставили перед собой гораздо большую цель. Мы больше не будем удовлетворены добавлением функций. Мы хотели сделать реальный шаг к истинному второму мозгу, который мы себе представляли.

Мы хотели понять долгосрочные записи человека, найти связи, разбросанные по разным временам и разным фрагментам контента, понять, о чем пользователь думал в тот момент, и распознать намерения, которые он еще не выразил четко.

Цель была захватывающей. Это также выходило далеко за рамки того, с чем мы могли справиться в то время.

В течение первой половины года мы посвятили огромные усилия развитию. Проблема заключалась не в недостатке усердной работы, а в количестве дел, которые нужно было решить сразу. Каждый шаг вперед вызывал все больше вопросов. Масштаб продолжал расширяться, а темпы нашего развития продолжали замедляться. Прошло полгода, а мы так и не поставили перед пользователями самое главное.

После входа в акселератор MiraclePlus мы все время слышали одно слово: sharp.

Мой наставник в акселераторе Peter не раз говорил нам, что стартап должен делать кинжал, а не швейцарский армейский нож.

К концу первого полугодия мы начали думать, что проблема в том, что продукт стал слишком большим. Если мы не можем сразу создать настоящий второй мозг, нам следует извлечь из него самый важный элемент и превратить его в маленький, быстрый и крутой продукт.

В то время мы думали, что именно это означает кинжал.

Второй мозг должен понимать еще не высказанные намерения

Мы неоднократно задавались вопросом, что важнее всего во втором мозге.

Ответ, который мы в конце концов нашли, заключался в понимании намерения.

Обычный информационный инструмент обычно начинается с того, что пользователь уже ввел. Если пользователь пишет предложение, он может его пересмотреть. Если пользователь задает вопрос, он может ответить. Если пользователь сохраняет статью, он может суммировать ее.

Но многие человеческие намерения вначале не выражены ясно. Иногда у нас есть лишь смутное ощущение, что что-то имеет значение, но мы не знаем, что нас действительно волнует. Иногда мы собираемся встретиться с кем-то важным и помним много информации, но не знаем, что стоит сказать больше всего. Иногда мы знаем, какое чувство хотим выразить, но не можем найти подходящие слова.

Если бы второй мозг мог объединить текущий контекст пользователя с этими невысказанными намерениями, он мог бы делать больше, чем просто обрабатывать существующую информацию. Он начнет участвовать в процессе, посредством которого человек формирует выражение или суждение.

Основываясь на этой идее, в середине года мы задумали продукт под названием Sayso.

Опираясь на текущий контекст человека, продукт помогал бы ему увидеть, что можно сказать дальше. Мы не хотели, чтобы ИИ решал за пользователя, каково его истинное намерение. Мы хотели предложить возможные направления, среди которых пользователь смог бы узнать то, что действительно хотел выразить.

Эта потребность возникает во многих реальных ситуациях. Перед встречей с важным человеком или важным разговором людям обычно есть что сказать. Проблема в том, чтобы понять, какая часть большого объема информации важнее всего именно сейчас.

Sayso пытался сжать большую цель понимания скрытых намерений человека в одну конкретную задачу: использовать текущий контекст человека, чтобы раскрыть намерения, которые он еще не выразил.

Мы думали, что наконец нашли кинжал внутри обширной идеи второго мозга.

Мы приняли «малое» за «острое»

В середине года мы перешли от большого продукта к маленькому, и скорость нашей разработки заметно возросла.

Но во время этого сдвига наше понимание кинжала по-прежнему ограничивалось его внешней формой.

Мы думали, что меньший размер сделает продукт кинжалом. Мы думали, что меньшее число функций сделает его кинжалом. Позже мы также приняли новизну и скорость разработки за остроту: если продукт выглядел новым, быстро создавался и быстро доходил до пользователей, он казался ближе к верному ответу, чем швейцарский армейский нож, который мы строили раньше.

В середине года мы создали Sayso за очень короткое время и передали его бета-пользователям.

Отзывы показали, что некоторым людям действительно нужна помощь, чтобы выразить себя перед важной встречей или разговором, и что они понимают ценность выявления намерений из контекста. Это стало первым свидетельством того, что выбранная нами проблема реальна, а не просто звучит ново.

Но сам продукт не работал.

Демо ИИ, понимающего намерение, могло ограничиться впечатляющим результатом на нескольких тщательно подготовленных примерах. Настоящий продукт должен был показать пользователям, какой контекст предоставить, помочь понять причины конкретных подсказок и позволить естественно редактировать, выбирать или отклонять их.

Интерфейс должен был вызывать доверие. Взаимодействия не могли создать новое бремя. Эти функции должны были поддерживать пользователя на протяжении всей задачи. В то же время система должна была быть надежной, простой в обслуживании и улучшении.

Ни одна из этих вещей, взятая по отдельности, не обязательно была за пределами нас. Трудность заключалась в том, чтобы сделать их все достаточно хорошими одновременно в течение ограниченного периода времени.

Пользователи могли быстро выявлять проблемы, но мы не умели решать их одновременно быстро и качественно. Иногда мы дорабатывали функцию в ущерб общему впечатлению. Иногда улучшали одну часть опыта, усложняя сопровождение базовой системы. Иногда основную возможность уже можно было продемонстрировать, но пользователь все равно не мог гладко пройти весь путь от начала до конца.

Бета-тестирование не было бессмысленным. По крайней мере, это позволило нам подтвердить наличие необходимости.

Но наличие необходимости не означает, что продукт работает. Работающий продукт не означает, что рынок работает.

Поскольку качество реализации стояло между пользователями и основной ценностью, мы по-настоящему не проверяли, сможет ли Sayso постоянно обеспечивать эту ценность, и тем более, захотят ли достаточное количество людей использовать его с течением времени.

Возможно, мы уже видели проблему, которую должен пронзить кинжал, но нам все еще не хватало способности превратить это понимание в кинжал, которым кто-то действительно смог бы пользоваться.

Глаз мог видеть, но рука еще не могла сделать

После выпуска Sayso мы изначально связывали проблему с недостаточной скоростью итерации. Пользователи оставляли нам отзывы, поэтому ответ, казалось, заключался в том, чтобы продолжать двигаться небольшими шагами и быстрее менять продукт.

Но вскоре мы обнаружили, что скорость — не единственная проблема.

Перед выпуском продукта мы уже знали, что он не очень хорош. Многие проблемы в отзывах пользователей не выходили за рамки нашего собственного суждения. Нам не хватало не глаза, чтобы отличить хороший продукт от плохого, а руки, которая могла бы быстро превратить это суждение в продукт.

Глаз уже мог видеть. Рука еще не могла сделать.

Это не означало, что все, что мы узнали о продуктах в 2024 году, было неверным.

В течение 2025 года MagicGourd оставался в сети и поддерживался. Новые функции появлялись медленнее, но существующий сервис продолжал работать. К концу года у MagicGourd было около 3000 пользователей, и отзывы в целом оставались положительными. Нам не было известно ни об утере или повреждении каких-либо пользовательских данных в течение года.

В 2024 году мы узнали, как превратить демо в программное обеспечение, способное работать во времени: как справляться с синхронизацией, конфиденциальностью, совместимостью и сбоями; как поддерживать сервис, от которого зависят реальные пользователи; и как отвечать за данные, которые человек может накапливать многие годы.

Эти возможности по-прежнему имели значение. Они сделали MagicGourd чем-то большим, чем демонстрация, и позволили нам сохранять ответственность перед существующими пользователями, даже когда темп появления новых функций снизился.

Но 2025 год открыл еще один уровень возможностей.

Мы все еще не умели превращать потребности в четкое определение продукта. Нам не удалось создать отточенный и естественный интерфейс и процесс взаимодействия за короткое время. Мы также не могли одновременно надежно сбалансировать опыт, функциональность, надежность и удобство обслуживания.

У нас были знания в области алгоритмов и способности к системному проектированию. Когда появлялась идея, мы могли быстро реализовать ее техническую основу. Но работающая технология не означала работающий продукт. Настоящая сила продукта заключалась в том, чтобы сжать множество суждений, которые ограничивали друг друга, в нечто, что пользователь воспринимал как простое, ясное и полное.

Вступая во вторую половину года, мы наконец признали, что возможности нашего продукта еще не могут удовлетворить наши амбиции.

Сначала научитесь затачивать лезвие

Мы определили вторую половину года как период наращивания потенциала.

Принятие решения было трудным. В конце первого полугодия мы только что приложили немало усилий, чтобы понять, почему нам следует встречаться с клиентами как можно раньше. Однако во втором полугодии мы решили перестать торопить пользователей с каждым незавершенным продуктом и сначала научиться хорошо создавать продукты.

На первый взгляд это выглядело как уход с рынка обратно внутри компании. Но проблема, которую мы хотели решить, не была той, на которую мог ответить только рынок.

Пользователи могли сказать нам, реальна ли потребность, создает ли продукт ценность и хотят ли они продолжать его использовать. Но если даже мы считали интерфейс несовершенным, уже знали, что поток взаимодействия неполный, или знали, что проблемы с надежностью скроют основную ценность, предоставление продукта пользователям не даст больше полезной информации по центральному вопросу.

Рынок должен помочь нам ответить на неизвестные вопросы, а не повторять ответы, которые мы уже знали.

Поэтому мы начали неоднократно изучать продукты, которыми мы искренне восхищаемся. Мы разобрали их структуру, визуальный дизайн и взаимодействие, задаваясь вопросом, почему каждая деталь была обработана определенным образом. Путем тщательного изучения и повторной реализации мы превратили суждения, которые могли видеть, в вещи, которые сделали сами. Затем мы сравнили различия и попробовали еще раз, пока не поняли, почему эти превосходные продукты кажутся простыми, естественными и законченными.

Тщательное изучение не заключалось в копировании поверхности продукта или поиске ответа, который мы могли бы унести без изменений. Это больше походило на практику, посредством которой кто-то учится рисованию, музыке или каллиграфии: сначала тренируйте глаз, чтобы различать разницу, затем позволяйте руке постепенно догонять ее, и только потом применяйте эту способность к собственной проблеме.

Возможности продукта содержат большое количество подобных неявных знаний. Понимание идеи или даже точная оценка чужого продукта не означает, что мы сами обладаем такими возможностями. Только превратив суждения в интерфейсы, взаимодействия и системы посредством повторяющегося конкретного выбора, мы сможем по-настоящему стать частью команды.

К концу года мы все еще не могли доказать, что способны последовательно создавать отличные продукты. Но в середине года все, что мы могли сделать, — это смутно почувствовать, что «этот продукт нехороший». В конце концов, мы могли бы разбить это суждение на более конкретные вопросы: как должна быть организована информация, как должно развиваться взаимодействие, как визуальные детали должны поддерживать целое и как системные ограничения повлияют на опыт. Затем мы могли бы тренировать эти способности одну за другой посредством декомпозиции, тщательного изучения, повторной реализации и перестройки.

Эти изменения по-прежнему были лишь результатами внутренней практики и не могли заменить тестирование реальных пользователей. Что мы могли сказать, так это то, что мы начали формировать более конкретный способ практики, и что расстояние между нашими глазами и нашими руками начало сужаться.

Сбор средств – это не только деньги

Оглядываясь назад, можно сказать, что точка зрения, которую Kehan высказал в начале года, медленно подтверждалась.

Получение инвестиций было важным, но деньги — это не все, что дал нам MiraclePlus. Руководство наставников и беседы с коллегами не обязательно сразу же обернутся пользователями, доходом или успешным продуктом. К концу года я не мог сказать, что эти отношения дали прямой результат. Но метафора кинжала Peter уже вошла в наш ежедневный подход к оценке продуктов.

Она продолжала заставлять нас пересматривать наши продукты. Всякий раз, когда мне казалось, что я понял это, более поздняя практика показывала мне, что я понял только одну часть.

Сначала я думал, что это означает выделить из огромного второго мозга что-то меньшее. Позже я решил, что малое, быстрое и эффектное — значит острое. Еще позже я понял, что настоящий кинжал не работает лишь потому, что он мал: он должен сосредоточить полноценный опыт использования продукта на одной конкретной проблеме.

Ускоритель не сделал для нас кинжал, но помог нам быстрее понять, почему вещь в наших руках еще не таковой.

Вот что значит сказать, что сбор средств — это не только деньги. Возможно, оно не даст немедленного ответа, но может изменить то, как мы задаем вопросы, оцениваем себя и продолжаем учиться.

Настоящая острота требует и полноты

К концу 2025 года мое понимание кинжала отличалось от того, что было в начале года.

Понимание проблемы пользователя было острием. Взаимодействие, интерфейс и опыт использования продукта образовывали режущую кромку. Функциональная завершенность была телом клинка. Надежность и сопровождаемость служили рукоятью и основой, позволяя человеку действительно держать кинжал и пользоваться им.

Одно острое острие может в лучшем случае стать впечатляющим демо. Это еще не кинжал, которым действительно можно пользоваться.

Полнота не означала вложение всего в продукт. Швейцарский армейский нож может решить множество проблем, но ни одну из них он не сможет проникнуть достаточно глубоко.

Истинная полнота означала завершение всего пути, необходимого пользователю, вокруг одной основной ценности. Каждая часть продукта должна была указывать на одну и ту же проблему и поддерживать другие части, а не использовать дополнительные функции, чтобы скрыть тот факт, что основная проблема осталась нерешенной.

В 2023 году я покинул SenseTime и прыгнул в следующую реку. В 2024 году мы создали тыкву и начали понимать, почему продукт должен работать с течением времени. В 2025 году мы хотели, чтобы волшебство наконец появилось, а также попытались превратить огромный второй мозг в кинжал.

Магия еще не появилась, и Sayso еще не стал работающим продуктом. Несмотря на то, что теперь мы могли видеть необходимость, нам все еще не хватало возможности построить его быстро и качественно.

Но в течение года мы, по крайней мере, стали более четко видеть, чего нам не хватает.

Стремление к остроте не заставило нас отказаться от полноты, надежности или долгосрочной ответственности. Мы также начали понимать, что ранняя встреча с клиентами не означает передачу им продукта, который мы сами уже считали плохим, а быстрая итерация не сводится к одной лишь скорости разработки.

На сегодняшний день мы еще не создали этот полностью сформированный кинжал.

Мы только начали учиться его затачивать.

Одно острие — еще не кинжал.

Trước khi phát hành nó, tôi đã biết nó chưa đủ tốt.

Giao diện của nó thiếu bóng bẩy, các tương tác chưa có cảm giác tự nhiên và quy trình chức năng chưa hoàn thiện. Chúng tôi có thể thấy nhiều vấn đề mà không cần chờ phản hồi của người dùng. Điều đáng lo ngại hơn là những vấn đề này không thể tách rời nhau. Giao diện, trải nghiệm người dùng, tính hoàn chỉnh về chức năng, độ tin cậy và khả năng bảo trì đều phải hoạt động cùng lúc trước khi chúng có thể tạo thành một sản phẩm hoàn chỉnh.

Nhưng chúng tôi vừa dành nhiều tháng để tiếp thu một loạt phương pháp khởi nghiệp: gặp gỡ khách hàng sớm, thực hiện từng bước nhỏ và lặp lại nhanh chóng. Vì vậy, mặc dù không hài lòng với sản phẩm nhưng chúng tôi vẫn tin rằng mình nên phát hành nó trước.

Người dùng đã nhanh chóng nêu ra nhiều vấn đề. Chúng tôi đã biết về một số lượng đáng kể trong số đó trước khi phát hành. Phản hồi của họ đã trở thành điểm khởi đầu cho sự thay đổi mà chúng tôi đã thực hiện trong nửa cuối năm nay.

Nhìn lại, bản thử nghiệm beta đó đã chia năm 2025 thành hai nửa. Trong nửa đầu, chúng tôi tiếp tục xây dựng MagicGourd, hy vọng cuối cùng sẽ làm cho điều kỳ diệu của nó xuất hiện. Vào giữa năm, chúng tôi trích xuất một ý tưởng vào Sayso, xây dựng nó một cách nhanh chóng và đưa nó đến với người dùng. Trong nửa sau, thay vì tiếp tục theo đuổi tốc độ phát hành, chúng tôi chuyển sang xây dựng khả năng sản phẩm của mình. Điểm khởi đầu cho tất cả những điều này là vào đầu năm, khi chúng tôi nhận được đầu tư từ MiraclePlus và tham gia chương trình tăng tốc của nó.

Đến cuối năm chúng tôi vẫn chưa làm được con dao đó. Nhưng chúng tôi đã bắt đầu hiểu: chỉ một đầu lưỡi dao không phải là một con dao găm.

Một cuộc phỏng vấn mà tôi không có ý định tham dự

Vào đầu năm 2025, tôi không có kế hoạch huy động tiền.

Vào năm 2024, chúng tôi đã dành phần lớn thời gian để xây dựng MagicGourd và phát hành 27 phiên bản. Những nỗ lực gây quỹ hạn chế của chúng tôi chẳng dẫn đến đâu và sản phẩm vẫn còn cách xa “bộ não thứ hai thực sự” mà chúng tôi đã hình dung. Nhưng tôi vô cùng thích thú với quá trình xây dựng nó.

Tôi nghĩ chúng tôi có thể tiếp tục ở quy mô rất nhỏ, tiến từng bước một mà không cần vội vàng đầu tư.

Kehan đã thay đổi quyết định của tôi. Anh ấy nói với tôi rằng việc gây quỹ không nhất thiết chỉ là tiền. Chương trình tăng tốc của MiraclePlus, những người cố vấn và cựu sinh viên của nó cũng có thể giúp chúng tôi trong thời gian dài hơn nhiều.

Khi đó, thời hạn nộp đơn đã trôi qua. Nhưng tôi không muốn lãng phí đề xuất của Kehan nên tôi vẫn gửi đơn đăng ký, mô tả ngắn gọn cách tôi nghĩ về bộ não thứ hai thực sự.

Cuộc phỏng vấn này diễn ra tại văn phòng MiraclePlus ở Bắc Kinh. Trong khi chờ đợi, tôi nhìn thấy một số gợi ý phỏng vấn trên màn hình: câu trả lời phải đơn giản, trực tiếp và trung thực.

Trong cuộc phỏng vấn một năm trước, tôi đã vô thức tìm kiếm những câu trả lời mà các nhà đầu tư muốn nghe. Khi họ liên tục thách thức ý tưởng của chúng tôi, tôi lo lắng rằng câu trả lời của mình chưa đủ tốt. Bởi vì tôi tôn trọng những người ngồi cùng bàn nên tôi thậm chí có thể bắt đầu nghi ngờ khả năng phán đoán của chính mình.

Lần này, tôi không vội vàng như vậy.

Sau trọn một năm phát triển vào năm 2024, chúng tôi vẫn ở trong nước, nhưng không còn chật vật như vừa mới nhảy vào. Tôi đã không cố gắng chứng minh rằng mình phải đúng và cũng chưa chuẩn bị sẵn những câu trả lời trau chuốt kỹ càng. Tôi chỉ nói những gì tôi thực sự nghĩ.

Tiến sĩ Lu Qi hỏi tôi nghĩ gì về SenseTime. Tôi nói rằng, trước hết, tôi vô cùng biết ơn công ty, vì tôi đã trải qua một giai đoạn trưởng thành và chuyển đổi quan trọng ở đó. Xung quanh sự xuất hiện của ChatGPT, SenseTime có thể đã phản ứng hơi chậm vì một con tàu lớn khó quay đầu. Nhưng đến năm 2025, tôi có thể thấy nó sẽ thay đổi nhanh chóng và tôi tin rằng một kỷ nguyên tốt đẹp hơn cho SenseTime sẽ đến.

Sau đó anh ấy hỏi tôi nghĩ gì về DeepSeek. Câu trả lời của tôi chỉ có một từ: chi phí. Tôi đã không nói chi tiết vào thời điểm đó. Tôi chỉ đơn giản tin rằng chi phí sẽ ảnh hưởng trực tiếp đến quy mô mà công nghệ có thể áp dụng vào thế giới thực.

Cuộc phỏng vấn diễn ra suôn sẻ hơn tôi mong đợi. Có lẽ vì tôi không còn khao khát một kết quả cụ thể nào nên việc nói chuyện trở nên đơn giản hơn.

LSau đó, MiraclePlus đã đầu tư vào chúng tôi và chúng tôi đã tham gia chương trình tăng tốc.

Chúng tôi muốn phép thuật cuối cùng xuất hiện

Nếu mục tiêu vào năm 2024 là tạo ra quả bầu đầu tiên, thì vào đầu năm 2025, chúng tôi muốn điều kỳ diệu của nó cuối cùng cũng xuất hiện.

Vào năm 2024, chúng tôi đã tập trung cao độ và hoàn thành phiên bản MagicGourd 0.27. Nó giúp mọi người đánh dấu những gì đã thúc đẩy họ trên các trang web, PDF trực tuyến và video, ghi lại những suy nghĩ nảy sinh và lưu giữ tất cả những điều đó theo thời gian.

Nhưng nó vẫn gần với một vật chứa hơn. Nó có thể thu thập và quản lý hồ sơ của một người, nhưng nó không thể thực sự hiểu được chúng, càng không thể giúp ai đó khám phá những suy nghĩ còn dang dở.

Vì vậy, khi lên kế hoạch cho năm 2025, chúng tôi đã đặt ra cho mình một mục tiêu lớn hơn nhiều. Chúng tôi sẽ không còn hài lòng với việc thêm các tính năng nữa. Chúng tôi muốn thực hiện một bước thực sự hướng tới bộ não thứ hai thực sự mà chúng tôi đã tưởng tượng.

Chúng tôi muốn hiểu hồ sơ dài hạn của một người, tìm các kết nối nằm rải rác ở các thời điểm khác nhau và các phần nội dung khác nhau, hiểu người dùng đang nghĩ gì vào thời điểm đó và nhận ra những ý định mà họ chưa thể hiện rõ ràng.

Mục tiêu rất thú vị. Nó cũng vượt xa phạm vi chúng tôi có thể quản lý vào thời điểm đó.

Trong nửa đầu năm, chúng tôi đã nỗ lực rất nhiều để phát triển. Vấn đề không phải là thiếu sự chăm chỉ mà là số lượng việc phải giải quyết cùng một lúc. Mỗi bước tiến về phía trước lại đặt ra nhiều câu hỏi hơn. Phạm vi tiếp tục mở rộng, trong khi tốc độ phát triển của chúng tôi ngày càng chậm lại. Nửa năm trôi qua mà chúng tôi vẫn chưa đưa ra giá trị quan trọng nhất trước mặt người dùng.

Sau khi tham gia chương trình tăng tốc của MiraclePlus, chúng tôi liên tục nghe thấy một từ: sharp.

Người cố vấn của tôi về máy gia tốc, Peter, đã nhiều lần nói với chúng tôi rằng một công ty khởi nghiệp nên chế tạo một con dao găm chứ không phải một con dao quân đội Thụy Sĩ.

Khi nửa đầu năm sắp kết thúc, chúng tôi bắt đầu nghĩ vấn đề là sản phẩm đã trở nên quá lớn. Nếu chúng ta không thể xây dựng bộ não thứ hai thực sự cùng một lúc, thì chúng ta nên trích xuất yếu tố quan trọng nhất của nó và biến nó thành một sản phẩm nhỏ, nhanh và tuyệt vời.

Vào thời điểm đó, chúng tôi nghĩ rằng đó chính là ý nghĩa của một con dao găm.

Bộ não thứ hai nên hiểu những ý định chưa được nói ra

Chúng tôi liên tục hỏi điều gì quan trọng nhất trong bộ não thứ hai.

Câu trả lời của chúng tôi cuối cùng tìm thấy là sự hiểu biết ý định.

Một công cụ thông tin thông thường thường bắt đầu bằng những gì người dùng đã nhập. Nếu người dùng viết một câu, nó có thể sửa lại nó. Nếu người dùng đặt câu hỏi, nó có thể trả lời. Nếu người dùng lưu một bài viết, nó có thể tóm tắt nó.

Nhưng nhiều ý định của con người không được thể hiện rõ ràng ngay từ đầu. Đôi khi chúng ta chỉ có cảm giác mơ hồ rằng có điều gì đó quan trọng mà không biết mình thực sự quan tâm đến điều gì. Đôi khi chúng ta sắp gặp một người quan trọng và có rất nhiều thông tin trong đầu nhưng lại không biết điều gì đáng nói nhất. Đôi khi chúng ta biết cảm xúc mình muốn diễn đạt nhưng không tìm được từ ngữ thích hợp.

Nếu bộ não thứ hai có thể kết hợp bối cảnh hiện tại của người dùng với những ý định không thành lời này, nó sẽ làm được nhiều việc hơn là chỉ xử lý thông tin hiện có. Nó sẽ bắt đầu tham gia vào quá trình mà qua đó một người hình thành biểu hiện hoặc phán đoán.

Dựa trên ý tưởng này, chúng tôi đã hình thành một sản phẩm có tên Sayso vào giữa năm nay.

Sử dụng bối cảnh hiện tại của người đó, nó sẽ giúp họ biết họ có thể nói gì tiếp theo. Chúng tôi không muốn AI quyết định ý định thực sự của người dùng đối với họ. Chúng tôi muốn nó đưa ra những hướng khả thi để từ đó người dùng có thể nhận ra điều họ thực sự muốn thể hiện.

Nhu cầu này xuất hiện trong nhiều tình huống thực tế. Trước khi gặp một người quan trọng hoặc bắt đầu một cuộc trò chuyện quan trọng, mọi người thường không thiếu điều gì để nói. Vấn đề là biết phần nào của lượng lớn thông tin quan trọng nhất vào thời điểm đó.

Sayso đã cố gắng nén mục tiêu lớn là hiểu ý định tiềm ẩn của một người thành một nhiệm vụ cụ thể: sử dụng bối cảnh hiện tại của người đó để khám phá những ý định mà họ chưa bày tỏ.

Chúng tôi nghĩ rằng cuối cùng chúng tôi đã tìm thấy một con dao găm bên trong ý tưởng rộng lớn về bộ não thứ hai.

Chúng tôi đã nhầm “Nhỏ” với “Sắc nét”

Vào giữa năm, chúng tôi đã chuyển từ một sản phẩm lớn sang một sản phẩm nhỏ, và công ty của chúng tôi tốc độ phát triển tăng lên đáng kể.

Nhưng trong quá trình thay đổi này, sự hiểu biết của chúng tôi về một con dao găm vẫn bị giới hạn ở hình thức bên ngoài của nó.

Chúng tôi nghĩ rằng việc làm cho sản phẩm nhỏ hơn sẽ khiến nó trở thành một con dao găm. Chúng tôi nghĩ rằng ít tính năng hơn sẽ khiến nó trở thành một con dao găm. Sau đó, chúng tôi cũng nhầm lẫn tính mới và tốc độ phát triển với độ sắc bén: nếu một sản phẩm có cảm giác mới, có thể được chế tạo nhanh chóng và có thể đến tay người dùng nhanh chóng, thì sản phẩm đó có vẻ gần với câu trả lời đúng hơn con dao Quân đội Thụy Sĩ mà chúng tôi đang chế tạo.

Vào giữa năm, chúng tôi đã xây dựng Sayso trong thời gian rất ngắn và cung cấp nó cho người dùng phiên bản beta.

Phản hồi của họ cho chúng tôi thấy rằng một số người thực sự cần trợ giúp để thể hiện bản thân trước một cuộc họp hoặc cuộc trò chuyện quan trọng và họ có thể hiểu được giá trị của việc khám phá ý định từ ngữ cảnh. Điều này đưa ra bằng chứng ban đầu cho thấy vấn đề mà chúng tôi nhắm tới là có thật chứ không chỉ đơn thuần là một ý tưởng nghe có vẻ mới lạ.

Nhưng bản thân sản phẩm đã không hoạt động.

Bản demo AI về việc hiểu ý định có thể chỉ cần tạo ra kết quả đáng ngạc nhiên trong một số ví dụ được chuẩn bị cẩn thận. Một sản phẩm thực sự phải cho người dùng biết bối cảnh cần cung cấp, giúp họ hiểu lý do tại sao sản phẩm đó đưa ra những đề xuất cụ thể và để họ chỉnh sửa, chọn hoặc từ chối những đề xuất đó một cách tự nhiên.

Giao diện phải truyền được niềm tin. Các tương tác không thể tạo ra gánh nặng mới. Các tính năng phải hỗ trợ người dùng trong toàn bộ tác vụ. Đồng thời, hệ thống phải đáng tin cậy, dễ bảo trì và cải tiến.

Không có điều nào trong số này, xét riêng lẻ, nhất thiết nằm ngoài khả năng của chúng tôi. Khó khăn là làm cho tất cả chúng đủ tốt cùng một lúc trong một khoảng thời gian giới hạn.

Người dùng có thể xác định vấn đề một cách nhanh chóng, nhưng chúng tôi không thể giải quyết chúng một cách nhanh chóng và tốt. Đôi khi chúng tôi hoàn thành một tính năng mà phải trả giá bằng trải nghiệm tổng thể. Đôi khi chúng tôi cải thiện một phần trải nghiệm trong khi khiến hệ thống cơ bản khó bảo trì hơn. Đôi khi khả năng cốt lõi có thể đã được chứng minh, nhưng người dùng vẫn không thể hoàn thành toàn bộ hành trình một cách suôn sẻ.

Thử nghiệm beta không phải là vô nghĩa. Ít nhất nó cho phép chúng tôi xác nhận rằng nhu cầu đã tồn tại.

Nhưng sự tồn tại của nhu cầu không có nghĩa là sản phẩm hoạt động. Một sản phẩm hoạt động không có nghĩa là thị trường cũng hoạt động.

Vì chất lượng triển khai đứng giữa người dùng và giá trị cốt lõi nên chúng tôi chưa thực sự kiểm tra xem liệu Sayso có thể cung cấp giá trị đó một cách nhất quán hay không, chứ đừng nói đến việc liệu có đủ người muốn sử dụng nó theo thời gian hay không.

Chúng tôi có thể đã thấy vấn đề mà con dao găm sẽ xuyên qua, nhưng chúng tôi vẫn thiếu khả năng biến thông tin chuyên sâu đó thành con dao găm mà ai đó thực sự có thể sử dụng.

Mắt có thể nhìn thấy nhưng tay chưa thể làm được

Sau khi phát hành Sayso, ban đầu chúng tôi cho rằng vấn đề là do tốc độ lặp lại không đủ. Người dùng đã phản hồi cho chúng tôi nên câu trả lời dường như đang tiếp tục tiến triển theo từng bước nhỏ và thay đổi sản phẩm nhanh hơn.

Nhưng chúng tôi sớm phát hiện ra rằng tốc độ không phải là vấn đề duy nhất.

Trước khi phát hành sản phẩm, chúng tôi đã biết nó không tốt. Nhiều vấn đề trong phản hồi của người dùng đã không vượt quá khả năng phán đoán của chúng tôi. Thứ chúng ta thiếu không phải là con mắt để phân biệt sản phẩm tốt với sản phẩm xấu mà là bàn tay có thể nhanh chóng biến phán đoán đó thành sản phẩm.

Con mắt đã có thể nhìn thấy rồi. Bàn tay vẫn chưa thể tạo ra.

Điều này không có nghĩa là mọi thứ chúng tôi đã học về sản phẩm vào năm 2024 đều sai.

Trong suốt năm 2025, MagicGourd vẫn trực tuyến và duy trì. Các tính năng mới đến chậm hơn nhưng dịch vụ hiện tại vẫn tiếp tục chạy. Đến cuối năm đó, MagicGourd đã có khoảng 3.000 người dùng và phản hồi nhìn chung vẫn tích cực. Chúng tôi không biết về bất kỳ dữ liệu người dùng nào bị mất hoặc bị hỏng trong năm.

Vào năm 2024, chúng tôi đã học cách biến bản demo thành phần mềm có thể hoạt động theo thời gian: cách xử lý đồng bộ hóa, quyền riêng tư, khả năng tương thích và lỗi; cách duy trì dịch vụ mà người dùng thực sự phụ thuộc vào; và cách chịu trách nhiệm về dữ liệu mà một người có thể tích lũy trong nhiều năm.

Những khả năng đó vẫn quan trọng. Họ biến MagicGourd không chỉ là một cuộc biểu tình và cho phép chúng tôi duy trì trách nhiệm với người dùng hiện tại ngay cả khi tốc độ của các tính năng mới chậm lại.

Nhưng năm 2025 đã bộc lộ một lớp khả năng khác.

Chúng tôi vẫn chưa giỏi trong việc biến nhu cầu thành một định nghĩa rõ ràng về sản phẩm. Chúng tôi không giỏi trong việc tạo ra giao diện và luồng tương tác bóng bẩy, tự nhiên trong thời gian ngắn. Chúng tôi cũng không thể cân bằng một cách đáng tin cậy trải nghiệm, chức năng, độ tin cậy và khả năng bảo trì cùng một lúc.

Chúng tôi có chuyên môn về thuật toán và khả năng kỹ thuật hệ thống. Khi một ý tưởng xuất hiện, chúng tôi có thể nhanh chóng triển khai cốt lõi kỹ thuật của nó. Nhưng công nghệ hoạt động không có nghĩa là một sản phẩm hoạt động được. Sức mạnh thực sự của sản phẩm có nghĩa là nén nhiều phán đoán ràng buộc lẫn nhau thành một thứ mà người dùng trải nghiệm là đơn giản, rõ ràng và đầy đủ.

Khi bước vào nửa cuối năm, cuối cùng chúng tôi cũng thừa nhận rằng khả năng sản phẩm của chúng tôi chưa thể hỗ trợ tham vọng của chúng tôi.

Đầu tiên hãy học cách mài lưỡi dao

Chúng tôi xác định nửa cuối năm là khoảng thời gian để xây dựng năng lực.

Quyết định này thật khó khăn. Vào cuối hiệp một, chúng tôi mới đầu tư rất nhiều công sức để tìm hiểu lý do tại sao chúng tôi nên gặp khách hàng sớm. Tuy nhiên, trong nửa sau, chúng tôi quyết định ngừng vội vã mọi sản phẩm chưa hoàn thiện trước mặt người dùng và trước tiên hãy học cách xây dựng sản phẩm tốt.

Nhìn bề ngoài, điều này giống như việc rút lui khỏi thị trường trong nội bộ công ty. Nhưng vấn đề chúng tôi muốn giải quyết không phải là vấn đề mà chỉ thị trường mới có thể giải đáp.

Người dùng có thể cho chúng tôi biết liệu nhu cầu có thực sự hay không, sản phẩm có tạo ra giá trị hay không và liệu họ có muốn tiếp tục sử dụng nó hay không. Nhưng nếu ngay cả khi chúng tôi coi giao diện chưa được trau chuốt, đã biết rằng luồng tương tác chưa hoàn chỉnh hoặc biết rằng các vấn đề về độ tin cậy sẽ che khuất giá trị cốt lõi thì việc cung cấp sản phẩm cho người dùng sẽ không tạo ra nhiều thông tin hữu ích hơn về câu hỏi trọng tâm.

Thị trường sẽ giúp chúng tôi trả lời những câu hỏi chưa biết, không lặp lại những câu trả lời mà chúng tôi đã biết.

Vì vậy, chúng tôi bắt đầu nghiên cứu nhiều lần những sản phẩm mà chúng tôi thực sự ngưỡng mộ. Chúng tôi đã chia nhỏ cấu trúc, thiết kế hình ảnh và sự tương tác của họ, đồng thời hỏi tại sao mọi chi tiết lại được xử lý theo một cách cụ thể. Thông qua những nghiên cứu kỹ lưỡng và thực hiện lại, chúng tôi đã biến những nhận định mà chúng tôi có thể nhìn thấy thành những điều chúng tôi tự mình làm ra. Sau đó, chúng tôi so sánh sự khác biệt và thử lại cho đến khi hiểu được lý do tại sao những sản phẩm tuyệt vời này lại mang lại cảm giác đơn giản, tự nhiên và đầy đủ.

Nghiên cứu kỹ lưỡng không phải là sao chép bề mặt của sản phẩm hay tìm kiếm câu trả lời mà chúng tôi có thể mang theo mà không thay đổi. Nó giống như cách một người học hội họa, âm nhạc hoặc thư pháp hơn: đầu tiên rèn luyện mắt để nhận ra sự khác biệt, sau đó để tay dần dần bắt kịp và chỉ sau đó mới áp dụng khả năng đó vào một vấn đề của riêng mình.

Khả năng của sản phẩm chứa đựng rất nhiều kiến thức ngầm như thế này. Hiểu được một ý tưởng, hay thậm chí đánh giá chính xác sản phẩm của người khác, không có nghĩa là bản thân chúng ta có năng lực. Chỉ bằng cách biến các phán đoán thành các giao diện, tương tác và hệ thống thông qua các lựa chọn cụ thể được lặp đi lặp lại thì khả năng đó mới thực sự trở thành một phần của nhóm.

Đến cuối năm, chúng tôi vẫn không thể chứng minh được rằng mình có thể tạo ra những sản phẩm xuất sắc một cách nhất quán. Nhưng đến giữa năm, tất cả những gì chúng tôi có thể làm chỉ là mơ hồ cảm thấy “sản phẩm này không tốt”. Cuối cùng, chúng ta có thể chia phán đoán đó thành các câu hỏi cụ thể hơn: thông tin nên được tổ chức như thế nào, quá trình tương tác sẽ diễn ra như thế nào, các chi tiết trực quan sẽ hỗ trợ tổng thể như thế nào và các ràng buộc của hệ thống sẽ ảnh hưởng đến trải nghiệm như thế nào. Sau đó, chúng ta có thể rèn luyện từng khả năng này thông qua quá trình phân rã, nghiên cứu kỹ lưỡng, thực hiện lại và xây dựng lại.

Những thay đổi này vẫn chỉ là kết quả thực hành nội bộ và không thể thay thế thử nghiệm của người dùng thực. Điều chúng tôi có thể nói là chúng tôi đã bắt đầu hình thành một cách luyện tập cụ thể hơn và khoảng cách giữa mắt và tay của chúng tôi đã bắt đầu thu hẹp.

Gây quỹ không chỉ là về tiền

Nhìn lại, quan điểm mà Kehan đưa ra hồi đầu năm đang dần được xác nhận.

Nhận được khoản đầu tư là quan trọng nhưng tiền không phải là tất cả những gì MiraclePlus mang lại cho chúng tôi. Hướng dẫn từ người cố vấn và cuộc trò chuyện với đồng nghiệp không nhất thiết sẽ ngay lập tức trở thành người dùng, doanh thu hoặc sản phẩm thành công. Đến cuối năm, tôi không thể nói rằng những mối quan hệ này đã mang lại kết quả trực tiếp. Nhưng phép ẩn dụ con dao găm của Peter đã đi vào cách chúng tôi đánh giá sản phẩm hàng ngày.

Nó liên tục buộc chúng tôi phải kiểm tra lại sản phẩm của mình. Bất cứ khi nào tôi nghĩ mình đã hiểu, thực tế sau này cho tôi thấy rằng tôi chỉ hiểu được một phần.

Lúc đầu, tôi nghĩ điều đó có nghĩa là chia bộ não thứ hai rộng lớn thành một thứ nhỏ hơn. Sau này tôi nghĩ nhỏ, nhanh và mát có nghĩa là sắc bén. Sau này tôi mới nhận ra rằng một con dao găm thật không có tác dụng chỉ vì nó nhỏ. Nó phải tập trung trải nghiệm sản phẩm hoàn chỉnh vào một vấn đề cụ thể.

Máy gia tốc không tạo ra con dao găm cho chúng tôi, nhưng nó giúp chúng tôi sớm nhận ra lý do tại sao thứ trong tay chúng tôi vẫn chưa phải là một.

Đó là ý nghĩa của việc gây quỹ không chỉ là tiền. Nó có thể không đưa ra câu trả lời ngay lập tức, nhưng nó có thể thay đổi cách chúng ta đặt câu hỏi, đánh giá bản thân và tiếp tục học hỏi.

Độ sắc nét thực sự cũng đòi hỏi sự hoàn chỉnh

Vào cuối năm 2025, sự hiểu biết của tôi về một con dao găm đã khác so với những gì nó có vào đầu năm.

Cái nhìn sâu sắc về vấn đề của người dùng là đầu lưỡi dao. Tương tác, giao diện và trải nghiệm sản phẩm hình thành nên lợi thế. Sự hoàn thiện về chức năng là phần thân của lưỡi kiếm. Độ tin cậy và khả năng bảo trì giống như tay cầm, cho phép ai đó thực sự cầm và sử dụng nó.

Một đầu nhọn duy nhất nhiều nhất có thể trở thành một bản demo ấn tượng. Nó vẫn chưa phải là một con dao găm mà ai đó thực sự có thể sử dụng.

Sự hoàn thiện không có nghĩa là đưa mọi thứ vào sản phẩm. Một con dao quân đội Thụy Sĩ có thể giải quyết được nhiều vấn đề, nhưng nó có thể không đi sâu vào bất kỳ vấn đề nào.

Sự hoàn thiện thực sự có nghĩa là hoàn thành toàn bộ hành trình mà người dùng cần xoay quanh một giá trị cốt lõi. Mọi bộ phận của sản phẩm đều phải hướng tới cùng một vấn đề và hỗ trợ các bộ phận khác, thay vì sử dụng nhiều tính năng hơn để che giấu sự thật rằng vấn đề cốt lõi vẫn chưa được giải quyết.

Năm 2023, tôi rời SenseTime và nhảy sang con sông tiếp theo. Vào năm 2024, chúng tôi đã làm ra quả bầu và bắt đầu hiểu lý do tại sao một sản phẩm phải hoạt động theo thời gian. Vào năm 2025, chúng tôi muốn phép thuật cuối cùng xuất hiện và chúng tôi cũng cố gắng bẻ bộ não thứ hai rộng lớn thành một con dao găm.

Phép màu vẫn chưa xuất hiện và Sayso vẫn chưa trở thành một sản phẩm có thể hoạt động được. Mặc dù bây giờ chúng tôi có thể thấy được nhu cầu, nhưng chúng tôi vẫn thiếu khả năng xây dựng nó một cách nhanh chóng và tốt.

Nhưng trong suốt một năm, ít nhất chúng tôi đã thấy chính xác hơn những gì chúng tôi còn thiếu.

Việc theo đuổi sự sắc bén không khiến chúng tôi từ bỏ tính trọn vẹn, độ tin cậy hay trách nhiệm lâu dài. Chúng tôi cũng bắt đầu hiểu rằng việc gặp gỡ khách hàng sớm không có nghĩa là cung cấp cho họ một sản phẩm mà chúng tôi đã biết là kém và việc lặp lại nhanh chóng đó không có nghĩa là chỉ theo đuổi tốc độ phát triển.

Cho đến ngày nay, chúng tôi vẫn chưa tạo ra con dao găm có hình dạng hoàn chỉnh đó.

Chúng tôi chỉ mới bắt đầu học cách mài nó.

Chỉ có mũi dao thì chưa phải là một con dao găm.

推出之前，我其实已经知道它不够好。

它的界面缺少专业感，交互还不够自然，功能链路也不完整。即使不看用户反馈，我们也能发现很多问题。更麻烦的是，这些问题并不独立。UI、用户体验、功能完整性，以及背后的可靠性和可维护性，必须同时成立，才能构成一个完整的产品。

但当时我们刚刚反复学习了一套创业方法：尽早见客户，小步快跑，快速迭代。于是，即使对产品并不满意，我们仍然认为应该先把它推出去。

用户很快提出了很多问题。其中相当一部分，我们在推出以前就已经知道了。这些反馈后来成为我们在下半年改变方向的起点。

回头看，这次内测把 2025 年分成了两半。上半年，我们继续开发魔法葫芦，希望让魔法真正显现；年中，我们把其中一个想法拆成 Sayso，迅速做出来并推给用户；到了下半年，我们没有继续追赶发布速度，而是转向产品能力建设。这一切的起点，是年初我们拿到了奇绩创坛的投资，进入创业营。

到了年底，我们仍然没有做出那把匕首，却开始理解：只有刀尖，还不是匕首。

一场原本不打算参加的面试

2025 年初，我原本没有融资计划。

2024 年，我们把大部分时间都用来开发魔法葫芦，先后上线了 27 个版本。虽然融资没有结果，产品也远没有达到我们心目中“真正的第二大脑”，但做产品的过程本身让我非常享受。

我当时觉得，我们也可以继续保持很小的规模，一点一点往前做，不必急着拿投资。

科含改变了我的看法。他告诉我，融资不一定只是钱。奇绩创坛的创业营、导师和校友，也可能在未来很长的时间里帮助我们。

那时，报名已经超过了截止日期。但我不想辜负科含的推荐，还是提交了申请，简单写下了自己对“真正的第二大脑”的理解。

这一次面试在北京奇绩创坛的办公室。等待的时候，我看到屏幕上写着几条面试建议：回答应该简单、直接、真实。

一年前参加面试时，我还会不自觉地寻找投资人期待的答案。面对连续的挑战，我会担心自己的回答不够好，甚至因为尊重对方，而动摇自己原本的判断。

这一次，我没有那么急了。

经过 2024 年一整年的开发，我们仍然在水里，但已经不再像刚刚跳进去时那样挣扎。我没有试图证明自己一定正确，也没有准备太多修饰过的答案，只是把自己真实的判断说出来。

陆奇博士问我怎样看待商汤。我说，我首先非常感谢商汤，因为我在那里经历了成长和蜕变最关键的一段时期。在 ChatGPT 出现前后，商汤也许因为船大难掉头，反应稍微慢了一些；但到了 2025 年，我看到它正在快速改革，也相信商汤更好的时代正在到来。

他又问我怎样看待 DeepSeek。我的回答只有一个词：成本。我当时没有进一步展开，只是认为成本会直接影响一种技术进入真实世界的规模。

整个面试比我预想中顺畅。也许正因为我不再急于得到一个结果，表达反而变得简单了。

后来，我们拿到了奇绩创坛的投资，进入创业营。

我们想让魔法真正显现

如果说 2024 年的目标是先做出一只葫芦，那么 2025 年初，我们希望魔法能够真正显现。

2024 年，我们非常聚焦地完成了魔法葫芦 0.27 版。它可以帮助用户在网页、在线 PDF 和视频中标记触动，记录灵感，并把这些内容长期保存下来。

但它仍然更接近一个容器。它能够收集和管理一个人的记录，还不能真正理解这些记录，更不能帮助一个人发现那些尚未完成的思考。

所以，在制定 2025 年计划时，我们给自己定了一个很大的目标：不再满足于增加功能，而是向心目中真正的第二大脑前进一步。

我们想理解一个人的长期记录，找到散落在不同时间、不同内容之间的联系，进一步理解用户此时此刻正在思考什么，以及他还没有明确表达出来的意图。

这个目标让人兴奋，也远远超过了我们当时能够驾驭的范围。

上半年，我们投入了大量时间进行开发。不是我们不够努力，而是需要同时解决的问题太多了。每向前走一步，都会暴露出更多问题。产品的范围越来越大，开发节奏也越来越慢。半年过去，我们仍然没有把最重要的价值送到用户面前。

进入奇绩创业营以后，我们不断听到一个词：sharp。

我的创业营导师 Peter 反复告诉我们，创业是做一把匕首，而不是做一把瑞士军刀。

上半年接近结束时，我们开始相信，问题出在产品太大了。既然无法一次完成真正的第二大脑，就应该把其中最重要的一点剥离出来，做成一个足够小、足够快，也足够酷的产品。

当时我们以为，这就是匕首。

第二大脑应该理解尚未说出的意图

我们反复追问，第二大脑最重要的事情究竟是什么。

最后，我们找到的答案是对意图的理解。

一个普通的信息工具，通常从用户已经输入的东西开始工作。用户写下一句话，它可以帮忙修改；用户提出一个问题，它可以给出回答；用户保存一篇文章，它可以生成摘要。

但人的很多意图在一开始并没有被清楚地表达出来。有时，我们只是模糊地感到某件事很重要，却不知道自己真正关心的是什么；有时，我们马上要见一个重要的人，脑子里有很多信息，却不知道最值得说的是什么；有时，我们知道自己想表达一种感受，却找不到准确的语言。

如果第二大脑能够结合用户此时此刻的上下文，发现那些还没有被说出来的意图，它就不只是处理已有信息，而是开始参与到一个人形成表达和判断的过程中。

基于这个想法，到了年中，我们构想了一款叫作 Sayso 的产品。

它希望根据用户当下的上下文，帮助他看见接下来可以说什么。我们不希望 AI 替用户决定他的真实意图，而是希望它提出一些可能的方向，让用户从中辨认出自己真正想表达的东西。

这种需求出现在很多真实场景里。比如，在见一个重要的人或者开始一场重要谈话之前，人们往往并非无话可说，而是不知道怎样从大量信息中找到此刻最值得表达的内容。

Sayso 试图把“理解人的隐含意图”这个很大的目标，压缩成一个具体任务：结合用户当下的上下文，发现那些尚未说出的表达意图。

我们觉得，终于从庞大的第二大脑中找到了一把匕首。

我们把“小”误认为“锋利”

到了年中，我们从大产品转向小产品，开发速度明显变快了。

但在这次转向中，我们对“匕首”的理解仍然停留在它的外形上。

我们以为，把产品做小就是匕首，把功能做少就是匕首。后来，我们又把酷炫和开发速度当作锋利：只要一个产品足够新奇，能够很快做出来、很快送到用户面前，它似乎就比原来的瑞士军刀更接近正确答案。

年中，我们用很短的时间做出了 Sayso，并把它推给内测用户。

从这些反馈里，我们看到，一些用户确实会在重要见面或谈话之前需要表达上的帮助，也能理解基于上下文发现意图的价值。这初步印证了产品瞄准的问题是真实的，而不只是一个听起来新奇的想法。

但产品本身没有成立。

一个关于意图理解的 AI Demo，也许只需要在几个精心准备的例子里给出令人惊喜的结果。一款真正的产品，却必须让用户知道应该提供什么上下文、理解产品为什么给出这些建议，并能够自然地修改、选择或者放弃它们。

界面需要让人信任，交互不能制造新的负担，功能必须支撑用户完成整个任务。与此同时，系统还要足够可靠，并且便于持续维护和迭代。

这些事情中的任何一件，单独看都未必超出我们的能力。困难在于，我们无法在有限时间里，让它们同时达到一个足够好的状态。

用户可以很快提出问题，我们却不能又快又好地解决问题。有时我们补齐了一项功能，却损害了整体体验；有时我们让局部体验变得更好，背后的系统却更难维护；有时核心能力已经可以演示，用户仍然无法顺畅地完成一段完整的使用流程。

这次内测并非毫无意义。它至少让我们确认，需求存在。

但需求存在，不等于产品成立；产品成立，也不等于市场成立。

因为实现质量挡在了核心价值前面，我们还没有真正验证 Sayso 是否能够稳定地交付这种价值，更没有验证是否会有足够多的用户愿意长期使用它。

我们可能已经看见了匕首应该刺中的问题，却还没有能力把这个洞察变成一把能够被使用的匕首。

眼睛已经看见，手却做不到

Sayso 推出以后，我们一开始把问题归结为迭代还不够快。既然用户已经提出了反馈，那就继续小步快跑，更快地修改产品。

但很快我们发现，问题不只是速度。

在把产品推出去以前，我们自己已经知道它不好。用户反馈里的许多问题，并没有超出我们的判断。我们缺少的不是分辨产品好坏的眼睛，而是把这种判断快速变成产品的手。

眼睛已经看见，手却做不到。

这并不意味着我们在 2024 年关于产品的学习全部错了。

过去一年，魔法葫芦一直保持运营和维护。虽然新功能上线的速度变慢了，但原有服务仍然在运行。到了 2025 年年底，魔法葫芦已经有大约 3000 位用户，收到的反馈总体上也是正向的。这一年里，同样没有发生我们已知的用户数据丢失或损坏事故。

2024 年，我们学习的是怎样把一个 Demo 变成能够长期运行的软件：怎样处理同步、隐私、兼容和异常，怎样维护真实用户正在使用的服务，以及怎样对一个人长期积累的数据负责。

这些能力仍然重要。它们让魔法葫芦不只是一个演示，也让我们能够在新功能放慢以后，继续为已经使用它的用户负责。

但 2025 年暴露出来的是另一层能力。

我们还不擅长把一个需求变成清楚的产品定义，不擅长在很短时间里形成专业而自然的 UI 和交互，也不能稳定地同时兼顾体验、功能、可靠性和可维护性。

我们有算法能力，也有底层开发能力。一个想法出现以后，我们可以很快实现其中最核心的技术部分。但技术能够运行，并不意味着产品已经成立。真正的产品力，是把许多彼此牵制的判断压缩在一起，让用户感受到的是一个简单、清楚、完整的东西。

进入下半年后，我们终于承认，团队当时的产品能力还跟不上自己的野心。

先学习怎样磨刀

我们把下半年定义为能力建设期。

这个决定并不轻松。上半年后期，我们刚刚花了很大力气理解为什么要尽早见客户；到了下半年，我们却决定暂时不再把每一个半成品都急着推出去，而是先学习怎样把产品做好。

表面上看，这像是从市场缩回内部。但我们想解决的并不是一个只能由市场回答的问题。

用户可以告诉我们，需求是否真实，产品有没有产生价值，以及他们是否愿意继续使用。但如果一个界面连我们自己都觉得不够专业，一条交互链路明知没有走通，或者系统的可靠性问题还会遮住核心价值，把它交给用户并不会让我们获得更多关于核心问题的有效信息。

市场应该帮助我们回答未知的问题，而不是重复已经知道的答案。

于是，我们开始反复研究那些自己真正认可的产品。我们拆解它们的结构、视觉和交互，追问每一个细节为什么这样处理；也通过临摹和复现，把看到的判断变成自己实际做过的东西。做完以后再比较差距，重新修改，直到能够理解这些优秀产品为什么显得简单、自然和完整。

临摹不是为了复制一个产品的表面，也不是为了寻找可以直接搬走的答案。它更像学习绘画、音乐或者书法时的练习：先让眼睛学会分辨，再让手逐渐跟上眼睛，最后才可能把这种能力用在自己的问题上。

产品能力包含大量这样的隐性知识。听懂一个道理，甚至能够准确地评价别人的产品，都不等于自己已经拥有这种能力。只有在一次次具体取舍中，把判断落实为界面、交互和系统，这种能力才可能真正成为团队的一部分。

到了年底，我们还不能证明自己已经能够稳定地做出优秀产品。但与年中只能笼统地感到“这个产品不好”相比，我们开始能够把这种判断拆成更具体的问题：信息怎样组织，交互怎样推进，视觉细节怎样服务于整体，系统约束又会怎样影响体验。然后，我们可以通过拆解、临摹、复现和重做，逐项训练这些能力。

这些变化暂时仍然只是内部训练的结果，不能代替真实用户的检验。我们能够确认的是，自己开始形成一套更具体的练习方法，也开始缩短眼睛和手之间的距离。

融资不一定只是钱

回头看，科含年初对我说的那句话正在以一种很慢的方式得到验证。

拿到投资当然是一件重要的事，但钱并不是奇绩创坛带给我们的全部。导师的指导和同行之间的交流，不一定马上转化成用户数、收入或者一款成功的产品。到了年底，我还不能说这些关系已经带来了直接成果，但 Peter 关于匕首的比喻，已经进入了我们每天评价产品的方式。

这句话让我们不断重新审视自己的产品。每当我觉得已经理解它，后来的实践都会告诉我，我理解的仍然只是其中一部分。

一开始，我以为它要求我们把庞大的第二大脑拆小。后来，我以为小、快和酷就是锋利。再后来，我才意识到，一把真正的匕首并不因为尺寸小而成立，它必须把完整的产品体验集中在一个具体问题上。

创业营没有替我们做出那把匕首，却让我们更早看见，自己手里的东西为什么还不是匕首。

这也是融资不只是钱的含义。它未必立刻给出答案，却会改变我们提出问题、评价自己和继续学习的方式。

真正的锋利，也需要完整

到了 2025 年年底，我对“匕首”有了和年初不同的理解。

对用户问题的洞察是刀尖，交互、UI 和产品体验是刀刃，功能的完整性是刀身，可靠性和可维护性则像刀柄，让人能够真正握住并使用它。

只有一个尖锐的亮点，最多只能成为令人惊艳的 Demo，还不是一把真正能够被使用的匕首。

完整也不意味着把所有东西都做进去。瑞士军刀可以解决很多问题，却未必会围绕其中一个问题做到足够深入。

真正的完整，是围绕一个核心价值，把用户需要经过的整条链路做完整。产品里的每一部分都指向同一个问题，彼此支撑，而不是用更多功能掩盖产品还没有解决核心问题的事实。

2023 年，我离开商汤，跳进下一条河。2024 年，我们做出了葫芦，开始理解产品为什么必须在时间里成立。2025 年，我们希望让魔法真正显现，也尝试把庞大的第二大脑拆成一把匕首。

魔法还没有真正显现，Sayso 也还没有成为一款成立的产品。即使我们已经看见了需求，我们仍然缺少把它又快又好地做出来的能力。

但这一年，我们至少更准确地看见了自己缺少什么。

我们没有因为开始追求锋利，就放弃对完整性、可靠性和长期责任的要求。我们也逐渐明白，尽早见客户并不意味着把明知不好的产品交给用户，快速迭代也不意味着只追求开发速度。

到了今天，我们还没有做出那把真正成形的匕首。

我们只是开始学习怎样磨出它。

只有刀尖，还不是匕首。

推出之前，我其實已經知道它不夠好。

它的介面缺乏專業感，互動還不夠自然，功能連結也不完整。即使不看用戶回饋，我們也能發現很多問題。更麻煩的是，這些問題並不獨立。 UI、使用者體驗、功能完整性，以及背後的可靠性和可維護性，必須同時成立，才能構成一個完整的產品。

但當時我們剛剛反覆學習了一套創業方法：儘早見客戶，小步快跑，快速迭代。於是，即使對產品並不滿意，我們仍然認為應該先把它推出去。

用戶很快就提出了許多問題。其中相當一部分，我們在推出以前就已經知道了。這些回饋後來成為我們在下半年改變方向的起點。

回頭看，這次內測把 2025 年分了兩半。上半年，我們繼續開發魔法葫蘆，希望讓魔法真正顯現；年中，我們把其中一個想法拆成 Sayso，迅速做出來並推給用戶；到了下半年，我們沒有繼續追趕發布速度，而是轉向產品能力建設。這一切的起點，是年初我們拿到了奇績創壇的投資，進入創業營。

到了年底，我們仍然沒有做出那把匕首，卻開始理解：只有刀尖，還不是匕首。

一場原本不打算參加的面試

2025 年初，我原本沒有融資計畫。

2024 年，我們把大部分時間都用來開發魔法葫蘆，先後上線了 27 個版本。雖然融資沒有結果，產品也遠遠沒有達到我們心目中“真正的第二個大腦”，但做產品的過程本身讓我非常享受。

我當時覺得，我們也可以繼續保持很小的規模，一點一點往前做，不必急著拿投資。

科含改變了我的看法。他告訴我，融資不一定只是錢。 奇績創壇的創業營、導師和校友，也可能在未來很長的時間裡幫助我們。

當時，報名已經超過了截止日期。但我不想辜負科含的推薦，還是提交了申請，簡單寫下了自己對「真正的第二個大腦」的理解。

這次面試在北京奇績創壇的辦公室。等待的時候，看到螢幕上寫著幾個面試建議：回答應該是簡單、直接、真實。

一年前參加面試時，我還會不自覺地尋找投資人期待的答案。面對連續的挑戰，我會擔心自己的回答不夠好，甚至因為尊重對方，而動搖原本的判斷。

這一次，我沒有那麼急了。

經過 2024 年一整年的開發，我們仍然在水里，但已經不再像剛剛跳進去時那樣掙扎。我沒有試圖證明自己一定正確，也沒有準備太多修飾過的答案，只是把自己真實的判斷說出來。

陸奇博士問我怎麼看待商湯。我說，我首先非常感謝商湯，因為我在那裡經歷了成長和蛻變最關鍵的一段時期。在 ChatGPT 出現前後，商湯也許因為船大難掉頭，反應稍微慢了一些；但到了 2025 年，我看到它正在快速改革，也相信商湯更好的時代正在到來。

他又問我怎麼看待 DeepSeek。我的回答只有一個詞：成本。我當時沒有進一步展開，只是認為成本會直接影響一種技術進入真實世界的規模。

整個面試比我預想中更順暢。也許正因為我不再急於得到一個結果，表達反而變得簡單了。

後來，我們拿到了奇績創壇的投資，進入創業營。

我們想讓魔法真正顯現

如果說 2024 年的目標是先做出一隻葫蘆，那麼 2025 年初，我們希望魔法能真正顯現。

2024 年，我們非常聚焦地完成了魔法葫蘆 0.27 版。它可以幫助用戶在網頁、線上 PDF 和影片中標記觸動，記錄靈感，並把這些內容長期保存下來。

但它仍然更接近一個容器。它能夠收集和管理一個人的記錄，還不能真正理解這些記錄，更不能幫助一個人發現那些尚未完成的思考。

所以，在製定 2025 年計畫時，我們給自己定了一個很大的目標：不再滿足於增加功能，而是向心目中真正的第二個大腦前進一步。

我們想理解一個人的長期記錄，找到散落在不同時間、不同內容之間的聯繫，進一步理解用戶此時此刻正在思考什麼，以及他還沒有明確表達出來的意圖。

這個目標讓人興奮，也遠遠超過了我們當時所能駕馭的範圍。

上半年，我們投入了大量時間進行開發。不是我們不夠努力，而是需要同時解決的問題太多了。每向前走一步，都會暴露出更多問題。產品的範圍越來越大，開發節奏也越來越慢。半年過去，我們仍然沒有把最重要的價值送到用戶面前。

進入奇績創壇創業營以後，我們不斷聽到一個詞：sharp。

我的創業營導師 Peter 一再告訴我們，創業是做一把匕首，而不是做一把瑞士軍刀。

上半年接近結束時，我們開始相信，問題出在產品太大了。既然無法一次完成真正的第二大腦，就應該把其中最重要的一點剝離出來，做成一個足夠小、足夠快，也足夠酷的產品。

當時我們以為，這就是匕首。

第二大腦應該理解尚未說出的意圖

我們反覆追問，第二大腦最重要的事情究竟是什麼。

最後，我們找到的答案是對意圖的理解。

一個普通的資訊工具，通常從使用者已經輸入的東西開始工作。使用者寫下一句話，它可以幫忙修改；使用者提出一個問題，它可以給予答案；使用者保存一篇文章，它可以產生摘要。

但人的許多意圖在一開始並沒有被清楚地表達出來。有時，我們只是模糊地感覺到某件事很重要，卻不知道自己真正關心的是什麼；有時，我們馬上要見一個重要的人，腦子裡有很多信息，卻不知道最值得說的是什麼；有時，我們知道自己想表達一種感受，卻找不到準確的語言。

如果第二大腦能夠結合使用者此時此刻的上下文，發現那些還沒有被說出來的意圖，它就不只是處理已有訊息，而是開始參與到一個人形成表達和判斷的過程中。

基於這個想法，到了年中，我們構思了一款叫作 Sayso 的產品。

它希望根據用戶當下的上下文，幫助他看見接下來可以說什麼。我們不希望 AI 替用戶決定他的真實意圖，而是希望它提出一些可能的方向，讓使用者從中辨認出真正想表達的東西。

這種需求出現在許多真實場景。例如，在見一個重要的人或開始一場重要對話之前，人們往往並非無話可說，而是不知道如何從大量資訊中找到此刻最值得表達的內容。

Sayso 試圖把「理解人的隱含意圖」這個很大的目標，壓縮成一個具體任務：結合使用者當下的上下文，發現那些尚未說出的表達意圖。

我們覺得，終於從龐大的第二腦中找到了一把匕首。

我們把「小」誤認為「鋒利」

到了年中，我們從大產品轉向小產品，開發速度明顯變快了。

但在這次轉向中，我們對「匕首」的理解仍然停留在它的外形上。

我們以為，把產品做小就是匕首，把功能做少就是匕首。後來，我們又把酷炫和開發速度當作鋒利：只要一個產品夠新奇，能夠很快做出來、很快送到用戶面前，它似乎就比原來的瑞士軍刀更接近正確答案。在

年中，我們用很短的時間做了 Sayso，並把它推給內測用戶。

從這些回饋裡，我們看到，有些使用者確實會在重要見面或談話之前需要表達上的幫助，也能理解基於上下文發現意圖的價值。這初步印證了產品瞄準的問題是真的，而不只是一個聽起來新穎的想法。

但產品本身並沒有成立。

一個關於意圖理解的 AI Demo，也許只需要在幾個精心準備的例子中給出令人驚訝的結果。真正的產品，卻必須讓使用者知道應該提供什麼脈絡、理解產品為何給予這些建議，並且能夠自然地修改、選擇或放棄它們。

介面需要讓人信任，互動不能製造新的負擔，功能必須支撐使用者完成整個任務。同時，系統也要夠可靠，便於持續維護和迭代。

這些事情中的任何一件，單獨看都未必超出我們的能力。困難在於，我們無法在有限時間裡，讓它們同時達到足夠好的狀態。

用戶可以很快提出問題，但我們不能又快又好地解決問題。有時我們補齊了一項功能，卻損害了整體體驗；有時我們讓局部體驗變得更好，背後的系統卻更難維護；有時核心能力已經可以演示，用戶仍然無法順暢地完成一段完整的使用流程。

這次內測並非毫無意義。它至少讓我們確認，需求存在。

但需求存在，不等於產品成立；產品成立，也不等於市場成立。

因為實現品質擋在了核心價值前面，我們還沒有真正驗證 Sayso 是否能夠穩定地交付這種價值，更沒有驗證是否會有足夠多的用戶願意長期使用它。

我們可能已經看見了匕首應該刺中的問題，卻還沒有能力把這個洞察變成一把能夠被使用的匕首。

眼睛已經看見，手卻做不到

Sayso 推出以後，我們一開始把問題歸結為迭代還不夠快。既然用戶已經提出了回饋，那就繼續小步快跑，更快地修改產品。

但很快我們發現，問題不只是速度。

在把產品推出去以前，我們自己已經知道它不好。用戶回饋裡的許多問題，並沒有超出我們的判斷。我們缺少的不是分辨產品好壞的眼睛，而是把這種判斷快速變成產品的手。

眼睛已經看見，手卻做不到。

這並不意味著我們在 2024 年關於產品的學習全部錯了。

過去一年，魔法葫蘆一直保持營運和維護。雖然新功能上線的速度變慢了，但原有服務仍在運作。到了 2025 年底，魔法葫蘆已經有大約 3,000 位用戶，收到的回饋大致上也是正向的。這一年裡，同樣沒有發生我們已知的用戶資料遺失或損壞事故。

2024 年，我們學習的是如何把一個 Demo 變成能夠長期運行的軟體：怎樣處理同步、隱私、相容和異常，怎樣維護真實用戶正在使用的服務，以及怎樣對一個人長期積累的數據負責。

這些能力仍然很重要。它們讓魔法葫蘆不只是一個演示，也讓我們能夠在新功能放慢以後，繼續為已經使用它的用戶負責。

但 2025 年曝光出來的是另一層能力。

我們還不擅長把一個需求變成清楚的產品定義，不擅長在很短時間裡形成專業而自然的 UI 和交互，也不能穩定地同時兼顧體驗、功能、可靠性和可維護性。

我們有演算法能力，也有底層開發能力。一個想法出現以後，我們很快就能實現其中最核心的技術部分。但技術能夠運行，並不代表產品已經成立。真正的產品力，是把許多彼此牽制的判斷壓縮在一起，讓使用者感受到的是一個簡單、清楚、完整的東西。

進入下半年後，我們終於承認，團隊當時的產品能力還跟不上自己的野心。

先學習怎樣磨刀

我們把下半年定義為能力建構期。

這個決定並不輕鬆。上半年後期，我們剛剛花了很大力氣理解為什麼要儘早見客戶；到了下半年，我們卻決定暫時不再把每一個半成品都急著推出去，而是先學習怎樣把產品做好。

表面上看，這像是從市場縮回內部。但我們想解決的並不是一個只能由市場回答的問題。

用戶可以告訴我們，需求是否真實，產品有沒有產生價值，以及他們是否願意繼續使用。但如果一個介面連我們自己都覺得不夠專業，一條互動鏈路明知沒有走通，或者係統的可靠性問題還會遮住核心價值，把它交給用戶並不會讓我們獲得更多關於核心問題的有效資訊。

市場應該幫助我們回答未知的問題，而不是重複已經知道的答案。

於是，我們開始反覆研究那些自己真正認可的產品。我們拆解它們的結構、視覺和交互，追問每一個細節為什麼這樣處理；也透過臨摹和復現，把看到的判斷變成自己實際做過的東西。做完以後再比較差距，重新修改，直到能夠理解這些優秀產品為什麼顯得簡單、自然、完整。

臨摹不是為了複製一個產品的表面，也不是為了尋找可以直接搬走的答案。它更像學習繪畫、音樂或書法時的練習：先讓眼睛學習分辨，再讓手逐漸跟上眼睛，最後才可能把這種能力用在自己的問題上。

產品能力包含大量這樣的隱性知識。聽懂一個道理，甚至能夠準確地評價別人的產品，都不等於自己已經擁有這種能力。只有在一次次具體取捨中，把判斷落實為介面、互動和系統，這種能力才可能真正成為團隊的一部分。

到了年底，我們還不能證明自己已經能夠穩定地做出優秀產品。但與年中只能籠統地感到「這個產品不好」相比，我們開始能夠把這種判斷拆成更具體的問題：資訊怎樣組織，交互怎樣推進，視覺細節怎樣服務於整體，系統約束又會怎樣影響體驗。然後，我們可以透過拆解、臨摹、復現和重做，逐項訓練這些能力。

這些變化暫時仍然只是內部訓練的結果，不能取代真實使用者的檢驗。我們能夠確認的是，自己開始形成一套更具體的練習方法，也開始縮短眼睛和手之間的距離。

融資不一定只是錢

回頭看，科含年初對我說的那句話正在以一種很慢的方式得到驗證。

拿到投資當然是一件重要的事，但錢並不是奇績創壇帶給我們的全部。導師的指導和同儕之間的交流，不一定馬上轉換成使用者數、收入或一款成功的產品。到了年底，我還不能說這些關係已經帶來了直接成果，但 Peter 關於匕首的比喻，已經進入了我們每天評價產品的方式。

這句話讓我們不斷重新檢視自己的產品。每當我覺得已經理解它，後來的實踐都會告訴我，我理解的仍然只是其中一部分。

一開始，我以為它要求我們把龐大的第二個大腦拆小。後來，我以為小、快和酷就是鋒利。再後來，我才意識到，一把真正的匕首並不是因為尺寸小而成立，它必須把完整的產品體驗集中在一個具體問題上。

創業營沒有替我們做出那把匕首，卻讓我們更早看見，自己手上的東西為什麼還不是匕首。

這也是融資不只是錢的意思。它未必立刻給出答案，卻會改變我們提出問題、評價自己和繼續學習的方式。

真正的鋒利，也需要完整

到了 2025 年年底，我對「匕首」有了和年初不同的理解。

對使用者問題的洞察是刀尖，互動、UI 和產品體驗是刀刃，功能的完整性是刀身，可靠性和可維護性則像刀柄，讓人能夠真正握住並使用它。

只有一個尖銳的亮點，最多只能成為令人驚豔的 Demo，還不是一把真正能夠被使用的匕首。

完整也不代表把所有東西都做進去。瑞士軍刀可以解決很多問題，卻可能不會圍繞其中一個問題做到足夠深入。

真正的完整，是圍繞著一個核心價值，把使用者需要經過的整個連結做完整。產品裡的每一部分都指向同一個問題，彼此支撐，而不是用更多功能來掩蓋產品還沒有解決核心問題的事實。

2023 年，我離開商湯，跳進下一條河。 2024 年，我們做出了葫蘆，開始理解產品為何必須在時間內成立。 2025 年，我們希望讓魔法真正顯現，也試著把龐大的第二腦拆成一把匕首。

魔法還沒有真正顯現，Sayso 也還沒成為一款成立的產品。即使我們已經看見了需求，我們仍然缺少把它又快又好地做出來的能力。

但這一年，我們至少更準確地看見了自己缺少什麼。

我們不是因為開始追求鋒利，就放棄對完整性、可靠性和長期責任的要求。我們也逐漸明白，儘早見客戶並不代表把明知不好的產品交給用戶，快速迭代也不代表只追求開發速度。

到了今天，我們還沒有做出那把真正成形的匕首。

我們只是開始學習怎麼磨出它。

只有刀尖，還不是匕首。

Ein Jahr ist vergangen, und ich bin noch immer im Wasser.

Der Fluss ist nicht einfacher geworden, und das andere Ufer ist nicht klarer zu erkennen. Aber etwas hat sich verändert. In der zweiten Hälfte des Jahres 2023, kurz nachdem ich SenseTime nach fast zehn Jahren verlassen hatte, verbrachte ich die meiste Zeit damit, zu kämpfen und nach einer Richtung zu suchen. 2024 begannen wir, den größten Teil unserer Zeit in ein konkretes Produkt zu investieren.

Der Hauptstrang des Jahres war das Produkt; einige wenige, begrenzte Finanzierungsversuche bildeten einen Nebenstrang. Wir erhielten keine Investition und sahen kein Marktsignal, das stark genug gewesen wäre, unsere Richtung zu bestätigen. Aber wir entwickelten und veröffentlichten 27 Versionen.

Nachdem wir in den nächsten Fluss gesprungen waren, begannen wir endlich zu lernen, vorwärtszuschwimmen.

Zuerst einen Flaschenkürbis bauen

In meinem Essay vom Ende des vergangenen Jahres schrieb ich, dass ich mich schließlich entschieden hatte, mit intelligenten Notizen zu beginnen.

Seit der Mittelschule habe ich die Gewohnheit, nicht zu lesen, ohne dabei zu schreiben. Wenn ich ein Buch oder einen Artikel lese oder ein Video anschaue, achte ich auf die Stellen, die etwas in mir auslösen, markiere sie und notiere die Gedanken, die dabei entstehen. Ich nenne diesen Vorgang „Punkte finden“: wahrnehmen, was berührt, und die daraus entstehende Inspiration festhalten.

Manchmal ist ein Punkt nur ein Satz, ein Bild oder ein einzelner Moment. Zunächst scheinen diese Punkte nichts miteinander zu tun zu haben. Wenn sich jedoch genug von ihnen angesammelt haben, verbinden sie sich irgendwann und helfen mir, ein Problem zu verstehen oder zu einem Urteil zu gelangen, an das ich zuvor nicht gedacht hatte.

Viele Jahre lang probierte ich verschiedene Notizwerkzeuge aus, fand aber nie ein Produkt, das wirklich zu dieser Gewohnheit passte. Nachdem ich SenseTime verlassen hatte, wandte ich mich an einen Freund aus Kindertagen — denselben Freund, mit dem ich Vogelnester ausnahm und mich prügelte — und wir beschlossen, es gemeinsam zu bauen. In der ersten Hälfte des Jahres 2024 arbeiteten wir die meiste Zeit in einem Coworking-Bereich im Sohu Tower.

Wir nannten das Produkt MagicGourd.

„Gourd“, der Flaschenkürbis, ist auch der Kosename meines Kindes. Als wir den Namen wählten, gab ich ihm bewusst keine besondere Bedeutung. Rückblickend steckte darin vielleicht ein unbewusster Wunsch: Das erste Produkt, das ich als Vollzeitgründer baute, sollte wie ein Kind unter unserer Fürsorge langsam wachsen können.

Ein Produkt ist natürlich kein Kind. Aber beide haben etwas gemeinsam: Es in die Welt zu bringen, ist nur der Anfang. Die lange Arbeit, es zu pflegen und wachsen zu lassen, ist der wirklich schwierige Teil.

Das echte zweite Gehirn, das wir uns vorstellten, war noch weit von der Realität entfernt und konnte nicht in einem einzigen Schritt vollendet werden. Deshalb begannen wir mit dem grundlegendsten: Menschen sollten beim Surfen im Web, beim Lesen einer Online-PDF oder beim Anschauen eines Videos markieren können, was sie berührt, und ihre Inspiration notieren.

Zuerst einen Flaschenkürbis bauen, der diese Punkte aufnehmen kann.

Die Produktentscheidungen hinter einer Markierungsschaltfläche

Kurz nach Beginn der Entwicklung stießen wir auf eine Frage, die fast zu klein schien, um wichtig zu sein: Wie sollte die Schaltfläche zum Markieren aussehen?

Sollte es nur eine Schaltfläche sein oder ein Feld mit mehreren Aktionen? Sollte sie unmittelbar nach der Auswahl eines Textes erscheinen oder warten, bis der Nutzer sie aufruft? Wo sollte sie erscheinen und wann wieder verschwinden? Wenn jemand die automatische Anzeige nicht mochte, sollten wir eine Möglichkeit zum Abschalten anbieten?

Jede zusätzliche Option scheint mehr Bedürfnisse zu erfüllen, erhöht aber auch den Aufwand, das Produkt zu verstehen und zu benutzen. Wenn die Schaltfläche aktiver erscheint, ist die Funktion leichter zu entdecken, kann aber auch immer wieder das Lesen unterbrechen. Bleibt sie zurückhaltender, kann der Nutzer sich besser konzentrieren, erfährt aber möglicherweise nie, dass die Funktion existiert.

Für solche Fragen gibt es keine Standardantwort im algorithmischen Sinn.

Beim Entwickeln von Algorithmen fragen wir gewöhnlich, ob sich eine Fähigkeit umsetzen lässt, ob die Genauigkeit verbessert werden kann und ob die Leistung den Anforderungen entspricht. Beim Entwickeln eines Produkts stellten wir uns eine andere Frage: Wann sollte eine Funktion eingreifen, und wann sollte sie sich in den Hintergrund zurückziehen?

Dass eine Funktion läuft, beweist nur, dass die Technik funktioniert. Ob Menschen sie verstehen, sich von ihr gestört fühlen und sie in ihrem Alltag behalten wollen, entscheidet darüber, ob das Produkt funktioniert.

Beim Entwickeln von Algorithmen und großen Projekten hatte ich bereits viele Probleme der realen Welt bearbeitet. Doch als wir ein Produkt von Grund auf schufen, lagen Entscheidungen, die zuvor Produkt-, Design-, Kunden- und Entwicklungsteams gemeinsam getragen hatten, plötzlich allein bei uns. Wir mussten entscheiden, was sichtbar sein und was verborgen bleiben sollte; was wir jetzt bauen und was wir vorerst weglassen sollten, selbst wenn es nützlich sein könnte.

Nach und nach verstanden wir, dass ein Produkt nicht aus der Zahl seiner Funktionen besteht, sondern aus unzähligen Abwägungen. Manchmal sind auch das Nichterscheinen und das Nichtstören Fähigkeiten eines Produkts.

Ein Produkt muss über die Zeit bestehen

Ob sich eine Schaltfläche natürlich anfühlt, kann ein Nutzer sofort wahrnehmen. Doch viele der Faktoren, die bestimmen, ob ein Produkt über Jahre verwendet wird, bleiben unsichtbar.

MagicGourd bewahrt den Leseverlauf, Momente der Resonanz und Gedanken eines Menschen auf. Wir wollten die Privatsphäre der Nutzer so gut wie möglich schützen und zugleich geräteübergreifende Synchronisierung sowie künftig intelligente Dienste anbieten. Um beides zu erreichen, verschlüsselten wir die Daten lokal und speicherten im Backend nur den verschlüsselten Text. Das machte Entwicklung und Wartung komplexer. Doch wenn Menschen ihre eigenen Daten nicht wirklich besitzen können, ist ein echtes zweites Gehirn von Anfang an unmöglich.

Synchronisierung ist ein weiteres Problem, das einfach aussieht und tatsächlich sehr komplex ist. Wenn jemand eine Markierung erstellt, sollte die Oberfläche sofort reagieren, statt auf das Netz zu warten. Das Festhalten darf auch bei schwacher oder fehlender Verbindung nicht unterbrochen werden. Kehrt das Netz zurück, müssen die Daten verschiedener Geräte korrekt synchronisiert werden, ohne Duplikate, Überschreibungen oder stilles Verschwinden.

Das zwang uns, die Zusammenarbeit von Frontend und Backend, die Organisation der Datenbank, die Kompatibilität bei Versionswechseln und die Wiederherstellung nach Fehlern neu zu bedenken. Nutzer sehen diese Entscheidungen normalerweise nicht. Sobald jedoch eine davon scheitert, wird die gesamte verborgene Komplexität augenblicklich zur unmittelbarsten Nutzererfahrung.

Eine kurzfristig gute Erfahrung ist vergleichsweise leicht zu erzeugen. Es ist nicht besonders schwer, eine flüssige Demo zu bauen, die jemanden ein paar Minuten lang beeindruckt. Für uns wäre sie trotzdem nur eine Demo.

Eine Demo muss nur im Augenblick bestehen. Ein Produkt muss über die Zeit bestehen.

Soll ein Produkt einen Menschen zehn Jahre lang begleiten, müssen die Grundlagen seiner Erfahrung in zehn Jahren schon heute gebaut werden. Ein Ausfall bei einem gewöhnlichen Werkzeug ist vielleicht nur eine vorübergehende Unannehmlichkeit. Bei einem Produkt, das jahrelange Notizen enthält, kann ein einziger Datenverlust das gesamte Vertrauen zerstören, das ein Nutzer aufgebaut hat.

Wir können nicht versprechen, dass das System niemals Probleme haben wird. Aber „keine einzige Notiz eines Nutzers verlieren“ muss eine unserer wichtigsten Designvorgaben bleiben. Produkterfahrung findet nicht nur auf dem Bildschirm statt, sondern auch in der Datenbank, die der Nutzer niemals sieht.

Ein sehr kurzer Nebenstrang der Finanzierung

Vielleicht ist es sogar übertrieben, die Finanzierung einen Nebenstrang des Jahres zu nennen. Wir sprachen nur mit drei Investmentgesellschaften und verbrachten fast die gesamte übrige Zeit mit dem Produkt.

Unsere Idee war einfach: Frühphaseninvestoren anzusprechen, die wir direkt oder indirekt kannten, ihnen zu erklären, was wir bauten, und unsere erste Angel-Investition einzuwerben.

Der Wert dieser Investition hätte nicht nur im Geld gelegen. Das Produkt war unfertig, und es gab kein klares Marktsignal. In dieser Phase wollten wir eine Außensicht darauf, ob hervorragende Investoren unsere Richtung für sinnvoll hielten.

Keiner dieser Versuche führte zu einem Ergebnis. Damals erklärten wir dies mit dem schwierigen Finanzierungsumfeld für KI-Anwendungen und unserer mangelnden Erfahrung im Gespräch mit Investoren. Beides spielte eine Rolle. Rückblickend gab es jedoch eine direktere Tatsache: Wir investierten wenig Zeit in die Finanzierung und sprachen nur mit drei Gesellschaften. Statt von einer gescheiterten Finanzierungsrunde zu sprechen, wäre es genauer zu sagen, dass wir einige erste Gespräche mit Investoren führten.

Mehr Nachdenken verdient meine Reaktion darauf, infrage gestellt zu werden.

Bei unserem Gespräch mit MiraclePlus saßen mir Menschen gegenüber, die ich zutiefst respektierte. Als sie unsere Ideen wiederholt herausforderten und ihre Fragen sehr scharf formulierten, geriet ich in einen Zwiespalt: Wir waren gekommen, um Investitionen zu suchen. Also schien es mir richtig, ihr Urteil zu respektieren und mich bis zu einem gewissen Grad den Antworten anzunähern, die sie erwarteten.

Wenn der Zweck der Finanzierung jedoch ehrliches Feedback war, würde jedes Wort, an das wir selbst nicht glaubten, dieses Feedback bedeutungslos machen.

Später fragte ich mich, ob wir wirklich nur Feedback wollten. Vielleicht suchten wir, bevor der Markt das Produkt validiert hatte, auch die Zustimmung einer Gruppe hervorragender Investoren, um uns zu vergewissern, dass wir nicht die falsche Richtung gewählt hatten.

Es war, als stünden wir in einem unbekannten Fluss und hofften, jemand am Ufer würde uns zuerst sagen, wohin wir schwimmen sollten. Doch ein Gründer muss die Strömung letztlich selbst spüren und anhand der Tatsachen vor ihm urteilen.

Die „Xuanming-Ältesten“ im Dongsheng Tower

In der zweiten Hälfte des Jahres 2024 zogen wir vom Sohu Tower in den Dongsheng Tower.

Mein Jugendfreund und ich arbeiteten über lange Strecken im Pair Programming, oft nebeneinander vor demselben Bildschirm. Unter den jungen Gründern im Coworking-Bereich fiel diese Arbeitsweise auf. Mit der Zeit bekamen wir einen Spitznamen: die „Xuanming-Ältesten“.

Es war lustig. Zwei Menschen, die als Kinder gemeinsam Vogelnester ausnahmen und sich prügelten, saßen zwanzig Jahre später in einem Gemeinschaftsbüro und bauten ein Produkt namens MagicGourd.

Im Dongsheng Tower lernten wir auch Kehan kennen. Bei MiraclePlus war er für die Community und die Gewinnung von Gründungsprojekten zuständig. Als er uns zum ersten Mal ansprach, fragte er: „Ihr seid Gründer, oder? Ich beobachte euch schon lange. Im ganzen Büro seid ihr beiden am deutlichsten im Gründermodus.“

Später, als er erfuhr, dass wir ein Gespräch bei MiraclePlus geführt hatten, sprachen wir über die damalige Situation. Er erklärte uns, dass Investoren eine Gründungsidee nicht immer nur deshalb wiederholt infrage stellen, weil sie widersprechen wollen. Manchmal testen sie auch, ob die Gründer die Sache wirklich durchdacht haben und unter Druck an ihrem eigenen Urteil festhalten können.

Dadurch verstand ich das Gespräch neu.

Investoren zu respektieren heißt nicht, ihnen das eigene Urteil zu überlassen. Ein Gründer muss verstehen, warum andere widersprechen, ohne das eigene Urteil allein deshalb aufzugeben, weil diese Menschen Respekt verdienen. Zu vermeiden ist nicht, seine Meinung aufgrund neuer Tatsachen zu ändern. Zu vermeiden ist, nur um Zustimmung zu erhalten etwas anderes zu sagen, bevor man die Frage selbst durchdacht hat.

Diese Lektion gilt nicht nur für Finanzierungen. Beim Aufbau eines Produkts begegnen uns jeden Tag Nutzerfeedback, Entscheidungen konkurrierender Produkte und neue Technologietrends. All diese äußeren Signale verdienen Aufmerksamkeit. Doch die Entscheidung darüber, was in das Produkt gehört, bleibt unsere Verantwortung.

Der Flaschenkürbis ist da

Bis Ende 2024 hatten wir 27 Versionen von MagicGourd entwickelt und veröffentlicht.

Wir begannen mit Text- und Bildanmerkungen auf gewöhnlichen Webseiten, unterstützten später Online-PDFs und erweiterten dieselbe Methode auf Bilibili und YouTube. Nutzer konnten einen Moment in einem Video markieren, der sie berührte, eine Notiz schreiben und über die Zeitleiste schnell dorthin zurückkehren. Wir fügten außerdem Tag-Verwaltung, Suche und Export hinzu und synchronisierten Daten zwischen Browsern und Geräten.

Jedes neue Inhaltsformat erforderte umfangreiche Anpassungen. Webseiten besitzen keine einheitliche Struktur, und Videoplattformen verändern sich ständig. Eine Funktion, die auf einer Website korrekt arbeitet, kann sich auf einer anderen Seite oder in einem anderen Browser völlig anders verhalten. Ein großer Teil unserer Zeit führte nicht zu auffälligen neuen Fähigkeiten, sondern floss in Grenzfälle, damit bereits vorhandene Funktionen zuverlässiger arbeiteten.

In den 27 Versionen, die wir im Laufe des Jahres veröffentlichten, fanden wir keinen Fall verlorener oder beschädigter Nutzerdaten. Gelegentliche Störungen betrafen vor allem Dienstschritte wie Anmeldebestätigungscodes. Nach einer Meldung konnten wir das Problem meist schnell lokalisieren und beheben. Das beweist nicht, dass das System niemals ausfallen wird. Es zeigt aber, dass die Zeit für die unsichtbaren Teile nicht verschwendet war.

Im November stellten wir die Videonotiz-Funktion auf sspai vor. Nutzer begannen, Rückmeldungen zu hinterlassen. Eine Person, die nützliche Videobilder zuvor als Screenshots gespeichert und anderswo eingefügt hatte, schrieb nach dem Ausprobieren von MagicGourd: „Dieses Plugin hat mich gerettet!“ Andere mochten die tropfenförmigen Markierungen auf der Zeitleiste, wünschten sich eigenständige Notizen oder hofften auf baldige Safari-Unterstützung.

Nutzerfeedback zu erhalten, war eine der größten Freuden des Jahres.

Uns freute nicht nur, dass Menschen das Produkt lobten, sondern dass jemand etwas von uns Geschaffenes in sein wirkliches Leben aufgenommen hatte. Die Nutzer machten auch hilfreiche Vorschläge, die uns zu weiteren Entscheidungen zwangen: Welche Rückmeldung weist auf ein gemeinsames Problem hin und welche entsteht aus einer individuellen Gewohnheit? Was sollte sofort gelöst werden, und was sollte trotz seines Nutzens in dieser Phase noch nicht in das Produkt gelangen?

Teilt man den Produktnamen in zwei Hälften, hatten wir am Jahresende zumindest den „Flaschenkürbis“ gebaut: ein Gefäß zum Sammeln, Bewahren und Ordnen von Momenten der Resonanz und Inspiration.

Die Magie ist noch nicht erschienen

Doch das war noch nicht die Magie, die wir im Sinn hatten.

Sie würde selbstverständlich KI verwenden, aber nicht lediglich eine Zusammenfassung eines Artikels erzeugen. Eine Zusammenfassung kann Informationen verdichten, ohne die Kognition voranzubringen.

Nach unserem Verständnis sind Informationen die Inhalte, die ein Mensch empfängt; Wissen sind verstandene und geordnete Informationen; Kognition ist die Art, wie ein Mensch die Welt versteht, Verbindungen und Urteile bildet und sie angesichts neuer Erfahrungen revidiert.

Heutige KI kann Informationen gut verarbeiten und Wissen immer besser ordnen. Sie kann einen Artikel zusammenfassen, Schlüsselwörter extrahieren und Fragen beantworten, deren Antworten bereits im Material enthalten sind. Doch wenn sie nur zehn Seiten auf eine reduziert oder ein Chatfenster neben eine Notiz-App setzt, berührt sie noch nicht das, was wir wirklich bauen wollen.

Ein zukünftiges MagicGourd soll die über lange Zeit gesammelten Aufzeichnungen eines Menschen verstehen und Momente der Resonanz zusammenbringen, die über verschiedene Zeiten und Medien verstreut sind. Es könnte Themen entdecken, die immer wiederkehren, ohne je ausdrücklich formuliert worden zu sein, Verbindungen und Widersprüche zwischen Notizen zeigen, lange unbeantwortete Fragen finden oder einen früheren Gedanken im richtigen Moment zurückbringen.

Noch wichtiger ist, dass es Fragen aufwerfen sollte, an die der Nutzer noch nicht gedacht hat, die aber eine weitere Beschäftigung verdienen, und ihm so helfen sollte, eigene neue Urteile zu bilden.

Dabei braucht es eine klare Grenze: KI darf ihre Vermutungen nicht als eine „Wahrheit“ verpacken, die der Nutzer nur noch nicht erkannt habe. Sie kann mögliche Verbindungen, Widersprüche und Fragen vorschlagen. Ob diese Verbindungen tragen, muss weiterhin der Nutzer entscheiden.

Magie denkt nicht anstelle des Nutzers. Sie hilft ihm, das Denken zu sehen, das er noch nicht zu Ende geführt hat.

Im Laufe des Jahres bauten wir mehrere interne Demos zu dieser Idee. Sie konnten Zusammenfassungen erstellen, Inhalte ordnen und Fragen beantworten. Sie sahen bereits ein wenig wie KI-Produkte aus. Doch von dem, was wir unter „Kognition voranbringen“ verstanden, waren sie noch weit entfernt. Deshalb veröffentlichten wir sie nicht überstürzt, nur um mit der KI-Welle Schritt zu halten.

Je tiefer KI am kognitiven Prozess eines Menschen teilnimmt, desto privater sind die Daten, auf die sie zugreifen muss. Das bestärkte uns darin, dass Privatsphäre und Dateneigentum keine von der Magie getrennten technischen Fragen sind, sondern Voraussetzungen für ihre Existenz. Wir können nicht behaupten, Nutzer verstehen zu wollen, und sie zugleich auffordern, die Kontrolle über ihre eigenen Daten abzugeben.

So war am 31. Dezember 2024 der Flaschenkürbis da, doch die Magie war noch nicht erschienen.

Wir hatten keine Investition erhalten, kein entscheidendes Marktsignal gesehen und kein klares Geschäftsmodell aufgebaut. Wir wussten noch immer nicht, wohin dieser Fluss schließlich führen würde.

Aber wir hatten 27 Versionen veröffentlicht. Nutzer begannen, das Produkt in ihr Leben aufzunehmen. Und wir begannen zu verstehen, wie aus einer funktionierenden Demo ein echtes Produkt wird — und wie man dafür langfristig Verantwortung übernimmt.

Ein Jahr zuvor hatte ich geschrieben: „Ich bin noch immer im Wasser.“

Ein Jahr später war ich weiterhin im Wasser. Der Fluss war nicht einfacher und das andere Ufer nicht klarer geworden.

Aber den Flaschenkürbis hatten wir gebaut.

Die Magie war noch nicht erschienen. Auch das andere Ufer hatten wir nicht erreicht. Aber zumindest hatten wir begonnen, vorwärtszuschwimmen.

A year has passed, and I am still in the water.

The river has not become easier, nor has the opposite bank become clearer. But something has changed. In the second half of 2023, after leaving SenseTime, where I had worked for nearly ten years, I spent most of my time struggling and looking for a direction. In 2024, we began spending most of our time building a specific product.

The main thread of the year was product development. A few limited fundraising attempts formed a side thread. We raised no money and saw no market signal strong enough to validate our direction, but we built and released 27 versions.

After jumping into the next river, we had finally begun learning how to swim forward.

First, Make a Gourd

In the essay I wrote at the end of last year, I said that I had ultimately decided to begin with intelligent notes.

Since middle school, I have believed that reading should involve writing. When I read a book or an article, or watch a video, I notice the parts that move me, mark them, and record the thoughts that arise. I call this process “finding points”: noticing what resonates and recording the inspiration it produces.

Sometimes a point is only a sentence, an image, or a single frame. At first, these points may seem unrelated. But once enough of them accumulate, they connect at unexpected moments, helping me understand a problem or form a judgment I had not previously considered.

Over the years, I tried many note-taking tools but never found a product that truly fit this habit. After leaving SenseTime, I asked a childhood friend—the same friend with whom I used to raid birds’ nests and get into fights—to build it with me. During the first half of 2024, we spent most of our time working in a coworking space in Sohu Tower.

We named the product MagicGourd.

“Gourd” is also my child’s nickname. I did not consciously attach much meaning to the name when we chose it. Looking back, perhaps it contained a subconscious hope: that the first product I built after becoming a full-time founder could, like a child, grow slowly under our care.

A product is not a child, of course. But they share one quality: bringing one into the world is only the beginning. The long work of caring for it and helping it grow is much harder.

The true second brain we envisioned was still far from reality and could not be completed in one step. So we decided to begin with the most basic one: let people mark what moves them and write down their inspiration while browsing the web, reading an online PDF, or watching a video.

First, make a gourd that could hold these points.

The Product Judgment Behind a Highlight Button

Soon after we started building, we ran into a question that seemed almost too small to matter: what should the highlight button look like?

Should it be a single button or a panel containing several actions? When someone selects text, should it appear immediately or wait to be invoked? Where should it appear, and when should it disappear? If someone dislikes having it appear automatically, should we add a setting to turn it off?

Every additional option seems capable of meeting more needs, but it also raises the cost of understanding and using the product. Making the button appear more proactively makes the feature easier to discover, but it may also interrupt reading. Keeping it quiet may help someone stay focused, but they may never realize the feature exists.

There is no algorithmic standard answer to questions like these.

When building algorithms, we tend to ask whether a capability can be implemented, whether accuracy can be improved, and whether performance meets the target. When building a product, we found ourselves asking a different question: when should a feature step in, and when should it recede into the background?

The fact that a feature runs only proves that the technology works. Whether people understand it, feel interrupted by it, and choose to keep it in their daily lives determines whether the product works.

I had dealt with many real-world problems while building algorithms and large projects. But when we created a product from scratch, product decisions that had once been shared among product, design, customer, and engineering teams suddenly became ours alone. We had to decide what should be visible and what should remain behind the scenes; what to build now and what to leave out, even if it might be useful.

We gradually realized that a product is not made from a count of its features. It is made from countless choices. Sometimes, not appearing and not interrupting are themselves product capabilities.

A Product Must Hold Up Over Time

Whether a button feels natural is an experience people can perceive immediately. But more of what determines whether a product will be used for years is hidden from view.

MagicGourd stores a person’s reading history, moments of resonance, and thoughts. We wanted to protect user privacy as much as possible while still providing cross-device synchronization and, in the future, intelligent services. To do both, we chose to encrypt data locally and store only ciphertext on the backend. This made development and maintenance more complex. But if people cannot truly own their data, a true second brain is impossible from the start.

Synchronization is another problem that looks simple and is anything but. When someone creates a highlight, the interface should respond immediately rather than stop and wait for the network. Recording should continue even on a weak connection or with no connection at all. When the network returns, data from different devices must synchronize correctly, without duplication, overwriting, or silent disappearance.

This forced us to reconsider how the frontend and backend should work together, how the database should organize data, how upgrades should preserve compatibility, and how the system should recover from errors. People do not usually see these decisions. But when one of them fails, all that hidden complexity becomes the most immediate part of the user experience.

Short-term experience is relatively easy to produce. It is not that difficult to make a smooth demo that impresses someone for a few minutes. But to us, it would still be only a demo.

A demo only has to hold up in the moment. A product has to hold up over time.

If a product is meant to accompany someone for ten years, the foundations of their experience ten years from now must be built today. A failure in an ordinary tool may be a temporary inconvenience. In a product that holds years of notes, a single loss of data can destroy all the trust a user has built.

We cannot promise that the system will never fail. But “do not lose a single user note” must remain one of our most important design constraints. Product experience does not exist only on the screen. It also exists in the database, where the user never sees it.

A Very Short Fundraising Side Thread

Even calling fundraising a side thread of the year may be an exaggeration. We spoke with only three investment firms and spent most of the rest of our time building the product.

Our idea was simple: approach early-stage investors whom we knew directly or indirectly, explain what we were building, and try to raise our first angel round.

The value of that investment would not have been only the money. The product was unfinished, and there was no clear market signal. At that stage, we wanted outside feedback on whether strong investors believed the direction made sense.

None of these attempts led anywhere. At the time, we attributed the result to a difficult funding environment for AI applications and to our own inexperience talking with investors. Both were true. But looking back, there was a more immediate fact: we invested little time in fundraising and spoke with only three firms. Rather than saying that we went through a failed fundraising round, it would be more accurate to say that we had a few preliminary conversations with investors.

What deserves more reflection is how I responded to being challenged.

When we interviewed with MiraclePlus, the people sitting across from me were people I respected deeply. When they repeatedly challenged our ideas and framed their questions sharply, I felt torn. We had come seeking investment, so it seemed that I should respect their judgment and, to some extent, move closer to the answers they expected.

But if the purpose of fundraising was to receive honest feedback, saying things I did not truly believe would make that feedback meaningless.

I later began to wonder whether feedback was really all we wanted. Perhaps, before the product had been validated by the market, we also wanted approval from a group of outstanding investors to reassure ourselves that we had not chosen the wrong direction.

It was like standing in an unfamiliar river and hoping that someone on the bank would first tell us where to swim. But a founder must ultimately feel the current firsthand and make judgments from the facts in front of them.

The “Xuanming Elders” of Dongsheng Tower

In the second half of 2024, we moved from Sohu Tower to Dongsheng Tower.

My childhood friend and I practiced pair programming for long stretches, often sitting together and staring at the same screen as we talked. Among the younger founders in the coworking space, this way of working was conspicuous. Before long, people gave us a nickname: the “Xuanming Elders.”

It was funny. Two people who had raided birds’ nests and fought together as children were sitting in a coworking space twenty years later, building a product called MagicGourd.

It was at Dongsheng Tower that we met Kehan. He was responsible for community work and founder recruitment at MiraclePlus. The first time he spoke to us, he asked, “You two are founders, right? I’ve been watching you for a long time. Of everyone in this office, you two look the most like you’re truly in founder mode.”

Later, when he learned that we had interviewed with MiraclePlus, we talked about what had happened. He told us that when investors repeatedly question a startup idea, they are not always merely expressing disagreement. They may also be testing whether the founders have truly thought it through and can preserve their judgment under pressure.

That helped me reinterpret the interview.

Respecting investors does not mean handing them your judgment. A founder must understand why others disagree without abandoning their own judgment simply because those people deserve respect. What must be avoided is not changing your mind in response to new facts. It is changing what you say merely to win approval before you have thought the question through.

This lesson applies beyond fundraising. When building a product, we encounter user feedback, choices made by competing products, and new technology trends every day. These external signals all deserve careful attention. But deciding what belongs in the product remains our responsibility.

The Gourd Is Here

By the end of 2024, we had built and released 27 versions of MagicGourd.

We began with annotations for text and images on ordinary web pages, then added support for online PDFs and extended the same method to Bilibili and YouTube. People could mark a video frame that moved them, add a note, and quickly return to those moments on the timeline. We also added tag management, search, and export, and synchronized data across browsers and devices.

Every new content format required a great deal of adaptation. Web pages have no uniform structure, and video platforms keep changing. A feature that works correctly on one site may behave entirely differently on another page or browser. Much of our time did not produce conspicuous new capabilities. It went into handling edge cases so that existing capabilities would work more reliably.

Across the 27 versions released during the year, we found no cases of user data being lost or corrupted. The occasional failures were concentrated in service steps such as login verification codes. When we received a report, we could usually locate and resolve the problem quickly. This does not prove that the system will never fail, but it does suggest that the time we spent on what users cannot see was not wasted.

In November, we introduced our video-note feature on sspai. Users began leaving feedback in the comments. One person, who had previously saved useful video frames by taking screenshots and pasting them elsewhere, wrote after trying MagicGourd: “This plugin saved me!” Others liked the droplet markers on the video timeline, asked for standalone notes, or hoped we would support Safari soon.

Receiving user feedback was one of the happiest parts of the year.

What made us happy was not only that people praised the product, but that someone had finally placed something we made into their real life. They also offered useful suggestions that pushed us to keep deciding: which comments reflected a shared problem and which came from an individual habit; what should be fixed immediately and what, though useful, did not belong in the product at this stage.

If the product’s name is divided in two, by the end of the year we had at least built the “gourd”: a vessel for collecting, preserving, and managing moments of resonance and inspiration.

The Magic Has Yet to Appear

But this was not yet the magic we had in mind.

It would certainly use AI, but it would not merely generate a summary of an article. A summary can compress information without advancing cognition.

As we understand them, information is the content a person receives; knowledge is information that has been understood and organized; cognition is the way a person understands the world, forms connections and judgments, and revises them as new experience arrives.

AI today is good at processing information and increasingly good at organizing knowledge. It can summarize an article, extract keywords, and answer questions already contained in the material. But if it only compresses ten pages into one, or adds a chat box beside a note-taking app, it has not touched what we truly want to build.

We want a future MagicGourd to understand the records a person has accumulated over time and bring together moments of resonance scattered across different periods and media. It might discover themes that recur without ever being stated explicitly, reveal connections and contradictions among notes, identify questions that have gone unanswered for a long time, or bring an earlier thought back at the right moment.

More importantly, it should raise questions the user has not yet considered but that are worth pursuing, helping them form new judgments of their own.

There must be a clear boundary here: AI cannot package its guesses as a “truth” the user has not yet realized. It can propose possible connections, contradictions, and questions. Whether those connections hold is still for the user to decide.

Magic does not think in place of the user. It helps the user see the thinking they have not yet finished.

During the year, we built several internal demos related to this idea. They could generate summaries, organize content, and answer questions. They already looked somewhat like AI products. But they were still far from what we meant by “advancing cognition,” so we did not rush them into production merely to keep up with the AI wave.

The more deeply AI participates in a person’s cognitive process, the more private the data it needs to access. This made us even more certain that privacy and data ownership are not engineering concerns separate from the magic. They are prerequisites for the magic to exist. We cannot claim that we want to understand users while asking them to surrender control of their own data.

And so, on December 31, 2024, the gourd was here, but the magic had yet to appear.

We had not raised investment, seen a decisive market signal, or established a clear business model. We still did not know where this river would ultimately lead.

But we had shipped 27 versions. Users had begun bringing the product into their lives. And we had begun to understand how to turn a demo that could run into a real product—and take responsibility for it over the long term.

A year earlier, I had written: “I am still in the water.”

A year later, I was still in the water. The river had not become easier, nor had the opposite bank become clearer.

But we had made the gourd.

The magic had yet to appear. We had not reached the opposite bank, either. But at least we had begun to swim forward.

Ha pasado un año y sigo en el agua.

El río no se ha vuelto más fácil ni la otra orilla más clara. Pero algo ha cambiado. En la segunda mitad de 2023, recién salido de SenseTime, donde había trabajado casi diez años, pasé la mayor parte del tiempo luchando y buscando una dirección. En 2024 empezamos a dedicar la mayor parte de nuestro tiempo a desarrollar un producto concreto.

La línea principal del año fue el producto; unos pocos intentos limitados de financiación fueron una línea secundaria. No conseguimos inversión ni vimos una señal de mercado lo bastante fuerte como para confirmar la dirección, pero desarrollamos y publicamos 27 versiones.

Después de saltar al siguiente río, por fin empezábamos a aprender a nadar hacia delante.

Primero, hacer una calabaza

En el ensayo de finales del año pasado escribí que al final había decidido empezar por las notas inteligentes.

Desde la escuela secundaria tengo el hábito de no leer sin escribir. Cuando leo un libro o un artículo, o veo un vídeo, presto atención a los fragmentos que me conmueven, los marco y anoto las ideas que surgen. Llamo a este proceso «encontrar puntos»: percibir lo que nos toca y registrar la inspiración que produce.

A veces un punto es solo una frase, una imagen o un fotograma. Al principio pueden parecer elementos sin relación. Pero, cuando se acumulan suficientes, se conectan en algún momento y me ayudan a entender un problema o a formar un juicio que antes no había considerado.

Durante muchos años probé distintas herramientas de notas, pero nunca encontré un producto que encajara de verdad con este hábito. Después de dejar SenseTime, busqué a un amigo de la infancia —el mismo con quien sacaba nidos de pájaros y me metía en peleas— y decidimos construirlo juntos. Durante la primera mitad de 2024 trabajamos casi todo el tiempo en un espacio compartido de la Torre Sohu.

Llamamos al producto MagicGourd.

«Gourd», calabaza, es también el apodo de mi hijo. Cuando elegimos el nombre no le atribuí conscientemente demasiado significado. Visto en retrospectiva, quizá contenía un deseo inconsciente: que el primer producto que construyera como emprendedor a tiempo completo pudiera crecer poco a poco bajo nuestro cuidado, como un niño.

Un producto no es un niño, por supuesto. Pero comparten algo: traerlo al mundo es solo el comienzo. El largo trabajo de cuidarlo y ayudarlo a crecer es la parte verdaderamente difícil.

El verdadero segundo cerebro que imaginábamos todavía estaba lejos de la realidad y no podía completarse de un solo paso. Decidimos empezar por el más básico: permitir que las personas marcaran aquello que les conmovía y anotaran su inspiración mientras navegaban por la web, leían un PDF en línea o veían un vídeo.

Primero, hacer una calabaza capaz de guardar esos puntos.

Las decisiones de producto detrás de un botón de resaltado

Poco después de empezar a desarrollar nos encontramos con una pregunta que parecía insignificante: ¿qué aspecto debía tener el botón de resaltado?

¿Debía ser un solo botón o un panel con varias acciones? Después de seleccionar un texto, ¿debía aparecer de inmediato o esperar a que el usuario lo invocara? ¿Dónde debía aparecer y cuándo debía desaparecer? Si a alguien no le gustaba que apareciera automáticamente, ¿debíamos ofrecer un interruptor para desactivarlo?

Cada opción adicional parece satisfacer más necesidades, pero también aumenta el coste de comprender y utilizar el producto. Hacer que el botón aparezca de forma más activa facilita descubrir la función, pero también puede interrumpir constantemente la lectura. Mantenerlo más discreto puede ayudar a concentrarse, pero quizá el usuario nunca descubra que la función existe.

No hay una respuesta estándar, en el sentido algorítmico, para preguntas como estas.

Cuando hacemos algoritmos solemos preguntar si una capacidad puede implementarse, si puede mejorar la precisión y si el rendimiento cumple los requisitos. Al hacer un producto empezamos a preguntarnos otra cosa: ¿cuándo debe intervenir una función y cuándo debe retirarse al fondo?

Que una función se ejecute solo demuestra que la tecnología funciona. Que la gente la entienda, que no se sienta interrumpida y que quiera conservarla en su vida cotidiana determina si el producto funciona.

Ya había afrontado muchos problemas del mundo real al desarrollar algoritmos y grandes proyectos. Pero, al crear un producto desde cero, decisiones que antes compartían los equipos de producto, diseño, clientes e ingeniería recayeron de pronto sobre nosotros. Teníamos que decidir qué debía verse y qué debía permanecer oculto; qué construir ahora y qué dejar fuera por el momento, aunque pudiera ser útil.

Poco a poco entendimos que un producto no está compuesto por la cantidad de sus funciones, sino por innumerables decisiones. A veces, no aparecer y no interrumpir también son capacidades del producto.

Un producto debe sostenerse en el tiempo

Que un botón resulte natural es una experiencia que el usuario puede percibir de inmediato. Pero muchos más factores que determinan si un producto se utilizará durante años permanecen fuera de su vista.

MagicGourd guarda el historial de lectura, los momentos de resonancia y las ideas de una persona. Queríamos proteger al máximo la privacidad de los usuarios y, al mismo tiempo, ofrecer sincronización entre dispositivos y futuros servicios inteligentes. Para lograr ambas cosas, decidimos cifrar los datos en el dispositivo y guardar solo texto cifrado en el servidor. Esto aumentó la complejidad del desarrollo y el mantenimiento. Pero, si una persona no puede ser verdaderamente dueña de sus datos, un verdadero segundo cerebro es imposible desde el principio.

La sincronización es otro problema que parece sencillo y en realidad es muy complejo. Cuando alguien crea un resaltado, la interfaz debe responder de inmediato en lugar de quedarse esperando a la red. La toma de notas no debe interrumpirse ni siquiera con una conexión débil o sin conexión. Cuando vuelva la red, los datos de distintos dispositivos deben sincronizarse correctamente, sin duplicarse, sobrescribirse ni desaparecer en silencio.

Esto nos obligó a reconsiderar cómo debían colaborar el frontend y el backend, cómo organizar los datos en la base de datos, cómo mantener la compatibilidad entre versiones y cómo recuperarse de los errores. El usuario normalmente no ve estas decisiones. Pero, cuando falla una de ellas, toda esa complejidad oculta se convierte de inmediato en la experiencia más directa.

La experiencia a corto plazo es relativamente fácil de conseguir. No es tan difícil crear una demostración fluida que impresione durante unos minutos. Pero, para nosotros, seguiría siendo solo una demo.

Una demo solo tiene que sostenerse ante los ojos. Un producto debe sostenerse en el tiempo.

Si un producto pretende acompañar a alguien durante diez años, los cimientos de la experiencia dentro de diez años deben construirse hoy. Un fallo en una herramienta normal quizá solo sea una molestia temporal. En un producto que contiene años de notas, una sola pérdida de datos puede destruir toda la confianza acumulada por el usuario.

No podemos prometer que el sistema nunca tendrá problemas. Pero «no perder ni una sola nota del usuario» debe ser una de nuestras restricciones de diseño más importantes. La experiencia de producto no solo ocurre en la pantalla; también ocurre en la base de datos que el usuario nunca ve.

Una línea secundaria de financiación muy breve

Quizá sea exagerado incluso llamar a la financiación una línea secundaria del año. Solo hablamos con tres firmas de inversión y dedicamos casi todo el resto del tiempo a desarrollar el producto.

Nuestra idea era sencilla: acercarnos a inversores de fase inicial que conociéramos directa o indirectamente, explicarles lo que estábamos construyendo e intentar conseguir nuestra primera inversión ángel.

El valor de esa inversión no estaría solo en el dinero. El producto aún no estaba terminado y no había una señal clara del mercado. En ese momento queríamos recibir una opinión externa sobre si inversores excelentes consideraban que la dirección tenía sentido.

Ninguno de esos intentos produjo resultados. Entonces lo atribuíamos a un entorno de financiación poco favorable para las aplicaciones de IA y a nuestra falta de experiencia hablando con inversores. Ambos factores existían. Pero, visto ahora, había un hecho más inmediato: dedicamos poco tiempo a financiar y solo hablamos con tres firmas. Más que haber atravesado una ronda de financiación fallida, tuvimos unas pocas conversaciones preliminares con inversores.

Lo que merece más reflexión es cómo reaccioné cuando cuestionaron nuestras ideas.

Durante la entrevista con MiraclePlus, frente a mí había personas a las que respetaba profundamente. Cuando cuestionaban repetidamente nuestras ideas y formulaban preguntas muy duras, sentía una tensión: habíamos ido a buscar inversión, así que parecía que debía respetar su juicio e incluso acercarme, hasta cierto punto, a las respuestas que esperaban.

Pero, si buscábamos financiación para recibir opiniones sinceras, decir algo en lo que no creíamos haría inútiles esas opiniones.

Más tarde empecé a preguntarme si de verdad solo queríamos opiniones. Tal vez, antes de que el mercado validara el producto, también buscábamos la aprobación de un grupo de inversores excelentes para asegurarnos de no haber elegido la dirección equivocada.

Era como estar en un río desconocido esperando que alguien en la orilla nos dijera primero hacia dónde nadar. Pero un emprendedor debe sentir la corriente por sí mismo y juzgar a partir de los hechos que tiene delante.

Los «Ancianos de Xuanming» de la Torre Dongsheng

En la segunda mitad de 2024 nos mudamos de la Torre Sohu a la Torre Dongsheng.

Mi amigo de la infancia y yo programábamos en pareja durante largos periodos, sentados frente a la misma pantalla mientras hablábamos. Entre los jóvenes emprendedores del espacio compartido, nuestra forma de trabajar llamaba mucho la atención. Con el tiempo nos pusieron un apodo: los «Ancianos de Xuanming».

Era divertido. Dos personas que de niños sacaban nidos de pájaros y se peleaban juntas estaban, veinte años después, sentadas en una oficina compartida construyendo un producto llamado MagicGourd.

Fue en la Torre Dongsheng donde conocimos a Kehan. En MiraclePlus se ocupaba de la comunidad y de captar proyectos emprendedores. La primera vez que habló con nosotros preguntó: «Ustedes son emprendedores, ¿verdad? Llevo mucho tiempo observándolos. De toda la oficina, ustedes dos son quienes más parecen estar en modo fundador».

Más tarde, cuando supo que habíamos pasado por una entrevista de MiraclePlus, hablamos de lo ocurrido. Nos explicó que, cuando los inversores cuestionan repetidamente una idea, no siempre se limitan a expresar desacuerdo. También pueden estar comprobando si los fundadores han pensado realmente el asunto y si pueden mantener su propio juicio bajo presión.

Eso me hizo reinterpretar la entrevista.

Respetar a los inversores no significa entregarles nuestro juicio. Un emprendedor debe entender por qué otros discrepan sin abandonar su propio criterio solo porque esas personas merecen respeto. Lo que hay que evitar no es cambiar de opinión ante nuevos hechos, sino cambiar lo que decimos únicamente para obtener aprobación antes de haber pensado bien la cuestión.

Esta lección no se limita a la financiación. Al crear un producto nos enfrentamos cada día a comentarios de usuarios, decisiones de productos competidores y nuevas tendencias tecnológicas. Todas estas señales externas merecen atención, pero decidir qué debe entrar en el producto sigue siendo responsabilidad nuestra.

La calabaza ya está

A finales de 2024 habíamos desarrollado y publicado 27 versiones de MagicGourd.

Empezamos con anotaciones de texto e imágenes en páginas web normales, añadimos compatibilidad con PDF en línea y extendimos el mismo método a Bilibili y YouTube. El usuario podía marcar un fotograma de vídeo que le conmoviera, escribir una nota y volver rápidamente a esos momentos en la línea temporal. También añadimos gestión de etiquetas, búsqueda y exportación, y sincronizamos datos entre navegadores y dispositivos.

Cada nuevo formato de contenido exigía una gran cantidad de adaptación. Las páginas web no tienen una estructura uniforme y las plataformas de vídeo cambian constantemente. Una función que opera correctamente en un sitio puede comportarse de manera muy distinta en otra página o navegador. Buena parte de nuestro tiempo no produjo capacidades nuevas y visibles: se dedicó a resolver casos límite para que las capacidades existentes funcionaran con mayor estabilidad.

En las 27 versiones publicadas durante el año no encontramos ningún caso de pérdida o corrupción de datos de usuarios. Los fallos ocasionales se concentraron en pasos del servicio como los códigos de verificación de inicio de sesión. Cuando recibíamos un aviso, casi siempre podíamos localizar y resolver el problema con rapidez. Esto no demuestra que el sistema nunca vaya a fallar, pero sí indica que el tiempo dedicado a lo que el usuario no ve no fue en vano.

En noviembre presentamos la función de notas de vídeo en sspai. Los usuarios empezaron a dejar comentarios. Una persona que antes guardaba fotogramas útiles haciendo capturas de pantalla y pegándolas en otro lugar escribió después de probar MagicGourd: «¡Este complemento me salvó!». A otros les gustaron las marcas en forma de gota en la línea temporal, pidieron notas independientes o esperaban que pronto ofreciéramos compatibilidad con Safari.

Recibir comentarios de los usuarios fue una de las mayores alegrías del año.

Lo que nos alegraba no era solo que elogiaran el producto, sino que alguien hubiera incorporado a su vida real algo que nosotros habíamos creado. También aportaban sugerencias útiles que nos obligaban a seguir decidiendo: qué comentarios reflejaban un problema común y cuáles nacían de un hábito individual; qué debíamos resolver de inmediato y qué, aunque útil, no debía entrar todavía en el producto.

Si dividimos el nombre del producto en dos, al final del año al menos habíamos construido la «calabaza»: un recipiente para recopilar, conservar y gestionar momentos de resonancia e inspiración.

La magia aún no ha aparecido

Pero aquello todavía no era la magia que teníamos en mente.

Sin duda usaría IA, pero no consistiría simplemente en generar el resumen de un artículo. Un resumen puede comprimir información sin hacer avanzar la cognición.

Según nuestra forma de entenderlo, la información es el contenido que una persona recibe; el conocimiento es información comprendida y organizada; la cognición es la manera en que una persona comprende el mundo, crea conexiones y juicios, y los revisa cuando llegan nuevas experiencias.

La IA actual procesa bien la información y cada vez organiza mejor el conocimiento. Puede resumir un artículo, extraer palabras clave y responder preguntas cuya respuesta ya está en el material. Pero, si solo comprime diez páginas en una o añade un cuadro de chat junto a una aplicación de notas, aún no ha tocado lo que realmente queremos construir.

Queremos que un futuro MagicGourd comprenda los registros que una persona ha acumulado a lo largo del tiempo y reúna momentos de resonancia dispersos entre distintas épocas y medios. Podría descubrir temas que se repiten sin haber sido expresados de forma explícita, mostrar conexiones y contradicciones entre notas, encontrar preguntas que llevan mucho tiempo sin respuesta o recuperar un pensamiento anterior en el momento oportuno.

Más importante aún, debería plantear preguntas que el usuario todavía no haya considerado pero que merezca la pena explorar, ayudándolo a formar nuevos juicios propios.

Aquí debe existir un límite claro: la IA no puede presentar sus conjeturas como una «verdad» que el usuario todavía no ha descubierto. Puede proponer posibles conexiones, contradicciones y preguntas. Si esas conexiones son válidas, debe decidirlo el usuario.

La magia no piensa en lugar del usuario. Le ayuda a ver el pensamiento que aún no ha terminado.

Durante el año construimos varias demos internas relacionadas con esta idea. Podían generar resúmenes, organizar contenido y responder preguntas. Ya parecían productos de IA. Pero todavía estaban lejos de lo que llamamos «hacer avanzar la cognición», así que no las publicamos deprisa solo para seguir la ola de la IA.

Cuanto más participa la IA en el proceso cognitivo de una persona, más privados son los datos a los que necesita acceder. Esto nos convenció aún más de que la privacidad y la propiedad de los datos no son cuestiones de ingeniería separadas de la magia: son requisitos para que la magia pueda existir. No podemos afirmar que queremos comprender a los usuarios y, al mismo tiempo, pedirles que renuncien al control de sus propios datos.

Así, el 31 de diciembre de 2024, la calabaza ya estaba, pero la magia aún no había aparecido.

No habíamos conseguido inversión, ni visto una señal decisiva del mercado, ni establecido un modelo de negocio claro. Seguíamos sin saber adónde acabaría llevando este río.

Pero habíamos publicado 27 versiones. Los usuarios empezaban a incorporar el producto a sus vidas. Y nosotros empezábamos a comprender cómo convertir una demo que funcionaba en un producto real y asumir la responsabilidad de mantenerlo a largo plazo.

Un año antes había escrito: «Sigo en el agua».

Un año después seguía en el agua. El río no se había vuelto más fácil ni la otra orilla más clara.

Pero ya habíamos construido la calabaza.

La magia aún no había aparecido. Tampoco habíamos llegado a la otra orilla. Pero, al menos, habíamos empezado a nadar hacia delante.

Un an a passé, et je suis toujours dans l’eau.

La rivière n’est pas devenue plus facile, ni l’autre rive plus nette. Mais quelque chose a changé. Au second semestre 2023, après avoir quitté SenseTime où j’avais travaillé près de dix ans, j’ai passé l’essentiel de mon temps à lutter et à chercher une direction. En 2024, nous avons commencé à consacrer la majeure partie de notre temps à construire un produit précis.

Le produit a constitué le fil principal de l’année ; quelques tentatives limitées de financement en ont été un fil secondaire. Nous n’avons pas levé de fonds ni vu de signal de marché assez fort pour confirmer notre direction, mais nous avons développé et publié 27 versions.

Après avoir plongé dans la rivière suivante, nous commencions enfin à apprendre à avancer à la nage.

D’abord, fabriquer une gourde

Dans l’essai écrit à la fin de l’année dernière, je disais avoir finalement décidé de commencer par les notes intelligentes.

Depuis le collège, j’ai pour habitude de ne pas lire sans écrire. Lorsque je lis un livre ou un article, ou que je regarde une vidéo, je remarque les passages qui me touchent, je les marque et je note les idées qui surgissent. J’appelle ce processus « trouver des points » : percevoir ce qui nous touche et consigner l’inspiration qui en naît.

Un point n’est parfois qu’une phrase, une image ou une seule séquence. Sur le moment, ces points peuvent sembler sans rapport. Mais, lorsqu’ils sont assez nombreux, ils finissent par se relier, m’aidant à comprendre un problème ou à former un jugement auquel je n’avais pas encore pensé.

Pendant des années, j’ai essayé différents outils de prise de notes sans jamais trouver un produit réellement adapté à cette habitude. Après avoir quitté SenseTime, j’ai retrouvé un ami d’enfance — celui avec qui je dénichais des oiseaux et me battais — et nous avons décidé de le construire ensemble. Durant le premier semestre 2024, nous avons travaillé la plupart du temps dans un espace partagé de la tour Sohu.

Nous avons appelé le produit MagicGourd.

« Gourd », la gourde, est aussi le surnom de mon enfant. Lorsque nous avons choisi ce nom, je ne lui ai pas consciemment attribué beaucoup de sens. Avec le recul, il contenait peut-être un espoir inconscient : que le premier produit construit après être devenu entrepreneur à plein temps puisse, comme un enfant, grandir lentement sous nos soins.

Un produit n’est évidemment pas un enfant. Mais ils ont un point commun : le faire naître n’est qu’un début. Le long travail qui consiste à en prendre soin et à le faire grandir est la partie réellement difficile.

Le véritable second cerveau que nous imaginions était encore loin de la réalité et ne pouvait être achevé en une seule étape. Nous avons donc commencé par la plus élémentaire : permettre aux utilisateurs de marquer ce qui les touche et de noter leur inspiration lorsqu’ils parcourent le Web, lisent un PDF en ligne ou regardent une vidéo.

D’abord, fabriquer une gourde capable de recueillir ces points.

Les choix de produit derrière un bouton de surlignage

Peu après le début du développement, nous avons rencontré une question qui semblait minuscule : à quoi devait ressembler le bouton de surlignage ?

Devait-il s’agir d’un seul bouton ou d’un panneau regroupant plusieurs actions ? Après la sélection d’un texte, devait-il apparaître immédiatement ou attendre d’être appelé ? Où devait-il apparaître, et quand devait-il disparaître ? Si quelqu’un n’aimait pas qu’il apparaisse automatiquement, fallait-il ajouter un réglage pour le désactiver ?

Chaque option supplémentaire semble répondre à davantage de besoins, mais elle augmente aussi le coût de compréhension et d’utilisation. Faire apparaître le bouton plus activement rend la fonction plus facile à découvrir, mais peut aussi interrompre sans cesse la lecture. Le rendre plus discret aide peut-être à rester concentré, mais l’utilisateur risque alors de ne jamais découvrir son existence.

Il n’existe pas de réponse standard, au sens algorithmique, à ce genre de questions.

Lorsque nous développons des algorithmes, nous demandons si une capacité peut être mise en œuvre, si la précision peut être améliorée et si les performances satisfont les exigences. En construisant un produit, nous avons commencé à poser une autre question : quand une fonction doit-elle intervenir, et quand doit-elle se retirer à l’arrière-plan ?

Le fait qu’une fonction s’exécute prouve seulement que la technologie fonctionne. Le fait que les utilisateurs la comprennent, ne se sentent pas interrompus et veuillent la garder dans leur quotidien détermine si le produit fonctionne.

J’avais déjà traité de nombreux problèmes du monde réel en développant des algorithmes et de grands projets. Mais, lorsque nous avons créé un produit à partir de zéro, des choix auparavant partagés entre les équipes produit, design, client et ingénierie sont soudain devenus les nôtres. Nous devions décider ce qui devait être visible et ce qui devait rester caché ; ce qu’il fallait construire maintenant et ce qu’il fallait laisser de côté, même si cela pouvait être utile.

Nous avons progressivement compris qu’un produit n’est pas fait du nombre de ses fonctions, mais d’innombrables arbitrages. Parfois, ne pas apparaître et ne pas interrompre sont aussi des capacités du produit.

Un produit doit tenir dans le temps

Le caractère naturel d’un bouton est une expérience immédiatement perceptible. Mais bien davantage de facteurs qui déterminent si un produit sera utilisé pendant des années restent invisibles.

MagicGourd conserve l’historique de lecture, les moments de résonance et les idées d’une personne. Nous voulions protéger autant que possible la vie privée des utilisateurs tout en proposant une synchronisation entre appareils et, à terme, des services intelligents. Pour concilier les deux, nous avons choisi de chiffrer les données localement et de ne stocker que du texte chiffré côté serveur. Cela a accru la complexité du développement et de la maintenance. Mais si une personne ne peut pas réellement posséder ses données, un véritable second cerveau est impossible dès le départ.

La synchronisation est un autre problème qui paraît simple et ne l’est pas. Lorsqu’une personne crée un surlignage, l’interface doit répondre immédiatement au lieu de s’arrêter pour attendre le réseau. La prise de notes ne doit pas être interrompue, même avec une connexion faible ou sans connexion. Lorsque le réseau revient, les données de différents appareils doivent se synchroniser correctement, sans doublon, écrasement ni disparition silencieuse.

Cela nous a obligés à repenser la collaboration entre le frontend et le backend, l’organisation des données dans la base, la compatibilité lors des mises à jour et la récupération après une erreur. L’utilisateur ne voit généralement pas ces choix. Mais lorsque l’un d’eux échoue, toute cette complexité cachée devient immédiatement l’expérience la plus directe.

L’expérience à court terme est relativement facile à produire. Il n’est pas si difficile de réaliser une démonstration fluide qui impressionne pendant quelques minutes. Mais, à nos yeux, ce ne serait encore qu’une démo.

Une démo doit seulement tenir sous nos yeux. Un produit doit tenir dans le temps.

Si un produit doit accompagner quelqu’un pendant dix ans, les fondations de son expérience dans dix ans doivent être construites aujourd’hui. Une panne dans un outil ordinaire n’est peut-être qu’un désagrément temporaire. Dans un produit qui contient des années de notes, une seule perte de données peut détruire toute la confiance accumulée par l’utilisateur.

Nous ne pouvons pas promettre que le système ne connaîtra jamais de problème. Mais « ne pas perdre une seule note d’utilisateur » doit rester l’une de nos contraintes de conception les plus importantes. L’expérience produit ne se déroule pas seulement à l’écran ; elle existe aussi dans la base de données que l’utilisateur ne voit jamais.

Un très court détour par le financement

Il est peut-être exagéré de qualifier le financement de fil secondaire de l’année. Nous n’avons parlé qu’à trois sociétés d’investissement et avons consacré presque tout le reste de notre temps au produit.

Notre idée était simple : approcher des investisseurs en phase initiale que nous connaissions directement ou indirectement, leur présenter ce que nous construisions et essayer d’obtenir notre premier investissement providentiel.

La valeur de cet investissement ne résidait pas seulement dans l’argent. Le produit n’était pas terminé et aucun signal clair du marché n’était apparu. À ce stade, nous voulions un regard extérieur sur la question de savoir si d’excellents investisseurs jugeaient cette direction pertinente.

Aucune de ces tentatives n’a abouti. À l’époque, nous l’expliquions par un environnement de financement difficile pour les applications d’IA et par notre manque d’expérience dans les échanges avec les investisseurs. Ces deux facteurs existaient. Mais, avec le recul, un fait plus immédiat s’imposait : nous avions consacré peu de temps à la levée de fonds et parlé à seulement trois sociétés. Plutôt que de dire que nous avions traversé un tour de financement raté, il serait plus juste de parler de quelques conversations préliminaires.

Ce qui mérite davantage de réflexion, c’est ma réaction face aux objections.

Lors de notre entretien avec MiraclePlus, les personnes assises en face de moi étaient des gens que je respectais profondément. Lorsqu’elles remettaient sans cesse nos idées en question et formulaient leurs questions de façon très tranchante, j’étais partagé : puisque nous étions venus chercher un investissement, il me semblait devoir respecter leur jugement et même, dans une certaine mesure, me rapprocher des réponses qu’elles attendaient.

Mais si le but de la levée de fonds était de recevoir un retour sincère, dire des choses auxquelles nous ne croyions pas aurait privé ce retour de tout sens.

Plus tard, j’ai commencé à me demander si nous ne cherchions vraiment qu’un retour. Peut-être voulions-nous aussi, avant que le marché ne valide le produit, l’approbation d’un groupe d’excellents investisseurs pour nous rassurer sur la direction choisie.

C’était comme se tenir dans une rivière inconnue en espérant que quelqu’un, sur la rive, nous indique d’abord où nager. Mais un entrepreneur doit finalement sentir lui-même le courant et juger à partir des faits qu’il a devant lui.

Les « Anciens de Xuanming » de la tour Dongsheng

Au second semestre 2024, nous avons quitté la tour Sohu pour la tour Dongsheng.

Mon ami d’enfance et moi programmions en binôme pendant de longues périodes, souvent assis devant le même écran à discuter. Parmi les jeunes entrepreneurs de l’espace partagé, cette manière de travailler se remarquait. Avec le temps, on nous a donné un surnom : les « Anciens de Xuanming ».

C’était amusant. Deux personnes qui, enfants, dénichaient des oiseaux et se battaient ensemble se retrouvaient vingt ans plus tard dans un bureau partagé à construire un produit appelé MagicGourd.

C’est à la tour Dongsheng que nous avons rencontré Kehan. Chez MiraclePlus, il était chargé de la communauté et du recrutement de projets entrepreneuriaux. La première fois qu’il nous a parlé, il a demandé : « Vous êtes des entrepreneurs, n’est-ce pas ? Je vous observe depuis longtemps. Dans tout le bureau, c’est vous deux qui avez le plus l’allure de véritables fondateurs. »

Plus tard, lorsqu’il a appris que nous avions passé un entretien avec MiraclePlus, nous avons reparlé de ce moment. Il nous a expliqué que, lorsque les investisseurs remettent sans cesse une idée en question, ils n’expriment pas toujours seulement leur désaccord. Ils peuvent aussi vérifier si les fondateurs ont réellement réfléchi au sujet et s’ils savent conserver leur jugement sous pression.

Cela m’a permis de relire l’entretien autrement.

Respecter les investisseurs ne signifie pas leur remettre notre jugement. Un entrepreneur doit comprendre pourquoi les autres ne sont pas d’accord sans abandonner son propre jugement simplement parce que ces personnes méritent son respect. Ce qu’il faut éviter, ce n’est pas de changer d’avis face à de nouveaux faits, mais de changer ce que l’on dit uniquement pour obtenir une approbation avant d’avoir réellement réfléchi.

Cette leçon dépasse le financement. En construisant un produit, nous rencontrons chaque jour des retours d’utilisateurs, des choix faits par des produits concurrents et de nouvelles tendances technologiques. Tous ces signaux extérieurs méritent notre attention, mais décider de ce qui doit entrer dans le produit reste notre responsabilité.

La gourde est là

À la fin de 2024, nous avions développé et publié 27 versions de MagicGourd.

Nous avons commencé par les annotations de texte et d’image sur des pages Web ordinaires, puis ajouté la prise en charge des PDF en ligne et étendu la même méthode à Bilibili et YouTube. L’utilisateur pouvait marquer une image vidéo qui le touchait, écrire une note et revenir rapidement à ces moments sur la ligne du temps. Nous avons également ajouté la gestion des étiquettes, la recherche et l’exportation, et synchronisé les données entre navigateurs et appareils.

Chaque nouveau format de contenu exigeait beaucoup d’adaptation. Les pages Web n’ont pas de structure uniforme et les plateformes vidéo changent constamment. Une fonction qui marche correctement sur un site peut se comporter tout autrement sur une autre page ou dans un autre navigateur. Une grande partie de notre temps n’a pas produit de capacités nouvelles et visibles ; elle a servi à traiter les cas limites afin que les capacités existantes fonctionnent de façon plus stable.

Dans les 27 versions publiées cette année-là, nous n’avons constaté aucun cas de perte ou de corruption de données utilisateur. Les défaillances occasionnelles concernaient surtout des étapes de service telles que les codes de vérification de connexion. Lorsque nous recevions un signalement, nous pouvions généralement localiser et résoudre rapidement le problème. Cela ne prouve pas que le système ne connaîtra jamais de panne, mais montre au moins que le temps consacré à ce que l’utilisateur ne voit pas n’a pas été perdu.

En novembre, nous avons présenté la fonction de notes vidéo sur sspai. Des utilisateurs ont commencé à laisser des commentaires. Une personne qui sauvegardait auparavant les images utiles d’une vidéo en faisant des captures d’écran puis en les collant ailleurs a écrit après avoir essayé MagicGourd : « Cette extension m’a sauvé ! » D’autres appréciaient les marqueurs en forme de goutte sur la ligne du temps, demandaient des notes indépendantes ou espéraient une prise en charge rapide de Safari.

Recevoir les retours des utilisateurs a été l’une des plus grandes joies de l’année.

Ce qui nous réjouissait n’était pas seulement que l’on fasse l’éloge du produit, mais que quelqu’un ait intégré à sa vie réelle quelque chose que nous avions créé. Les utilisateurs proposaient aussi des suggestions utiles qui nous obligeaient à continuer de choisir : quels commentaires révélaient un problème commun et lesquels venaient d’une habitude individuelle ; ce qui devait être résolu immédiatement et ce qui, bien qu’utile, ne devait pas encore entrer dans le produit.

Si l’on sépare le nom du produit en deux, à la fin de l’année nous avions au moins construit la « gourde » : un récipient pour recueillir, conserver et organiser les moments de résonance et d’inspiration.

La magie ne s’est pas encore manifestée

Mais ce n’était pas encore la magie que nous avions en tête.

Elle ferait certainement appel à l’IA, mais ne se contenterait pas de générer le résumé d’un article. Un résumé peut compresser l’information sans faire progresser la cognition.

Selon notre compréhension, l’information est le contenu qu’une personne reçoit ; la connaissance est une information comprise et organisée ; la cognition est la manière dont une personne comprend le monde, établit des liens et des jugements, puis les révise à mesure que de nouvelles expériences arrivent.

L’IA actuelle sait bien traiter l’information et devient de plus en plus efficace pour organiser les connaissances. Elle peut résumer un article, extraire des mots-clés et répondre à des questions dont la réponse figure déjà dans le contenu. Mais si elle se contente de réduire dix pages à une ou d’ajouter une fenêtre de discussion à côté d’une application de notes, elle n’a pas encore touché ce que nous voulons réellement construire.

Nous voulons qu’un futur MagicGourd comprenne les traces accumulées par une personne au fil du temps et réunisse des moments de résonance dispersés entre différentes périodes et différents médias. Il pourrait découvrir des thèmes récurrents qui n’ont jamais été formulés explicitement, révéler les liens et les contradictions entre des notes, repérer des questions restées longtemps sans réponse ou faire ressurgir une réflexion passée au bon moment.

Plus important encore, il devrait soulever des questions que l’utilisateur n’a pas encore envisagées mais qui méritent d’être poursuivies, afin de l’aider à former ses propres nouveaux jugements.

Une limite claire est nécessaire : l’IA ne peut pas présenter ses suppositions comme une « vérité » que l’utilisateur n’aurait pas encore découverte. Elle peut proposer des liens, des contradictions et des questions possibles. Il appartient toujours à l’utilisateur de décider si ces liens tiennent.

La magie ne pense pas à la place de l’utilisateur. Elle l’aide à voir la réflexion qu’il n’a pas encore terminée.

Au cours de l’année, nous avons construit plusieurs démos internes autour de cette idée. Elles pouvaient générer des résumés, organiser du contenu et répondre à des questions. Elles ressemblaient déjà à des produits d’IA. Mais elles restaient loin de ce que nous appelions « faire progresser la cognition », et nous ne les avons donc pas mises en ligne à la hâte simplement pour suivre la vague de l’IA.

Plus l’IA participe profondément au processus cognitif d’une personne, plus les données auxquelles elle doit accéder sont privées. Cela nous a encore davantage convaincus que la vie privée et la propriété des données ne sont pas des problèmes d’ingénierie séparés de la magie : elles sont des conditions préalables à son existence. Nous ne pouvons pas prétendre vouloir comprendre les utilisateurs tout en leur demandant d’abandonner le contrôle de leurs propres données.

Ainsi, au 31 décembre 2024, la gourde était là, mais la magie ne s’était pas encore manifestée.

Nous n’avions pas levé de fonds, ni vu de signal décisif du marché, ni établi de modèle économique clair. Nous ne savions toujours pas où cette rivière finirait par nous conduire.

Mais nous avions publié 27 versions. Des utilisateurs commençaient à intégrer le produit à leur vie. Et nous commencions à comprendre comment transformer une démo fonctionnelle en un véritable produit et en assumer la responsabilité dans la durée.

Un an plus tôt, j’avais écrit : « Je suis encore dans l’eau. »

Un an plus tard, j’étais toujours dans l’eau. La rivière n’était pas devenue plus facile, ni l’autre rive plus nette.

Mais nous avions construit la gourde.

La magie ne s’était pas encore manifestée. Nous n’avions pas atteint l’autre rive non plus. Mais au moins, nous avions commencé à avancer à la nage.

एक वर्ष बीत गया, और मैं अभी भी पानी में हूँ।

नदी आसान नहीं हुई है, न ही दूसरा किनारा अधिक साफ़ दिखाई देने लगा है। लेकिन एक बात बदल गई है। 2023 की दूसरी छमाही में, लगभग दस साल काम करने के बाद SenseTime से निकलते ही, मैंने अपना अधिकांश समय संघर्ष करने और दिशा खोजने में बिताया। 2024 में हमने अपना अधिकांश समय एक ठोस उत्पाद बनाने में लगाना शुरू किया।

उस वर्ष की मुख्य धारा उत्पाद था; धन जुटाने की कुछ सीमित कोशिशें उसकी सहायक धारा थीं। हमें निवेश नहीं मिला और ऐसा कोई बाज़ार संकेत भी नहीं मिला जो दिशा को प्रमाणित करने के लिए पर्याप्त हो। फिर भी हमने 27 संस्करण विकसित करके जारी किए।

अगली नदी में कूदने के बाद हम आख़िरकार आगे तैरना सीखने लगे थे।

पहले एक लौकी बनाना

पिछले वर्ष के अंत में लिखे निबंध में मैंने बताया था कि अंततः मैंने बुद्धिमान नोट्स से शुरुआत करने का निर्णय लिया।

माध्यमिक विद्यालय से ही मेरी आदत रही है कि मैं बिना लिखे पढ़ता नहीं। किताब या लेख पढ़ते समय, या वीडियो देखते समय, मैं उन हिस्सों पर ध्यान देता हूँ जो मुझे भीतर से छूते हैं, उन्हें चिह्नित करता हूँ और उस क्षण आए विचार लिख लेता हूँ। मैं इस प्रक्रिया को “बिंदु खोजना” कहता हूँ: जो भीतर असर करे उसे पहचानना और उससे निकली प्रेरणा दर्ज करना।

कभी कोई बिंदु केवल एक वाक्य, एक चित्र या एक दृश्य होता है। उस समय वे एक-दूसरे से असंबद्ध लग सकते हैं। लेकिन पर्याप्त मात्रा में जमा होने के बाद किसी क्षण वे आपस में जुड़ जाते हैं और मुझे किसी समस्या को समझने या ऐसा निर्णय बनाने में मदद करते हैं जिसके बारे में मैंने पहले नहीं सोचा था।

कई वर्षों तक मैंने अलग-अलग नोट उपकरण आज़माए, लेकिन ऐसा उत्पाद नहीं मिला जो सचमुच इस आदत के अनुकूल हो। SenseTime छोड़ने के बाद मैंने अपने बचपन के उस मित्र को बुलाया जिसके साथ मैं पक्षियों के घोंसले टटोला करता और लड़ाइयाँ करता था, और हमने इसे साथ बनाने का निश्चय किया। 2024 की पहली छमाही में हमने अपना अधिकांश समय Sohu Tower के एक साझा कार्यस्थल में बिताया।

हमने उत्पाद का नाम MagicGourd रखा।

“लौकी” मेरे बच्चे का घर का नाम भी है। नाम चुनते समय मैंने जानबूझकर उसमें इतना अर्थ नहीं भरा था। पीछे मुड़कर देखता हूँ तो शायद उसमें एक अवचेतन इच्छा छिपी थी: पूर्णकालिक उद्यमी बनने के बाद बनाया गया मेरा पहला उत्पाद भी किसी बच्चे की तरह हमारी देखभाल में धीरे-धीरे बड़ा हो।

उत्पाद निश्चित रूप से बच्चा नहीं है। फिर भी दोनों में एक समानता है: उसे दुनिया में लाना केवल शुरुआत है। लंबे समय तक उसकी देखभाल करना और उसे बढ़ाना ही वास्तव में कठिन हिस्सा है।

जिस सच्चे दूसरे मस्तिष्क की हमने कल्पना की थी, वह अभी वास्तविकता से बहुत दूर था और एक ही कदम में पूरा नहीं हो सकता था। इसलिए हमने सबसे बुनियादी कदम से शुरू करने का निर्णय लिया: वेब ब्राउज़ करते, ऑनलाइन PDF पढ़ते या वीडियो देखते समय उपयोगकर्ता जिस चीज़ से प्रभावित हों उसे चिह्नित कर सकें और अपनी प्रेरणा लिख सकें।

पहले ऐसी लौकी बनाना जो इन बिंदुओं को समेट सके।

हाइलाइट बटन के पीछे के उत्पाद निर्णय

विकास शुरू करने के कुछ ही समय बाद हमारे सामने एक ऐसा प्रश्न आया जो लगभग बहुत छोटा लगता था: हाइलाइट बटन कैसा होना चाहिए?

क्या वह केवल एक बटन हो या कई क्रियाओं वाला पैनल? उपयोगकर्ता के पाठ चुनते ही वह सामने आ जाए या बुलाए जाने की प्रतीक्षा करे? वह कहाँ दिखाई दे और कब गायब हो? अगर किसी को उसका अपने आप आना पसंद न हो, तो क्या उसे बंद करने का विकल्प देना चाहिए?

हर अतिरिक्त विकल्प अधिक आवश्यकताओं को पूरा करता हुआ लगता है, पर उत्पाद को समझने और चलाने की लागत भी बढ़ाता है। बटन को अधिक सक्रिय रूप से दिखाने पर सुविधा आसानी से मिलती है, लेकिन पढ़ने में बार-बार बाधा आ सकती है। उसे शांत रखने से ध्यान बना रह सकता है, पर उपयोगकर्ता को शायद कभी पता ही न चले कि सुविधा मौजूद है।

ऐसे प्रश्नों का एल्गोरिदमिक अर्थ में कोई मानक उत्तर नहीं होता।

एल्गोरिदम बनाते समय हम पूछते हैं कि कोई क्षमता लागू हो सकती है या नहीं, सटीकता बढ़ सकती है या नहीं, और प्रदर्शन अपेक्षा पूरी करता है या नहीं। उत्पाद बनाते समय हमने दूसरा प्रश्न बार-बार पूछना शुरू किया: किसी सुविधा को कब सामने आना चाहिए और कब पीछे हट जाना चाहिए?

किसी सुविधा का चलना केवल यह साबित करता है कि तकनीक काम करती है। लोग उसे समझते हैं या नहीं, उससे बाधित महसूस करते हैं या नहीं, और उसे अपने दैनिक जीवन में रखना चाहते हैं या नहीं—यही तय करता है कि उत्पाद काम करता है।

एल्गोरिदम और बड़े प्रोजेक्ट बनाते समय मैंने वास्तविक दुनिया की बहुत-सी समस्याओं पर काम किया था। लेकिन जब हमने शून्य से उत्पाद बनाया, तो जो निर्णय पहले उत्पाद, डिज़ाइन, ग्राहक और इंजीनियरिंग टीमें मिलकर लेती थीं, वे अचानक केवल हमारे हो गए। हमें तय करना पड़ा कि क्या दिखाई दे और क्या पीछे छिपा रहे; क्या अभी बनाया जाए और क्या उपयोगी होने पर भी फिलहाल छोड़ दिया जाए।

धीरे-धीरे हमने समझा कि उत्पाद सुविधाओं की संख्या से नहीं, अनगिनत चुनावों से बनता है। कभी-कभी सामने न आना और बाधा न बनना भी उत्पाद की क्षमता होती है।

उत्पाद को समय की कसौटी पर टिकना होता है

बटन स्वाभाविक लगता है या नहीं, यह उपयोगकर्ता तुरंत महसूस कर सकता है। लेकिन उत्पाद वर्षों तक इस्तेमाल होगा या नहीं, इसे तय करने वाले बहुत-से तत्व उसकी नज़र से छिपे रहते हैं।

MagicGourd किसी व्यक्ति का पढ़ने का इतिहास, मन को छूने वाले क्षण और विचार सुरक्षित रखता है। हम उपयोगकर्ता की निजता की अधिकतम रक्षा करना चाहते थे और साथ ही उपकरणों के बीच सिंक्रोनाइज़ेशन तथा भविष्य में बुद्धिमान सेवाएँ देना चाहते थे। दोनों के लिए हमने डेटा को स्थानीय रूप से एन्क्रिप्ट करने और बैकएंड पर केवल एन्क्रिप्टेड पाठ रखने का रास्ता चुना। इससे विकास और रखरखाव जटिल हुए। लेकिन यदि व्यक्ति अपने डेटा का वास्तविक स्वामी नहीं हो सकता, तो सच्चा दूसरा मस्तिष्क शुरू से ही असंभव है।

सिंक्रोनाइज़ेशन एक और समस्या है जो सरल दिखती है लेकिन वास्तव में बहुत जटिल है। उपयोगकर्ता हाइलाइट बनाए तो इंटरफ़ेस को नेटवर्क की प्रतीक्षा में रुकने के बजाय तुरंत प्रतिक्रिया देनी चाहिए। कमज़ोर नेटवर्क या पूरी तरह ऑफ़लाइन होने पर भी रिकॉर्डिंग नहीं रुकनी चाहिए। नेटवर्क लौटे तो अलग-अलग उपकरणों का डेटा बिना दोहराव, ओवरराइट या चुपचाप गायब हुए सही ढंग से सिंक्रोनाइज़ होना चाहिए।

इसके लिए हमें फिर से सोचना पड़ा कि फ्रंटएंड और बैकएंड कैसे साथ काम करें, डेटाबेस डेटा को कैसे व्यवस्थित करे, संस्करण बदलने पर अनुकूलता कैसे बनी रहे और गलती के बाद व्यवस्था कैसे सुधरे। उपयोगकर्ता आम तौर पर ये निर्णय नहीं देखता। लेकिन इनमें से एक भी विफल हो तो पूरी छिपी जटिलता एक पल में सबसे प्रत्यक्ष उपयोगकर्ता अनुभव बन जाती है।

अल्पकालिक अनुभव बनाना अपेक्षाकृत आसान है। कुछ मिनटों के लिए किसी को प्रभावित करने वाला सहज डेमो बनाना इतना कठिन नहीं। लेकिन हमारी नज़र में वह फिर भी केवल डेमो होगा।

डेमो को केवल सामने के क्षण में टिकना होता है। उत्पाद को समय की कसौटी पर टिकना होता है।

यदि कोई उत्पाद दस साल तक उपयोगकर्ता का साथ देना चाहता है, तो दस साल बाद के अनुभव की नींव आज ही बनानी होगी। साधारण उपकरण में एक खराबी अस्थायी असुविधा हो सकती है। वर्षों के नोट सँभालने वाले उत्पाद में डेटा की एक हानि उपयोगकर्ता का सारा भरोसा नष्ट कर सकती है।

हम यह वादा नहीं कर सकते कि व्यवस्था में कभी समस्या नहीं आएगी। लेकिन “उपयोगकर्ता का एक भी नोट न खोना” हमारी सबसे महत्वपूर्ण डिज़ाइन सीमाओं में से एक होना चाहिए। उत्पाद अनुभव केवल स्क्रीन पर नहीं, उस डेटाबेस में भी होता है जिसे उपयोगकर्ता कभी नहीं देखता।

धन जुटाने की बहुत छोटी सहायक धारा

धन जुटाने को उस वर्ष की सहायक धारा कहना भी शायद अतिशयोक्ति है। हमने केवल तीन निवेश संस्थाओं से बात की और लगभग पूरा बाकी समय उत्पाद बनाने में लगाया।

हमारा विचार सरल था: सीधे या परोक्ष रूप से परिचित शुरुआती निवेशकों से संपर्क करें, उन्हें बताएँ कि हम क्या बना रहे हैं और पहला एंजेल निवेश पाने की कोशिश करें।

उस निवेश का अर्थ केवल पैसा नहीं था। उत्पाद अधूरा था और बाज़ार का कोई स्पष्ट संकेत नहीं था। उस चरण में हम बाहर से यह प्रतिक्रिया चाहते थे कि अच्छे निवेशकों को यह दिशा सार्थक लगती है या नहीं।

इन कोशिशों से कोई परिणाम नहीं निकला। उस समय हमने इसका कारण AI अनुप्रयोगों के लिए कठिन निवेश वातावरण और निवेशकों से बातचीत में अपनी अनुभवहीनता को माना। दोनों कारण मौजूद थे। लेकिन पीछे मुड़कर देखने पर एक अधिक सीधा तथ्य था: हमने धन जुटाने में कम समय लगाया और केवल तीन संस्थाओं से बात की। इसे असफल निवेश दौर कहने के बजाय निवेशकों के साथ कुछ शुरुआती बातचीत कहना अधिक सही होगा।

जिस बात पर अधिक विचार चाहिए, वह चुनौती दिए जाने पर मेरी प्रतिक्रिया थी।

MiraclePlus के साक्षात्कार में मेरे सामने ऐसे लोग बैठे थे जिनका मैं बहुत सम्मान करता था। जब उन्होंने बार-बार हमारे विचारों पर प्रश्न उठाए और बहुत तीखे ढंग से सवाल पूछे, तो मेरे भीतर तनाव पैदा हुआ। हम निवेश माँगने आए थे, इसलिए लगा कि उनके निर्णय का सम्मान करना और कुछ हद तक उन उत्तरों के करीब जाना चाहिए जिनकी वे अपेक्षा करते हैं।

लेकिन यदि धन जुटाने का उद्देश्य ईमानदार प्रतिक्रिया पाना था, तो ऐसी बातें कहना जिन पर हम स्वयं विश्वास नहीं करते, उस प्रतिक्रिया को अर्थहीन कर देता।

बाद में मैंने सोचना शुरू किया कि क्या हमें वास्तव में केवल प्रतिक्रिया चाहिए थी। शायद बाज़ार द्वारा उत्पाद को प्रमाणित करने से पहले हम उत्कृष्ट निवेशकों के एक समूह की स्वीकृति भी चाहते थे, ताकि खुद को भरोसा दिला सकें कि दिशा गलत नहीं चुनी।

यह किसी अनजान नदी में खड़े होकर किनारे पर बैठे व्यक्ति से पहले यह बताने की आशा करने जैसा था कि किस ओर तैरना है। लेकिन उद्यमी को अंततः धारा खुद महसूस करनी और सामने के तथ्यों के आधार पर निर्णय लेना पड़ता है।

Dongsheng Tower के “Xuanming Elders”

2024 की दूसरी छमाही में हम Sohu Tower से Dongsheng Tower चले गए।

मेरा बचपन का मित्र और मैं लंबे समय तक जोड़ी में प्रोग्रामिंग करते, अक्सर एक ही स्क्रीन के सामने बैठकर चर्चा करते थे। साझा कार्यालय के युवा उद्यमियों के बीच यह तरीका अलग दिखाई देता था। समय के साथ लोगों ने हमें एक उपनाम दिया: “Xuanming Elders”।

यह मज़ेदार था। बचपन में साथ पक्षियों के घोंसले टटोलने और लड़ने वाले दो लोग बीस साल बाद साझा कार्यालय में बैठकर MagicGourd नाम का उत्पाद बना रहे थे।

Kehan से हमारी मुलाकात भी Dongsheng Tower में हुई। MiraclePlus में वह समुदाय और उद्यमी प्रोजेक्ट भर्ती के लिए ज़िम्मेदार था। पहली बार बात करते हुए उसने पूछा: “आप दोनों उद्यमी हैं, है न? मैं आपको काफ़ी समय से देख रहा हूँ। इस पूरे कार्यालय में आप दोनों सबसे अधिक सच्चे संस्थापक जैसे काम करते दिखाई देते हैं।”

बाद में जब उसे पता चला कि हमने MiraclePlus का साक्षात्कार दिया था, तो हमने उस अनुभव पर बात की। उसने बताया कि निवेशक जब किसी स्टार्टअप विचार पर बार-बार सवाल उठाते हैं, तो हमेशा केवल असहमति व्यक्त नहीं कर रहे होते। कभी-कभी वे यह भी जाँचते हैं कि संस्थापकों ने बात सचमुच सोची है या नहीं और दबाव में अपना निर्णय बनाए रख सकते हैं या नहीं।

इससे मैंने उस साक्षात्कार को नए ढंग से समझा।

निवेशकों का सम्मान करने का अर्थ अपना निर्णय उन्हें सौंप देना नहीं है। उद्यमी को समझना चाहिए कि दूसरे लोग असहमत क्यों हैं, लेकिन केवल इसलिए अपना निर्णय नहीं छोड़ना चाहिए कि वे सम्मान के योग्य हैं। नई सच्चाइयों के कारण विचार बदलना समस्या नहीं है; पूरी तरह सोचने से पहले केवल स्वीकृति पाने के लिए अपनी बात बदलना समस्या है।

यह सीख केवल धन जुटाने तक सीमित नहीं। उत्पाद बनाते समय हमें रोज़ उपयोगकर्ता प्रतिक्रिया, प्रतिस्पर्धी उत्पादों के चुनाव और नई तकनीकी प्रवृत्तियाँ मिलती हैं। इन बाहरी संकेतों को गंभीरता से समझना चाहिए, लेकिन उत्पाद में क्या जाना चाहिए, यह तय करना हमारी ज़िम्मेदारी है।

लौकी तैयार है

2024 के अंत तक हमने MagicGourd के 27 संस्करण विकसित करके जारी कर दिए थे।

हमने सामान्य वेब पृष्ठों पर पाठ और चित्र की टिप्पणियों से शुरुआत की, फिर ऑनलाइन PDF का समर्थन जोड़ा और वही तरीका Bilibili तथा YouTube तक फैलाया। उपयोगकर्ता वीडियो के उस दृश्य को चिह्नित कर सकता था जो उसे छूता था, नोट लिख सकता था और टाइमलाइन से उस क्षण पर जल्दी लौट सकता था। हमने टैग प्रबंधन, खोज और निर्यात भी जोड़े और ब्राउज़र तथा उपकरणों के बीच डेटा सिंक्रोनाइज़ किया।

हर नए सामग्री प्रारूप के लिए बहुत अनुकूलन करना पड़ा। वेब पृष्ठों की कोई एक समान संरचना नहीं, और वीडियो प्लेटफ़ॉर्म बदलते रहते हैं। एक साइट पर सही काम करने वाली सुविधा दूसरे पृष्ठ या ब्राउज़र में बिल्कुल अलग व्यवहार कर सकती है। हमारा बहुत-सा समय दिखाई देने वाली नई क्षमता बनाने में नहीं, बल्कि किनारी स्थितियाँ सँभालने और मौजूदा क्षमताओं को अधिक स्थिर बनाने में लगा।

उस वर्ष जारी 27 संस्करणों में हमें उपयोगकर्ता डेटा खोने या खराब होने का कोई मामला नहीं मिला। कभी-कभार की गड़बड़ियाँ मुख्यतः लॉगिन सत्यापन कोड जैसे सेवा चरणों में थीं। सूचना मिलने पर हम आम तौर पर जल्दी कारण खोजकर समस्या हल कर लेते थे। यह साबित नहीं करता कि व्यवस्था कभी विफल नहीं होगी, लेकिन इतना अवश्य बताता है कि अदृश्य हिस्सों पर लगाया समय व्यर्थ नहीं गया।

नवंबर में हमने sspai पर वीडियो नोट सुविधा का परिचय दिया। उपयोगकर्ताओं ने टिप्पणियाँ छोड़नी शुरू कीं। पहले उपयोगी वीडियो दृश्य को स्क्रीनशॉट लेकर कहीं और चिपकाने वाले एक व्यक्ति ने MagicGourd आज़माने के बाद लिखा: “इस एक्सटेंशन ने मुझे बचा लिया!” कुछ लोगों को टाइमलाइन पर बूँद के आकार के चिह्न पसंद आए, कुछ ने स्वतंत्र नोट माँगे और कुछ Safari समर्थन का इंतज़ार कर रहे थे।

उपयोगकर्ता प्रतिक्रिया पाना उस वर्ष की सबसे बड़ी खुशियों में से एक था।

हमें खुशी केवल इसलिए नहीं थी कि लोगों ने उत्पाद की प्रशंसा की, बल्कि इसलिए कि किसी ने हमारी बनाई चीज़ को अपने वास्तविक जीवन का हिस्सा बनाया। उन्होंने उपयोगी सुझाव भी दिए, जिनसे हमें बार-बार तय करना पड़ा: कौन-सी टिप्पणी साझा समस्या दिखाती है और कौन-सी व्यक्तिगत आदत से आती है; क्या तुरंत हल करना चाहिए और क्या उपयोगी होने पर भी इस चरण में उत्पाद का हिस्सा नहीं होना चाहिए।

यदि उत्पाद के नाम को दो भागों में बाँटें, तो वर्ष के अंत तक कम से कम “लौकी” बन चुकी थी: मन को छूने वाले क्षण और प्रेरणा इकट्ठा करने, सुरक्षित रखने और व्यवस्थित करने का एक पात्र।

जादू अभी प्रकट नहीं हुआ

लेकिन यह अभी वह जादू नहीं था जिसकी हमने कल्पना की थी।

उसमें AI का उपयोग अवश्य होगा, लेकिन वह केवल लेख का सार बनाने तक सीमित नहीं होगा। सार सूचना को छोटा कर सकता है, पर ज़रूरी नहीं कि वह संज्ञान को आगे बढ़ाए।

हमारी समझ में सूचना वह सामग्री है जो व्यक्ति को मिलती है; ज्ञान समझी और व्यवस्थित की गई सूचना है; संज्ञान वह तरीका है जिससे व्यक्ति दुनिया को समझता है, संबंध और निर्णय बनाता है और नए अनुभव आने पर उन्हें बदलता है।

आज का AI सूचना संसाधित करने में अच्छा है और ज्ञान व्यवस्थित करने में लगातार बेहतर हो रहा है। वह लेख का सार बना सकता है, मुख्य शब्द निकाल सकता है और उन प्रश्नों का उत्तर दे सकता है जिनका उत्तर सामग्री में पहले से मौजूद है। लेकिन यदि वह केवल दस पृष्ठों को एक पृष्ठ में समेटता है या नोट ऐप के पास चैट बॉक्स जोड़ता है, तो उसने अभी उस चीज़ को नहीं छुआ जिसे हम वास्तव में बनाना चाहते हैं।

हम चाहते हैं कि भविष्य का MagicGourd किसी व्यक्ति द्वारा लंबे समय में जमा किए गए रिकॉर्ड समझे और अलग-अलग समय तथा माध्यमों में बिखरे प्रभाव के क्षणों को दोबारा मिलाए। वह बार-बार लौटने वाले पर कभी स्पष्ट रूप से न कहे गए विषय खोज सके, नोटों के बीच संबंध और विरोध दिखा सके, लंबे समय से अनुत्तरित प्रश्न पहचान सके या पुराने विचार को सही समय पर वापस ला सके।

और भी महत्वपूर्ण यह है कि वह ऐसे प्रश्न उठाए जिनके बारे में उपयोगकर्ता ने अभी नहीं सोचा, लेकिन जिन्हें आगे बढ़ाना सार्थक हो, और इस तरह उसे अपने नए निर्णय बनाने में मदद करे।

यहाँ स्पष्ट सीमा आवश्यक है: AI अपनी अटकल को ऐसी “सच्चाई” बनाकर प्रस्तुत नहीं कर सकता जिसे उपयोगकर्ता ने अभी नहीं पहचाना। वह संभावित संबंध, विरोध और प्रश्न सामने रख सकता है। वे संबंध सही हैं या नहीं, यह निर्णय अंततः उपयोगकर्ता का है।

जादू उपयोगकर्ता की जगह सोचता नहीं। वह उपयोगकर्ता को अपनी अधूरी सोच देखने में मदद करता है।

उस वर्ष हमने इस विचार से जुड़े कुछ आंतरिक डेमो बनाए। वे सार बना सकते थे, सामग्री व्यवस्थित कर सकते थे और प्रश्नों का उत्तर दे सकते थे। वे कुछ हद तक AI उत्पाद जैसे दिखते थे। लेकिन जिसे हम “संज्ञान को आगे बढ़ाना” कहते थे, उससे वे अभी बहुत दूर थे, इसलिए केवल AI की लहर के साथ बने रहने के लिए हमने उन्हें जल्दबाज़ी में जारी नहीं किया।

AI जितना गहराई से किसी व्यक्ति की संज्ञान प्रक्रिया में भाग लेता है, उसे उतना ही निजी डेटा देखना पड़ता है। इससे हमारा विश्वास और मजबूत हुआ कि निजता और डेटा स्वामित्व जादू से अलग इंजीनियरिंग समस्याएँ नहीं, बल्कि जादू के अस्तित्व की शर्तें हैं। हम यह नहीं कह सकते कि हम उपयोगकर्ताओं को समझना चाहते हैं और साथ ही उनसे अपने डेटा का नियंत्रण छोड़ने को कहें।

इसलिए 31 दिसंबर 2024 को लौकी तैयार थी, लेकिन जादू अभी प्रकट नहीं हुआ था।

हमें निवेश नहीं मिला था, निर्णायक बाज़ार संकेत नहीं दिखा था और स्पष्ट व्यवसाय मॉडल नहीं बना था। हमें अब भी नहीं पता था कि यह नदी अंततः कहाँ ले जाएगी।

लेकिन हमने 27 संस्करण जारी किए थे। उपयोगकर्ता उत्पाद को अपने जीवन में लाने लगे थे। और हम समझने लगे थे कि चलने वाले डेमो को वास्तविक उत्पाद में कैसे बदला जाए और लंबे समय तक उसकी ज़िम्मेदारी कैसे ली जाए।

एक वर्ष पहले मैंने लिखा था: “मैं अभी भी पानी में हूँ।”

एक वर्ष बाद भी मैं पानी में था। नदी आसान नहीं हुई थी और दूसरा किनारा साफ़ नहीं हुआ था।

लेकिन हमने लौकी बना ली थी।

जादू अभी प्रकट नहीं हुआ था। हम दूसरे किनारे तक भी नहीं पहुँचे थे। फिर भी कम से कम हमने आगे तैरना शुरू कर दिया था।

Setahun telah berlalu, dan saya masih berada di dalam air.

Sungainya tidak menjadi lebih mudah, dan seberang pun tidak terlihat lebih jelas. Namun, ada sesuatu yang berubah. Pada paruh kedua 2023, tak lama setelah meninggalkan SenseTime tempat saya bekerja hampir sepuluh tahun, sebagian besar waktu saya habiskan untuk bergulat dan mencari arah. Pada 2024, kami mulai menghabiskan sebagian besar waktu untuk membangun satu produk yang konkret.

Alur utama tahun itu adalah produk; beberapa upaya pendanaan yang terbatas menjadi alur sampingannya. Kami tidak memperoleh investasi dan tidak melihat sinyal pasar yang cukup kuat untuk membuktikan arah kami, tetapi kami mengembangkan dan merilis 27 versi.

Setelah melompat ke sungai berikutnya, akhirnya kami mulai belajar berenang maju.

Pertama, membuat sebuah labu

Dalam esai pada akhir tahun lalu, saya menulis bahwa pada akhirnya saya memutuskan untuk memulai dari catatan cerdas.

Sejak sekolah menengah, saya terbiasa tidak membaca tanpa menulis. Saat membaca buku atau artikel, atau menonton video, saya memperhatikan bagian yang menyentuh saya, menandainya, lalu mencatat gagasan yang muncul. Saya menyebut proses ini “mencari titik”: menyadari apa yang menggugah dan merekam inspirasi yang lahir darinya.

Kadang sebuah titik hanyalah satu kalimat, satu gambar, atau satu adegan. Saat itu, titik-titik tersebut mungkin tampak tidak berhubungan. Namun, setelah cukup banyak terkumpul, pada suatu saat semuanya tersambung dan membantu saya memahami masalah atau membentuk penilaian yang sebelumnya tidak terpikirkan.

Selama bertahun-tahun, saya mencoba berbagai alat catatan, tetapi tidak pernah menemukan produk yang benar-benar cocok dengan kebiasaan ini. Setelah meninggalkan SenseTime, saya mengajak teman masa kecil—orang yang dulu bersama saya mengusik sarang burung dan berkelahi—untuk membangunnya bersama. Pada paruh pertama 2024, kami menghabiskan sebagian besar waktu di ruang kerja bersama di Sohu Tower.

Kami menamai produk itu MagicGourd.

“Gourd”, labu, juga merupakan nama panggilan anak saya. Saat memilih nama itu, saya tidak secara sadar memberinya banyak makna. Jika dilihat kembali, mungkin ada harapan bawah sadar di dalamnya: semoga produk pertama yang saya bangun setelah menjadi pendiri purnawaktu dapat tumbuh perlahan di bawah perawatan kami, seperti seorang anak.

Tentu saja produk bukanlah anak. Namun, keduanya memiliki satu kesamaan: menghadirkannya ke dunia hanyalah permulaan. Pekerjaan panjang untuk merawat dan membantunya tumbuh adalah bagian yang benar-benar sulit.

Otak kedua yang sesungguhnya dalam bayangan kami masih jauh dari kenyataan dan tidak mungkin diselesaikan dalam satu langkah. Karena itu, kami memulai dari langkah paling dasar: memungkinkan orang menandai hal yang menggugah mereka dan menuliskan inspirasi saat menjelajah web, membaca PDF daring, atau menonton video.

Pertama, membuat labu yang dapat menampung titik-titik itu.

Keputusan produk di balik tombol sorotan

Tidak lama setelah mulai mengembangkan, kami berhadapan dengan pertanyaan yang tampak terlalu kecil untuk dianggap penting: seperti apa seharusnya tombol sorotan?

Haruskah hanya ada satu tombol, atau sebuah panel yang memuat beberapa tindakan? Setelah pengguna memilih teks, haruskah tombol itu langsung muncul atau menunggu dipanggil? Di mana ia harus muncul dan kapan harus menghilang? Jika seseorang tidak menyukai kemunculannya secara otomatis, haruskah kami menyediakan pengaturan untuk mematikannya?

Setiap pilihan tambahan tampak dapat memenuhi lebih banyak kebutuhan, tetapi juga menambah biaya untuk memahami dan menggunakan produk. Membuat tombol tampil lebih aktif memudahkan fungsi ditemukan, tetapi dapat terus mengganggu proses membaca. Membuatnya lebih tenang mungkin membantu pengguna berfokus, tetapi mereka bisa saja tidak pernah mengetahui bahwa fungsi tersebut ada.

Pertanyaan seperti ini tidak memiliki jawaban standar dalam pengertian algoritmis.

Saat membuat algoritme, kami biasa bertanya apakah suatu kemampuan dapat diterapkan, apakah akurasi dapat ditingkatkan, dan apakah performanya memenuhi syarat. Saat membuat produk, kami mulai mengajukan pertanyaan lain: kapan sebuah fungsi harus masuk, dan kapan ia harus mundur ke latar belakang?

Fungsi yang berjalan hanya membuktikan bahwa teknologinya bekerja. Apakah orang memahaminya, merasa terganggu olehnya, dan ingin mempertahankannya dalam kehidupan sehari-hari—itulah yang menentukan apakah produknya bekerja.

Ketika mengembangkan algoritme dan proyek besar, saya telah menangani banyak persoalan dunia nyata. Namun, saat kami menciptakan produk dari nol, keputusan yang sebelumnya ditanggung bersama oleh tim produk, desain, pelanggan, dan rekayasa tiba-tiba menjadi milik kami sendiri. Kami harus menentukan apa yang terlihat dan apa yang tetap tersembunyi; apa yang dibangun sekarang dan apa yang belum perlu dibuat, sekalipun mungkin berguna.

Pelan-pelan kami memahami bahwa produk tidak tersusun dari jumlah fungsinya, melainkan dari pilihan yang tak terhitung. Kadang, tidak muncul dan tidak mengganggu pun merupakan kemampuan produk.

Produk harus bertahan dalam waktu

Apakah sebuah tombol terasa alami adalah pengalaman yang dapat langsung dirasakan pengguna. Namun, banyak faktor yang menentukan apakah produk akan dipakai bertahun-tahun tersembunyi dari pandangan.

MagicGourd menyimpan riwayat bacaan, momen yang menggugah, dan pemikiran seseorang. Kami ingin melindungi privasi pengguna semaksimal mungkin sekaligus menyediakan sinkronisasi lintas perangkat dan, kelak, layanan cerdas. Untuk mencapai keduanya, kami memilih mengenkripsi data secara lokal dan hanya menyimpan teks terenkripsi di backend. Ini menambah kerumitan pengembangan dan pemeliharaan. Namun, jika seseorang tidak benar-benar memiliki datanya sendiri, otak kedua yang sesungguhnya mustahil terwujud sejak awal.

Sinkronisasi adalah masalah lain yang tampak sederhana, padahal sangat rumit. Ketika seseorang membuat sorotan, antarmuka harus segera merespons, bukan berhenti menunggu jaringan. Pencatatan tidak boleh terputus, bahkan dengan koneksi lemah atau tanpa koneksi sama sekali. Saat jaringan kembali, data dari perangkat yang berbeda harus tersinkron dengan benar, tanpa duplikasi, penimpaan, atau menghilang diam-diam.

Hal ini memaksa kami memikirkan ulang cara frontend dan backend bekerja sama, cara basis data menyusun informasi, cara pembaruan menjaga kompatibilitas, dan cara sistem pulih dari kesalahan. Pengguna biasanya tidak melihat keputusan ini. Namun, ketika salah satunya gagal, seluruh kerumitan yang tersembunyi seketika menjadi pengalaman pengguna yang paling langsung.

Pengalaman jangka pendek relatif mudah dibuat. Tidak terlalu sulit membuat demonstrasi mulus yang mengesankan seseorang selama beberapa menit. Namun, bagi kami, itu tetap hanya sebuah demo.

Demo hanya perlu bertahan di depan mata. Produk harus bertahan dalam waktu.

Jika suatu produk ingin menemani seseorang selama sepuluh tahun, fondasi pengalaman sepuluh tahun mendatang harus dibangun hari ini. Kegagalan pada alat biasa mungkin hanya menjadi ketidaknyamanan sementara. Pada produk yang menyimpan catatan bertahun-tahun, satu kali kehilangan data dapat menghancurkan seluruh kepercayaan yang telah dibangun pengguna.

Kami tidak dapat menjanjikan bahwa sistem tidak akan pernah mengalami masalah. Namun, “tidak kehilangan satu pun catatan pengguna” harus menjadi salah satu batasan desain terpenting kami. Pengalaman produk tidak hanya terjadi di layar; ia juga terjadi di dalam basis data yang tidak pernah dilihat pengguna.

Alur sampingan pendanaan yang sangat singkat

Bahkan menyebut pendanaan sebagai alur sampingan tahun itu mungkin berlebihan. Kami hanya berbicara dengan tiga firma investasi dan menghabiskan hampir seluruh waktu lainnya untuk mengembangkan produk.

Gagasan kami sederhana: mendekati investor tahap awal yang kami kenal secara langsung atau tidak langsung, menjelaskan apa yang sedang kami bangun, dan mencoba memperoleh investasi malaikat pertama.

Nilai investasi itu bukan hanya uang. Produk belum selesai dan belum ada sinyal pasar yang jelas. Pada tahap itu, kami menginginkan pandangan dari luar tentang apakah investor yang baik menganggap arah ini masuk akal.

Tidak satu pun upaya tersebut menghasilkan sesuatu. Saat itu, kami mengaitkannya dengan lingkungan pendanaan yang sulit bagi aplikasi AI dan kurangnya pengalaman kami berbicara dengan investor. Keduanya memang ada. Namun, jika dilihat kembali, ada fakta yang lebih langsung: kami hanya mencurahkan sedikit waktu untuk pendanaan dan berbicara dengan tiga firma. Daripada mengatakan bahwa kami gagal dalam satu putaran pendanaan, lebih tepat jika dikatakan bahwa kami melakukan beberapa percakapan awal dengan investor.

Hal yang lebih layak direnungkan adalah reaksi saya saat ditantang.

Dalam wawancara dengan MiraclePlus, orang-orang di hadapan saya adalah mereka yang sangat saya hormati. Ketika mereka berulang kali menantang gagasan kami dan mengajukan pertanyaan dengan tajam, saya mengalami ketegangan: kami datang untuk mencari investasi, jadi terasa seolah saya harus menghormati penilaian mereka dan, sampai batas tertentu, bergerak mendekati jawaban yang mereka harapkan.

Namun, jika tujuan pendanaan adalah mendapat umpan balik yang jujur, mengatakan sesuatu yang tidak benar-benar kami yakini akan membuat umpan balik itu kehilangan arti.

Belakangan saya mulai bertanya apakah umpan balik benar-benar satu-satunya yang kami inginkan. Mungkin, sebelum produk divalidasi pasar, kami juga menginginkan pengakuan dari sekelompok investor unggul agar yakin bahwa kami tidak memilih arah yang salah.

Rasanya seperti berdiri di sungai yang asing dan berharap seseorang di tepi sungai lebih dulu memberi tahu ke mana kami harus berenang. Namun, seorang pendiri pada akhirnya harus merasakan arus sendiri dan menilai berdasarkan fakta di hadapannya.

“Tetua Xuanming” di Dongsheng Tower

Pada paruh kedua 2024, kami pindah dari Sohu Tower ke Dongsheng Tower.

Saya dan teman masa kecil saya melakukan pemrograman berpasangan untuk waktu yang lama, sering duduk di depan layar yang sama sambil berdiskusi. Di antara para pendiri muda di ruang kerja bersama, cara kerja ini cukup mencolok. Lama-kelamaan orang memberi kami julukan: “Tetua Xuanming”.

Rasanya lucu. Dua orang yang saat kecil bersama-sama mengusik sarang burung dan berkelahi, dua puluh tahun kemudian duduk di kantor bersama membangun produk bernama MagicGourd.

Di Dongsheng Tower pula kami bertemu Kehan. Di MiraclePlus, ia bertanggung jawab atas komunitas dan perekrutan proyek rintisan. Saat pertama kali berbicara kepada kami, ia bertanya, “Kalian berdua pendiri, kan? Saya sudah lama memperhatikan kalian. Di seluruh kantor ini, kalian berdualah yang paling terlihat benar-benar berada dalam mode pendiri.”

Belakangan, ketika mengetahui bahwa kami pernah mengikuti wawancara MiraclePlus, ia membicarakan pengalaman itu bersama kami. Ia menjelaskan bahwa ketika investor berulang kali mempertanyakan sebuah gagasan rintisan, mereka tidak selalu hanya menyatakan ketidaksetujuan. Mereka mungkin juga sedang menguji apakah para pendiri benar-benar sudah memikirkannya dan mampu mempertahankan penilaian sendiri di bawah tekanan.

Hal itu membuat saya menafsirkan ulang wawancara tersebut.

Menghormati investor bukan berarti menyerahkan penilaian kita kepada mereka. Seorang pendiri harus memahami mengapa orang lain tidak setuju, tanpa meninggalkan penilaian sendiri hanya karena orang-orang itu layak dihormati. Yang harus dihindari bukanlah mengubah pikiran karena fakta baru, melainkan mengubah ucapan semata-mata demi mendapat pengakuan sebelum persoalannya dipikirkan dengan matang.

Pelajaran ini tidak terbatas pada pendanaan. Saat membuat produk, setiap hari kami menghadapi umpan balik pengguna, pilihan produk pesaing, dan tren teknologi baru. Semua sinyal luar ini perlu dipahami dengan sungguh-sungguh, tetapi keputusan tentang apa yang masuk ke produk tetap menjadi tanggung jawab kami.

Labunya sudah ada

Pada akhir 2024, kami telah mengembangkan dan merilis 27 versi MagicGourd.

Kami memulai dengan anotasi teks dan gambar pada halaman web biasa, lalu menambahkan dukungan untuk PDF daring dan memperluas metode yang sama ke Bilibili dan YouTube. Pengguna dapat menandai bingkai video yang menggugah mereka, menulis catatan, dan segera kembali ke momen itu melalui linimasa. Kami juga menambahkan pengelolaan tag, pencarian, dan ekspor, serta menyinkronkan data di berbagai peramban dan perangkat.

Setiap format konten baru membutuhkan banyak penyesuaian. Halaman web tidak memiliki struktur yang seragam dan platform video terus berubah. Fungsi yang berjalan baik di satu situs dapat berperilaku sangat berbeda di halaman atau peramban lain. Banyak waktu kami tidak menghasilkan kemampuan baru yang mencolok; waktu itu dipakai untuk menangani kasus tepi agar kemampuan yang sudah ada bekerja lebih stabil.

Dalam 27 versi yang dirilis sepanjang tahun, kami tidak menemukan kasus data pengguna hilang atau rusak. Kegagalan sesekali terutama terjadi pada tahap layanan seperti kode verifikasi login. Ketika menerima laporan, kami biasanya dapat menemukan dan menyelesaikan masalah dengan cepat. Ini tidak membuktikan bahwa sistem tidak akan pernah gagal, tetapi menunjukkan bahwa waktu yang kami habiskan untuk hal-hal yang tidak terlihat pengguna tidak sia-sia.

Pada November, kami memperkenalkan fitur catatan video di sspai. Pengguna mulai meninggalkan tanggapan. Seseorang yang sebelumnya menyimpan bingkai video berguna dengan mengambil tangkapan layar dan menempelkannya di tempat lain menulis setelah mencoba MagicGourd: “Ekstensi ini menyelamatkan saya!” Pengguna lain menyukai penanda berbentuk tetesan di linimasa, meminta catatan mandiri, atau berharap dukungan Safari segera hadir.

Menerima tanggapan pengguna menjadi salah satu kegembiraan terbesar tahun itu.

Yang membuat kami senang bukan hanya pujian terhadap produk, tetapi fakta bahwa seseorang telah memasukkan sesuatu yang kami buat ke dalam kehidupan nyata mereka. Pengguna juga memberi saran berguna yang mendorong kami terus memutuskan: tanggapan mana yang menunjukkan masalah bersama dan mana yang berasal dari kebiasaan pribadi; apa yang harus segera diselesaikan dan apa yang, meskipun berguna, belum seharusnya masuk ke produk pada tahap ini.

Jika nama produk dibagi menjadi dua, pada akhir tahun setidaknya kami telah membangun “labu”: wadah untuk mengumpulkan, menyimpan, dan mengelola momen yang menggugah serta inspirasi.

Keajaibannya belum muncul

Namun, itu belum menjadi keajaiban yang kami bayangkan.

Ia tentu akan menggunakan AI, tetapi bukan sekadar menghasilkan ringkasan sebuah artikel. Ringkasan dapat memadatkan informasi tanpa memajukan kognisi.

Menurut pemahaman kami, informasi adalah isi yang diterima seseorang; pengetahuan adalah informasi yang telah dipahami dan diatur; kognisi adalah cara seseorang memahami dunia, membentuk hubungan dan penilaian, lalu mengubahnya ketika pengalaman baru datang.

AI saat ini pandai memproses informasi dan semakin baik mengatur pengetahuan. Ia dapat merangkum artikel, mengambil kata kunci, dan menjawab pertanyaan yang jawabannya sudah ada di dalam materi. Namun, jika hanya memadatkan sepuluh halaman menjadi satu atau menambahkan kotak percakapan di samping aplikasi catatan, ia belum menyentuh apa yang benar-benar ingin kami bangun.

Kami ingin MagicGourd di masa depan memahami catatan yang dikumpulkan seseorang selama bertahun-tahun dan mempertemukan kembali momen-momen yang menggugah, yang tersebar di berbagai waktu dan media. Ia mungkin menemukan tema berulang yang tidak pernah dinyatakan secara eksplisit, menunjukkan hubungan dan pertentangan antarcatatan, menemukan pertanyaan yang lama tidak terjawab, atau mengembalikan pemikiran lama pada waktu yang tepat.

Yang lebih penting, ia harus mengajukan pertanyaan yang belum terpikirkan pengguna tetapi layak dikejar, sehingga membantu mereka membentuk penilaian baru sendiri.

Harus ada batas yang jelas: AI tidak boleh membungkus dugaannya sebagai “kebenaran” yang belum disadari pengguna. Ia dapat mengusulkan kemungkinan hubungan, pertentangan, dan pertanyaan. Apakah hubungan itu valid tetap harus diputuskan oleh pengguna.

Keajaiban tidak berpikir menggantikan pengguna. Ia membantu pengguna melihat pemikiran yang belum mereka selesaikan.

Sepanjang tahun, kami membuat beberapa demo internal terkait gagasan ini. Demo itu dapat menghasilkan ringkasan, mengatur isi, dan menjawab pertanyaan. Semuanya sudah tampak seperti produk AI. Namun, jaraknya masih jauh dari apa yang kami sebut “memajukan kognisi”, sehingga kami tidak buru-buru merilisnya hanya untuk mengikuti gelombang AI.

Semakin dalam AI ikut serta dalam proses kognitif seseorang, semakin pribadi data yang perlu diaksesnya. Hal ini semakin meyakinkan kami bahwa privasi dan kepemilikan data bukan persoalan rekayasa yang terpisah dari keajaiban, melainkan prasyarat agar keajaiban dapat hadir. Kami tidak dapat mengaku ingin memahami pengguna sambil meminta mereka melepaskan kendali atas data sendiri.

Maka, pada 31 Desember 2024, labunya sudah ada, tetapi keajaibannya belum muncul.

Kami belum mendapat investasi, belum melihat sinyal pasar yang menentukan, dan belum membangun model bisnis yang jelas. Kami masih belum tahu ke mana sungai ini pada akhirnya akan mengalir.

Namun, kami telah merilis 27 versi. Pengguna mulai membawa produk ke dalam kehidupan mereka. Kami pun mulai memahami cara mengubah demo yang berjalan menjadi produk sungguhan dan memikul tanggung jawab jangka panjang atasnya.

Setahun sebelumnya saya menulis: “Saya masih berada di dalam air.”

Setahun kemudian saya masih berada di dalam air. Sungainya tidak menjadi lebih mudah dan seberang tidak menjadi lebih jelas.

Namun, kami telah membuat labunya.

Keajaibannya belum muncul. Kami juga belum mencapai seberang. Namun, setidaknya kami telah mulai berenang maju.

È passato un anno e sono ancora in acqua.

Il fiume non è diventato più facile, né l’altra riva più nitida. Eppure, rispetto a un anno fa, qualcosa è cambiato. Nella seconda metà del 2023, dopo aver lasciato SenseTime, dove avevo lavorato per quasi dieci anni, ho trascorso gran parte del tempo dibattendomi e cercando una direzione. Nel 2024 abbiamo cominciato a dedicare la maggior parte del nostro tempo allo sviluppo di un prodotto concreto.

Il filo principale dell’anno è stato il prodotto; quello secondario, alcuni tentativi di raccolta fondi molto limitati. Non abbiamo ricevuto investimenti, né visto un segnale di mercato abbastanza forte da confermare la direzione, ma abbiamo sviluppato e pubblicato 27 versioni.

Dopo esserci tuffati nel fiume successivo, finalmente abbiamo iniziato a imparare a nuotare in avanti.

Prima, costruire una zucca

Nell’articolo scritto alla fine dell’anno scorso raccontavo di avere infine deciso di partire dalle note intelligenti.

Fin dalle scuole medie ho l’abitudine di non leggere senza prendere appunti. Quando leggo un libro o un articolo, oppure guardo un video, presto attenzione ai passaggi che mi colpiscono, li segno e annoto i pensieri che fanno nascere in quel momento. Chiamo questo processo “trovare punti”: accorgersi di ciò che ci tocca e registrare l’ispirazione.

A volte questi punti sono soltanto una frase, un’immagine o un’inquadratura. Sul momento sembrano non avere alcun rapporto tra loro. Ma, quando se ne accumulano abbastanza, prima o poi si collegano, aiutandomi a capire un problema o a formulare un giudizio a cui non avevo mai pensato.

Per molti anni ho provato diversi strumenti per prendere appunti, senza mai trovare un prodotto davvero adatto a questa abitudine. Dopo aver lasciato SenseTime, ho cercato l’amico d’infanzia con cui un tempo andavo a stanare nidi e facevo a botte, e abbiamo deciso di realizzarlo insieme. Nella prima metà del 2024 abbiamo lavorato per lo più in uno spazio di coworking nella Sohu Tower.

Abbiamo chiamato il prodotto MagicGourd.

“Gourd” è anche il soprannome di mio figlio. Quando abbiamo scelto il nome, non gli ho attribuito intenzionalmente troppi significati. Guardandomi indietro, però, forse nascondeva un’aspettativa inconscia: speravo che il primo prodotto creato dopo essermi dedicato a tempo pieno all’impresa potesse crescere lentamente sotto le nostre cure, proprio come un bambino.

Naturalmente un prodotto non è un bambino. Ma hanno qualcosa in comune: essere creati è soltanto l’inizio; la lunga cura e la crescita che seguono sono la parte davvero difficile.

Il vero secondo cervello che immaginavamo era ancora molto lontano dalla realtà e non poteva essere realizzato in un solo passo. Così abbiamo deciso di partire da quello più essenziale: permettere alle persone di segnare ciò che le colpisce e annotare un’ispirazione mentre navigano sul web, leggono un PDF online o guardano un video.

Prima di tutto, costruire una zucca capace di raccogliere questi punti.

Le scelte di prodotto dietro un pulsante di evidenziazione

Appena iniziato lo sviluppo, ci siamo imbattuti in una domanda apparentemente minuscola: che aspetto dovrebbe avere il pulsante di evidenziazione?

Dovrebbe essere un solo pulsante o un pannello con diverse azioni? Dopo che una persona seleziona del testo, dovrebbe apparire subito o aspettare di essere richiamato? Dove dovrebbe comparire, e quando dovrebbe scomparire? Se qualcuno non vuole che appaia automaticamente, dovremmo offrirgli anche un interruttore per disattivarlo?

Ogni opzione in più sembra soddisfare più esigenze, ma aumenta anche il costo di comprensione e di utilizzo. Far apparire il pulsante in modo più attivo rende la funzione più facile da scoprire, ma può interrompere continuamente la lettura. Tenerlo più discreto può aiutare a concentrarsi, ma una persona potrebbe non accorgersi mai che la funzione esiste.

Domande simili non hanno una risposta standard in senso algoritmico.

Quando lavoriamo sugli algoritmi, siamo abituati a chiederci se una capacità sia realizzabile, se la precisione possa migliorare, se le prestazioni soddisfino i requisiti. Dopo aver iniziato a costruire un prodotto, abbiamo cominciato a chiederci ripetutamente: quando dovrebbe intervenire una funzione, e quando dovrebbe ritirarsi sullo sfondo?

Il fatto che una funzione sia eseguibile dimostra soltanto che la tecnologia funziona. Che le persone la capiscano, si sentano disturbate oppure no e vogliano mantenerla nella propria vita quotidiana è ciò che determina se il prodotto funziona davvero.

Quando lavoravo su algoritmi e grandi progetti avevo già affrontato molti problemi del mondo reale. Ma, creando davvero un prodotto da zero, le decisioni che prima erano condivise tra gruppi di prodotto, design, clienti e ingegneria sono improvvisamente ricadute tutte su di noi. Dovevamo decidere che cosa mostrare e che cosa nascondere; che cosa realizzare subito e che cosa, pur utile, rimandare.

Poco a poco abbiamo capito che un prodotto non è fatto dal numero delle sue funzioni, ma da innumerevoli scelte. A volte anche “non apparire” e “non disturbare” sono capacità del prodotto.

Un prodotto deve reggere nel tempo

Che un pulsante sia comodo è un’esperienza immediatamente percepibile. Ma molti dei fattori che decidono se un prodotto verrà usato a lungo rimangono nascosti agli utenti.

MagicGourd conserva la cronologia di lettura, i momenti di risonanza e i pensieri di una persona. Vogliamo proteggere il più possibile la privacy degli utenti e, al tempo stesso, offrire la sincronizzazione tra dispositivi e futuri servizi intelligenti. Per fare entrambe le cose, abbiamo scelto di cifrare i dati in locale e di conservare sul backend soltanto il testo cifrato. Questo aumenta la complessità dello sviluppo e della manutenzione, ma se le persone non possono possedere davvero i propri dati, un vero secondo cervello è impossibile fin dall’inizio.

La sincronizzazione è un altro problema che sembra semplice e in realtà è molto complesso. Quando una persona crea un’evidenziazione, l’interfaccia dovrebbe rispondere immediatamente, senza fermarsi ad aspettare a causa di una connessione scadente. La registrazione non dovrebbe interrompersi nemmeno con una rete debole o assente; quando la connessione torna, i dati sui diversi dispositivi devono sincronizzarsi correttamente, senza duplicarsi, sovrascriversi a vicenda o, peggio, scomparire in silenzio.

Questo ci ha costretto a ripensare come frontend e backend dovessero collaborare, come organizzare i dati nel database, come mantenere la compatibilità durante gli aggiornamenti e come recuperare in caso di anomalie. Di solito le persone non vedono queste scelte, ma basta che un solo anello fallisca perché tutta quella complessità si trasformi all’istante nella parte più diretta dell’esperienza utente.

L’esperienza a breve termine è relativamente facile da ottenere. Non è così difficile creare una dimostrazione fluida che sorprenda per qualche minuto. Ma, ai nostri occhi, rimane soltanto una demo.

Una demo deve reggere soltanto nel momento presente; un prodotto deve reggere nel tempo.

Se un prodotto intende accompagnare una persona per dieci anni, le fondamenta dell’esperienza che avrà tra dieci anni devono essere costruite già oggi. In uno strumento comune, un guasto può essere soltanto un disagio temporaneo; in un prodotto che custodisce anni di appunti, una sola perdita di dati può distruggere tutta la fiducia costruita dall’utente.

Non possiamo promettere che il sistema non avrà mai problemi, ma dobbiamo trattare “non perdere nemmeno una nota dell’utente” come uno dei vincoli progettuali più importanti. L’esperienza di prodotto non avviene soltanto sullo schermo, ma anche nel database invisibile agli utenti.

Un brevissimo filo secondario: la raccolta fondi

Definire la raccolta fondi un filo secondario dell’anno è forse già un’esagerazione. In tutto abbiamo parlato soltanto con tre società d’investimento; per il resto, abbiamo continuato a dedicare la maggior parte del tempo allo sviluppo del prodotto.

La nostra idea era semplice: rivolgerci ad alcuni investitori early-stage che conoscevamo direttamente o indirettamente, presentare ciò che stavamo costruendo e cercare di ottenere il primo investimento angel.

Per noi il significato di quell’investimento non stava soltanto nel denaro. Il prodotto non era ancora finito e mancava un chiaro segnale di mercato; in quella fase volevamo prima ricevere un riscontro esterno, per capire se la direzione avesse senso agli occhi di investitori eccellenti.

Nessuno di questi tentativi ha portato a un risultato. All’epoca attribuivamo la cosa a un contesto poco favorevole per finanziare applicazioni di AI e alla nostra scarsa esperienza nel parlare con gli investitori. Entrambi i fattori esistevano. Ma, guardando indietro, c’è un fatto ancora più diretto: abbiamo investito pochissimo tempo nella raccolta fondi e parlato soltanto con tre società. Più che dire di avere attraversato un round fallito, sarebbe corretto dire che abbiamo avuto alcuni colloqui preliminari con degli investitori.

Ciò su cui vale maggiormente la pena riflettere è il modo in cui reagivo alle contestazioni.

Al colloquio con MiraclePlus, davanti a me sedevano persone che rispettavo profondamente. Quando mettevano ripetutamente in discussione le nostre idee, a volte con domande molto taglienti, provavo sentimenti contrastanti: dato che eravamo lì per cercare un investimento, mi sembrava di dover rispettare il loro giudizio e, fino a un certo punto, avvicinarmi alle risposte che si aspettavano.

Ma, se attraverso la raccolta fondi volevamo ottenere un riscontro autentico, compiacerli dicendo cose in cui non credevamo avrebbe reso quel riscontro privo di significato.

In seguito ho anche cominciato a chiedermi se desiderassimo davvero soltanto un riscontro. Forse, prima che il mercato convalidasse il prodotto, volevamo anche l’approvazione di un gruppo di ottimi investitori, per rassicurarci di non avere scelto la direzione sbagliata.

Era come trovarsi in un fiume sconosciuto e sperare che qualcuno sulla riva ci dicesse prima dove nuotare. Ma un fondatore, alla fine, deve sentire la corrente in prima persona e giudicare sulla base dei fatti che ha davanti.

I “due anziani Xuanming” della Dongsheng Tower

Nella seconda metà del 2024 ci siamo trasferiti dalla Sohu Tower alla Dongsheng Tower.

Il mio amico d’infanzia e io programmavamo spesso in coppia per lunghi periodi, seduti insieme a discutere davanti allo stesso schermo. In mezzo ai giovani fondatori dello spazio di coworking, il nostro modo di lavorare saltava all’occhio. Con il tempo ci hanno dato un soprannome: i “due anziani Xuanming”.

Era una cosa molto divertente. Due persone che da bambini andavano insieme a stanare nidi e facevano a botte, vent’anni dopo sedevano di nuovo in un ufficio condiviso per costruire un prodotto chiamato MagicGourd.

È stato proprio alla Dongsheng Tower che abbiamo conosciuto Kehan. Allora si occupava della community e del reclutamento di progetti imprenditoriali per MiraclePlus. La prima volta che ci parlò, chiese: «Voi siete fondatori, vero? Vi osservo da molto tempo. In tutto questo ufficio, voi due siete quelli che più di tutti hanno lo stato d’animo dell’imprenditore».

In seguito seppe che avevamo partecipato al colloquio con MiraclePlus e parlammo di ciò che era accaduto. Ci spiegò che, quando gli investitori contestano ripetutamente un’idea imprenditoriale, a volte non stanno soltanto manifestando disaccordo: stanno anche verificando se i fondatori abbiano davvero riflettuto a fondo e sappiano mantenere il proprio giudizio sotto pressione.

Questo mi fece reinterpretare quel colloquio.

Rispettare gli investitori non significa cedere loro il proprio giudizio. Un fondatore deve capire perché gli altri non sono d’accordo, ma non può rinunciare al proprio giudizio solo perché li rispetta. Ciò che va davvero evitato non è cambiare opinione in base a fatti nuovi, ma cambiare ciò che si dice soltanto per ottenere approvazione prima di aver riflettuto fino in fondo.

Non è una lezione che riguarda soltanto la raccolta fondi. Costruendo un prodotto, ogni giorno incontriamo i riscontri degli utenti, le scelte dei prodotti concorrenti e nuove tendenze tecnologiche. Tutti questi segnali esterni meritano di essere compresi con attenzione, ma decidere che cosa debba entrare nel prodotto resta una nostra responsabilità.

La zucca c’è

Alla fine del 2024 avevamo sviluppato e pubblicato 27 versioni di MagicGourd.

Siamo partiti dalle annotazioni di testo e immagini sulle normali pagine web, poi abbiamo aggiunto il supporto ai PDF online ed esteso lo stesso metodo a Bilibili e YouTube. Le persone potevano segnare in un video un fotogramma che le aveva colpite, aggiungere una nota e tornare rapidamente a quei momenti sulla timeline. Abbiamo anche aggiunto gradualmente la gestione dei tag, la ricerca e l’esportazione, oltre alla sincronizzazione dei dati tra browser e dispositivi diversi.

Ogni nuovo formato di contenuto richiedeva moltissimo lavoro di adattamento. Le pagine web non hanno una struttura uniforme e le piattaforme video cambiano continuamente. Una funzione che opera correttamente su un sito può comportarsi in modo completamente diverso su un’altra pagina o in un altro browser. Molto del nostro tempo non è servito a creare una nuova capacità appariscente, ma a gestire casi limite di ogni genere affinché quelle esistenti funzionassero in modo più stabile.

Nelle 27 versioni pubblicate durante l’anno non abbiamo rilevato casi di perdita o danneggiamento dei dati degli utenti. I problemi occasionali si sono concentrati soprattutto in passaggi del servizio come i codici di verifica per l’accesso; dopo una segnalazione, nella maggior parte dei casi siamo riusciti a individuarli e risolverli rapidamente. Questo non dimostra che il sistema non sbaglierà mai più, ma indica almeno che il tempo investito in ciò che non si vede non è andato sprecato.

A novembre abbiamo presentato su sspai la funzione per prendere appunti sui video. Dopo la pubblicazione dell’articolo, gli utenti hanno iniziato a lasciare commenti. Una persona, che prima poteva salvare un fotogramma utile soltanto facendo uno screenshot e incollandolo altrove, dopo avere provato MagicGourd ha scritto: «Questo plugin mi ha salvato!» Altri hanno apprezzato i marcatori a goccia sulla timeline del video, chiesto note indipendenti o auspicato un rapido supporto per Safari.

Ricevere i riscontri degli utenti è stata una delle cose più felici dell’anno.

A renderci davvero felici non erano soltanto gli elogi, ma il fatto che finalmente qualcuno avesse inserito ciò che avevamo costruito nella propria vita reale. Gli utenti offrivano anche molti suggerimenti utili, spingendoci a continuare a valutare: quali osservazioni indicavano un problema comune e quali derivavano da un’abitudine individuale; che cosa andava risolto subito e che cosa, pur utile, non era adatto al prodotto in quella fase.

Dividendo in due il nome del prodotto, alla fine dell’anno avevamo realizzato almeno la “zucca”: un contenitore capace di raccogliere, conservare e gestire momenti di risonanza e ispirazioni.

La magia non si è ancora manifestata

Ma non era ancora la magia che avevamo in mente.

Avrebbe certamente usato l’AI, ma non si sarebbe limitata a generare il riassunto di un articolo. Un riassunto può comprimere l’informazione senza necessariamente far avanzare la cognizione.

Secondo la nostra interpretazione, l’informazione è il contenuto che una persona riceve; la conoscenza è informazione compresa e organizzata; la cognizione è il modo in cui una persona comprende il mondo, crea connessioni, formula giudizi e li corregge con l’arrivo di nuove esperienze.

Oggi l’AI è molto brava a elaborare informazioni e sempre più capace di organizzare la conoscenza. Può riassumere un articolo, estrarre parole chiave e rispondere alle domande già contenute nel materiale. Ma, se si limita a comprimere dieci pagine in una o ad aggiungere una finestra di chat accanto a un’app per appunti, non ha ancora toccato ciò che vogliamo davvero costruire.

Vorremmo che in futuro MagicGourd fosse capace di comprendere le annotazioni accumulate da una persona nel tempo, facendo incontrare nuovamente momenti di risonanza dispersi tra periodi e media differenti. Potrebbe scoprire temi ricorrenti mai espressi in modo esplicito, mostrare collegamenti e contraddizioni tra gli appunti, individuare domande rimaste a lungo senza risposta o riportare alla luce un pensiero passato al momento opportuno.

Soprattutto, dovrebbe sollevare domande a cui l’utente non ha ancora pensato ma che vale la pena approfondire, aiutandolo a formulare nuovi giudizi propri.

Qui deve esserci un confine chiaro: l’AI non può confezionare le proprie congetture come “verità” di cui l’utente non si è ancora accorto. Può proporre possibili collegamenti, contraddizioni e domande; spetta comunque all’utente stabilire se quei collegamenti reggano davvero.

La magia non consiste nel pensare al posto dell’utente, ma nell’aiutarlo a vedere il pensiero che non ha ancora portato a termine.

Durante l’anno abbiamo realizzato internamente alcune demo legate a questa idea. Potevano generare riassunti, organizzare contenuti e rispondere a domande; sembravano già avere qualcosa dell’AI. Ma erano ancora molto lontane da ciò che intendiamo per “far avanzare la cognizione”, quindi non le abbiamo pubblicate in fretta soltanto per inseguire l’ondata dell’AI.

Quanto più profondamente l’AI partecipa al processo cognitivo di una persona, tanto più privati diventano i dati a cui deve accedere. Questo ci ha resi ancora più convinti che privacy e proprietà dei dati non siano problemi ingegneristici separati dalla magia, ma i presupposti perché la magia possa esistere. Non possiamo affermare di voler comprendere gli utenti mentre chiediamo loro di rinunciare al controllo dei propri dati.

Così, il 31 dicembre 2024, la zucca c’era, ma la magia non si era ancora manifestata.

Non avevamo ottenuto investimenti, né un segnale di mercato decisivo, né stabilito un modello di business chiaro. Non sapevamo ancora dove avrebbe portato quel fiume.

Ma avevamo pubblicato 27 versioni, alcuni utenti avevano cominciato a portare il prodotto nella propria vita e noi avevamo iniziato a capire come trasformare una demo funzionante in un vero prodotto, assumendocene la responsabilità nel lungo periodo.

Un anno prima avevo scritto: «Sono ancora in acqua».

Un anno dopo ero ancora in acqua. Il fiume non era diventato più facile, né l’altra riva più nitida.

Ma avevamo costruito la zucca.

La magia non si era ancora manifestata. Non avevamo nemmeno raggiunto l’altra riva, ma almeno avevamo iniziato a nuotare in avanti.

一年が過ぎた。私はいまも水の中にいる。

川が簡単になったわけでも、対岸がはっきり見えるようになったわけでもない。ただ、一年前とは少し違う。2023年後半、約10年勤めたSenseTimeを離れたばかりの私は、ほとんどの時間をもがきながら方向を探すことに費やした。2024年になると、私たちは大半の時間を具体的なプロダクトの開発に使い始めた。

この年の本筋はプロダクトで、数回のごく限られた資金調達の試みが脇筋だった。投資は得られず、方向性を証明するほど強い市場のシグナルもなかった。それでも、私たちは27のバージョンを開発し、公開した。

次の川へ飛び込んだあと、ようやく前へ泳ぐことを学び始めた。

まず、ひょうたんを作る

昨年末の文章で、私は最終的にインテリジェントノートから始めると決めたことを書いた。

中学生の頃から、私は「書かずに読まない」習慣を持っている。本や記事を読んだり、動画を見たりするとき、心が動いた箇所に注意を向け、印をつけ、そのとき生まれた考えを記録する。私はこの過程を「点を探す」と呼んでいる。心が動いたことに気づき、そこから生まれた着想を書き留めるという意味だ。

その点は、一文、一枚の画像、あるいは一つの場面にすぎないこともある。その時点では互いに無関係に見える。しかし十分に蓄積すると、ある瞬間にそれらが結びつき、問題を理解したり、それまで思いつかなかった判断を形づくったりする助けになる。

長年さまざまなノートツールを試したが、この習慣に本当に合うものは見つからなかった。SenseTimeを離れたあと、子どもの頃に一緒に鳥の巣を探り、けんかもした幼なじみに声をかけ、二人で作ることにした。2024年前半、私たちはほとんどの時間を搜狐大厦（Sohu Tower）のコワーキングスペースで過ごした。

プロダクトには「MagicGourd」という名前をつけた。

「ひょうたん」は、私の子どもの愛称でもある。この名前を選んだとき、意識して多くの意味を込めたわけではなかった。振り返ると、そこには無意識の願いがあったのかもしれない。フルタイムで起業してから初めて作るプロダクトが、子どものように、私たちの世話のもとで少しずつ育ってほしいという願いだ。

もちろん、プロダクトは子どもではない。ただ、共通するところが一つある。生み出すことは始まりにすぎず、その後長く世話をし、育てていくことこそが本当に難しい。

私たちが思い描く真の第二の脳は、まだ現実から遠く、一歩で完成させられるものではなかった。そこで、まず最も基本的な一歩から始めることにした。ウェブを閲覧するとき、オンラインPDFを読むとき、動画を見るときに、心が動いた箇所をすぐに印づけ、着想を書き留められるようにすることだ。

まず、そうした点を集めるひょうたんを作る。

一つのハイライトボタンの背後にあるプロダクト判断

開発を始めてすぐ、あまりに小さく見える問題にぶつかった。ハイライトボタンはどんな形であるべきか。

一つのボタンにするのか、複数の操作を含むパネルにするのか。テキストを選択したらすぐに表示するのか、それともユーザーが呼び出すまで待つのか。どこに表示し、いつ消すのか。自動表示を嫌う人のために、無効にする設定も用意するべきか。

選択肢を増やせば、より多くの要望に応えられるように見える。しかし同時に、理解と操作の負担も増える。ボタンを積極的に表示すれば機能は見つけやすくなるが、読書を何度も中断させるかもしれない。静かにしておけば集中しやすいが、機能の存在そのものに気づかれないかもしれない。

こうした問いに、アルゴリズムのような標準解はない。

アルゴリズムを作るとき、私たちは能力を実現できるか、精度を上げられるか、性能が要件を満たすかを問う。プロダクトを作るようになってからは、別の問いを繰り返すようになった。機能はいつ介入し、いつ舞台裏へ下がるべきか。

機能が動くことは、技術が成立していることを示すにすぎない。ユーザーが理解できるか、邪魔だと感じないか、日常の中に残したいと思うかが、プロダクトとして成立するかを決める。

アルゴリズムや大規模プロジェクトを手がけていた頃にも、現実世界の問題を数多く扱ってきた。だがゼロからプロダクトを作ると、それまでプロダクト、デザイン、顧客、エンジニアリングの各チームが分担していた判断が、突然すべて私たちにのしかかった。何を見せ、何を裏に隠すのか。何を今作り、役に立つとしても何をまだ作らないのか。自分たちで決めなければならなかった。

プロダクトは機能の数でできているのではなく、無数の選択でできているのだと、少しずつ分かった。ときには「現れないこと」と「邪魔をしないこと」も、プロダクトの能力である。

プロダクトは時間の中で成立しなければならない

ボタンが使いやすいかどうかは、ユーザーがその場で感じられる体験だ。しかし、長年使われるかどうかを決める多くの要因は、見えない場所に隠れている。

MagicGourdが保存するのは、一人の人間の読書履歴、心が動いた瞬間、そして考えだ。私たちはユーザーのプライバシーをできる限り守りながら、端末間同期と将来のインテリジェントサービスも提供したかった。その両方を実現するため、データをローカルで暗号化し、バックエンドには暗号文だけを保存する方式を選んだ。開発と保守は複雑になったが、自分のデータを本当に所有できなければ、真の第二の脳は最初から成り立たない。

同期も、簡単に見えて実際には複雑な問題だ。ユーザーがハイライトを作成したら、ネットワークを待って止まるのではなく、画面はすぐに反応すべきだ。接続が弱いときも、オフラインのときも、記録は中断してはならない。接続が戻ったら、複数端末のデータは重複したり上書きされたり、黙って消えたりすることなく、正しく同期されなければならない。

そのために、フロントエンドとバックエンドの連携、データベースの構造、バージョン更新時の互換性、異常からの復旧を考え直す必要があった。ユーザーには通常、こうした設計は見えない。しかし一つでも失敗すれば、隠れていた複雑さが一瞬で最も直接的なユーザー体験になる。

短期的な体験は比較的作りやすい。数分間人を驚かせる滑らかなデモを作ることは、さほど難しくない。しかし私たちにとって、それはまだデモにすぎない。

デモは目の前で成立すればよい。プロダクトは時間の中で成立しなければならない。

十年間ユーザーに寄り添うつもりなら、十年後の体験を支える土台を今日から築かなければならない。普通のツールなら、一度の障害は一時的な不便で済むかもしれない。何年分ものノートを預かるプロダクトでは、一度のデータ消失が、それまで築いた信頼をすべて壊しかねない。

システムに問題が絶対に起きないとは約束できない。それでも「ユーザーのノートを一件も失わない」ことは、最も重要な設計制約の一つでなければならない。プロダクト体験は画面の上だけでなく、ユーザーには見えないデータベースの中にも存在する。

ごく短い資金調達の脇道

資金調達をこの年の脇筋と呼ぶことさえ、大げさかもしれない。話をした投資機関は三社だけで、それ以外のほとんどの時間はプロダクト開発に使った。

考えは単純だった。直接または間接に知っている初期投資家に、私たちが作っているものを説明し、最初のエンジェル投資を得ようとした。

投資の意味はお金だけではなかった。プロダクトは未完成で、明確な市場シグナルもなかった。その段階で、優れた投資家から見てこの方向に意味があるか、外部の意見を得たかった。

いずれの試みも結果にはつながらなかった。当時は、AIアプリケーションをめぐる資金調達環境が良くないことと、投資家との話し方に慣れていないことを理由にしていた。どちらも事実だった。だが振り返れば、もっと直接的な事実がある。資金調達に使った時間は少なく、話した相手も三社だけだった。資金調達ラウンドに失敗したというより、投資機関と数回の予備的な対話をしただけ、と言うほうが正確だ。

もっと考えるべきなのは、疑問をぶつけられたときの自分の反応だった。

MiraclePlusの面接で、私の向かいに座っていたのは、私が深く尊敬する人たちだった。彼らが何度も私たちの考えを問い、厳しい言葉で質問すると、私は複雑な気持ちになった。投資を求めて来た以上、彼らの判断を尊重し、ある程度は彼らが期待する答えに近づくべきではないか、と。

しかし、資金調達を通して率直なフィードバックを得たいのなら、自分が信じていないことを口にした時点で、そのフィードバックは意味を失う。

後になって、私たちが本当に欲しかったのはフィードバックだけだったのか、と考えるようになった。市場がプロダクトを検証する前に、優れた投資家たちの承認を得て、自分たちが方向を間違えていないと安心したかったのかもしれない。

それは、見知らぬ川の中に立ちながら、岸の人に先に泳ぐ方向を教えてもらおうとするようなものだった。だが起業家は最後には自分で流れを感じ、目の前の事実から判断しなければならない。

東升大厦の「玄冥二佬」

2024年後半、私たちは搜狐大厦から東升大厦へ移った。

幼なじみと私は長時間ペアで開発し、同じ画面を見ながら議論することが多かった。コワーキングスペースの若い起業家たちの中で、この働き方は目立った。やがて皆から「玄冥二佬」というあだ名をつけられた。

面白い話だ。子どもの頃に一緒に鳥の巣を探り、けんかをした二人が、二十年後、共有オフィスに座ってMagicGourdというプロダクトを作っている。

科含（Kehan）と知り合ったのも東升大厦だった。彼はMiraclePlusでコミュニティと起業プロジェクトの募集を担当していた。初めて話しかけられたとき、彼はこう言った。「お二人は起業家ですよね？　ずっと見ていました。このオフィス全体で、いちばん起業家らしい状態にいるのはお二人です。」

その後、私たちがMiraclePlusの面接を受けたと知り、当時のことを話した。投資家が起業アイデアを繰り返し疑うのは、単に反対を表明するためだけではないこともある、と彼は教えてくれた。起業家が本当に考え抜いているか、圧力の中でも自分の判断を保てるかを試している場合もあるという。

その話を聞いて、私は面接を捉え直した。

投資家を尊重することは、判断を投資家に渡すことではない。なぜ反対されるのかを理解しなければならないが、相手を尊敬しているという理由だけで自分の判断を捨ててもいけない。避けるべきなのは、新しい事実によって意見を変えることではない。考えが固まっていないのに、承認を得るためだけに言い方を変えることだ。

これは資金調達だけの教訓ではない。プロダクトを作るとき、私たちは毎日、ユーザーの声、競合プロダクトの選択、新しい技術の潮流に向き合う。こうした外部シグナルはすべて真剣に理解すべきだが、何をプロダクトに入れるかを決める責任は、依然として私たちにある。

ひょうたんはできた

2024年末までに、MagicGourdは27のバージョンを開発し、公開していた。

通常のウェブページでのテキストと画像の注釈から始め、オンラインPDFへ広げ、同じ方法をBilibiliとYouTubeにも適用した。ユーザーは心が動いた動画の一場面を印づけ、ノートを書き、タイムラインからすぐにその瞬間へ戻れる。タグ管理、検索、エクスポートも順次追加し、ブラウザや端末をまたいでデータを同期できるようにした。

コンテンツ形式を一つ増やすたびに、多くの適応作業が必要になった。ウェブページには統一された構造がなく、動画プラットフォームも変化し続ける。あるサイトで正しく動く機能が、別のページやブラウザではまったく違う挙動をすることがある。多くの時間は目立つ新機能ではなく、境界条件を処理し、既存の能力をより安定して動かすために使われた。

この年に公開した27のバージョンでは、ユーザーデータの消失や破損は確認されなかった。時折起きた障害は、ログイン認証コードなどのサービス工程に集中していた。報告を受けると、たいていはすぐに原因を特定し、解決できた。これは今後システムに問題が起きないことを証明するものではない。それでも、見えない場所に費やした時間が無駄ではなかったことは示している。

11月、私たちは動画ノート機能をsspaiで紹介した。コメント欄にはユーザーからの声が届き始めた。以前は保存したい動画の場面をスクリーンショットにして別の場所へ貼っていた人が、MagicGourdを試したあと「この拡張機能に救われた！」と書いた。動画タイムラインの水滴型マーカーを気に入った人、独立したノートを望む人、Safari対応を待つ人もいた。

ユーザーからの声を受け取ることは、この年で最もうれしい出来事の一つだった。

うれしかったのは、プロダクトを褒められたことだけではない。私たちが作ったものを、誰かが現実の生活に取り入れてくれたことだった。役立つ提案も多く、私たちは判断を続けなければならなかった。どの意見が共通の問題を示し、どれが個人の習慣から来るのか。何をすぐ解決し、何が有用でも今の段階ではプロダクトに入れるべきでないのか。

プロダクト名を二つに分けるなら、この年の終わりまでに、少なくとも「ひょうたん」はできていた。心が動いた瞬間と着想を集め、保存し、管理するための器だ。

魔法はまだ現れていない

しかし、それはまだ私たちが思い描く魔法ではなかった。

もちろんAIを使う。だが、一つの記事を要約するだけではない。要約は情報を圧縮できても、認知を前へ進めるとは限らない。

私たちの理解では、情報とは人が受け取る内容であり、知識とは理解され整理された情報であり、認知とは、人が世界を理解し、つながりと判断をつくり、新しい経験に応じてそれらを修正する方法である。

今日のAIは情報処理が得意で、知識の整理も上手くなっている。記事を要約し、キーワードを抽出し、内容の中にすでに答えがある質問に答えられる。しかし十ページを一ページに縮めたり、ノートアプリの横にチャット欄を置いたりするだけなら、私たちが本当に作りたいものには触れていない。

未来のMagicGourdには、一人の人間が長年蓄積した記録を理解し、異なる時期や媒体に散らばる心の動きを再び出会わせてほしい。繰り返し現れながら明示されていないテーマを見つけ、ノート間のつながりや矛盾を示し、長く答えられていない問いを見つけ、過去の思考を適切な瞬間に呼び戻せるかもしれない。

さらに重要なのは、ユーザーがまだ考えていないが追究する価値のある問いを提示し、自分自身の新しい判断を形づくる手助けをすることだ。

ここには明確な境界が必要だ。AIは自分の推測を、ユーザーがまだ気づいていない「真実」として包んではならない。可能性のあるつながり、矛盾、問いを示すことはできる。しかし、そのつながりが成立するかを決めるのは、あくまでユーザーだ。

魔法はユーザーの代わりに考えることではない。まだ終わっていない自分の思考を、ユーザー自身が見つけられるようにすることだ。

この一年、私たちはこの考えに関する社内デモをいくつか作った。要約を生成し、内容を整理し、質問に答えることはできた。見た目はすでにAIプロダクトらしかった。しかし私たちの言う「認知を前へ進める」ものからはまだ遠く、AIの波に追いつくためだけに急いで公開することはしなかった。

AIが人の認知過程に深く関わるほど、アクセスする必要のあるデータは私的になる。だからこそ、プライバシーとデータ所有権は魔法とは別の技術問題ではなく、魔法が成立するための前提だと確信した。ユーザーを理解したいと言いながら、自分のデータを管理する権利を手放すよう求めることはできない。

こうして2024年12月31日、ひょうたんはできていたが、魔法はまだ現れていなかった。

投資は得られず、決定的な市場シグナルもなく、明確なビジネスモデルもできていなかった。この川がどこへ流れていくのか、まだ分からなかった。

それでも27のバージョンを公開し、ユーザーはプロダクトを自分の生活に取り入れ始めた。私たちも、動くデモを本物のプロダクトへ変え、長く責任を負うとはどういうことかを理解し始めた。

一年前、私は「いまも水の中にいる」と書いた。

一年後も、私は水の中にいた。川が簡単になったわけでも、対岸がはっきりしたわけでもない。

だが、ひょうたんはできた。

魔法はまだ現れていない。対岸にもまだ着いていない。それでも少なくとも、前へ泳ぎ始めていた。

1년이 지났지만, 나는 여전히 물속에 있다.

강이 쉬워진 것도 아니고 건너편 강둑이 더 선명해진 것도 아니다. 다만 1년 전과 달라진 점이 하나 있다. 거의 10년간 일한 센스타임을 막 떠난 2023년 하반기에는 대부분의 시간을 몸부림치며 방향을 찾는 데 썼다. 2024년에는 구체적인 제품 하나를 만드는 데 대부분의 시간을 쓰기 시작했다.

그해의 본류는 제품이었고, 몇 차례의 제한적인 투자 유치 시도가 지류였다. 투자를 받지 못했고 방향을 증명할 만큼 강한 시장 신호도 만나지 못했지만, 우리는 27개 버전을 개발해 출시했다.

다음 강으로 뛰어든 뒤, 마침내 앞으로 헤엄치는 법을 배우기 시작했다.

먼저 호리병을 만들다

지난해 말 글에서 나는 결국 지능형 노트에서 시작하기로 했다고 썼다.

중학생 때부터 나는 글을 쓰지 않고 책을 읽지 않는 습관이 있었다. 책이나 글을 읽거나 영상을 볼 때 마음을 건드리는 대목을 알아차리고, 표시하고, 그 순간 떠오른 생각을 기록한다. 나는 이 과정을 ‘점 찾기’라고 부른다. 마음의 움직임을 알아차리고 거기서 생긴 영감을 기록하는 일이다.

그 점은 한 문장, 한 장의 이미지, 한 장면일 때도 있다. 당시에는 서로 아무 관련이 없어 보일 수 있다. 하지만 충분히 쌓이면 어느 순간 서로 연결되어, 하나의 문제를 이해하거나 이전에는 생각하지 못했던 판단을 형성하는 데 도움을 준다.

오랫동안 여러 노트 도구를 써 봤지만 이 습관에 정말 맞는 제품은 찾지 못했다. 센스타임을 떠난 뒤, 어릴 때 함께 새 둥지를 뒤지고 싸움도 하던 친구에게 연락해 같이 만들기로 했다. 2024년 상반기에는 대부분의 시간을 소후 타워의 공유 업무 공간에서 보냈다.

우리는 제품에 MagicGourd라는 이름을 붙였다.

‘호리병’은 내 아이의 애칭이기도 하다. 이름을 정할 때 의식적으로 많은 의미를 담은 것은 아니었다. 돌이켜 보면 그 안에는 무의식적인 바람이 숨어 있었는지도 모른다. 전업 창업자가 된 뒤 처음 만든 제품이 아이처럼 우리의 돌봄 속에서 천천히 자라기를 바랐던 것이다.

물론 제품은 아이가 아니다. 하지만 공통점이 하나 있다. 세상에 태어나게 하는 것은 시작일 뿐이고, 이후 오랫동안 돌보고 성장시키는 일이 정말 어렵다는 점이다.

우리가 그리던 진정한 제2의 뇌는 아직 현실에서 멀리 떨어져 있었고 한 번에 완성할 수 없었다. 그래서 가장 기본적인 한 걸음부터 시작하기로 했다. 웹을 탐색하거나 온라인 PDF를 읽고 영상을 볼 때, 마음을 건드린 부분을 바로 표시하고 영감을 적을 수 있게 하는 일이었다.

먼저 이런 점들을 담을 호리병을 만들자.

하나의 하이라이트 버튼 뒤에 있는 제품 판단

개발을 시작한 지 얼마 되지 않아, 너무 작아 보이는 문제 하나를 만났다. 하이라이트 버튼은 어떤 모습이어야 할까?

버튼 하나여야 할까, 여러 동작을 담은 패널이어야 할까? 사용자가 텍스트를 선택하면 바로 나타나야 할까, 아니면 사용자가 직접 불러낼 때까지 기다려야 할까? 어디에 나타나고 언제 사라져야 할까? 자동으로 나타나는 것을 싫어하는 사람을 위해 끄는 설정도 제공해야 할까?

선택지를 하나 늘릴 때마다 더 많은 요구를 충족할 수 있을 것 같지만, 제품을 이해하고 조작하는 비용도 늘어난다. 버튼이 더 적극적으로 나타나면 기능을 발견하기 쉬워지지만 읽기를 계속 방해할 수도 있다. 조용히 물러나 있으면 사용자는 더 집중할 수 있지만, 그런 기능이 있다는 사실조차 모를 수 있다.

이런 질문에는 알고리즘에서 말하는 표준 정답이 없다.

알고리즘을 만들 때 우리는 어떤 능력을 구현할 수 있는지, 정확도를 높일 수 있는지, 성능이 요구 사항에 도달하는지를 묻는다. 제품을 만들면서는 다른 질문을 반복하게 됐다. 기능은 언제 개입하고, 언제 무대 뒤로 물러나야 하는가?

기능이 동작한다는 것은 기술이 작동한다는 사실만 증명한다. 사용자가 그것을 이해하는지, 방해받는다고 느끼는지, 일상 속에 계속 두고 싶어 하는지가 제품의 성립 여부를 결정한다.

알고리즘과 대형 프로젝트를 만들 때도 현실 세계의 문제를 많이 다뤘다. 하지만 제품을 처음부터 만들자, 예전에는 제품, 디자인, 고객, 엔지니어링 팀이 나누어 맡던 판단이 갑자기 모두 우리의 몫이 됐다. 무엇을 보여 주고 무엇을 뒤에 숨길지, 무엇을 지금 만들고 무엇은 유용하더라도 당장은 만들지 않을지 결정해야 했다.

제품은 기능의 개수로 이루어지는 것이 아니라 수많은 선택으로 이루어진다는 사실을 조금씩 깨달았다. 때로는 ‘나타나지 않는 것’과 ‘방해하지 않는 것’도 제품의 능력이다.

제품은 시간 속에서 성립해야 한다

버튼이 자연스러운지는 사용자가 당장 느낄 수 있는 경험이다. 하지만 제품이 여러 해 동안 사용될지를 결정하는 더 많은 요인은 보이지 않는 곳에 숨어 있다.

MagicGourd는 한 사람의 독서 기록, 마음이 움직인 순간, 생각을 보관한다. 우리는 사용자 프라이버시를 최대한 보호하면서 기기 간 동기화와 미래의 지능형 서비스도 제공하고 싶었다. 둘을 동시에 이루기 위해 데이터를 로컬에서 암호화하고 백엔드에는 암호문만 저장하는 방식을 택했다. 개발과 유지 보수는 더 복잡해졌다. 하지만 사용자가 자신의 데이터를 진정으로 소유할 수 없다면, 진정한 제2의 뇌는 처음부터 성립할 수 없다.

동기화도 단순해 보이지만 실제로는 매우 복잡한 문제다. 사용자가 하이라이트 하나를 만들면 화면은 네트워크를 기다리며 멈추지 않고 즉시 반응해야 한다. 연결이 약하거나 완전히 끊겨도 기록은 중단되어서는 안 된다. 네트워크가 돌아오면 서로 다른 기기의 데이터가 중복되거나 덮어쓰이거나 조용히 사라지지 않고 정확히 동기화되어야 한다.

이를 위해 프런트엔드와 백엔드가 어떻게 협력할지, 데이터베이스가 데이터를 어떻게 구성할지, 버전 업그레이드 때 호환성을 어떻게 유지할지, 오류가 생긴 뒤 어떻게 복구할지를 다시 고민해야 했다. 사용자는 보통 이런 설계를 보지 못한다. 하지만 그중 하나라도 실패하면 숨겨져 있던 복잡성이 순식간에 가장 직접적인 사용자 경험으로 바뀐다.

단기적인 경험은 비교적 만들기 쉽다. 몇 분 동안 사람을 놀라게 하는 매끄러운 데모는 그리 어렵지 않다. 하지만 우리 눈에는 여전히 데모일 뿐이다.

데모는 눈앞에서만 성립하면 된다. 제품은 시간 속에서 성립해야 한다.

제품이 사용자를 10년 동안 동반하려 한다면, 10년 뒤의 경험을 지탱할 기반을 오늘부터 쌓아야 한다. 일반적인 도구의 장애는 잠깐의 불편으로 끝날 수 있다. 하지만 수년간의 노트를 보관하는 제품에서 한 번의 데이터 손실은 사용자가 쌓아 온 신뢰를 모두 무너뜨릴 수 있다.

시스템에 문제가 절대 생기지 않을 것이라고 약속할 수는 없다. 하지만 ‘사용자의 노트 한 건도 잃지 않는다’는 원칙은 가장 중요한 설계 제약 중 하나여야 한다. 제품 경험은 화면에서만 일어나는 것이 아니라 사용자가 볼 수 없는 데이터베이스 안에서도 일어난다.

아주 짧은 투자 유치의 지류

투자 유치를 그해의 지류라고 부르는 것조차 과장일 수 있다. 우리는 투자 기관 세 곳과만 대화했고, 나머지 대부분의 시간은 계속 제품을 만드는 데 썼다.

생각은 단순했다. 직접 또는 간접적으로 아는 초기 투자자에게 우리가 만드는 것을 설명하고 첫 엔젤 투자를 받고 싶었다.

그 투자의 의미는 돈에만 있지 않았다. 제품은 아직 완성되지 않았고 분명한 시장 신호도 없었다. 이 단계에서 뛰어난 투자자들이 이 방향을 타당하다고 보는지 외부의 피드백을 얻고 싶었다.

몇 차례의 시도는 모두 결과로 이어지지 않았다. 당시에는 AI 애플리케이션의 투자 환경이 좋지 않았고 우리도 투자자와 대화하는 데 익숙하지 않았기 때문이라고 생각했다. 두 요인 모두 존재했다. 하지만 돌이켜 보면 더 직접적인 사실이 있다. 투자 유치에 쓴 시간이 적었고 만난 기관도 세 곳뿐이었다. 한 차례의 투자 유치에 실패했다고 하기보다, 투자 기관과 몇 번의 초기 대화를 나눴다고 하는 편이 정확하다.

더 돌아볼 것은 의심을 받았을 때 나의 반응이었다.

MiraclePlus 면접에서 내 맞은편에는 내가 깊이 존경하는 사람들이 앉아 있었다. 그들이 우리의 생각을 거듭 반박하고 질문을 날카롭게 던졌을 때, 나는 복잡한 마음이 들었다. 투자를 받으러 왔으니 그들의 판단을 존중해야 하고, 어느 정도는 그들이 기대하는 답에 가까워져야 한다고 느꼈다.

하지만 투자 유치를 통해 솔직한 피드백을 얻으려 했다면, 스스로 믿지 않는 말을 하는 순간 그 피드백은 의미를 잃는다.

나중에는 우리가 정말 피드백만 원했던 것인지 의심하기 시작했다. 시장이 제품을 검증하기 전에 뛰어난 투자자들의 인정을 받아, 방향을 잘못 선택하지 않았다는 확신을 얻고 싶었던 것인지도 모른다.

낯선 강에 서서 강가의 누군가가 먼저 어디로 헤엄칠지 알려 주기를 바라는 것과 같았다. 하지만 창업자는 결국 직접 물살을 느끼고 눈앞의 사실에 근거해 판단해야 한다.

둥성 타워의 ‘현명 이로’

2024년 하반기, 우리는 소후 타워에서 둥성 타워로 옮겼다.

어릴 적 친구와 나는 오랫동안 페어 프로그래밍을 했고, 같은 화면을 바라보며 이야기하는 일이 많았다. 공유 업무 공간의 젊은 창업자들 사이에서 이런 일하는 방식은 눈에 띄었다. 시간이 지나자 사람들은 우리에게 ‘현명 이로’라는 별명을 붙였다.

재미있는 일이었다. 어린 시절 함께 새 둥지를 뒤지고 싸웠던 두 사람이 20년 뒤 공유 사무실에 앉아 MagicGourd라는 제품을 만들고 있었다.

커한을 만난 곳도 둥성 타워였다. 그는 MiraclePlus에서 커뮤니티와 창업 프로젝트 모집을 맡고 있었다. 처음 말을 걸었을 때 그는 물었다. “두 분은 창업자죠? 오래 지켜봤어요. 이 사무실 전체에서 두 분이 가장 창업자다운 상태로 일하고 있어요.”

나중에 우리가 MiraclePlus 면접을 봤다는 것을 알고 당시 상황을 함께 이야기했다. 그는 투자자가 창업 아이디어를 반복해서 의심하는 것이 단순히 반대를 표현하기 위해서만은 아닐 수 있다고 말했다. 창업자가 정말 충분히 생각했는지, 압박 속에서도 자신의 판단을 유지할 수 있는지를 시험하는 경우도 있다는 것이다.

그 말을 듣고 나는 당시 면접을 새롭게 이해했다.

투자자를 존중하는 것은 판단을 투자자에게 넘기는 일이 아니다. 창업자는 다른 사람이 왜 반대하는지 이해해야 하지만, 그들이 존경할 만하다는 이유만으로 자신의 판단을 포기해서는 안 된다. 피해야 할 것은 새로운 사실에 따라 생각을 바꾸는 일이 아니다. 아직 충분히 생각하지 않은 상태에서 인정받기 위해 말만 바꾸는 일이다.

이 교훈은 투자 유치에만 해당하지 않는다. 제품을 만들 때 우리는 매일 사용자 피드백, 경쟁 제품의 선택, 새로운 기술 흐름을 마주한다. 이런 외부 신호는 모두 진지하게 이해해야 하지만, 무엇을 제품에 넣을지 결정하는 책임은 여전히 우리에게 있다.

호리병은 생겼다

2024년 말까지 우리는 MagicGourd의 27개 버전을 개발해 출시했다.

일반 웹페이지의 텍스트와 이미지 주석으로 시작해 온라인 PDF를 지원했고, 같은 방법을 Bilibili와 YouTube로 확장했다. 사용자는 마음이 움직인 영상 장면을 표시하고 노트를 쓴 뒤 타임라인에서 그 순간으로 빠르게 돌아갈 수 있었다. 태그 관리, 검색, 내보내기도 차례로 추가했고 브라우저와 기기 사이에서 데이터를 동기화했다.

콘텐츠 형식을 하나 늘릴 때마다 많은 적응 작업이 필요했다. 웹페이지에는 통일된 구조가 없고 영상 플랫폼도 계속 바뀐다. 한 사이트에서 정상 작동하는 기능이 다른 페이지나 브라우저에서는 전혀 다르게 움직일 수 있다. 많은 시간은 눈에 띄는 새 기능이 아니라 경계 조건을 처리하고 기존 기능을 더 안정적으로 작동시키는 데 쓰였다.

그해 출시한 27개 버전에서 사용자 데이터가 유실되거나 손상된 사례는 발견하지 못했다. 가끔 발생한 장애는 로그인 인증 코드 같은 서비스 단계에 주로 집중됐다. 제보를 받으면 대부분 빠르게 원인을 찾고 해결할 수 있었다. 이것이 앞으로 시스템에 문제가 생기지 않을 것임을 증명하지는 않는다. 다만 사용자가 볼 수 없는 곳에 들인 시간이 헛되지 않았음을 보여 준다.

11월에는 sspai에서 영상 노트 기능을 소개했다. 댓글에 사용자 피드백이 달리기 시작했다. 이전에는 유용한 영상 장면을 캡처해 다른 곳에 붙여 넣던 한 사용자는 MagicGourd를 써 본 뒤 “이 확장 프로그램이 나를 살렸어요!”라고 썼다. 영상 타임라인의 물방울 표시를 좋아한 사람도 있었고, 독립 노트나 빠른 Safari 지원을 바라는 사람도 있었다.

사용자 피드백을 받는 일은 그해 가장 기쁜 일 중 하나였다.

기뻤던 이유는 사람들이 제품을 칭찬해서만이 아니었다. 누군가 우리가 만든 것을 자신의 실제 생활에 들여놓았기 때문이다. 사용자들은 유용한 제안도 건넸고, 우리는 계속 판단해야 했다. 어떤 의견이 공통 문제를 보여 주고 어떤 의견이 개인의 사용 습관에서 나오는지, 무엇을 즉시 해결하고 무엇은 유용하더라도 현재 단계의 제품에는 넣지 말아야 하는지 판단해야 했다.

제품 이름을 둘로 나누어 본다면, 그해 말까지 적어도 ‘호리병’은 만들었다. 마음이 움직인 순간과 영감을 모으고, 보존하고, 관리하는 그릇이었다.

마법은 아직 나타나지 않았다

하지만 그것은 아직 우리가 생각한 마법이 아니었다.

물론 AI를 사용할 것이다. 그러나 글 한 편의 요약을 만드는 데 그치지는 않는다. 요약은 정보를 압축할 수 있지만 인지를 앞으로 나아가게 하지는 못할 수 있다.

우리의 이해에서 정보는 사람이 받아들이는 내용이고, 지식은 이해되고 조직된 정보이며, 인지는 사람이 세계를 이해하고 연결과 판단을 만들고 새로운 경험이 들어올 때 그것을 수정하는 방식이다.

오늘날의 AI는 정보를 잘 처리하고 지식을 정리하는 능력도 점점 좋아지고 있다. 글을 요약하고 핵심어를 추출하고, 자료 안에 이미 답이 있는 질문에 대답할 수 있다. 하지만 열 쪽을 한 쪽으로 압축하거나 노트 앱 옆에 채팅창을 붙이는 데 그친다면 우리가 정말 만들고 싶은 것에는 아직 닿지 못한다.

미래의 MagicGourd는 한 사람이 오랫동안 쌓아 온 기록을 이해하고, 서로 다른 시기와 매체에 흩어진 마음의 움직임을 다시 만나게 해야 한다. 반복해서 등장하지만 명시적으로 표현된 적 없는 주제를 발견하고, 노트 사이의 연결과 모순을 보여 주며, 오랫동안 답하지 못한 질문을 찾거나 과거의 생각을 적절한 순간에 다시 불러올 수 있을 것이다.

더 중요한 것은 사용자가 아직 생각하지 못했지만 계속 탐구할 가치가 있는 질문을 제시해, 스스로 새로운 판단을 형성하도록 돕는 일이다.

여기에는 분명한 경계가 필요하다. AI는 자신의 추측을 사용자가 아직 깨닫지 못한 ‘진실’로 포장해서는 안 된다. 가능한 연결, 모순, 질문을 제시할 수는 있다. 그 연결이 타당한지는 끝내 사용자가 판단해야 한다.

마법은 사용자를 대신해 생각하는 것이 아니다. 사용자가 아직 끝내지 못한 자신의 생각을 볼 수 있도록 돕는 것이다.

그해 우리는 이 아이디어와 관련된 내부 데모 몇 개를 만들었다. 요약을 만들고 내용을 정리하며 질문에 답할 수 있었다. 이미 AI 제품처럼 보이기도 했다. 하지만 우리가 말한 ‘인지를 앞으로 나아가게 하는 것’과는 여전히 거리가 멀었기 때문에, AI 흐름을 따라가기 위해 서둘러 출시하지 않았다.

AI가 한 사람의 인지 과정에 더 깊이 참여할수록 접근해야 하는 데이터는 더 사적이 된다. 그래서 프라이버시와 데이터 소유권은 마법과 별개의 엔지니어링 문제가 아니라 마법이 성립하기 위한 전제라고 더욱 확신하게 됐다. 사용자를 이해하고 싶다고 말하면서 동시에 자신의 데이터에 대한 통제권을 포기하라고 요구할 수는 없다.

그래서 2024년 12월 31일, 호리병은 생겼지만 마법은 아직 나타나지 않았다.

투자를 받지 못했고, 결정적인 시장 신호도 보지 못했으며, 분명한 사업 모델도 세우지 못했다. 이 강이 결국 어디로 흐를지도 여전히 알지 못했다.

하지만 우리는 27개 버전을 출시했다. 사용자들은 제품을 자신의 생활에 들이기 시작했다. 우리도 작동하는 데모를 진짜 제품으로 바꾸고 오랫동안 책임진다는 것이 무엇인지 이해하기 시작했다.

1년 전 나는 “나는 아직 물속에 있다”고 썼다.

1년 뒤에도 나는 여전히 물속에 있었다. 강이 쉬워진 것도, 건너편 강둑이 더 선명해진 것도 아니었다.

하지만 호리병은 만들었다.

마법은 아직 나타나지 않았다. 건너편에도 도착하지 못했다. 그래도 적어도 앞으로 헤엄치기 시작했다.

Um ano se passou, e continuo na água.

O rio não ficou mais fácil, nem a margem oposta mais nítida. Mas algo mudou. No segundo semestre de 2023, logo depois de deixar a SenseTime, onde trabalhei por quase dez anos, passei a maior parte do tempo lutando e procurando uma direção. Em 2024, começamos a dedicar a maior parte do nosso tempo ao desenvolvimento de um produto concreto.

O fio principal do ano foi o produto; algumas tentativas limitadas de captação formaram um fio secundário. Não conseguimos investimento nem vimos um sinal de mercado forte o bastante para confirmar a direção, mas desenvolvemos e lançamos 27 versões.

Depois de saltar para o próximo rio, finalmente começamos a aprender a nadar para a frente.

Primeiro, fazer uma cabaça

No ensaio do fim do ano passado, escrevi que havia decidido começar pelas notas inteligentes.

Desde o ensino médio, tenho o hábito de não ler sem escrever. Quando leio um livro ou artigo, ou assisto a um vídeo, presto atenção aos trechos que me tocam, marco-os e registro as ideias que surgem. Chamo esse processo de “encontrar pontos”: perceber o que nos toca e registrar a inspiração.

Às vezes, um ponto é apenas uma frase, uma imagem ou um quadro de vídeo. Naquele momento, eles podem parecer desconectados. Mas, quando se acumulam em quantidade suficiente, acabam se ligando e me ajudam a compreender um problema ou formar um julgamento no qual eu ainda não havia pensado.

Durante muitos anos, experimentei diferentes ferramentas de notas, mas nunca encontrei um produto que realmente se ajustasse a esse hábito. Depois de deixar a SenseTime, procurei um amigo de infância — o mesmo com quem eu mexia em ninhos de pássaros e entrava em brigas — e decidimos construí-lo juntos. No primeiro semestre de 2024, passamos a maior parte do tempo trabalhando em um espaço compartilhado na Torre Sohu.

Chamamos o produto de MagicGourd.

“Gourd”, cabaça, também é o apelido do meu filho. Quando escolhemos o nome, não lhe atribuí conscientemente tanto significado. Olhando para trás, talvez houvesse ali um desejo inconsciente: que o primeiro produto construído por mim como empreendedor em tempo integral pudesse, como uma criança, crescer aos poucos sob nossos cuidados.

Um produto não é uma criança, claro. Mas eles têm algo em comum: trazê-lo ao mundo é apenas o começo. O longo trabalho de cuidar dele e ajudá-lo a crescer é a parte realmente difícil.

O verdadeiro segundo cérebro que imaginávamos ainda estava longe da realidade e não poderia ser concluído de uma só vez. Por isso, decidimos começar pelo passo mais básico: permitir que as pessoas marcassem o que as tocava e anotassem suas inspirações enquanto navegavam na web, liam um PDF on-line ou assistiam a um vídeo.

Primeiro, fazer uma cabaça capaz de guardar esses pontos.

As decisões de produto por trás de um botão de destaque

Logo depois de começar o desenvolvimento, encontramos uma questão que parecia pequena demais para importar: como deveria ser o botão de destaque?

Ele deveria ser um único botão ou um painel com várias ações? Depois que alguém selecionasse um texto, deveria aparecer imediatamente ou esperar ser chamado? Onde deveria aparecer e quando deveria desaparecer? Se alguém não gostasse que aparecesse automaticamente, deveríamos oferecer uma opção para desativá-lo?

Cada opção adicional parece atender a mais necessidades, mas também aumenta o custo de entender e usar o produto. Fazer o botão aparecer de forma mais ativa facilita descobrir a função, mas também pode interromper a leitura repetidamente. Mantê-lo mais discreto pode ajudar na concentração, mas talvez a pessoa nunca perceba que a função existe.

Não existe uma resposta padrão, no sentido algorítmico, para perguntas como essas.

Ao desenvolver algoritmos, costumamos perguntar se uma capacidade pode ser implementada, se a precisão pode aumentar e se o desempenho atende aos requisitos. Ao desenvolver um produto, passamos a fazer outra pergunta: quando uma função deve intervir e quando deve recuar para os bastidores?

O fato de uma função rodar apenas demonstra que a tecnologia funciona. Se as pessoas a compreendem, se se sentem interrompidas e se querem mantê-la em sua vida cotidiana é o que determina se o produto funciona.

Eu já havia lidado com muitos problemas do mundo real ao desenvolver algoritmos e grandes projetos. Mas, quando criamos um produto do zero, decisões antes compartilhadas entre equipes de produto, design, clientes e engenharia de repente passaram a ser só nossas. Precisávamos decidir o que deveria ser visível e o que deveria permanecer nos bastidores; o que fazer agora e o que deixar de fora, mesmo que pudesse ser útil.

Aos poucos, percebemos que um produto não é formado pela quantidade de funções, mas por incontáveis escolhas. Às vezes, não aparecer e não interromper também são capacidades do produto.

Um produto precisa se sustentar no tempo

Se um botão parece natural é algo que o usuário percebe imediatamente. Mas muitos dos fatores que determinam se um produto será usado por anos ficam escondidos.

O MagicGourd guarda o histórico de leitura, os momentos de impacto e as ideias de uma pessoa. Queríamos proteger ao máximo a privacidade dos usuários e, ao mesmo tempo, oferecer sincronização entre dispositivos e, no futuro, serviços inteligentes. Para fazer as duas coisas, escolhemos criptografar os dados localmente e armazenar apenas texto cifrado no backend. Isso aumentou a complexidade do desenvolvimento e da manutenção. Mas, se a pessoa não pode ser verdadeiramente dona dos próprios dados, um verdadeiro segundo cérebro é impossível desde o início.

A sincronização é outro problema que parece simples, mas é muito complexo. Quando alguém cria um destaque, a interface deve responder imediatamente, em vez de parar e esperar pela rede. O registro não deve ser interrompido nem com conexão fraca nem sem conexão. Quando a rede voltar, os dados de diferentes dispositivos precisam ser sincronizados corretamente, sem duplicação, sobrescrita ou desaparecimento silencioso.

Isso nos obrigou a repensar como frontend e backend deveriam trabalhar juntos, como o banco de dados deveria organizar as informações, como as atualizações preservariam a compatibilidade e como o sistema se recuperaria de falhas. O usuário normalmente não vê essas decisões. Mas, quando uma delas falha, toda a complexidade oculta se transforma de imediato na experiência mais direta.

A experiência de curto prazo é relativamente fácil de produzir. Não é tão difícil criar uma demonstração fluida que impressione por alguns minutos. Mas, para nós, ela ainda seria apenas uma demo.

Uma demo só precisa funcionar diante dos olhos. Um produto precisa se sustentar no tempo.

Se um produto pretende acompanhar alguém por dez anos, os alicerces da experiência daqui a dez anos precisam ser construídos hoje. Uma falha em uma ferramenta comum talvez seja apenas um incômodo temporário. Em um produto que guarda anos de notas, uma única perda de dados pode destruir toda a confiança acumulada pelo usuário.

Não podemos prometer que o sistema nunca terá problemas. Mas “não perder uma única nota do usuário” precisa ser uma das nossas restrições de projeto mais importantes. A experiência do produto não acontece apenas na tela; ela também acontece no banco de dados que o usuário nunca vê.

Um fio secundário de captação muito curto

Talvez seja exagero até chamar a captação de recursos de fio secundário do ano. Conversamos com apenas três firmas de investimento e passamos quase todo o restante do tempo desenvolvendo o produto.

Nossa ideia era simples: procurar investidores em estágio inicial que conhecíamos direta ou indiretamente, explicar o que estávamos construindo e tentar obter nosso primeiro investimento-anjo.

O valor desse investimento não estaria apenas no dinheiro. O produto ainda não estava pronto e não havia um sinal claro do mercado. Naquele momento, queríamos receber uma avaliação externa sobre se bons investidores consideravam que a direção fazia sentido.

Nenhuma dessas tentativas produziu resultado. Na época, atribuímos isso a um ambiente de financiamento ruim para aplicações de IA e à nossa pouca experiência em conversar com investidores. Os dois fatores existiam. Mas, olhando agora, havia um fato mais imediato: dedicamos pouco tempo à captação e falamos com apenas três firmas. Em vez de dizer que passamos por uma rodada de captação fracassada, seria mais preciso dizer que tivemos algumas conversas preliminares com investidores.

O que merece mais reflexão é como reagi quando nossas ideias foram questionadas.

Na entrevista com a MiraclePlus, diante de mim estavam pessoas que eu respeitava profundamente. Quando elas desafiavam repetidamente nossas ideias e faziam perguntas muito duras, eu sentia uma tensão: estávamos ali buscando investimento, então parecia que eu deveria respeitar o julgamento delas e até me aproximar, em alguma medida, das respostas que esperavam.

Mas, se buscávamos investimento para receber um retorno honesto, dizer algo em que não acreditávamos tornaria esse retorno sem sentido.

Mais tarde, comecei a me perguntar se era mesmo só isso que queríamos. Talvez, antes de o produto ser validado pelo mercado, também buscássemos a aprovação de um grupo de excelentes investidores para nos assegurar de que não havíamos escolhido a direção errada.

Era como estar em um rio desconhecido, esperando que alguém na margem nos dissesse primeiro para onde nadar. Mas um empreendedor precisa sentir a corrente por si mesmo e julgar com base nos fatos à sua frente.

Os “Anciãos de Xuanming” da Torre Dongsheng

No segundo semestre de 2024, mudamos da Torre Sohu para a Torre Dongsheng.

Meu amigo de infância e eu programávamos em par por longos períodos, muitas vezes sentados diante da mesma tela enquanto conversávamos. Entre os jovens empreendedores do espaço compartilhado, essa forma de trabalhar chamava bastante atenção. Com o tempo, ganhamos um apelido: os “Anciãos de Xuanming”.

Era engraçado. Duas pessoas que, quando crianças, mexiam em ninhos de pássaros e brigavam juntas estavam, vinte anos depois, sentadas em um escritório compartilhado construindo um produto chamado MagicGourd.

Foi na Torre Dongsheng que conhecemos Kehan. Na MiraclePlus, ele era responsável pela comunidade e pelo recrutamento de projetos empreendedores. Na primeira vez que falou conosco, perguntou: “Vocês são empreendedores, certo? Observo vocês há muito tempo. De todo mundo neste escritório, vocês dois são os que mais parecem estar de verdade no modo fundador.”

Mais tarde, quando soube que havíamos participado de uma entrevista da MiraclePlus, conversamos sobre o que tinha acontecido. Ele explicou que, quando investidores questionam repetidamente uma ideia, nem sempre estão apenas expressando discordância. Também podem estar testando se os fundadores realmente pensaram bem no assunto e se conseguem preservar o próprio julgamento sob pressão.

Isso me fez reinterpretar a entrevista.

Respeitar os investidores não significa entregar a eles nosso julgamento. Um empreendedor precisa entender por que os outros discordam sem abandonar o próprio critério só porque essas pessoas merecem respeito. O que deve ser evitado não é mudar de opinião diante de novos fatos, mas mudar o que dizemos apenas para obter aprovação antes de pensar bem na questão.

Essa lição não vale apenas para captação. Ao desenvolver um produto, encontramos diariamente comentários de usuários, escolhas feitas por produtos concorrentes e novas tendências tecnológicas. Todos esses sinais externos merecem atenção, mas decidir o que deve entrar no produto continua sendo nossa responsabilidade.

A cabaça já existe

No fim de 2024, havíamos desenvolvido e lançado 27 versões do MagicGourd.

Começamos com anotações de texto e imagem em páginas comuns, depois adicionamos suporte a PDFs on-line e estendemos o mesmo método ao Bilibili e ao YouTube. O usuário podia marcar um quadro de vídeo que o tocasse, escrever uma nota e retornar rapidamente àqueles momentos na linha do tempo. Também adicionamos gerenciamento de etiquetas, busca e exportação, e sincronizamos dados entre navegadores e dispositivos.

Cada novo formato de conteúdo exigia muita adaptação. As páginas da web não têm uma estrutura uniforme, e as plataformas de vídeo mudam continuamente. Uma função que opera corretamente em um site pode se comportar de maneira totalmente diferente em outra página ou navegador. Grande parte do nosso tempo não produziu capacidades novas e visíveis: foi dedicada a resolver casos-limite para que as capacidades existentes funcionassem com mais estabilidade.

Nas 27 versões lançadas durante o ano, não encontramos casos de perda ou corrupção de dados dos usuários. As falhas ocasionais se concentraram em etapas do serviço, como códigos de verificação de login. Quando recebíamos um relato, quase sempre conseguíamos localizar e resolver o problema rapidamente. Isso não prova que o sistema nunca falhará, mas sugere que o tempo dedicado ao que o usuário não vê não foi desperdiçado.

Em novembro, apresentamos o recurso de notas de vídeo no sspai. Os usuários começaram a deixar comentários. Uma pessoa que antes salvava quadros úteis tirando capturas de tela e colando-as em outro lugar escreveu, depois de experimentar o MagicGourd: “Este plugin me salvou!” Outros gostaram dos marcadores em forma de gota na linha do tempo, pediram notas independentes ou esperavam suporte ao Safari em breve.

Receber comentários dos usuários foi uma das maiores alegrias do ano.

O que nos alegrou não foi apenas o elogio ao produto, mas o fato de alguém ter incorporado à vida real algo que havíamos criado. As pessoas também davam sugestões úteis que nos levavam a continuar decidindo: quais comentários revelavam um problema comum e quais vinham de um hábito individual; o que deveria ser resolvido imediatamente e o que, embora útil, ainda não deveria entrar no produto.

Se dividirmos o nome do produto em duas partes, no fim do ano pelo menos já havíamos construído a “cabaça”: um recipiente para coletar, preservar e organizar momentos de impacto e inspiração.

A magia ainda não apareceu

Mas aquilo ainda não era a magia que tínhamos em mente.

Ela certamente usaria IA, mas não se limitaria a gerar o resumo de um artigo. Um resumo pode comprimir informação sem fazer a cognição avançar.

Na nossa maneira de entender, informação é o conteúdo que uma pessoa recebe; conhecimento é informação compreendida e organizada; cognição é a forma como uma pessoa entende o mundo, cria conexões e julgamentos e os revisa quando chegam novas experiências.

A IA de hoje é boa em processar informação e cada vez melhor em organizar conhecimento. Ela pode resumir um artigo, extrair palavras-chave e responder a perguntas cuja resposta já está no material. Mas, se apenas comprime dez páginas em uma ou adiciona uma caixa de conversa ao lado de um aplicativo de notas, ainda não tocou no que realmente queremos construir.

Queremos que um futuro MagicGourd compreenda os registros que uma pessoa acumulou ao longo do tempo e reúna momentos de impacto dispersos entre diferentes épocas e mídias. Ele poderia descobrir temas que se repetem sem nunca terem sido explicitados, revelar conexões e contradições entre notas, identificar perguntas há muito tempo sem resposta ou trazer de volta um pensamento anterior no momento certo.

Mais importante, deveria levantar perguntas que o usuário ainda não considerou, mas que valem a pena investigar, ajudando-o a formar novos julgamentos próprios.

É preciso haver um limite claro: a IA não pode apresentar suas suposições como uma “verdade” que o usuário ainda não percebeu. Ela pode propor possíveis conexões, contradições e perguntas. Se essas conexões fazem sentido, ainda cabe ao usuário decidir.

A magia não pensa no lugar do usuário. Ela o ajuda a enxergar o pensamento que ainda não terminou.

Durante o ano, construímos algumas demos internas relacionadas a essa ideia. Elas conseguiam gerar resumos, organizar conteúdo e responder a perguntas. Já pareciam produtos de IA. Mas ainda estavam longe do que chamamos de “fazer a cognição avançar”, por isso não as lançamos às pressas apenas para acompanhar a onda da IA.

Quanto mais profundamente a IA participa do processo cognitivo de uma pessoa, mais privados são os dados que precisa acessar. Isso nos deixou ainda mais certos de que privacidade e propriedade dos dados não são questões de engenharia separadas da magia: são condições para que a magia possa existir. Não podemos afirmar que queremos compreender os usuários e, ao mesmo tempo, pedir que abram mão do controle dos próprios dados.

Assim, em 31 de dezembro de 2024, a cabaça já existia, mas a magia ainda não havia aparecido.

Não tínhamos conseguido investimento, visto um sinal decisivo do mercado nem estabelecido um modelo de negócio claro. Ainda não sabíamos aonde aquele rio acabaria nos levando.

Mas havíamos lançado 27 versões. Os usuários começavam a incorporar o produto à própria vida. E nós começávamos a entender como transformar uma demo que funcionava em um produto real e assumir responsabilidade por ele no longo prazo.

Um ano antes, eu havia escrito: “Ainda estou na água.”

Um ano depois, continuava na água. O rio não havia ficado mais fácil, nem a margem oposta mais clara.

Mas já tínhamos feito a cabaça.

A magia ainda não havia aparecido. Também não tínhamos chegado à outra margem. Mas, pelo menos, havíamos começado a nadar para a frente.

Прошёл год, а я всё ещё в воде.

Река не стала проще, и противоположный берег не стал яснее. Но кое-что изменилось. Во второй половине 2023 года, только что уйдя из SenseTime, где я проработал почти десять лет, я большую часть времени боролся с собой и искал направление. В 2024 году мы начали посвящать большую часть времени созданию конкретного продукта.

Главной линией года был продукт, а несколько ограниченных попыток привлечь финансирование стали побочной. Мы не получили инвестиций и не увидели рыночного сигнала, достаточно сильного, чтобы подтвердить выбранное направление, но разработали и выпустили 27 версий.

Прыгнув в следующую реку, мы наконец начали учиться плыть вперёд.

Сначала сделать горлянку

В эссе, написанном в конце прошлого года, я рассказал, что решил начать с умных заметок.

Со средней школы я привык не читать без карандаша в руке. Читая книгу или статью, смотря видео, я замечаю места, которые меня задевают, отмечаю их и записываю возникшие мысли. Я называю этот процесс «поиском точек»: заметить отклик и сохранить вдохновение.

Иногда точка — это всего одна фраза, изображение или кадр. В тот момент они могут казаться не связанными друг с другом. Но когда таких точек становится достаточно, в какой-то момент они соединяются и помогают мне понять проблему или сформировать суждение, о котором я раньше не думал.

Много лет я пробовал разные инструменты для заметок, но так и не нашёл продукта, который действительно соответствовал бы этой привычке. После ухода из SenseTime я позвал друга детства — того самого, с которым мы разоряли птичьи гнёзда и дрались, — и мы решили создать такой продукт вместе. В первой половине 2024 года мы большую часть времени работали в коворкинге в башне Sohu.

Мы назвали продукт MagicGourd.

«Горлянка» — ещё и домашнее прозвище моего ребёнка. Выбирая название, я не вкладывал в него столько смысла сознательно. Оглядываясь назад, я думаю, что в нём могло скрываться подсознательное желание: чтобы первый продукт, созданный мной после перехода к полноценному предпринимательству, рос под нашей заботой медленно, как ребёнок.

Конечно, продукт — не ребёнок. Но у них есть общее: появление на свет — лишь начало. По-настоящему трудна долгая работа по уходу и развитию.

Настоящий второй мозг, который мы представляли, был ещё далёк от реальности, и создать его за один шаг было невозможно. Поэтому мы решили начать с самого основного: дать людям возможность отмечать то, что их задело, и записывать мысли во время просмотра сайтов, чтения PDF онлайн или просмотра видео.

Сначала сделать горлянку, способную собирать эти точки.

Продуктовые решения за кнопкой выделения

Вскоре после начала разработки мы столкнулись с вопросом, который казался почти ничтожным: как должна выглядеть кнопка выделения?

Должна ли это быть одна кнопка или панель с несколькими действиями? После выделения текста должна ли она появляться сразу или ждать вызова пользователя? Где она должна возникать и когда исчезать? Если кому-то не нравится автоматическое появление, следует ли дать возможность его отключить?

Каждая новая настройка будто бы позволяет удовлетворить больше потребностей, но одновременно повышает цену понимания и использования продукта. Если показывать кнопку активнее, функцию легче обнаружить, но она может постоянно мешать чтению. Если сделать её тише, пользователю будет проще сосредоточиться, но он может вовсе не узнать о её существовании.

У подобных вопросов нет стандартного ответа в алгоритмическом смысле.

Создавая алгоритм, мы спрашиваем, можно ли реализовать способность, повысить точность и добиться нужной производительности. Создавая продукт, мы стали постоянно задавать другой вопрос: когда функция должна вмешаться, а когда — отойти за кулисы?

То, что функция запускается, доказывает лишь работоспособность технологии. Понимают ли её люди, не чувствуют ли помехи и хотят ли оставить её в своей повседневной жизни — вот что определяет состоятельность продукта.

Работая над алгоритмами и крупными проектами, я уже сталкивался со множеством проблем реального мира. Но когда мы начали создавать продукт с нуля, решения, которые раньше делили между собой продуктовая, дизайнерская, клиентская и инженерная команды, внезапно стали только нашими. Нам приходилось решать, что показать, а что спрятать; что делать сейчас, а что пока не делать, даже если это может быть полезно.

Постепенно мы поняли: продукт состоит не из количества функций, а из бесчисленных решений. Иногда не появляться и не мешать — тоже способности продукта.

Продукт должен выдерживать время

Удобство кнопки пользователь ощущает сразу. Но многие факторы, от которых зависит, будут ли пользоваться продуктом годами, скрыты от глаз.

MagicGourd хранит историю чтения, моменты отклика и мысли человека. Мы хотели максимально защитить приватность пользователей и одновременно дать синхронизацию между устройствами и в будущем интеллектуальные сервисы. Поэтому мы выбрали локальное шифрование данных, сохраняя на сервере только шифротекст. Это усложнило разработку и поддержку. Но если человек не может по-настоящему владеть собственными данными, настоящий второй мозг невозможен с самого начала.

Синхронизация — ещё одна задача, которая кажется простой, но на деле очень сложна. Когда человек создаёт выделение, интерфейс должен ответить мгновенно, а не останавливаться в ожидании сети. Запись не должна прерываться даже при слабом соединении или полном его отсутствии. Когда сеть вернётся, данные с разных устройств должны правильно синхронизироваться, не дублируясь, не перезаписывая друг друга и не исчезая незаметно.

Это заставило нас заново продумать взаимодействие фронтенда и бэкенда, организацию данных в базе, совместимость при обновлениях и восстановление после ошибок. Обычно пользователь не видит этих решений. Но стоит одному из них дать сбой, и вся скрытая сложность мгновенно становится самым непосредственным пользовательским опытом.

Краткосрочное впечатление создать сравнительно легко. Не так уж трудно сделать плавную демонстрацию, которая впечатлит человека на несколько минут. Но для нас это всё равно было бы лишь демо.

Демо должно выдержать только текущий момент. Продукт должен выдерживать время.

Если продукт должен сопровождать человека десять лет, фундамент его опыта через десять лет нужно строить уже сегодня. Сбой обычного инструмента может оказаться лишь временным неудобством. Но в продукте, где хранятся годы заметок, одна потеря данных способна уничтожить всё доверие пользователя.

Мы не можем обещать, что система никогда не столкнётся с проблемой. Но «не потерять ни одной пользовательской заметки» должно оставаться одним из важнейших проектных ограничений. Опыт продукта существует не только на экране, но и в базе данных, которую пользователь никогда не видит.

Очень короткая побочная линия финансирования

Возможно, даже называть финансирование побочной линией года — преувеличение. Мы поговорили всего с тремя инвестиционными компаниями, а почти всё остальное время продолжали создавать продукт.

Идея была проста: обратиться к ранним инвесторам, которых мы знали прямо или через знакомых, рассказать о продукте и попытаться получить первые ангельские инвестиции.

Ценность инвестиций заключалась не только в деньгах. Продукт ещё не был готов, и ясного рыночного сигнала не существовало. На этом этапе мы хотели получить взгляд со стороны: считают ли сильные инвесторы выбранное направление осмысленным.

Ни одна попытка не дала результата. Тогда мы объясняли это неблагоприятной средой для финансирования ИИ-приложений и собственной неопытностью в разговорах с инвесторами. Оба фактора были реальны. Но теперь очевиден более непосредственный факт: мы потратили на привлечение средств мало времени и поговорили лишь с тремя компаниями. Точнее будет сказать не о проваленном раунде, а о нескольких предварительных беседах.

Больше размышлений заслуживает моя реакция на сомнения собеседников.

На собеседовании в MiraclePlus напротив меня сидели люди, которых я глубоко уважал. Когда они снова и снова оспаривали наши идеи и задавали жёсткие вопросы, я испытывал внутреннее напряжение: раз мы пришли за инвестициями, мне казалось, что я должен уважать их суждение и в какой-то мере приблизиться к ответам, которых они ожидают.

Но если цель финансирования — получить честную обратную связь, слова, в которые мы сами не верим, лишают эту обратную связь смысла.

Позже я начал сомневаться, действительно ли мы хотели только обратной связи. Возможно, до рыночной проверки продукта мы также искали одобрения группы выдающихся инвесторов, чтобы убедиться, что не выбрали неверное направление.

Это было похоже на попытку стоять в незнакомой реке и ждать, пока кто-то на берегу скажет, куда плыть. Но предприниматель должен сам почувствовать течение и судить по фактам перед собой.

«Старцы Сюаньмин» в башне Dongsheng

Во второй половине 2024 года мы переехали из башни Sohu в башню Dongsheng.

Мы с другом детства подолгу программировали в паре, часто сидя перед одним экраном и обсуждая работу. Среди молодых предпринимателей коворкинга такой способ работы бросался в глаза. Со временем нам дали прозвище: «Старцы Сюаньмин».

Это было забавно. Два человека, которые в детстве вместе разоряли птичьи гнёзда и дрались, двадцать лет спустя сидели в общем офисе и создавали продукт под названием MagicGourd.

Именно в башне Dongsheng мы познакомились с Кэханем. В MiraclePlus он отвечал за сообщество и поиск предпринимательских проектов. В первый раз он спросил: «Вы ведь предприниматели? Я давно за вами наблюдаю. Во всём этом офисе именно вы двое больше всех похожи на людей в настоящем предпринимательском режиме».

Позже, узнав о нашем собеседовании в MiraclePlus, он обсудил с нами тот опыт. По его словам, когда инвесторы раз за разом подвергают идею сомнению, они не всегда лишь выражают несогласие. Иногда они проверяют, действительно ли основатели всё продумали и способны ли сохранить собственное суждение под давлением.

Это помогло мне иначе понять собеседование.

Уважать инвесторов не значит отдавать им своё суждение. Предприниматель должен понимать причины чужого несогласия, но не отказываться от собственного взгляда лишь потому, что эти люди достойны уважения. Избегать нужно не изменения мнения под влиянием новых фактов, а изменения своих слов ради одобрения, пока вопрос ещё не продуман.

Этот урок касается не только финансирования. Создавая продукт, мы каждый день сталкиваемся с отзывами пользователей, решениями конкурирующих продуктов и новыми технологическими тенденциями. Все эти внешние сигналы нужно внимательно понимать, но решение о том, что должно войти в продукт, остаётся нашей ответственностью.

Горлянка уже есть

К концу 2024 года мы разработали и выпустили 27 версий MagicGourd.

Мы начали с аннотаций текста и изображений на обычных веб-страницах, затем добавили поддержку PDF онлайн и распространили тот же подход на Bilibili и YouTube. Пользователь мог отметить тронувший его кадр видео, написать заметку и быстро вернуться к этому моменту на временной шкале. Мы также добавили управление тегами, поиск и экспорт, а данные синхронизировались между браузерами и устройствами.

Каждый новый формат контента требовал большой работы по адаптации. У веб-страниц нет единой структуры, а видеоплатформы постоянно меняются. Функция, работающая на одном сайте, на другой странице или в другом браузере может вести себя совершенно иначе. Значительная часть времени уходила не на заметные новые возможности, а на обработку граничных случаев, чтобы уже существующие функции работали стабильнее.

В 27 версиях, выпущенных за год, мы не обнаружили случаев потери или повреждения пользовательских данных. Редкие сбои в основном касались таких этапов сервиса, как коды подтверждения при входе. Получив сообщение, мы обычно быстро находили и устраняли проблему. Это не доказывает, что система больше никогда не даст сбой, но показывает, что время, вложенное в невидимые пользователю части, не было потрачено зря.

В ноябре мы представили функцию видеозаметок на sspai. Пользователи начали оставлять отзывы. Один человек, который прежде сохранял полезные кадры с помощью снимков экрана и вставлял их в другое место, после знакомства с MagicGourd написал: «Это расширение меня спасло!» Другим понравились отметки-капли на временной шкале; кто-то просил отдельные заметки или скорую поддержку Safari.

Отзывы пользователей стали одной из самых радостных частей года.

Нас радовало не только то, что продукт хвалили, но и то, что кто-то включил созданную нами вещь в свою реальную жизнь. Пользователи предлагали полезные идеи, заставляя нас снова решать: какие отзывы указывают на общую проблему, а какие связаны с личной привычкой; что нужно исправить сразу, а что, хотя и полезно, пока не должно входить в продукт.

Если разделить название продукта на две части, к концу года мы по крайней мере создали «горлянку» — сосуд для сбора, сохранения и организации моментов отклика и вдохновения.

Магия ещё не проявилась

Но это ещё не была та магия, которую мы представляли.

Она, конечно, будет использовать ИИ, но не сведётся к созданию краткого содержания статьи. Резюме может сжать информацию, не продвигая познание.

В нашем понимании информация — это содержание, которое человек получает; знание — понятая и организованная информация; познание — способ, которым человек понимает мир, создаёт связи и суждения и пересматривает их с появлением нового опыта.

Современный ИИ хорошо обрабатывает информацию и всё лучше организует знания. Он может кратко изложить статью, выделить ключевые слова и ответить на вопросы, ответы на которые уже содержатся в материале. Но если он только сжимает десять страниц до одной или добавляет окно чата рядом с приложением для заметок, он ещё не затрагивает то, что мы действительно хотим создать.

Мы хотим, чтобы будущий MagicGourd понимал записи, накопленные человеком за долгое время, и соединял моменты отклика, разбросанные по разным периодам и носителям. Он мог бы находить повторяющиеся, но никогда прямо не сформулированные темы, показывать связи и противоречия между заметками, выявлять вопросы, долго остававшиеся без ответа, или вовремя возвращать к прежней мысли.

Ещё важнее, чтобы он задавал вопросы, о которых пользователь ещё не думал, но которые стоит исследовать, помогая ему формировать собственные новые суждения.

Здесь нужна ясная граница: ИИ не может выдавать свои предположения за «истину», которую пользователь пока не осознал. Он может предложить возможные связи, противоречия и вопросы. Решать, выдерживают ли эти связи проверку, должен сам пользователь.

Магия не думает вместо пользователя. Она помогает ему увидеть мысль, которую он ещё не закончил.

В течение года мы создали несколько внутренних демо, связанных с этой идеей. Они могли создавать резюме, организовывать материалы и отвечать на вопросы. Они уже выглядели как ИИ-продукты. Но до того, что мы называли «продвижением познания», было ещё далеко, поэтому мы не стали спешно выпускать их только ради участия в волне ИИ.

Чем глубже ИИ участвует в познавательном процессе человека, тем более частные данные ему нужно видеть. Это ещё сильнее убедило нас, что приватность и владение данными — не инженерные вопросы, отдельные от магии, а условия её существования. Нельзя заявлять, что мы хотим понимать пользователей, и одновременно просить их отказаться от контроля над собственными данными.

Итак, 31 декабря 2024 года горлянка уже была, но магия ещё не проявилась.

Мы не получили инвестиций, не увидели решающего рыночного сигнала и не выстроили ясную бизнес-модель. Мы всё ещё не знали, куда в итоге приведёт эта река.

Но мы выпустили 27 версий. Пользователи начали включать продукт в свою жизнь. А мы начали понимать, как превратить работающее демо в настоящий продукт и нести за него долгосрочную ответственность.

Годом ранее я написал: «Я всё ещё в воде».

Год спустя я по-прежнему был в воде. Река не стала проще, и противоположный берег не стал яснее.

Но горлянку мы уже сделали.

Магия ещё не проявилась. До противоположного берега мы тоже не добрались. Но по крайней мере начали плыть вперёд.

Một năm đã trôi qua, tôi vẫn đang ở dưới nước.

Dòng sông không trở nên dễ vượt qua hơn, bờ bên kia cũng không rõ ràng hơn. Nhưng so với một năm trước, đã có một chút khác biệt. Nửa cuối năm 2023, sau khi rời SenseTime—nơi tôi đã làm việc gần mười năm—phần lớn thời gian của tôi là những ngày vật lộn và tìm kiếm phương hướng. Sang năm 2024, chúng tôi bắt đầu dành phần lớn thời gian để phát triển một sản phẩm cụ thể.

Mạch chính của năm nay là sản phẩm; mạch phụ là vài lần thử gọi vốn rất hạn chế. Chúng tôi không nhận được đầu tư, cũng chưa đón nhận tín hiệu thị trường nào đủ mạnh để chứng minh hướng đi, nhưng đã phát triển và đưa lên mạng 27 phiên bản.

Sau khi nhảy xuống dòng sông tiếp theo, cuối cùng chúng tôi cũng bắt đầu học cách bơi về phía trước.

Trước hết, làm ra một quả bầu

Trong bài viết cuối năm ngoái, tôi nói rằng cuối cùng mình đã quyết định bắt đầu từ ghi chú thông minh.

Từ thời trung học, tôi đã có thói quen “đọc là phải cầm bút”. Khi đọc một cuốn sách hay bài viết, hoặc xem một đoạn video, tôi chú ý đến những chỗ khiến mình rung động, đánh dấu chúng rồi ghi lại suy nghĩ nảy sinh lúc đó. Tôi gọi quá trình này là “tìm điểm”: nhận ra điều chạm đến mình và ghi lại cảm hứng.

Đôi khi những điểm ấy chỉ là một câu nói, một bức ảnh hay một khung hình. Ở thời điểm đó, chúng dường như chẳng liên quan đến nhau. Nhưng khi tích lũy đủ nhiều, vào một lúc nào đó chúng sẽ kết nối lại, giúp tôi hiểu một vấn đề hoặc hình thành một nhận định mà trước đây mình chưa từng nghĩ đến.

Trong nhiều năm, tôi đã thử nhiều công cụ ghi chú khác nhau nhưng vẫn không tìm được sản phẩm nào thật sự phù hợp với thói quen này. Sau khi rời SenseTime, tôi tìm đến người bạn nối khố từng cùng mình trèo tổ chim và đánh nhau thuở nhỏ, rồi quyết định cùng nhau làm ra nó. Trong nửa đầu năm 2024, phần lớn thời gian chúng tôi làm việc tại một không gian làm việc chung ở tòa Sohu.

Chúng tôi đặt tên sản phẩm là MagicGourd.

“Gourd” cũng là tên gọi ở nhà của con tôi. Khi đặt tên, tôi không cố ý gửi gắm quá nhiều ý nghĩa. Nhưng nhìn lại, có lẽ trong đó ẩn chứa một mong ước vô thức: tôi hy vọng sản phẩm đầu tiên mình làm sau khi toàn tâm khởi nghiệp cũng có thể lớn lên từ từ dưới sự chăm sóc của chúng tôi, giống như một đứa trẻ.

Tất nhiên, sản phẩm không phải là một đứa trẻ. Nhưng chúng có một điểm giống nhau: được tạo ra mới chỉ là khởi đầu; sự chăm sóc và trưởng thành lâu dài sau đó mới là phần thật sự khó khăn.

Bộ não thứ hai đích thực mà chúng tôi hình dung vẫn còn rất xa thực tế và không thể hoàn thành trong một bước. Vì vậy, chúng tôi quyết định trước tiên thực hiện bước căn bản nhất: cho phép người dùng dễ dàng đánh dấu điều chạm đến mình và viết lại cảm hứng khi duyệt web, đọc PDF trực tuyến hoặc xem video.

Trước hết, làm ra một quả bầu có thể chứa những điểm ấy.

Những quyết định sản phẩm phía sau một nút tô sáng

Ngay sau khi bắt đầu phát triển, chúng tôi gặp một câu hỏi tưởng như nhỏ đến mức không thể nhỏ hơn: nút tô sáng nên trông như thế nào?

Nó chỉ nên là một nút hay là một bảng gồm nhiều thao tác? Sau khi người dùng chọn văn bản, nó nên xuất hiện ngay hay chờ người dùng chủ động gọi ra? Nó nên xuất hiện ở đâu và biến mất khi nào? Nếu có người không thích nó tự động hiện lên, chúng tôi có nên cung cấp thêm một công tắc hay không?

Mỗi lựa chọn được thêm vào dường như có thể đáp ứng thêm nhu cầu, nhưng đồng thời cũng làm tăng chi phí hiểu và thao tác. Cho nút xuất hiện chủ động hơn giúp tính năng dễ được phát hiện, nhưng cũng có thể liên tục ngắt quãng việc đọc. Để nó yên lặng hơn có thể giúp người dùng tập trung, nhưng họ cũng có thể hoàn toàn không biết tính năng ấy tồn tại.

Những câu hỏi này không có một đáp án chuẩn theo nghĩa thuật toán.

Khi làm thuật toán, chúng tôi quen hỏi liệu một năng lực có thể thực hiện được không, độ chính xác có thể tăng không, hiệu năng có đạt yêu cầu không. Sau khi làm sản phẩm, chúng tôi bắt đầu liên tục tự hỏi: một tính năng nên can thiệp vào lúc nào và lúc nào nên lùi vào hậu cảnh?

Một tính năng chạy được chỉ chứng minh rằng công nghệ khả thi. Người dùng có hiểu nó hay không, có thấy bị làm phiền không, có muốn giữ nó trong đời sống hằng ngày không—những điều đó mới quyết định sản phẩm có đứng vững hay không.

Trước đây, khi làm thuật toán và các dự án lớn, tôi cũng từng xử lý rất nhiều vấn đề của thế giới thực. Nhưng khi thật sự bắt đầu từ con số không để tạo ra một sản phẩm, những quyết định từng được chia sẻ giữa các nhóm sản phẩm, thiết kế, khách hàng và kỹ thuật bỗng cùng rơi lên vai chúng tôi. Chúng tôi phải quyết định điều gì nên được nhìn thấy, điều gì nên ẩn phía sau; điều gì cần làm ngay và điều gì, dù hữu ích, cũng phải tạm thời chưa làm.

Chúng tôi dần nhận ra rằng sản phẩm không được tạo nên bởi số lượng tính năng, mà bởi vô số sự lựa chọn. Đôi khi, “không xuất hiện” và “không làm phiền” tự thân cũng là một năng lực của sản phẩm.

Sản phẩm phải đứng vững theo thời gian

Nút bấm có thuận tay hay không là trải nghiệm người dùng có thể cảm nhận ngay. Nhưng nhiều yếu tố quyết định sản phẩm có thể được sử dụng lâu dài lại nằm ở những nơi họ không nhìn thấy.

MagicGourd lưu trữ lịch sử đọc, những khoảnh khắc rung động và suy nghĩ của một người. Chúng tôi muốn bảo vệ quyền riêng tư của người dùng nhiều nhất có thể, đồng thời vẫn cung cấp đồng bộ đa thiết bị và các dịch vụ thông minh trong tương lai. Để làm được cả hai, chúng tôi chọn mã hóa dữ liệu ngay trên thiết bị và chỉ lưu bản mã ở máy chủ. Điều này làm tăng độ phức tạp của phát triển và bảo trì, nhưng nếu người dùng không thể thật sự sở hữu dữ liệu của mình, thì ngay từ đầu đã không thể nói đến một bộ não thứ hai đích thực.

Đồng bộ là một vấn đề khác trông có vẻ đơn giản nhưng thực tế rất phức tạp. Khi người dùng tạo một đoạn tô sáng, giao diện phải phản hồi ngay, không thể dừng lại chờ chỉ vì mạng kém. Ngay cả khi mạng yếu hoặc mất kết nối, việc ghi chép cũng không được gián đoạn; khi mạng trở lại, dữ liệu trên các thiết bị khác nhau phải đồng bộ chính xác, không bị trùng lặp, ghi đè lẫn nhau, càng không được âm thầm biến mất.

Điều đó buộc chúng tôi phải suy nghĩ lại cách frontend và backend phối hợp, cách cơ sở dữ liệu tổ chức dữ liệu, cách duy trì khả năng tương thích khi nâng cấp phiên bản và cách phục hồi khi xảy ra lỗi. Người dùng thường không nhìn thấy những thiết kế này, nhưng chỉ cần một mắt xích gặp sự cố, toàn bộ độ phức tạp sẽ lập tức biến thành trải nghiệm trực tiếp nhất của họ.

Trải nghiệm ngắn hạn tương đối dễ tạo ra. Làm một bản trình diễn mượt mà khiến người dùng ấn tượng trong vài phút không quá khó. Nhưng trong mắt chúng tôi, đó vẫn chỉ là một bản demo.

Một bản demo chỉ cần đứng vững trước mắt; một sản phẩm phải đứng vững theo thời gian.

Nếu một sản phẩm được kỳ vọng đồng hành với người dùng mười năm, nền móng cho trải nghiệm của mười năm sau phải được xây từ hôm nay. Với một công cụ thông thường, một lần trục trặc có thể chỉ gây bất tiện tạm thời; với một sản phẩm chứa nhiều năm ghi chú, chỉ một lần mất dữ liệu cũng đủ phá hủy toàn bộ niềm tin mà người dùng đã gây dựng.

Chúng tôi không thể hứa rằng hệ thống sẽ không bao giờ gặp vấn đề, nhưng phải coi “không làm mất dù chỉ một ghi chú của người dùng” là một trong những ràng buộc thiết kế quan trọng nhất. Trải nghiệm sản phẩm không chỉ diễn ra trên màn hình, mà còn diễn ra trong cơ sở dữ liệu mà người dùng không thể nhìn thấy.

Một mạch phụ gọi vốn rất ngắn

Gọi việc huy động vốn là mạch phụ của năm nay có lẽ còn hơi phóng đại. Tổng cộng chúng tôi chỉ tiếp xúc với ba tổ chức đầu tư; phần lớn thời gian còn lại vẫn dành cho phát triển sản phẩm.

Ý nghĩ lúc đó rất đơn giản: tìm một vài nhà đầu tư giai đoạn sớm mà chúng tôi trực tiếp hoặc gián tiếp quen biết, giới thiệu ngắn gọn việc mình đang làm và hy vọng nhận được khoản đầu tư thiên thần đầu tiên.

Ý nghĩa của khoản đầu tư ấy đối với chúng tôi không chỉ nằm ở tiền. Sản phẩm chưa hoàn thiện và chưa có tín hiệu thị trường rõ ràng; ở giai đoạn đó, chúng tôi muốn nhận trước một phản hồi bên ngoài để biết liệu hướng đi này có đứng vững trong mắt những nhà đầu tư xuất sắc hay không.

Những lần thử ấy đều không có kết quả. Khi đó, chúng tôi cho rằng môi trường gọi vốn dành cho ứng dụng AI không thuận lợi và bản thân mình cũng chưa biết cách trao đổi với nhà đầu tư. Cả hai yếu tố đều có thật. Nhưng nhìn lại, còn một sự thật trực tiếp hơn: chúng tôi dành rất ít thời gian cho gọi vốn và chỉ tiếp xúc với ba tổ chức. Thay vì nói rằng đã trải qua một vòng gọi vốn thất bại, chính xác hơn là chúng tôi chỉ có vài cuộc trao đổi ban đầu với các tổ chức đầu tư.

Điều đáng suy ngẫm hơn là phản ứng của chính mình khi đối mặt với chất vấn.

Khi tham gia phỏng vấn tại MiraclePlus, những người ngồi đối diện đều là những người tôi vô cùng kính trọng. Khi họ liên tục thách thức ý tưởng của chúng tôi, thậm chí đặt câu hỏi rất sắc, tôi nảy sinh một tâm thế phức tạp: vì chúng tôi đến để tìm kiếm đầu tư, có lẽ mình nên tôn trọng phán đoán của họ, thậm chí ở mức độ nào đó tiến gần hơn đến đáp án mà họ mong đợi.

Nhưng nếu chúng tôi muốn thông qua gọi vốn để nhận được phản hồi chân thực, thì việc chiều theo họ bằng những lời mình không thật sự tin lại chính là điều khiến phản hồi mất ý nghĩa.

Sau đó tôi cũng bắt đầu hoài nghi liệu điều mình muốn lúc ấy có thật sự chỉ là phản hồi. Có lẽ trước khi sản phẩm được thị trường kiểm chứng, chúng tôi còn muốn được một nhóm nhà đầu tư xuất sắc công nhận, qua đó xác nhận rằng mình chưa đi sai hướng.

Điều này giống như ở trong một dòng sông xa lạ và mong người trên bờ nói trước cho chúng tôi biết nên bơi về đâu. Nhưng cuối cùng, người sáng lập phải tự mình cảm nhận dòng chảy và đưa ra phán đoán dựa trên những sự thật trước mắt.

“Hai lão Xuanming” ở tòa Dongsheng

Nửa cuối năm 2024, chúng tôi chuyển từ tòa Sohu sang tòa Dongsheng.

Tôi và người bạn nối khố thường xuyên lập trình theo cặp trong thời gian dài, hay ngồi cạnh nhau nhìn vào cùng một màn hình để thảo luận. Giữa một nhóm nhà sáng lập trẻ trong không gian làm việc chung, cách làm việc này rất dễ gây chú ý. Sau một thời gian, mọi người đặt cho chúng tôi biệt danh “Hai lão Xuanming”.

Đó là một chuyện rất thú vị. Hai người từng cùng nhau trèo tổ chim và đánh nhau thuở nhỏ, hai mươi năm sau lại ngồi trong một văn phòng chung, cùng làm một sản phẩm có tên MagicGourd.

Cũng chính tại tòa Dongsheng, chúng tôi quen Kehan. Khi đó anh phụ trách cộng đồng và tuyển mộ dự án khởi nghiệp tại MiraclePlus. Lần đầu nói chuyện với chúng tôi, anh hỏi: “Hai anh là người khởi nghiệp phải không? Tôi đã quan sát hai anh khá lâu rồi. Trong cả văn phòng này, hai anh là hai người có trạng thái khởi nghiệp rõ nhất.”

Sau đó, khi biết chúng tôi từng tham gia phỏng vấn tại MiraclePlus, anh nói chuyện với chúng tôi về tình hình lúc ấy. Anh cho biết việc nhà đầu tư liên tục chất vấn một ý tưởng khởi nghiệp đôi khi không chỉ để bày tỏ phản đối, mà còn để kiểm tra xem người sáng lập có thật sự suy nghĩ thấu đáo hay không và có thể giữ vững phán đoán của mình dưới áp lực hay không.

Điều đó khiến tôi hiểu lại cuộc phỏng vấn năm ấy.

Tôn trọng nhà đầu tư không có nghĩa là giao phán đoán của mình cho họ. Người sáng lập vừa phải hiểu vì sao người khác phản đối, vừa không thể vì đối phương đáng kính mà từ bỏ phán đoán của mình. Điều thật sự cần tránh không phải là thay đổi quan điểm dựa trên sự thật mới, mà là khi còn chưa suy nghĩ thấu đáo đã thay đổi cách diễn đạt chỉ để được công nhận.

Đây cũng không chỉ là bài học trong gọi vốn. Khi làm sản phẩm, mỗi ngày chúng tôi đều đối mặt với phản hồi của người dùng, cách làm của sản phẩm cùng ngành và các xu hướng công nghệ mới. Những tín hiệu bên ngoài ấy đều đáng được tìm hiểu nghiêm túc, nhưng quyết định điều gì nên đi vào sản phẩm vẫn là trách nhiệm của chính chúng tôi.

Quả bầu đã có

Đến cuối năm 2024, MagicGourd đã phát triển và đưa lên mạng 27 phiên bản.

Chúng tôi bắt đầu từ việc chú thích văn bản và hình ảnh trên các trang web thông thường, dần hỗ trợ PDF trực tuyến rồi mở rộng cùng một phương pháp sang Bilibili và YouTube. Người dùng có thể đánh dấu một khung hình khiến mình rung động trong video, viết ghi chú và nhanh chóng quay lại những khoảnh khắc ấy trên dòng thời gian. Chúng tôi cũng lần lượt bổ sung quản lý thẻ, tìm kiếm, xuất dữ liệu và đồng bộ dữ liệu giữa các trình duyệt, thiết bị khác nhau.

Mỗi loại nội dung được thêm vào đều kéo theo rất nhiều việc thích ứng. Các trang web không có cấu trúc thống nhất, còn nền tảng video cũng liên tục thay đổi. Một tính năng hoạt động bình thường trên một trang có thể biểu hiện hoàn toàn khác khi chuyển sang trang hay trình duyệt khác. Rất nhiều thời gian của chúng tôi không được dùng để tạo ra một năng lực mới dễ thấy, mà để xử lý đủ loại trường hợp biên, giúp những năng lực hiện có hoạt động ổn định hơn.

Trong 27 phiên bản liên tục được phát hành trong năm, chúng tôi không phát hiện trường hợp dữ liệu người dùng bị mất hoặc hư hỏng. Những sự cố thỉnh thoảng xuất hiện chủ yếu tập trung ở các khâu dịch vụ như mã xác minh đăng nhập; sau khi nhận phản hồi, phần lớn chúng tôi đều có thể nhanh chóng xác định và giải quyết. Điều này không chứng minh rằng từ nay hệ thống sẽ không bao giờ sai, nhưng ít nhất cho thấy thời gian chúng tôi đầu tư vào những nơi vô hình không hề lãng phí.

Tháng 11, chúng tôi giới thiệu tính năng ghi chú video trên sspai. Sau khi bài viết được đăng, người dùng dần để lại phản hồi trong phần bình luận. Trước đây, có người muốn lưu một khung hình cần thiết trong video chỉ có thể chụp màn hình rồi dán sang nơi khác; sau khi dùng MagicGourd, họ viết: “Plugin này cứu tôi rồi!” Có người thích các dấu hình giọt nước trên dòng thời gian video, cũng có người hy vọng chúng tôi bổ sung ghi chú độc lập hoặc sớm hỗ trợ Safari.

Nhận được phản hồi của người dùng là một trong những điều khiến chúng tôi vui nhất trong năm.

Điều thật sự khiến chúng tôi vui không chỉ là sản phẩm được khen ngợi, mà là cuối cùng đã có người đưa thứ chúng tôi làm ra vào đời sống thật của họ. Họ cũng đưa ra nhiều đề xuất hữu ích, thúc đẩy chúng tôi tiếp tục phán đoán: ý kiến nào phản ánh một vấn đề chung, ý kiến nào xuất phát từ thói quen sử dụng cá nhân; điều gì nên giải quyết ngay, điều gì tuy hữu ích nhưng chưa phù hợp để đưa vào sản phẩm ở giai đoạn hiện tại.

Nếu tách tên sản phẩm thành hai nửa, đến cuối năm nay, ít nhất chúng tôi đã làm ra được “quả bầu”: một vật chứa có thể thu thập, lưu giữ và quản lý những khoảnh khắc rung động cùng cảm hứng.

Phép màu vẫn chưa xuất hiện

Nhưng đó vẫn chưa phải là phép màu mà chúng tôi hình dung.

Nó chắc chắn sẽ sử dụng AI, nhưng tuyệt đối không chỉ là tạo bản tóm tắt cho một bài viết. Tóm tắt có thể nén thông tin, nhưng không nhất thiết thúc đẩy nhận thức.

Theo cách hiểu của chúng tôi, thông tin là nội dung một người tiếp nhận; tri thức là thông tin đã được hiểu và tổ chức; còn nhận thức là cách một người hiểu thế giới, thiết lập liên hệ, hình thành phán đoán và điều chỉnh chúng khi trải nghiệm mới xuất hiện.

AI ngày nay rất giỏi xử lý thông tin và ngày càng giỏi tổ chức tri thức. Nó có thể tóm tắt bài viết, trích xuất từ khóa và trả lời những câu hỏi đã có sẵn trong nội dung. Nhưng nếu nó chỉ nén mười trang chữ thành một trang hoặc thêm một khung trò chuyện bên cạnh phần mềm ghi chú, thì nó vẫn chưa chạm tới điều chúng tôi thật sự muốn làm.

Chúng tôi hy vọng MagicGourd trong tương lai có thể hiểu những ghi chép một người tích lũy trong thời gian dài, để những rung động rải rác ở các thời điểm và phương tiện khác nhau gặp lại nhau. Nó có thể phát hiện những chủ đề lặp đi lặp lại nhưng chưa bao giờ được diễn đạt rõ ràng, trình bày các mối liên hệ và mâu thuẫn giữa những ghi chú, tìm ra những câu hỏi lâu nay chưa được trả lời, hoặc đánh thức một suy nghĩ cũ vào đúng thời điểm.

Quan trọng hơn, nó nên đặt ra những câu hỏi người dùng chưa từng nghĩ đến nhưng đáng để tiếp tục truy vấn, qua đó giúp họ hình thành nhận định mới của riêng mình.

Ở đây phải có một ranh giới rõ ràng: AI không thể đóng gói suy đoán của nó thành một “sự thật” mà người dùng chưa nhận ra. Điều nó có thể làm là đề xuất những mối liên hệ, mâu thuẫn và câu hỏi có thể tồn tại; còn các mối liên hệ ấy có đứng vững hay không cuối cùng vẫn phải do người dùng phán đoán.

Phép màu không phải là suy nghĩ thay cho người dùng, mà là giúp họ nhìn thấy phần suy nghĩ mình còn chưa hoàn tất.

Trong năm nay, chúng tôi đã làm một số bản demo nội bộ liên quan đến ý tưởng này. Chúng có thể tạo bản tóm tắt, sắp xếp nội dung và trả lời câu hỏi; nhìn qua đã mang dáng dấp của AI. Nhưng chúng vẫn còn rất xa điều chúng tôi gọi là “thúc đẩy nhận thức”, nên chúng tôi không vội vàng đưa lên mạng chỉ để theo kịp làn sóng AI.

AI càng tham gia sâu vào quá trình nhận thức của một người, dữ liệu mà nó cần tiếp cận càng riêng tư. Điều này càng khiến chúng tôi tin chắc rằng quyền riêng tư và quyền sở hữu dữ liệu không phải là vấn đề kỹ thuật nằm ngoài phép màu, mà là tiền đề để phép màu có thể tồn tại. Chúng tôi không thể vừa tuyên bố muốn hiểu người dùng, vừa yêu cầu họ từ bỏ quyền kiểm soát dữ liệu của chính mình.

Vì vậy, đến ngày 31 tháng 12 năm 2024, quả bầu đã có, nhưng phép màu vẫn chưa xuất hiện.

Chúng tôi chưa nhận được đầu tư, chưa có tín hiệu thị trường mang tính quyết định, cũng chưa xây dựng được mô hình kinh doanh rõ ràng. Chúng tôi vẫn không biết cuối cùng dòng sông này sẽ chảy về đâu.

Nhưng chúng tôi đã đưa lên mạng 27 phiên bản, bắt đầu có người dùng đưa sản phẩm vào cuộc sống của họ, và cũng bắt đầu hiểu cách biến một bản demo có thể chạy thành một sản phẩm đích thực để chịu trách nhiệm lâu dài với nó.

Một năm trước, tôi đã viết: “Lúc này, tôi vẫn đang ở dưới nước.”

Một năm sau, tôi vẫn đang ở dưới nước. Dòng sông không trở nên dễ vượt qua hơn, bờ bên kia cũng không rõ ràng hơn.

Nhưng chúng tôi đã làm ra quả bầu.

Phép màu vẫn chưa xuất hiện. Chúng tôi cũng chưa đến được bờ bên kia, nhưng ít nhất đã bắt đầu bơi về phía trước.

一年过去，我仍然在水里。

河流没有变得更简单，对岸也没有变得更清晰。但和一年前相比，已经有了一点不同。2023 年下半年，我刚刚离开工作近十年的商汤，大部分时间都在挣扎和寻找方向；到了 2024 年，我们开始把大部分时间用来开发一个具体的产品。

这一年的主线是产品，支线是几次很有限的融资尝试。我们没有获得投资，也没有等来一个足以证明方向的市场信号，但先后开发并上线了 27 个版本。

跳进下一条河以后，我们终于开始学着往前游。

先做一只葫芦

在去年底那篇文章里，我写到自己最终决定从智能笔记开始。

我从中学起就有“不动笔墨不读书”的习惯。读一本书或一篇文章、看一段视频时，我会留意那些让自己产生触动的地方，把它们标记下来，再记录当时产生的想法。我把这个过程叫作“找点”：觉察触动，记录灵感。

这些点有时只是一句话、一张图片或者一个画面，当下看起来彼此没有关系。但积累得足够多以后，它们会在某个时刻连接起来，帮助我理解一个问题，或者形成一个此前没有想到的判断。

过去很多年，我尝试过不同的笔记工具，却始终没有找到一个真正适合这种习惯的产品。离开商汤以后，我找到从小一起掏鸟窝、打架的发小，决定一起把它做出来。2024 年上半年，我们大部分时间都在搜狐大厦的一处共享办公区里工作。

我们给产品取名“魔法葫芦”。

“葫芦”也是我孩子的乳名。起这个名字时，我没有刻意赋予它太多含义。后来回头看，其中也许藏着一种潜意识里的期待：我希望全职创业后做出的第一个产品，也能像一个孩子一样，在我们的照料下慢慢长大。

产品当然不是孩子。但它们有一点相似：被创造出来只是开始，此后漫长的照料和成长才是真正困难的部分。

我们心目中真正的第二大脑离现实还很远，不可能一步完成。于是决定先实现最基本的一步：让用户在浏览网页、阅读在线 PDF 或者观看视频时，可以随手标记触动，写下灵感。

先做一只能够收集这些点的葫芦。

一个高亮按钮背后的产品判断

开始开发以后，我们很快遇到了一个看起来小得不能再小的问题：高亮按钮应该长什么样？

它应该只是一个按钮，还是一个包含多个操作的面板？用户选中文字以后，它应该马上出现，还是等用户主动唤起？它应该出现在什么位置，什么时候又应该消失？如果有人不喜欢它自动出现，我们是否应该再提供一个开关？

每增加一个选项，似乎都能满足更多需求，却也会增加理解和操作的成本。让按钮更主动地出现，能够使功能更容易被发现，也可能不断打断阅读。让它安静一些，用户或许更专注，却又可能根本不知道这个功能存在。

这些问题没有算法意义上的标准答案。

做算法时，我们习惯问一种能力能不能实现，准确率能不能提高，性能能不能达到要求。做产品以后，我们开始反复追问：一个功能应该在什么时候介入，又应该在什么时候退到幕后？

一个功能能够运行，只能说明技术成立。用户能否理解它，是否感到被打扰，愿不愿意把它留在自己的日常生活里，才决定产品是否成立。

过去做算法和大型项目时，我也处理过大量面向真实世界的问题。但当我们真正从零开始创造一款产品，这些过去由产品、设计、客户和工程团队共同承担的产品判断，突然都落到了我们自己身上。我们必须决定什么应该被看见，什么应该藏在背后；什么现在就做，什么即使有用也暂时不做。

我们逐渐发现，产品不是由功能数量构成的，而是由无数取舍构成的。有时，“不出现”和“不打扰”本身也是一种产品能力。

产品要在时间里成立

按钮是否顺手，是用户当下能够感知的体验。但决定产品能否被长期使用的更多因素，却藏在用户看不见的地方。

魔法葫芦保存的是一个人的阅读记录、触动和想法。我们希望尽可能保护用户隐私，又要提供跨设备同步和未来的智能服务。为了同时做到这两件事，我们选择让数据在本地加密，后端只保存密文。这增加了开发和维护的复杂度，但如果用户不能真正拥有自己的数据，真正的第二大脑从一开始就无从谈起。

同步是另一个看起来简单、实际很复杂的问题。用户创建一条高亮时，界面应该立即响应，不能因为网络不好而停在那里等待。即使处于弱网或者断网环境，记录也不应该中断；网络恢复以后，不同设备上的数据还要正确同步，不能重复、相互覆盖，更不能悄悄消失。

这要求我们重新考虑前端和后端怎样协作，数据库怎样组织数据，版本升级时怎样保持兼容，出现异常以后又怎样恢复。用户通常不会看到这些设计，但只要其中一个环节出了问题，所有复杂性都会在一瞬间变成最直接的用户体验。

短期的体验相对容易做到。做出一个流畅的演示，让用户在几分钟内觉得惊艳，并没有那么难。但在我们眼里，那仍然只是一个 Demo。

一个 Demo 只需要在眼前成立，一个产品却要在时间里成立。

如果一款产品准备陪伴用户十年，那么支撑十年后体验的基础，也必须从今天开始建设。对一款普通工具来说，一次故障也许只是暂时的不便；对一个积累了多年笔记的产品来说，一次数据丢失就足以摧毁用户建立起来的全部信任。

我们无法承诺系统永远不会出现问题，但必须把“不丢失一条用户笔记”当作最重要的设计约束之一。产品体验不只发生在屏幕上，也发生在用户看不见的数据库里。

一条很短的融资支线

说融资是这一年的支线，甚至都有些夸张。我们总共只接触了三家投资机构，其余大部分时间仍然在开发产品。

当时我们的想法很简单：找一些直接或者间接认识的早期投资人，向他们介绍正在做的事情，希望获得第一笔天使投资。

这笔投资对我们的意义不只在于钱。产品还没有做成，也没有出现明确的市场信号，我们希望在这个阶段先获得一种外部反馈，知道这个方向在优秀的投资人眼中是否成立。

这几次尝试都没有结果。当时我们会把原因归结为 AI 应用的融资环境不够好，自己也还不太会和投资人交流。这些因素都存在，但现在回头看，还有一个更直接的事实：我们在融资上投入的时间很少，也只接触了三家机构。与其说我们经历了一轮融资失败，不如说只是和投资机构做过几次初步接触。

更值得反思的是自己面对质疑时的反应。

参加奇绩创坛的面试时，坐在我对面的是一些我非常尊敬的人。当他们连续挑战我们的想法，甚至把问题说得很尖锐时，我会产生一种复杂的心态：既然是来寻求投资，就应该尊重他们的判断，甚至在某种程度上靠近他们期待的答案。

但如果我们希望通过融资获得真实反馈，言不由衷的迎合恰恰会让反馈失去意义。

后来我也开始怀疑，当时想要的是否真的只是反馈。也许在产品还没有得到市场验证以前，我们还希望先得到一群优秀投资人的认可，以此确认自己没有走错。

这很像在一条陌生的河里，希望岸上的人先告诉我们应该往哪里游。但创业者最终必须亲自感受水流，并依据眼前的事实作出判断。

东升大厦的“玄冥二佬”

2024 年下半年，我们从搜狐大厦搬到了东升大厦。

我和发小长期结对开发，经常坐在一起盯着同一块屏幕讨论。在共享办公区的一群年轻创业者中，这种工作方式非常显眼。时间久了，大家给我们起了一个外号：“玄冥二佬”。

这是一件很好玩的事情。两个从小一起掏鸟窝、打架的人，二十年以后又坐在共享办公室里，一起做一款叫作魔法葫芦的产品。

也正是在东升大厦，我们认识了科含。他当时在奇绩创坛负责社区和创业项目招募。第一次和我们说话时，他问：“你们是创业者吧？我观察你们很久了。整个办公室里，你们两个特别有创业的状态。”

后来他知道我们参加过奇绩创坛的面试，就聊起了当时的情况。他告诉我们，投资人连续质疑一个创业想法，有时并不只是为了表达反对，也是在测试创业者是否真正想清楚了这件事，是否能在压力下保持自己的判断。

这让我重新理解了当时的面试。

尊重投资人，不等于把判断交给投资人。创业者既要听懂别人为什么反对，也不能因为对方值得尊敬，就放弃自己的判断。真正需要避免的不是依据新的事实改变观点，而是在还没有想清楚以前，仅仅为了获得认可而改变表达。

这也不只是融资中的功课。做产品时，我们每天都会面对用户反馈、同行产品的做法和新的技术潮流。这些外部信号都值得认真理解，但决定什么应该进入产品，仍然是我们自己的责任。

葫芦已经有了

到了 2024 年年底，魔法葫芦已经开发并上线了 27 个版本。

我们从普通网页的文字和图片批注开始，逐渐支持在线 PDF，又把同一套方法扩展到 Bilibili 和 YouTube。用户可以在视频中标记一个触动自己的画面，写下笔记，并在时间线上快速回到那些时刻。我们也陆续加入标签管理、搜索和导出，在不同浏览器和设备之间同步数据。

每增加一种内容形态，都意味着大量新的适配。网页没有统一的结构，视频平台也会不断变化。一个在某个网站上工作正常的功能，换一个页面或者浏览器，表现就可能完全不同。很多时间并没有用来创造一个显眼的新能力，而是在处理各种边界，让已经存在的能力更稳定地工作。

在这一年连续上线的 27 个版本中，我们没有发现用户数据丢失或损坏的问题。偶尔出现的故障主要集中在登录验证码等服务环节；收到反馈后，我们大多能很快定位并解决。这不能证明系统从此不会出错，却至少说明，我们在那些看不见的地方投入的时间没有白费。

11 月，我们在少数派介绍了视频笔记功能。文章发布以后，评论区陆续有用户留下反馈。有人过去看到视频里需要保存的画面，只能先截图再粘贴，使用魔法葫芦以后留言说：“这个插件救命了！”有人喜欢视频时间线上的水滴标记，也有人希望我们增加独立笔记，或者尽快支持 Safari。

收到用户反馈，是这一年里最让我们快乐的事情之一。

真正让我们高兴的，不只是别人夸奖了产品，而是终于有人把我们做出来的东西放进了自己的真实生活。他们也会提出许多有用的建议，促使我们继续判断：哪些意见代表一个共同问题，哪些来自个别的使用习惯；哪些应该马上解决，哪些虽然有用，却不适合在当前阶段进入产品。

如果把产品的名字拆成两半，到这一年年底，我们至少已经做出了“葫芦”：一个能够收集、保存和管理触动与灵感的容器。

魔法还没有显现

但这还不是我们心目中的魔法。

它当然会使用 AI，却绝不只是为一篇文章生成摘要。摘要可以压缩信息，却不一定能够推进认知。

在我们的理解里，信息是一个人接收到的内容，知识是经过理解和组织的信息，认知则是一个人理解世界、建立联系、形成判断，并在新经验到来时修正自己的方式。

今天的 AI 很擅长处理信息，也越来越善于整理知识。它可以总结文章、提取关键词、回答内容中已经存在的问题。但如果它只是把十页文字压缩成一页，或者在笔记软件旁边增加一个聊天框，它仍然没有触及我们真正想做的事情。

我们希望未来的魔法葫芦能够理解一个人长期积累的记录，让散落在不同时间、不同媒介里的触动重新相遇。它也许能发现反复出现、却从未被明确表达的主题，呈现不同笔记之间的联系和矛盾，找出长期没有回答的问题，或者在合适的时候重新唤起一段过去的思考。

更重要的是，它应该提出用户尚未想到、但值得继续追问的问题，帮助用户形成自己的新判断。

这里必须有一条清楚的边界：AI 不能把自己的推测包装成用户尚未意识到的“真相”。它能做的是提出可能存在的联系、矛盾和问题，至于这些联系是否成立，最终仍然要由用户判断。

魔法不是替用户思考，而是帮助用户看见自己尚未完成的思考。

这一年，我们在内部做过一些相关的 Demo。它们能够生成摘要、整理内容，也能够回答问题，看起来已经有了一些 AI 的样子。但距离我们所说的“推进认知”仍然很远，所以没有为了赶上 AI 的热潮而草率上线。

AI 越深入地参与一个人的认知过程，它需要接触的数据就越私密。这也让我们更加确信，隐私和数据所有权不是魔法之外的工程问题，而是魔法能否成立的前提。我们不能一边声称要理解用户，一边要求用户放弃对自己数据的控制。

所以，到了 2024 年 12 月 31 日，葫芦已经有了，魔法还没有显现。

我们没有拿到投资，没有得到决定性的市场信号，也还没有建立清晰的商业模式。我们仍然不知道这条河最终会流向哪里。

但我们上线了 27 个版本，开始有用户把产品放进自己的生活，也开始理解怎样把一个能够运行的 Demo 变成一款真正的产品，并为它长期负责。

一年前，我写道：“我现在还在水里。”

一年以后，我仍然在水里。河流没有变得更简单，对岸也没有变得更清晰。

但我们已经做出了葫芦。

魔法还没有显现。我们也还没有到达对岸，但至少，已经开始往前游。

一年過去，我仍然在水裡。

河流沒有變得更簡單，對岸也沒有變得更清晰。但和一年前相比，已經有了一點不同。2023 年下半年，我剛剛離開工作近十年的商湯，大部分時間都在掙扎和尋找方向；到了 2024 年，我們開始把大部分時間用來開發一個具體的產品。

這一年的主線是產品，支線是幾次很有限的融資嘗試。我們沒有獲得投資，也沒有等來一個足以證明方向的市場訊號，但先後開發並上線了 27 個版本。

跳進下一條河以後，我們終於開始學著往前游。

先做一隻葫蘆

在去年底那篇文章裡，我寫到自己最終決定從智慧筆記開始。

我從中學起就有「不動筆墨不讀書」的習慣。讀一本書或一篇文章、看一段影片時，我會留意那些讓自己產生觸動的地方，把它們標記下來，再記錄當時產生的想法。我把這個過程叫作「找點」：覺察觸動，記錄靈感。

這些點有時只是一句話、一張圖片或一個畫面，當下看起來彼此沒有關係。但累積得足夠多以後，它們會在某個時刻連接起來，幫助我理解一個問題，或形成一個此前沒有想到的判斷。

過去很多年，我嘗試過不同的筆記工具，卻始終沒有找到一個真正適合這種習慣的產品。離開商湯以後，我找到從小一起掏鳥窩、打架的髮小，決定一起把它做出來。2024 年上半年，我們大部分時間都在搜狐大廈的一處共享辦公區裡工作。

我們給產品取名「魔法葫蘆」。

「葫蘆」也是我孩子的乳名。起這個名字時，我沒有刻意賦予它太多含義。後來回頭看，其中也許藏著一種潛意識裡的期待：我希望全職創業後做出的第一個產品，也能像一個孩子一樣，在我們的照料下慢慢長大。

產品當然不是孩子。但它們有一點相似：被創造出來只是開始，此後漫長的照料和成長才是真正困難的部分。

我們心目中真正的第二大腦離現實還很遠，不可能一步完成。於是決定先實現最基本的一步：讓使用者在瀏覽網頁、閱讀線上 PDF 或觀看影片時，可以隨手標記觸動，寫下靈感。

先做一隻能夠收集這些點的葫蘆。

一個醒目標示按鈕背後的產品判斷

開始開發以後，我們很快遇到了一個看起來小得不能再小的問題：醒目標示按鈕應該長什麼樣？

它應該只是一個按鈕，還是一個包含多個操作的面板？使用者選取文字以後，它應該馬上出現，還是等使用者主動喚起？它應該出現在什麼位置，什麼時候又應該消失？如果有人不喜歡它自動出現，我們是否應該再提供一個開關？

每增加一個選項，似乎都能滿足更多需求，卻也會增加理解和操作的成本。讓按鈕更主動地出現，能使功能更容易被發現，也可能不斷打斷閱讀。讓它安靜一些，使用者或許更專注，卻又可能根本不知道這個功能存在。

這些問題沒有演算法意義上的標準答案。

做演算法時，我們習慣問一種能力能不能實現，準確率能不能提高，效能能不能達到要求。做產品以後，我們開始反覆追問：一個功能應該在什麼時候介入，又應該在什麼時候退到幕後？

一個功能能夠運作，只能說明技術成立。使用者能否理解它，是否感到被打擾，願不願意把它留在自己的日常生活裡，才決定產品是否成立。

過去做演算法和大型專案時，我也處理過大量面向真實世界的問題。但當我們真正從零開始創造一款產品，這些過去由產品、設計、客戶和工程團隊共同承擔的產品判斷，突然都落到了我們自己身上。我們必須決定什麼應該被看見，什麼應該藏在背後；什麼現在就做，什麼即使有用也暫時不做。

我們逐漸發現，產品不是由功能數量構成的，而是由無數取捨構成的。有時，「不出現」和「不打擾」本身也是一種產品能力。

產品要在時間裡成立

按鈕是否順手，是使用者當下能夠感知的體驗。但決定產品能否被長期使用的更多因素，卻藏在使用者看不見的地方。

魔法葫蘆保存的是一個人的閱讀記錄、觸動和想法。我們希望盡可能保護使用者隱私，又要提供跨裝置同步和未來的智慧服務。為了同時做到這兩件事，我們選擇讓資料在本地加密，後端只保存密文。這增加了開發和維護的複雜度，但如果使用者不能真正擁有自己的資料，真正的第二大腦從一開始就無從談起。

同步是另一個看起來簡單、實際很複雜的問題。使用者建立一條醒目標示時，介面應該立即回應，不能因為網路不好而停在那裡等待。即使處於弱網或離線環境，記錄也不應該中斷；網路恢復以後，不同裝置上的資料還要正確同步，不能重複、相互覆蓋，更不能悄悄消失。

這要求我們重新考慮前端和後端如何協作，資料庫如何組織資料，版本升級時如何保持相容，出現異常以後又如何恢復。使用者通常不會看到這些設計，但只要其中一個環節出了問題，所有複雜性都會在一瞬間變成最直接的使用者體驗。

短期的體驗相對容易做到。做出一個流暢的展示，讓使用者在幾分鐘內覺得驚豔，並沒有那麼難。但在我們眼裡，那仍然只是一個 Demo。

一個 Demo 只需要在眼前成立，一個產品卻要在時間裡成立。

如果一款產品準備陪伴使用者十年，那麼支撐十年後體驗的基礎，也必須從今天開始建設。對一款普通工具來說，一次故障也許只是暫時的不便；對一個累積了多年筆記的產品來說，一次資料遺失就足以摧毀使用者建立起來的全部信任。

我們無法承諾系統永遠不會出現問題，但必須把「不遺失一條使用者筆記」當作最重要的設計約束之一。產品體驗不只發生在螢幕上，也發生在使用者看不見的資料庫裡。

一條很短的融資支線

說融資是這一年的支線，甚至都有些誇張。我們總共只接觸了三家投資機構，其餘大部分時間仍然在開發產品。

當時我們的想法很簡單：找一些直接或間接認識的早期投資人，向他們介紹正在做的事情，希望獲得第一筆天使投資。

這筆投資對我們的意義不只在於錢。產品還沒有做成，也沒有出現明確的市場訊號，我們希望在這個階段先獲得一種外部回饋，知道這個方向在優秀的投資人眼中是否成立。

這幾次嘗試都沒有結果。當時我們會把原因歸結為 AI 應用的融資環境不夠好，自己也還不太會和投資人交流。這些因素都存在，但現在回頭看，還有一個更直接的事實：我們在融資上投入的時間很少，也只接觸了三家機構。與其說我們經歷了一輪融資失敗，不如說只是和投資機構做過幾次初步接觸。

更值得反思的是自己面對質疑時的反應。

參加奇績創壇的面試時，坐在我對面的是一些我非常尊敬的人。當他們連續挑戰我們的想法，甚至把問題說得很尖銳時，我會產生一種複雜的心態：既然是來尋求投資，就應該尊重他們的判斷，甚至在某種程度上靠近他們期待的答案。

但如果我們希望透過融資獲得真實回饋，言不由衷的迎合恰恰會讓回饋失去意義。

後來我也開始懷疑，當時想要的是否真的只是回饋。也許在產品還沒有得到市場驗證以前，我們還希望先得到一群優秀投資人的認可，以此確認自己沒有走錯。

這很像在一條陌生的河裡，希望岸上的人先告訴我們應該往哪裡游。但創業者最終必須親自感受水流，並依據眼前的事實作出判斷。

東升大廈的「玄冥二佬」

2024 年下半年，我們從搜狐大廈搬到了東升大廈。

我和髮小長期結對開發，經常坐在一起盯著同一塊螢幕討論。在共享辦公區的一群年輕創業者中，這種工作方式非常顯眼。時間久了，大家給我們起了一個外號：「玄冥二佬」。

這是一件很好玩的事情。兩個從小一起掏鳥窩、打架的人，二十年以後又坐在共享辦公室裡，一起做一款叫作魔法葫蘆的產品。

也正是在東升大廈，我們認識了科含。他當時在奇績創壇負責社群和創業專案招募。第一次和我們說話時，他問：「你們是創業者吧？我觀察你們很久了。整個辦公室裡，你們兩個特別有創業的狀態。」

後來他知道我們參加過奇績創壇的面試，就聊起了當時的情況。他告訴我們，投資人連續質疑一個創業想法，有時並不只是為了表達反對，也是在測試創業者是否真正想清楚了這件事，是否能在壓力下保持自己的判斷。

這讓我重新理解了當時的面試。

尊重投資人，不等於把判斷交給投資人。創業者既要聽懂別人為什麼反對，也不能因為對方值得尊敬，就放棄自己的判斷。真正需要避免的不是依據新的事實改變觀點，而是在還沒有想清楚以前，僅僅為了獲得認可而改變表達。

這也不只是融資中的功課。做產品時，我們每天都會面對使用者回饋、同業產品的做法和新的技術潮流。這些外部訊號都值得認真理解，但決定什麼應該進入產品，仍然是我們自己的責任。

葫蘆已經有了

到了 2024 年年底，魔法葫蘆已經開發並上線了 27 個版本。

我們從普通網頁的文字和圖片批註開始，逐漸支援線上 PDF，又把同一套方法擴展到 Bilibili 和 YouTube。使用者可以在影片中標記一個觸動自己的畫面，寫下筆記，並在時間軸上快速回到那些時刻。我們也陸續加入標籤管理、搜尋和匯出，在不同瀏覽器和裝置之間同步資料。

每增加一種內容形態，都意味著大量新的適配。網頁沒有統一的結構，影片平台也會不斷變化。一個在某個網站上運作正常的功能，換一個頁面或瀏覽器，表現就可能完全不同。很多時間並沒有用來創造一個顯眼的新能力，而是在處理各種邊界，讓已經存在的能力更穩定地運作。

在這一年連續上線的 27 個版本中，我們沒有發現使用者資料遺失或損壞的問題。偶爾出現的故障主要集中在登入驗證碼等服務環節；收到回饋後，我們大多能很快定位並解決。這不能證明系統從此不會出錯，卻至少說明，我們在那些看不見的地方投入的時間沒有白費。

11 月，我們在少數派介紹了影片筆記功能。文章發布以後，留言區陸續有使用者留下回饋。有人過去看到影片裡需要保存的畫面，只能先截圖再貼上，使用魔法葫蘆以後留言說：「這個外掛救了我！」有人喜歡影片時間軸上的水滴標記，也有人希望我們增加獨立筆記，或盡快支援 Safari。

收到使用者回饋，是這一年裡最讓我們快樂的事情之一。

真正讓我們高興的，不只是別人稱讚了產品，而是終於有人把我們做出來的東西放進了自己的真實生活。他們也會提出許多有用的建議，促使我們繼續判斷：哪些意見代表一個共同問題，哪些來自個別的使用習慣；哪些應該馬上解決，哪些雖然有用，卻不適合在目前階段進入產品。

如果把產品的名字拆成兩半，到這一年年底，我們至少已經做出了「葫蘆」：一個能夠收集、保存和管理觸動與靈感的容器。

魔法還沒有顯現

但這還不是我們心目中的魔法。

它當然會使用 AI，卻絕不只是為一篇文章生成摘要。摘要可以壓縮資訊，卻不一定能夠推進認知。

在我們的理解裡，資訊是一個人接收到的內容，知識是經過理解和組織的資訊，認知則是一個人理解世界、建立聯繫、形成判斷，並在新經驗到來時修正自己的方式。

今天的 AI 很擅長處理資訊，也越來越善於整理知識。它可以總結文章、提取關鍵字、回答內容中已經存在的問題。但如果它只是把十頁文字壓縮成一頁，或在筆記軟體旁邊增加一個聊天框，它仍然沒有觸及我們真正想做的事情。

我們希望未來的魔法葫蘆能夠理解一個人長期累積的記錄，讓散落在不同時間、不同媒介裡的觸動重新相遇。它也許能發現反覆出現、卻從未被明確表達的主題，呈現不同筆記之間的聯繫和矛盾，找出長期沒有回答的問題，或在合適的時候重新喚起一段過去的思考。

更重要的是，它應該提出使用者尚未想到、但值得繼續追問的問題，幫助使用者形成自己的新判斷。

這裡必須有一條清楚的邊界：AI 不能把自己的推測包裝成使用者尚未意識到的「真相」。它能做的是提出可能存在的聯繫、矛盾和問題，至於這些聯繫是否成立，最終仍然要由使用者判斷。

魔法不是替使用者思考，而是幫助使用者看見自己尚未完成的思考。

這一年，我們在內部做過一些相關的 Demo。它們能夠生成摘要、整理內容，也能夠回答問題，看起來已經有了一些 AI 的樣子。但距離我們所說的「推進認知」仍然很遠，所以沒有為了趕上 AI 的熱潮而草率上線。

AI 越深入地參與一個人的認知過程，它需要接觸的資料就越私密。這也讓我們更加確信，隱私和資料所有權不是魔法之外的工程問題，而是魔法能否成立的前提。我們不能一邊聲稱要理解使用者，一邊要求使用者放棄對自己資料的控制。

所以，到了 2024 年 12 月 31 日，葫蘆已經有了，魔法還沒有顯現。

我們沒有拿到投資，沒有得到決定性的市場訊號，也還沒有建立清晰的商業模式。我們仍然不知道這條河最終會流向哪裡。

但我們上線了 27 個版本，開始有使用者把產品放進自己的生活，也開始理解如何把一個能夠運作的 Demo 變成一款真正的產品，並為它長期負責。

一年前，我寫道：「我現在還在水裡。」

一年以後，我仍然在水裡。河流沒有變得更簡單，對岸也沒有變得更清晰。

但我們已經做出了葫蘆。

魔法還沒有顯現。我們也還沒有到達對岸，但至少，已經開始往前游。

Als ich ging, hatte ich weder ein validiertes Produkt noch einen vollständigen Geschäftsplan. Ich wusste nicht einmal genau, was ich tun würde.

Aber ich wusste, dass für mich wieder die Zeit gekommen war, in den nächsten Fluss zu springen.

Es war nicht das erste Mal, dass ich den Fluss wechselte. Aber zum ersten Mal musste ich dafür ein Unternehmen verlassen.

Eine Entscheidung, die ich immer wieder treffe

Von einer ländlichen Grundschule wechselte ich auf eine Mittelschule in der Kreisstadt. Später studierte ich an der Universität Nanjing und absolvierte mein Aufbaustudium an der Tsinghua-Universität. Währenddessen schloss ich mich SenseTime an, das gerade erst begonnen hatte. Dort gründete ich zuerst das Team für Lebenderkennung und später das Team für industrielle Bildverarbeitung.

Rückblickend scheint eine solche Veränderung alle paar Jahre einzutreten.

Diese Veränderungen waren kein vorab entworfener Lebensplan. Sie geschahen auch nicht, weil die bisherige Arbeit ihre Bedeutung verloren hatte. Nach jahrelangem Einsatz waren das Gebiet und ich einfach allmählich gereift. Die Arbeit war nicht unbedingt beendet, aber sie zwang mich nicht mehr dazu, meine eigenen Grenzen zu überschreiten.

Für viele Menschen wäre das ein Idealzustand. Mich macht er unruhig. Ich mag kein Leben, dessen Ende ich von meinem Standort aus schon sehen kann. Deshalb muss ich mich von Zeit zu Zeit in ein Problem versetzen, das ich nicht lösen kann — manchmal eines, bei dem ich nicht einmal weiß, wo ich anfangen soll.

Der „Fluss“ ist hier kein Unternehmen. Den Fluss zu wechseln bedeutet auch nicht zwingend zu kündigen. Er steht für ein Gebiet, das ich neu lernen muss, für eine schwierige Sache, die ich noch nicht zu verwirklichen weiß. In meinen fast zehn Jahren bei SenseTime sprang ich nacheinander in zwei verschiedene Flüsse.

Aber ich bin niemand, der nur der Veränderung nachjagt. In mir wirkt noch eine andere, fast entgegengesetzte Kraft: Verantwortungsgefühl.

Ich hasse es, Dinge auf halbem Weg aufzugeben. Wenn ich mich für etwas entscheide, möchte ich es wirklich und gut zu Ende bringen. Die eine Kraft lässt mich nach dem nächsten Fluss suchen; die andere hält mich im bisherigen fest, damit ich vollende, was ich begonnen habe.

Mein Weggang in diesem Jahr war das Ergebnis eines langen Kampfes zwischen diesen beiden Kräften.

Algorithmen in die reale Welt bringen

Als ich zu SenseTime kam, arbeitete ich in der Forschungsabteilung. Mein Interesse galt jedoch immer den Anwendungen. Ich wollte nicht nur wissen, ob ein Algorithmus mit experimentellen Daten funktionierte, sondern ob er in die reale Welt eintreten und ein konkretes Problem lösen konnte.

Die Lebenderkennung war ein Kernstück des ersten großen Einsatzprojekts von SenseTime. Zuvor hatten wir bereits einige gute Demos zur Gesichtserkennung. Doch als wir mit einer wirklich groß angelegten Anwendung konfrontiert waren, stellten wir fest, dass viele Produktionsprobleme ungelöst waren — besonders die Angriffe auf das Onlinesystem.

Das System verzeichnete täglich mehr als eine Million Zugriffe und war zu Spitzenzeiten Hunderttausenden Angriffen pro Tag ausgesetzt. Die Technik musste weiterentwickelt werden, während der bereits laufende Dienst zugleich stabil bleiben musste. Oft war die Arbeit ein Nahkampf. Wir verließen das Büro regelmäßig erst um drei oder vier Uhr morgens und arbeiteten manchmal die ganze Nacht durch.

Häufig kämpften wir einen Tag und eine Nacht lang, behoben alle bekannten Angriffe und fuhren zum Schlafen nach Hause. Kurz nachdem wir eingeschlafen waren, klingelte wieder das Telefon: Das Onlinesystem war erneut überwunden worden.

In diesem Prozess halfen wir, die End-to-End-Modellarchitektur von SenseTime für die Gesichtserkennung voranzutreiben. Zuvor kamen viele Deep-Learning-Algorithmen nur in einzelnen Teilen zum Einsatz, während das Gesamtsystem mehrere Stufen miteinander verkettete. Gegen ständig wechselnde Angriffe konnten manuell kombinierte Methoden jedoch nicht schnell genug iterieren. Der einzige Ausweg, den wir sahen, war ein einziges End-to-End-Deep-Learning-Modell, das direkt aus Daten lernte. Damals nannten wir es das „vereinheitlichte Modell“.

Dieses Projekt ließ mich zum ersten Mal wirklich verstehen, dass ein in einer Demo funktionierender Algorithmus noch keine tragfähige Technologie ist. Erst wenn er massenhafte Zugriffe, fortlaufende Angriffe und alle möglichen unerwarteten Situationen übersteht, wird er tatsächlich nutzbar.

Später gingen wir in den Smartphone-Markt. Vor jeder Einführung organisierten die Hersteller Tests mit Hunderten Menschen, während Wettbewerber und Nutzer ständig neue Probleme fanden. Das zwang uns, eines der damals nach unserem Wissen größten Testteams eines KI-Algorithmusunternehmens aufzubauen und zu versuchen, jede Möglichkeit auszuschöpfen.

Ein Problem mit Gegenlicht ließ sich nur in einer bestimmten Herrentoilette an einem SenseTime-Standort reproduzieren. Ein anderes, das wir „Halblicht-Gesicht“ nannten, trat nur aus einem bestimmten Winkel unter einem bestimmten Baum auf. Damit ein Produkt im Alltag von Hunderten Millionen Menschen zuverlässig funktionierte, erledigten wir sehr viel Arbeit dieser Art.

Am Ende machten wir die Identitätsauthentifizierung auf Smartphones zu einem Marktführer.

Das war der erste Fluss, in den ich bei SenseTime einstieg. Die Lebenderkennung begann als Forschungsdemo, wurde in mehreren groß angelegten Anwendungen geprüft und entwickelte sich schließlich zu einem recht ausgereiften Gebiet. Bis 2019 ließen sich viele Probleme, die früher riskante Erkundung verlangt hatten, mit gesammelter Erfahrung lösen. Ich hatte nicht alles abgeschlossen, aber ich wusste, dass ich wieder in einer Komfortzone angekommen war.

Also wurde ich erneut unruhig.

Bei SenseTime bleiben und den Fluss wechseln

2019 verließ ich SenseTime nicht. Ich entschied mich, im selben Unternehmen von der Identitätsauthentifizierung zur industriellen Bildverarbeitung zu wechseln.

Nach umfassender Recherche und vielen Gesprächen mit der Unternehmensleitung und dem Vertriebsteam wählten wir als erstes Projekt für industrielle Bildverarbeitung die intelligente Inspektion des C4-Oberleitungssystems von Hochgeschwindigkeitszügen.

Gemeinsam mit dem Presales-Team besuchte ich viele Eisenbahn-Prüfzentren und Behörden. Den tiefsten Eindruck hinterließ das Zentrum in Xuzhou. Als wir ankamen, hatte es gerade geregnet. Das Zentrum lag recht abgelegen, und wir stapften über einen schlammigen Weg hinein.

Drinnen standen Computer in langen Reihen. Die Prüfer verbrachten jeden Tag viel Zeit damit, Bilder nach möglichen Fehlern an Eisenbahnoberleitungen zu durchsuchen. Fast alle hatten dunkle Augenringe. Nachdem sie einen Fehler gefunden hatten, mussten sie noch Tausende Kilometer Schienenstrecke entlangfahren und jedes Problem einzeln behandeln. Manchmal war nur eine Schraube oder Mutter locker, trotzdem mussten sie vor Ort sein. Ob bei bitterer Kälte oder großer Hitze — die Reparatur durfte nicht warten.

Der Bedarf war für mich schmerzhaft deutlich. Wenigstens bei der zeitaufwendigsten Arbeit sollten wir ihnen helfen: beim Betrachten der Bilder.

Erst nach dem Start merkten wir, wie viel schwieriger das Problem war als gedacht. Eine Oberleitung enthält mehr als hundert Arten von Bauteilen und über tausend Arten von Defekten. Selbst diese Zahlen entstanden erst, nachdem wir sie gemeinsam mit den Kollegen vor Ort wiederholt gezählt und geordnet hatten. Viele Prüfungen beruhten auf Erfahrung, während Dokumente und historische Daten verstreut lagen. Wir mussten das Material von Grund auf sammeln, an der Seite der Menschen vor Ort arbeiten und jeden Fehlertyp einzeln verstehen. Dieser Prozess dauerte fast zwei Jahre.

Die größere Herausforderung waren die wenigen Beispiele. Fehler auf Hochgeschwindigkeitsstrecken sind von Natur aus äußerst selten. Manche treten vielleicht kein einziges Mal im Jahr auf, können dann aber schwerwiegende Folgen haben. Wir konnten nicht warten, bis wir genügend Beispiele gesammelt hatten. Wir mussten unsere Methoden für die realen Bedingungen neu entwerfen.

Schließlich gelang das Projekt und wurde in großem Maßstab eingesetzt.

Die industrielle Bildverarbeitung war der zweite Fluss, in den ich bei SenseTime einstieg. Ich wechselte nicht das Unternehmen, doch fast alles Vertraute änderte sich: Probleme, Daten, Kunden, Bewertungskriterien und Arbeitsweise. Ich wurde wieder zum Anfänger und schaffte mit dem Team etwas, von dem wir anfangs nicht wussten, wie es ging.

Deshalb sage ich, dass der Fluss nicht das Unternehmen ist. Was mich wirklich anzieht, ist nicht, einen Ort zu verlassen, sondern ein schwierigeres Problem zu betreten.

Das Jahr 2022, in dem ich den Fluss nicht wechselte

Nach dem Börsengang stand SenseTime unter neuem finanziellen und materiellem Druck. Gleichzeitig trat die vorherige Welle der Computer Vision allmählich in die Reifephase ein, während die nächste noch nicht klar sichtbar war. Vieles wurde durch Ressourcen, den Markt oder technische Grenzen eingeschränkt und ließ sich nicht mehr so schnell vorantreiben wie zuvor.

Das ganze Jahr 2022 war ich etwas niedergeschlagen oder, anders gesagt, ein wenig passiv. Ich begann, zu gewöhnlichen Zeiten zu arbeiten.

An diesem Satz ist nichts falsch. Regelmäßige Arbeitszeiten sind für viele Menschen ein normales Leben. Aber ich hatte meine Arbeit immer wie ein Start-up behandelt. Als ich plötzlich in diesen Zustand geriet, fühlte ich mich tief entmutigt.

Oberflächlich betrachtet war das Leben viel bequemer als früher. Ich wachte nicht mehr jeden Tag mit einem neuen, unbedingt zu lösenden Problem auf und blieb nicht mehr so oft wegen eines Onlinefehlers die ganze Nacht wach. Doch genau dieser Komfort machte mir zu schaffen: Ich konnte mir allmählich vorstellen, wie mein Leben in einigen Jahren aussähe, wenn sich nichts änderte.

Ich ging nicht sofort. Was mich hielt, war Verantwortung.

Die Eisenbahninspektion war gelungen, doch bei der Qualitätsprüfung in Automobilwerken waren wir nicht erfolgreich, und auch der intelligente Industrieroboterarm war nicht fertig. Ich wollte diese Arbeit fortsetzen. Ich konnte nur schwer akzeptieren, ein Team gegründet und eine Richtung gewählt zu haben, um dann im schwierigsten Moment zu gehen.

Eine Kraft sagte mir, ich solle nach dem nächsten Fluss suchen; die andere, dass die Arbeit vor mir noch nicht beendet sei.

Im Jahr 2022 war die zweite Kraft stärker.

Ich sah den nächsten Fluss

Ende letzten Jahres erschien ChatGPT. In der ersten Hälfte dieses Jahres kam GPT-4. Das alte Gleichgewicht zerbrach.

Damals hatte ich ein sehr starkes Gefühl: Der Computer Vision war ihre eigene Basis genommen worden.

Die Zukunft würde nicht aus voneinander getrennten Modellen für Text, Bild und Sprache bestehen. Computer Vision würde nicht verschwinden, sondern ein Teil davon werden, wie allgemeine Modelle die Welt verstehen. Früher hatten wir das Sehen als vollständiges technisches Zentrum betrachtet; nun zeichnete sich eine größere Ära allgemeiner Intelligenz ab.

Das war kein weiteres technisches Upgrade innerhalb der Computer Vision. Der Hauptstrom der technologischen Entwicklung selbst hatte sich verändert.

Ich sah wieder einen Fluss, dessen Strömungen ich noch nicht kannte.

Früher hatte ich den Fluss wechseln können, ohne SenseTime zu verlassen. Der Wechsel von Identitätsauthentifizierung zu industrieller Bildverarbeitung im Jahr 2019 war eine solche Entscheidung. Diesmal lag der nächste Fluss jedoch nicht in der Verlängerung meiner bisherigen Arbeit. Ich wollte in die allgemeine Intelligenz und die neuen Anwendungen eintreten, die sie schaffen würde.

Meine Rolle und meine Verantwortung lagen weiterhin in der industriellen Bildverarbeitung. Wenn ich blieb, sollte ich mich ganz darauf konzentrieren, diese Arbeit gut zu machen. Ich sollte nicht meine bestehenden Pflichten tragen und nebenher meine nächste Station vorbereiten.

Um wirklich in den nächsten Fluss zu springen, musste ich zuerst meine alte Rolle verlassen.

In der ersten Jahreshälfte fiel es mir immer schwerer, stillzusitzen. Ich wusste nicht, welche Produkte die neue Technologie letztlich hervorbringen würde oder was ich darin tun könnte. Aber ich wusste: Wenn ich wartete, bis alles durchdacht war, verpasste ich vielleicht die Jahre, in denen ich am dringendsten mit dem Lernen beginnen musste.

Wirklich wichtige Dinge erreichen selten einen Zeitpunkt, an dem man sie für „vollständig abgeschlossen“ erklären kann. Wenn Verantwortung bedeutet, bis zum Ende aller Probleme zu warten, trifft ein Mensch womöglich nie eine neue Entscheidung.

Nach und nach erkannte ich, dass Verantwortung nicht nur Bleiben bedeutet. Auch das Bleiben ist eine Entscheidung, deren Folgen man tragen muss. Verantwortungsgefühl darf kein Grund werden, eine Entscheidung auf unbestimmte Zeit zu verschieben.

Deshalb verließ ich SenseTime im Juni dieses Jahres.

Warum ich ohne Antwort ging

Vor meinem Weggang bereitete ich nicht heimlich außerhalb der Arbeit ein Start-up vor. Ich plante auch nicht, das laufende Geschäft von SenseTime mitzunehmen und darauf ein eigenes Unternehmen aufzubauen.

Wenn ich weiterhin für ein Unternehmen arbeitete, für seine Ergebnisse verantwortlich war und seine Ressourcen nutzte, innerlich aber darüber nachdachte, wie ich meine nächste Station vorbereiten könnte, würde ich mich gegenüber meiner bisherigen Arbeit unehrlich fühlen.

Das bedeutete, dass ich bei meiner Kündigung tatsächlich nicht vorbereitet war.

Ich war nicht unvorbereitet, weil ich das Gründen nicht ernst nahm, sondern weil ich bis zu meinem Weggang meine bisherige Arbeit weiterhin ernst nahm.

Ich konnte nur zuerst gehen und danach nach der Antwort suchen.

Schwimmen zu können bedeutet nicht, jeden Fluss zu kennen. Man kann auch nicht am Ufer stehen bleiben, bis man die Strömung vollständig verstanden hat, und erst dann hineinspringen. Manches Wissen gewinnt man nur im Wasser, und manche Richtung wird erst sichtbar, nachdem man sich in Bewegung gesetzt hat.

Diesmal bedeutete der Flusswechsel, meine Stelle aufzugeben. Aber nicht die Sehnsucht nach dem Kündigen trieb mich an, sondern das Erscheinen des nächsten Flusses.

Die Seite der Anwendungen wählen

Nach dem Erscheinen von ChatGPT diskutierte ich mit Freunden eine Frage: Wenn AGI kommt, wird Intelligenz am Ende in den Händen weniger Plattformen konzentriert sein oder von mehr Menschen geteilt werden?

Meine Einschätzung war, dass sie sich unweigerlich verbreiten würde.

Streng beweisen kann ich das nicht. Meine Intuition ist schlicht, dass das Universum selbst kein zentralisiertes System ist. Die reale Welt besteht aus unzähligen Menschen, Geräten, Umgebungen und lokalen Problemen. Wenn Intelligenz wirklich in diese Welt eintreten soll, muss auch sie in zahllosen Formen existieren. Das Training von Basismodellen mag sich auf wenige Unternehmen konzentrieren, aber die Anwendungen der Intelligenz werden nicht nur wenigen Plattformen gehören.

Deshalb möchte ich keine Basismodelle bauen. Lieber entwickle ich Anwendungen, die mit dieser neuen Intelligenz auf konkrete Bedürfnisse antworten, eines nach dem anderen.

Diese Entscheidung kommt auch aus meinem eigenen Leben.

Ich wuchs auf dem Land auf. Von der Grundschule bis zur Mittelschule verbrachte ich viele Ferien und freie Stunden mit der landwirtschaftlichen Arbeit meiner Familie. Ich säte, düngte, brachte Pflanzenschutzmittel aus, fuhr Traktor und hielt Tiere. In den Ferien war ich für mich ein ganz wirklicher Bauer.

Ich mochte das Erfolgserlebnis dieser Arbeit. Ob die Pflanzen gut wuchsen und die Tiere gut aufgezogen waren, zeigte sich unmittelbar. Wenn man die Arbeit ein wenig besser machte, wurde das Leben einer Familie ein wenig besser.

An der Universität hatte ich viele Nebenjobs und veranstaltete mit Kommilitonen einen Sommerkurs. Wir warben selbst die Schüler an, kassierten die Gebühren und unterrichteten. In jenem Sommer verdienten alle Beteiligten genug für die Lebenshaltungskosten des folgenden Jahres.

Im Aufbaustudium arbeitete ich als Privatlehrer. Später, als SenseTime gerade begonnen hatte und das Büro noch aus einem Hotelzimmer im Wenjin Hotel nahe dem Südtor von Tsinghua bestand, kam ich als einer der frühen Gründungsmitarbeiter hinzu.

Oberflächlich haben diese Dinge wenig gemeinsam. Doch sie gaben mir auf dieselbe Weise ein Erfolgserlebnis: Ich löste ein reales Problem und sah, wie sich durch meine Beteiligung etwas veränderte.

Als die neue Ära allgemeiner Intelligenz erschien, stellte ich mich daher instinktiv wieder auf die Seite der Anwendungen. Mich beschäftigt nicht, wie man beweist, dass eine Technologie stärker ist, sondern was sie am Ende für einen konkreten Menschen tun kann.

Nach dem Sprung

In den nächsten Fluss einzutreten bedeutete nicht, dass ich sofort wusste, wohin ich schwimmen sollte.

In den ersten Monaten nach meinem Weggang von SenseTime suchte ich instinktiv weiter dort nach Möglichkeiten, wo ich mich am besten auskannte. Mit einem Freund probierte ich einige bildbezogene Produkte aus. Schließlich hatten sich fast zehn Jahre meiner Arbeit um Computer Vision gedreht. Dort zu beginnen schien am natürlichsten.

Doch nach einiger Zeit spürte ich immer stärker, dass die Richtung nicht stimmte. Das Problem lag nicht unbedingt in den Produkten selbst, sondern darin, dass wir weiterhin von dem ausgingen, was wir konnten, statt von dem, was die Nutzer wirklich brauchten.

Wer zehn Jahre lang einen Hammer getragen hat, sieht selbst in einem anderen Raum leicht überall nur Nägel.

Mir wurde klar, dass der Eintritt in ein neues Gebiet nicht bedeutet, nur den Ort zu wechseln und dort weiter die früher erfolgreichen Methoden anzuwenden. Ein echter Neuanfang verlangt, die vertrautesten Antworten vorübergehend beiseitezulegen.

Also fragte ich mich: Wenn ich die technische Erfahrung der vergangenen zehn Jahre außer Acht ließe, welches KI-Produkt würde ich selbst am liebsten haben?

Meine Antwort lautete: Notizen.

Das Produkt, das ich am meisten wollte

Seit der Mittelschule halte ich mich an den Grundsatz: „Nie lesen, ohne zu schreiben und Notizen zu machen.“ Für mich waren Notizen nie nur ein Ort zur Ablage von Informationen. Sie sind eine Erweiterung des Gedächtnisses und ein Teil des Denkens.

Oft nennt man sie ein „zweites Gehirn“. Doch dieses sogenannte zweite Gehirn ist nicht wirklich intelligent.

Wir legen Dinge hinein, müssen sie aber weiterhin selbst ordnen, suchen, miteinander verbinden und wieder hervorholen. Es ähnelt eher einer externen Festplatte als einem anderen Gehirn.

Diese Generation großer Modelle ließ mich zum ersten Mal glauben, dass sich das grundlegend ändern könnte. Notizen der Zukunft bewahren vielleicht nicht nur auf, was jemand geschrieben hat. Sie könnten die Inhalte verstehen, Verbindungen finden, uns bei Bedarf beim Erinnern helfen und sogar an unserem Denken teilnehmen.

Ich möchte keine Notizsoftware mit ein paar hinzugefügten KI-Funktionen bauen, sondern ein wirklich intelligentes zweites Gehirn.

Allgemeine Intelligenz ist der nächste Fluss, in den ich gesprungen bin. Intelligente Notizen sind die erste Richtung, in die ich darin schwimmen will.

Noch nicht am anderen Ufer

Zuvor hatte ich vieles mit unternehmerischem Charakter getan. Der Sommerkurs an der Universität war eine informelle Gründung. Mich SenseTime in seinen Anfängen anzuschließen bedeutete, an einer Gründung teilzunehmen. Die Teams für Lebenderkennung und industrielle Bildverarbeitung innerhalb von SenseTime aufzubauen ähnelte ebenfalls dem Gründen innerhalb eines Unternehmens.

Doch diesmal war es anders. Im Juni dieses Jahres verließ ich zum ersten Mal ein Unternehmen, setzte mich vollständig dem Markt aus und begann im eigentlichen Sinne in Vollzeit zu gründen.

Heute ist der 31. Dezember 2023. Seit meinem Weggang von SenseTime ist ein halbes Jahr vergangen.

Ich habe noch nicht auf alle Fragen Antworten gefunden und kein Ufer erreicht, das man Erfolg nennen könnte. Ich lerne vieles, das mir zuvor nicht lag: ein Produkt zu bauen, einen Markt zu verstehen und beides zur Deckung zu bringen.

Viele Menschen würden diesen Zustand vielleicht als schmerzhaft empfinden. Mir vermittelt er eine lange vermisste Vertrautheit, weil ich wieder an einem Ort bin, an dem ich die Antworten nicht kenne.

Dies ist der erste Beitrag in meinem persönlichen Blog. Ich schreibe ihn nicht, weil die Reise beendet wäre, sondern weil ich in dem Augenblick, in dem sie wirklich beginnt, festhalten möchte, warum ich aufgebrochen bin. Künftig werde ich hier weiter über Technologie, Produkte und Menschen sowie über die Dinge schreiben, die ich erschaffe.

Ich weiß nicht, wohin dieser Fluss schließlich führen wird.

Doch rückblickend begannen mehrere wichtige Veränderungen in meinem Leben mit derselben Entscheidung: Nachdem ich lange genug Zeit investiert und bemerkt hatte, dass ich allmählich in eine Komfortzone geriet, begann ich nach dem nächsten Fluss zu suchen.

Im Juni dieses Jahres traf ich diese Entscheidung erneut.

Ich bin noch immer im Wasser.

When I left, I had no validated product, no complete business plan, and not even a clear idea of exactly what I was going to build.

But I knew it was time for me to jump into the next river.

It was not the first time I had changed rivers, but it was the first time doing so required me to leave a company.

A Choice I Keep Making

I went from a rural primary school to a middle school in the county seat, then to Nanjing University for my undergraduate degree and Tsinghua University for graduate school. While at Tsinghua, I joined SenseTime when it was just getting started. At SenseTime, I first founded the liveness detection team and later the industrial vision team.

Looking back, a change like this seems to happen every few years.

These changes were not parts of a life plan drawn up in advance. Nor did they happen because the work I had been doing had lost its meaning. It was simply that after years of effort, both the field and I had gradually matured. The work was not necessarily finished, but it no longer forced me to push beyond my own limits.

For many people, that would be an ideal state. For me, it creates unease. I do not like a life whose end I can see from where I stand. Every so often, I need to put myself inside a problem I do not know how to solve—sometimes one I do not even know how to begin.

The “river” here is not a company. Changing rivers does not necessarily mean leaving a job. A river is a field I have to learn from scratch, a difficult thing I do not yet know how to make work. During my nearly ten years at SenseTime, I jumped into two different rivers.

But I am not someone who pursues change for its own sake. There is another force in me that pulls almost in the opposite direction: a sense of responsibility.

I hate leaving things half done. Once I decide to do something, I want to do it properly. One force makes me search for the next river; the other keeps me in the old one, trying to finish what I started.

My departure this year was the result of a long struggle between these two forces.

Taking Algorithms into the Real World

I joined SenseTime as a member of the research department, but what interested me most was always applications. I wanted to know not only whether an algorithm worked on an experimental dataset, but whether it could enter the real world and solve a concrete problem.

Liveness detection was a core part of SenseTime's first major deployment. Before then, we already had some impressive face-recognition demos. But when we faced a genuinely large-scale application, we discovered that many production problems remained unsolved, especially attacks against the online system.

The system handled more than a million visits a day. At peak times, it faced hundreds of thousands of attack attempts in a single day. The technology still had to improve, while the service already online had to keep running. Much of the work became hand-to-hand combat. We often left the office at three or four in the morning, and sometimes stayed all night.

A familiar pattern was that we would fight for a day and a night, fix every attack we knew about, and go home to sleep. Soon after we fell asleep, the phone would ring again: the online system had been broken once more.

It was during this process that we helped push forward SenseTime's end-to-end model architecture for face recognition. Before then, many deep-learning algorithms were used only in isolated parts of the system, with several stages connected in sequence. But against constantly changing attacks, manually assembled methods could not iterate fast enough. The only way forward we could see was to let a single end-to-end deep-learning model learn directly from data. At the time, we called it the “unified model.”

This project taught me for the first time what it means for an algorithm to be real. Working in a demo is not enough. A technology becomes truly usable only after it survives large-scale traffic, continuous attacks, and all kinds of unexpected conditions.

We later moved into smartphones. Before each launch, phone makers would organize tests involving hundreds of people, while competitors and users kept discovering new problems. This forced us to build what was, as far as we knew, one of the largest testing teams at any AI algorithm company at the time, in an attempt to exhaust every possibility.

One backlighting bug could be reproduced only in a particular men's restroom in one of SenseTime's offices. Another problem, which we called the “half-lit face,” appeared only from a particular angle beneath a certain tree. To make a product work reliably in the daily lives of hundreds of millions of people, we did an enormous amount of work like this.

In the end, we made identity authentication on smartphones a market leader.

This was the first river I entered at SenseTime. Liveness detection began as a research demo, passed through several rounds of large-scale deployment, and eventually became a fairly mature field. By 2019, many problems that had once required risky exploration could be solved with accumulated experience. I had not finished everything, but I knew I had entered a comfort zone again.

So I began to grow restless.

Changing Rivers Without Leaving SenseTime

In 2019, I did not leave SenseTime. I chose to move within the same company, from identity authentication to industrial vision.

After extensive research and many discussions with company leaders and the business team, we chose intelligent inspection of the C4 overhead contact system on high-speed railways as our first industrial vision project.

The presales team and I visited many railway inspection centers and railway bureaus. The place that left the deepest impression on me was the Xuzhou inspection center. It had just rained when we visited. The center was in a fairly remote location, and we made our way through a muddy road, sinking into it with every step.

Inside were rows and rows of computers. Inspectors spent much of every day looking through images for possible faults in railway overhead contact systems. Almost all of them had dark circles under their eyes. After finding a fault, they still had to travel along thousands of kilometers of railway and deal with each problem in turn. Sometimes it was only a loose screw or nut, but they still had to reach the site. Whether in bitter cold or intense heat, the repair could not wait.

The need was painfully clear. At the very least, we should help them with the most time-consuming part: looking at images.

Only after we started did we discover how much harder the problem was than we had imagined. An overhead contact system contains more than a hundred types of components and over a thousand types of defects. Even those numbers emerged only after we repeatedly worked through them with frontline colleagues. Much inspection work had long depended on experience, while documents and historical data were scattered across different places. We had to collect the material from scratch, work beside the people on the front line, and understand every fault item one by one. The process took nearly two years.

The greater challenge was the small-sample problem. Faults on high-speed rail lines are rare by nature. Some might not occur even once in a year, but can have serious consequences when they do. We could not wait until we had gathered enough samples. We had to redesign our methods around the conditions of the real world.

Eventually, the project worked and was deployed at scale.

Industrial vision was the second river I entered at SenseTime. I did not change companies, but almost everything familiar changed: the problems, data, customers, evaluation criteria, and way of working. I became a beginner again, then worked with the team to accomplish something we had not previously known how to do.

This is why I say a river is not a company. What attracts me is not leaving a place, but entering a harder problem.

The Year I Did Not Change Rivers

After SenseTime went public, it began to face new financial and resource pressures. At the same time, the previous wave of computer vision was entering maturity, while the next wave had not yet clearly appeared. Many things were constrained by resources, the market, or the limits of the technology, and could no longer advance as quickly as before.

Throughout 2022, I was in a somewhat dispirited—or perhaps passive—state. I started working ordinary hours.

There is nothing wrong with that sentence. Working regular hours is a normal life for many people. But I had always treated my work as if I were building a startup. When I suddenly entered this state, I felt deeply discouraged.

On the surface, life was much more comfortable than before. I no longer woke each day to a new problem that had to be solved, and I no longer stayed up all night so often because of an online failure. Yet that comfort was exactly what troubled me: I could begin to imagine what my life would look like several years later if nothing changed.

I did not leave immediately. What kept me there was responsibility.

We had made high-speed railway inspection work, but we had not succeeded with quality inspection in automobile factories, and we had not finished the intelligent industrial robot arm. I wanted to keep working on these things. I could not easily accept founding a team, choosing a direction, and then leaving at its most difficult moment.

One force told me to look for the next river. The other told me that the work in front of me was not finished.

In 2022, the second force was stronger.

I Saw the Next River

ChatGPT appeared at the end of last year. GPT-4 arrived in the first half of this year. The old balance was broken.

I had a powerful feeling at the time: computer vision's base had been raided.

The future would not be made of separate models for text, images, and speech. Computer vision would not disappear, but it would become one part of how general models understand the world. We had treated vision as a complete technical center. Now a larger age of general intelligence was emerging.

This was not another technical upgrade within computer vision. The main course of technological progress itself had changed.

I saw another river whose currents I did not yet understand.

In the past, I had been able to change rivers without leaving SenseTime. Moving from identity authentication to industrial vision in 2019 was one such choice. This time, however, the next river did not lie along the extension of my existing work. I wanted to enter general intelligence and the new applications it would create.

My role and responsibilities were still in industrial vision. If I stayed, I should devote myself fully to doing that work well. I should not carry my existing responsibilities while preparing for my own next destination on the side.

To truly jump into the next river, I first had to leave my old role.

By the first half of this year, I had become increasingly unable to sit still. I did not know what products the new technology would ultimately create, or what role I could play in them. But I knew that if I waited until I had thought everything through, I might miss the years when I most needed to begin learning.

Things that truly matter rarely reach a moment when one can declare them “completely finished.” If responsibility means waiting until every problem is over, a person may never make a new choice.

I gradually realized that responsibility does not only mean staying. Staying is also a choice, and its consequences must also be borne. A sense of responsibility cannot become a reason to postpone a decision forever.

So in June this year, I left SenseTime.

Why I Left Without an Answer

Before leaving, I did not secretly prepare a startup outside work, nor did I plan to take SenseTime's existing business and build a company around it.

If I was still employed by a company, responsible for delivering its work and using the resources it provided, while privately thinking about how to prepare for my next destination, I would feel that I was not being honest with my current work.

This meant I truly was not ready when I resigned.

I was unprepared to start a company not because I did not take entrepreneurship seriously, but because, before I left, I was still taking my previous work seriously.

I could only leave first, then search for the answer.

Knowing how to swim does not mean knowing every river. Nor can someone stand on the bank until they fully understand the current before jumping in. Some knowledge can be gained only in the water, and some directions become visible only after we begin moving.

This time, changing rivers happened to mean leaving my job. But what moved me was not a desire to resign. It was the appearance of the next river.

Choosing Applications

After ChatGPT appeared, I discussed a question with friends: if AGI arrives, will intelligence eventually be concentrated in the hands of a few platforms, or will it be shared more widely?

My judgment was that it would inevitably spread.

I cannot prove this rigorously. My intuition is simply that the universe itself is not a centralized system. The real world consists of countless people, devices, environments, and local problems. If intelligence is to truly enter this world, it too must exist in countless different forms. The training of foundation models may be concentrated in a small number of companies, but applications of intelligence will not belong only to a few platforms.

That is why I do not want to build foundation models. I would rather build applications that use this new intelligence to respond to one concrete need after another.

This choice also comes from my own life.

I grew up in the countryside. From primary school through middle school, I spent many holidays and spare hours helping with farm work at home. I sowed seed, applied fertilizer and pesticides, drove tractors, and raised animals. During school holidays, I considered myself a farmer in every practical sense.

I liked the sense of accomplishment this work brought. Whether the crops grew well and whether the animals were raised well were direct and visible. If you did the work a little better, a family's life became a little better.

At university, I took many part-time jobs and ran a summer tutoring program with several classmates. We recruited students, collected fees, and taught the classes ourselves. That summer, each of us involved earned enough to cover the following year's living expenses.

In graduate school, I worked as a private tutor. Later, when SenseTime was just getting started, its office was still a guest room in the Wenjin Hotel near Tsinghua's south gate. I joined as an early founding employee.

On the surface, these things have little in common. But they gave me a sense of accomplishment in the same way: I solved a real problem and saw something change because I had taken part.

So when the new age of general intelligence appeared, I instinctively chose the application side again. My concern is not how to prove that a technology is more powerful, but what it can eventually do for a particular person.

After I Jumped In

Entering the next river did not mean that I immediately knew where to swim.

In the first few months after leaving SenseTime, I still instinctively looked for opportunities in the place I knew best. A friend and I tried several image-related products. After all, nearly ten years of my work had been in computer vision. Starting there seemed the most natural choice.

But after working on them for a while, I increasingly felt that the direction was wrong. The problem was not necessarily the products themselves. It was that we were still starting from what we knew how to do, rather than from what users truly needed.

After carrying a hammer for ten years, even in a different room, everything can still look like a nail.

I realized that entering a new field does not mean moving somewhere else and continuing to apply the methods that worked before. To truly begin again, one has to temporarily put aside the answers one knows best.

So I asked myself a question: if I ignored the technical experience I had accumulated over the previous ten years, what AI product would I most want for myself?

My answer was notes.

The Product I Wanted Most

Since middle school, I have followed a rule: “Never read without making marks and notes.” To me, notes have never been just a place to store material. They are an extension of memory and a part of thinking.

People often call notes a “second brain,” but this second brain is not actually intelligent.

We put things into it, but still have to organize them, find them, connect them, and figure out how to retrieve them ourselves. It is more like an external hard drive than another brain.

This generation of large models made me believe for the first time that this could change fundamentally. Notes in the future may not only preserve what a person has written. They may understand it, find connections within it, help us remember when needed, and even take part in our thinking.

What I want to build is not note-taking software with a few AI features added. It is a genuinely intelligent second brain.

General intelligence is the next river I jumped into. Intelligent notes are the first direction I decided to swim toward once inside.

Not Yet on the Other Bank

Before this, I had done many things that resembled entrepreneurship. Running the tutoring program at university was an informal startup. Joining SenseTime at its beginning meant participating in a startup. Founding the liveness detection and industrial vision teams inside SenseTime was also much like starting companies within a company.

But this time was different. In June this year, for the first time, I left a company, placed myself fully in the market, and began working full-time on a startup in the true sense.

Today is December 31, 2023. Half a year has passed since I left SenseTime.

I still do not have answers to every question, nor have I reached any opposite bank that could be called success. I am learning many things I was not good at before, including how to build a product, how to understand a market, and how to make the two fit.

Many people might find this state painful. To me, it carries a long-missed sense of familiarity, because I am once again in a place where I do not know the answers.

This is the first essay on my personal blog. I am writing it not because this journey is over, but because I want to record, at the moment it truly begins, why I set out. In the future, I will continue to write here about technology, products, people, and the things I am building.

I do not know where this river will ultimately lead.

But looking back, several important changes in my life began with the same choice: after investing enough time and finding myself gradually entering a comfort zone, I started looking for the next river.

In June this year, I made that choice again.

I am still in the water.

Cuando me fui, no tenía un producto validado ni un plan de negocio completo. Ni siquiera había decidido exactamente qué iba a hacer.

Pero sabía que había llegado otra vez el momento de saltar al siguiente río.

No era la primera vez que cambiaba de río, pero sí la primera en que hacerlo exigía dejar una empresa.

Una elección que repito

Pasé de una escuela primaria rural a un instituto en la capital del condado. Después estudié la carrera en la Universidad de Nankín y el posgrado en la Universidad de Tsinghua. Durante el posgrado me incorporé a SenseTime, que acababa de nacer. Allí fundé primero el equipo de detección de vida y, más tarde, el de visión industrial.

Al mirar atrás, veo que estos cambios aparecen cada pocos años.

No formaban parte de un plan de vida diseñado de antemano, ni ocurrían porque lo anterior hubiera perdido su sentido. Sencillamente, después de años de dedicación, tanto el campo como yo íbamos madurando. El trabajo no tenía por qué estar terminado, pero ya no me obligaba a superar mis propios límites.

Para muchas personas, ese sería el estado ideal. A mí, en cambio, me inquieta. No me gusta una vida cuyo final se ve de un vistazo. Por eso, cada cierto tiempo necesito meterme en un problema que no sé resolver, uno en el que a veces ni siquiera sé por dónde empezar.

El «río» no es una empresa. Cambiar de río tampoco implica necesariamente renunciar. Es un campo que exige aprender de nuevo, algo difícil que todavía no sé cómo llevar a buen término. En mis casi diez años en SenseTime salté a dos ríos distintos.

Pero no soy una persona que busque el cambio por sí mismo. Dentro de mí actúa otra fuerza, casi opuesta: el sentido de la responsabilidad.

Detesto dejar las cosas a medias. Cuando decido hacer algo, quiero hacerlo de verdad y hacerlo bien. Una fuerza me lleva a buscar el siguiente río; la otra me mantiene en el anterior, intentando terminar lo que ya empecé.

Mi marcha de este año fue el resultado de una larga lucha entre ambas.

Llevar los algoritmos al mundo real

Cuando entré en SenseTime trabajaba en el departamento de investigación, pero lo que siempre me interesó fueron las aplicaciones. No solo quería saber si un algoritmo funcionaba con datos experimentales, sino si podía entrar en el mundo real y resolver un problema concreto.

La detección de vida era una pieza central del primer gran proyecto implantado por SenseTime. Antes ya teníamos algunas demostraciones de reconocimiento facial bastante buenas. Sin embargo, al enfrentarnos a una aplicación realmente masiva descubrimos que muchos problemas de producción seguían sin resolverse, sobre todo los ataques contra el sistema en línea.

El sistema recibía más de un millón de accesos diarios y, en los momentos de mayor actividad, hasta cientos de miles de ataques en un solo día. La tecnología tenía que seguir avanzando, mientras el servicio ya desplegado debía mantenerse en pie. Muchas veces aquello era un combate cuerpo a cuerpo. Solíamos salir de la oficina a las tres o cuatro de la madrugada y, en ocasiones, pasábamos allí toda la noche.

Era habitual que, después de luchar durante un día y una noche y resolver todos los ataques conocidos, volviéramos a casa para dormir. Poco después de acostarnos sonaba otra vez el teléfono: habían vuelto a vulnerar el sistema.

En ese proceso ayudamos a impulsar la arquitectura de modelos de extremo a extremo de SenseTime para el reconocimiento facial. Hasta entonces, muchos algoritmos de aprendizaje profundo se utilizaban solo en partes aisladas y el sistema completo encadenaba varias etapas. Pero frente a ataques que cambiaban continuamente, los métodos combinados a mano no podían iterar con suficiente rapidez. La única salida que veíamos era dejar que un único modelo de aprendizaje profundo de extremo a extremo aprendiera directamente de los datos. Entonces lo llamábamos el «modelo unificado».

Ese proyecto me enseñó por primera vez que un algoritmo funcione en una demostración no significa que la tecnología ya sea válida. Solo se vuelve realmente utilizable cuando resiste el acceso a gran escala, los ataques continuos y toda clase de situaciones imprevistas.

Después entramos en los teléfonos inteligentes. Antes de cada lanzamiento, los fabricantes organizaban pruebas con cientos de personas, y tanto otras empresas como los usuarios seguían descubriendo nuevos problemas. Eso nos obligó a crear uno de los mayores equipos de pruebas que, hasta donde sabíamos, existían entonces en una empresa de algoritmos de IA, con la intención de agotar todas las posibilidades.

Un problema de contraluz solo podía reproducirse en un aseo masculino concreto de una de las oficinas de SenseTime. Otro, al que llamábamos «rostro de dos luces», aparecía únicamente desde cierto ángulo bajo un árbol determinado. Para que un producto funcionara con fiabilidad en la vida cotidiana de cientos de millones de personas, hicimos una enorme cantidad de trabajo de este tipo.

Al final conseguimos que la autenticación de identidad en teléfonos inteligentes liderara el mercado.

Ese fue el primer río al que entré en SenseTime. La detección de vida comenzó como una demostración de investigación, superó varias rondas de aplicaciones a gran escala y terminó convirtiéndose en un campo bastante maduro. En 2019, muchos problemas que antes exigían explorar asumiendo riesgos ya podían resolverse con la experiencia acumulada. No había terminado todo, pero sabía que había vuelto a entrar en una zona de confort.

Y empecé de nuevo a sentirme inquieto.

Quedarme en SenseTime y cambiar de río

En 2019 no dejé SenseTime. Elegí pasar, dentro de la misma empresa, de la autenticación de identidad a la visión industrial.

Tras mucha investigación y numerosas conversaciones con los responsables de la empresa y el equipo comercial, escogimos como primer proyecto de visión industrial la inspección inteligente del sistema de catenaria C4 de los trenes de alta velocidad.

El equipo de preventa y yo visitamos muchos centros de inspección y organismos ferroviarios. El que más me impresionó fue el centro de Xuzhou. Acababa de llover cuando llegamos. Estaba en una zona bastante apartada y avanzamos por un camino embarrado, hundiéndonos a cada paso.

Dentro había filas y filas de ordenadores. Los inspectores pasaban gran parte del día mirando imágenes para localizar posibles fallos en la catenaria ferroviaria. Casi todos tenían ojeras. Después de encontrar un fallo, todavía debían recorrer miles de kilómetros de vías para solucionar cada problema. A veces solo se trataba de un tornillo o una tuerca flojos, pero tenían que desplazarse hasta allí. Con frío intenso o calor sofocante, la reparación no podía esperar.

La necesidad me pareció dolorosamente clara. Como mínimo, debíamos ayudarles con lo que más tiempo consumía: mirar imágenes.

Solo al empezar descubrimos que era mucho más difícil de lo imaginado. Una catenaria contiene más de cien tipos de componentes y más de mil tipos de defectos. Incluso esas cifras surgieron después de contarlos y ordenarlos repetidamente con los compañeros de primera línea. Gran parte de las inspecciones dependía de la experiencia, mientras los documentos y datos históricos estaban dispersos. Tuvimos que reunir el material desde cero, trabajar junto a quienes estaban sobre el terreno y entender uno a uno todos los tipos de fallo. El proceso se prolongó durante casi dos años.

El reto aún mayor era la escasez de muestras. Los fallos en las líneas de alta velocidad son, por naturaleza, muy raros. Algunos no aparecen ni una vez al año, pero cuando ocurren pueden tener consecuencias graves. No podíamos esperar a reunir suficientes muestras. Solo podíamos rediseñar los métodos a partir de las condiciones reales.

Finalmente, el proyecto funcionó y se implantó a gran escala.

La visión industrial fue mi segundo río en SenseTime. No cambié de empresa, pero cambió casi todo lo que conocía: los problemas, los datos, los clientes, los criterios de evaluación y la manera de trabajar. Volví a ser principiante y, junto con el equipo, conseguimos hacer algo que al principio no sabíamos hacer.

Por eso digo que el río no es la empresa. Lo que de verdad me atrae no es dejar un lugar, sino entrar en un problema más difícil.

El 2022 en que no cambié de río

Después de salir a bolsa, SenseTime empezó a afrontar nuevas presiones financieras y de recursos. Al mismo tiempo, la ola anterior de visión artificial entraba poco a poco en su madurez y la siguiente aún no había aparecido con claridad. Muchas cosas estaban limitadas por los recursos, el mercado o las fronteras de la tecnología, y ya no podían avanzar tan deprisa como antes.

Durante todo 2022 estuve algo abatido o, dicho de otro modo, un poco resignado. Empecé a cumplir un horario normal.

No hay nada malo en esa frase. Trabajar un horario normal es la vida normal de mucha gente. Pero yo siempre había tratado mi trabajo como un emprendimiento. Al entrar de pronto en ese estado, me sentí profundamente desanimado.

En apariencia, aquella vida era mucho más cómoda. Ya no me despertaba cada día con un problema nuevo que exigía una solución inmediata, ni pasaba tantas noches en vela por una avería en línea. Sin embargo, lo que de verdad me incomodaba era precisamente eso: empezaba a imaginar cómo sería mi vida unos años después si nada cambiaba.

No me fui de inmediato. Lo que me hizo quedarme fue la responsabilidad.

La inspección ferroviaria había funcionado, pero no habíamos conseguido la inspección de calidad en fábricas de automóviles ni terminado el brazo robótico industrial inteligente. Quería seguir trabajando en ello. Me costaba aceptar haber fundado un equipo y elegido una dirección para luego marcharme en el momento más difícil.

Una fuerza me decía que buscara el siguiente río; la otra, que el trabajo que tenía delante aún no estaba terminado.

En 2022, la segunda era más fuerte.

Vi el siguiente río

ChatGPT apareció a finales del año pasado. GPT-4 llegó durante la primera mitad de este año. El equilibrio anterior se rompió.

Entonces tuve una sensación muy intensa: la visión artificial había perdido su propia base.

El futuro no estaría formado por modelos independientes para texto, imagen y voz. La visión artificial no desaparecería, pero se convertiría en una parte de la forma en que los modelos generales entienden el mundo. Antes tratábamos la visión como un centro tecnológico completo; ahora empezaba a aparecer una era más amplia de inteligencia general.

No era otra actualización técnica dentro de la visión artificial. Había cambiado la corriente principal del desarrollo tecnológico.

Volví a ver un río cuyas corrientes todavía desconocía.

Antes podía cambiar de río sin salir de SenseTime. El paso de la autenticación a la visión industrial en 2019 fue una decisión de ese tipo. Esta vez, sin embargo, el siguiente río no estaba en la prolongación de mi trabajo anterior. Yo quería entrar en la inteligencia general y en las nuevas aplicaciones que esta crearía.

Mi puesto y mis responsabilidades seguían estando en la visión industrial. Si me quedaba, debía dedicarme por completo a hacer bien ese trabajo. No debía cargar con mis responsabilidades actuales mientras preparaba por otro lado mi próximo destino.

Para saltar de verdad al siguiente río, primero tenía que dejar mi antiguo puesto.

En la primera mitad de este año cada vez me costaba más quedarme quieto. No sabía qué productos crearía finalmente la nueva tecnología, ni qué podría hacer yo dentro de ella. Pero sabía que, si esperaba a tenerlo todo claro, podía perder los años en los que más necesitaba empezar a aprender.

Las cosas que de verdad importan rara vez llegan a un momento en el que se pueda declarar que están «completamente terminadas». Si ser responsable significa esperar a que todos los problemas hayan acabado, una persona quizá nunca pueda tomar una decisión nueva.

Poco a poco entendí que la responsabilidad no solo significa quedarse. Quedarse también es una elección y exige asumir sus consecuencias. El sentido de la responsabilidad no puede convertirse en un motivo para posponer una decisión indefinidamente.

Por eso, en junio de este año, dejé SenseTime.

Por qué me fui sin tener una respuesta

Antes de marcharme, no preparé en secreto una empresa fuera del trabajo ni pensé en sacar fuera el negocio que SenseTime estaba desarrollando para fundar la mía.

Si seguía trabajando en una empresa, con la responsabilidad de entregar su trabajo y usando los recursos que me proporcionaba, mientras por dentro pensaba cómo preparar mi siguiente destino, sentiría que no estaba siendo honesto con mi trabajo actual.

Eso significaba que, cuando renuncié, de verdad no estaba preparado.

No me faltaba preparación porque no me tomara en serio emprender, sino porque hasta el momento de marcharme seguía tomándome en serio mi trabajo anterior.

Solo podía irme primero y buscar la respuesta después.

Saber nadar no significa conocer todos los ríos. Tampoco se puede permanecer en la orilla hasta entender por completo la corriente antes de saltar. Hay conocimientos que solo se adquieren en el agua y direcciones que solo se ven después de empezar a moverse.

Esta vez, cambiar de río significó dejar mi empleo. Pero lo que me impulsó no fue el deseo de renunciar, sino la aparición del siguiente río.

Elegir el lado de las aplicaciones

Después de la aparición de ChatGPT, hablé con amigos sobre una cuestión: si llega la AGI, ¿acabará la inteligencia concentrada en unas pocas plataformas o será compartida por más personas?

Mi conclusión fue que terminaría por extenderse.

No puedo demostrarlo de manera rigurosa. Mi intuición es simplemente que el universo no es un sistema centralizado. El mundo real está compuesto por innumerables personas, dispositivos, entornos y problemas locales. Para entrar de verdad en este mundo, la inteligencia también tendrá que existir de incontables formas. El entrenamiento de los modelos fundacionales puede concentrarse en unas pocas empresas, pero las aplicaciones de la inteligencia no pertenecerán solo a unas pocas plataformas.

Por eso no quiero crear modelos fundacionales. Prefiero crear aplicaciones que utilicen esta nueva inteligencia para responder a necesidades concretas, una tras otra.

Esta elección también viene de mi propia vida.

Crecí en el campo. Desde la primaria hasta el instituto dediqué muchas vacaciones y horas libres a las labores agrícolas de mi familia. Sembré, aboné, apliqué pesticidas, conduje tractores y crié animales. Durante las vacaciones, me consideraba un agricultor en el sentido más real.

Me gustaba la sensación de logro que producía ese trabajo. Si los cultivos crecían bien o los animales estaban bien criados, el resultado era directo y visible. Si hacías el trabajo un poco mejor, la vida de una familia mejoraba un poco.

En la universidad tuve muchos trabajos a tiempo parcial y organicé un curso de verano con varios compañeros. Nosotros mismos captábamos a los alumnos, cobrábamos y dábamos las clases. Aquel verano, todos los que participamos ganamos lo suficiente para cubrir los gastos de vida del año siguiente.

Durante el posgrado trabajé como tutor particular. Más tarde, cuando SenseTime acababa de empezar y su oficina seguía siendo una habitación del hotel Wenjin, cerca de la puerta sur de Tsinghua, me incorporé como uno de sus primeros empleados fundadores.

A primera vista, estas cosas tienen poco en común. Pero me daban satisfacción de la misma forma: resolviendo un problema real y viendo cómo algo cambiaba gracias a mi participación.

Por eso, cuando apareció la nueva era de la inteligencia general, volví a situarme instintivamente del lado de las aplicaciones. No me preocupa cómo demostrar que una tecnología es más potente, sino qué podrá hacer al final por una persona concreta.

Después de saltar

Entrar en el siguiente río no significaba que supiera de inmediato hacia dónde nadar.

Durante los primeros meses tras dejar SenseTime, seguí buscando oportunidades de forma instintiva en el lugar que mejor conocía. Con un amigo probé varios productos relacionados con imágenes. Al fin y al cabo, casi diez años de mi trabajo habían estado ligados a la visión artificial. Empezar desde ahí parecía lo más natural.

Pero después de un tiempo sentí cada vez con más fuerza que la dirección no era la correcta. El problema no estaba necesariamente en los productos, sino en que seguíamos partiendo de lo que sabíamos hacer, no de lo que los usuarios necesitaban de verdad.

Después de llevar un martillo durante diez años, aunque uno cambie de habitación, es fácil que todo siga pareciendo un clavo.

Entendí que entrar en un campo nuevo no consiste en cambiar de lugar para seguir usando los métodos que funcionaron antes. Empezar realmente de nuevo implica apartar por un tiempo las respuestas que mejor conocemos.

Así que me hice una pregunta: si no tuviera en cuenta la experiencia técnica acumulada en los últimos diez años, ¿qué producto de IA desearía más para mí?

Mi respuesta fueron las notas.

El producto que más quería

Desde la secundaria sigo una regla: «No leer sin escribir ni hacer anotaciones». Para mí, las notas nunca han sido solo un lugar donde guardar información. Son una extensión de la memoria y una parte del pensamiento.

La gente suele llamarlas un «segundo cerebro», pero ese supuesto segundo cerebro no es verdaderamente inteligente.

Ponemos cosas en él, pero seguimos teniendo que ordenarlas, encontrarlas, relacionarlas y pensar cómo recuperarlas. Se parece más a un disco duro externo que a otro cerebro.

Esta generación de grandes modelos me hizo creer por primera vez que eso podía cambiar de manera fundamental. Las notas del futuro quizá no solo conserven lo que una persona ha escrito. Podrían comprenderlo, descubrir las relaciones entre los contenidos, ayudarnos a recordar cuando lo necesitemos e incluso participar en nuestro pensamiento.

No quiero crear una aplicación de notas a la que se hayan añadido unas cuantas funciones de IA, sino un segundo cerebro verdaderamente inteligente.

La inteligencia general es el siguiente río al que salté. Las notas inteligentes son la primera dirección hacia la que decidí nadar una vez dentro.

Aún no he llegado a la otra orilla

Antes había hecho muchas cosas con rasgos de emprendimiento. Organizar el curso de verano en la universidad fue una empresa informal. Unirme a SenseTime en sus inicios fue participar en una empresa emergente. Fundar dentro de SenseTime los equipos de detección de vida y visión industrial también se parecía mucho a emprender dentro de una empresa.

Pero esta vez era distinto. En junio de este año dejé por primera vez una empresa, me expuse por completo al mercado y empecé a emprender a tiempo completo en el sentido real.

Hoy es 31 de diciembre de 2023. Ha pasado medio año desde que dejé SenseTime.

Aún no he encontrado las respuestas a todas las preguntas ni he llegado a una orilla que pueda llamarse éxito. Estoy aprendiendo muchas cosas que antes no dominaba: crear un producto, entender un mercado y lograr que ambos encajen.

Para muchas personas, este estado puede resultar doloroso. A mí me produce una familiaridad que echaba de menos, porque he vuelto a un lugar en el que no conozco las respuestas.

Este es el primer artículo de mi blog personal. No lo escribo porque el viaje haya terminado, sino porque quiero dejar constancia, justo cuando comienza de verdad, de por qué partí. En el futuro seguiré escribiendo aquí sobre tecnología, productos y personas, así como sobre las cosas que estoy creando.

No sé adónde llevará finalmente este río.

Pero, al mirar atrás, varios de los cambios importantes de mi vida empezaron con la misma elección: después de invertir suficiente tiempo y descubrir que iba entrando poco a poco en una zona de confort, comenzaba a buscar el siguiente río.

En junio de este año volví a elegirlo.

Todavía estoy en el agua.

Au moment de partir, je n’avais ni produit validé ni plan d’affaires complet. Je ne savais même pas encore précisément ce que j’allais faire.

Mais je savais qu’il était de nouveau temps de plonger dans la rivière suivante.

Ce n’était pas la première fois que je changeais de rivière, mais c’était la première fois que cela m’obligeait à quitter une entreprise.

Un choix que je fais sans cesse

Je suis passé d’une école primaire rurale à un collège du chef-lieu du district, puis j’ai fait mes études de premier cycle à l’université de Nankin et mes études supérieures à l’université Tsinghua. Pendant mon master, j’ai rejoint SenseTime, qui venait de démarrer. J’y ai d’abord fondé l’équipe de détection du vivant, puis l’équipe de vision industrielle.

Avec le recul, un changement de ce genre semble se produire tous les quelques ans.

Ces changements ne relevaient pas d’un projet de vie conçu à l’avance. Ils ne venaient pas non plus de ce que mon travail précédent aurait perdu son sens. Simplement, après des années d’efforts, le domaine et moi avions peu à peu mûri. Le travail n’était pas forcément terminé, mais il ne me forçait plus à dépasser mes propres limites.

Pour beaucoup, ce serait une situation idéale. Chez moi, elle provoque de l’inquiétude. Je n’aime pas une vie dont on peut déjà apercevoir le bout. À intervalles réguliers, j’ai donc besoin de me placer au cœur d’un problème que je ne sais pas résoudre, parfois même d’un problème dont j’ignore par où commencer.

La « rivière » n’est pas une entreprise. Changer de rivière ne signifie pas nécessairement démissionner. C’est entrer dans un domaine qu’il faut réapprendre, s’attaquer à une chose difficile que l’on ne sait pas encore mener à bien. Pendant mes presque dix années chez SenseTime, j’ai ainsi plongé dans deux rivières différentes.

Pour autant, je ne recherche pas le changement pour lui-même. Une autre force agit en moi, dans une direction presque opposée : le sens des responsabilités.

Je déteste abandonner les choses à mi-chemin. Dès que je décide de faire quelque chose, je veux le faire vraiment et bien le faire. Une force me pousse à chercher la rivière suivante ; l’autre me retient dans l’ancienne pour achever ce que j’ai commencé.

Mon départ cette année est le résultat d’un long affrontement entre ces deux forces.

Porter les algorithmes dans le monde réel

À mon arrivée chez SenseTime, je travaillais au département de recherche, mais ce qui m’intéressait depuis toujours, c’étaient les applications. Je ne voulais pas seulement savoir si un algorithme fonctionnait sur des données expérimentales. Je voulais savoir s’il pouvait entrer dans le monde réel et résoudre un problème concret.

La détection du vivant constituait le cœur du premier grand projet déployé par SenseTime. Auparavant, nous avions déjà de bonnes démonstrations de reconnaissance faciale. Mais face à une application réellement massive, nous avons découvert que de nombreux problèmes de production restaient sans solution, en particulier les attaques contre le système en ligne.

Le système recevait plus d’un million de visites par jour et, aux heures de pointe, pouvait subir plusieurs centaines de milliers d’attaques en une journée. Il fallait continuer à faire progresser la technologie tout en maintenant le service déjà en ligne. Le travail ressemblait souvent à un combat au corps à corps. Nous quittions régulièrement les bureaux à trois ou quatre heures du matin, quand nous n’y passions pas toute la nuit.

Il arrivait souvent qu’après un jour et une nuit de lutte, nous ayons corrigé toutes les attaques connues et soyons rentrés dormir. Peu après nous être couchés, le téléphone sonnait de nouveau : le système venait encore d’être compromis.

C’est au cours de ce processus que nous avons contribué à faire avancer l’architecture de modèles de bout en bout de SenseTime pour la reconnaissance faciale. Auparavant, de nombreux algorithmes d’apprentissage profond n’intervenaient que dans des étapes isolées, l’ensemble du système en enchaînant plusieurs. Mais face à des attaques en évolution constante, les méthodes assemblées manuellement ne permettaient pas d’itérer assez vite. La seule issue que nous voyions consistait à laisser un unique modèle d’apprentissage profond de bout en bout apprendre directement des données. À l’époque, nous l’appelions le « modèle unifié ».

Ce projet m’a fait comprendre pour la première fois qu’un algorithme efficace dans une démonstration n’est pas encore une technologie établie. Il ne devient réellement utilisable qu’après avoir résisté à un trafic massif, à des attaques continues et à toutes sortes d’imprévus.

Nous sommes ensuite entrés dans le secteur des smartphones. Avant chaque lancement, les fabricants organisaient des tests réunissant des centaines de personnes, tandis que les autres acteurs et les utilisateurs continuaient de découvrir de nouveaux problèmes. Cela nous a obligés à créer l’une des plus grandes équipes de test parmi les entreprises d’algorithmes d’IA que nous connaissions à l’époque, afin d’essayer d’épuiser toutes les possibilités.

Un problème de contre-jour ne pouvait être reproduit que dans des toilettes pour hommes bien précises, dans l’un des bureaux de SenseTime. Un autre, que nous appelions le « visage mi-ombre mi-lumière », n’apparaissait qu’à un angle particulier sous un arbre donné. Pour qu’un produit fonctionne de manière fiable dans le quotidien de centaines de millions de personnes, nous avons accompli énormément de travail de ce genre.

Nous avons fini par placer l’authentification d’identité sur smartphone en tête du marché.

Ce fut la première rivière dans laquelle je suis entré chez SenseTime. La détection du vivant avait commencé comme une démonstration de recherche, traversé plusieurs cycles d’applications à grande échelle, puis était devenue un domaine assez mûr. En 2019, beaucoup de problèmes qui exigeaient autrefois une exploration risquée pouvaient être résolus grâce à l’expérience accumulée. Je n’avais pas tout terminé, mais je savais que j’étais de nouveau entré dans une zone de confort.

J’ai alors recommencé à ne plus tenir en place.

Rester chez SenseTime et changer de rivière

En 2019, je n’ai pas quitté SenseTime. J’ai choisi de passer, au sein de la même entreprise, de l’authentification d’identité à la vision industrielle.

Après des recherches approfondies et de nombreuses discussions avec les dirigeants de l’entreprise et l’équipe commerciale, nous avons choisi comme premier projet de vision industrielle l’inspection intelligente de la caténaire C4 des lignes à grande vitesse.

Avec l’équipe d’avant-vente, j’ai visité de nombreux centres d’inspection et organismes ferroviaires. Celui de Xuzhou m’a le plus marqué. Il venait de pleuvoir lorsque nous sommes arrivés. Le centre se trouvait dans un endroit assez isolé et nous avons avancé sur une route boueuse, en nous enfonçant à chaque pas.

À l’intérieur s’alignaient des rangées d’ordinateurs. Les inspecteurs passaient une grande partie de leur journée à regarder des images pour repérer d’éventuelles défaillances de la caténaire. Presque tous avaient des cernes. Après avoir trouvé une panne, ils devaient encore parcourir des milliers de kilomètres de voies et traiter chaque problème. Il ne s’agissait parfois que d’une vis ou d’un écrou desserré, mais ils devaient tout de même se rendre sur place. Par froid glacial comme par chaleur accablante, l’intervention ne pouvait pas attendre.

Le besoin me paraissait douloureusement évident. Nous devions au moins les aider sur la tâche qui leur prenait le plus de temps : regarder les images.

Ce n’est qu’une fois lancés que nous avons découvert combien le problème était plus difficile que prévu. Une caténaire comprend plus de cent types de composants et plus de mille types de défauts. Même ces chiffres n’ont émergé qu’après de nombreux comptages et classements avec nos collègues de terrain. Une grande partie des inspections reposait sur l’expérience, tandis que les documents et données historiques étaient dispersés. Nous avons dû rassembler les informations à partir de zéro, travailler aux côtés des équipes de terrain et comprendre chaque type de défaut, un à un. Ce processus s’est étalé sur près de deux ans.

Le défi le plus important était celui du faible nombre d’exemples. Les pannes sur les lignes à grande vitesse sont extrêmement rares par nature. Certaines peuvent ne pas se produire une seule fois dans l’année, mais avoir des conséquences graves lorsqu’elles surviennent. Nous ne pouvions pas attendre d’avoir recueilli assez d’exemples. Il fallait repenser nos méthodes à partir des conditions réelles.

Finalement, le projet a réussi et a été déployé à grande échelle.

La vision industrielle a été ma deuxième rivière chez SenseTime. Je n’ai pas changé d’entreprise, mais presque tout ce qui m’était familier a changé : les problèmes, les données, les clients, les critères d’évaluation et la manière de travailler. Je suis redevenu débutant, puis j’ai accompli avec l’équipe quelque chose que nous ne savions pas faire au départ.

C’est pourquoi je dis que la rivière n’est pas l’entreprise. Ce qui m’attire vraiment n’est pas de quitter un endroit, mais d’entrer dans un problème plus difficile.

L’année 2022 sans changement de rivière

Après son introduction en bourse, SenseTime a commencé à subir de nouvelles pressions financières et matérielles. Dans le même temps, la vague précédente de vision par ordinateur entrait peu à peu dans sa phase de maturité, tandis que la suivante ne s’était pas encore clairement manifestée. Beaucoup de choses étaient limitées par les ressources, le marché ou les frontières de la technologie et ne pouvaient plus avancer aussi vite qu’avant.

Pendant toute l’année 2022, j’ai été quelque peu abattu ou, pour le dire autrement, plutôt résigné. J’ai commencé à travailler à des horaires normaux.

Cette phrase n’a rien de problématique. Avoir des horaires réguliers est la vie normale de beaucoup de gens. Mais j’avais toujours abordé mon travail comme une création d’entreprise. En entrant brusquement dans cet état, je me suis au contraire senti profondément découragé.

En apparence, cette vie était bien plus confortable qu’avant. Je ne me réveillais plus chaque jour avec un nouveau problème à résoudre impérativement, et je passais moins souvent la nuit à réparer une panne en ligne. Pourtant, c’est précisément ce confort qui me faisait souffrir : je commençais à pouvoir imaginer ma vie quelques années plus tard si rien ne changeait.

Je ne suis pas parti immédiatement. Ce qui m’a retenu, c’était la responsabilité.

L’inspection ferroviaire avait réussi, mais nous n’avions pas abouti pour le contrôle qualité dans les usines automobiles ni terminé le bras robotique industriel intelligent. Je voulais continuer à travailler sur ces sujets. Je pouvais difficilement accepter d’avoir fondé une équipe et choisi une direction, puis de partir au moment le plus difficile.

Une force me disait de chercher la rivière suivante ; l’autre, que le travail devant moi n’était pas achevé.

En 2022, la seconde force était plus puissante.

J’ai vu la rivière suivante

ChatGPT est apparu à la fin de l’année dernière. GPT-4 est arrivé pendant la première moitié de cette année. L’ancien équilibre s’est rompu.

J’ai alors ressenti quelque chose de très fort : la vision par ordinateur venait de se faire prendre sa propre base.

L’avenir ne serait pas composé de modèles indépendants pour le texte, l’image et la voix. La vision par ordinateur ne disparaîtrait pas, mais deviendrait une partie de la manière dont les modèles généraux comprennent le monde. Nous avions autrefois traité la vision comme un centre technologique complet ; une ère plus vaste d’intelligence générale commençait maintenant à apparaître.

Il ne s’agissait pas d’une nouvelle amélioration technique interne à la vision par ordinateur. Le courant principal du progrès technologique avait changé.

Je voyais de nouveau une rivière dont je ne connaissais pas encore les courants.

Auparavant, je pouvais changer de rivière sans quitter SenseTime. Passer de l’authentification à la vision industrielle en 2019 avait été un choix de ce type. Mais cette fois, la rivière suivante ne se trouvait pas dans le prolongement de mon travail précédent. Je voulais entrer dans l’intelligence générale et dans les nouvelles applications qu’elle créerait.

Mon poste et mes responsabilités restaient dans la vision industrielle. Si je restais, je devais me consacrer entièrement à ce travail. Je ne devais pas assumer mes responsabilités actuelles tout en préparant à côté ma prochaine destination.

Pour plonger réellement dans la rivière suivante, je devais d’abord quitter mon ancien rôle.

Au cours du premier semestre, il m’est devenu de plus en plus difficile de rester immobile. J’ignorais quels produits la nouvelle technologie finirait par créer et ce que je pourrais y faire. Mais je savais qu’en attendant d’avoir tout compris, je risquais de perdre les années pendant lesquelles il fallait avant tout commencer à apprendre.

Les choses qui comptent vraiment atteignent rarement un instant où l’on peut les déclarer « entièrement terminées ». Si la responsabilité exige d’attendre la fin de tous les problèmes, une personne risque de ne jamais faire un nouveau choix.

J’ai peu à peu compris que la responsabilité ne signifie pas seulement rester. Rester est aussi un choix, dont il faut assumer les conséquences. Le sens des responsabilités ne peut pas devenir une raison de repousser indéfiniment une décision.

C’est pourquoi, en juin de cette année, j’ai quitté SenseTime.

Pourquoi je suis parti sans réponse

Avant mon départ, je n’ai pas préparé secrètement une entreprise en dehors du travail. Je n’avais pas non plus l’intention de reprendre à mon compte l’activité que SenseTime développait.

Si je travaillais encore pour une entreprise, responsable de ses livrables et utilisant les ressources qu’elle me fournissait, tout en pensant intérieurement à préparer ma prochaine destination, j’aurais eu le sentiment de ne pas être honnête envers mon travail actuel.

Cela signifie qu’au moment de démissionner, je n’étais réellement pas prêt.

Je n’étais pas mal préparé parce que je ne prenais pas l’entrepreneuriat au sérieux, mais parce que, jusqu’à mon départ, je prenais encore mon travail précédent au sérieux.

Je ne pouvais que partir d’abord, puis chercher la réponse.

Savoir nager ne signifie pas connaître chaque rivière. On ne peut pas non plus rester sur la rive jusqu’à comprendre parfaitement le courant avant de plonger. Certaines connaissances ne s’acquièrent que dans l’eau, et certaines directions n’apparaissent qu’une fois en mouvement.

Cette fois, changer de rivière signifiait quitter mon emploi. Mais ce qui m’a poussé n’était pas le désir de démissionner en lui-même : c’était l’apparition de la rivière suivante.

Choisir le côté des applications

Après l’apparition de ChatGPT, j’ai discuté d’une question avec des amis : si l’AGI arrive, l’intelligence finira-t-elle concentrée entre les mains de quelques plateformes, ou sera-t-elle partagée plus largement ?

Mon jugement était qu’elle finirait nécessairement par se diffuser.

Je ne peux pas le démontrer rigoureusement. Mon intuition est simplement que l’univers lui-même n’est pas un système centralisé. Le monde réel est constitué d’innombrables personnes, appareils, environnements et problèmes locaux. Pour y entrer véritablement, l’intelligence devra elle aussi exister sous une multitude de formes. L’entraînement des modèles fondamentaux peut se concentrer dans quelques entreprises, mais les applications de l’intelligence n’appartiendront pas à quelques plateformes seulement.

Je ne veux donc pas construire de modèles fondamentaux. Je préfère créer des applications qui utilisent cette nouvelle intelligence pour répondre, une à une, à des demandes concrètes.

Ce choix vient aussi de ma vie.

J’ai grandi à la campagne. De l’école primaire au collège, j’ai consacré beaucoup de vacances et de temps libre aux travaux agricoles de ma famille. J’ai semé, épandu engrais et pesticides, conduit des tracteurs et élevé des animaux. Pendant les vacances, je me considérais comme un véritable agriculteur.

J’aimais le sentiment d’accomplissement que procurait ce travail. La réussite des cultures ou de l’élevage produisait un résultat direct et visible. Si l’on faisait un peu mieux son travail, la vie d’une famille s’améliorait un peu.

À l’université, j’ai eu de nombreux emplois à temps partiel et organisé avec des camarades un programme de cours d’été. Nous recrutions les élèves, encaissions les frais et donnions nous-mêmes les cours. Cet été-là, tous les participants ont gagné de quoi couvrir les dépenses de l’année suivante.

Pendant mes études supérieures, j’ai donné des cours particuliers. Plus tard, alors que SenseTime venait de démarrer et que ses bureaux occupaient encore une chambre de l’hôtel Wenjin près de la porte sud de Tsinghua, je l’ai rejointe comme l’un de ses premiers employés fondateurs.

En apparence, ces expériences ont peu de points communs. Mais elles me donnaient satisfaction de la même manière : résoudre un problème réel et voir une situation changer grâce à ma participation.

Ainsi, quand la nouvelle ère de l’intelligence générale est apparue, je me suis de nouveau placé instinctivement du côté des applications. Ce qui m’intéresse n’est pas de prouver qu’une technologie est plus puissante, mais de savoir ce qu’elle pourra finalement faire pour une personne concrète.

Après avoir plongé

Entrer dans la rivière suivante ne signifiait pas que je savais immédiatement vers où nager.

Pendant les premiers mois après mon départ de SenseTime, j’ai continué instinctivement à chercher des occasions dans ce que je connaissais le mieux. Avec un ami, j’ai essayé plusieurs produits liés à l’image. Après tout, presque dix années de mon travail avaient été consacrées à la vision par ordinateur. Partir de là semblait le choix le plus naturel.

Mais après un certain temps, j’ai de plus en plus senti que la direction n’était pas la bonne. Le problème ne venait pas forcément des produits eux-mêmes, mais du fait que nous partions encore de ce que nous savions faire, et non de ce dont les utilisateurs avaient réellement besoin.

Quand on porte un marteau depuis dix ans, même dans une autre pièce, tout continue facilement à ressembler à un clou.

J’ai compris qu’entrer dans un nouveau domaine ne consiste pas seulement à changer de lieu pour continuer d’appliquer les méthodes qui ont réussi autrefois. Recommencer vraiment exige de laisser temporairement de côté les réponses que l’on connaît le mieux.

Je me suis donc posé une question : si je ne tenais pas compte de l’expérience technique accumulée au cours des dix dernières années, quel produit d’IA voudrais-je le plus pour moi-même ?

Ma réponse a été : les notes.

Le produit que je désirais le plus

Depuis le collège, je suis une règle : « Ne jamais lire sans écrire ni annoter. » Pour moi, les notes n’ont jamais été un simple lieu de stockage. Elles prolongent la mémoire et font partie de la pensée.

On les appelle souvent un « second cerveau », mais ce prétendu second cerveau n’est pas réellement intelligent.

Nous y déposons des informations, mais devons encore les organiser, les retrouver, créer des liens et chercher comment les faire ressortir. Il ressemble davantage à un disque dur externe qu’à un autre cerveau.

Cette génération de grands modèles m’a fait croire pour la première fois que cela pouvait changer en profondeur. Les notes de demain ne se contenteront peut-être pas de conserver ce qu’une personne a écrit. Elles pourraient le comprendre, trouver les liens entre les idées, nous aider à nous souvenir au bon moment et même participer à notre réflexion.

Je ne veux pas créer un logiciel de notes auquel on aurait ajouté quelques fonctions d’IA, mais un second cerveau véritablement intelligent.

L’intelligence générale est la rivière suivante dans laquelle j’ai plongé. Les notes intelligentes sont la première direction vers laquelle j’ai décidé de nager une fois dans l’eau.

Pas encore sur l’autre rive

Auparavant, j’avais entrepris beaucoup de choses qui ressemblaient à de l’entrepreneuriat. Organiser les cours d’été à l’université était une création d’entreprise informelle. Rejoindre SenseTime à ses débuts, c’était participer à une création d’entreprise. Fonder les équipes de détection du vivant et de vision industrielle au sein de SenseTime ressemblait aussi à entreprendre dans une entreprise.

Mais cette fois était différente. En juin de cette année, j’ai quitté pour la première fois une entreprise, me suis placé entièrement face au marché et me suis lancé à plein temps dans l’entrepreneuriat au sens véritable.

Nous sommes le 31 décembre 2023. Six mois se sont écoulés depuis mon départ de SenseTime.

Je n’ai toujours pas trouvé la réponse à toutes les questions ni atteint une rive que l’on pourrait appeler le succès. J’apprends beaucoup de choses que je maîtrisais mal auparavant : construire un produit, comprendre un marché et parvenir à faire correspondre les deux.

Beaucoup trouveraient peut-être cet état pénible. Il m’apporte au contraire une familiarité qui m’avait manqué, car je suis de nouveau dans un endroit où je ne connais pas les réponses.

Voici le premier article de mon blog personnel. Je ne l’écris pas parce que ce voyage est terminé, mais parce que je veux consigner, au moment où il commence réellement, les raisons de mon départ. À l’avenir, je continuerai d’écrire ici sur la technologie, les produits, les personnes et les choses que je suis en train de créer.

Je ne sais pas où cette rivière finira par couler.

Mais avec le recul, plusieurs changements importants de ma vie ont commencé par le même choix : après avoir consacré assez de temps à un domaine et constaté que j’entrais peu à peu dans une zone de confort, je commençais à chercher la rivière suivante.

En juin de cette année, j’ai refait ce choix.

Je suis encore dans l’eau.

छोड़ते समय मेरे पास न कोई जाँचा-परखा उत्पाद था, न पूरी व्यवसाय योजना। मैंने यह भी ठीक से तय नहीं किया था कि मुझे करना क्या है।

लेकिन इतना जानता था कि मेरे लिए फिर से अगली नदी में छलांग लगाने का समय आ गया है।

यह पहली बार नहीं था जब मैं नदी बदल रहा था, मगर पहली बार ऐसा करने के लिए मुझे एक कंपनी छोड़नी पड़ी।

एक चुनाव जो मैं बार-बार करता हूँ

मैं गाँव के प्राथमिक विद्यालय से ज़िले के कस्बे के माध्यमिक विद्यालय पहुँचा। फिर नानजिंग विश्वविद्यालय में स्नातक और त्सिंगहुआ विश्वविद्यालय में स्नातकोत्तर अध्ययन किया। स्नातकोत्तर के दौरान मैं तब नई-नई शुरू हुई SenseTime से जुड़ा। वहाँ पहले मैंने जीवंतता पहचान की टीम बनाई और बाद में औद्योगिक विज़न की टीम।

पीछे मुड़कर देखता हूँ तो ऐसे बदलाव लगभग हर कुछ साल में हुए हैं।

ये पहले से बनाई गई जीवन योजना के हिस्से नहीं थे। न ही इसलिए हुए कि पहले का काम अर्थहीन हो गया था। बस कई साल लगाने के बाद वह क्षेत्र और मैं, दोनों धीरे-धीरे परिपक्व हो जाते थे। काम ज़रूरी नहीं कि पूरा हो चुका हो, पर वह मुझे अपनी सीमा तोड़ने के लिए मजबूर नहीं करता था।

बहुत लोगों के लिए यह आदर्श स्थिति होगी। मेरे लिए यह बेचैनी लाती है। मुझे ऐसा जीवन पसंद नहीं जिसका अंत वहीं से दिखाई दे जहाँ मैं खड़ा हूँ। इसलिए कुछ समय बाद मुझे स्वयं को किसी ऐसे सवाल के बीच रखना पड़ता है जिसे हल करना नहीं आता—कभी-कभी तो यह भी नहीं पता होता कि शुरुआत कहाँ से करूँ।

यहाँ “नदी” किसी कंपनी का नाम नहीं है। नदी बदलने का अर्थ हमेशा नौकरी छोड़ना भी नहीं है। नदी ऐसा क्षेत्र है जिसे फिर से सीखना पड़े, ऐसा कठिन काम जिसे पूरा करने का तरीका अभी मालूम न हो। SenseTime में अपने लगभग दस वर्षों के दौरान मैं दो अलग-अलग नदियों में उतरा।

लेकिन मैं केवल बदलाव के पीछे भागने वाला व्यक्ति भी नहीं हूँ। मेरे भीतर लगभग उलटी दिशा में खींचने वाली एक और शक्ति है: ज़िम्मेदारी का भाव।

मुझे काम अधूरा छोड़ना बिल्कुल पसंद नहीं। एक बार कुछ करने का निर्णय ले लूँ तो उसे सचमुच अच्छी तरह करना चाहता हूँ। एक शक्ति मुझे अगली नदी खोजने भेजती है; दूसरी पुरानी नदी में रोककर शुरू किए हुए काम को पूरा करने को कहती है।

इस साल मेरा जाना इन दोनों शक्तियों के लंबे संघर्ष का परिणाम था।

एल्गोरिदम को वास्तविक दुनिया तक ले जाना

SenseTime से जुड़ने पर मैं अनुसंधान विभाग में था, लेकिन मेरी रुचि हमेशा अनुप्रयोगों में रही। मैं केवल यह नहीं जानना चाहता था कि कोई एल्गोरिदम प्रयोगात्मक डेटा पर काम करता है या नहीं, बल्कि यह कि वह वास्तविक दुनिया में जाकर किसी ठोस समस्या को हल कर सकता है या नहीं।

जीवंतता पहचान SenseTime की पहली बड़ी तैनाती का मुख्य हिस्सा थी। उससे पहले हमारे पास चेहरा पहचानने के कुछ अच्छे डेमो थे। लेकिन सचमुच बड़े पैमाने के उपयोग का सामना करने पर पता चला कि उत्पादन से जुड़ी बहुत-सी समस्याएँ अनसुलझी थीं, खासकर ऑनलाइन सिस्टम पर होने वाले हमले।

उस समय सिस्टम पर रोज़ दस लाख से अधिक पहुँच होती थी। चरम समय में एक ही दिन में कई लाख हमले तक होते थे। तकनीक को आगे बढ़ाना था और पहले से चल रही सेवा को भी संभाले रखना था। इसलिए बहुत बार काम आमने-सामने की लड़ाई जैसा था। हम अक्सर रात के तीन या चार बजे दफ़्तर से निकलते और कभी पूरी रात वहीं रहते।

अक्सर हम दिन-रात लड़कर सभी ज्ञात हमलों का हल निकालते और सोने के लिए घर लौटते। सोए कुछ ही देर हुई होती कि फ़ोन फिर बजता: ऑनलाइन सिस्टम फिर तोड़ दिया गया था।

इसी प्रक्रिया में हमने चेहरा पहचानने के लिए SenseTime की एंड-टू-एंड मॉडल व्यवस्था को आगे बढ़ाने में हिस्सा लिया। इससे पहले बहुत-से डीप लर्निंग एल्गोरिदम केवल अलग-अलग हिस्सों में इस्तेमाल होते थे, और पूरा सिस्टम कई चरणों को जोड़कर बनता था। लेकिन लगातार बदलते हमलों के सामने हाथ से जोड़े गए तरीके इतनी तेज़ी से सुधारे नहीं जा सकते थे। हमें एक ही रास्ता दिखा: एक एंड-टू-एंड डीप लर्निंग मॉडल को सीधे डेटा से सीखने दिया जाए। उस समय हम इसे “एकीकृत मॉडल” कहते थे।

इस परियोजना ने पहली बार मुझे सच में समझाया कि किसी एल्गोरिदम का डेमो में काम करना उसके पूरी तरह सफल तकनीक बन जाने के बराबर नहीं है। वह तभी वास्तव में उपयोगी तकनीक बनता है जब बड़े पैमाने के ट्रैफ़िक, लगातार हमलों और तरह-तरह की अनपेक्षित परिस्थितियों की परीक्षा सह ले।

बाद में हम स्मार्टफ़ोन के क्षेत्र में गए। हर लॉन्च से पहले फ़ोन निर्माता सैकड़ों लोगों से परीक्षण कराते थे, और दूसरी कंपनियाँ तथा उपयोगकर्ता भी नई समस्याएँ खोजते रहते थे। इससे हमें उस समय की हमारी जानकारी के अनुसार किसी AI एल्गोरिदम कंपनी की सबसे बड़ी परीक्षण टीमों में से एक बनानी पड़ी, ताकि हर संभावना को खोज सकें।

बैकलाइट की एक समस्या केवल SenseTime के एक कार्यालय के किसी खास पुरुष शौचालय में दोहराई जा सकती थी। दूसरी समस्या, जिसे हम “आधा उजला, आधा अँधेरा चेहरा” कहते थे, किसी विशेष पेड़ के नीचे एक निश्चित कोण पर ही दिखाई देती थी। करोड़ों लोगों की रोज़मर्रा की ज़िंदगी में उत्पाद को भरोसेमंद बनाने के लिए हमने इस तरह का बहुत काम किया।

अंततः स्मार्टफ़ोन पर पहचान प्रमाणीकरण को हमने बाज़ार में अग्रणी बना दिया।

यह SenseTime में मेरी पहली नदी थी। जीवंतता पहचान शोध के एक डेमो से शुरू हुई, बड़े पैमाने के कई उपयोगों की कसौटी से गुज़री और अंततः काफी परिपक्व क्षेत्र बन गई। 2019 तक, जिन समस्याओं के लिए कभी जोखिम उठाकर खोज करनी पड़ती थी, उनमें से बहुतों को संचित अनुभव से हल किया जा सकता था। मैंने सब कुछ पूरा नहीं किया था, मगर जानता था कि फिर से सहज क्षेत्र में पहुँच गया हूँ।

तब मैं फिर बेचैन होने लगा।

SenseTime में रहकर नदी बदलना

2019 में मैंने SenseTime नहीं छोड़ी। उसी कंपनी के भीतर पहचान प्रमाणीकरण से औद्योगिक विज़न की ओर जाने का चुनाव किया।

व्यापक शोध और कंपनी के नेतृत्व तथा व्यावसायिक टीम से कई चर्चाओं के बाद हमने अपनी पहली औद्योगिक विज़न परियोजना के रूप में हाई-स्पीड रेलवे की C4 ऊपरी संपर्क-तार प्रणाली का बुद्धिमान निरीक्षण चुना।

मैंने प्रीसेल्स टीम के साथ कई रेलवे निरीक्षण केंद्रों और रेलवे ब्यूरो का दौरा किया। शूझोउ का निरीक्षण केंद्र मेरे मन पर सबसे गहरी छाप छोड़ गया। हमारे पहुँचने से पहले बारिश हुई थी। केंद्र काफ़ी दूर था और हम कीचड़ भरे रास्ते में हर कदम पर धँसते हुए अंदर पहुँचे।

भीतर कंप्यूटरों की लंबी कतारें थीं। निरीक्षक रोज़ बहुत समय तस्वीरें देखकर रेलवे के संपर्क-तार में संभावित खराबियाँ खोजने में लगाते थे। लगभग सभी की आँखों के नीचे काले घेरे थे। खराबी मिलने के बाद भी उन्हें हज़ारों किलोमीटर की रेल लाइन पर जाकर हर समस्या एक-एक करके ठीक करनी पड़ती थी। कभी केवल कोई पेंच या नट ढीला होता, फिर भी उन्हें मौके पर पहुँचना होता। कड़कड़ाती ठंड हो या तपती गर्मी, मरम्मत टाली नहीं जा सकती थी।

यह ज़रूरत मुझे बेहद तीखी लगी। कम-से-कम सबसे अधिक समय लेने वाले काम—तस्वीरें देखने—में तो हमें उनकी मदद करनी चाहिए थी।

काम शुरू करने के बाद ही पता चला कि समस्या कल्पना से कहीं कठिन है। संपर्क-तार प्रणाली में सौ से अधिक तरह के पुर्ज़े और एक हज़ार से अधिक तरह के दोष होते हैं। ये संख्याएँ भी मैदानी सहकर्मियों के साथ बार-बार गिनने और व्यवस्थित करने के बाद सामने आईं। पुराने निरीक्षण का बड़ा हिस्सा अनुभव पर निर्भर था, और दस्तावेज़ तथा ऐतिहासिक डेटा अलग-अलग जगह बिखरे थे। हमें सब कुछ शुरू से इकट्ठा करना पड़ा, अग्रिम पंक्ति के सहकर्मियों के साथ काम करना पड़ा और हर दोष को एक-एक करके समझना पड़ा। इस प्रक्रिया में लगभग दो साल लगे।

बड़ी चुनौती छोटे नमूने थे। हाई-स्पीड रेलवे पर खराबियाँ स्वभावतः बहुत दुर्लभ होती हैं। कुछ साल में एक बार भी नहीं आतीं, लेकिन आने पर गंभीर परिणाम हो सकते हैं। पर्याप्त नमूने जमा होने तक हम इंतज़ार नहीं कर सकते थे। वास्तविक परिस्थितियों के अनुसार तरीकों को फिर से बनाना पड़ा।

आखिरकार परियोजना सफल हुई और बड़े पैमाने पर लागू की गई।

औद्योगिक विज़न SenseTime में मेरी दूसरी नदी थी। कंपनी नहीं बदली, लेकिन लगभग हर परिचित चीज़ बदल गई: समस्या, डेटा, ग्राहक, मूल्यांकन के मानदंड और काम करने का तरीका। मैं फिर से नौसिखिया बना और टीम के साथ मिलकर वह काम कर दिखाया जिसे पहले करना नहीं आता था।

इसीलिए मैं कहता हूँ कि नदी कंपनी नहीं है। मुझे किसी जगह से जाना नहीं, बल्कि किसी अधिक कठिन समस्या में प्रवेश करना आकर्षित करता है।

2022, जब मैंने नदी नहीं बदली

शेयर बाज़ार में सूचीबद्ध होने के बाद SenseTime पर नई वित्तीय और संसाधन संबंधी दबाव आए। उसी समय कंप्यूटर विज़न की पिछली लहर धीरे-धीरे परिपक्व हो रही थी और अगली लहर अभी स्पष्ट नहीं हुई थी। संसाधनों, बाज़ार या तकनीकी सीमाओं के कारण बहुत-से काम पहले जितनी तेज़ी से आगे बढ़ना मुश्किल हो गया था।

पूरे 2022 में मैं कुछ हतोत्साहित, या कहें कि थोड़ा निष्क्रिय था। मैंने सामान्य समय पर दफ़्तर आना-जाना शुरू कर दिया।

इस वाक्य में कोई बुराई नहीं है। नियमित समय पर काम करना बहुत लोगों का सामान्य जीवन है। लेकिन मैंने अपने काम को हमेशा उद्यम की तरह लिया था। अचानक इस अवस्था में आकर मैं उलटे बहुत निराश हो गया।

ऊपर से वह जीवन पहले से कहीं अधिक आरामदेह था। हर सुबह कोई नई समस्या अनिवार्य रूप से हल करने को नहीं होती थी और किसी ऑनलाइन गड़बड़ी के कारण रात भर जागना भी कम हो गया था। मगर मुझे सबसे अधिक यही आराम खलता था: मैं कल्पना करने लगा था कि कुछ न बदला तो कई साल बाद मेरा जीवन कैसा होगा।

मैं तुरंत नहीं गया। मुझे ज़िम्मेदारी ने रोके रखा।

हाई-स्पीड रेलवे निरीक्षण सफल था, लेकिन मोटर वाहन कारखानों का गुणवत्ता निरीक्षण सफल नहीं हुआ था और बुद्धिमान औद्योगिक रोबोटिक भुजा भी पूरी नहीं हुई थी। मैं इन कामों को जारी रखना चाहता था। अपनी टीम बनाने और दिशा चुनने के बाद उसके सबसे कठिन समय में चले जाने को मैं आसानी से स्वीकार नहीं कर सकता था।

एक शक्ति कहती थी कि अगली नदी खोजो; दूसरी कहती थी कि सामने का काम अभी पूरा नहीं हुआ।

2022 में दूसरी शक्ति अधिक मज़बूत थी।

मुझे अगली नदी दिखाई दी

पिछले साल के अंत में ChatGPT आया। इस साल की पहली छमाही में GPT-4 आया। पुराना संतुलन टूट गया।

उस समय मुझे बहुत तीव्र अनुभूति हुई: कंप्यूटर विज़न का अपना गढ़ छिन गया था।

भविष्य पाठ, चित्र और आवाज़ के अलग-अलग मॉडलों से नहीं बनेगा। कंप्यूटर विज़न गायब नहीं होगा, लेकिन सामान्य मॉडल के दुनिया को समझने का एक हिस्सा बन जाएगा। पहले हम विज़न को एक संपूर्ण तकनीकी केंद्र मानते थे; अब सामान्य बुद्धिमत्ता का एक बड़ा युग उभर रहा था।

यह कंप्यूटर विज़न के भीतर का कोई और तकनीकी उन्नयन नहीं था। तकनीकी विकास की मुख्य धारा ही बदल गई थी।

मुझे फिर एक ऐसी नदी दिखाई दी जिसकी धाराओं से मैं परिचित नहीं था।

पहले मैं SenseTime के भीतर रहते हुए नदी बदल सकता था। 2019 में पहचान प्रमाणीकरण से औद्योगिक विज़न की ओर जाना ऐसा ही चुनाव था। लेकिन इस बार अगली नदी मेरे पुराने काम की सीधी अगली कड़ी नहीं थी। मैं सामान्य बुद्धिमत्ता और उससे बनने वाले नए अनुप्रयोगों में प्रवेश करना चाहता था।

उस समय मेरी भूमिका और ज़िम्मेदारी अब भी औद्योगिक विज़न में थी। अगर रहता, तो मुझे पूरी शक्ति से वही काम अच्छी तरह करना चाहिए था। पुरानी ज़िम्मेदारियाँ उठाते हुए अपने अगले पड़ाव की तैयारी साथ-साथ नहीं करनी चाहिए थी।

सचमुच अगली नदी में कूदने के लिए पहले अपनी पुरानी भूमिका छोड़ना ज़रूरी था।

इस साल की पहली छमाही तक मेरे लिए स्थिर बैठना लगातार कठिन हो गया। मैं नहीं जानता था कि नई तकनीक अंततः कौन-से उत्पाद बनाएगी या उसमें मैं क्या कर सकूँगा। लेकिन जानता था कि सब कुछ पूरी तरह समझने तक प्रतीक्षा की, तो शायद उन वर्षों को खो दूँगा जब सीखना शुरू करना सबसे ज़रूरी था।

सचमुच महत्वपूर्ण कामों में अक्सर ऐसा क्षण नहीं आता जब उन्हें “पूरी तरह समाप्त” घोषित किया जा सके। अगर ज़िम्मेदारी का अर्थ हर समस्या के खत्म होने तक प्रतीक्षा करना है, तो शायद कोई व्यक्ति कभी नया चुनाव नहीं कर पाएगा।

धीरे-धीरे मैंने समझा कि ज़िम्मेदारी केवल रुके रहने का नाम नहीं है। रुकना भी एक चुनाव है और उसके परिणाम भी उठाने पड़ते हैं। ज़िम्मेदारी का भाव निर्णय को अनंत समय तक टालने का कारण नहीं बन सकता।

इसलिए इस साल जून में मैंने SenseTime छोड़ दी।

बिना उत्तर के जाने का कारण

जाने से पहले मैंने काम के बाहर चुपचाप उद्यम की तैयारी नहीं की, न SenseTime के चल रहे व्यवसाय को बाहर ले जाकर अपनी कंपनी बनाने की योजना बनाई।

यदि मैं किसी कंपनी में काम कर रहा हूँ, उसके परिणाम देने की ज़िम्मेदारी उठाता हूँ और उसके दिए संसाधन इस्तेमाल करता हूँ, लेकिन मन ही मन अपने अगले पड़ाव की तैयारी सोच रहा हूँ, तो मुझे लगेगा कि मैं अपने मौजूदा काम के प्रति ईमानदार नहीं हूँ।

इसका अर्थ था कि नौकरी छोड़ते समय मैं सचमुच तैयार नहीं था।

मैं उद्यम के लिए इसलिए तैयार नहीं था कि उसे गंभीरता से नहीं लेता था, बल्कि इसलिए कि जाने से पहले तक मैं अपने पुराने काम को गंभीरता से ले रहा था।

मेरे पास पहले जाने और फिर उत्तर खोजने के अलावा कोई रास्ता नहीं था।

तैरना आना हर नदी को जानना नहीं है। कोई व्यक्ति किनारे पर खड़े होकर धारा को पूरी तरह समझ लेने के बाद ही छलांग भी नहीं लगा सकता। कुछ ज्ञान केवल पानी में मिलता है, और कुछ दिशाएँ चलना शुरू करने के बाद ही दिखाई देती हैं।

इस बार नदी बदलने का अर्थ नौकरी छोड़ना था। लेकिन मुझे जाने के लिए प्रेरित करने वाली चीज़ नौकरी छोड़ने की इच्छा नहीं, अगली नदी का दिखाई देना था।

अनुप्रयोगों की ओर चुनाव

ChatGPT आने के बाद मैंने दोस्तों के साथ एक सवाल पर चर्चा की: अगर AGI आ गया, तो बुद्धिमत्ता अंत में कुछ ही प्लेटफ़ॉर्मों के हाथ में केंद्रित होगी या अधिक लोगों के बीच बाँटी जाएगी?

मेरा आकलन था कि अंततः वह ज़रूर फैलेगी।

मैं इसे कड़ाई से सिद्ध नहीं कर सकता। मेरा सहज बोध बस इतना है कि ब्रह्मांड स्वयं कोई केंद्रीकृत व्यवस्था नहीं है। वास्तविक दुनिया अनगिनत लोगों, उपकरणों, परिवेशों और स्थानीय समस्याओं से बनी है। अगर बुद्धिमत्ता सच में इस दुनिया में प्रवेश करेगी, तो उसे भी अनगिनत रूपों में मौजूद होना होगा। आधारभूत मॉडलों का प्रशिक्षण कुछ कंपनियों में केंद्रित हो सकता है, लेकिन बुद्धिमत्ता के अनुप्रयोग केवल कुछ प्लेटफ़ॉर्मों के नहीं होंगे।

इसीलिए मैं आधारभूत मॉडल नहीं बनाना चाहता। मैं ऐसे अनुप्रयोग बनाना चाहता हूँ जो नई बुद्धिमत्ता से एक-एक ठोस ज़रूरत का उत्तर दें।

यह चुनाव मेरे जीवन के अनुभव से भी आता है।

मैं गाँव में बड़ा हुआ। प्राथमिक से माध्यमिक विद्यालय तक बहुत-सी छुट्टियाँ और खाली समय परिवार के खेत के काम में लगाया। बीज बोना, खाद और कीटनाशक डालना, ट्रैक्टर चलाना और पशु पालना—मैंने लगभग सब किया। छुट्टियों में मैं स्वयं को सचमुच किसान मानता था।

मुझे इस काम से मिलने वाली उपलब्धि का भाव पसंद था। फसल अच्छी हुई या नहीं, पशु अच्छी तरह पले या नहीं—नतीजा साफ़ दिखाई देता था। काम थोड़ा बेहतर करने पर किसी परिवार का जीवन थोड़ा बेहतर हो जाता था।

विश्वविद्यालय में मैंने कई अंशकालिक काम किए और सहपाठियों के साथ गर्मियों की एक कक्षा भी चलाई। विद्यार्थियों को लाना, शुल्क लेना और पढ़ाना—सब हमने स्वयं किया। उस गर्मी में शामिल सभी साथियों ने अगले साल के जीवन-यापन के लिए पर्याप्त पैसे कमाए।

स्नातकोत्तर पढ़ाई के दौरान मैंने निजी ट्यूशन दिया। बाद में, जब SenseTime बस शुरू हुई थी और उसका कार्यालय त्सिंगहुआ के दक्षिणी द्वार के पास वेनजिन होटल के एक कमरे में था, मैं शुरुआती संस्थापक कर्मचारी के रूप में उससे जुड़ा।

ऊपर से इन कामों में कम समानता दिखती है। लेकिन वे मुझे एक ही तरह से उपलब्धि का अनुभव देते थे: कोई वास्तविक समस्या हल करना और अपनी भागीदारी से चीज़ों को बदलते देखना।

इसलिए सामान्य बुद्धिमत्ता का नया युग दिखाई देने पर मैं फिर सहज रूप से अनुप्रयोगों की ओर खड़ा हुआ। मेरी चिंता यह सिद्ध करना नहीं कि तकनीक अधिक शक्तिशाली है, बल्कि यह है कि वह अंततः किसी ठोस व्यक्ति के लिए क्या कर सकती है।

छलांग लगाने के बाद

अगली नदी में उतरने का अर्थ यह नहीं था कि मुझे तुरंत पता चल गया कि किस दिशा में तैरना है।

SenseTime छोड़ने के शुरुआती महीनों में मैं सहज रूप से वहीं अवसर ढूँढ़ता रहा जिसे सबसे अच्छी तरह जानता था। एक दोस्त के साथ चित्रों से जुड़े कुछ उत्पाद आज़माए। आखिर मेरे लगभग दस साल का काम कंप्यूटर विज़न से जुड़ा था। वहीं से शुरू करना सबसे स्वाभाविक लगा।

लेकिन कुछ समय काम करने के बाद मुझे लगातार लगा कि दिशा ठीक नहीं है। समस्या ज़रूरी नहीं कि उन उत्पादों में थी। समस्या यह थी कि हम अब भी इस बात से शुरू कर रहे थे कि हमें क्या करना आता है, न कि उपयोगकर्ताओं को वास्तव में क्या चाहिए।

दस साल तक हाथ में हथौड़ा रहे तो कमरा बदलने के बाद भी हर चीज़ कील जैसी दिखाई देना आसान है।

मैंने समझा कि नए क्षेत्र में प्रवेश करना केवल जगह बदलकर पुराने सफल तरीकों को जारी रखना नहीं है। सचमुच फिर से शुरू करने का अर्थ है अपने सबसे परिचित उत्तरों को कुछ समय के लिए अलग रख देना।

तब मैंने स्वयं से पूछा: पिछले दस साल की तकनीकी पूँजी को न देखूँ, तो मुझे अपने लिए सबसे अधिक कौन-सा AI उत्पाद चाहिए?

मेरा उत्तर था: नोट्स।

वह उत्पाद जो मुझे सबसे अधिक चाहिए था

माध्यमिक विद्यालय से मेरी आदत रही है: “लिखे और निशान लगाए बिना मत पढ़ो।” मेरे लिए नोट्स केवल सामग्री रखने की जगह कभी नहीं रहे। वे स्मृति का विस्तार और सोच का एक हिस्सा हैं।

लोग अक्सर नोट्स को “दूसरा दिमाग” कहते हैं, लेकिन यह तथाकथित दूसरा दिमाग वास्तव में बुद्धिमान नहीं है।

हम उसमें चीज़ें डालते हैं, फिर भी उन्हें व्यवस्थित करना, खोजना, उनके बीच संबंध बनाना और दोबारा निकालने का तरीका सोचना स्वयं पड़ता है। वह दूसरे दिमाग से अधिक किसी बाहरी हार्ड ड्राइव जैसा है।

बड़े मॉडलों की इस पीढ़ी ने पहली बार मुझे विश्वास दिलाया कि यह स्थिति मूल रूप से बदल सकती है। भविष्य के नोट्स शायद केवल यह सुरक्षित न रखें कि किसी व्यक्ति ने क्या लिखा। वे उसे समझ सकेंगे, बातों के बीच संबंध खोज सकेंगे, ज़रूरत पर याद दिला सकेंगे, और शायद हमारी सोच में भाग भी ले सकेंगे।

मैं कुछ AI सुविधाएँ जोड़कर बना नोट्स सॉफ़्टवेयर नहीं, बल्कि सचमुच बुद्धिमान दूसरा दिमाग बनाना चाहता हूँ।

सामान्य बुद्धिमत्ता वह अगली नदी है जिसमें मैंने छलांग लगाई। बुद्धिमान नोट्स वह पहली दिशा है जिसकी ओर मैंने भीतर पहुँचकर तैरने का निर्णय लिया।

अभी दूसरे किनारे पर नहीं पहुँचा

इससे पहले मैंने कई ऐसे काम किए जिनमें उद्यमिता का स्वभाव था। विश्वविद्यालय में गर्मियों की कक्षा चलाना एक अनौपचारिक उद्यम था। शुरुआती SenseTime से जुड़ना किसी उद्यम में भाग लेना था। SenseTime के भीतर जीवंतता पहचान और औद्योगिक विज़न की टीमें बनाना भी किसी कंपनी के भीतर उद्यम बनाने जैसा था।

लेकिन इस बार बात अलग थी। इस साल जून में मैंने पहली बार किसी कंपनी को छोड़ा, स्वयं को पूरी तरह बाज़ार के सामने रखा और वास्तविक अर्थ में पूर्णकालिक उद्यम शुरू किया।

आज 31 दिसंबर 2023 है। SenseTime छोड़े आधा साल हो गया है।

मुझे अभी सभी सवालों के जवाब नहीं मिले और मैं ऐसे किसी दूसरे किनारे पर नहीं पहुँचा जिसे सफलता कहा जा सके। मैं बहुत-सी ऐसी बातें सीख रहा हूँ जिनमें पहले कुशल नहीं था: उत्पाद बनाना, बाज़ार समझना और दोनों का मेल बैठाना।

बहुत लोगों के लिए यह अवस्था कष्टदायक हो सकती है। मुझे इसमें लंबे समय बाद एक परिचित भाव मिलता है, क्योंकि मैं फिर ऐसी जगह हूँ जहाँ उत्तर नहीं जानता।

यह मेरे निजी ब्लॉग का पहला लेख है। मैं इसे इसलिए नहीं लिख रहा कि यात्रा समाप्त हो गई, बल्कि इसलिए कि जब वह सचमुच शुरू हो रही है, तब दर्ज करना चाहता हूँ कि मैंने प्रस्थान क्यों किया। आगे भी यहाँ तकनीक, उत्पादों, लोगों और अपनी बनाई जा रही चीज़ों के बारे में लिखता रहूँगा।

मैं नहीं जानता यह नदी अंततः कहाँ जाएगी।

लेकिन पीछे मुड़कर देखता हूँ तो मेरे जीवन के कई बड़े बदलाव एक ही चुनाव से शुरू हुए: पर्याप्त लंबा समय लगाने और स्वयं को धीरे-धीरे सहज क्षेत्र में पहुँचते देखने पर मैंने अगली नदी खोजनी शुरू की।

इस साल जून में मैंने वही चुनाव फिर किया।

मैं अभी भी पानी में हूँ।

Saat pergi, saya tidak memiliki produk yang sudah tervalidasi ataupun rencana bisnis yang lengkap. Saya bahkan belum menentukan dengan jelas apa yang akan saya kerjakan.

Namun saya tahu bahwa sudah waktunya bagi saya untuk kembali melompat ke sungai berikutnya.

Ini bukan pertama kalinya saya berganti sungai, tetapi untuk pertama kalinya saya harus meninggalkan sebuah perusahaan demi melakukannya.

Pilihan yang terus saya buat

Saya berpindah dari sekolah dasar di desa ke sekolah menengah di kota kabupaten, lalu menempuh studi sarjana di Universitas Nanjing dan pascasarjana di Universitas Tsinghua. Saat kuliah pascasarjana, saya bergabung dengan SenseTime yang baru berdiri. Di sana saya mula-mula mendirikan tim deteksi keaktifan, kemudian tim visi industri.

Jika menoleh ke belakang, perubahan seperti ini tampaknya terjadi setiap beberapa tahun.

Perubahan itu bukan bagian dari rencana hidup yang disusun sebelumnya. Perubahan juga bukan terjadi karena pekerjaan lama kehilangan makna. Hanya saja, setelah bertahun-tahun mencurahkan usaha, bidang itu dan saya sendiri berangsur matang. Pekerjaan belum tentu selesai, tetapi tidak lagi memaksa saya melampaui batas diri.

Bagi banyak orang, itu adalah keadaan ideal. Bagi saya, keadaan itu justru menimbulkan kegelisahan. Saya tidak menyukai hidup yang ujungnya sudah dapat terlihat. Karena itu, setiap beberapa waktu saya perlu menempatkan diri di dalam masalah yang tidak saya kuasai—bahkan terkadang tidak saya ketahui harus dimulai dari mana.

“Sungai” di sini bukan sebuah perusahaan. Berganti sungai juga tidak selalu berarti mengundurkan diri. Sungai adalah bidang yang harus dipelajari kembali, sesuatu yang sulit dan belum saya ketahui cara mewujudkannya. Selama hampir sepuluh tahun di SenseTime, saya pernah melompat ke dua sungai yang berbeda.

Namun saya bukan orang yang semata-mata mengejar perubahan. Ada kekuatan lain di dalam diri saya yang arahnya hampir berlawanan: rasa tanggung jawab.

Saya sangat tidak suka meninggalkan sesuatu setengah jalan. Begitu memutuskan untuk mengerjakan sesuatu, saya ingin sungguh-sungguh mengerjakannya dengan baik. Satu kekuatan membuat saya mencari sungai berikutnya; kekuatan yang lain menahan saya di sungai lama agar menyelesaikan apa yang sudah dimulai.

Kepergian saya tahun ini merupakan hasil pertarungan panjang di antara kedua kekuatan itu.

Membawa algoritma ke dunia nyata

Ketika pertama kali bergabung dengan SenseTime, saya berada di departemen riset. Namun yang selalu saya pedulikan adalah penerapan. Saya tidak hanya ingin tahu apakah suatu algoritma bekerja pada data eksperimen, tetapi apakah algoritma itu dapat masuk ke dunia nyata dan memecahkan masalah konkret.

Deteksi keaktifan merupakan bagian inti dari proyek penerapan besar pertama SenseTime. Sebelumnya, kami sudah memiliki beberapa demo pengenalan wajah yang bagus. Akan tetapi, ketika menghadapi penerapan berskala besar yang sesungguhnya, kami baru menemukan bahwa banyak masalah produksi belum terpecahkan, terutama serangan terhadap sistem daring.

Saat itu sistem menerima lebih dari satu juta kunjungan per hari. Pada puncaknya, dalam sehari sistem bahkan menghadapi ratusan ribu serangan. Teknologi harus terus dikembangkan, sementara layanan yang sudah berjalan juga harus tetap ditopang. Karena itu, pekerjaan kami sering terasa seperti pertarungan jarak dekat. Kami kerap baru meninggalkan kantor pukul tiga atau empat pagi, dan terkadang bekerja sepanjang malam.

Yang sering terjadi, kami berjuang siang dan malam, mengatasi semua serangan yang diketahui, lalu pulang untuk tidur. Tidak lama setelah terlelap, telepon kembali berdering: sistem daring berhasil ditembus lagi.

Dalam proses itulah kami ikut mendorong terbentuknya arsitektur model pengenalan wajah end-to-end di SenseTime. Sebelumnya, banyak algoritma pembelajaran mendalam hanya digunakan pada bagian-bagian tertentu, sedangkan keseluruhan sistem terdiri atas beberapa tahap yang dirangkai. Namun menghadapi serangan yang terus berubah, metode yang dirakit secara manual tidak dapat mengikuti kebutuhan iterasi yang cepat. Satu-satunya jalan keluar yang kami lihat adalah membiarkan sebuah model pembelajaran mendalam end-to-end belajar langsung dari data. Saat itu kami menyebutnya “model terpadu”.

Proyek ini untuk pertama kalinya membuat saya benar-benar memahami bahwa algoritma yang bekerja dalam demo belum tentu sudah menjadi teknologi yang mapan. Teknologi baru benar-benar dapat digunakan setelah bertahan terhadap akses berskala besar, serangan terus-menerus, dan berbagai keadaan tak terduga.

Kemudian kami memasuki ranah ponsel pintar. Sebelum setiap peluncuran, produsen ponsel mengadakan pengujian dengan ratusan orang, sementara perusahaan lain dan pengguna terus menemukan masalah baru. Hal ini memaksa kami membentuk salah satu tim pengujian terbesar di antara perusahaan algoritma AI yang kami ketahui pada waktu itu, demi mencoba menjangkau semua kemungkinan.

Satu masalah cahaya latar hanya dapat direproduksi di toilet pria tertentu di salah satu kantor SenseTime. Masalah lain, yang kami sebut “wajah separuh terang”, hanya muncul dari sudut tertentu di bawah sebuah pohon tertentu. Agar sebuah produk dapat bekerja andal dalam kehidupan sehari-hari ratusan juta orang, kami melakukan sangat banyak pekerjaan semacam ini.

Pada akhirnya, kami menjadikan autentikasi identitas pada ponsel pintar sebagai pemimpin pasar.

Inilah sungai pertama yang saya masuki di SenseTime. Deteksi keaktifan berawal dari demo riset, melewati beberapa putaran pengujian dalam penerapan berskala besar, dan akhirnya menjadi bidang yang cukup matang. Pada 2019, banyak masalah yang dahulu harus dijelajahi dengan risiko sudah dapat diatasi lewat pengalaman yang terkumpul. Saya belum menyelesaikan semuanya, tetapi tahu bahwa saya kembali memasuki zona nyaman.

Maka saya kembali merasa gelisah.

Tetap di SenseTime, berganti sungai

Pada 2019, saya tidak meninggalkan SenseTime. Saya memilih beralih dari autentikasi identitas ke visi industri di dalam perusahaan yang sama.

Setelah melakukan banyak riset dan berdiskusi berulang kali dengan pimpinan perusahaan serta tim bisnis, kami memilih inspeksi cerdas sistem kabel kontak C4 kereta cepat sebagai proyek visi industri pertama.

Saya bersama tim prapenjualan mengunjungi banyak pusat inspeksi dan biro perkeretaapian. Pusat inspeksi Xuzhou meninggalkan kesan paling mendalam. Ketika kami datang, hujan baru saja berhenti. Pusat itu berada di tempat yang cukup terpencil, dan kami berjalan masuk melalui jalan berlumpur sambil terbenam pada setiap langkah.

Di dalam terdapat deretan komputer. Setiap hari para pemeriksa menghabiskan banyak waktu melihat gambar untuk mencari kemungkinan kerusakan pada sistem kabel kontak kereta api. Hampir semuanya memiliki lingkaran hitam di bawah mata. Setelah menemukan kerusakan, mereka masih harus menyusuri ribuan kilometer rel dan menangani setiap masalah satu per satu. Terkadang hanya ada sekrup atau mur yang longgar, tetapi mereka tetap harus pergi ke lokasi. Dalam dingin menusuk maupun panas terik, perbaikan tidak boleh ditunda.

Kebutuhan ini terasa sangat menyakitkan bagi saya. Setidaknya, kami seharusnya membantu mereka pada pekerjaan yang paling memakan waktu: melihat gambar.

Setelah benar-benar memulai, barulah kami menyadari bahwa masalahnya jauh lebih sulit daripada yang dibayangkan. Sistem kabel kontak memiliki lebih dari seratus jenis komponen dan lebih dari seribu jenis cacat. Bahkan angka-angka itu baru tersusun setelah kami berulang kali menghitungnya bersama rekan di lapangan. Banyak pekerjaan inspeksi sebelumnya bergantung pada pengalaman, sementara dokumen dan data historis tersebar di berbagai tempat. Kami harus mengumpulkan bahan dari awal, bekerja bersama rekan di garis depan, dan memahami setiap jenis kerusakan satu demi satu. Proses ini berlangsung hampir dua tahun.

Tantangan yang lebih besar adalah sedikitnya sampel. Kerusakan pada jalur kereta cepat pada dasarnya sangat jarang. Sebagian mungkin tidak muncul sekali pun dalam setahun, tetapi dapat menimbulkan akibat serius ketika terjadi. Kami tidak dapat menunggu sampai sampel yang cukup terkumpul. Kami harus merancang ulang metode berdasarkan kondisi nyata.

Akhirnya, proyek ini berhasil dan diterapkan dalam skala besar.

Visi industri adalah sungai kedua yang saya masuki di SenseTime. Saya tidak berganti perusahaan, tetapi hampir segala sesuatu yang akrab berubah: masalah, data, pelanggan, kriteria penilaian, dan cara bekerja. Saya kembali menjadi pemula, lalu bersama tim berhasil mengerjakan sesuatu yang sebelumnya tidak kami ketahui caranya.

Itulah sebabnya saya mengatakan bahwa sungai bukanlah perusahaan. Yang benar-benar menarik saya bukan meninggalkan suatu tempat, melainkan memasuki masalah yang lebih sulit.

Tahun 2022 ketika saya tidak berganti sungai

Setelah SenseTime melantai di bursa, perusahaan mulai menghadapi tekanan baru dalam keuangan dan sumber daya. Pada saat yang sama, gelombang visi komputer sebelumnya berangsur memasuki masa matang, sementara gelombang berikutnya belum tampak jelas. Banyak hal dibatasi oleh sumber daya, pasar, atau batas teknologi, sehingga sulit bergerak secepat dahulu.

Sepanjang 2022, saya berada dalam keadaan agak lesu atau, dengan kata lain, sedikit pasrah. Saya mulai bekerja dengan jam kantor biasa.

Tidak ada yang salah dengan kalimat itu. Bekerja dengan jam biasa adalah kehidupan normal bagi banyak orang. Namun sebelumnya saya selalu memperlakukan pekerjaan seperti membangun perusahaan rintisan. Ketika tiba-tiba masuk ke keadaan semacam itu, saya justru merasa sangat terpuruk.

Di permukaan, hidup saat itu jauh lebih nyaman daripada sebelumnya. Saya tidak lagi bangun setiap hari dengan masalah baru yang harus diselesaikan, dan tidak lagi sering begadang sepanjang malam karena gangguan daring. Namun justru kenyamanan itu yang membuat saya menderita: saya mulai dapat membayangkan seperti apa hidup saya beberapa tahun kemudian bila tidak ada yang berubah.

Saya tidak langsung pergi. Rasa tanggung jawablah yang membuat saya bertahan.

Inspeksi kereta cepat sudah berhasil, tetapi inspeksi kualitas di pabrik mobil belum berhasil dan lengan robot industri cerdas juga belum selesai. Saya ingin melanjutkan pekerjaan itu. Sulit bagi saya untuk menerima bahwa saya mendirikan sebuah tim dan memilih arah, lalu pergi pada saat yang paling sulit.

Satu kekuatan menyuruh saya mencari sungai berikutnya; kekuatan lain mengatakan bahwa pekerjaan di depan saya belum selesai.

Pada 2022, kekuatan kedua lebih besar.

Saya melihat sungai berikutnya

ChatGPT muncul pada akhir tahun lalu. GPT-4 hadir pada paruh pertama tahun ini. Keseimbangan lama pun pecah.

Saat itu saya memiliki perasaan yang sangat kuat: visi komputer telah kehilangan bentengnya sendiri.

Masa depan tidak akan terdiri atas model terpisah untuk teks, gambar, dan suara. Visi komputer tidak akan lenyap, tetapi akan menjadi bagian dari cara model umum memahami dunia. Dahulu kami memperlakukan visi sebagai satu pusat teknologi yang utuh; sekarang era kecerdasan umum yang lebih besar mulai muncul.

Ini bukan sekadar peningkatan teknis lain di dalam visi komputer. Arus utama perkembangan teknologi itu sendiri telah berubah.

Saya kembali melihat sebuah sungai yang arusnya belum saya kenal.

Dahulu saya dapat berganti sungai tanpa meninggalkan SenseTime. Peralihan dari autentikasi identitas ke visi industri pada 2019 adalah pilihan semacam itu. Namun kali ini, sungai berikutnya tidak terletak di perpanjangan pekerjaan lama saya. Saya ingin memasuki kecerdasan umum dan aplikasi baru yang akan diciptakannya.

Pada saat itu, jabatan dan tanggung jawab saya masih berada di visi industri. Jika tetap tinggal, saya semestinya mengerahkan seluruh tenaga untuk mengerjakan visi industri dengan baik. Saya tidak seharusnya memikul tanggung jawab lama sambil mempersiapkan tujuan berikutnya di samping itu.

Untuk benar-benar melompat ke sungai berikutnya, saya harus lebih dahulu meninggalkan peran lama.

Pada paruh pertama tahun ini, saya semakin tidak dapat berdiam diri. Saya tidak tahu produk apa yang akhirnya akan diciptakan teknologi baru itu, atau apa yang dapat saya kerjakan di dalamnya. Namun saya tahu bahwa jika menunggu sampai semuanya jelas, saya mungkin akan kehilangan tahun-tahun ketika saya paling perlu mulai belajar.

Hal yang benar-benar penting jarang mencapai saat ketika kita dapat menyatakannya “selesai sepenuhnya”. Jika tanggung jawab berarti harus menunggu sampai semua masalah berakhir, seseorang mungkin tidak akan pernah membuat pilihan baru.

Perlahan saya menyadari bahwa tanggung jawab tidak hanya berarti bertahan. Bertahan juga merupakan pilihan, dan konsekuensinya juga harus dipikul. Rasa tanggung jawab tidak boleh menjadi alasan untuk menunda pilihan tanpa batas.

Karena itu, pada Juni tahun ini, saya meninggalkan SenseTime.

Mengapa saya pergi tanpa jawaban

Sebelum pergi, saya tidak diam-diam mempersiapkan usaha di luar pekerjaan, dan tidak berencana membawa bisnis yang sedang dikerjakan SenseTime keluar untuk mendirikan perusahaan sendiri.

Jika saya masih bekerja di sebuah perusahaan, bertanggung jawab atas hasil pekerjaannya dan memakai sumber daya yang diberikannya, tetapi diam-diam memikirkan cara mempersiapkan tujuan berikutnya, saya akan merasa tidak jujur terhadap pekerjaan saya saat itu.

Artinya, ketika mengundurkan diri, saya memang belum siap.

Saya belum siap merintis usaha bukan karena tidak menganggapnya serius, melainkan karena sampai saat pergi saya masih menganggap serius pekerjaan lama.

Saya hanya dapat pergi lebih dahulu, kemudian mencari jawabannya.

Mampu berenang tidak berarti mengenal setiap sungai. Kita juga tidak mungkin berdiri di tepi sampai sepenuhnya memahami arus, baru kemudian melompat. Sebagian pengetahuan hanya dapat diperoleh di dalam air, dan sebagian arah baru tampak setelah kita mulai bergerak.

Kali ini, berganti sungai kebetulan berarti meninggalkan pekerjaan. Namun yang mendorong saya bukan hasrat untuk mengundurkan diri, melainkan kemunculan sungai berikutnya.

Memilih sisi aplikasi

Setelah ChatGPT muncul, saya membahas sebuah pertanyaan dengan teman-teman: jika AGI tiba, apakah kecerdasan pada akhirnya akan terpusat di tangan segelintir platform, atau dibagikan kepada lebih banyak orang?

Penilaian saya adalah bahwa kecerdasan pada akhirnya pasti akan menyebar.

Saya tidak dapat membuktikannya secara ketat. Intuisi saya sederhana: alam semesta sendiri bukan sistem yang terpusat. Dunia nyata terdiri atas tak terhitung banyaknya manusia, perangkat, lingkungan, dan masalah lokal. Jika kecerdasan benar-benar ingin masuk ke dunia ini, ia juga harus hadir dalam tak terhitung banyaknya bentuk. Pelatihan model fondasi mungkin terpusat di segelintir perusahaan, tetapi penerapan kecerdasan tidak akan hanya menjadi milik beberapa platform.

Karena itu saya tidak ingin membangun model fondasi. Saya lebih ingin membangun aplikasi yang memakai kecerdasan baru untuk menjawab kebutuhan konkret satu demi satu.

Pilihan ini juga berasal dari pengalaman hidup saya.

Saya tumbuh di desa. Dari sekolah dasar hingga menengah, saya menghabiskan banyak masa libur dan waktu senggang untuk membantu pekerjaan pertanian keluarga. Menanam benih, memberi pupuk dan pestisida, mengemudikan traktor, serta memelihara hewan—hampir semuanya pernah saya lakukan. Selama liburan, saya menganggap diri saya petani dalam arti yang sesungguhnya.

Saya menyukai rasa pencapaian yang diberikan pekerjaan semacam itu. Apakah tanaman tumbuh baik dan hewan dipelihara dengan baik, hasilnya langsung terlihat. Jika kita bekerja sedikit lebih baik, kehidupan satu keluarga juga menjadi sedikit lebih baik.

Saat kuliah, saya menjalani banyak pekerjaan paruh waktu dan membuka kelas tambahan musim panas bersama beberapa teman. Kami sendiri yang merekrut murid, menerima pembayaran, dan mengajar. Musim panas itu, semua yang terlibat mendapat cukup uang untuk biaya hidup tahun berikutnya.

Saat pascasarjana, saya menjadi guru privat. Kemudian, ketika SenseTime baru mulai dan kantornya masih berupa satu kamar di Hotel Wenjin dekat gerbang selatan Tsinghua, saya bergabung sebagai salah satu karyawan pendiri awal.

Di permukaan, berbagai pengalaman ini tampaknya tidak banyak memiliki kesamaan. Namun semuanya memberi saya rasa pencapaian dengan cara yang sama: memecahkan masalah nyata dan melihat sesuatu berubah karena saya ikut terlibat.

Karena itu, ketika era baru kecerdasan umum muncul, saya kembali secara naluriah berdiri di sisi aplikasi. Yang saya pedulikan bukan cara membuktikan bahwa sebuah teknologi lebih kuat, melainkan apa yang akhirnya dapat dilakukannya bagi seseorang yang konkret.

Setelah melompat

Memasuki sungai berikutnya tidak berarti saya langsung tahu harus berenang ke arah mana.

Pada beberapa bulan pertama setelah meninggalkan SenseTime, secara naluriah saya masih mencari peluang dari tempat yang paling saya kenal. Bersama seorang teman, saya mencoba beberapa produk terkait gambar. Bagaimanapun, hampir sepuluh tahun pekerjaan saya berkaitan dengan visi komputer. Memulai dari sana tampaknya merupakan pilihan paling alami.

Namun setelah mengerjakannya beberapa waktu, saya semakin merasa bahwa arahnya tidak tepat. Masalahnya belum tentu terletak pada produk itu sendiri, melainkan bahwa kami masih berangkat dari apa yang dapat kami lakukan, bukan dari apa yang benar-benar dibutuhkan pengguna.

Setelah memegang palu selama sepuluh tahun, meski pindah ke ruangan lain, semua hal masih mudah terlihat seperti paku.

Saya menyadari bahwa memasuki bidang baru bukan sekadar berpindah tempat lalu terus memakai metode yang berhasil dahulu. Benar-benar memulai kembali berarti untuk sementara meletakkan jawaban yang paling kita kuasai.

Maka saya bertanya kepada diri sendiri: jika tidak mempertimbangkan pengalaman teknis yang terkumpul selama sepuluh tahun terakhir, produk AI apa yang paling saya inginkan untuk diri sendiri?

Jawaban saya adalah catatan.

Produk yang paling saya inginkan

Sejak sekolah menengah saya memegang prinsip: “Jangan membaca tanpa menulis dan membuat catatan.” Bagi saya, catatan tidak pernah sekadar tempat menyimpan bahan. Catatan adalah perpanjangan ingatan sekaligus bagian dari proses berpikir.

Orang sering menyebut catatan sebagai “otak kedua”, tetapi apa yang disebut otak kedua ini sebenarnya tidak cerdas.

Kita memasukkan sesuatu ke dalamnya, tetapi tetap harus mengatur, mencari, menghubungkan, dan memikirkan sendiri cara mengambilnya kembali. Ia lebih menyerupai cakram keras eksternal daripada otak lain.

Generasi model besar ini untuk pertama kalinya membuat saya percaya bahwa keadaan itu dapat berubah secara mendasar. Catatan masa depan mungkin bukan hanya menyimpan apa yang pernah ditulis seseorang. Catatan dapat memahami isinya, menemukan hubungan, membantu kita mengingat ketika dibutuhkan, bahkan ikut dalam proses berpikir.

Yang ingin saya bangun bukan perangkat lunak catatan yang ditambahi beberapa fitur AI, melainkan otak kedua yang benar-benar cerdas.

Kecerdasan umum adalah sungai berikutnya yang saya masuki. Catatan cerdas adalah arah pertama yang saya putuskan untuk dituju setelah berada di dalamnya.

Belum sampai ke seberang

Sebelumnya, saya telah melakukan banyak hal yang memiliki sifat kewirausahaan. Membuka kelas musim panas saat kuliah merupakan usaha informal. Bergabung dengan SenseTime yang baru berdiri berarti ikut dalam sebuah perusahaan rintisan. Mendirikan tim deteksi keaktifan dan visi industri di dalam SenseTime juga sangat mirip dengan merintis usaha di dalam sebuah perusahaan.

Namun kali ini berbeda. Pada Juni tahun ini, untuk pertama kalinya saya meninggalkan sebuah perusahaan, menempatkan diri sepenuhnya di hadapan pasar, dan mulai merintis usaha secara penuh waktu dalam arti yang sebenarnya.

Hari ini adalah 31 Desember 2023. Setengah tahun telah berlalu sejak saya meninggalkan SenseTime.

Saya masih belum menemukan jawaban atas semua pertanyaan, juga belum mencapai seberang yang dapat disebut keberhasilan. Saya sedang mempelajari banyak hal yang sebelumnya tidak saya kuasai: membangun produk, memahami pasar, dan membuat keduanya cocok.

Bagi banyak orang, keadaan ini mungkin menyakitkan. Bagi saya, justru ada rasa akrab yang sudah lama hilang, karena saya kembali berada di tempat yang jawabannya tidak saya ketahui.

Ini adalah tulisan pertama di blog pribadi saya. Saya menulisnya bukan karena perjalanan ini telah berakhir, tetapi karena pada saat perjalanan benar-benar dimulai, saya ingin mencatat mengapa saya berangkat. Kelak, saya juga akan terus menulis di sini tentang teknologi, produk, manusia, dan hal-hal yang sedang saya ciptakan.

Saya tidak tahu ke mana sungai ini pada akhirnya akan mengalir.

Namun jika menoleh ke belakang, beberapa perubahan penting dalam hidup saya dimulai dari pilihan yang sama: setelah mencurahkan cukup banyak waktu dan menyadari bahwa saya berangsur masuk ke zona nyaman, saya mulai mencari sungai berikutnya.

Pada Juni tahun ini, saya kembali membuat pilihan itu.

Saya masih berada di dalam air.

Quando me ne sono andato, non avevo un prodotto già validato né un piano aziendale completo. Non avevo nemmeno deciso con precisione che cosa avrei fatto.

Sapevo però che per me era arrivato di nuovo il momento di tuffarmi nel fiume successivo.

Non era la prima volta che cambiavo fiume, ma era la prima in cui farlo richiedeva di lasciare un’azienda.

Una scelta che continuo a fare

Sono passato da una scuola elementare rurale a una scuola media nel capoluogo della contea, poi ho studiato alla Nanjing University e ho proseguito gli studi alla Tsinghua University. Durante il corso post-laurea sono entrato in SenseTime, che aveva appena cominciato. Lì ho fondato prima il gruppo di rilevamento della vitalità e poi quello di visione industriale.

Guardando indietro, cambiamenti del genere sembrano avvenire ogni pochi anni.

Non facevano parte di un progetto di vita preparato in anticipo, né accadevano perché il lavoro precedente avesse perso significato. Semplicemente, dopo anni di impegno, sia il settore sia io maturavamo. Il lavoro non era necessariamente finito, ma non mi costringeva più a superare i miei limiti.

Per molti sarebbe una condizione ideale. A me, invece, mette inquietudine. Non amo una vita di cui riesco già a vedere la fine. Per questo, ogni tanto, ho bisogno di mettermi dentro un problema che non so risolvere, a volte senza sapere nemmeno da dove cominciare.

Il “fiume” non è un’azienda. Cambiare fiume non significa necessariamente dimettersi. È un campo che devo imparare da capo, qualcosa di difficile che ancora non so portare a compimento. Nei miei quasi dieci anni in SenseTime mi sono tuffato in due fiumi diversi.

Ma non sono una persona che cerca il cambiamento fine a se stesso. Dentro di me agisce un’altra forza, quasi opposta: il senso di responsabilità.

Detesto lasciare le cose a metà. Quando decido di fare qualcosa, voglio farla davvero e farla bene. Una forza mi spinge a cercare il fiume successivo; l’altra mi trattiene in quello precedente, per finire ciò che ho iniziato.

La mia partenza di quest’anno è stata il risultato di un lungo conflitto tra queste due forze.

Portare gli algoritmi nel mondo reale

Quando sono entrato in SenseTime facevo parte del reparto ricerca, ma il mio interesse è sempre stato rivolto alle applicazioni. Non volevo sapere soltanto se un algoritmo funzionasse sui dati sperimentali, ma se potesse entrare nel mondo reale e risolvere un problema concreto.

Il rilevamento della vitalità era una parte centrale del primo grande progetto applicativo di SenseTime. Prima avevamo già alcune buone demo di riconoscimento facciale. Ma davanti a un’applicazione davvero su larga scala scoprimmo che molti problemi di produzione restavano irrisolti, soprattutto gli attacchi al sistema online.

Il sistema riceveva più di un milione di accessi al giorno e, nei momenti di picco, affrontava persino centinaia di migliaia di attacchi in una sola giornata. La tecnologia doveva continuare a progredire, mentre il servizio già online doveva rimanere operativo. Spesso era un combattimento corpo a corpo. Lasciavamo l’ufficio alle tre o alle quattro di notte e, a volte, restavamo svegli fino al mattino.

Capitava spesso di lottare per un giorno e una notte, risolvere tutti gli attacchi noti e tornare a casa a dormire. Poco dopo esserci addormentati, il telefono suonava di nuovo: il sistema era stato violato un’altra volta.

Fu in quel processo che contribuimmo a sviluppare l’architettura end-to-end dei modelli di SenseTime per il riconoscimento facciale. Prima, molti algoritmi di deep learning erano impiegati solo in parti isolate e il sistema completo concatenava diverse fasi. Ma contro attacchi in continuo mutamento, metodi composti manualmente non riuscivano a iterare abbastanza in fretta. L’unica via che vedevamo era far apprendere direttamente dai dati un unico modello di deep learning end-to-end. All’epoca lo chiamavamo “modello unificato”.

Quel progetto mi fece capire per la prima volta che un algoritmo efficace in una demo non è ancora una tecnologia compiuta. Diventa davvero utilizzabile solo quando resiste ad accessi su larga scala, attacchi continui e ogni genere di situazione imprevista.

In seguito entrammo negli smartphone. Prima di ogni lancio, i produttori organizzavano test con centinaia di persone, mentre concorrenti e utenti continuavano a scoprire nuovi problemi. Questo ci costrinse a creare uno dei gruppi di test più grandi, per quanto ne sapevamo, tra le aziende di algoritmi di IA di allora, cercando di esaurire ogni possibilità.

Un problema di controluce si poteva riprodurre soltanto in uno specifico bagno maschile di uno degli uffici SenseTime. Un altro, che chiamavamo “volto a due luci”, appariva solo da un certo angolo sotto un determinato albero. Per far funzionare un prodotto in modo affidabile nella vita quotidiana di centinaia di milioni di persone, svolgemmo una quantità enorme di lavoro di questo tipo.

Alla fine portammo l’autenticazione dell’identità sugli smartphone ai vertici del mercato.

Questo fu il primo fiume in cui entrai in SenseTime. Il rilevamento della vitalità partì da una demo di ricerca, superò varie prove in applicazioni su larga scala e divenne infine un settore piuttosto maturo. Nel 2019, molti problemi che prima richiedevano esplorazioni rischiose potevano ormai essere risolti grazie all’esperienza accumulata. Non avevo finito tutto, ma sapevo di essere rientrato in una zona di comfort.

Così ricominciai a sentirmi irrequieto.

Restare in SenseTime e cambiare fiume

Nel 2019 non lasciai SenseTime. Scelsi di passare, all’interno della stessa azienda, dall’autenticazione dell’identità alla visione industriale.

Dopo molte ricerche e numerose discussioni con i responsabili dell’azienda e il gruppo commerciale, scegliemmo come primo progetto di visione industriale l’ispezione intelligente della catenaria C4 delle ferrovie ad alta velocità.

Con il gruppo di prevendita visitai molti centri di ispezione e uffici ferroviari. Quello che mi colpì di più fu il centro di Xuzhou. Quando arrivammo aveva appena piovuto. Il centro si trovava in una zona piuttosto isolata e percorremmo una strada fangosa, sprofondando a ogni passo.

All’interno c’erano file e file di computer. Gli ispettori passavano gran parte della giornata a guardare immagini per cercare possibili guasti nella catenaria ferroviaria. Quasi tutti avevano occhiaie scure. Dopo aver trovato un guasto, dovevano ancora percorrere migliaia di chilometri di ferrovia e risolvere ogni problema. A volte si trattava solo di una vite o di un dado allentati, ma dovevano comunque raggiungere il posto. Con il gelo o con il caldo torrido, la riparazione non poteva aspettare.

Il bisogno mi sembrò dolorosamente chiaro. Come minimo, dovevamo aiutarli nella parte che richiedeva più tempo: guardare le immagini.

Solo dopo aver iniziato scoprimmo quanto il problema fosse più difficile di quanto immaginassimo. Una catenaria comprende oltre cento tipi di componenti e più di mille tipi di difetti. Persino questi numeri emersero soltanto dopo ripetuti conteggi e classificazioni con i colleghi sul campo. Gran parte delle ispezioni si basava sull’esperienza, mentre documenti e dati storici erano sparsi in luoghi diversi. Dovemmo raccogliere tutto da zero, lavorare accanto alle persone sul campo e comprendere ogni voce di guasto, una per una. Il processo durò quasi due anni.

La sfida più grande era la scarsità di campioni. I guasti sulle linee ad alta velocità sono per natura molto rari. Alcuni possono non verificarsi nemmeno una volta all’anno, ma avere conseguenze gravi quando accadono. Non potevamo aspettare di raccogliere abbastanza campioni. Dovevamo riprogettare i metodi sulla base delle condizioni reali.

Alla fine il progetto riuscì e venne applicato su larga scala.

La visione industriale fu il secondo fiume in cui entrai in SenseTime. Non cambiai azienda, ma cambiò quasi tutto ciò che conoscevo: problemi, dati, clienti, criteri di valutazione e modo di lavorare. Tornai a essere un principiante e, insieme al gruppo, riuscimmo a realizzare qualcosa che prima non sapevamo fare.

È per questo che dico che il fiume non è l’azienda. Ciò che mi attira davvero non è lasciare un luogo, ma entrare in un problema più difficile.

Il 2022 in cui non cambiai fiume

Dopo la quotazione in borsa, SenseTime cominciò ad affrontare nuove pressioni finanziarie e di risorse. Nello stesso tempo, la precedente ondata della visione artificiale entrava gradualmente nella maturità, mentre la successiva non era ancora apparsa con chiarezza. Molte cose erano limitate dalle risorse, dal mercato o dai confini della tecnologia e non potevano più avanzare rapidamente come prima.

Per tutto il 2022 fui piuttosto scoraggiato o, per dirla in un altro modo, un po’ rassegnato. Cominciai a lavorare con orari normali.

Non c’è nulla di sbagliato in questa frase. Un orario regolare è la vita normale di molte persone. Ma io avevo sempre trattato il lavoro come una startup. Entrando all’improvviso in quello stato, mi sentii invece profondamente demoralizzato.

In superficie, quella vita era molto più comoda di prima. Non mi svegliavo ogni giorno con un nuovo problema da risolvere, né passavo più così tante notti in bianco per un guasto online. Eppure era proprio quella comodità a pesarmi: cominciavo a immaginare come sarebbe stata la mia vita alcuni anni dopo se nulla fosse cambiato.

Non me ne andai subito. A trattenermi fu il senso di responsabilità.

L’ispezione ferroviaria aveva funzionato, ma non eravamo riusciti nell’ispezione della qualità nelle fabbriche automobilistiche e non avevamo finito il braccio robotico industriale intelligente. Volevo continuare quel lavoro. Mi era difficile accettare di aver fondato un gruppo e scelto una direzione per poi andarmene nel momento più difficile.

Una forza mi diceva di cercare il fiume successivo; l’altra che il lavoro davanti a me non era ancora concluso.

Nel 2022, la seconda forza era più intensa.

Vidi il fiume successivo

ChatGPT apparve alla fine dell’anno scorso. GPT-4 arrivò nella prima metà di quest’anno. Il vecchio equilibrio si spezzò.

Allora ebbi una sensazione molto forte: la visione artificiale aveva perso la propria roccaforte.

Il futuro non sarebbe stato composto da modelli separati per testo, immagini e voce. La visione artificiale non sarebbe scomparsa, ma sarebbe diventata una parte del modo in cui i modelli generali comprendono il mondo. Prima consideravamo la visione un centro tecnologico completo; ora stava emergendo un’era più ampia di intelligenza generale.

Non era un altro aggiornamento tecnico interno alla visione artificiale. Era cambiata la corrente principale dello sviluppo tecnologico.

Vidi di nuovo un fiume di cui non conoscevo ancora le correnti.

In passato potevo cambiare fiume senza lasciare SenseTime. Il passaggio dall’autenticazione alla visione industriale nel 2019 era stata una scelta di quel tipo. Questa volta, però, il fiume successivo non si trovava sul prolungamento del mio lavoro precedente. Volevo entrare nell’intelligenza generale e nelle nuove applicazioni che avrebbe creato.

Il mio ruolo e le mie responsabilità erano ancora nella visione industriale. Se fossi rimasto, avrei dovuto dedicarmi interamente a quel lavoro. Non avrei dovuto portare le responsabilità attuali mentre preparavo, parallelamente, la mia prossima destinazione.

Per tuffarmi davvero nel fiume successivo, dovevo prima lasciare il ruolo precedente.

Nella prima metà dell’anno divenne sempre più difficile restare fermo. Non sapevo quali prodotti avrebbe creato la nuova tecnologia, né che cosa avrei potuto fare al suo interno. Ma sapevo che, se avessi aspettato di capire tutto, avrei potuto perdere gli anni in cui era più importante cominciare a imparare.

Le cose davvero importanti raramente arrivano a un momento in cui si può dichiarare che sono “del tutto finite”. Se responsabilità significa aspettare che ogni problema sia concluso, una persona potrebbe non fare mai una nuova scelta.

Gradualmente capii che responsabilità non significa soltanto restare. Anche restare è una scelta e richiede di accettarne le conseguenze. Il senso di responsabilità non può diventare una ragione per rimandare una decisione all’infinito.

Così, nel giugno di quest’anno, lasciai SenseTime.

Perché me ne andai senza una risposta

Prima di partire, non preparai di nascosto una startup fuori dal lavoro, né pensavo di portare via l’attività che SenseTime stava sviluppando per fondare un’azienda mia.

Se lavoravo ancora per un’azienda, con la responsabilità di consegnare il suo lavoro e usando le risorse che mi forniva, mentre dentro di me pensavo a come preparare la destinazione successiva, avrei sentito di non essere onesto verso il lavoro attuale.

Questo significava che, quando mi dimisi, non ero davvero pronto.

Non ero impreparato perché non prendessi sul serio l’imprenditorialità, ma perché, fino al momento di andarmene, prendevo ancora sul serio il lavoro precedente.

Potevo soltanto partire prima e cercare la risposta dopo.

Saper nuotare non significa conoscere ogni fiume. Non si può nemmeno restare sulla riva finché non si comprende completamente la corrente, per poi tuffarsi. Alcune conoscenze si acquisiscono solo nell’acqua e certe direzioni diventano visibili solo dopo aver cominciato a muoversi.

Questa volta cambiare fiume significava lasciare il lavoro. Ma ciò che mi spinse non fu il desiderio di dimettermi: fu la comparsa del fiume successivo.

Scegliere il lato delle applicazioni

Dopo l’arrivo di ChatGPT, discussi con alcuni amici una domanda: se arriverà l’AGI, l’intelligenza finirà concentrata nelle mani di poche piattaforme oppure sarà condivisa da più persone?

Il mio giudizio era che alla fine si sarebbe necessariamente diffusa.

Non posso dimostrarlo rigorosamente. La mia intuizione è semplicemente che l’universo stesso non è un sistema centralizzato. Il mondo reale è formato da innumerevoli persone, dispositivi, ambienti e problemi locali. Se l’intelligenza vuole entrarci davvero, dovrà anch’essa esistere in innumerevoli forme. L’addestramento dei modelli fondazionali può concentrarsi in poche aziende, ma le applicazioni dell’intelligenza non apparterranno soltanto a poche piattaforme.

Per questo non voglio costruire modelli fondazionali. Preferisco creare applicazioni che usino la nuova intelligenza per rispondere, una per una, a esigenze concrete.

Questa scelta viene anche dalla mia vita.

Sono cresciuto in campagna. Dalle elementari alle medie, passavo molte vacanze e ore libere nei lavori agricoli di famiglia. Ho seminato, distribuito fertilizzanti e pesticidi, guidato trattori e allevato animali. Durante le vacanze mi consideravo un agricoltore in ogni senso concreto.

Mi piaceva il senso di realizzazione dato da quel lavoro. Che le colture crescessero bene o che gli animali fossero allevati bene, il risultato era diretto e visibile. Se svolgevi il lavoro un po’ meglio, la vita di una famiglia migliorava un po’.

All’università feci molti lavori part-time e organizzai con alcuni compagni un corso estivo. Reclutavamo gli studenti, riscuotevamo le quote e insegnavamo da soli. Quell’estate tutti i partecipanti guadagnarono abbastanza per coprire le spese dell’anno seguente.

Durante gli studi post-laurea lavorai come tutor privato. In seguito, quando SenseTime aveva appena cominciato e il suo ufficio era ancora una camera del Wenjin Hotel vicino al cancello sud di Tsinghua, entrai come uno dei primi dipendenti fondatori.

In apparenza, queste esperienze hanno poco in comune. Ma mi davano soddisfazione nello stesso modo: risolvendo un problema reale e vedendo qualcosa cambiare grazie al mio contributo.

Così, quando apparve la nuova era dell’intelligenza generale, mi schierai di nuovo istintivamente dalla parte delle applicazioni. Ciò che mi interessa non è come dimostrare che una tecnologia sia più potente, ma che cosa potrà fare alla fine per una persona concreta.

Dopo il tuffo

Entrare nel fiume successivo non significava sapere subito in quale direzione nuotare.

Nei primi mesi dopo aver lasciato SenseTime, continuai per istinto a cercare opportunità nel luogo che conoscevo meglio. Con un amico provai alcuni prodotti legati alle immagini. Dopotutto, quasi dieci anni del mio lavoro erano stati dedicati alla visione artificiale. Partire da lì sembrava la scelta più naturale.

Ma dopo un po’ sentii sempre più chiaramente che la direzione non era quella giusta. Il problema non stava necessariamente nei prodotti, ma nel fatto che partivamo ancora da ciò che sapevamo fare, invece che da ciò di cui gli utenti avevano davvero bisogno.

Dopo aver portato un martello per dieci anni, anche cambiando stanza, è facile continuare a vedere chiodi dappertutto.

Compresi che entrare in un campo nuovo non significa soltanto cambiare posto e continuare a usare i metodi che avevano funzionato in passato. Ricominciare davvero richiede di mettere temporaneamente da parte le risposte che conosciamo meglio.

Così mi posi una domanda: se ignorassi l’esperienza tecnica accumulata nei dieci anni precedenti, quale prodotto di IA desidererei di più per me stesso?

La mia risposta fu: le note.

Il prodotto che desideravo di più

Dalle scuole medie seguo una regola: “Non leggere senza scrivere e prendere appunti.” Per me, le note non sono mai state soltanto un luogo in cui conservare informazioni. Sono un’estensione della memoria e una parte del pensiero.

Spesso vengono chiamate “secondo cervello”, ma questo presunto secondo cervello non è davvero intelligente.

Inseriamo le cose, ma dobbiamo ancora organizzarle, cercarle, collegarle e capire da soli come recuperarle. Somiglia più a un disco rigido esterno che a un altro cervello.

Questa generazione di grandi modelli mi ha fatto credere per la prima volta che la situazione possa cambiare alla radice. Le note del futuro forse non conserveranno soltanto ciò che una persona ha scritto. Potranno comprenderlo, trovare collegamenti, aiutarci a ricordare quando serve e persino partecipare al nostro pensiero.

Non voglio creare un software per note a cui siano state aggiunte alcune funzioni di IA, ma un secondo cervello davvero intelligente.

L’intelligenza generale è il fiume successivo in cui mi sono tuffato. Le note intelligenti sono la prima direzione verso cui ho deciso di nuotare una volta entrato.

Non sono ancora arrivato all’altra riva

In precedenza avevo fatto molte cose con caratteristiche imprenditoriali. Organizzare il corso estivo all’università era stata un’impresa informale. Entrare in SenseTime ai suoi inizi significava partecipare a una startup. Fondare dentro SenseTime i gruppi di rilevamento della vitalità e visione industriale somigliava molto a fare impresa dentro un’azienda.

Ma questa volta era diverso. Nel giugno di quest’anno, per la prima volta, ho lasciato un’azienda, mi sono messo interamente davanti al mercato e ho cominciato a fare l’imprenditore a tempo pieno nel senso vero del termine.

Oggi è il 31 dicembre 2023. È passato mezzo anno da quando ho lasciato SenseTime.

Non ho ancora trovato le risposte a tutte le domande, né ho raggiunto una riva che possa essere chiamata successo. Sto imparando molte cose in cui prima non ero bravo: costruire un prodotto, capire un mercato e fare in modo che i due coincidano.

Per molti questo stato potrebbe essere doloroso. A me dà invece una familiarità che mi mancava da tempo, perché sono tornato in un luogo in cui non conosco le risposte.

Questo è il primo articolo del mio blog personale. Non lo scrivo perché il viaggio sia finito, ma perché voglio registrare, nel momento in cui comincia davvero, perché sono partito. In futuro continuerò a scrivere qui di tecnologia, prodotti e persone, oltre che delle cose che sto creando.

Non so dove finirà per scorrere questo fiume.

Ma guardando indietro, alcuni importanti cambiamenti della mia vita sono iniziati tutti dalla stessa scelta: dopo aver dedicato abbastanza tempo a un campo e aver scoperto che stavo entrando gradualmente in una zona di comfort, iniziavo a cercare il fiume successivo.

Nel giugno di quest’anno ho fatto di nuovo quella scelta.

Sono ancora nell’acqua.

辞めた時点で、検証済みのプロダクトも、完成した事業計画もなかった。具体的に何をするのかさえ、まだはっきりしていなかった。

ただ、自分が再び次の川へ飛び込む時を迎えたことだけは分かっていた。

川を変えるのは初めてではない。だが、そのために会社を離れなければならなかったのは初めてだった。

私が繰り返してきた選択

私は農村の小学校から県庁所在地の中学校へ進み、その後、南京大学で学部を、清華大学で大学院を修めた。大学院在学中に、創業したばかりのSenseTimeへ加わった。入社後は、まず生体検知チームを立ち上げ、その後、産業用ビジョンチームを立ち上げた。

振り返ると、こうした変化は数年おきに訪れている。

あらかじめ設計した人生計画ではない。それまでの仕事が意味を失ったからでもない。ただ、何年も取り組むうちに、その領域も自分も少しずつ成熟していく。仕事がすべて終わったわけではなくても、自分の限界を越えることを迫られなくなる。

多くの人にとって、それは理想的な状態だろう。だが私には不安をもたらす。先まで見通せる人生が好きではない。だから時折、やり方が分からず、どこから始めるべきかさえ分からない問題の中へ、自分を置く必要がある。

ここでいう「川」は会社ではない。川を変えることが、必ずしも退職を意味するわけでもない。新たに学び直さなければならない領域、まだどうすれば成し遂げられるか分からない仕事のことだ。SenseTimeで過ごした約10年の間にも、私は二つの異なる川へ飛び込んだ。

一方で、私はただ変化だけを求める人間でもない。自分の中には、それとほとんど反対向きに働く力もある。責任感だ。

私は物事を途中で投げ出すのがひどく嫌いだ。やると決めたことは、本当にうまくやり遂げたい。一方の力は次の川を探させ、もう一方の力は元の川にとどまって、始めたことを終わらせようとする。

今年の退職は、この二つの力が長くせめぎ合った結果だった。

アルゴリズムを現実世界へ

SenseTimeに入った当初、私は研究部にいた。それでも関心は一貫して応用にあった。知りたかったのは、アルゴリズムが実験データ上で有効かどうかだけではない。それが現実世界に入り、具体的な問題を解けるかどうかだった。

生体検知は、SenseTimeにとって最初の大規模な実用化プロジェクトの中核だった。それ以前にも、顔認識ではいくつか優れたデモができていた。しかし、本当の大規模運用に向き合うと、本番環境の問題が数多く未解決だと分かった。とりわけ、オンラインシステムへの攻撃が問題だった。

当時、システムへのアクセスは一日100万件を超え、ピーク時には一日に数十万回もの攻撃を受けた。技術を進歩させ続ける一方で、すでに稼働しているサービスも支えなければならない。仕事はしばしば白兵戦になった。午前3時、4時まで会社に残ることも多く、そのまま徹夜することもあった。

一日一晩かけて既知の攻撃をすべて解決し、家へ戻って眠る。ところが寝入った直後に電話が鳴る。オンラインがまた破られた、というのがよくあることだった。

この過程で私たちは、SenseTimeの顔認識におけるエンドツーエンドのモデル体系づくりにも携わった。それ以前、多くの深層学習アルゴリズムは局所的な工程にしか使われず、システム全体は複数の段階を直列につないで構成されていた。しかし、変化し続ける攻撃を前に、人手で組み合わせた手法では高速な反復に追いつけない。私たちに見えた唯一の道は、一つのエンドツーエンド深層学習モデルにデータから直接学ばせることだった。当時、私たちはこれを「大一統モデル」と呼んだ。

このプロジェクトで、私は初めて本当の意味を理解した。デモで有効なアルゴリズムが、そのまま成立した技術なのではない。大規模アクセス、絶え間ない攻撃、さまざまな想定外に耐えて初めて、実際に使える技術になる。

その後、私たちはスマートフォンへ進出した。端末メーカーはリリースのたびに数百人規模のテストを行い、同業者や利用者も新たな問題を次々と見つけた。そのため、当時私たちが知るAIアルゴリズム企業の中でも最大級のテストチームをつくり、あらゆる可能性を洗い出そうとした。

逆光に関するある問題は、SenseTimeのあるオフィスにある特定の男性用トイレでしか再現できなかった。「陰陽顔」と呼んだ別の問題は、特定の木の下の決まった角度に立った時だけ現れた。数億人の日常で確実に動くプロダクトにするため、私たちはこうした作業を大量に重ねた。

最終的に、スマートフォンの本人認証で市場をリードするまでになった。

これがSenseTimeで入った最初の川だった。生体検知は論文のデモから始まり、何度もの大規模運用による検証を経て、かなり成熟した領域になった。2019年には、かつて危険を承知で探索しなければならなかった問題の多くを、蓄積した経験で解けるようになっていた。すべてを終えたわけではない。それでも、自分が再びコンフォートゾーンに入ったことは分かった。

そして、またじっとしていられなくなった。

SenseTimeに残り、川を変える

2019年、私はSenseTimeを辞めなかった。同じ会社の中で、本人認証から産業用ビジョンへ移ることを選んだ。

大規模な調査を行い、会社の経営陣やビジネスチームと何度も話し合った末、最初の産業用ビジョン案件として、高速鉄道C4架線設備のスマート検査を選んだ。

私はプリセールスチームとともに、多くの鉄道検査センターや鉄道局を訪ねた。最も印象に残っているのは徐州の検査センターだ。訪問の直前まで雨が降っていた。センターはかなり辺鄙な場所にあり、私たちは足を泥に取られながら中へ入った。

中にはコンピュータがずらりと並んでいた。検査員は毎日長い時間、画像を見続け、鉄道の架線設備に起こり得る故障を探す。ほとんど全員の目の下にくまがあった。故障を見つけた後も、数千キロに及ぶ線路をたどり、一つずつ対処しなければならない。単にねじやナットが緩んでいるだけでも、現場へ急ぐ必要がある。厳寒でも猛暑でも、先延ばしにはできない。

あまりにも切実なニーズだと思った。少なくとも、一番時間のかかる作業、つまり画像を見ることは、私たちが助けるべきだった。

実際に始めてみると、想像以上に難しかった。架線設備には100種類以上の部品と、1,000種類以上の欠陥がある。この数字でさえ、現場の人たちと何度も数え直して、ようやく整理できたものだ。従来の検査の多くは経験に依存し、資料や過去のデータは各所に散在していた。私たちは一から資料を集め、現場の人たちと一緒に働きながら、故障項目を一つずつ理解しなければならなかった。この作業には断続的に2年近くかかった。

さらに大きな課題は少数サンプルだった。高速鉄道で故障が起きること自体、極めて少ない。一年に一度も起きないものもあるが、ひとたび起きれば深刻な結果を招き得る。十分なサンプルが集まるまで待つことはできない。現実の条件に合わせて手法を設計し直すしかなかった。

最終的に、このプロジェクトは成功し、大規模に導入された。

産業用ビジョンは、SenseTimeで入った二本目の川だった。会社は変わらなかったが、それまで慣れ親しんだもののほとんどが変わった。問題、データ、顧客、評価基準、働き方。そのすべてが違った。私は再び初心者になり、チームとともに、当初はやり方すら分からなかったことを成し遂げた。

だから私は、川は会社と同じではないと言う。私を本当に引きつけるのは、ある場所を離れることではなく、より難しい問題へ入ることだ。

川を変えなかった2022年

SenseTimeは上場後、新たな財務面とリソース面の圧力に直面し始めた。同時に、前のコンピュータビジョンの波は成熟期に入り、次の波はまだはっきりとは現れていなかった。多くのことがリソース、市場、技術の限界に制約され、以前のような速さで進めにくくなった。

2022年を通じて、私は少し意気消沈し、言い換えれば、やや流されるような状態にいた。普通に出勤し、普通に退勤するようになった。

それ自体には何の問題もない。決まった時間に働くのは、多くの人にとって普通の暮らしだ。しかし私は、それまで仕事をずっと起業のように捉えていた。突然この状態に入ると、かえって強く落ち込んだ。

表面上、その頃の生活は以前よりずっと快適だった。目覚めるたびに必ず解くべき新たな問題があるわけでもなく、オンライン障害のために徹夜することも減った。だが私を本当に苦しめたのは、その快適さだった。何も変えなければ、数年後にどんな暮らしをしているか想像できるようになった。

それでも、すぐには辞めなかった。私をとどめたのは責任感だった。

高速鉄道の検査は成功したが、自動車工場の品質検査は実現できず、産業用の知能ロボットアームも完成していなかった。私はそれらを続けたかった。自らチームをつくり、方向を選んでおきながら、最も苦しい時に去ることを簡単には受け入れられなかった。

一方の力は次の川を探せと言い、もう一方の力は目の前の仕事がまだ終わっていないと言った。

2022年は、後者の力の方が強かった。

次の川が見えた

昨年末にChatGPTが現れ、今年前半にはGPT-4が登場した。それまでの均衡は崩れた。

当時、私は強く感じた。コンピュータビジョンは「本丸を奪われた」と。

未来は、文字、画像、音声それぞれの独立したモデルから成るのではない。コンピュータビジョンはなくならないが、汎用モデルが世界を理解するための一部になる。私たちは以前、ビジョンを一つの完結した技術の中心と考えていた。今、より大きな汎用知能の時代が現れつつあった。

これはコンピュータビジョン内部の技術更新ではない。技術発展の本流そのものが変わったのだ。

私はまた、流れをまだ知らない川を見つけた。

以前なら、SenseTimeに残ったまま川を変えられた。2019年に本人認証から産業用ビジョンへ移ったのが、まさにそうだった。だが今回、次の川は従来の仕事の延長線上にはなかった。私が入りたかったのは、汎用知能と、そこから生まれる新しい応用だった。

当時の私の役割と責任は、まだ産業用ビジョンにあった。残るのであれば、産業用ビジョンをよいものにするため全力を注ぐべきであり、元の責任を負いながら自分の次の行き先を準備すべきではなかった。

本当に次の川へ飛び込むには、まず以前の役割を離れなければならなかった。

今年前半になると、私はますますじっとしていられなくなった。新しい技術が最終的にどんなプロダクトを生むのかも、自分がそこで何をできるのかも分からなかった。それでも、すべてを考え抜くまで待てば、学び始めるべき最も大切な数年間を逃すかもしれないと分かっていた。

本当に重要な仕事には、「すべて完了した」と宣言できる瞬間がないことが多い。責任とはあらゆる問題が終わるまで待つことだとすれば、人は永遠に新しい選択をできないかもしれない。

私は次第に、責任は残ることだけを意味しないと気づいた。残るのも一つの選択であり、その結果を引き受けなければならない。責任感を、選択を無期限に先送りする理由にしてはいけない。

こうして今年6月、私はSenseTimeを離れた。

答えがないまま辞めた理由

辞める前、仕事の外でひそかに起業の準備をしてはいなかった。SenseTimeが手がけていた事業を持ち出して起業するつもりもなかった。

会社で働き、会社の仕事を届ける責任を負い、会社のリソースを使いながら、心の中では自分の次の行き先の準備を考えているとしたら、それは現在の仕事に対して誠実ではないと感じる。

つまり、退職した時の私は本当に準備ができていなかった。

起業を真剣に考えていなかったからではない。辞めるまでは、まだ以前の仕事を真剣に考えていたからだ。

先に離れ、その後で答えを探すしかなかった。

泳げるからといって、すべての川を知っているわけではない。流れを完全に理解するまで岸に立ち、それから飛び込むこともできない。水の中でしか得られない知識があり、動き始めて初めて見える方向もある。

今回は、川を変えることがたまたま退職を意味した。だが私を動かしたのは、退職そのものへの憧れではない。次の川が現れたことだった。

応用する側を選ぶ

ChatGPTの登場後、私は友人たちとある問題を話し合った。AGIが実現したら、知能は最終的に少数のプラットフォームへ集中するのか、それともより多くの人に共有されるのか。

私の考えは、最終的には必ず広がっていく、というものだった。

これを厳密に証明することはできない。ただ、宇宙そのものは中央集権的なシステムではない、という直感がある。現実世界は、無数の人、デバイス、環境、局所的な問題からできている。知能が本当にこの世界へ入るなら、同じように無数の異なる形で存在するはずだ。基盤モデルの訓練は少数の企業に集中するかもしれない。しかし、知能の応用が少数のプラットフォームだけのものになるとは思わない。

だから私は、基盤モデルをつくろうとは思わない。新しい知能で、一つひとつの具体的なニーズに応える応用をつくりたい。

この選択は、自分の人生経験からも来ている。

私は農村で育った。小学校から中学校まで、休みや放課後の多くを家の農作業に使った。種まき、施肥、農薬散布、トラクターの運転、家畜の飼育。ほとんど何でもやった。休暇中の自分は、まさに一人の農民だった。

私は、この仕事がもたらす達成感が好きだった。作物がよく育ったか、動物をうまく育てられたか。結果はすぐに分かる。少しうまくやれば、一つの家族の暮らしが少しよくなる。

大学では多くのアルバイトをし、同級生と夏期講習も開いた。募集、集金、授業のすべてを自分たちで行った。その夏、参加した数人の同級生は皆、翌年の生活費を稼ぐことができた。

大学院では家庭教師をした。その後、SenseTimeが創業したばかりで、オフィスが清華大学南門近くの文津ホテルの一室にあった頃、私は初期の創業メンバーとして加わった。

表面上、これらに共通点はないように見える。だが、達成感を与える仕組みは同じだった。現実にある問題を解き、自分が関わったことで物事が変わるのを見ることだ。

だから、新たな汎用知能の時代が現れた時も、私は本能的に応用する側に立った。関心があるのは、技術の強さをどう証明するかではなく、それが最終的に具体的な一人のために何をできるかだ。

飛び込んだ後

次の川に入ったからといって、すぐにどこへ泳ぐべきか分かったわけではない。

SenseTimeを離れて最初の数か月、私はまだ本能的に最も慣れた場所から機会を探した。友人と画像に関わるプロダクトをいくつか試した。それまで約10年間の仕事はコンピュータビジョンに関わっていたのだから、そこから始めるのが最も自然に思えた。

だがしばらく取り組むうちに、方向が違うと感じるようになった。必ずしもプロダクト自体が悪いのではない。私たちが、利用者が本当に何を必要としているかではなく、自分たちに何ができるかを出発点にしていたことが問題だった。

10年もハンマーを持っていると、別の部屋に移っても、目に入るものはすべて釘になりやすい。

新しい領域へ入るとは、場所を変えて過去に成功した方法を使い続けることではない。本当に一から始めるには、自分が最もよく知る答えを、いったん手放さなければならない。

そこで自分に問うた。過去10年の技術的な蓄積を考えないなら、自分が一番欲しいAIプロダクトは何だろう。

答えはノートだった。

私が最も欲しいプロダクト

中学生の頃から、私は「筆を動かさずに本を読まない」という習慣を持っている。私にとってノートは、資料を保存するだけの場所ではない。記憶の延長であり、思考の一部でもある。

ノートはよく「第二の脳」と呼ばれる。しかし、その第二の脳は実際には知能を持っていない。

情報を入れても、整理し、探し、つながりをつくり、取り出す方法を考えるのは自分だ。もう一つの脳というより、外付けハードディスクに近い。

今世代の大規模モデルを見て、私は初めて、これが根本から変わり得ると信じた。未来のノートは、人が書いたものを保存するだけでなく、その内容を理解し、互いのつながりを見つけ、必要な時に思い出すのを助け、さらには思考に加わるかもしれない。

私がつくりたいのは、AI機能をいくつか追加したノートアプリではない。本当に知能を持つ第二の脳だ。

汎用知能は、私が飛び込んだ次の川である。インテリジェントノートは、その中に入って最初に泳ごうと決めた方向だ。

まだ対岸には着いていない

それ以前にも、私は起業に似たことをいくつもしてきた。大学で夏期講習を開いたのは非公式な起業だった。創業直後のSenseTimeに加わったのは起業への参加だった。SenseTimeの中で生体検知と産業用ビジョンのチームを立ち上げたことも、会社の中で起業するのによく似ていた。

だが今回は違う。今年6月、私は初めて会社を離れ、自分を完全に市場の中へ置き、本当の意味でフルタイムの起業を始めた。

今日は2023年12月31日だ。SenseTimeを離れてから半年が過ぎた。

すべての問いに答えが見つかったわけではない。成功と呼べる対岸にも着いていない。プロダクトをつくること、市場を理解すること、そして両者を適合させることなど、これまで得意ではなかった多くのことを学んでいる。

多くの人には苦しい状態かもしれない。私にはむしろ、久しぶりの懐かしさがある。自分が答えを知らない場所へ、また戻ってきたからだ。

これは私の個人ブログの最初の記事だ。旅が終わったから書くのではない。本当に始まる時に、自分がなぜ出発したのかを記録しておきたい。これからもここで、技術、プロダクト、人について考えたこと、そして自分がつくっているものを書き続けるつもりだ。

この川が最終的にどこへ流れるのかは分からない。

だが振り返れば、人生の重要な変化のいくつかは、同じ選択から始まっていた。十分に長い時間を注ぎ、自分が少しずつコンフォートゾーンに入ったと気づいた時、次の川を探し始めるという選択だ。

今年6月、私は再びその選択をした。

今もまだ、水の中にいる。

떠날 때 내게는 검증된 제품도, 완성된 사업 계획도 없었다. 구체적으로 무엇을 할지조차 분명하지 않았다.

하지만 다시 다음 강으로 뛰어들 때가 왔다는 사실만은 알고 있었다.

강을 바꾸는 것이 처음은 아니었지만, 그러기 위해 회사를 떠나야 했던 것은 처음이었다.

내가 거듭해 온 선택

나는 농촌 초등학교에서 현 소재지의 중학교로 진학했고, 이후 난징대학교에서 학부를, 칭화대학교에서 대학원을 다녔다. 대학원 재학 중 막 시작한 센스타임에 합류했다. 센스타임에서는 먼저 생체 탐지 팀을 만들었고, 나중에는 산업 비전 팀을 만들었다.

돌이켜 보면 이런 변화는 대략 몇 년에 한 번씩 일어났다.

미리 설계한 인생 계획 때문은 아니었다. 원래 하던 일이 의미를 잃었기 때문도 아니었다. 여러 해를 쏟고 나면 한 분야와 나 자신이 함께 성숙해졌다. 일이 반드시 끝난 것은 아니지만, 더는 내 한계를 넘어서도록 몰아붙이지 않았다.

많은 사람에게는 이상적인 상태일 것이다. 그러나 내게는 불안을 가져온다. 끝이 한눈에 보이는 삶을 좋아하지 않기 때문이다. 그래서 얼마에 한 번씩은 할 줄도 모르고, 어디서 시작할지도 모르는 문제 속에 나 자신을 던져 넣어야 한다.

여기서 ‘강’은 회사가 아니다. 강을 바꾼다고 반드시 퇴사해야 하는 것도 아니다. 새로 배워야 하는 분야, 아직 어떻게 해낼지 모르는 일을 뜻한다. 센스타임에서 보낸 거의 10년 동안에도 나는 서로 다른 두 강에 차례로 뛰어들었다.

그렇다고 내가 변화만 좇는 사람은 아니다. 내 안에는 거의 반대 방향으로 작용하는 또 하나의 힘이 있다. 책임감이다.

나는 일을 중도에 포기하는 것을 몹시 싫어한다. 하기로 정한 일은 제대로 해내고 싶다. 앞의 힘은 다음 강을 찾게 하고, 뒤의 힘은 원래 강에 남아 이미 시작한 일을 마치게 한다.

올해의 퇴사는 이 두 힘이 오랫동안 맞선 결과였다.

알고리즘을 현실 세계로 밀어 넣다

센스타임에 처음 합류했을 때 나는 연구부에 있었지만, 줄곧 관심을 둔 것은 응용이었다. 알고리즘이 실험 데이터에서 효과가 있는지만이 아니라, 현실 세계로 들어가 구체적인 문제를 해결할 수 있는지를 알고 싶었다.

생체 탐지는 센스타임 최초의 대규모 상용화 프로젝트에서 핵심을 이루었다. 그전에도 얼굴 인식에서 꽤 좋은 데모가 있었다. 하지만 실제 대규모 응용을 마주하자 생산 환경의 많은 문제가 해결되지 않았다는 사실을 알게 되었다. 특히 온라인 시스템이 공격받는 문제가 컸다.

당시 시스템은 하루 100만 건이 넘는 접속을 처리했고, 정점에는 하루 수십만 건의 공격을 받기도 했다. 기술은 계속 돌파해야 했고, 이미 운영 중인 서비스도 동시에 지켜야 했다. 많은 순간이 백병전과 같았다. 새벽 세네 시에야 회사를 나서는 일이 잦았고, 아예 밤을 새우기도 했다.

하루 낮과 밤을 싸워 알려진 공격을 모두 해결하고 집에 가서 잠드는 일이 반복됐다. 막 잠이 들면 다시 전화가 왔다. 온라인이 또 뚫렸다는 소식이었다.

바로 그 과정에서 우리는 센스타임 얼굴 인식의 엔드투엔드 모델 체계를 만드는 데 참여했다. 그전에는 많은 딥러닝 알고리즘이 국소적인 단계에만 쓰였고, 전체 시스템은 여러 단계를 이어 붙인 구조였다. 그러나 계속 변하는 공격 앞에서 사람이 조합한 방식은 빠른 반복을 감당하지 못했다. 우리가 본 유일한 출구는 하나의 엔드투엔드 딥러닝 모델이 데이터에서 직접 학습하게 하는 것이었다. 당시 우리는 이를 ‘대통합 모델’이라고 불렀다.

이 프로젝트를 통해 나는 데모에서 작동하는 알고리즘이 곧 성립한 기술은 아니라는 점을 처음으로 제대로 이해했다. 대규모 접속과 지속적인 공격, 온갖 예기치 않은 상황을 견뎌 내야 비로소 실제로 쓸 수 있는 기술이 된다.

이후 우리는 스마트폰 시장에도 진입했다. 휴대전화 제조사는 출시 전마다 수백 명을 조직해 테스트했고, 동종 업계와 사용자도 끊임없이 새로운 문제를 찾아냈다. 그 때문에 우리는 당시 알고 있던 AI 알고리즘 회사 중 최대 규모에 속하는 테스트 팀을 만들고, 모든 가능성을 찾아내려 했다.

역광과 관련된 한 문제는 센스타임의 어느 사무실에 있는 특정 남자 화장실에서만 재현할 수 있었다. 우리가 ‘음양 얼굴’이라고 부른 또 다른 문제는 어느 나무 아래 특정 각도에 서야만 나타났다. 수억 명의 일상에서 제품이 안정적으로 작동하게 하려고 우리는 이런 일을 수없이 했다.

결국 스마트폰 본인 인증 분야에서 시장을 선도하게 되었다.

이것이 센스타임에서 들어간 첫 번째 강이었다. 생체 탐지는 논문의 데모에서 시작해 여러 차례 대규모 응용의 검증을 거쳤고, 마침내 상당히 성숙한 분야가 되었다. 2019년이 되자 과거에는 위험을 감수하며 탐색해야 했던 많은 문제를 축적된 경험으로 해결할 수 있었다. 모든 일을 끝낸 것은 아니었지만, 내가 다시 안락지대에 들어왔다는 사실은 알 수 있었다.

그래서 다시 가만히 있을 수 없게 되었다.

센스타임에 남아 강을 바꾸다

2019년, 나는 센스타임을 떠나지 않았다. 같은 회사 안에서 본인 인증에서 산업 비전으로 옮기는 길을 택했다.

폭넓게 조사하고 회사 리더와 사업 팀과 여러 차례 논의한 끝에, 첫 산업 비전 프로젝트로 고속철도 C4 전차선 지능형 검사를 선택했다.

나는 프리세일즈 팀과 많은 철도 검사 센터와 철도국을 방문했다. 가장 깊은 인상을 남긴 곳은 쉬저우 검사 센터였다. 우리가 갔을 때는 막 비가 그친 뒤였다. 센터는 비교적 외진 곳에 있었고, 우리는 진흙탕 길에 발이 푹푹 빠지며 들어갔다.

안에는 컴퓨터가 줄지어 놓여 있었다. 검사원들은 매일 많은 시간을 이미지에 쏟으며 철도 전차선에서 생길 수 있는 고장을 찾았다. 거의 모든 사람의 눈 밑이 어두웠다. 고장을 찾은 뒤에도 수천 킬로미터에 이르는 철길을 따라가 하나씩 처리해야 했다. 나사나 너트 하나가 풀린 것뿐이어도 현장으로 달려가야 했다. 혹한이든 혹서든 미룰 수 없었다.

너무나 절실한 요구라고 생각했다. 적어도 가장 시간이 많이 드는 일, 곧 이미지를 보는 일부터 도와야 했다.

실제로 시작하고 나서야 이 일이 상상보다 훨씬 어렵다는 것을 알게 되었다. 전차선에는 100가지가 넘는 부품과 1,000가지가 넘는 결함이 있었다. 이 숫자조차 일선 동료들과 반복해서 세고 정리한 끝에 나온 것이었다. 기존의 많은 검사 업무는 경험에 의존했고, 자료와 과거 데이터는 여러 곳에 흩어져 있었다. 우리는 처음부터 자료를 모으고, 일선 동료들과 함께 일하며 고장 항목을 하나씩 이해해야 했다. 이 과정은 거의 2년에 걸쳐 이어졌다.

더 큰 도전은 소량 표본 문제였다. 고속철도 노선의 고장은 본래 극히 드물다. 어떤 고장은 일 년에 한 번도 나타나지 않지만, 일단 일어나면 결과가 심각할 수 있다. 충분한 표본이 모일 때까지 기다릴 수 없었다. 실제 조건에 맞춰 방법을 다시 설계해야 했다.

마침내 이 프로젝트는 성공했고 대규모로 적용되었다.

산업 비전은 센스타임에서 들어간 두 번째 강이었다. 회사를 바꾸지는 않았지만 익숙했던 거의 모든 것이 달라졌다. 문제, 데이터, 고객, 평가 기준과 일하는 방식이 모두 변했다. 나는 다시 초보자가 되었고, 팀과 함께 원래는 할 줄 몰랐던 일을 해냈다.

그래서 나는 강이 회사와 같지 않다고 말한다. 나를 진정으로 끌어당기는 것은 한 장소를 떠나는 일이 아니라 더 어려운 문제로 들어가는 일이다.

강을 바꾸지 않았던 2022년

센스타임은 상장 이후 새로운 재무와 자원 압박에 직면했다. 동시에 이전 컴퓨터 비전의 물결은 점차 성숙기에 접어들었고, 다음 물결은 아직 선명하게 나타나지 않았다. 많은 일이 자원과 시장, 기술의 경계에 막혀 예전처럼 빠르게 나아가기 어려웠다.

2022년 내내 나는 다소 의기소침했고, 달리 말하면 조금은 체념한 상태였다. 정상적으로 출퇴근하기 시작했다.

이 말 자체에는 아무 문제가 없다. 정해진 시간에 출퇴근하는 것은 많은 사람의 평범한 삶이다. 하지만 나는 과거에 늘 일을 창업처럼 대했다. 갑자기 이런 상태로 들어가자 오히려 몹시 침체되었다.

겉으로 그 시기의 삶은 전보다 훨씬 편안했다. 매일 눈을 뜰 때마다 반드시 해결해야 할 새 문제가 있는 것도 아니었고, 온라인 장애 때문에 밤을 새우는 일도 줄었다. 하지만 나를 정말 힘들게 한 것은 바로 그 편안함이었다. 아무것도 바꾸지 않으면 몇 년 뒤 내 삶이 어떤 모습일지 상상할 수 있게 되었다.

나는 곧바로 떠나지 않았다. 나를 남게 한 것은 책임감이었다.

고속철도 검사는 성공했지만 자동차 공장의 품질 검사는 성공하지 못했고, 지능형 산업용 로봇 팔도 완성하지 못했다. 나는 이 일을 계속하고 싶었다. 내가 팀을 만들고 방향을 선택해 놓고, 가장 어려운 시기에 떠난다는 것을 쉽게 받아들일 수 없었다.

한 힘은 다음 강을 찾아야 한다고 했고, 다른 힘은 눈앞의 일이 아직 끝나지 않았다고 했다.

2022년에는 뒤의 힘이 더 강했다.

다음 강이 보였다

작년 말 ChatGPT가 나타났고, 올해 상반기에는 GPT-4가 등장했다. 이전의 균형은 깨졌다.

당시 나는 강하게 느꼈다. 컴퓨터 비전이 ‘본진을 털렸다’고.

미래가 텍스트, 이미지, 음성마다 따로 존재하는 모델로 이루어지지는 않을 것이었다. 컴퓨터 비전은 사라지지 않겠지만, 범용 모델이 세계를 이해하는 한 부분이 될 것이다. 과거 우리는 비전을 완결된 기술의 중심으로 여겼다. 이제 더 큰 범용 지능의 시대가 나타나고 있었다.

이는 컴퓨터 비전 내부의 기술 업그레이드가 아니었다. 기술 발전의 주류 자체가 달라진 것이었다.

나는 아직 물살을 모르는 또 하나의 강을 보았다.

과거에는 센스타임 안에 남아 강을 바꿀 수 있었다. 2019년 본인 인증에서 산업 비전으로 옮긴 것이 그런 선택이었다. 그러나 이번에는 다음 강이 원래 하던 일의 연장선에 있지 않았다. 내가 들어가려는 곳은 범용 지능과 그것이 만들어 낼 새로운 응용이었다.

당시 내 역할과 책임은 여전히 산업 비전에 있었다. 계속 남는다면 산업 비전을 잘해 내는 데 온 힘을 다해야 했다. 기존 책임을 짊어진 채 한편으로 내 다음 행선지를 준비해서는 안 된다고 생각했다.

진정으로 다음 강에 뛰어들려면 먼저 이전 역할을 떠나야 했다.

올해 상반기가 되자 나는 점점 더 가만히 있을 수 없었다. 새로운 기술이 궁극적으로 어떤 제품을 만들지, 내가 그 안에서 무엇을 할 수 있을지도 알지 못했다. 하지만 모든 것을 확실히 생각할 때까지 기다리면, 가장 먼저 학습을 시작해야 할 몇 년을 놓칠 수 있다는 사실은 알았다.

정말 중요한 일에는 흔히 ‘모두 끝났다’고 선언할 순간이 없다. 책임진다는 것이 모든 문제가 끝날 때까지 기다린다는 뜻이라면, 사람은 영원히 새로운 선택을 하지 못할 수도 있다.

나는 책임이 남는 것만을 뜻하지 않는다는 사실을 차츰 깨달았다. 남는 것도 하나의 선택이며, 그 결과를 감당해야 한다. 책임감을 선택을 끝없이 미루는 이유로 삼을 수는 없다.

그래서 올해 6월, 나는 센스타임을 떠났다.

답이 없는 채로 떠난 이유

떠나기 전에 업무 밖에서 몰래 창업을 준비하지 않았고, 센스타임이 하던 사업을 들고 나가 창업할 생각도 없었다.

한 회사에서 일하며 회사의 결과물을 낼 책임을 지고 회사가 제공한 자원을 쓰면서, 마음속으로는 내 다음 행선지를 준비할 방법만 생각한다면 이전 업무에 정직하지 못하다고 느꼈을 것이다.

이는 내가 퇴사할 때 정말 준비되어 있지 않았다는 뜻이다.

창업을 진지하게 대하지 않아서 준비하지 못한 것이 아니다. 떠나기 전까지 이전 일을 여전히 진지하게 대하고 있었기 때문이다.

나는 먼저 떠난 뒤 답을 찾아야 했다.

수영할 줄 안다고 모든 강을 아는 것은 아니다. 물살을 완전히 이해할 때까지 강둑에 서 있다가 뛰어드는 것도 불가능하다. 어떤 지식은 물속에서만 얻을 수 있고, 어떤 방향은 움직이기 시작한 뒤에야 보인다.

이번에는 강을 바꾸는 일이 마침 퇴사를 뜻했다. 하지만 나를 떠나게 한 것은 퇴사 자체에 대한 동경이 아니라, 다음 강이 이미 나타났다는 사실이었다.

응용의 편을 선택하다

ChatGPT가 나온 뒤 친구들과 한 가지 문제를 이야기했다. AGI가 오면 지능은 결국 소수 플랫폼의 손에 집중될까, 아니면 더 많은 사람이 공유하게 될까?

내 판단은 결국 반드시 퍼져 나갈 것이라는 쪽이었다.

이를 엄밀히 증명할 수는 없다. 내 직관은 단순하다. 우주 자체가 중앙 집중형 시스템이 아니라는 것이다. 현실 세계는 무수한 사람과 기기, 환경, 국지적인 문제로 이루어져 있다. 지능이 진정으로 이 세계에 들어오려면, 그것도 무수히 다른 형태로 존재해야 한다. 파운데이션 모델의 훈련은 소수 회사에 집중될 수 있지만, 지능의 응용까지 소수 플랫폼만의 것은 아닐 것이다.

그래서 나는 파운데이션 모델을 만들고 싶지 않다. 새로운 지능으로 하나하나의 구체적인 요구에 응답하는 응용을 만들고 싶다.

이 선택은 내 인생 경험에서도 비롯되었다.

나는 농촌에서 자랐다. 초등학교부터 중학교까지 많은 방학과 여가 시간을 집안 농사에 썼다. 씨 뿌리기, 비료와 농약 주기, 트랙터 운전, 동물 사육까지 거의 모두 해 보았다. 방학 동안 나는 스스로를 실질적인 농부라고 생각했다.

나는 이런 일이 주는 성취감이 좋았다. 농사가 잘됐는지, 동물을 잘 키웠는지 결과가 아주 직접적이었다. 일을 조금 더 잘하면 한 가정의 삶도 조금 더 나아졌다.

대학 때는 여러 아르바이트를 했고, 동기들과 여름 보충 수업도 열었다. 학생 모집과 수강료 수납, 수업을 모두 직접 했다. 그해 여름, 함께한 동기 몇 명은 모두 이듬해 생활비를 벌었다.

대학원 때는 개인 과외를 했다. 이후 센스타임이 막 시작해 사무실이 칭화대 남문 근처 원진호텔 객실 한 칸에 있던 때, 초기 창업 직원으로 합류했다.

겉으로는 이 일들에 공통점이 없어 보인다. 하지만 내게 성취감을 준 방식은 같았다. 현실의 문제를 해결하고, 내가 참여했기 때문에 무언가 달라지는 것을 보는 일이었다.

그래서 새로운 범용 지능 시대가 나타났을 때도 나는 본능적으로 응용의 편에 섰다. 내가 궁금한 것은 기술이 더 강하다는 사실을 어떻게 증명할지가 아니라, 그것이 결국 구체적인 한 사람에게 무엇을 해 줄 수 있는가이다.

뛰어든 뒤

다음 강에 들어갔다고 곧바로 어디를 향해 헤엄쳐야 할지 알게 된 것은 아니다.

센스타임을 떠난 뒤 첫 몇 달 동안 나는 여전히 가장 익숙한 곳에서 본능적으로 기회를 찾았다. 친구와 함께 이미지 관련 제품을 몇 가지 시도했다. 거의 10년 동안 컴퓨터 비전을 다뤘으니, 그곳에서 출발하는 것이 가장 자연스러워 보였다.

하지만 한동안 해 보자 방향이 맞지 않는다는 느낌이 점점 강해졌다. 반드시 제품 자체에 문제가 있었던 것은 아니다. 우리가 사용자가 정말 무엇을 필요로 하는지가 아니라, 우리가 무엇을 할 줄 아는지에서 출발하고 있다는 점이 문제였다.

10년 동안 망치를 들고 있으면, 방을 바꾸어도 눈에 보이는 것은 여전히 모두 못이 되기 쉽다.

새로운 분야에 들어간다는 것은 장소만 바꾸고 과거에 성공한 방법을 계속 쓰는 일이 아니라는 것을 깨달았다. 진정으로 다시 시작하려면 내가 가장 잘 아는 답을 잠시 내려놓아야 했다.

그래서 스스로 물었다. 지난 10년의 기술 축적을 고려하지 않는다면, 내가 가장 갖고 싶은 AI 제품은 무엇일까?

내 답은 노트였다.

내가 가장 원한 제품

중학교 때부터 나는 ‘붓을 움직이지 않고는 책을 읽지 않는다’는 습관을 지켜 왔다. 내게 노트는 자료를 보관하는 곳에 그치지 않는다. 기억의 연장이자 생각의 한 부분이다.

사람들은 흔히 노트를 ‘두 번째 뇌’라고 부른다. 하지만 이른바 두 번째 뇌는 실제로 지능적이지 않다.

무언가를 넣고 나서도 직접 정리하고, 찾고, 연결하고, 다시 꺼낼 방법을 생각해야 한다. 또 하나의 뇌라기보다 외장 하드디스크에 가깝다.

이번 세대의 대규모 모델을 보고 나는 처음으로 이 일이 근본적으로 달라질 수 있다고 믿었다. 미래의 노트는 한 사람이 쓴 것을 보관할 뿐 아니라 그 내용을 이해하고, 서로의 연결을 찾아내며, 필요할 때 기억을 돕고, 심지어 생각에 참여할 수도 있다.

내가 만들고 싶은 것은 AI 기능 몇 개를 더한 노트 소프트웨어가 아니다. 진정으로 지능적인 두 번째 뇌다.

범용 지능은 내가 뛰어든 다음 강이다. 지능형 노트는 그 안에 들어간 뒤 가장 먼저 헤엄쳐 가기로 정한 방향이다.

아직 건너편에 닿지 않았다

그전에도 창업의 성격을 띤 일을 많이 했다. 대학 때 보충 수업을 연 것은 비공식적인 창업이었고, 막 시작한 센스타임에 합류한 것은 창업에 참여한 일이었다. 센스타임 안에서 생체 탐지와 산업 비전 팀을 만든 것도 한 회사 안에서 창업하는 것과 비슷했다.

하지만 이번에는 달랐다. 올해 6월, 나는 처음으로 한 회사를 떠나 나 자신을 온전히 시장에 두고 진정한 의미의 전업 창업을 시작했다.

오늘은 2023년 12월 31일이다. 센스타임을 떠난 지 반년이 지났다.

아직 모든 문제의 답을 찾지 못했고, 성공이라 부를 만한 어떤 건너편에도 닿지 못했다. 제품을 만드는 일, 시장을 이해하는 일, 그리고 둘을 맞추는 일처럼 과거에는 잘하지 못했던 많은 것을 배우고 있다.

많은 사람에게는 고통스러운 상태일 수 있다. 내게는 오히려 오래간만에 느끼는 익숙함이 있다. 답을 알 수 없는 곳으로 다시 돌아왔기 때문이다.

이 글은 내 개인 블로그의 첫 번째 글이다. 여정이 끝났기 때문에 쓰는 것이 아니다. 진정으로 시작하는 순간, 내가 왜 출발했는지를 기록하고 싶었다. 앞으로도 이곳에 기술과 제품, 사람에 관한 생각과 내가 만들고 있는 것들을 계속 쓸 것이다.

이 강이 결국 어디로 흐를지는 모른다.

그러나 돌이켜 보면 내 인생의 몇몇 중요한 변화는 모두 같은 선택에서 시작했다. 충분히 오랜 시간을 쏟은 뒤 내가 조금씩 안락지대에 들어가고 있음을 발견하면, 다음 강을 찾기 시작하는 선택이었다.

올해 6월, 나는 다시 그 선택을 했다.

나는 지금도 물속에 있다.

Quando saí, não tinha um produto validado nem um plano de negócios completo. Eu sequer havia decidido exatamente o que faria.

Mas sabia que havia chegado novamente a hora de saltar para o próximo rio.

Não era a primeira vez que eu mudava de rio, mas era a primeira em que isso exigia deixar uma empresa.

Uma escolha que continuo fazendo

Saí de uma escola primária rural para estudar em uma escola na sede do condado. Depois fiz a graduação na Universidade de Nanquim e a pós-graduação na Universidade Tsinghua. Durante a pós, entrei na SenseTime quando ela ainda estava começando. Lá, primeiro fundei a equipe de detecção de vivacidade e, mais tarde, a de visão industrial.

Olhando para trás, mudanças assim parecem acontecer a cada poucos anos.

Elas não faziam parte de um plano de vida traçado de antemão, nem aconteciam porque o trabalho anterior tivesse perdido o sentido. Era apenas que, depois de anos de dedicação, tanto o campo quanto eu amadurecíamos. O trabalho não precisava estar concluído, mas já não me obrigava a ultrapassar meus próprios limites.

Para muitas pessoas, esse seria o estado ideal. Para mim, ele traz inquietação. Não gosto de uma vida cujo fim se consegue enxergar de onde se está. Por isso, de tempos em tempos, preciso me colocar dentro de um problema que não sei resolver — às vezes, um problema que nem sei por onde começar.

O “rio” aqui não é uma empresa. Mudar de rio também não significa necessariamente pedir demissão. É um campo que preciso reaprender, algo difícil que ainda não sei como realizar. Nos meus quase dez anos na SenseTime, saltei para dois rios diferentes.

Mas não sou alguém que busca mudança por si só. Há em mim outra força, quase oposta: o senso de responsabilidade.

Detesto abandonar algo pela metade. Quando decido fazer alguma coisa, quero fazê-la de verdade e fazê-la bem. Uma força me leva a procurar o próximo rio; a outra me mantém no rio anterior, tentando terminar o que comecei.

Minha saída neste ano foi o resultado de uma longa disputa entre essas duas forças.

Levar os algoritmos ao mundo real

Quando entrei na SenseTime, eu fazia parte do departamento de pesquisa, mas meu interesse sempre esteve nas aplicações. Eu queria saber não apenas se um algoritmo funcionava em dados experimentais, mas se ele poderia entrar no mundo real e resolver um problema concreto.

A detecção de vivacidade era uma parte central do primeiro grande projeto implantado pela SenseTime. Antes disso, já tínhamos algumas boas demonstrações de reconhecimento facial. Porém, ao encarar uma aplicação realmente em larga escala, descobrimos que muitos problemas de produção continuavam sem solução, especialmente os ataques ao sistema on-line.

O sistema recebia mais de um milhão de acessos por dia e, nos picos, chegava a enfrentar centenas de milhares de ataques em um único dia. A tecnologia precisava continuar avançando, enquanto o serviço já implantado tinha de permanecer funcionando. Muitas vezes, o trabalho era um combate corpo a corpo. Saíamos da empresa às três ou quatro da manhã e, às vezes, passávamos a noite inteira lá.

Era comum lutarmos por um dia e uma noite, resolvermos todos os ataques conhecidos e voltarmos para casa para dormir. Pouco depois de adormecer, o telefone tocava de novo: o sistema on-line havia sido rompido outra vez.

Foi nesse processo que ajudamos a impulsionar a arquitetura de modelos ponta a ponta da SenseTime para reconhecimento facial. Antes disso, muitos algoritmos de aprendizagem profunda ainda eram usados apenas em partes isoladas, e o sistema completo encadeava várias etapas. Mas, diante de ataques em constante mudança, métodos combinados manualmente não conseguiam iterar com rapidez suficiente. A única saída que víamos era permitir que um único modelo de aprendizagem profunda ponta a ponta aprendesse diretamente com os dados. Na época, nós o chamávamos de “modelo unificado”.

Esse projeto me fez entender pela primeira vez que um algoritmo funcionar em uma demonstração não significa que a tecnologia já esteja estabelecida. Ela só se torna realmente utilizável depois de resistir a acessos em larga escala, ataques contínuos e todo tipo de situação inesperada.

Mais tarde, entramos nos smartphones. Antes de cada lançamento, os fabricantes organizavam testes com centenas de pessoas, enquanto outras empresas e usuários continuavam descobrindo novos problemas. Isso nos obrigou a montar uma das maiores equipes de teste que, até onde sabíamos, existiam em uma empresa de algoritmos de IA naquela época, tentando esgotar todas as possibilidades.

Um problema de contraluz só podia ser reproduzido em um banheiro masculino específico de um dos escritórios da SenseTime. Outro, que chamávamos de “rosto de duas luzes”, só aparecia em um determinado ângulo sob certa árvore. Para que um produto funcionasse de forma confiável no cotidiano de centenas de milhões de pessoas, fizemos uma enorme quantidade de trabalhos assim.

No fim, levamos a autenticação de identidade em smartphones à liderança do mercado.

Esse foi o primeiro rio em que entrei na SenseTime. A detecção de vivacidade começou como uma demonstração de pesquisa, passou por várias rodadas de aplicações em larga escala e acabou se tornando um campo bastante maduro. Em 2019, muitos problemas que antes exigiam exploração arriscada já podiam ser resolvidos com a experiência acumulada. Eu não havia terminado tudo, mas sabia que tinha entrado novamente em uma zona de conforto.

Então comecei outra vez a ficar inquieto.

Ficar na SenseTime e mudar de rio

Em 2019, não deixei a SenseTime. Escolhi passar, dentro da mesma empresa, da autenticação de identidade para a visão industrial.

Depois de muita pesquisa e de várias conversas com a liderança da empresa e a equipe comercial, escolhemos como primeiro projeto de visão industrial a inspeção inteligente do sistema de catenária C4 dos trens de alta velocidade.

Eu e a equipe de pré-vendas visitamos muitos centros de inspeção e órgãos ferroviários. O que mais me marcou foi o centro de Xuzhou. Tinha acabado de chover quando chegamos. O centro ficava em um lugar relativamente remoto, e avançamos por uma estrada de lama, afundando a cada passo.

Lá dentro havia fileiras e fileiras de computadores. Os inspetores passavam boa parte do dia olhando imagens em busca de possíveis falhas na catenária ferroviária. Quase todos tinham olheiras. Depois de encontrar uma falha, ainda precisavam percorrer milhares de quilômetros de ferrovia para tratar cada problema. Às vezes, era apenas um parafuso ou uma porca soltos, mas mesmo assim tinham de ir ao local. Fizesse frio intenso ou calor extremo, o reparo não podia esperar.

A necessidade me pareceu dolorosamente clara. No mínimo, deveríamos ajudá-los na tarefa que mais consumia tempo: olhar imagens.

Só depois de começar descobrimos que o problema era muito mais difícil do que imaginávamos. Uma catenária contém mais de cem tipos de componentes e mais de mil tipos de defeitos. Até esses números só surgiram depois de repetidas contagens e organização junto aos colegas da linha de frente. Grande parte das inspeções dependia da experiência, e documentos e dados históricos estavam espalhados por vários lugares. Tivemos de reunir o material do zero, trabalhar ao lado de quem estava no campo e entender cada item de falha, um por um. O processo levou quase dois anos.

O desafio maior era a escassez de amostras. Falhas em linhas de alta velocidade são, por natureza, muito raras. Algumas podem não aparecer nem uma vez por ano, mas, quando ocorrem, as consequências podem ser graves. Não podíamos esperar até reunir amostras suficientes. Precisávamos redesenhar os métodos a partir das condições reais.

Por fim, o projeto deu certo e foi implantado em larga escala.

A visão industrial foi o segundo rio em que entrei na SenseTime. Não mudei de empresa, mas quase tudo o que eu conhecia mudou: os problemas, os dados, os clientes, os critérios de avaliação e a forma de trabalhar. Voltei a ser iniciante e, junto com a equipe, conseguimos realizar algo que antes não sabíamos fazer.

É por isso que digo que o rio não é a empresa. O que realmente me atrai não é sair de um lugar, mas entrar em um problema mais difícil.

O ano de 2022 em que não mudei de rio

Depois de abrir o capital, a SenseTime começou a enfrentar novas pressões financeiras e de recursos. Ao mesmo tempo, a onda anterior de visão computacional entrava gradualmente na maturidade, enquanto a seguinte ainda não havia aparecido com clareza. Muitas coisas eram limitadas pelos recursos, pelo mercado ou pelas fronteiras da tecnologia e já não podiam avançar tão depressa quanto antes.

Durante todo o ano de 2022, fiquei um pouco desanimado ou, em outras palavras, um tanto resignado. Passei a cumprir um horário normal de trabalho.

Não há nada errado nessa frase. Ter um expediente normal é a vida normal de muita gente. Mas eu sempre havia tratado meu trabalho como um empreendimento. Ao entrar de repente nesse estado, senti-me profundamente abatido.

Na aparência, aquela vida era muito mais confortável do que antes. Eu já não acordava todos os dias com um problema novo que precisava ser resolvido, nem passava tantas noites em claro por causa de uma falha on-line. Mas o que realmente me incomodava era justamente isso: eu começava a imaginar como seria minha vida alguns anos depois se nada mudasse.

Não fui embora imediatamente. O que me fez ficar foi a responsabilidade.

A inspeção ferroviária havia dado certo, mas não havíamos conseguido a inspeção de qualidade em fábricas de automóveis nem terminado o braço robótico industrial inteligente. Eu queria continuar trabalhando nessas coisas. Era difícil aceitar que eu tivesse fundado uma equipe e escolhido uma direção para então partir no momento mais difícil.

Uma força me dizia para procurar o próximo rio; a outra dizia que o trabalho diante de mim ainda não estava terminado.

Em 2022, a segunda era mais forte.

Eu vi o próximo rio

O ChatGPT apareceu no fim do ano passado. O GPT-4 chegou na primeira metade deste ano. O antigo equilíbrio se rompeu.

Na época, tive uma sensação muito forte: a visão computacional havia perdido a própria base.

O futuro não seria composto de modelos independentes para texto, imagem e voz. A visão computacional não desapareceria, mas se tornaria uma parte da maneira como modelos gerais compreendem o mundo. Antes, tratávamos a visão como um centro técnico completo; agora surgia uma era mais ampla de inteligência geral.

Não se tratava de mais uma atualização técnica dentro da visão computacional. A própria corrente principal do desenvolvimento tecnológico havia mudado.

Voltei a ver um rio cujas correntes eu ainda não conhecia.

No passado, eu podia mudar de rio sem sair da SenseTime. A passagem da autenticação de identidade para a visão industrial em 2019 foi uma escolha assim. Desta vez, porém, o próximo rio não estava no prolongamento do meu trabalho anterior. Eu queria entrar na inteligência geral e nas novas aplicações que ela criaria.

Meu cargo e minhas responsabilidades continuavam na visão industrial. Se ficasse, eu deveria me dedicar por inteiro a fazer bem esse trabalho. Não deveria carregar minhas responsabilidades atuais enquanto preparava, em paralelo, meu próximo destino.

Para realmente saltar para o próximo rio, eu precisava primeiro deixar minha antiga função.

Na primeira metade deste ano, ficou cada vez mais difícil permanecer parado. Eu não sabia quais produtos a nova tecnologia acabaria criando nem o que eu poderia fazer dentro dela. Mas sabia que, se esperasse até ter tudo claro, poderia perder os anos em que mais precisava começar a aprender.

As coisas realmente importantes raramente chegam a um momento em que se possa declarar que estão “totalmente concluídas”. Se responsabilidade significar esperar até que todos os problemas terminem, uma pessoa talvez nunca consiga fazer uma nova escolha.

Aos poucos, percebi que responsabilidade não significa apenas ficar. Ficar também é uma escolha, e suas consequências também precisam ser assumidas. O senso de responsabilidade não pode se tornar uma razão para adiar indefinidamente uma decisão.

Por isso, em junho deste ano, deixei a SenseTime.

Por que saí sem uma resposta

Antes de partir, não preparei secretamente uma startup fora do trabalho, nem planejei levar para fora o negócio que a SenseTime desenvolvia para fundar minha própria empresa.

Se eu ainda trabalhasse em uma empresa, com a responsabilidade de entregar seu trabalho e usando os recursos que ela oferecia, enquanto por dentro pensava em como preparar meu próximo destino, sentiria que não estava sendo honesto com meu trabalho atual.

Isso significava que eu realmente não estava pronto quando pedi demissão.

Eu não estava despreparado porque não levasse o empreendedorismo a sério, mas porque, até o momento de sair, ainda levava meu trabalho anterior a sério.

Só podia sair primeiro e procurar a resposta depois.

Saber nadar não significa conhecer todos os rios. Também não é possível ficar na margem até compreender completamente a corrente antes de saltar. Há conhecimentos que só se obtêm dentro da água e direções que só aparecem depois que começamos a nos mover.

Desta vez, mudar de rio significou deixar meu emprego. Mas o que me moveu não foi o desejo de pedir demissão, e sim o surgimento do próximo rio.

Escolher o lado das aplicações

Depois que o ChatGPT apareceu, discuti uma questão com amigos: se a AGI chegar, a inteligência acabará concentrada nas mãos de poucas plataformas ou será compartilhada por mais pessoas?

Minha conclusão era que ela acabaria necessariamente se espalhando.

Não consigo provar isso de modo rigoroso. Minha intuição é apenas que o próprio universo não é um sistema centralizado. O mundo real é composto de inúmeras pessoas, dispositivos, ambientes e problemas locais. Se a inteligência quiser realmente entrar nesse mundo, também terá de existir em incontáveis formas diferentes. O treinamento dos modelos fundacionais pode se concentrar em poucas empresas, mas as aplicações da inteligência não pertencerão apenas a poucas plataformas.

Por isso, não quero criar modelos fundacionais. Prefiro criar aplicações que usem essa nova inteligência para responder, uma a uma, a necessidades concretas.

Essa escolha também vem da minha própria vida.

Cresci no campo. Do ensino primário ao secundário, passei muitas férias e horas livres ajudando no trabalho agrícola da família. Plantei, apliquei fertilizantes e pesticidas, dirigi tratores e criei animais. Durante as férias, eu me considerava um agricultor no sentido mais real.

Gostava da sensação de realização que esse trabalho trazia. Se a plantação crescia bem ou se os animais eram bem criados, o resultado era direto e visível. Se você fazia o trabalho um pouco melhor, a vida de uma família melhorava um pouco.

Na universidade, tive muitos empregos de meio período e organizei um curso de verão com alguns colegas. Nós mesmos recrutávamos os alunos, cobrávamos e dávamos as aulas. Naquele verão, todos os envolvidos ganharam o suficiente para pagar as despesas do ano seguinte.

Durante a pós-graduação, trabalhei como professor particular. Mais tarde, quando a SenseTime ainda estava começando e seu escritório continuava sendo um quarto do hotel Wenjin, perto do portão sul da Tsinghua, entrei como um dos primeiros funcionários fundadores.

À primeira vista, essas coisas têm pouco em comum. Mas me davam realização da mesma maneira: resolvendo um problema real e vendo algo mudar porque eu havia participado.

Por isso, quando surgiu a nova era da inteligência geral, voltei a me colocar instintivamente do lado das aplicações. Minha preocupação não é como provar que uma tecnologia é mais poderosa, mas o que ela poderá fazer, no fim, por uma pessoa concreta.

Depois de saltar

Entrar no próximo rio não significava que eu soubesse imediatamente para onde nadar.

Nos primeiros meses depois de deixar a SenseTime, continuei procurando oportunidades, por instinto, no lugar que conhecia melhor. Com um amigo, tentei alguns produtos relacionados a imagens. Afinal, quase dez anos do meu trabalho tinham sido ligados à visão computacional. Começar dali parecia a escolha mais natural.

Mas, depois de algum tempo, senti cada vez mais que a direção não estava certa. O problema não estava necessariamente nos produtos, mas no fato de ainda partirmos do que sabíamos fazer, e não do que os usuários realmente precisavam.

Depois de carregar um martelo por dez anos, mesmo que se mude de sala, é fácil continuar vendo pregos em toda parte.

Percebi que entrar em um novo campo não é apenas mudar de lugar e continuar usando os métodos que deram certo no passado. Recomeçar de verdade significa deixar de lado, por algum tempo, as respostas que conhecemos melhor.

Então fiz uma pergunta a mim mesmo: se eu não levasse em conta a experiência técnica acumulada nos últimos dez anos, qual produto de IA eu mais gostaria de ter?

Minha resposta foi: notas.

O produto que eu mais queria

Desde o ensino secundário, sigo uma regra: “Não ler sem escrever e fazer anotações.” Para mim, notas nunca foram apenas um lugar onde guardar informações. São uma extensão da memória e uma parte do pensamento.

As pessoas costumam chamá-las de “segundo cérebro”, mas esse suposto segundo cérebro não é realmente inteligente.

Colocamos coisas nele, mas ainda precisamos organizá-las, encontrá-las, criar conexões e descobrir como recuperá-las por conta própria. Ele se parece mais com um disco rígido externo do que com outro cérebro.

Esta geração de grandes modelos me fez acreditar pela primeira vez que isso poderia mudar de forma fundamental. As notas do futuro talvez não apenas preservem o que uma pessoa escreveu. Poderão compreender esse conteúdo, encontrar relações entre as ideias, ajudar-nos a lembrar quando necessário e até participar do nosso pensamento.

Não quero criar um aplicativo de notas com alguns recursos de IA acrescentados, mas um segundo cérebro verdadeiramente inteligente.

A inteligência geral é o próximo rio em que saltei. As notas inteligentes são a primeira direção para a qual decidi nadar depois de entrar.

Ainda não cheguei à outra margem

Antes disso, eu havia feito muitas coisas com características de empreendedorismo. Organizar o curso de verão na universidade foi uma startup informal. Entrar na SenseTime quando ela estava começando foi participar de uma startup. Fundar, dentro da SenseTime, as equipes de detecção de vivacidade e visão industrial também se parecia muito com empreender dentro de uma empresa.

Mas desta vez foi diferente. Em junho deste ano, deixei uma empresa pela primeira vez, coloquei-me inteiramente no mercado e comecei a empreender em tempo integral no sentido verdadeiro.

Hoje é 31 de dezembro de 2023. Já se passou meio ano desde que deixei a SenseTime.

Ainda não encontrei as respostas para todas as perguntas nem cheguei a uma margem que possa ser chamada de sucesso. Estou aprendendo muitas coisas que antes não dominava: criar um produto, compreender um mercado e fazer com que os dois se encaixem.

Para muitas pessoas, esse estado pode ser doloroso. Para mim, ele traz uma familiaridade de que eu sentia falta, porque voltei a um lugar em que não sei as respostas.

Este é o primeiro texto do meu blog pessoal. Não o escrevo porque a jornada terminou, mas porque quero registrar, no momento em que ela realmente começa, por que parti. No futuro, continuarei escrevendo aqui sobre tecnologia, produtos e pessoas, além das coisas que estou criando.

Não sei para onde este rio acabará fluindo.

Mas, olhando para trás, várias mudanças importantes da minha vida começaram com a mesma escolha: depois de investir tempo suficiente e perceber que eu entrava aos poucos em uma zona de conforto, começava a procurar o próximo rio.

Em junho deste ano, fiz essa escolha outra vez.

Ainda estou na água.

На момент ухода у меня не было ни проверенного продукта, ни готового бизнес-плана. Я даже не решил, чем именно буду заниматься.

Но я знал, что для меня снова настало время прыгнуть в следующую реку.

Я уже не впервые менял реку, но впервые ради этого пришлось покинуть компанию.

Выбор, который я делаю снова и снова

Из сельской начальной школы я поступил в среднюю школу в уездном центре, затем учился в Нанкинском университете и в магистратуре Университета Цинхуа. Во время учёбы я присоединился к SenseTime, которая только начинала работу. Там я сначала создал команду проверки живости, а позже — команду промышленного зрения.

Оглядываясь назад, я вижу, что такие перемены происходят примерно раз в несколько лет.

Они не были частью заранее составленного жизненного плана и случались не потому, что прежняя работа теряла смысл. Просто после многих лет усилий и область, и я сам постепенно становились зрелее. Работа не обязательно была закончена, но уже не заставляла меня выходить за собственные пределы.

Для многих это идеальное состояние. У меня же оно вызывает тревогу. Мне не нравится жизнь, конец которой уже виден. Поэтому время от времени мне нужно помещать себя внутрь задачи, которую я не умею решать, а порой даже не знаю, с чего начать.

«Река» здесь — не компания. Смена реки не обязательно означает увольнение. Это область, которую приходится осваивать заново, трудное дело, которое я пока не знаю, как довести до результата. За почти десять лет в SenseTime я последовательно прыгнул в две разные реки.

Но я не человек, который ищет перемен ради самих перемен. Во мне действует и другая, почти противоположная сила — чувство ответственности.

Я терпеть не могу бросать дело на полпути. Решив что-то сделать, я хочу сделать это по-настоящему хорошо. Одна сила заставляет меня искать следующую реку, другая удерживает в прежней, чтобы завершить начатое.

Мой уход в этом году стал результатом долгой борьбы этих двух сил.

Перенести алгоритмы в реальный мир

Когда я пришёл в SenseTime, то работал в исследовательском отделе, но меня всегда интересовали приложения. Я хотел знать не только то, работает ли алгоритм на экспериментальных данных, но и способен ли он войти в реальный мир и решить конкретную задачу.

Проверка живости была ключевой частью первого крупного внедрения SenseTime. До этого у нас уже были хорошие демонстрации распознавания лиц. Но когда мы столкнулись с по-настоящему масштабным применением, выяснилось, что многие производственные проблемы не решены, особенно атаки на онлайн-систему.

Система обрабатывала больше миллиона обращений в день, а на пике подвергалась сотням тысяч атак за сутки. Технологию нужно было продолжать развивать, одновременно поддерживая уже запущенный сервис. Часто это напоминало рукопашный бой. Мы регулярно уходили из офиса в три-четыре часа ночи, а иногда работали до утра.

Нередко после суток борьбы мы устраняли все известные атаки и ехали домой спать. Вскоре после того, как мы засыпали, снова звонил телефон: онлайн-систему опять взломали.

Именно в ходе этой работы мы помогли развить сквозную архитектуру моделей SenseTime для распознавания лиц. Раньше многие алгоритмы глубокого обучения применялись только на отдельных этапах, а вся система представляла собой цепочку из нескольких ступеней. Но перед постоянно меняющимися атаками вручную собранные методы не могли обновляться достаточно быстро. Единственным выходом, который мы видели, была единая сквозная модель глубокого обучения, обучающаяся непосредственно на данных. Тогда мы называли её «объединённой моделью».

Этот проект впервые дал мне по-настоящему понять: если алгоритм работает в демонстрации, это ещё не означает, что технология состоялась. Она становится действительно пригодной только после того, как выдержит масштабный трафик, непрерывные атаки и самые разные неожиданности.

Позднее мы вышли на рынок смартфонов. Перед каждым запуском производители организовывали тестирование с участием сотен людей, а другие компании и пользователи постоянно находили новые проблемы. Это заставило нас создать одну из крупнейших, насколько нам было известно, команд тестирования среди тогдашних компаний, разрабатывавших алгоритмы ИИ, и попытаться перебрать все возможности.

Одну проблему с контровым светом удавалось воспроизвести только в определённом мужском туалете одного из офисов SenseTime. Другая, которую мы называли «лицо света и тени», возникала лишь под конкретным углом под определённым деревом. Чтобы продукт надёжно работал в повседневной жизни сотен миллионов людей, мы проделали огромное количество такой работы.

В итоге наше решение для проверки личности на смартфонах стало лидером рынка.

Это была первая река, в которую я вошёл в SenseTime. Проверка живости началась с исследовательской демонстрации, прошла несколько циклов крупномасштабного внедрения и превратилась в довольно зрелую область. К 2019 году многие задачи, прежде требовавшие рискованных поисков, можно было решать за счёт накопленного опыта. Я не закончил всё, но понимал, что снова оказался в зоне комфорта.

И вновь мне стало не по себе.

Остаться в SenseTime и сменить реку

В 2019 году я не покинул SenseTime. Я решил внутри той же компании перейти от проверки личности к промышленному зрению.

После масштабного исследования и множества обсуждений с руководством и коммерческой командой мы выбрали первым проектом промышленного зрения интеллектуальную проверку контактной сети C4 высокоскоростных железных дорог.

Вместе с предпродажной командой я посетил много железнодорожных центров проверки и управлений. Больше всего мне запомнился центр в Сюйчжоу. Перед нашим приездом только что прошёл дождь. Центр находился в довольно удалённом месте, и мы добирались к нему по грязной дороге, проваливаясь на каждом шагу.

Внутри стояли ряды компьютеров. Инспекторы ежедневно часами просматривали изображения в поисках возможных неисправностей контактной сети. Почти у всех были тёмные круги под глазами. Обнаружив неисправность, они ещё должны были проехать вдоль тысяч километров путей и устранить каждую проблему. Иногда речь шла лишь об ослабленном винте или гайке, но всё равно приходилось ехать на место. Ни мороз, ни жара не позволяли отложить ремонт.

Потребность казалась мне болезненно очевидной. По меньшей мере мы должны были помочь им с самой трудоёмкой частью — просмотром изображений.

Лишь начав работу, мы обнаружили, насколько задача сложнее, чем представлялось. В контактной сети больше ста типов деталей и свыше тысячи типов дефектов. Даже эти цифры появились только после многократного подсчёта и упорядочивания вместе с сотрудниками на местах. Многие проверки опирались на опыт, а документы и исторические данные были разбросаны по разным местам. Нам пришлось собирать материалы с нуля, работать рядом с линейными специалистами и разбираться с каждым видом неисправности по отдельности. Это заняло почти два года.

Ещё более серьёзной была проблема малой выборки. Неисправности на высокоскоростных линиях по природе крайне редки. Некоторые могут не произойти ни разу за год, но при возникновении иметь тяжёлые последствия. Мы не могли ждать, пока наберётся достаточно примеров. Приходилось заново проектировать методы под реальные условия.

В конце концов проект удался и был внедрён в широком масштабе.

Промышленное зрение стало второй рекой, в которую я вошёл в SenseTime. Я не менял компанию, но изменилось почти всё привычное: задачи, данные, клиенты, критерии оценки и способы работы. Я снова стал новичком, а затем вместе с командой сделал то, чего прежде мы делать не умели.

Именно поэтому я говорю, что река — не компания. Меня по-настоящему привлекает не уход из места, а вход в более трудную задачу.

2022 год, когда я не сменил реку

После выхода SenseTime на биржу компания столкнулась с новым финансовым и ресурсным давлением. Одновременно предыдущая волна компьютерного зрения постепенно входила в зрелую фазу, а следующая ещё не обозначилась ясно. Многие дела упирались в ресурсы, рынок или границы технологии и уже не могли развиваться так же быстро, как раньше.

Весь 2022 год я находился в несколько подавленном, или, иначе говоря, пассивном состоянии. Я начал работать по обычному расписанию.

В этой фразе нет ничего плохого. Обычный рабочий день — нормальная жизнь для многих людей. Но я всегда относился к работе как к собственному стартапу. Внезапно оказавшись в таком состоянии, я, наоборот, почувствовал глубокий упадок.

Внешне та жизнь была гораздо комфортнее прежней. Я больше не просыпался каждый день с новой задачей, которую обязательно нужно решить, и реже проводил ночи без сна из-за онлайн-сбоя. Но именно этот комфорт и мучил меня: я начал представлять, какой станет моя жизнь через несколько лет, если ничего не изменить.

Я не ушёл сразу. Меня удержала ответственность.

Железнодорожная инспекция получилась, но мы не добились успеха в контроле качества на автомобильных заводах и не завершили интеллектуальную промышленную роботизированную руку. Я хотел продолжать эту работу. Мне было трудно принять, что я создал команду и выбрал направление, а затем покину его в самый тяжёлый момент.

Одна сила говорила искать следующую реку, другая — что работа передо мной ещё не закончена.

В 2022 году вторая сила была сильнее.

Я увидел следующую реку

В конце прошлого года появился ChatGPT. В первой половине этого года вышел GPT-4. Прежнее равновесие нарушилось.

Тогда у меня возникло очень сильное ощущение: компьютерное зрение лишилось собственной цитадели.

Будущее не будет состоять из отдельных моделей для текста, изображений и речи. Компьютерное зрение не исчезнет, но станет частью того, как универсальные модели понимают мир. Раньше мы воспринимали зрение как самостоятельный технический центр; теперь появлялась более широкая эпоха общего интеллекта.

Это было не очередное техническое обновление внутри компьютерного зрения. Изменилось основное русло развития технологий.

Я вновь увидел реку, течений которой ещё не знал.

Раньше я мог сменить реку, оставаясь в SenseTime. Переход от проверки личности к промышленному зрению в 2019 году был таким выбором. Но на этот раз следующая река не лежала на продолжении моей прежней работы. Я хотел войти в общий интеллект и новые приложения, которые он создаст.

Моя должность и ответственность по-прежнему относились к промышленному зрению. Если бы я остался, то должен был полностью посвятить себя этой работе. Нельзя было нести текущую ответственность и одновременно готовить для себя следующую остановку.

Чтобы действительно прыгнуть в следующую реку, сначала нужно было уйти с прежней позиции.

В первой половине года мне становилось всё труднее сидеть на месте. Я не знал, какие продукты в итоге создаст новая технология и что смогу в ней сделать. Но понимал: если ждать, пока всё станет ясно, я рискую упустить годы, когда важнее всего начать учиться.

У действительно важных дел редко наступает момент, когда можно объявить их «полностью завершёнными». Если ответственность означает ждать, пока закончатся все проблемы, человек может никогда не сделать нового выбора.

Постепенно я понял, что ответственность не сводится к тому, чтобы остаться. Остаться — тоже выбор, и за его последствия тоже нужно отвечать. Чувство ответственности не должно становиться причиной бесконечно откладывать решение.

Поэтому в июне этого года я ушёл из SenseTime.

Почему я ушёл без ответа

До ухода я не готовил тайком стартап вне работы и не собирался вынести из SenseTime её действующий бизнес, чтобы основать собственную компанию.

Если я всё ещё работал в компании, отвечал за её результат и пользовался предоставленными ею ресурсами, но втайне думал, как подготовить следующую остановку, то чувствовал бы себя нечестным по отношению к нынешней работе.

Это означало, что в момент увольнения я действительно не был готов.

Я не был готов к предпринимательству не потому, что относился к нему несерьёзно, а потому, что до ухода продолжал серьёзно относиться к прежней работе.

Я мог только сначала уйти, а затем искать ответ.

Умение плавать не означает знакомства с каждой рекой. Невозможно и стоять на берегу до полного понимания течения, а уже потом прыгать. Некоторые знания можно получить только в воде, а некоторые направления видны лишь после начала движения.

На этот раз смена реки означала увольнение. Но двигало мной не стремление уйти само по себе, а появление следующей реки.

Выбрать сторону приложений

После появления ChatGPT я обсуждал с друзьями вопрос: если придёт AGI, окажется ли интеллект сосредоточен в руках нескольких платформ или будет доступен большему числу людей?

Я считал, что в конечном счёте он непременно распространится.

Строго доказать это я не могу. Моя интуиция проста: сама Вселенная не является централизованной системой. Реальный мир состоит из бесчисленных людей, устройств, сред и локальных задач. Если интеллект действительно войдёт в этот мир, он тоже должен существовать во множестве форм. Обучение фундаментальных моделей может сосредоточиться в нескольких компаниях, но приложения интеллекта не будут принадлежать только нескольким платформам.

Поэтому я не хочу создавать фундаментальные модели. Я хочу делать приложения, которые с помощью нового интеллекта отвечают на одну конкретную потребность за другой.

Этот выбор связан и с моей жизнью.

Я вырос в деревне. С начальной до средней школы я проводил много каникул и свободного времени, помогая семье в сельском хозяйстве. Я сеял, вносил удобрения и пестициды, водил трактор и разводил животных. На каникулах я считал себя самым настоящим крестьянином.

Мне нравилось чувство результата от такой работы. Хорошо ли вырос урожай, хорошо ли выращены животные — всё было видно напрямую. Если сделать работу чуть лучше, жизнь одной семьи становилась чуть лучше.

В университете у меня было много подработок, а ещё мы с однокурсниками организовали летние дополнительные занятия. Мы сами набирали учеников, собирали оплату и преподавали. Тем летом все участники заработали достаточно на расходы следующего года.

Во время учёбы в магистратуре я давал частные уроки. Позже, когда SenseTime только начинала и её офисом всё ещё служил гостиничный номер в отеле Wenjin у южных ворот Цинхуа, я присоединился к ней как один из первых сотрудников-основателей.

Внешне между этими делами мало общего. Но они давали мне ощущение достижения одинаковым способом: я решал реальную проблему и видел, как что-то меняется благодаря моему участию.

Поэтому, когда стала появляться новая эпоха общего интеллекта, я снова инстинктивно выбрал сторону приложений. Меня волнует не то, как доказать, что технология сильнее, а то, что в итоге она сможет сделать для конкретного человека.

После прыжка

Войти в следующую реку не значило сразу понять, куда плыть.

В первые месяцы после ухода из SenseTime я по привычке искал возможности там, где разбирался лучше всего. Вместе с другом мы попробовали несколько продуктов, связанных с изображениями. Всё-таки почти десять лет моей работы относились к компьютерному зрению. Начать оттуда казалось естественнее всего.

Но спустя некоторое время я всё сильнее чувствовал, что направление неверно. Проблема была не обязательно в самих продуктах, а в том, что мы по-прежнему исходили из того, что умеем, а не из того, что действительно нужно пользователям.

Если десять лет носить молоток, то даже в другой комнате легко продолжать видеть повсюду гвозди.

Я понял, что войти в новую область — не значит просто сменить место и продолжить применять прежние успешные методы. Настоящее начало с нуля требует на время отложить самые привычные ответы.

Тогда я спросил себя: если не учитывать технический опыт предыдущих десяти лет, какой продукт с ИИ я больше всего хотел бы получить сам?

Моим ответом были заметки.

Продукт, которого я хотел больше всего

Со средней школы я следую правилу: «Не читать, не делая пометок и записей». Для меня заметки никогда не были только местом хранения. Они продолжают память и являются частью мышления.

Их часто называют «вторым мозгом», но этот так называемый второй мозг на самом деле не обладает интеллектом.

Мы складываем в него информацию, но всё равно должны сами её организовывать, искать, устанавливать связи и думать, как извлечь обратно. Он больше похож на внешний жёсткий диск, чем на ещё один мозг.

Это поколение больших моделей впервые заставило меня поверить, что положение может измениться коренным образом. Возможно, заметки будущего будут не только хранить написанное человеком. Они смогут понимать содержание, находить связи, помогать нам вспоминать в нужный момент и даже участвовать в мышлении.

Я хочу создать не программу для заметок с несколькими функциями ИИ, а по-настоящему интеллектуальный второй мозг.

Общий интеллект — следующая река, в которую я прыгнул. Умные заметки — первое направление, в котором я решил плыть, оказавшись в ней.

До другого берега ещё далеко

До этого я много раз делал вещи, похожие на предпринимательство. Летние занятия в университете были неформальным бизнесом. Присоединиться к SenseTime в самом начале означало участвовать в стартапе. Создание команд проверки живости и промышленного зрения внутри SenseTime тоже было похоже на предпринимательство внутри компании.

Но на этот раз всё было иначе. В июне этого года я впервые покинул компанию, полностью вышел на рынок и начал заниматься собственным бизнесом полный день в настоящем смысле слова.

Сегодня 31 декабря 2023 года. С моего ухода из SenseTime прошло полгода.

Я ещё не нашёл ответов на все вопросы и не достиг берега, который можно назвать успехом. Я учусь многому, в чём прежде не был силён: создавать продукт, понимать рынок и добиваться их соответствия.

Для многих такое состояние может быть мучительным. Мне же оно дарит давно забытое чувство знакомого, потому что я снова оказался там, где не знаю ответов.

Это первая статья в моём личном блоге. Я пишу её не потому, что путешествие завершилось, а потому, что в момент его настоящего начала хочу записать, почему отправился в путь. В будущем я продолжу писать здесь о технологиях, продуктах, людях и о том, что создаю.

Я не знаю, куда в конце концов приведёт эта река.

Но, оглядываясь назад, я вижу: несколько важных перемен в моей жизни начинались с одного выбора. Уделив делу достаточно времени и заметив, что постепенно вхожу в зону комфорта, я начинал искать следующую реку.

В июне этого года я снова сделал такой выбор.

Я всё ещё в воде.

Khi ra đi, tôi không có sản phẩm đã được kiểm chứng, không có kế hoạch kinh doanh hoàn chỉnh, thậm chí còn chưa nghĩ rõ mình sẽ làm gì.

Nhưng tôi biết đã đến lúc mình lại nhảy vào dòng sông tiếp theo.

Đây không phải lần đầu tôi đổi sông, nhưng là lần đầu tôi phải rời một công ty để làm điều đó.

Lựa chọn tôi lặp lại nhiều lần

Tôi đi từ một trường tiểu học ở nông thôn đến trường trung học ở thị trấn huyện, sau đó học đại học tại Đại học Nam Kinh và học cao học tại Đại học Thanh Hoa. Trong thời gian học cao học, tôi gia nhập SenseTime khi công ty vừa khởi đầu. Tại đó, trước hết tôi thành lập nhóm phát hiện người sống, rồi sau này thành lập nhóm thị giác công nghiệp.

Nhìn lại, những thay đổi như vậy dường như xảy ra sau mỗi vài năm.

Chúng không nằm trong một kế hoạch cuộc đời được thiết kế sẵn, cũng không phải vì công việc cũ đã mất ý nghĩa. Chỉ là sau nhiều năm đầu tư, cả lĩnh vực ấy lẫn tôi đều dần trưởng thành. Công việc chưa chắc đã hoàn tất, nhưng nó không còn buộc tôi vượt qua giới hạn của chính mình.

Với nhiều người, đó là trạng thái lý tưởng. Với tôi, nó lại gây bất an. Tôi không thích một cuộc đời mà từ chỗ đứng hiện tại đã có thể nhìn thấy tận cùng. Vì vậy, cứ sau một thời gian, tôi cần đặt mình vào một bài toán chưa biết làm, thậm chí không biết phải bắt đầu từ đâu.

“Dòng sông” ở đây không phải là một công ty. Đổi sông cũng không nhất thiết có nghĩa là nghỉ việc. Đó là một lĩnh vực cần học lại từ đầu, một việc khó mà tôi chưa biết cách làm thành công. Trong gần mười năm ở SenseTime, tôi đã lần lượt nhảy vào hai dòng sông khác nhau.

Nhưng tôi không phải người chỉ theo đuổi sự thay đổi. Trong tôi còn có một sức mạnh gần như ngược lại: tinh thần trách nhiệm.

Tôi đặc biệt ghét bỏ dở việc. Một khi đã quyết định làm điều gì, tôi muốn thực sự làm tốt. Sức mạnh thứ nhất khiến tôi tìm dòng sông tiếp theo; sức mạnh thứ hai giữ tôi lại trong dòng sông cũ để hoàn thành việc đã bắt đầu.

Việc ra đi năm nay là kết quả của cuộc giằng co lâu dài giữa hai sức mạnh ấy.

Đưa thuật toán vào thế giới thực

Khi mới gia nhập SenseTime, tôi ở bộ phận nghiên cứu, nhưng điều tôi luôn quan tâm là ứng dụng. Tôi không chỉ muốn biết một thuật toán có hiệu quả trên dữ liệu thí nghiệm hay không, mà còn muốn biết nó có thể đi vào thế giới thực và giải quyết một vấn đề cụ thể hay không.

Phát hiện người sống là phần cốt lõi trong dự án triển khai lớn đầu tiên của SenseTime. Trước đó, chúng tôi đã có một số bản demo nhận diện khuôn mặt khá tốt. Nhưng khi thực sự đối mặt với ứng dụng quy mô lớn, chúng tôi mới nhận ra nhiều vấn đề trong môi trường sản xuất vẫn chưa được giải quyết, đặc biệt là các cuộc tấn công vào hệ thống trực tuyến.

Khi ấy hệ thống có hơn một triệu lượt truy cập mỗi ngày. Vào cao điểm, một ngày thậm chí phải chịu hàng trăm nghìn cuộc tấn công. Công nghệ cần tiếp tục đột phá, còn dịch vụ đã chạy thì đồng thời phải được duy trì. Vì vậy, nhiều lúc công việc giống một cuộc cận chiến. Chúng tôi thường rời công ty lúc ba, bốn giờ sáng, có khi thức trắng đêm.

Tình huống thường gặp là chúng tôi chiến đấu suốt một ngày một đêm, xử lý tất cả các kiểu tấn công đã biết rồi về ngủ. Vừa chợp mắt không lâu, điện thoại lại gọi đến: hệ thống trực tuyến lại bị phá vỡ.

Chính trong quá trình ấy, chúng tôi tham gia thúc đẩy việc xây dựng hệ thống mô hình đầu-cuối cho nhận diện khuôn mặt của SenseTime. Trước đó, nhiều thuật toán học sâu chỉ được dùng ở từng khâu cục bộ, còn toàn bộ hệ thống là chuỗi nhiều giai đoạn nối tiếp nhau. Nhưng trước các kiểu tấn công không ngừng biến đổi, phương pháp kết hợp thủ công không thể đáp ứng nhu cầu lặp nhanh. Lối thoát duy nhất chúng tôi thấy là để một mô hình học sâu đầu-cuối học trực tiếp từ dữ liệu. Khi ấy chúng tôi gọi nó là “mô hình đại nhất thống”.

Dự án này lần đầu khiến tôi thực sự hiểu rằng một thuật toán có hiệu quả trong bản demo không có nghĩa là nó đã đứng vững. Chỉ khi chịu được lưu lượng quy mô lớn, các cuộc tấn công liên tục và đủ loại tình huống bất ngờ, nó mới trở thành công nghệ thực sự có thể sử dụng.

Sau đó chúng tôi bước vào lĩnh vực điện thoại thông minh. Trước mỗi lần ra mắt, các hãng điện thoại đều tổ chức kiểm thử với hàng trăm người; các công ty cùng ngành và người dùng cũng liên tục tìm ra vấn đề mới. Điều đó buộc chúng tôi xây dựng một trong những đội kiểm thử lớn nhất, theo những gì chúng tôi biết khi ấy, trong các công ty thuật toán AI, nhằm cố gắng vét hết mọi khả năng.

Có một lỗi ngược sáng chỉ có thể tái hiện trong một nhà vệ sinh nam cụ thể tại một văn phòng của SenseTime. Một lỗi khác, được chúng tôi gọi là “khuôn mặt âm dương”, chỉ xuất hiện ở một góc nhất định dưới một cái cây nhất định. Để một sản phẩm hoạt động tin cậy trong đời sống hằng ngày của hàng trăm triệu người, chúng tôi đã làm rất nhiều việc như vậy.

Cuối cùng, chúng tôi đưa xác thực danh tính trên điện thoại thông minh lên vị trí dẫn đầu thị trường.

Đây là dòng sông đầu tiên tôi bước vào tại SenseTime. Phát hiện người sống bắt đầu từ một bản demo trong nghiên cứu, trải qua nhiều vòng kiểm nghiệm bằng ứng dụng quy mô lớn, rồi cuối cùng trở thành một lĩnh vực khá trưởng thành. Đến năm 2019, nhiều bài toán trước kia phải mạo hiểm khám phá đã có thể giải quyết nhờ kinh nghiệm tích lũy. Tôi chưa làm xong tất cả, nhưng biết mình đã lại đi vào vùng an toàn.

Thế là tôi lại bắt đầu đứng ngồi không yên.

Ở lại SenseTime, đổi sang dòng sông khác

Năm 2019, tôi không rời SenseTime. Tôi chọn chuyển từ xác thực danh tính sang thị giác công nghiệp ngay trong cùng một công ty.

Sau nhiều nghiên cứu và nhiều lần thảo luận với lãnh đạo công ty cùng đội kinh doanh, chúng tôi chọn dự án thị giác công nghiệp đầu tiên là kiểm tra thông minh hệ thống dây tiếp xúc C4 của đường sắt cao tốc.

Tôi cùng đội tiền bán hàng đã đến thăm nhiều trung tâm kiểm tra và cục đường sắt. Nơi để lại ấn tượng sâu sắc nhất là trung tâm kiểm tra Từ Châu. Khi chúng tôi đến, trời vừa mưa xong. Trung tâm nằm ở nơi khá hẻo lánh; chúng tôi lội qua con đường lầy lội, mỗi bước chân đều lún xuống.

Bên trong là từng dãy máy tính. Mỗi ngày, nhân viên kiểm tra phải dành rất nhiều thời gian xem hình để tìm các hỏng hóc có thể có trên hệ thống dây tiếp xúc đường sắt. Gần như ai cũng có quầng thâm dưới mắt. Sau khi tìm ra lỗi, họ còn phải dọc theo hàng nghìn kilômét đường sắt để xử lý từng vấn đề. Đôi khi chỉ là một con vít hoặc đai ốc bị lỏng, họ vẫn phải đến hiện trường. Dù rét buốt hay nóng bức, việc sửa chữa đều không thể trì hoãn.

Tôi thấy nhu cầu này quá nhức nhối. Ít nhất, chúng tôi nên giúp họ giải quyết phần tốn thời gian nhất: xem hình.

Chỉ sau khi thực sự bắt đầu, chúng tôi mới nhận ra việc này khó hơn tưởng tượng rất nhiều. Trong hệ thống dây tiếp xúc có hơn một trăm loại linh kiện và hơn một nghìn loại khuyết tật. Ngay cả những con số này cũng chỉ dần được hệ thống hóa sau khi chúng tôi nhiều lần thống kê cùng đồng nghiệp tuyến đầu. Trước đây, phần lớn công việc kiểm tra dựa vào kinh nghiệm, còn tài liệu và dữ liệu lịch sử nằm rải rác ở nhiều nơi. Chúng tôi phải thu thập tài liệu từ đầu, làm việc cùng đồng nghiệp tuyến đầu và hiểu rõ từng hạng mục lỗi. Quá trình này kéo dài gần hai năm.

Thách thức lớn hơn là mẫu ít. Hỏng hóc trên đường sắt cao tốc vốn cực kỳ hiếm; có loại cả năm chưa chắc xuất hiện một lần, nhưng một khi xảy ra có thể gây hậu quả nghiêm trọng. Chúng tôi không thể đợi đến khi thu thập đủ mẫu mới bắt đầu, mà chỉ có thể thiết kế lại phương pháp theo điều kiện thực tế.

Cuối cùng, dự án đã thành công và được ứng dụng trên quy mô lớn.

Thị giác công nghiệp là dòng sông thứ hai tôi bước vào tại SenseTime. Tôi không đổi công ty, nhưng gần như mọi thứ quen thuộc đều thay đổi: vấn đề, dữ liệu, khách hàng, tiêu chuẩn đánh giá và cách làm việc. Tôi lại trở thành người mới, rồi cùng đội làm được một việc mà ban đầu chúng tôi không biết làm.

Đó là lý do tôi nói dòng sông không đồng nghĩa với công ty. Điều thực sự thu hút tôi không phải rời một nơi, mà là bước vào một vấn đề khó hơn.

Năm 2022 không đổi sông

Sau khi SenseTime niêm yết, công ty bắt đầu đối mặt với áp lực mới về tài chính và nguồn lực. Đồng thời, làn sóng thị giác máy tính trước đó dần bước vào giai đoạn trưởng thành, còn làn sóng tiếp theo vẫn chưa xuất hiện rõ ràng. Nhiều việc bị giới hạn bởi nguồn lực, thị trường hoặc biên giới công nghệ, khó có thể tiến nhanh như trước.

Trong suốt năm 2022, tôi ở trạng thái hơi chán nản, hay có thể nói là phần nào buông xuôi. Tôi bắt đầu đi làm và tan làm bình thường.

Nghe câu này không có gì sai. Làm việc theo giờ bình thường vốn là cuộc sống bình thường của nhiều người. Nhưng trước đây tôi luôn coi công việc như khởi nghiệp. Đột nhiên đi vào trạng thái như vậy, tôi lại cảm thấy vô cùng sa sút.

Bề ngoài, cuộc sống lúc đó thoải mái hơn trước rất nhiều. Không còn mỗi sáng thức dậy là có một vấn đề mới buộc phải giải quyết, cũng không còn thường xuyên thức trắng vì một sự cố trực tuyến. Nhưng chính sự thoải mái ấy mới khiến tôi khó chịu: tôi bắt đầu có thể hình dung vài năm sau cuộc sống sẽ ra sao nếu không có gì thay đổi.

Tôi không rời đi ngay. Điều giữ tôi lại là tinh thần trách nhiệm.

Kiểm tra đường sắt cao tốc đã thành công, nhưng kiểm tra chất lượng trong nhà máy ô tô chưa thành công, cánh tay robot công nghiệp thông minh cũng chưa hoàn tất. Tôi muốn tiếp tục những việc này. Tôi khó có thể chấp nhận rằng mình đã thành lập một đội, chọn một hướng, rồi lại rời đi vào lúc khó khăn nhất.

Một sức mạnh bảo tôi nên tìm dòng sông tiếp theo; sức mạnh kia nói công việc trước mắt vẫn chưa xong.

Trong năm 2022, sức mạnh thứ hai lớn hơn.

Tôi nhìn thấy dòng sông tiếp theo

Cuối năm ngoái, ChatGPT xuất hiện. Nửa đầu năm nay, GPT-4 xuất hiện. Thế cân bằng cũ bị phá vỡ.

Khi ấy tôi có một cảm giác rất mạnh: thị giác máy tính đã bị chiếm mất căn cứ.

Tương lai sẽ không được tạo thành từ các mô hình văn bản, hình ảnh và giọng nói độc lập với nhau. Thị giác máy tính sẽ không biến mất, nhưng sẽ trở thành một phần trong cách mô hình tổng quát hiểu thế giới. Trước đây chúng tôi coi thị giác là một trung tâm kỹ thuật hoàn chỉnh; giờ đây, một thời đại trí tuệ tổng quát lớn hơn đang xuất hiện.

Đây không phải một lần nâng cấp công nghệ bên trong thị giác máy tính, mà là dòng chính của phát triển công nghệ đã thay đổi.

Tôi lại nhìn thấy một dòng sông mà mình chưa quen dòng chảy.

Trước đây, tôi có thể ở lại SenseTime và đổi sông. Việc chuyển từ xác thực danh tính sang thị giác công nghiệp năm 2019 là một lựa chọn như vậy. Nhưng lần này, dòng sông tiếp theo không nằm trên đường kéo dài của công việc cũ. Điều tôi muốn bước vào là trí tuệ tổng quát và những ứng dụng mới do nó tạo ra.

Khi ấy vai trò và trách nhiệm của tôi vẫn nằm ở thị giác công nghiệp. Nếu tiếp tục ở lại, tôi nên dốc toàn lực làm tốt thị giác công nghiệp, chứ không nên vừa gánh trách nhiệm cũ vừa chuẩn bị cho chặng đường tiếp theo của riêng mình.

Muốn thực sự nhảy vào dòng sông tiếp theo, trước hết tôi phải rời vai trò cũ.

Đến nửa đầu năm nay, tôi càng lúc càng không thể ngồi yên. Tôi không biết công nghệ mới cuối cùng sẽ tạo ra sản phẩm gì, cũng không biết mình có thể làm gì trong đó. Nhưng tôi biết nếu tiếp tục đợi đến khi mọi thứ đều được nghĩ rõ, rất có thể tôi sẽ bỏ lỡ những năm đáng lẽ phải bắt đầu học hỏi nhất.

Những việc thực sự quan trọng thường không có khoảnh khắc có thể tuyên bố “đã hoàn tất tất cả”. Nếu trách nhiệm có nghĩa là phải đợi mọi vấn đề kết thúc, một người có thể mãi mãi không đưa ra được lựa chọn mới.

Tôi dần nhận ra rằng trách nhiệm không chỉ có nghĩa là ở lại. Ở lại cũng là một lựa chọn và cũng phải gánh hậu quả của nó. Tinh thần trách nhiệm không thể trở thành lý do để trì hoãn lựa chọn vô thời hạn.

Vì vậy, tháng 6 năm nay, tôi rời SenseTime.

Vì sao khi ra đi tôi vẫn chưa có câu trả lời

Trước khi rời đi, tôi không bí mật chuẩn bị khởi nghiệp ngoài công việc, cũng không định mang hoạt động kinh doanh SenseTime đang làm ra ngoài để tự khởi nghiệp.

Nếu tôi vẫn làm việc cho một công ty, gánh trách nhiệm giao kết quả cho công ty và sử dụng nguồn lực công ty cung cấp, nhưng trong lòng lại nghĩ cách chuẩn bị cho chặng tiếp theo của mình, tôi sẽ thấy điều đó không trung thực với công việc hiện tại.

Điều này có nghĩa là lúc nghỉ việc, tôi thực sự chưa sẵn sàng.

Tôi chưa sẵn sàng khởi nghiệp không phải vì không nghiêm túc với việc khởi nghiệp, mà vì trước khi rời đi, tôi vẫn nghiêm túc với công việc cũ.

Tôi chỉ có thể rời đi trước, rồi mới tìm câu trả lời.

Biết bơi không có nghĩa là quen mọi dòng sông. Một người cũng không thể đứng trên bờ, đợi đến khi hiểu hoàn toàn dòng chảy rồi mới nhảy xuống. Có kiến thức chỉ có thể đạt được trong nước, và có hướng đi chỉ có thể nhìn thấy sau khi bắt đầu hành động.

Lần này, đổi sông tình cờ có nghĩa là nghỉ việc. Nhưng điều thúc đẩy tôi ra đi không phải khát vọng nghỉ việc, mà là dòng sông tiếp theo đã xuất hiện.

Tôi chọn phía ứng dụng

Sau khi ChatGPT xuất hiện, tôi từng thảo luận với bạn bè một câu hỏi: nếu AGI đến, trí tuệ cuối cùng sẽ tập trung trong tay một số ít nền tảng, hay được nhiều người chia sẻ hơn?

Phán đoán của tôi là cuối cùng nó nhất định sẽ lan rộng.

Tôi không thể chứng minh điều này một cách chặt chẽ. Trực giác của tôi chỉ là bản thân vũ trụ không phải một hệ thống tập trung. Thế giới thực được tạo nên từ vô số con người, thiết bị, môi trường và vấn đề cục bộ. Nếu trí tuệ thực sự đi vào thế giới này, nó cũng nhất định tồn tại dưới vô số hình thức khác nhau. Việc huấn luyện mô hình nền tảng có thể tập trung ở một số ít công ty, nhưng ứng dụng của trí tuệ sẽ không chỉ thuộc về một số ít nền tảng.

Vì vậy tôi không muốn làm mô hình nền tảng. Tôi muốn làm ứng dụng hơn, dùng trí tuệ mới để đáp lại từng nhu cầu cụ thể.

Lựa chọn này cũng đến từ trải nghiệm cuộc đời tôi.

Tôi lớn lên ở nông thôn. Từ tiểu học đến trung học, tôi dành nhiều kỳ nghỉ và thời gian rảnh tham gia việc đồng áng của gia đình. Gieo hạt, bón phân, phun thuốc, lái máy kéo, nuôi động vật—hầu như việc gì tôi cũng từng làm. Trong kỳ nghỉ, tôi thấy mình là một người nông dân thực thụ.

Tôi thích cảm giác thành tựu mà những việc này mang lại. Hoa màu có được trồng tốt hay không, vật nuôi có được nuôi tốt hay không, kết quả đều rất trực tiếp. Bạn làm tốt hơn một chút thì cuộc sống của một gia đình cũng tốt hơn một chút.

Khi học đại học, tôi làm nhiều việc bán thời gian và cùng bạn học mở một lớp phụ đạo mùa hè. Chúng tôi tự tuyển học viên, thu tiền và dạy học. Mùa hè đó, mấy người cùng tham gia đều kiếm đủ chi phí sinh hoạt cho năm sau.

Khi học cao học, tôi từng dạy kèm. Sau đó, lúc SenseTime vừa bắt đầu và văn phòng vẫn là một phòng khách sạn Wenjin gần cổng nam Thanh Hoa, tôi gia nhập với tư cách một trong những nhân viên sáng lập đầu tiên.

Bề ngoài, những việc này không có nhiều điểm chung. Nhưng chúng mang lại cho tôi cảm giác thành tựu theo cùng một cách: giải quyết một vấn đề có thật và thấy mọi thứ thay đổi nhờ sự tham gia của mình.

Vì vậy, khi thời đại trí tuệ tổng quát mới xuất hiện, theo bản năng tôi vẫn đứng về phía ứng dụng. Điều tôi quan tâm không phải làm thế nào chứng minh công nghệ mạnh hơn, mà là cuối cùng nó có thể làm gì cho một con người cụ thể.

Sau khi nhảy xuống

Bước vào dòng sông tiếp theo không có nghĩa là tôi lập tức biết nên bơi về đâu.

Trong những tháng đầu sau khi rời SenseTime, theo bản năng tôi vẫn tìm cơ hội từ nơi quen thuộc nhất. Tôi cùng một người bạn thử một số sản phẩm liên quan đến hình ảnh. Dù sao, gần mười năm làm việc trước đây của tôi đều liên quan đến thị giác máy tính. Xuất phát từ đó có vẻ là lựa chọn tự nhiên nhất.

Nhưng sau một thời gian, tôi ngày càng cảm thấy hướng đi không đúng. Vấn đề chưa chắc nằm ở bản thân những sản phẩm ấy, mà ở chỗ chúng tôi vẫn xuất phát từ việc mình biết làm gì, chứ không phải người dùng thực sự cần gì.

Khi một người đã cầm búa mười năm, dù đổi sang căn phòng khác, mọi thứ trước mắt vẫn rất dễ trở thành đinh.

Tôi nhận ra rằng bước vào lĩnh vực mới không chỉ là đổi một nơi để tiếp tục dùng phương pháp từng thành công. Thực sự bắt đầu lại có nghĩa là tạm thời đặt xuống những câu trả lời mình quen thuộc nhất.

Vì thế tôi tự hỏi: nếu không xét đến tích lũy kỹ thuật của mười năm qua, sản phẩm AI mà bản thân tôi muốn nhất là gì?

Câu trả lời của tôi là ghi chú.

Sản phẩm tôi mong muốn nhất

Từ khi học trung học, tôi đã có thói quen “không động bút thì không đọc sách”. Với tôi, ghi chú chưa bao giờ chỉ là nơi lưu tài liệu. Nó là phần mở rộng của trí nhớ và cũng là một phần của tư duy.

Người ta thường gọi ghi chú là “bộ não thứ hai”, nhưng bộ não thứ hai này thực ra không thật sự thông minh.

Chúng ta đưa mọi thứ vào đó, nhưng vẫn phải tự sắp xếp, tìm kiếm, thiết lập liên hệ và nghĩ cách lấy chúng ra. Nó giống một ổ cứng ngoài hơn là một bộ não khác.

Thế hệ mô hình lớn này lần đầu khiến tôi tin rằng điều đó có thể thay đổi tận gốc. Ghi chú trong tương lai có lẽ không chỉ lưu lại những gì một người đã viết. Nó có thể hiểu nội dung, tìm ra liên hệ giữa chúng, giúp chúng ta nhớ lại khi cần, thậm chí tham gia vào quá trình suy nghĩ.

Điều tôi muốn làm không phải phần mềm ghi chú được thêm vài tính năng AI, mà là một bộ não thứ hai thực sự thông minh.

Trí tuệ tổng quát là dòng sông tiếp theo tôi đã nhảy vào. Ghi chú thông minh là hướng đầu tiên tôi quyết định bơi tới sau khi xuống nước.

Vẫn chưa tới bờ bên kia

Trước đó, tôi từng làm nhiều việc mang tính khởi nghiệp. Mở lớp phụ đạo khi học đại học là một lần khởi nghiệp không chính thức; gia nhập SenseTime khi công ty vừa bắt đầu là tham gia một lần khởi nghiệp; thành lập đội phát hiện người sống và thị giác công nghiệp trong SenseTime cũng rất giống khởi nghiệp bên trong một công ty.

Nhưng lần này khác. Tháng 6 năm nay, lần đầu tiên tôi rời một công ty, đặt mình hoàn toàn vào thị trường và bắt đầu khởi nghiệp toàn thời gian theo đúng nghĩa.

Hôm nay là ngày 31 tháng 12 năm 2023. Đã nửa năm kể từ khi tôi rời SenseTime.

Tôi vẫn chưa tìm được câu trả lời cho mọi vấn đề, cũng chưa tới bất kỳ bờ bên kia nào có thể gọi là thành công. Tôi đang học nhiều việc trước đây mình không giỏi, bao gồm làm sản phẩm, hiểu thị trường và làm cho hai điều ấy khớp nhau.

Trạng thái này có thể đau khổ với nhiều người, nhưng với tôi lại mang một cảm giác quen thuộc đã lâu không gặp. Bởi vì tôi lại trở về một nơi mà mình không biết câu trả lời.

Đây là bài viết đầu tiên trên blog cá nhân của tôi. Tôi viết nó không phải vì hành trình này đã kết thúc, mà vì muốn ghi lại lý do mình lên đường ngay vào lúc hành trình thực sự bắt đầu. Sau này, tôi cũng sẽ tiếp tục viết ở đây những suy nghĩ về công nghệ, sản phẩm, con người và những thứ mình đang tạo ra.

Tôi không biết cuối cùng dòng sông này sẽ chảy về đâu.

Nhưng nhìn lại, vài thay đổi quan trọng trong đời tôi đều bắt đầu từ cùng một lựa chọn: sau khi đầu tư đủ lâu và nhận ra mình dần đi vào vùng an toàn, tôi bắt đầu tìm dòng sông tiếp theo.

Tháng 6 năm nay, tôi lại đưa ra lựa chọn ấy.

Tôi vẫn đang ở trong nước.

离开的时候，我没有已经验证的产品，没有完整的商业计划，甚至没有想清楚具体要做什么。

但我知道，自己又到了该跳进下一条河的时候。

这不是我第一次换河，却是第一次必须为此离开一家公司。

我反复做出的选择

我从农村小学考到县城中学，后来去南京大学读本科，再到清华大学读研究生。读研期间，我加入了刚刚起步的商汤。进入商汤以后，我先创立活体检测团队，后来又创立工业视觉团队。

回头看，这些变化大约每隔几年就会发生一次。

这些变化不是预先设计好的人生计划，也不是因为原来的事情失去了意义。只是在多年投入之后，一个领域和我都逐渐成熟。事情未必已经做完，却不再迫使我突破自己。

对很多人来说，这是理想状态；对我来说，却会带来不安。我不喜欢一眼可以看到头的人生，所以每隔一段时间，就需要把自己放进一个不会做、甚至不知道从哪里开始的问题里。

这里的“河”不是一家公司。换一条河，也不一定意味着离职。它指的是一个需要重新学习的领域，一件还不知道怎样做成的事情。在商汤近十年，我就先后跳进过两条不同的河。

但我并不是一个只追求变化的人。我身上还有一股几乎相反的力量：责任感。

我特别讨厌半途而废。一件事情既然决定做了，我就希望把它真正做好。前一股力量让我寻找下一条河，后一股力量则让我留在原来的河里，把已经开始的事情做完。

今年的离开，是这两股力量长期对抗的结果。

把算法推到真实世界

我刚加入商汤时在研究部，但我关心的一直是应用。我想知道的，不只是一个算法在实验数据上是否有效，而是它能不能进入真实世界，解决一个具体的问题。

活体检测是商汤第一个重大落地项目的核心部分。在此之前，我们在人脸识别上已经有了一些不错的演示。但真正面对大规模应用时，我们才发现，许多面向生产的问题并没有解决，尤其是线上系统被攻击的问题。

当时系统每天有超过一百万次访问，高峰期一天甚至会遭遇数十万次攻击。技术需要继续突破，已经上线的业务又必须同时被支撑住，所以很多时候都是肉搏战。我们经常凌晨三四点才离开公司，有时干脆通宵。

经常发生的情况是，我们经过一天一夜的奋战，解决了所有已知攻击，回去睡了一觉。刚睡下不久，电话又来了：线上再次被攻破了。

也正是在这个过程中，我们参与推动了商汤人脸识别端到端模型体系的建立。在此之前，许多深度学习算法仍只用于局部环节，整个系统则由多个阶段串联而成。但面对不断变化的攻击方式，人工组合的方法无法满足快速迭代的需求。我们看到的唯一出路，是让一个端到端的深度学习模型直接从数据中学习。我们当时把它叫作“大一统模型”。

这个项目让我第一次真正理解，一个算法在演示中有效，并不等于它已经成立。只有当它经受住大规模访问、持续攻击和各种意外情况的考验，才成为一种真正可用的技术。

后来我们又进入智能手机。手机厂商每次上线前都会组织几百人测试，同行和用户也会不断发现新的问题。这迫使我们建立了在我们当时所知的 AI 算法公司中规模最大的测试团队之一，试图穷尽所有可能性。

有一个逆光问题，只能在商汤某个办公区的一间男厕所里复现。另一个被我们称作“阴阳脸”的问题，必须站在某棵树下的特定角度才能出现。为了让一个产品在数亿人的日常生活中可靠工作，我们做了大量这样的事情。

最终，我们把智能手机上的身份认证做到了市场领先。

这是我在商汤进入的第一条河。活体检测从论文 Demo 开始，经过几轮大规模应用的检验，最后变成了一个已经相当成熟的领域。到 2019 年，许多过去必须冒险探索的问题，已经可以依靠积累的经验解决。我并没有做完所有事情，但我知道，自己已经重新进入了舒适区。

于是，我又开始坐不住了。

留在商汤，换一条河

2019 年，我没有离开商汤。我选择在同一家公司里，从身份认证转向工业视觉。

经过大量调研，并与公司领导、商务团队多次讨论后，我们选择的第一个工业视觉项目，是高铁 C4 接触网智能巡检。

我和售前团队走访了很多铁路检测中心和铁路局。给我印象最深的是徐州检测中心。我们去的时候刚下完雨，检测中心在一个比较偏僻的地方，路上一片泥泞，我们深一脚浅一脚地走进去。

里面是一排排电脑。检测员每天要花大量时间看图，寻找铁路接触网上可能存在的故障，几乎每个人都有黑眼圈。找到故障以后，他们还要沿着上千公里的铁路，一个一个处理问题。有时只是一个螺丝或者螺母松动，他们也必须赶到现场。无论严寒酷暑，都不能耽误。

我觉得这个需求太痛了。至少，我们应该先帮他们解决最耗时间的一件事：看图。

真正开始以后，我们才发现这件事比想象中更难。接触网里有一百多种零部件、一千多种缺陷。这些数字也是我们拉着一线同事反复统计，才逐渐梳理出来的。过去许多检测工作依赖经验，资料和历史数据散落在不同地方。我们不得不从头收集资料，与一线同事一起工作，把故障项点逐个弄明白。这个过程陆续花了近两年。

更大的挑战是小样本。高铁线路上的故障本来就极少，有些一年都未必出现一次，但一旦发生，后果可能很严重。我们不能等到收集了足够多的样本再开始，只能根据真实条件重新设计方法。

最后，这个项目做成了，并实现了规模化应用。

工业视觉是我在商汤进入的第二条河。我没有换公司，却几乎换掉了原来熟悉的一切：问题、数据、客户、评价标准和工作方式都变了。我又重新成为一个初学者，然后和团队一起把一件原本不会做的事情做成。

这也是为什么我说，河不等于公司。真正吸引我的不是离开一个地方，而是进入一个更难的问题。

没有换河的 2022 年

商汤上市之后，开始面临新的财务和资源压力。与此同时，上一轮计算机视觉浪潮逐渐进入成熟期，下一轮浪潮还没有清楚出现。很多事情受到资源、市场或者技术边界的限制，很难再像以前那样快速推进。

整个 2022 年，我处在一种有些颓废，或者说有些躺平的状态。我开始正常上下班。

这句话听起来并没有什么问题。正常上下班本来就是很多人的正常生活。但我过去一直把工作当作创业。突然进入这样一种状态，我反而感到非常消沉。

表面上看，那段生活比以前舒适得多。没有每天醒来都必须解决的新问题，也不再经常为了一个线上故障通宵。但真正让我难受的恰恰是：我开始可以想象，如果什么都不改变，几年后的生活会是什么样子。

我没有马上离开。让我留下来的，是责任感。

高铁巡检已经做成了，但汽车工厂的质量检测没有做成，工业智能机械臂也没有做完。我希望把这些事情继续做下去。我无法轻易接受自己创立了一支团队、选择了一个方向，最后却在它最困难的时候离开。

一股力量告诉我，应该寻找下一条河；另一股力量告诉我，眼前的事情还没有完成。

在 2022 年，后一股力量更强。

我看见了下一条河

去年年底，ChatGPT 出现。今年上半年，GPT-4 出现。原来的平衡被打破了。

我当时有一种很强烈的感觉：计算机视觉被“偷家”了。

未来不会由文字、图像和语音各自独立的模型组成。计算机视觉不会消失，但它会成为通用模型理解世界的一部分。过去我们把视觉当作一个完整的技术中心；现在，一个更大的通用智能时代正在出现。

这不是计算机视觉内部的一次技术升级，而是技术发展的主线发生了变化。

我又看见了一条还不熟悉水流的河。

过去，我可以留在商汤内部换河。2019 年从身份认证转向工业视觉，就是一次这样的选择。但这一次，下一条河不在我原来工作的延长线上。我要进入的，是通用智能以及由它创造的新应用。

当时我的岗位和责任仍然在工业视觉。如果继续留下，我就应该全力把工业视觉做好，而不应该一边承担原来的责任，一边为自己的下一站做准备。

要真正跳进下一条河，我必须先离开原来的岗位。

到了今年上半年，我越来越坐不住了。我不知道新的技术最终会创造什么产品，也不知道自己能在其中做什么。但我知道，如果继续等到一切都想清楚，我很可能会错过最应该开始学习的几年。

真正重要的事情，往往没有一个可以宣布“全部完成”的时刻。如果责任意味着必须等到所有问题都结束，一个人就可能永远无法作出新的选择。

我逐渐意识到，责任不只意味着留下。留下同样是一种选择，也需要承担它的后果。责任感不能变成无限推迟选择的理由。

所以，今年 6 月，我离开了商汤。

为什么离开时还没有答案

离开之前，我没有在工作之外秘密准备创业，也没有打算把商汤正在做的业务拿出去创业。

如果我仍然在一家公司工作，承担着公司交付的责任，也使用着公司提供的资源，心里想的却是怎样为自己的下一站做准备，我会觉得这对原来的工作不够诚实。

这意味着我离职时确实没有准备好。

我没有准备好创业，并不是因为我没有认真对待创业，而是因为在离开之前，我仍然在认真对待原来的工作。

我只能先离开，再寻找答案。

会游泳，不等于熟悉每一条河。一个人也不可能站在岸上，等到完全了解水流以后再跳进去。有些知识只能在水里获得，有些方向也只能在开始行动以后看见。

这一次，换河恰好意味着离职。但推动我离开的，并不是对离职本身的向往，而是下一条河已经出现了。

我选择应用这一边

ChatGPT 出现后，我和朋友讨论过一个问题：如果 AGI 到来，智能最终会集中在少数平台手中，还是会被更多人共享？

我的判断是，它最终一定会扩散出去。

我无法严格证明这一点。我的直觉只是，宇宙本身并不是一个集中式系统。真实世界由无数个人、设备、环境和局部问题组成。智能如果要真正进入这个世界，也一定会以无数不同的形式存在。基础模型的训练可能集中在少数公司，但智能的应用不会只属于少数平台。

所以我不想做基础模型。我更想做应用，用新的智能回应一个个具体的需求。

这个选择也来自我的人生经历。

我在农村长大。从小学到中学，我会花很多假期和课余时间参与家里的农活。播种、施肥、打药、开拖拉机、养殖动物，我几乎都做过。在假期里，我觉得自己就是一个实实在在的农民。

我喜欢这种事情带来的成就感。庄稼种得好不好，动物养得好不好，结果都很直接。你做得好一点，一个家庭的生活就会好一点。

大学时，我做过许多兼职，也和同学办过一个暑期补习班。我们自己招生、收费、带学生。那个暑假，参与的几个同学都赚到了第二年的生活费。

读研究生时，我做过家教。后来商汤刚刚起步，办公室还设在清华南门附近文津酒店的一间客房里。我加入进去，成为早期创始员工。

这些事情表面上没有什么共同点。但它们给我成就感的方式是一样的：解决一个实实在在的问题，并且看到事情因为自己的参与发生变化。

所以，当新的通用智能时代出现时，我仍然本能地站在应用这一边。我关心的不是怎样证明技术更强，而是它最终能为具体的人做什么。

跳进去以后

进入下一条河，并不意味着我马上就知道应该游向哪里。

离开商汤后的最初几个月，我仍然本能地从自己最熟悉的地方寻找机会。我和朋友尝试过一些与图像有关的产品。毕竟，我过去近十年的工作都与计算机视觉有关，从这里出发似乎是最自然的选择。

但做了一段时间以后，我越来越觉得方向不太对。问题不一定在那些产品本身，而在于我们仍然从自己会什么出发，而不是从用户真正需要什么出发。

当一个人拿了十年锤子之后，即使换了一间房子，看到的仍然很容易全是钉子。

我意识到，进入新的领域，并不只是换一个地方继续使用过去成功的方法。真正的重新开始，意味着暂时放下自己最熟悉的答案。

于是我问了自己一个问题：如果不考虑过去十年的技术积累，我自己最想要的 AI 产品是什么？

我的答案是笔记。

我最想要的产品

我从中学开始就有“不动笔墨不读书”的习惯。对我来说，笔记从来不只是保存资料的地方。它是记忆的延伸，也是思考的一部分。

人们常把笔记叫作“第二大脑”，但这个所谓的第二大脑其实并不真正智能。

我们把东西放进去，仍然需要自己整理、寻找、建立联系，再想办法把它们取出来。它更像一个外接硬盘，而不是另一个大脑。

这一代大模型让我第一次相信，这件事可能发生根本性的变化。未来的笔记也许不仅能保存一个人写过什么，还能理解这些内容，找到它们之间的联系，在需要的时候帮助我们回忆，甚至参与思考。

我想做的，不是一个增加了几个 AI 功能的笔记软件，而是一个真正智能的第二大脑。

通用智能是我跳进的下一条河。智能笔记，是我进入以后，决定首先游向的方向。

还没有到达对岸

在此之前，我做过很多具有创业性质的事情。大学时办补习班，是一次非正式的创业；加入刚刚起步的商汤，是参与一次创业；在商汤内部创立活体检测和工业视觉团队，也很像在一家公司里创业。

但这一次不同。今年 6 月，我第一次离开一家公司，把自己完全放进市场里，开始真正意义上的全职创业。

今天是 2023 年 12 月 31 日。距离离开商汤，已经过去半年。

我还没有找到所有问题的答案，也没有到达任何可以被称为成功的对岸。我正在学习许多过去并不擅长的事情，包括做产品、做市场，以及如何让二者匹配。

这种状态对很多人来说可能很痛苦，对我来说反而有一种久违的熟悉感。因为我又回到了一个自己不知道答案的地方。

这是我的个人博客的第一篇文章。我写下它，不是因为这段旅程已经结束，而是想在真正开始的时候，记录自己为什么出发。以后，我也会在这里继续写下我对技术、产品和人的思考，以及我正在创造的东西。

我不知道这条河最终会流向哪里。

但回头看，我人生中几次重要的变化，都始于同一个选择：当我经过足够长的投入，又发现自己逐渐进入舒适区，就开始寻找下一条河。

今年 6 月，我又做了一次这样的选择。

我现在还在水里。

離開時，我沒有已經驗證的產品，沒有完整的商業計畫，甚至還沒想清楚具體要做什麼。

但我知道，自己又到了該跳進下一條河的時候。

這不是我第一次換河，卻是第一次必須為此離開一家公司。

我反覆做出的選擇

我從農村小學考進縣城中學，後來到南京大學讀本科，再到清華大學讀研究所。讀研期間，我加入了剛起步的商湯。進入商湯後，我先創立活體偵測團隊，後來又創立工業視覺團隊。

回頭看，這些變化大約每隔幾年就會發生一次。

這些變化不是預先設計好的人生計畫，也不是因為原來的事情失去了意義。只是在投入多年之後，一個領域和我都逐漸成熟。事情未必已經做完，卻不再迫使我突破自己。

對很多人來說，這是理想狀態；對我來說，卻會帶來不安。我不喜歡一眼可以看到盡頭的人生，所以每隔一段時間，就需要把自己放進一個不會做、甚至不知道從哪裡開始的問題裡。

這裡的「河」不是一家公司。換一條河，也不一定意味著離職。它指的是一個需要重新學習的領域，一件還不知道怎樣做成的事情。在商湯近十年，我就先後跳進過兩條不同的河。

但我不是一個只追求變化的人。我身上還有一股幾乎相反的力量：責任感。

我特別討厭半途而廢。一件事情既然決定做了，我就希望把它真正做好。前一股力量讓我尋找下一條河，後一股力量則讓我留在原來的河裡，把已經開始的事情做完。

今年的離開，是這兩股力量長期對抗的結果。

把演算法推向真實世界

我剛加入商湯時在研究部，但我關心的一直是應用。我想知道的，不只是一個演算法在實驗資料上是否有效，而是它能不能進入真實世界，解決一個具體的問題。

活體偵測是商湯第一個重大落地專案的核心部分。在此之前，我們在人臉辨識上已經有了一些不錯的展示。但真正面對大規模應用時，我們才發現，許多生產環境的問題並沒有解決，尤其是線上系統被攻擊的問題。

當時系統每天有超過一百萬次存取，高峰期一天甚至會遭遇數十萬次攻擊。技術需要繼續突破，已經上線的業務又必須同時撐住，所以很多時候都是肉搏戰。我們經常凌晨三四點才離開公司，有時乾脆通宵。

經常發生的情況是，我們經過一天一夜的奮戰，解決了所有已知攻擊，回去睡了一覺。剛睡下不久，電話又來了：線上再次被攻破。

也正是在這個過程中，我們參與推動了商湯人臉辨識端到端模型體系的建立。在此之前，許多深度學習演算法仍只用於局部環節，整個系統則由多個階段串聯而成。但面對不斷變化的攻擊方式，人工組合的方法無法滿足快速迭代的需求。我們看到的唯一出路，是讓一個端到端的深度學習模型直接從資料中學習。我們當時把它叫作「大一統模型」。

這個專案讓我第一次真正理解，一個演算法在展示中有效，並不等於它已經成立。只有當它經受住大規模存取、持續攻擊和各種意外情況的考驗，才會成為一種真正可用的技術。

後來我們又進入智慧型手機。手機廠商每次上線前都會組織幾百人測試，同行和使用者也會不斷發現新的問題。這迫使我們建立了在我們當時所知的 AI 演算法公司中規模最大的測試團隊之一，試圖窮盡所有可能性。

有一個逆光問題，只能在商湯某個辦公區的一間男廁裡重現。另一個被我們稱作「陰陽臉」的問題，必須站在某棵樹下的特定角度才會出現。為了讓一個產品在數億人的日常生活中可靠運作，我們做了大量這樣的事情。

最終，我們把智慧型手機上的身分認證做到了市場領先。

這是我在商湯進入的第一條河。活體偵測從論文展示開始，經過幾輪大規模應用的檢驗，最後變成一個已經相當成熟的領域。到 2019 年，許多過去必須冒險探索的問題，已經可以依靠累積的經驗解決。我並沒有做完所有事情，但我知道，自己已經重新進入了舒適圈。

於是，我又開始坐不住了。

留在商湯，換一條河

2019 年，我沒有離開商湯。我選擇在同一家公司裡，從身分認證轉向工業視覺。

經過大量調研，並與公司領導、商務團隊多次討論後，我們選擇的第一個工業視覺專案，是高鐵 C4 接觸網智慧巡檢。

我和售前團隊走訪了很多鐵路檢測中心和鐵路局。給我印象最深的是徐州檢測中心。我們去的時候剛下完雨，檢測中心在一個比較偏僻的地方，路上一片泥濘，我們深一腳淺一腳地走進去。

裡面是一排排電腦。檢測員每天要花大量時間看圖，尋找鐵路接觸網上可能存在的故障，幾乎每個人都有黑眼圈。找到故障後，他們還要沿著上千公里的鐵路，一個一個處理問題。有時只是一顆螺絲或螺帽鬆動，他們也必須趕到現場。無論嚴寒酷暑，都不能耽誤。

我覺得這個需求太痛了。至少，我們應該先幫他們解決最耗時間的一件事：看圖。

真正開始後，我們才發現這件事比想像中更難。接觸網裡有一百多種零件、一千多種缺陷。這些數字也是我們和第一線同事反覆統計，才逐漸梳理出來的。過去許多檢測工作依賴經驗，資料和歷史數據散落在不同地方。我們不得不從頭收集資料，與第一線同事一起工作，把故障項目逐個弄明白。這個過程陸續花了近兩年。

更大的挑戰是小樣本。高鐵線路上的故障本來就極少，有些一年都未必出現一次，但一旦發生，後果可能很嚴重。我們不能等到收集了足夠多的樣本再開始，只能根據真實條件重新設計方法。

最後，這個專案做成了，並實現了規模化應用。

工業視覺是我在商湯進入的第二條河。我沒有換公司，卻幾乎換掉了原來熟悉的一切：問題、資料、客戶、評估標準和工作方式都變了。我又重新成為一個初學者，然後和團隊一起把一件原本不會做的事情做成。

這也是為什麼我說，河不等於公司。真正吸引我的不是離開一個地方，而是進入一個更難的問題。

沒有換河的 2022 年

商湯上市後，開始面臨新的財務和資源壓力。與此同時，上一輪電腦視覺浪潮逐漸進入成熟期，下一輪浪潮還沒有清楚出現。很多事情受到資源、市場或技術邊界的限制，很難再像以前那樣快速推進。

整個 2022 年，我處在一種有些頹廢，或者說有些躺平的狀態。我開始正常上下班。

這句話聽起來並沒有什麼問題。正常上下班本來就是很多人的正常生活。但我過去一直把工作當作創業。突然進入這樣一種狀態，我反而感到非常消沉。

表面上看，那段生活比以前舒適得多。沒有每天醒來都必須解決的新問題，也不再經常為了一個線上故障通宵。但真正讓我難受的恰恰是：我開始可以想像，如果什麼都不改變，幾年後的生活會是什麼樣子。

我沒有馬上離開。讓我留下來的，是責任感。

高鐵巡檢已經做成了，但汽車工廠的品質檢測沒有做成，工業智慧機械手臂也沒有做完。我希望把這些事情繼續做下去。我無法輕易接受自己創立了一支團隊、選擇了一個方向，最後卻在它最困難的時候離開。

一股力量告訴我，應該尋找下一條河；另一股力量告訴我，眼前的事情還沒有完成。

在 2022 年，後一股力量更強。

我看見了下一條河

去年年底，ChatGPT 出現。今年上半年，GPT-4 出現。原來的平衡被打破了。

我當時有一種很強烈的感覺：電腦視覺被「偷家」了。

未來不會由文字、圖像和語音各自獨立的模型組成。電腦視覺不會消失，但它會成為通用模型理解世界的一部分。過去我們把視覺當作一個完整的技術中心；現在，一個更大的通用智慧時代正在出現。

這不是電腦視覺內部的一次技術升級，而是技術發展的主線發生了變化。

我又看見了一條還不熟悉水流的河。

過去，我可以留在商湯內部換河。2019 年從身分認證轉向工業視覺，就是一次這樣的選擇。但這一次，下一條河不在我原來工作的延長線上。我要進入的，是通用智慧以及由它創造的新應用。

當時我的職位和責任仍然在工業視覺。如果繼續留下，我就應該全力把工業視覺做好，而不應該一邊承擔原來的責任，一邊為自己的下一站做準備。

要真正跳進下一條河，我必須先離開原來的職位。

到了今年上半年，我越來越坐不住了。我不知道新的技術最終會創造什麼產品，也不知道自己能在其中做什麼。但我知道，如果繼續等到一切都想清楚，我很可能會錯過最應該開始學習的幾年。

真正重要的事情，往往沒有一個可以宣布「全部完成」的時刻。如果責任意味著必須等到所有問題都結束，一個人就可能永遠無法作出新的選擇。

我逐漸意識到，責任不只意味著留下。留下同樣是一種選擇，也需要承擔它的後果。責任感不能變成無限推遲選擇的理由。

所以，今年 6 月，我離開了商湯。

為什麼離開時還沒有答案

離開之前，我沒有在工作之外秘密準備創業，也沒有打算把商湯正在做的業務拿出去創業。

如果我仍然在一家公司工作，承擔著公司交付的責任，也使用著公司提供的資源，心裡想的卻是怎樣為自己的下一站做準備，我會覺得這對原來的工作不夠誠實。

這意味著我離職時確實沒有準備好。

我沒有準備好創業，並不是因為我沒有認真對待創業，而是因為在離開之前，我仍然在認真對待原來的工作。

我只能先離開，再尋找答案。

會游泳，不等於熟悉每一條河。一個人也不可能站在岸上，等到完全了解水流後再跳進去。有些知識只能在水裡獲得，有些方向也只能在開始行動後看見。

這一次，換河恰好意味著離職。但推動我離開的，並不是對離職本身的嚮往，而是下一條河已經出現了。

我選擇應用這一邊

ChatGPT 出現後，我和朋友討論過一個問題：如果 AGI 到來，智慧最終會集中在少數平台手中，還是會被更多人共享？

我的判斷是，它最終一定會擴散出去。

我無法嚴格證明這一點。我的直覺只是，宇宙本身並不是一個集中式系統。真實世界由無數個人、裝置、環境和局部問題組成。智慧如果要真正進入這個世界，也一定會以無數不同的形式存在。基礎模型的訓練可能集中在少數公司，但智慧的應用不會只屬於少數平台。

所以我不想做基礎模型。我更想做應用，用新的智慧回應一個個具體的需求。

這個選擇也來自我的人生經歷。

我在農村長大。從小學到中學，我會花很多假期和課餘時間參與家裡的農活。播種、施肥、噴藥、開拖拉機、養殖動物，我幾乎都做過。在假期裡，我覺得自己就是一個實實在在的農民。

我喜歡這種事情帶來的成就感。莊稼種得好不好，動物養得好不好，結果都很直接。你做得好一點，一個家庭的生活就會好一點。

大學時，我做過許多兼職，也和同學辦過一個暑期補習班。我們自己招生、收費、帶學生。那個暑假，參與的幾個同學都賺到了第二年的生活費。

讀研究所時，我做過家教。後來商湯剛剛起步，辦公室還設在清華南門附近文津酒店的一間客房裡。我加入進去，成為早期創始員工。

這些事情表面上沒有什麼共同點。但它們帶給我成就感的方式是一樣的：解決一個實實在在的問題，並且看到事情因為自己的參與而發生變化。

所以，當新的通用智慧時代出現時，我仍然本能地站在應用這一邊。我關心的不是怎樣證明技術更強，而是它最終能為具體的人做什麼。

跳進去以後

進入下一條河，並不意味著我馬上就知道應該游向哪裡。

離開商湯後的最初幾個月，我仍然本能地從自己最熟悉的地方尋找機會。我和朋友嘗試過一些與圖像有關的產品。畢竟，我過去近十年的工作都與電腦視覺有關，從這裡出發似乎是最自然的選擇。

但做了一段時間後，我越來越覺得方向不太對。問題不一定在那些產品本身，而在於我們仍然從自己會什麼出發，而不是從使用者真正需要什麼出發。

當一個人拿了十年錘子之後，即使換了一個房間，看到的仍然很容易全是釘子。

我意識到，進入新的領域，並不只是換一個地方繼續使用過去成功的方法。真正的重新開始，意味著暫時放下自己最熟悉的答案。

於是我問了自己一個問題：如果不考慮過去十年的技術累積，我自己最想要的 AI 產品是什麼？

我的答案是筆記。

我最想要的產品

我從中學開始就有「不動筆墨不讀書」的習慣。對我來說，筆記從來不只是保存資料的地方。它是記憶的延伸，也是思考的一部分。

人們常把筆記叫作「第二大腦」，但這個所謂的第二大腦其實並不真正智慧。

我們把東西放進去，仍然需要自己整理、尋找、建立連結，再想辦法把它們取出來。它更像一個外接硬碟，而不是另一個大腦。

這一代大模型讓我第一次相信，這件事可能發生根本性的變化。未來的筆記也許不僅能保存一個人寫過什麼，還能理解這些內容，找到它們之間的連結，在需要的時候幫助我們回憶，甚至參與思考。

我想做的，不是一個增加了幾個 AI 功能的筆記軟體，而是一個真正智慧的第二大腦。

通用智慧是我跳進的下一條河。智慧筆記，是我進入以後，決定首先游向的方向。

還沒有到達對岸

在此之前，我做過很多具有創業性質的事情。大學時辦補習班，是一次非正式的創業；加入剛剛起步的商湯，是參與一次創業；在商湯內部創立活體偵測和工業視覺團隊，也很像在一家公司裡創業。

但這一次不同。今年 6 月，我第一次離開一家公司，把自己完全放進市場裡，開始真正意義上的全職創業。

今天是 2023 年 12 月 31 日。距離離開商湯，已經過去半年。

我還沒有找到所有問題的答案，也沒有到達任何可以被稱為成功的對岸。我正在學習許多過去並不擅長的事情，包括做產品、做市場，以及如何讓兩者匹配。

這種狀態對很多人來說可能很痛苦，對我來說反而有一種久違的熟悉感。因為我又回到了一個自己不知道答案的地方。

這是我的個人部落格的第一篇文章。我寫下它，不是因為這段旅程已經結束，而是想在真正開始的時候，記錄自己為什麼出發。以後，我也會在這裡繼續寫下我對技術、產品和人的思考，以及我正在創造的東西。

我不知道這條河最終會流向哪裡。

但回頭看，我人生中幾次重要的變化，都始於同一個選擇：當我投入了足夠長的時間，又發現自己逐漸進入舒適圈，就開始尋找下一條河。

今年 6 月，我又做了一次這樣的選擇。

我現在還在水裡。