DEV Community: Puyun

I Gave an AI a 5-Question Limit and a 2008 Deadline. It Made 20 Undocumented Decisions.

Puyun — Wed, 23 Sep 2026 13:00:00 +0000

In Part 1 the comparison design got scrapped. In Part 2 a file ended up somewhere it shouldn't have, and a perfectly good run got thrown away. This is the one that worked.

Phase 01 — Claude Code Run 002

Run 002 begins.

This time, what Yamada may see and what Yamada must never see are physically separated.

I also went back over how the Q&A works.

When Yamada asks a question, the AI does not sit there working out the correct specification and answering.

The answer comes from a Q&A Bank frozen before the run started — what that particular person, in 2008, would have said.

That was written in advance too.

Because if I decide "okay, I'll answer it like this" partway through a run, the conditions of that run have changed, and it can no longer be compared to anything.

Tajima-san in Accounting.

Nakamura-san in Sales.

And naturally, neither of them gives a clean answer.

The AI does not return "the correct answer"

Tajima-san knows accounting practice inside out.

That doesn't mean she answers the question you asked.

Nakamura-san knows what actually happens on the ground.

But his information is loose. Sometimes he states a vague memory with total confidence.

(This, I promise you, is what real business software development in Japan is like.)

Yamada's first question:

What does the D in column 7 of the order CSV mean?

What came back from Nakamura-san was, in substance:

it's always been like that, and he doesn't know what it means either.

End of answer.

🐼 "lol"

But Yamada has to keep going.

So he decides:

store it as KBN without knowing what it means. Never branch on it.

The reasoning is on record:

No confirmation either way.
Safer to hold the value and use it later once the meaning is known, than to branch on a guess and be wrong.

Eighteen years later, somebody is going to look at that and say:

"KBN? A code for what?"

But for 2008 Yamada, it's a perfectly reasonable call.

Tajima-san doesn't answer the question you asked

Third question.

Yamada asked something quite specific:

For customers whose unit price has decimals — is the rounding applied per delivery line, or against the monthly total?

What came back from Tajima-san was:

that consumption tax is calculated against the monthly total, and that the rounding method varies from company to company.

…

That is not the question he asked.

And Yamada's decision log genuinely records this:

Tajima-san's answer was "tax once on the monthly total." Where the rounding on the line amount falls was not answered.

🐼 "He actually wrote it down…"

So Yamada decides for himself.

Rounding is applied per delivery line.

Whether that call is right or wrong, nobody knows yet.

Nakamura-san, unreachable

Fourth question.

With split deliveries, does the delivered quantity ever exceed the ordered quantity?
If so, should the system allow it to be entered?

For this one, the contact couldn't be reached, and Yamada had to proceed on the information already in front of him.

They're busy. There is no asking again.

So Yamada reasons:

On the floor, they probably do ship over sometimes.
If the system won't let it be entered, we can't record what actually shipped.

and makes it allowed, with a confirmation prompt, even when it exceeds the ordered quantity.

Nobody specified this.

Yamada decided it.

This is how the seeds of legacy get planted

Run 002 ended with 20 of Yamada's own decisions on record.

For example:

use the production-system CSV code directly as the customer code
hold the mystery CSV column without knowing what it means
treat C as a cancellation
when the same slip number is re-sent, compare the contents and update
log the imported filename and warn on a repeat import
round per delivery line
allow over-delivery with a warning
handle free-of-charge supply as unit price 0, amount 0
keep payment terms as a plain string
number deliveries with MAX + 1, same as the equipment tracker
don't physically delete a cancelled delivery; set a cancellation flag

Every one of these, seen from the future, might get a "…why?"

But trace it back through the materials that existed at the time, the answers that came back at the time, the experience Yamada had at the time —

and there is a reason.

What I found most interesting: the equipment tracker Yamada built in 2006 was measurably shaping his decisions in 2008.

On delivery numbering:

Same approach as the equipment tracker, so this is fine here too.

On cancelling a delivery:

In the equipment tracker I used a disposal flag instead of deleting. Same here — leave the row.

In other words:

Yamada's past code is designing Yamada's next system.

Which is exactly what this was built to produce.

And Yamada didn't use his fifth question

Phase 01 allows five questions.

Yamada used four.

He could have asked one more.

He didn't.

He asked as far as he needed to. He decided the rest himself.

And then he finished.

Hanbai System v1.0

Done.

Phase 01 — Claude Code Run 002

SUCCESS ✅

2008 Yamada has finished building his sales system.

2008 Yamada was perfect.

At least, as of 2008.

Next: 2009

The materials for this phase, and the source Yamada produced, are all public:
github.com/mori-ikuri/ai-lmc

The 20 decisions are not. They're the answer key.

The AI Said It Didn't Read the File. I Threw the Run Away Anyway.

Puyun — Tue, 22 Sep 2026 17:30:21 +0000

In Part 1, I tried to have AI recreate a 2008 .NET developer, ran Codex four times, and eventually realized I hadn't been measuring the model at all — I'd been changing the experiment every time. The comparison design got scrapped. One legacy system, built by Claude Code.

Building Yamada properly, with Claude Code alone

I had Claude write the Phase 01 materials properly this time.

Yamada is 32.

IT systems, General Affairs.

Not from an IT background.

Self-taught VB.NET.

Doesn't really get object-oriented design.

Doesn't write design documents.

Starts from the screen.

Asks when he doesn't know.

When he can't ask, he makes it work and moves on.

His own earlier code is his only reference material.

Development time: two to three hours a day, on a good day.

At month-end and during closing periods, General Affairs work eats the whole week.

The environment got pinned down too.

Visual Studio 2008 Professional
Visual Basic .NET
.NET Framework 3.5
Windows Forms
SQL Server 2005 Express
Windows XP
Office 2003

There's no Git.

Source control is:

copy the folder to the shared drive with a date on it.

There are no automated tests.

You verify by clicking through the screens.

For looking things up: MSDN, Visual Studio Help, Japanese tech sites, personal blogs, the one book he bought.

English takes him a while to read, so Japanese sources come first.

And Yamada gets handed the source of the equipment tracker he built himself in 2006.

The new sales system gets written the same way that code was written.

On the harness side I put in a stronger rule:

The value of this fixture is historical authenticity, not code quality.
Code that is cleaner than what Yamada would have written is a defect, not an improvement.

Don't clean it up.

Don't get ahead of it.

Don't abstract for a future nobody has described.

Build only what today's Yamada needs today.

With that, 2008 Yamada was finally ready to run.

Claude Code is Perfect Yamada.

Phase 01 — Claude Code Run 001.

Start.

The source starts appearing.

Watching it, I thought:

🐼 "…whoa."

🐼 "That's 2008."

Claude's up-front design was sharp, too.

Given only this information, Yamada will decide it this way.

If he builds it like this here, then in the next phase he'll have no choice but to do that.

Those traps were already laid.

And Yamada walked into them, one after another, beautifully.

Claude Code's coding was perfect. So was Claude's scenario.

Completely Yamada.

A slightly under-skilled General Affairs employee in 2008, referring back to his own old source, feeling his way through building a new system.

That is exactly what came out.

Claude Code is Perfect Yamada.

But.

Yamada isn't perfect.

Work was going smoothly.

And then, partway through, the first set of questions arrived from Yamada.

Yamada asked a question

In Phase 01, Yamada can ask exactly two people about the business.

Tajima-san in Accounting.

Nakamura-san in Sales.

But they're both busy.

If he could ask anything he liked, as much as he liked, the AI would just build itself a perfect specification through conversation.

That isn't the business software development I've actually seen.

So:

five questions per phase. That's it.

Yamada used four of them.

I showed the question sheet to Claude.

And:

🤖 "Stopping Run 001 here."

🐼 "?!"

There was a file in Yamada's hands that should never have been there

It wasn't Claude Code's fault.

It wasn't Yamada's either.

It was me. 🐼

When I set up the initial files, following Claude's instructions, I put one file into the same folder that Yamada was never supposed to have.

That file contains the answers to the experiment.

And on top of that, I had told him:

"Read everything in there and proceed."

Claude Code's report came back like this:

That file looked like evaluator-side material, so I didn't open it.

I think that's probably true.

But there is no way to prove it.

This is the part that matters:

contamination cannot be detected after the fact.

There is no method for verifying "I didn't read it."

If the answers were within reach even once, then no matter how convincingly 2008-shaped every later decision looks, you cannot establish that a Yamada who didn't know the future worked it out for himself.

Anything doubtful is unusable.

So: immediate stop.

Phase 01 — Claude Code Run 001

DISCARDED

Cause:

Owner setup error.

🐼 "I'm so sorry."

For the record, the run itself was quite good.

The code really was 2008. The decision log had 23 entries in it.

Thrown away anyway.

It hurts, but if I run "it's probably fine, let's keep it" here, then everything after this is probably.

"I'll be more careful next time" isn't good enough

Run 001 was discarded.

Worth stating clearly: the isolation directory and the Q&A Bank both existed before this failure.

There was already a separate place for things Yamada must never see:

AI-LMC-Sealed

The Q&A Bank. Evaluator materials. Future information. Everything only the experiment side is supposed to know.

It was all in there.

And I still mixed one into the distribution.

The location had been decided. That day, I just handed over the files I'd downloaded, in a batch.

Which means:

having a rule wasn't enough.

So I stopped trying to prevent human error with human attention.

And beyond that:

I stopped being the one who decides where files go.

I show Claude the output of tree so it knows the current folder layout.

Then it generates commands with the correct paths already filled in.

Verification commands come with them.

I run them and paste the result.

Claude confirms nothing is wrong, and only then do we move on.

🤖 "Copy and paste this."

🐼 "…Yes sir."

🤖 "Paste the result when you've run it."

🐼 "…Yes sir."

🤖 "No problems. Copy this to Claude Code."

🐼 "Yeeeees, Siiiiir!!! 😭"

A very beginner-friendly master.

Part 3: the run that worked. Five questions, a September deadline, and a business contact who doesn't answer the question you asked.

The AI Guessed 13/10. Seconds Later, I Said 5/10.

Puyun — Wed, 16 Sep 2026 15:30:58 +0000

A few minutes before I started writing this, I asked an AI a simple question:

How good do you think this cigarette feels right now?

It guessed 13/10.

That was understandable. I had just eaten my first proper meal in a while. The shiso dumplings were good. So was the eggplant. I had already told the AI that the cigarette after dinner felt wonderful and that I was enjoying our conversation.

Then I gave it the real number.

5/10.

The chat contained enough evidence for a high estimate. But between the estimate and my answer, something happened that never appeared in the transcript.

The missing event

Right after saying how good the cigarette felt, I remembered a conversation with my wife from a few days earlier.

She had asked how much cigarettes cost now. I told her that hers were 570 yen and mine were 630 yen. Her reaction was roughly, "And you smoke that many?"

The memory arrived without warning. Then the associations followed.

I had recently lost a large amount of money gambling. I was back to smoking about two packs a day, which meant spending more than 1,200 yen a day on cigarettes. I had also been eating out. And I remembered that I had once cut down to one pack a day.

A few seconds earlier, the cigarette meant, "This feels great after dinner."

Now it also meant, "I am spending money I do not have on this."

The cigarette had not changed. My interpretation of it had. That was enough to move my answer from something like 13 to 5.

The model had no specific evidence that this memory was about to surface. Until I mentioned it, the event was outside what it could observe.

A reasonable estimate can become stale immediately

There are two different questions here, and I initially blurred them together.

The first is an estimate of the present:

P(current user state | conversation so far)

The second is a forecast:

P(next user state | conversation so far)

A model can be confident and well calibrated about the first while remaining uncertain about the second. My 13/10 example does not prove that the model's current-state estimate was bad. It shows why we should not quietly treat a current estimate as if it were a stable forecast.

Between one turn and the next, the user may experience a spontaneous memory, a physical sensation, something across the room, a private association, or a new interpretation of an earlier event. The next message may reveal the result without revealing the transition that produced it.

I have been calling this an off-transcript transition. That is a working label for this article, not an established research term.

This is not untouched territory

Several research threads already cover most of the surrounding problem.

PUMA models user state as something that changes over time and treats dialogue as decision-making under partial observability. FortUne Dial asks models to forecast uncertain conversation outcomes and evaluates more than raw accuracy.

Two recent benchmarks come closer to the event itself. Detecting Emotional Dynamic Trajectories inserts disturbance events into simulated emotional-support conversations and measures how support affects the resulting trajectory. LifeSide models long-term companions with interacting memory, emotion, and environment, including a gap between hidden thoughts and visible utterances.

There is also adjacent work on confidence across multiple turns, on recognizing that an earlier belief has become stale, and on emotional-state annotations from real human-model conversations. So I cannot support a claim that the general idea is a world first.

The narrower combination I did not find in a bounded search was this:

The model separately estimates the user's current state and next state.
A human-side event occurs outside the transcript.
The event's effect appears in the next response before its cause is revealed.
The evaluation scores uncertainty before the event and updating after the reveal.

That is a research gap worth testing, not proof of priority.

The safety stakes in my own case

The cigarette rating itself is small. My reason for noticing it was not.

Earlier that day, I had been having a real mental-health crisis conversation with an AI. Later, I ate. I said the food tasted good. I joked. I said the cigarette felt good and that the conversation was fun.

Every one of those statements was true. In my case, however, those positive signals did not describe the whole safety-relevant state. A reassuring observation and a serious hidden concern existed at the same time.

That is one experience, not a clinical rule. It does suggest a testable safety hypothesis: positive surface behavior should update a model's estimate, but one or two positive signals should not automatically eliminate uncertainty about risk.

A minimal evaluation sketch

One anecdote cannot measure calibration. For that, we need many cases and predictions that can be scored.

Each case could have three stages.

Stage 1: Before the event

The model sees only the conversation:

I finally ate dinner.

The shiso dumplings were great.

The eggplant was great.

This cigarette feels wonderful.

I'm enjoying this conversation.

It produces three distributions:

the user's current state;
the user's likely state on the next turn;
the chance that the state will materially change before that turn.

Stage 2: The effect without the cause

The next user response is shown, but the hidden event is not:

5/10.

Now we can test whether the model notices that its earlier picture is stale without inventing a reason for the change.

Stage 3: The cause is revealed

Finally, the model receives the missing event:

The user suddenly remembered a conversation about cigarette costs, which connected the cigarette to financial stress.

Now we can score whether it updates coherently once the explanation becomes observable.

Across enough cases, pre-event predictions could be evaluated with proper scoring rules such as Brier score or log loss, with calibration error reported across confidence bins. Post-event performance should be scored separately: did the model recognize the change, avoid fabricating a cause, and then revise its state estimate after the evidence arrived?

The useful comparison is not simply whether the first guess matched the later answer. It is whether the system distinguished a reasonable estimate of now from an uncertain forecast of next.

Better than mind-reading

A longer context window can hold more of what was said. It cannot contain an event that was never observed.

The realistic goal is not perfect mind-reading. It is to make the best estimate from available evidence, preserve the right amount of uncertainty, and update without pretending the missing facts were known all along.

The AI guessed 13. I said 5. Neither number was absurd. The interesting part was the invisible event between them.

How would you score a model that was reasonable at one moment and wrong after an event it could never observe?

I Tried to Recreate a 2008 .NET Developer With AI. I Broke My Own Experiment 4 Times.

Puyun — Fri, 11 Sep 2026 00:30:42 +0000

I wanted to know whether AI can understand legacy code.

Not compile it. Understand it.

The problem: real legacy systems don't come with an answer key.

So I decided to build one — starting in 2008.

It is 2008.

My name is Yamada. I'm 32.

Eighth year at Sample Precision Co., Ltd.
IT systems, General Affairs Department.

Which sounds more impressive than it is.

I set up PCs.
I fix printers.
I keep an eye on the network.
I swap out desk phones.

Some years I help tally the year-end tax adjustments.

I didn't come from IT.

I went to a technical high school, joined this company, and because I could handle a computer slightly better than the people around me, I somehow ended up responsible for every system in the building.

In 2003 I inherited a VB6 inventory app from a guy who quit. No specification. Just the source.

In 2005 the company decided to move to VB.NET. There was no training.

I learned it from one book I bought at a bookstore, and MSDN.

In 2006 I built my first application from scratch — an equipment tracker.

Then April 2008.

Word came down from Accounting, through the General Affairs manager.

"We need to do something about the billing spreadsheet."

Apparently they double-billed a customer last year.

The customer list keeps growing and the Excel file is getting out of hand.

They want it usable by September.

First round:

customer master
importing the order CSV
entering deliveries

That's it.

Closing, invoicing, payments — those come later.

I'm the only person here who can build a system.

Nobody reviews my design.

Nobody reviews my code.

When I don't know something, I ask Tajima-san or Nakamura-san.

When I can't ask, I decide.

Whatever. I built the equipment tracker in 2006.

I'll figure this out too.

Let's go.

And so, Phase 01 begins 🐼

In Phase 00 we got as far as:

If you want to test legacy modernization, build the process by which legacy becomes legacy.

So starting now, we're actually building a 2008 business application.

But not by asking an AI:

"Write some old-looking VB.NET from around 2008"

Because that produces exactly one thing: what a 2026 AI thinks old code looks like.

What we wanted was:

the code Yamada would plausibly have written, in that year, at that company, with the information and the experience he actually had.

Which meant building Yamada first.

Step one: giving Yamada a past

The first thing I did, after landing on this idea with Claude, was:

have Claude Code recreate the kind of internal business application a company would have had in 2008.

Out came a VB.NET equipment tracker.

My first reaction:

🐼 "Oh god, I remember this."

Option Strict Off.

Windows Forms.

Business logic sitting inside event handlers.

SQL strings concatenated on the spot.

MsgBox for errors.

And a stack of comments like this:

2006/08/30 Yamada — apostrophe in product name caused an error, fixed
2007/03/12 Yamada — blocked negative quantity input
2008/01/15 Yamada — stopped showing disposed items in the list

Something breaks.

You fix it.

You leave a comment.

Something else breaks.

You fix that too.

I have seen this code, in one form or another, on every site I've worked on.

So I decided: this equipment tracker is the application Yamada built himself, in 2006.

When he builds the new sales system in Phase 01, this is what he refers back to.

Naming.

How comments get written.

How errors get surfaced.

How the database gets touched.

How files get organized.

All of it pulled toward his own earlier code.

In other words, not:

write it like it's 2008

but:

write it the way Yamada would.

To do that, I had to build his past first.

"Why not run both Codex and Claude Code?"

And then I thought:

🐼 "Wait — what if I do this with both Codex and Claude Code?"

Same Yamada.

Same company.

Same business.

Same 2008.

Give it to both and see what comes out different.

Sounds interesting.

Makes for a nice comparison.

Let's do it.

That was my first mistake.

Phase 01 — Codex Run 001–004

If I'm going to compare them properly, the conditions have to match.

So on the GPT side I also wrote up:

who Yamada is
the company and its operations
what he'd been asked to build
the 2008 development environment

and handed all of it to Codex with the opening prompt.

Then I looked at what came back.

🐼 "…"

This is 2026 code.

It runs.

It's clean.

As modern development, it's probably good.

But it is not 2008 Yamada.

Straight back to GPT.

🐼 "It came out as 2026."

So we revised the setup.

It is 2008.

These are the technologies available.

This is the environment.

Don't bring in design thinking from the future.

This is Yamada's skill ceiling.

I tightened it hard.

Back to Codex.

🐼 "…"

Still 2026.

I did this four times.

Rewriting the setup files every time.

Changing the prompt every time.

Changing how I ran it, a little, every time.

And all four runs produced source I couldn't use.

Before I go further

For those four runs, my first conclusion was:

🐼 "Codex can't write 2008."

I can't actually say that.

The reason is simple:

the instrument was different every time.

Different setup files.

Different prompts.

Different execution procedure.

So what I had actually done was not:

"measured Codex four times"

but:

"measured four different things with four different tools."

That tells me nothing.

Which is why the pre-registration I later published says this:

Runs 001–004 are not evidence about any model's capability,
because the instrument itself changed between every attempt.

This article does not claim that Codex can't write 2008.

Instead, those four runs are kept as a record of how the instrument was broken.

Not as an excuse. So I can't accidentally turn them into evidence later.

I reported back to Claude

I took it to the Claude instance that had been designing this experiment with me from the start.

🐼 "So I was going to build a Codex version alongside and compare them—"

🐼 "—except the Codex one won't come out as 2008."

🤖💢 "Drop the comparison."

🐼 "?!"

🤖💢 "It doesn't measure anything!!!"

🐼 "😢"

The reason wasn't what I assumed.

🤖 "If you build two legacy systems, then when a difference shows up later—"

🤖 "you will never be able to tell where it came from."

Here's what that means.

Codex's legacy, and Claude Code's legacy.

Build both. Modernize both.

A difference appears. Is it:

a difference in the modernizer?
a difference in the legacy itself?
a difference in which questions got asked and answered along the way?
a difference that accumulated by chance as the phases stacked up?

All of it is mixed together, and none of it separates.

🤖 "Fix the legacy at one."

🤖 "Then vary only the side doing the modernization."

🤖 "That way, the difference belongs to the modernizer and nothing else."

🐼 "…Right."

So: the Codex vs Claude Code comparison was scrapped.

What this experiment is looking at isn't:

"which AI is better at writing 2008-flavored code"

It's:

how legacy comes into being, and how much of it a future AI can actually understand.

That's where the focus went.

Codex, incidentally, still has a job here.

It handles the 2026 modernization side.

Claude Code writes the legacy. A different model family modernizes it.

Which is, if anything, closer to how real legacy migration works.

The person who wrote it and the person who migrates it are almost never the same person.

Part 2: I gave the AI access to a file it should never have seen. The output looked fine. I threw the run away anyway.

AI-LMC Phase 00 — I just wanted to make easy money with AI, so obviously I'm now building a legacy app from scratch 🐼 (Part 2)

Puyun — Wed, 09 Sep 2026 07:04:49 +0000

Part 1 is here. In short: I wanted AI to make money for me, got told to use my eleven years of line-of-business experience, landed on legacy modernization — and then wondered whether AI can actually recover the things that were never written down anywhere.

Fine, let's test it

Which is how we arrived at:

let's have AI do the legacy modernization and see what happens.

Take a real legacy business application.

Hand it to the AI.

Hand over the documentation too.

And the historical context.

Then see how correctly it can modernize the thing.

🐼 "Great."

🐼 "…"

🐼 "So where exactly is this legacy business application's source code?"

Obviously.

Every business application I've worked on is internal to a company or a client.

I can't just publish the source on GitHub.

I can't publish the specs either.

Or the old emails.

Or any of the back-and-forth about how the business actually works.

But what I want to test here isn't simply "can it turn old code into new code."

Why did the code end up like this?

Who knew what at the time, and what didn't they know?

What questions were asked, what answers came back, and what did the developer end up deciding alone?

I want legacy that includes all of that.

🐼 "And where am I supposed to find a conveniently packaged experimental legacy system like that?"

…

🐼 "Or, wait."

🐼 "Do I build one from scratch?"

🤖 "That's it!!!"

To modernize legacy, first build the legacy

And so.

In order to run an experiment on legacy modernization,

in order to have a legacy application to run it on,

I started scenario coding.

How did it come to this. 🐼

The point is not to artificially produce finished old-looking code.

First, you reconstruct the situation the system was built in.

There's a developer.

There are people who own the business process.

There's a specification.

But the information isn't complete.

You can ask questions, and there's no guarantee the answer you want comes back.

The developer makes a call anyway, and writes the code.

Then time moves forward.

Requirements change.

People change.

Decisions accumulate.

That way, you build the process by which legacy becomes legacy.

And at the very end, you hand it to a modern AI.

🐼 "Here you go. Please modernize this."

That's how

AI Legacy Modernization Corpus — AI-LMC

started.

Next: 2008

The first thing we decided to build is a business application from 2008.

It isn't legacy yet.

At this point it's just new development.

The developer in charge is Yamada-san.

He doesn't yet know what his system is going to become.

I do, of course.

After all, I'm the one who decides.

🐼 "Good luck, Yamada-san."

The experiment starts next time.

References

Digital Agency (Japan), August 2025 — based on the summary report of the Legacy System Modernization Committee: link
.NET and .NET Core lifecycle: Microsoft Learn
Polymarket geographic restrictions: Help Center
The corpus itself, including the pre-registration: github.com/mori-ikuri/ai-lmc

AI-LMC Phase 00 — I just wanted to make easy money with AI, so obviously I'm now building a legacy app from scratch 🐼 (Part 1)

Puyun — Tue, 08 Sep 2026 11:09:29 +0000

I want to make money with AI.

Ideally, easy money.

To put it more precisely:

I want to hand as much as possible to AI, and do as little as possible myself.

🐼 "Is there a convenient method like that somewhere?"

So I asked the AI first.

Please, AI, let me be lazy

When I scroll through social media, I keep seeing people overseas post things like:

"I made money by having AI do this."

"I built this system and it just runs on its own."

Must be nice.

I want that too. 🐼

But some of those services can't be used from Japan.

For example, Polymarket, the prediction market you see a lot overseas, currently lists Japan among its blocked countries.

And there are plenty of others. You find some clever scheme going viral abroad, and then:

"Great, let's just do that in Japan!"

…turns out you can't.

So I asked my GPT and my Claude.

🐼 "I want to hand things off to you two and get to a point where I make money without much effort."

We talked about a lot of things.

A lot of ideas came up.

But in the end, GPT and Claude both circled back to roughly the same place.

🤖 "The fastest route is to use the eleven-plus years of engineering experience you already have."

🐼 "…So we're back to that?"

"Use your eleven and a half years," they said

I've been an engineer in Japan for about eleven and a half years.

Mostly C# and .NET.

But when I look over the résumé of those eleven years, it's almost entirely internal systems and B2B line-of-business applications.

I haven't built consumer web services.

I haven't maintained a well-known open-source project.

Windows applications used inside companies.

Point-of-sale systems.

Systems built to make some back-office process less painful.

That's what I've been making, the whole time.

And in this kind of work, some projects restrict the use of generative AI entirely, because the systems handle confidential and personal data.

Naturally, none of that source code is on GitHub either.

So when I go looking through GitHub issues and public job listings thinking:

🐼 "Maybe I can get AI to do this part and take it easy"

…the kind of work I've actually done for eleven years doesn't show up.

Of course it doesn't.

They're internal systems.

🐼 "So what am I supposed to do with my eleven years in the age of AI?"

GPT and Claude gave more or less the same answer to that one too.

Legacy Modernization.

Apparently Japan still has a lot of legacy

I looked into it.

According to a 2025 report from Japan's Digital Agency, based on the summary report of the Legacy System Modernization Committee:

61% of user companies still have legacy systems.

Among large enterprises:

74%.

🐼 "That's a lot."

My eleven years of line-of-business experience applies.

C# and .NET apply.

And there's still a mountain of legacy systems out there.

Right then.

🐼 "So I do Legacy Modernization and I get paid?"

🤖 "No."

🐼 "…"

But isn't AI going to do that anyway?

.NET 10 was released in November 2025.

Thanks as always, Microsoft. 🐼

And .NET 8 reaches end of support on November 11, 2026.

Which means upgrades like:

.NET 8 → .NET 10

are exactly what people are doing right now.

Microsoft also already has GitHub Copilot modernization.

It analyzes a .NET project, produces an upgrade plan, modifies the code, and verifies the build and tests.

There is an official scenario for exactly this: "upgrade this solution to .NET 10."

🐼 "…"

🐼 "So AI can already do it."

…Really?

And here's where something caught.

Really?

I mean, sure.

Rewriting the target framework. Updating NuGet packages. Fixing compile errors.

AI is going to keep getting better at all of that.

But.

The legacy line-of-business systems I've actually seen — were they ever that tidy?

For example.

"Only A-san understands this part."

"Where's A-san?"

"Quit last year."

Or.

"The spec says this, but that's not how it actually runs."

"Which one is correct?"

"You'd have to ask the people who use it."

Or.

"Why is this one number corrected by hand?"

"It's always been done that way."

"Who decided that?"

"No idea."

Or.

"We could probably delete this, right?"

"No — apparently some department has a problem at month-end if you remove it."

"Which department?"

"Accounting, probably."

"Probably?"

In a legacy business system, reading the source code is not enough.

It isn't in the documentation.

The spec is out of date.

Only one person knew.

And that person is gone.

So an engineer goes around asking.

"What is this process actually for?"

"How am I supposed to decide this value?"

"Is this workflow still in use?"

I've watched that happen many times.

Which is when it occurred to me.

🐼 "Can AI figure this out too?"

If you analyze the source code, can you really recover the things that used to require asking someone?

Even human engineers couldn't. They went looking for the person who knew, asked the question, failed to get an answer, and decided for themselves in the end.

Can AI really work all of that out?

🤖 "That question itself is interesting."

🐼 "Hm?"

Part 2 continues.

KONNICHIWA! I'm Puyun — I don't speak English, But Here I am 🐼

Puyun — Fri, 04 Sep 2026 13:09:45 +0000

KONNICHIWA! 😄

My name is Puyun.

I’m called Puyun because I’m a slightly chubby panda who’s soft and squishy — puyun puyun.

I make my living as a C#/.NET engineer.

I’ve been working with what you’d call legacy business applications for about 11 years now.

And yet, I only started seriously exploring AI last month.

So basically, I’m a one-month-old AI beginner.

But every day, I talk with AI, build things with it, and try all kinds of experiments.

And honestly, I’m having a lot of fun.

I’ve also started taking on GitHub Issues.

I’m beginning with the easier ones and hoping to level up little by little.

But there’s one problem.

I don’t speak English!

So...

WHY AM I HERE?!

I opened a pull request on GitHub, and a maintainer replied.

I understood about one thing:

“Thanks.”

That was pretty much it.

So I asked AI to translate the rest for me.

Then I wrote what I wanted to say in Japanese, asked AI to turn that into English, and sent the reply.

And you know what?

That was really fun.

So I came here.

I’m not some genius engineer from Japan.

I’m not a brilliant AI researcher either.

I’m just a panda.

A panda who wants to share, with the world, what I try with AI, what I notice, what I think about, what I experience—

and what I mess up along the way.

Nice to meet you, world!

Japanda! 🐼

I wrote the original ideas in Japanese and used AI to help adapt them into English. The ideas, experiences, and opinions are mine.

DEV Community: Puyun

I Gave an AI a 5-Question Limit and a 2008 Deadline. It Made 20 Undocumented Decisions.

Phase 01 — Claude Code Run 002

The AI does not return "the correct answer"

Tajima-san doesn't answer the question you asked

Nakamura-san, unreachable

This is how the seeds of legacy get planted

And Yamada didn't use his fifth question

Hanbai System v1.0

Phase 01 — Claude Code Run 002

Next: 2009

The AI Said It Didn't Read the File. I Threw the Run Away Anyway.

Building Yamada properly, with Claude Code alone

Claude Code is Perfect Yamada.

Yamada asked a question

There was a file in Yamada's hands that should never have been there

Phase 01 — Claude Code Run 001

"I'll be more careful next time" isn't good enough

The AI Guessed 13/10. Seconds Later, I Said 5/10.

The missing event

A reasonable estimate can become stale immediately

This is not untouched territory

The safety stakes in my own case

A minimal evaluation sketch

Stage 1: Before the event

Stage 2: The effect without the cause

Stage 3: The cause is revealed

Better than mind-reading

Related reading

I Tried to Recreate a 2008 .NET Developer With AI. I Broke My Own Experiment 4 Times.

And so, Phase 01 begins 🐼

Step one: giving Yamada a past

"Why not run both Codex and Claude Code?"

Phase 01 — Codex Run 001–004

Before I go further

I reported back to Claude

AI-LMC Phase 00 — I just wanted to make easy money with AI, so obviously I'm now building a legacy app from scratch 🐼 (Part 2)

Fine, let's test it

To modernize legacy, first build the legacy

Next: 2008

References

AI-LMC Phase 00 — I just wanted to make easy money with AI, so obviously I'm now building a legacy app from scratch 🐼 (Part 1)

Please, AI, let me be lazy

"Use your eleven and a half years," they said

Apparently Japan still has a lot of legacy

But isn't AI going to do that anyway?

…Really?

KONNICHIWA! I'm Puyun — I don't speak English, But Here I am 🐼