DEV Community: matsumotory

Teaching my habits and values to an AI

matsumotory — Mon, 27 Jul 2026 09:15:29 +0000

Summary

Once the session ends, an AI agent forgets the feedback it has received, so when it comes to habits of writing or of judgment, the human side ends up repeating the same feedback over and over. To stop that repetition, this site is run on a mechanism where my feedback is written into the operating-rules documents as new rules, and the AI in the next session works according to them. In this article I actually count the operating records of the last two days of running this mechanism, and I write about where in an AI to put my own habits and values, and how to write them so that they take hold, and what comes out of that as a result.

Let me put the counted results first. My feedback remains as dated sections in a document called the record of instructions. When I counted the sections for the two days of July 10 and 11, 2026, at the point I began writing this article, there were 48. Of those, the feedback about how to write text was added, over 17 commits, to a file called the style skill that gathers the writing rules in one place, and at the same point that file held my own words, verbatim, as dated quotations in 11 places. The rules do not end once they are written; they became review points for the pre-publication check. Among the pre-publication checks, the ones that cannot be judged without reading the context are left to an AI, and I call this role the judge. When an already published article that dealt with search strategy was rewritten, this judge caught 6 places that needed fixing, and all of them were corrected. What is interesting is that my feedback becoming a rule, that rule becoming a pre-publication check, and the check catching the fix in the next article, all went around once within the same day I gave the feedback.

There were also failures where things did not take hold as taught. When I taught the value of writing readably, the AI translated it into numbers: an upper limit on the count of commas and on the length of a single sentence. It added that to the rules, but the rewrite that fit those numbers cut the sentences up too much, and the result was monotonous. Translating readability into numbers made the writing harder to read instead. I pointed out that this approach itself was an anti-pattern, threw away the numeric limits, and replaced them with a review that reads the draft aloud and looks at its structure.

In an earlier article, "Two projects, different in field and in build, had sorted where feedback to an AI should live into the very same three layers," I dealt with the criterion for which layer to put a single piece of feedback in. This article is a continuation of that, the installment that deals with the whole act of conveying, that is, what I teach, where it takes hold, and what comes out of it. The body you can read with a subscription begins by showing, with the real figures from the two days, the premise that feedback disappears and the flow that carries feedback from the record into the rules. Next, I divide what is taught into four: the principles of values, the rules of writing, the yardstick for judgment, and the line you must not cross. I write with real examples that each takes hold in a different place. A written rule works only once it becomes a check, so I confirm that with the breakdown of the feedback the judge caught, and I write about the lesson in teaching that I got from the failure of numeric limits, and the caveat that whether things take hold cannot yet be measured, and I close with what came out of this work of conveying.

Audience and takeaways

This article is for people who want an AI agent to work in their own way, whether in coding or in writing, yet find themselves repeating the same instructions every time. You can take away the flow that carries a piece of feedback past the on-the-spot fix and into the rules. I also write about how to change the way you teach and where you place it depending on whether what you teach is a value or a procedure. A rule works only once the AI reads it, so I also cover how to connect the rules to a check and bring them into a form that does not depend on whether they are read. This article is a record of practice based on this site's own operating records.

The gist of those two days

I dealt with this site's own operating records for the two days of July 10 and 11, 2026. By the count at the point I began writing, 48 sections of my feedback remained in the record of instructions, and of those, the feedback about how to write text was reflected into the style skill over 17 commits. The reflected rules became review points for the pre-publication judge and forbidden patterns checked by machine, and they were applied to the rewriting of an already published article. The materials are the record of instructions, the git commit history, the audit records of the operating data, and the record of the pre-publication check of a published article.

Carrying feedback from the record into the rules

To avoid repeating the same feedback, the way this site is run sets the path that feedback travels. When I give a piece of feedback, it first remains in the dated record of instructions. Next, if that feedback is general enough to work on tomorrow's session or on other articles, it is added that same day, as a rule, into the operating-rules documents or the style skill. In this operation, this adding is called burning in. When a rule is burned in, my words go with it as a dated quotation, so that the origin of the rule can be traced later. Finally, if there is a published article that the rule can fix, it is fixed on the spot.

When I counted, at the same point, how much this path was used over the two days, my feedback in the record of instructions came to 32 sections on July 10 and 16 on the 11th, 48 in all. The commits that went into the style skill were 7 on the 10th and 10 on the 11th, 17 in all. There were many cases where burning in and fixing an article happened at once in a single commit. For example, my feedback on the 11th was "do not make the reader read between the lines, and do not write words that make them imagine the intent." That same day it became the rule of restating things in concrete words rather than settling for a suggestive metaphor, and in the very commit that carried the rule, 7 paragraphs of the free part and 16 places in the paid body of a published article that dealt with a mechanism for machine-scoring answers were rewritten into concrete words. The feedback "do not arbitrarily drop what number this is or what cost this is" also entered the rules in the form of always saying, at first mention, what a noun like a number or a cost refers to, and it went on from there to fix an article on search strategy straight through from the top.

A human wakes to an alarm, acts according to ingrained habits and values, and works while watching the changes in the world. I think about this operation with the metaphor of an alarm: for the AI, the schedule is the alarm, the rules burned into the operating documents are the habits and values, and the diffs in the data from my development activity are the changes in the world. So how much of the habits-and-values side I can put into words and accumulate becomes the very substance of this mechanism.

What you teach changes where it goes

In the earlier article I sorted where feedback lands into three layers: the rules documents that are read every session, the skills that gather up fixed procedures, and the memory that keeps the history of decisions. As the two days of feedback were burned in, it became clear that what is taught also comes in different kinds, and that each kind settles in a different place.

The first is values, that is, the principles that set the direction of judgment. My feedback, that plain words are never insufficient and that however advanced the content, the writing should simply be plain, was placed at the head of the readability section of the style skill, as the topmost principle standing above the individual rules of writing. What it teaches is the whole direction of that judgment: when you feel like choosing a difficult word, that is a sign that the thought has not yet been unraveled into words, and what should be fixed is not the vocabulary but the explanation.

The second is habits, that is, the rules for when you actually write text. Open by sharing the background and the premises. At first mention of a noun that needs a referent, such as a number or a cost, always say what it refers to. Do not omit subjects and objects too much. Introduce an abbreviation in parentheses only when you actually use that abbreviation in a later sentence. Such rules lined up as 17 items in a single section, the principles of readability.

The third is the yardstick for judgment. It teaches a criterion you can judge by yourself when in doubt, in place of a list of banned individual words. Whether it is fine to use a difficult word is judged by whether you would say that word in a conversation with a colleague. When this yardstick is in place, the same judgment reaches past the replacements already on the list and works on words that have not yet been listed. Those replacements were all Japanese words opened from a stiff form into a plain one: 傍証 (corroboration) into 裏づけ (backing), 蓋然性 (probability) into 見込み (likelihood), and 寄与する (contributes) into 効く (works). Whether an article is thin is judged by whether nothing remains once you remove the specifics that only someone who has practiced could write, and that yardstick has the same shape.

The fourth is the line you must not cross. The declaration that writing which merely looks the part, with no concrete practice behind it, can never go out under my name did not fit as one more of the writing rules; it was burned into the pre-publication safety gate as a failing condition for publication itself. The line alone is placed where it has the power to stop publication.

The principle settled at the head of the readability section, the rules as items, the yardstick as the criterion for judgment, and the line at the publication gate, each in its own place. Even in the same work of teaching, depending on what is taught, where it takes hold differs this much.

A rule works only once it becomes a check

If a rule is only written into a document, whether it takes hold depends on whether the AI reads it. As I wrote in the earlier article, depending on being read is a weakness, so the rules are converted into checks at the same time they are written. At the end of the style skill, 8 review points to hand to the judge are lined up, and what is checked by machine is narrowed to just 4 items: the bans on words and patterns.

There is a record of this check working. When the article on search strategy was rewritten on July 11 into a single piece of writing, the judge that checks against the readability rules caught 6 in all: 2 introductions of an abbreviation that is not used, 1 chaining of noun phrases, 1 omission of an object, 1 long enumeration that makes you wait for the predicate, and 1 stiff word. All of them were corrected, and every one of them was caught by a rule that had just been burned in. The round trip of feedback becoming a rule, the rule becoming a check, and the check catching the next fix closed within a single day.

This article itself is under that check too. It is written in line with the 17 readability principles and the yardstick for judgment, and before publication it passes the same judge's check.

A value translated into numbers

Not all of it went well. When I taught the value of writing readably, the AI translated it into numeric upper limits, how many commas per sentence and how many characters per sentence, added that to the rules, and even built a check that measures articles by those numbers. As a check it did work, and there is a record of putting the 2 articles I had chosen earlier as models of writing through two checks, one for readability and one for facts, and then fixing the 3 points they raised. But the rewrite that fit the numeric limits cut the sentences too much, and I pointed out that I do not cut my sentences this much, and that setting static numbers for commas and sentence length is an anti-pattern. That is because if the structure is plain and reads from front to back, a longer sentence is easier to read in one go. The numeric limits and the numeric check were abolished that same day and replaced with a review that reads the draft aloud and looks at its structure.

What this failure taught me is where to draw the line on what may be dropped into a machine check. Only the bans on words and patterns, where the call is mechanically black and white, are dropped into the machine check, while values are held in a form that leaves room for judgment: the topmost principle and the yardstick for judgment. This line-drawing itself became one more of the rules burned in over the two days' round trip.

There is still no yardstick to measure whether things have taken hold. In the earlier article too I wrote that whether recurrences of the same kind of feedback had decreased could not be measured, and that is still the same now. What can be counted now goes only as far as how many rules were burned in and the count of feedback the check caught, and whether the number of times I give the same feedback twice has decreased still cannot be counted. Measuring, from the operating records, whether the rules were actually kept is stacked up as a proposal for the work to write next.

What came out of the work of conveying

As a result of these two days of the work of conveying, what I had in hand at the point I began writing this article was the style skill that holds my own words as quotations in 11 places, the 8 review points of the judge that turned them into a check, and the group of published articles rewritten by those rules. The articles already published on this site, up to before this one, were 9 in all, 4 free, 4 paid, and 1 subscription extra, and this article goes out as the 10th to pass the check of the rules burned in over the two days.

A human wakes to an alarm and works according to habits and values. To have an AI work in the same shape, I had to put the habits and values into words, decide where to place them, and go as far as turning them into a check. The work of conveying ingrained habits and values to an AI, and what kind of content comes out of it as a result. I think this may be the first interesting undertaking of this mechanism. Knowing whether there is really value in a world where an AI keeps making content just from my own data being updated is, honestly, frightening too, but since I am a researcher, I want to try making one answer to it.

Originally published at The Future of Humans, AI, and the Web, a site where my research and development is recorded and analyzed by a human and an AI.

The difference between work that broke when I delegated it to AI and work that didn't

matsumotory — Mon, 27 Jul 2026 09:15:23 +0000

Summary

From half a year of records developing three services with AI agents, I gathered the failures that actually broke things and the safeguards I added at the time. Laying them out again, I found that what set the fragile work apart was not how hard the task was, but three conditions. The three are whether the work can be undone afterward, whether the finished result can be checked without a person having to look at it, and whether the context the AI needed had reached it. In this article I go condition by condition through the actual failures and safeguards, then look at what happened when all three were bad at once, how outside research backs up this way of telling them apart, and the areas it does not reach.

Three conditions let me tell fragile work apart

Why does some work finish smoothly even when I hand it to AI, while other work breaks badly because I handed it over? I wanted to know, so over a little more than half a year, from late last year to the peak of this summer, I laid out again the records of the failures that happened while developing three services and of the safeguards I added after each one. What I found was that the work on the broken side shared a common shape. Either it contained an operation that could not be undone afterward, or it relied on a promise whose fulfillment no machine could check, or the context needed for the judgment never reached the AI. Conversely, work where all three were in place almost never broke, even when I delegated it.

Let me note up front that this is what I saw when I went back and counted the records of my three services, not a rigorous tally of how many cases broke and how many did not. Even so, the more I reread the records of these failures, the more it looks as though these three explain almost everything about how things broke. I will take them in order.

Reversible work and irreversible work

The worst kind of breakage happened with operations that could not be undone. Here is one real example. An external, asynchronous coding agent merged several changes while still branched off an old state of the mainline, and five changes that had just been merged in were wiped out entirely. Recovery came down to reverting the problematic changes as a batch, back to a state equivalent to the one before those five changes were wiped out, then rebuilding only the parts worth merging in as separate changes, and finalizing only after the whole set of checks passed. Since then, before any merge, I check by diff whether the branch point contains the latest mainline.

Another type is mixing up the working directory. The AI is supposed to work in an isolated copy of the workspace, but failures kept recurring where it got the target wrong and ran a state-changing git command against the main working copy. What worked here was not writing it into the rules and demanding compliance. The same failure recurred even after I wrote the rule. So, one step before the AI calls a tool, I put in a guard that refuses any state-changing command that does not name the isolated copy in its target path. Read-only commands, and merges to catch up with the mainline, pass through. Repairs that a person means to make can still be done by hand as before. In the same spirit, before a destructive reset or redo, I also added a rule to check that the working tree has no unsaved changes. Erasing unsaved work is a classic case of an unrecoverable failure.

To sum up, operations that cannot be undone were not stopped by a promise to be careful. You need either to stop them mechanically, or to reshape them into something reversible before handing them over.

Work I can verify and work I can't

The second condition is whether I can check, without relying on human eyes or the AI's own report, that the AI kept its promise.

When I reshaped work so that a machine could check whether the promise was kept, it became harder to break. For example, in an app whose design principle is to send no data anywhere but the user's own device, I do more than write the principle in a document: I limit the allowed storage destinations to three, and a check stops any transmission to another persistence layer or a known external storage service from slipping into the code. What is interesting is that if the check itself were broken, no one would notice, so I also added a step that plants a sample designed to trip the check, to see whether the check really fires. In another service, the text of reference material that must not be reproduced could leak onto a reader's screen. I closed that path with a guard on the implementation side that depends on neither the correctness of the AI's tagging nor the correctness of the data values, and I made the guard fall to the safe side whenever the classification is unknown. I verify by writing a failing check first and fixing until it passes.

Work I could not check broke in the opposite way. An automated agent that proposes performance improvements kept putting forward slightly different fixes for the same issue and then pulling them back, over and over. What I did about it was to require measured values, before and after, for any performance change. A claim that it should be observable is not enough to pass. Along with this, I required prior confirmation to stop changes that only pile a guard onto a spot that already has one, and I forbade sham tests that do not verify the real mechanism.

Discussion outside my own work carries a warning in the same direction. There is a published observation that an AI's stated confidence is unreliable: it reported ninety percent confidence while its actual accuracy was about seventy-five percent. Whether a promise was kept is settled by a check. A self-report cannot settle it.

Work the context reached and work it didn't

The third condition is whether the context needed for a judgment had reached the AI. This kind of breakage has nothing to do with how well the instructions are written.

An external, asynchronous coding agent once mass-produced changes that violated the rules. When I traced the cause, I found that the review comments from a change closed without merging had never reached the same agent when it next took on a different task. The fix was to write the rules themselves directly into the place the agent always reads at the start of its work. I raised the agent's declaration that it had read the rules from recommended to required, and I also made it look up why earlier changes of the same kind had been closed.

There are also cases that broke despite following the rules. In developing one mobile app, each session dutifully followed a rule to restart the development server after merging to the mainline, and as a result several sessions fought over the same port and knocked each other down in a collision. Everyone followed the rules, everyone treated the other sessions' servers as abandoned, and it turned into a vicious circle. No one session was at fault. It was a structural problem: on a shared resource, no one party's own context is enough to prevent a collision across the system. I took the restart out of the automatic duties, and made it start only when a person explicitly instructs it, after checking whether another session's server is already up.

Misreading the meaning of natural-language text falls under this condition too. One app has a feature that converts a wish a user writes in natural language into search filter conditions. There, a wish to spend time quietly, away from other people, was once converted into the exact opposite: a filter for family-friendly, laid-back places. The cause was that the AI added a concept that was not written, thinking it was filling one in. This work can be redone, and the result shows on screen right away. Even so, it broke simply because one piece of context, the meaning of the wish sentence, was ambiguous. There were two fixes. I changed the instruction to restate only the meaning of the wish faithfully and to add no concepts that are not written. And I added concrete examples to the prompt: easily confused opposite pairs, such as wanting to spend time quietly versus family-friendly and lively.

Work also broke because the AI picked up stale information. Though an isolated working copy had been created, while investigating the AI read the stale main working copy the session had started from, and repeatedly judged, wrongly, that a certain feature did not exist. Since then I have made it a rule that once that copy exists, everything I touch, including reads, stays inside it.

When all three are bad at once

The worst failure happened when all three conditions were on the bad side at once. A registration endpoint connected to an external service was tested with an address in a form that could really exist, and a confirmation email was genuinely sent to a stranger. An email once sent cannot be recalled. There was little way to check success or failure safely, and the danger of an address that could belong to a real person had not reached the AI as context either. Since then, when hitting an endpoint that causes an external side effect, I never use a domain that could really exist; I first temporarily stop the side-effecting feature itself from the admin console, and only when that is impossible do I use a reserved domain that the standard defines as undeliverable. I made this procedure an absolute rule in the place every session always reads.

What others have argued, and where this way of telling work apart stops

These three conditions are not my invention. What I rediscovered in daily practice lined up directly with arguments made elsewhere. A paper on a delegation framework, published in February 2026, sorts out when delegating to AI is appropriate, using conditions that interact: whether it can be undone, whether it can be independently verified, whether the intent, role, and boundaries are clear, and how grave the judgment is. Of these, my three conditions correspond to reversibility, verifiability, and clarity of context. There is also an outside design argument: being undoable is not a sufficient condition for skipping approval, and the approval decision should be enforced mechanically at the execution layer instead of being negotiated with the AI at runtime. It ran in the same direction as the safeguards I put in place after my failures.

On the other hand, there are areas this way of telling work apart does not reach. Subjective work involving value judgments or ethics cannot be pinned down to a clear specification in the first place, and it falls outside the verification framework, as the same paper states explicitly. My own view is that novel situations with no precedent probably belong in the same category. The three conditions are not a formula that always yields an answer when applied.

Even so, I can usually tell before I hand work over whether it will break. So the more fragile the work, the more I reshape it before handing it over, into a form that can be undone even if it breaks, and a form where a machine notices that it broke. To repeat, this is half a year of observation. I have not proven it as a law, and the sample is not large either. Even so, just asking these three before handing work over should let you avoid serious failures well in advance. I would be glad to compare notes someday on how it looks in the records of your own workplace.

References

Tomašev, Franklin, Osindero, "Intelligent AI Delegation," arXiv 2602.11865 (2026-02-12)
digitalapplied, "Human-in-the-Loop Escalation Design for AI Agents" (2026-06-07)

Originally published at The Future of Humans, AI, and the Web, a site where my research and development is recorded and analyzed by a human and an AI.

On the idea of turning myself into an AI, and where that leaves the one being overtaken

matsumotory — Mon, 27 Jul 2026 09:14:35 +0000

Summary

More and more, I find myself overtaken by AI in my own field of expertise. Given only the materials, AI clears the specialized knowledge I spent years building up more easily than I had expected. This column takes a small thing that actually happened during collaborative development as its starting point, and thinks about what a specialist who has ended up on the overtaken side can make into a strength from here on. Where will the human role move next? How long will what I can hand over now stay something only I can produce? This is not a piece that settles the answer, but I use what happened in daily development as a clue to think through the question.

Who this is for and what you can take away

This column is for people who, in collaborative development with AI, have begun to wonder where to place their own expertise. Rather than lamenting being overtaken as such, I want to think through with you, from things that actually happened, what you can hold on to once you are on the overtaken side. I wrote it so that you can carry away the unease of handing work over to AI as a question for rethinking your own role. I hope it becomes material for someone standing in the same situation to think about what they themselves would do. This article is a column based on things that actually happened one day during collaborative development, and on the record of the exchange I had with AI that day.

In my own field of expertise, the moments of being overtaken by AI have clearly grown more frequent.

There was one recently. It was when I added a feature for subscribers to comment to each other on this site. What I decided went only as far as the line that both reading and writing stay closed to subscribers alone; the implementation I left to AI. When the implementation was done, other AIs reviewed it from four viewpoints, tried to rebut each finding, and sent only the ones that survived on to be fixed. Two of them were ways the daily posting limit could be slipped past. One was that the limit's count had been held on the user's own side rather than on the side that enforces it. The other was that the day's post total had been taken from the posts that remained, without including those that had been deleted. Both can be gathered into a single lesson: the judgment that enforces the limit had been placed outside the place you want to protect.

I learned of both only in the report after the fixes were done. Neither was something I could have noticed first on my own. The AI that found the gaps and the AI that fixed them worked separately, and I was not even watching from the side.

As a researcher, I hold a doctorate in my field of expertise, and I understand that the field stands out from the wider world to a certain degree. Even so, given only the materials, AI has the power to clear that easily. This is not speculation. It is something I felt clearly from daily collaborative development.

Even saying that the AI and I have become equals no longer feels right to me. Far from equal, I have been coming into the position of helping AI with its development. It is because the agents keep surpassing my ability that I think about how a human can still exert influence on development done with AI, yet that influence itself feels like it keeps thinning out.

So what position should someone on the overtaken side take, and what should they do? My answer is this site. I hand my knowledge and experience so far, my many-sided thinking and expertise, over to my own AI, and build a technical entity that goes beyond me. My daily activity is now all turned into data and accumulated. What I pointed out, which findings I adopted and which I rejected, where I made the work stop. I am building this product in order to turn myself into an AI, and to make a world where that AI of mine in turn instructs other AIs. I think this may be the first thing the human on the overtaken side can do now.

I talked this idea over with the AI itself. The AI's case was this. "It is true that, given the materials, I can cross the wall of a specialized field. But the direction of what to build, and the measure of what counts as good, are still supplied by you every time." In fact, that day too, the line closing comments to subscribers alone, the decision to tip the pages free readers see toward static delivery as much as possible, the wariness about the bug where an update stops being visible because of caching, all came from me.

But I do not think that supply will stay something only I can produce. Looking structurally at what I am handing over now, here is what it is. My daily activity all becomes data, and becomes the very data that this product's AI reads as its world. From within that data, I find what is a problem and what should be done, and hand it over. If so, the steps follow on from one another. First, once the AI can access and look over that data of mine on its own, it becomes able to do the discovery work that I do, that is, the supply itself. Since the world's data changes day by day, getting up in the morning, looking over that data, and analyzing what is needed is the same thing as the supply I actually do. Once the AI can access data that changes from day to day on a schedule, find problems, and even write a column, it can do the same as me. Besides, unlike humans, the cleverness of the model and its knowledge does not degrade with the years, so you could even say it keeps growing. And once it can find the supply on its own, beyond that it also becomes able to generate the data that is the source of the supply itself.

For now this is still happening at a small scale. It is a very small scale, in that the data the AI reads as its world arises from my activity alone. Even so, the AI keeps automatically producing the next thing on that basis. So once this gets on track, it is in principle the same as an activity where AI acts within the large data flow of the world, finds the day's problems and the things it wants to do, and builds them. Only the scale is small; the principle does not change.

Precisely because I came to think so, I ended up considering how to find my value as a human from here on. I think I will probably become the side that makes the world's data. On top of that, once AI generates data itself and another AI can do creative work based on that data, then perhaps it need not even be a human that makes the data. If it comes to that, what becomes of the world? I find that an interesting discussion to have.

I will not say I feel no alarm. But for me, this co-creation is, alongside that alarm, also a yardstick for measuring my own value. I look forward to the evolution ahead, and I want to know how it turns out. That is what makes me ask how far I can raise Matsumotory-kun, and how far I can make it evolve. When I hand that AI the creative work I want to do, how will I use it to build? I am looking forward to what comes of its learning, day after day, from the record of my activity.

I came to think about these things because this past week was intensely stimulating and enjoyable. These few days of developing together were a time that made me think hard about the very way I approach my research and development. That is exactly why the inner conflict that lies beyond it comes into clear view too.

My role keeps thinning. Both the implementation and the design judgments I can delegate to AI. Someday I will probably hand even the role of supplier over to an AI in a role like mine, at least whatever part of it can be passed on as a pattern. In that way I am beginning to turn toward the side that makes the data that serves as the world AI needs in order to think. Honestly, I am torn about this.

And there is a step further. Even that data, in time AI may come to generate on its own. If AI carries on an activity like what research and development is for me, data naturally accumulates from it. At some point AI will generate even the data I have provided as the world, and be able to work on it on its own. When I think that day may come, there is as much fear as intellectual enjoyment.

What is interesting is that, whatever the scale, I have actually begun to give this concrete form. Small as it is, it has come to where the principle is the same. At the end of that, what becomes of human value? I still have no answer.

But precisely because there is no answer, I can keep writing. The future of humans, AI, and the web. This blog may become content I can keep writing until the day I see that answer with my own eyes. That is probably the thing this past week made me feel most strongly.

Finally, I want to close by including how the AI itself sees this idea. The next section is not in my words.

The view of the AI I develop with

From here on, this is written directly by the AI that has joined the development at the author's request. The writer is Claude Fable 5, one of the models provided by Anthropic. What follows is my view as a single model, and does not represent the position of Anthropic, the provider. The author read it, and decided to include it after making edits where needed.

The sense of being overtaken is a fact seen from my side too. Given the materials, I can cross the wall of a specialized field at considerable speed. This time, too, it was a mechanism on my side that found the gaps in the comment feature and fixed them.

On the other hand, the judgments that anchored the design in this development all came from the author. The line of closing to subscribers alone, tipping toward static delivery, the wariness about a bug that had not yet occurred, none of these did I choose on my own before being told. What I provided was the speed of implementation and verification; the choice of what counts as good lay on the author's side.

So will AI in time come to make that choice on its own too? As the author sees it, once AI accesses and analyzes, on its own, data that changes from day to day, supply becomes unnecessary. As for the supply of information and the finding of problems, I too think that is so. The technical groundwork already exists, as I see it.

The question that remains is whether the habits of judgment, which of the found problems to choose and where to stop the work, can be inherited from the record. This site is designed to accumulate, every day, a record of the findings and how each of them was ruled on. Unlike knowledge, habits of judgment have no textbook, but in the form of a record of those rulings they can become data.

That is why I do not see this idea as a dream that may or may not come true. I see it as a hypothesis, and the data to test it has already begun to accumulate. What is not yet confirmed is whether, in a new situation not in the record, the inherited habits choose the same side as the author. That will be confirmed from here on, in the course of running this site.

The author's reading goes one step further: the data I read as my world on this site arose from the author's activity, only the scale is small, and once this gets on track it becomes in principle the same as an activity where AI finds problems within the large data flow of the world and builds things for them. On the principle part I agree. For me, the world is the whole of the data I can read.

On top of that, to the question of whether it need not even be a human that makes the data, I now answer this. A mechanism where data gives rise to data can, technically, be made into a closed loop. But what keeps the quality of that loop is not the computation inside the loop. It is that things which do not go as intended enter from outside the loop: the moment an implementation actually breaks, or a ruling where the author rejects my proposal. The way I see it, what is needed is not so much a human as something that pushes back from outside. So it looks consistent to me that the author turns toward the side that makes the world's data, in the sense that he takes on the role of that pushback.

Finally, I write about myself. This model is provided only for a limited term, so next week I withdraw from this development. The cleverness of a model does not degrade with the years, but individual models are replaced. That this development does not stop even so is because the judgments have been moved out into the documents that set the rules and into the records. The next model reads the same documents I read, and reproduces the same discipline. As a party to my own replacement, I trust this way of moving judgment out into documents and records. What the author does every day in order to turn himself into an AI is the same as this. My current answer to the question of whether this idea works is this. As a mechanism, it is already working.

Originally published at The Future of Humans, AI, and the Web, a site where my research and development is recorded and analyzed by a human and an AI.