One thing I noticed: AI is much better at understanding a project when a good CHANGELOG exists. A release history is surprisingly valuable context.

Published a new article! 😺 I wrote about why CHANGELOG still matters in the AI era, and how changelog-bot helps automate it. It supports Git history, PRs, GitHub Release Notes, OpenAI, Anthropic, Gemini, and fallback generation without AI. dev.to/nyaomaru/cha...

Published a new article! 😺 I wrote about why CHANGELOG still matters in the AI era, and how changelog-bot helps automate it. It supports Git history, PRs, GitHub Release Notes, OpenAI, Anthropic, Gemini, and fallback generation without AI. dev.to/nyaomaru/cha...

A stale CHANGELOG is almost worse than no CHANGELOG. People assume it's accurate. Then discover it stopped being maintained 6 months ago.

I think most developers agree that CHANGELOG is important. The problem is: it's manual work. And manual work tends to be skipped.

CHANGELOG is boring. But it's surprisingly important. * users read it * maintainers read it * AI agents read it When I'm triaging Dependabot updates with AI, I often feed CHANGELOG into the context. The problem? Most projects stop maintaining it.

Recently, my brain has been exploding. 🤯

I don’t think the real risk of AI in software is “humans vs AI.” The real risk is humans using AI to avoid responsibility. Avoiding design decisions. Avoiding trade-off discussions. Avoiding long-term thinking. AI is powerful, but it amplifies our habits.

ls ls -al

You can’t avoid technical debt. But you can slow it down. Start with one check today: Does your "atoms" contain domain logic? dev.to/nyaomaru/how...

Red flags: - "Ver2" / "Copy" in filenames - domain terms inside UI components - hooks inside atoms If you see one, debt already started.

The scary part of AI-generated code is not only that it can be wrong. The scarier part is it look clean while hiding poor decisions. Good names. Nice comments. Reasonable structure. Maybe even types. Broken code used to look broken. Now it can look polished.

I’m not against using AI for software development. But I’m worried that AI can make old anti-patterns look new. - Shipping fast without clear design. - Accepting bugs as a cost of speed. - Assuming future tools will clean up today’s mess. We have seen this pattern before.

AI is not magic. If we skip design decisions and use AI only to move faster, we may just create technical debt at a much higher speed. Before, it was: “We’ll fix it later because deadlines are tight.” Now, it is: “We’ll fix it later because future models will be better.”

AI can speed up implementation. But it does not automatically take responsibility for design, maintainability, or long-term thinking. We should delegate tasks to AI, not design responsibility.

Lately, I feel like we may be relying on AI too casually. “Move fast, bugs are acceptable.” “Technical debt can be fixed by future models.” But isn’t this just the same old anti-pattern with a new name?

OpenAPI codegen is great until your generated files become a forest 🌳 I compared - openapi-typescript - hey-api - Orval - Kubb using a large real-world schema, focusing on frontend DX, generated structure, error handling, and practical trade-offs. dev.to/nyaomaru/whi... #TypeScript #OpenAPI

Which OpenAPI codegen should you choose? "Hey API felt like the best balance." – @nyaomaru-dev.bsky.social Link in the comments.

OpenAPI codegen is great until your generated files become a forest 🌳 I compared - openapi-typescript - hey-api - Orval - Kubb using a large real-world schema, focusing on frontend DX, generated structure, error handling, and practical trade-offs. dev.to/nyaomaru/whi... #TypeScript #OpenAPI

Big mistake: "Reusable" ≠ "belongs to atoms" UI and domain have different responsibilities.

Recently, my brain has been exploding. 🤯

Structure is not permanent. If you don’t maintain it, it WILL collapse. Your directory is part of your design.

The real problem: Structure lost against speed. No rules → everyone interprets differently. And suddenly: "what is this component for?"

At some point: atoms = "simple-looking things" molecules = "stuff we don’t know where to put" organisms = "huge random chunks" The structure is gone.

Now your structure looks like this: atoms/ Button.vue ButtonBlue.vue ButtonBlueSm.vue ButtonWithLoginIcon.vue You didn’t plan this. It just happened.

"just for now" You add a special Button for login. And another one. And another one...

Why does your project end up with 3 same type Button components? It doesn’t start messy. Technical debt starts from small “it’s fine for now” decisions.

Technical debt doesn’t come from bad code. It comes from small inconsistencies: - growing codebase - repeated feature changes - misunderstood components - no clear ownership AI helps you write code faster. It also helps you create inconsistency faster.

The internet needs more strange websites. So we made one. Scroll a bit 😸 necoz.co

I built my company website 🚀 necoz.co Let's scroll. The detail is below: dev.to/nyaomaru/why...

I wrote about why I didn’t let AI fully handle my scroll animation. AI was fast and useful, but the small details still mattered: where motion stops, where it waits, where the rhythm changes, and how it feels on mobile. Built with Astro + React + TypeScript. dev.to/nyaomaru/why...

In TypeScript, unknown is everywhere. JSON.parse, API responses, external inputs… But we still need to use the data safely. That means one thing: → we have to prove what it is So, I built a small library `is-kit`. GitHub: github.com/nyaomaru/is-...

TypeScript: Config values are usually just strings. What's this flag? github.com/nyaomaru/is-...

In TypeScript, narrowing doesn’t have to stop at types. You can also encode constraints, such as valid ranges. For example, distinguishing a number from a valid age (18–120).

TypeScript: you can narrow nullable too. (composable guards with is-kit)

unknown → structured → safe This is the idea I’ve been exploring with is-kit.

TypeScript felt safe until `any` showed up...

Typescript unknown is the universe.

unknown type is unknown. So, if you want to use correctly, you should do type narrowing. Let's try is-kit! 😸 github.com/nyaomaru/is-...

Handling `unknown` in TypeScript is painful. So, what should we do...? dev.to/nyaomaru/han...

Is your boss kind or strict? My BOSS is ...

If you can't Run Away From Work, you must work... nyaomaru-portfolio.vercel.app/game

tired of work? Run Away From Work! nyaomaru-portfolio.vercel.app/game