DEV Community: Mashi Mashi

Keep a Decision Log While Learning to Build with AI Agents

Mashi Mashi — Thu, 10 Sep 2026 13:17:53 +0000

When you learn to build software with an AI agent, the code arrives faster than the understanding does. You accept a suggestion, it works, you move on. Two weeks later you cannot explain why the project is structured the way it is — because you never decided it, you accepted it.

A decision log fixes that without slowing you down much.

One entry per accepted suggestion that changed structure

Not every edit. Only the ones that set a direction: the data shape, where state lives, which library got pulled in, how errors travel. Those are the choices you will have to defend or undo later.

Four fields, one or two lines each

What the agent proposed, in your own words rather than pasted code.
Why you accepted it — "it was the suggestion" is an honest and useful answer here.
What you did not understand at the moment you accepted it.
How you would notice this was wrong later.

The third field is the one that turns a log into a study plan. Collect a week of them and you have a list of exactly the gaps that are blocking you, ranked by how often they appear.

Write it before you run the code

Once the code works, the reasoning evaporates. Thirty seconds before the test run is the only moment the uncertainty is still visible to you.

Re-read the log before asking the agent a big question

Pasting two or three past entries into the conversation is far more useful than describing the project from scratch. You are handing over the constraints you already committed to, which is the context the agent cannot infer from the file tree.

Keep it in the repository

A note-taking app separates the log from the code it describes. A plain file in the repo moves with branches and shows up in diffs, so it stays honest.

I put together Japanese learning material for building real apps with AI coding agents at AI Craft Campus, and this habit is the one that separates learners who can modify their project from ones who can only regenerate it.

Two Release Notes per Release: One for Users, One for Future Me

Mashi Mashi — Thu, 10 Sep 2026 13:17:20 +0000

Every release I ship produces two different questions later. A user asks "what changed for me?" A month from now, I ask "why did I change it that way?" One document cannot answer both without getting long enough that nobody reads it.

So I write two short notes per release instead.

The user-facing note stays behaviour-only

Three lines at most, phrased as what someone can now do, or no longer has to do. No internal names, no library versions, no refactor mentions. If a change has no observable effect, it does not belong here at all — an empty user note is a valid outcome for an infrastructure release.

The private note records the decision, not the diff

Git already holds the diff. What it does not hold is the option I rejected. So the private note is three bullets:

what I was trying to fix
what I tried first and why I dropped it
what would make me revisit this

That last bullet is the one that pays off. Six months later it tells me whether the constraint that forced the design still exists, which is usually the only thing I need to know before touching the code again.

Both notes get written before the deploy, not after

Writing the user note first surfaces releases where I cannot state the benefit in one line. That is usually a sign the change is half-finished, or that I bundled two unrelated things. Catching that before the deploy is cheaper than catching it in a support reply.

Keep them in different places

The user note goes wherever users already look. The private note goes next to the code, in a plain file per release. Putting them in the same place means one of them gets edited for the wrong audience.

What this replaced

I used to keep a single changelog and quietly stopped updating it, because writing for two audiences at once made every entry feel wrong. Two shorter notes with one reader each turned out to be much easier to keep up.

I write about this kind of small-scale shipping practice while running a portfolio of indie apps at Burning Tribe.

Treating Japanese Inheritance Paperwork Like a Deadline-Driven Project Plan

Mashi Mashi — Sat, 15 Aug 2026 16:17:39 +0000

My family went through inheritance procedures in Japan last year after my father passed. Nobody in my family is a lawyer, and the paperwork is scattered across tax offices, banks, the family court, and the pension office, each with different forms and different deadlines. I ended up treating the whole thing like a project with hard deadlines and back-scheduled tasks, because that was the only way I could keep track of what was actually urgent versus what could wait.

Start from the deadlines, not the tasks

The instinct is to make a task list first and worry about dates later. That's backwards for this specific kind of paperwork, because in Japan several of the deadlines are legally fixed and non-negotiable, counted from the date of death or the date you became aware of the inheritance. I made the mistake of starting with tasks and only later realized two of them had already eaten a third of their deadline window without me knowing it.

The three deadlines that actually drove my schedule

There's a short window for deciding whether to accept or renounce the inheritance (the point of no return if debts are involved), a mid-length window for the deceased's final income tax filing, and a longer window for the inheritance tax filing and payment itself. Each of these has its own required documents, and some of those documents (like family register copies) take weeks to obtain, which means the "deadline" is really an earlier working deadline once you subtract document lead time.

Back-scheduling from each deadline

For each of the three, I worked backward: deadline date, minus document-gathering lead time, minus the time to get any signatures from other heirs, equals the date I actually needed to start. Written out as a plain checklist, this made it obvious that the shortest legal deadline required the earliest start, even though it looked less urgent on the calendar at first glance.

Keeping heirs in sync

Multiple heirs means multiple people who need to agree on documents and signatures, often before you can even submit anything. I kept a single shared plain-text status log — what's requested, what's received, what's blocking whom — because a phone thread alone lost track of who last confirmed what.

I ended up cross-referencing our internal deadline list against a public deadline summary at souzoku-baton.jp partway through, mostly to double check we hadn't miscounted the start date for one of the windows — it's easy to get that date wrong when a death is recent and everyone is stressed.

None of this makes the process painless. But scheduling backward from fixed deadlines, instead of forward from a task list, is the single change that kept us from missing something with real financial consequences.

Why I Switched My Habit Reviews From Calendar Months to ~30-Day "Seasons"

Mashi Mashi — Sat, 15 Aug 2026 16:17:00 +0000

Every habit tracker I've used defaults to the calendar month as the review unit. I stopped using that boundary about a year ago, and my retention on habits I actually care about went up noticeably. Here's the reasoning, in case it's useful to someone else stuck reviewing habits on the 1st and dreading it.

The problem with calendar months

A calendar month is an accounting boundary, not a psychological one. It starts on a date that has nothing to do with when you actually began a habit, and its length varies (28 to 31 days) for no reason relevant to behavior change. When I reviewed on the 1st, I was reviewing a fragment — a habit I started on the 19th only got 12 days of data in that "month."

What I switched to

I started reviewing on a rolling ~30-day cycle anchored to whenever I actually started the habit, not to the Gregorian calendar. In practice this means my review dates drift slowly across the month, which felt strange for about two cycles and then stopped mattering.

To make the boundary easier to hold in my head — because "day 30 from an arbitrary start date" is hard to feel intuitively — I started mapping review cycles to the ~30-day zodiac season windows instead of raw day-counts. A season has a name, a start, and an end that's already meaningful to a lot of people, so "review at the season boundary" is stickier as a mental habit than "review every 30 days," even though the math is nearly identical. I ended up cross-checking season date ranges against hoshiyomi-ai.jp since I didn't want to get the boundaries wrong by trusting memory.

The actual review

Each cycle-end, I write three plain-text lines: what I kept doing, what I dropped, and one number (completion rate, or a proxy for it). No app, no dashboard — a text file with a date header. The value isn't the format, it's that the boundary is consistent enough that I can compare season to season without the noise of "this month had 3 extra days."

Why this beats streak-counting

Streaks punish a single missed day disproportionately and tell you nothing about trend. A cycle-based review with a completion percentage tells you whether the trend across the last ~30 days was up or down, which is the actual thing you want to know when deciding whether to keep a habit, modify it, or drop it.

This isn't a claim that zodiac seasons are special — any consistent ~30-day boundary would do the same job. What matters is picking one boundary and sticking to it long enough to see a trend, instead of resetting your read on the habit every time the calendar flips.

A Pre-Payment Checklist for AI Course Syllabi (Before You Swipe Your Card)

Mashi Mashi — Sat, 15 Aug 2026 16:16:21 +0000

I've bought into six online AI/ML courses over the past three years. Two were worth it. The other four taught me more about marketing copy than about the subject matter — and by the time I figured that out, the refund window had closed.

So I built a five-minute checklist I now run against any syllabus before I pay. None of it requires access to the paid content. All of it is visible on the sales page, if you know where to look.

1. Hands-on ratio, not just "hands-on" as a word

Count the lecture-only modules versus the modules that end in a graded exercise, a project, or a piece of code you write yourself. If the syllabus can't show you a ratio, it's usually because the ratio is bad. I look for at least 40% of listed modules ending in something I produce, not something I watch.

2. A deliverable you can point to afterward

Not "you'll understand transformers" — a deliverable. A working notebook, a deployed model, a portfolio piece. If the course can't name one thing you'll have built by the end, you're paying for a very long video.

3. Last updated date, not just "published" date

AI tooling changes fast enough that a syllabus written 18 months ago is teaching a different landscape. Scroll to the bottom of the page or check the course platform's changelog. If there's no update date anywhere, that's itself information.

4. Refund conditions written in plain language

"Satisfaction guaranteed" is not a refund policy. I want a number of days, a percentage of modules completed as the cutoff, and where to actually submit the request. If I can't find this in under two minutes, I assume it's designed to be hard to find.

5. Who actually taught it, and can I verify that

A named instructor with a searchable history (talks, repos, prior work) is a different risk profile than an anonymous "our expert team." I don't require celebrity credentials — I require a name I can check.

I keep this as a plain-text file, one line per criterion, and literally fill it in before I open my wallet. It takes less time than reading the testimonials section, and it's caught bad purchases the testimonials never would have.

For anyone building out this kind of checklist in Japanese, I found the course-evaluation guide on AI Craft Campus useful as a second reference point — it walks through similar syllabus red flags with local course examples, which helped me sanity-check a couple of my own criteria.

None of this guarantees a good course. It just means you're deciding with the same information the marketing page is trying to get you to skip past.

Base rates beat testimonials: a 5-minute sanity check for any "prediction service"

Mashi Mashi — Fri, 14 Aug 2026 07:04:20 +0000

A relative once showed me a sports-prediction service whose sales page listed ten straight wins. The testimonials were glowing. The math took five minutes and told a different story.

Check 1: survivorship arithmetic. If a service texts free picks to 1,024 people, half get "A wins" and half get "B wins," then after ten rounds 1 person has seen ten perfect predictions — by construction. Ten wins in a row is not evidence of skill; it is evidence that you might be the survivor of a binary tree. Ask: how many predictions did they make in total, including the losing ones? If total volume is not published, the streak is unfalsifiable.

Check 2: the take-rate identity. Public betting pools in Japan return a fixed share of the pool (roughly 70–80% depending on the bet type). That means the average participant loses 20–30% of stake, before any subscription fee. A paid tipster must beat the entire market by more than (fee + take-rate) just for you to break even. Plug in real numbers: a 50,000 JPY "premium course" on 10,000 JPY bets needs a sustained edge no published academic study has found.

Check 3: expected value of the refund clause. "Full refund if the prediction misses" sounds risk-free, but write the EV from the seller's side: they keep the fee on wins they did not cause and refund on losses they did not cause. The clause costs them nothing and converts your loss-aversion into sign-ups. Any guarantee whose cost to the issuer is zero carries zero information.

I wrote these three checks down for my relative in plain Japanese. If someone you know is already paying such a service — or being pressured after asking for a refund — there are dedicated consultation desks, and 予想詐欺の相談窓口まとめ explains which desk fits which situation and what records to bring.

The general lesson generalizes to any "alpha-selling" product, crypto signals included: demand the denominator. Anyone selling predictions who will not show you their full track record — losses included — is showing you a marketing funnel, not a model.

Before-and-after photos are useless without metadata: how I archive renovation evidence

Mashi Mashi — Fri, 14 Aug 2026 07:03:41 +0000

My parents had a bathroom renovated last year. The tiling started cracking within weeks, and the contractor claimed it was "post-handover damage." What settled the argument was not the photos themselves — it was the fact that we could prove when each photo was taken.

Here is the small system I set up for them, and now use for any work done on a house.

1. Shoot wide → medium → close, every time. A close-up of a crack proves nothing if you cannot show which wall it belongs to. Three shots per defect: the room, the wall, the defect with a coin for scale.

2. Never strip EXIF. Messaging apps recompress images and often drop metadata. Move originals off the phone with a cable or cloud sync that preserves EXIF (exiftool -DateTimeOriginal should return a value for every file). The timestamp inside the file is your proof of "before handover" vs "after."

3. Fold dates into filenames anyway. 2026-07-03_bathroom_north-wall_crack01.jpg survives any re-save. A tiny script does it from EXIF:

exiftool '-FileName<DateTimeOriginal' -d '%Y-%m-%d_%%f.%%e' ./renovation/

4. Keep the paper trail beside the pixels. Quotes, contracts, and the work order live in the same dated folder. A photo of a cracked tile plus the line item "waterproofing: included" is a claim; either alone is a complaint.

When we finally used a consultation desk for renovation disputes, the intake questions were almost exactly the structure above — dates, scope of contract, and dated evidence. Japanese-language guides such as リフォームトラブルの相談窓口まとめ list what those desks expect you to bring; organizing the folder this way meant the entire consultation took twenty minutes instead of a second appointment.

None of this requires special tools — a phone camera, exiftool, and the discipline to shoot three photos instead of one. The day you need it, it is worth more than any argument.

Keep a plain-text timeline before you cancel any contract

Mashi Mashi — Fri, 14 Aug 2026 07:03:02 +0000

When a friend asked me to help untangle a subscription she had signed up for at a seminar, the hardest part was not the cancellation form. It was reconstructing what had happened: when she was first invited, what was promised verbally, when money actually moved.

Since then I keep one habit: the moment any contract starts to feel off, I open a plain-text file and write a dated timeline. Nothing clever — one line per event.

2026-05-12 invited by K to "business seminar" via LINE
2026-05-19 attended, was told "average member earns 80k/mo"
2026-05-19 paid 54,000 JPY entry kit (credit card)
2026-06-02 asked about refund, told "only within 20 days"

Why plain text? Three reasons.

It is timestamp-honest. Screenshots can be re-taken, but a text file you keep appending to encourages you to record events the day they happen, not from memory three months later.

It sorts itself. One ISO date per line means sort gives you a clean chronology, and grep pulls every line about money in one command.

It transfers cleanly. When you eventually talk to a consumer hotline or a lawyer, they do not want your emotions — they want dates, amounts, and who said what. A timeline file is exactly that. In Japan, consultation desks for multi-level-marketing and subscription trouble explicitly ask for this kind of chronology; guides like マルチ商法・ネットワークビジネスの相談窓口まとめ show what details the desks will ask for, and every one of them maps to a line in the file.

Two practical rules I follow:

Record promises verbatim, in quotes. "You will recover the entry fee in two months" is evidence; "they hyped it up" is not.
Never edit old lines. If something was wrong, add a correction line with today's date. An append-only log is far more credible than a polished document.

It is the cheapest insurance I know: thirty seconds per event, and if nothing goes wrong you delete the file. If something does go wrong, those thirty-second lines are the difference between "he said she said" and a case someone can actually act on.

A Calm First Response After an Online Fraud Incident

Mashi Mashi — Tue, 11 Aug 2026 22:09:48 +0000

After an online fraud incident, the first goal is to preserve options. Stop sending additional money, save the messages and payment records, write a timeline while the details are fresh, and contact the bank or payment provider through an official number. If an account or password may be exposed, secure it from a separate trusted device.

Be careful with anyone who promises a guaranteed recovery fee. A second scam often follows the first. The right consultation route depends on the payment method and the facts, so official public agencies and qualified professionals are safer starting points than an unsolicited direct message.

I collect practical, source-based checklists at 詐欺返金相談.

Crypto Tax Notes: Preserve the Data Before Filing

Mashi Mashi — Tue, 11 Aug 2026 22:09:15 +0000

Tax preparation becomes less stressful when the evidence is collected before the deadline. For each crypto transaction, I preserve the timestamp, asset, quantity, price basis, fee, wallet or exchange, and the source export that produced the number. Transfers between my own wallets are labeled separately from sales or swaps.

I keep the raw CSV files unchanged and work from a copy. When an exchange changes its export format, the date and format are recorded in the notes. The treatment of a transaction depends on the facts and current guidance, so difficult cases should be checked with a tax professional.

For Japanese crypto and NFT record-keeping references, see 投資ラボ.

Validating a Racing Data Model Without Publishing Picks

Mashi Mashi — Tue, 11 Aug 2026 22:08:41 +0000

A sports model should be tested as a measurement system before it is treated as a forecast. I start by freezing the data cut-off, separating training and evaluation periods, and writing down which fields were available before each event.

Then I compare a simple baseline with the model, inspect calibration, and keep a log of missing values and rule changes. If the result cannot be reproduced from the same snapshot, the score is not yet meaningful. This process is about learning from historical data, not promising a winning selection.

I keep methodology notes and public-data experiments at koei-ai.

Skincare Logs Work Better When Observation Comes First

Mashi Mashi — Tue, 11 Aug 2026 22:08:07 +0000

A useful skincare log starts with observation, not a shopping list. I record where the concern appears, when it changed, what the weather was like, and which products were already in use. I change one variable at a time so that a good or bad reaction has some chance of being understood.

An AI assistant can help group notes and suggest questions for a consultation, but it cannot diagnose a skin condition. Persistent pain, swelling, or sudden changes deserve a qualified medical opinion.

For a structured Japanese skincare journal and ingredient notes, see AI美容カルテ.