When I started this blog, I left a lot of things unfinished.
Not because I did not care.
Because the goal was not to build the perfect website.
The goal was to create a place where I could write field notes.
That distinction mattered.
In the first post, Where the Real Impact Is (and Where It Isn’t), I wrote about the decision to stop polishing everything around the blog and move forward with something that was good enough. Fonts, colors, templates, UI details, structure, and small design decisions were all important eventually, but none of them were the reason the blog existed.
The real impact was having a place where writing could happen.
That decision was correct.
But it also left a trail.
The work around the work
After the blog was live, the unfinished details did not disappear.
They became the work around the work.
Small visual inconsistencies.
Templates that felt borrowed.
Repeated i18n code.
Open Graph images that were too manual.
A language switcher that could be clearer.
Spacing that felt almost right, but not quite.
Little pieces of technical debt that were easy to ignore because the main goal had already been achieved.
None of those things blocked writing.
But they still shaped the experience.
They affected how the site felt, how maintainable it was, and how much friction appeared every time I wanted to change something.
That kind of debt is easy to postpone because it rarely looks urgent.
It does not break production.
It does not page anyone.
It simply waits.
And every time you come back to the project, it quietly reminds you that the system is not as easy to work with as it could be.
Waiting for the right tool
Sometimes we leave things unfinished because we are lazy.
But often, we leave them unfinished because we do not yet have the right tool, the right context, or the right amount of energy for the problem.
That was true here.
A lot of the remaining work was frontend work.
I can work on frontend, but it is not my strongest area. I know when a layout feels off. I know when the spacing is strange. I know when a UI is harder to use than it should be.
But translating that feeling into a consistent design system, responsive behavior, better templates, and cleaner structure takes a different kind of attention.
That is where AI helped.
Not as a replacement.
As leverage.
It helped me move through the parts of the work where I had enough expertise to evaluate the result, but not always enough fluency to get there quickly.
That distinction matters.
AI did not decide what the blog should be.
It did not know what felt right for the site.
It did not know which trade-offs mattered.
It helped execute, compare, refine, and connect pieces faster once the direction became clear.
AI still needs ownership
There is a shallow version of the AI conversation that says technical people will simply be replaced.
I do not find that very useful.
The more interesting question is:
What kind of work becomes easier when we learn how to use AI properly?
I am thinking about that question in the context of engineering work.
Not isolated tasks with no consequences.
The kind of work where we build and operate services, connect systems, carry production responsibilities, make trade-offs across teams, and keep changing things that other people or systems depend on.
That context matters because good engineering is rarely just about producing code.
For me, this was a good example.
AI helped clean up duplicated i18n pages.
It helped improve the look and feel.
It helped generate Open Graph templates.
It helped make sharing links clearer.
It helped turn messy TODOs into smaller, reviewable changes.
But the work still required judgment.
The prompts mattered.
The questions mattered.
The ability to look at an output and say “this is close, but not quite” mattered.
The ability to notice when the solution was too complex also mattered.
AI can produce a lot of code very quickly.
That is useful only if someone is still responsible for the direction.
Without ownership, speed just creates more things to clean up later.
There is also a smaller, more practical version of that risk.
Some of the frontend pieces I changed now work better than before, but I cannot honestly say I understand every detail of how each one works from memory.
That is not a failure.
But it is a signal.
AI-assisted work needs to stay local enough that I can keep up with it.
“Improve this component.”
“Clean up this duplicated route.”
“Make this spacing consistent.”
“Generate this template from data I already trust.”
Those are good prompts because they keep the work reviewable.
“Refactor the whole site” is a very different kind of request.
It may produce a lot of movement, but movement is not the same as progress if I cannot explain what changed, why it changed, and where I would fix it later.
The step-by-step shape matters.
Each change should be small enough to read, test, adjust, and own before asking for the next one.
The right tool changes the shape of the work
What changed today was not that the TODOs suddenly became important.
They were already important.
What changed was that I finally had the right tool to make them affordable.
That is a familiar pattern in engineering.
Some debt remains because the cost of paying it down is too high compared to the immediate value. Then a better abstraction, a better platform, a better workflow, a better library or a better tool changes the equation.
The work becomes small enough to do.
Not because the problem disappeared.
Because the path through it became clearer.
That is how this blog felt today.
The original goal was still the same: a place to write field notes.
But now the work around that goal is cleaner.
The site is easier to maintain.
The multilingual structure is less repetitive.
The visual system feels more intentional.
The Open Graph images can be generated instead of hand-crafted.
The details around the writing support the writing better than before.
That is worth doing.
Not before the first post.
But eventually.
A tool is not a strategy
The lesson is not “use AI for everything.”
The lesson is closer to this:
The right tool can unlock work, but it still needs the right questions.
Tools do not remove judgment.
They move judgment to a different place.
Instead of asking “Can I build this from scratch?”, the question becomes:
What am I trying to solve?
What should stay simple?
What is worth automating?
What should be generated?
What should remain handwritten?
What does good enough look like now?
Those questions still belong to the person doing the work.
And maybe that is the healthiest way to think about AI in technical work.
Not as magic.
Not as a threat.
As another tool that changes what becomes possible when used with enough care.
Today, it helped me pay down the debt around the place where I write.
Tomorrow, the point of this blog is still the same:
Keep writing.
Edit:
After all the improvement work, I published this new post.
It worked locally, but it did not appear in production.
The issue was the date field in the post metadata. Locally, the post was already visible. But once the site was built using UTC instead of JST, that same date pushed the post into the future.
That kind of bug is a good reminder: improving a system with AI does not remove the need to understand the system.