DEV Community: Tohru Yaginuma

Using the Grok API to Reduce the Effort of Keeping Up with AI

Tohru Yaginuma — Sat, 19 Sep 2026 02:45:05 +0000

Long Story Short

X is useful for keeping up with AI and tech, but I find browsing the feed mentally exhausting.
I built a simple pipeline with Grok API, Google Apps Script, and Message App that sends me a few selected AI topics every morning.
The most important part was not collecting more information, but defining what information was actually worth sending to me.

Context

I am very sensitive to information, and X is one of the social platforms I struggle with the most.

Reading the feed can leave me surprisingly drained.

In particular, if I accidentally open the "For you" tab and start scrolling through posts from people I do not follow, I sometimes notice that it affects my mood for a while afterward.

At the same time, X is still one of the most useful places for me to keep up with fast-moving information.

This is especially true for AI and software engineering.

New tools, coding-agent workflows, experiments, failures, pricing changes, and practical tips often appear there before they are summarized elsewhere.

So I had a problem:

I wanted information from X, but I did not want to spend time inside X.

I had been thinking for a while about whether I could separate those two things.

Then I learned that Grok could help with exactly that.

It could access information from X, summarize it, filter it, and be called through an API.

That was enough for me to start building something the same day.

What I Built

The pipeline is very simple.

X
↓
Grok API
↓
Google Apps Script
↓
Message App (LINE in my case)
↓
Me

Google Apps Script runs on a schedule every morning.

It calls Grok and asks for a small number of AI-related topics from roughly the previous 24 hours.

The selected topics are then sent to LINE, which is the messaging app I already use every day.

So instead of opening X and searching for useful information, I wake up and find a short list already waiting for me.

Grok is mainly doing two things:

Collecting information from X
Selecting which information is worth showing me

The second part turned out to be much more important than I initially expected.

Why Grok Was a Good Fit

I did not only need search.

I wanted something that could:

access information being discussed on X
summarize what happened
compare multiple topics
filter out things I probably would not care about
run automatically through an API

I wanted to reduce a large stream of information into a very small number of things that were actually relevant to my work.

The First Version Wasn't Very Useful

My first prompt was much simpler.

I basically asked for important AI news.

Technically, it worked.

The problem was that "important AI news" was much broader than what I actually wanted.

I started getting topics that were academically interesting or technologically impressive, but not especially useful for my daily work as a software engineer.

There is a lot happening in AI.

Research papers, benchmarks, model releases, image generation, business news, funding, robotics, policy, and many other areas can all reasonably be called "AI news."

But that was not what I was trying to optimize for.

What I really wanted was something closer to:

What happened in AI recently that might change how a software engineer works?

That distinction changed the prompt significantly.

The Hard Part Was Selection

Over time, I started making the selection criteria much more explicit.

I now prioritize topics around things like:

coding agents
agentic software engineering
developer tools
MCP
CLI and IDE workflows
debugging
testing
code review
CI/CD
model changes that affect software development
practical AI adoption inside engineering teams
real-world experiments from engineers and maintainers

I also started prioritizing posts that contain concrete experience.

For example:

How many tokens did it use?
How long did it take?
How much did it cost?
Did it actually work?
What failed?
How much engineering time did it save?

I find these much more useful than generic announcements because they give me something I can compare with my own work.

One of the questions I now effectively ask the model is:

If a software engineer only had five minutes to catch up on AI today, would this be worth reading?

Another is:

Would this make someone want to reply with their own experience?

Those questions improved the output much more than simply adding more AI-related keywords.

What Changed for Me

The amount of effort required to keep up with AI has gone down quite a bit.

Before, catching up meant opening X, looking through the feed, deciding what was relevant, opening posts, and trying not to get distracted by everything else.

Now the default is much simpler.

I open my messaging app and read a few selected topics.

If something looks genuinely interesting, I can then open the original source.

Of course, directly browsing X would still expose me to more information.

I am probably missing useful posts.

But that is a trade-off I am comfortable with.

The goal of this system is not:

Never miss anything.

It is:

Keep learning about AI consistently without making information gathering exhausting.

For me, that is much more sustainable.

Limitations

This system is not a complete replacement for X.

The model can miss important information.

Its selection is influenced by the prompt.

A topic that would have been useful to me may never be selected.

And because AI is such a broad field, getting the filtering criteria right still requires iteration.

I have already rewritten the prompt several times, and I expect to keep changing it as my interests and work change.

There is also an unavoidable element of randomness in what reaches me each day.

I think that is acceptable.

I would rather receive a small imperfect selection consistently than have access to everything and avoid looking at it altogether.

Conclusion

The technology behind this project is not particularly complicated.

It is mostly an API, a scheduled Google Apps Script, and a messaging app.

But I enjoyed building it because it solved a very specific problem I had in my daily life.

I did not want a better X client.

I wanted to remove the part of X that was difficult for me while keeping the part that was useful.

The result was a small information pipeline tailored to how I actually want to consume information.

It also reminded me of something I like about software engineering:

Not every useful system has to solve a large problem.

Sometimes it is enough to notice a small source of friction in your own life and build something that makes it a little easier.

I Started Using /clear After Testing with Playwright MCP

Tohru Yaginuma — Fri, 11 Sep 2026 23:07:45 +0000

Long Story Short

After using tools like Playwright MCP that can return large tool results, continuing to work with that context still in the session can make subsequent processing heavier.
Since then, when I finish testing with Playwright MCP and do not need that context for the next task, I use /clear.
My rule is simple: “Will I need this context for the next task?”

Context

Recently, I hit the usage credits limit in Claude Code, which I use at work.

What confused me was that my plan usage still had plenty of room, while the additional usage credits I had configured had already reached their limit.

After looking into it, I realized that Fable usage was what had caused me to go beyond the included usage and consume additional credits.

That explained why the credits had run out.

But it also made me ask a different question:

Why was I consuming so much usage in the first place?

Until then, I had been using Claude Code every day without paying much attention to what was actually driving my usage.

So I started looking more closely at /usage and reviewing how I had been working.

One thing that stood out was Playwright MCP.

That did not mean Playwright MCP itself was the reason I had exceeded my usage limit.

Rather, it made me notice how much context could accumulate during browser testing, and how that context could continue to affect subsequent work if I kept using the same session.

The habit I eventually changed was very simple:

After finishing a test with Playwright MCP, if I do not need that context for the next task, I use /clear.

This article is a short learning log about how I got there.

Usage Is Not Just About How Many Times You Talk to Claude

I used to think about Claude Code usage in a fairly simple way:

The more questions I ask, the more expensive it gets.

That is not entirely wrong.

But the size of the context Claude is working with also matters.

Claude Code is not looking only at the latest sentence I type.

It works with the context needed for the current task, including previous conversation history, files it has read, and tool results.

So, if I simplify my understanding quite a bit:

The larger the context is, the heavier it can become to keep processing within that context.

`/usage` Made Me Look at Playwright MCP

When I checked /usage, I saw results like these:

79% of your usage was at >150k context

61% of your usage came from subagent-heavy sessions

36% of your usage came from the MCP server "playwright"

At first, I thought these were three separate problems:

My context was too large
I was using too many subagents
Playwright MCP was expensive

But after looking at how I had been working, they seemed more connected than I initially thought.

When using Playwright MCP for E2E checks, I repeatedly do things like:

Open a page
Inspect elements
Click a button
Fill in a form
Check the state after navigation
Fix something and try again if necessary

For Claude to understand the browser state, relatively large tool results can be added to the context during these interactions.

Each individual operation may feel like a simple browser check.

But after repeating them several times, browser-related context can accumulate quickly.

That part can be considered a necessary cost of testing.

The more interesting problem for me was what happened afterward.

The Test Was Finished, but the Context Wasn't

From my perspective, once I reach:

Test complete. Time to move on to the next task.

much of the information generated during the Playwright session has already served its purpose.

But if I continue using the same session, I also continue working with that context.

For example:

Implement a feature
Verify it with Playwright MCP
Confirm that it works
Start implementing another feature

I used to move directly to step 4 without resetting the session.

But when working on the next feature, I may no longer need all the browser information generated during the previous E2E test.

There is a gap between:

“This context is no longer useful to me”

and:

“Claude Code is no longer carrying this context.”

Looking into my usage made me much more aware of that difference.

After Playwright MCP Testing, I Use `/clear`

So I now follow one simple rule:

After finishing a Playwright MCP test, if I do not need that context for the next task, I use /clear.

I do not clear the session mechanically after every test.

My rule is simply:

Will I need this context for the next task?

If not, I clear it.

Conclusion

When I first started using Claude Code, I tended to think of context as something that was simply better to have more of.

And of course, having the right context is important.

But after looking into my usage, I started thinking about the cost of keeping context that is no longer useful.

This feels especially relevant with tools like Playwright MCP, where repeated browser interactions can add a lot of information to the session in a relatively short period of time.

And once the test is finished, that information may no longer be useful for the next task.

This experience made me start thinking of Claude Code context as having a kind of lifecycle:

Collect it when needed.

Keep it while it is useful.

Let it go when its job is done.

For now, that is the rule I am following.

Web APIs and Batch Jobs Communicate Failure Differently

Tohru Yaginuma — Sat, 22 Aug 2026 23:58:22 +0000

Long Story Short

Web APIs can communicate failure through HTTP status codes, but batch jobs need to terminate in a way that allows the execution environment to recognize that the process has failed.
In this case, I changed the error handling to throw an exception. This caused failed Lambda invocations to be reflected in the CloudWatch Errors metric, which allowed the alarm to trigger.
Error handling does not end inside the application. We also need to think about whether failures can be correctly observed by the monitoring and alerting systems outside it.

Context

Recently, I had the opportunity to implement a mechanism that sends a Slack notification when a batch job running on AWS fails.

The batch job itself was an existing Lambda function that was already running in production, so I initially thought the task would be relatively simple.

The setup was to monitor Lambda execution errors with CloudWatch and send notifications to Slack through AWS notification services.

The AWS-side configuration itself was not particularly complicated.

However, when I looked at the existing batch code that we wanted to monitor, I found a problem.

An Error Was Happening, but the Job Wasn't Failing

The existing error handling included code like this:

return false

or:

return { status: 500 }

The intention was probably to indicate that an error had occurred.

From Lambda's perspective, however, that is not what happens.

Returning false or { status: 500 } simply means that the Lambda function returned a value and completed successfully.

Just because the returned value contains the number 500 does not mean that Lambda automatically treats the invocation as a failure.

As a result, even though the application code intended to handle the situation as an error, the execution environment still saw it as a successful invocation.

Because of that, the invocation was not treated as a function error and was not reflected in CloudWatch's Errors metric.

The CloudWatch Alarm therefore did not trigger, and no Slack notification was sent.

Building the monitoring mechanism made me realize that the existing error handling was not communicating the failure correctly to the systems outside the application.

I Couldn't Apply the Same Mental Model as a Web API

What I found interesting was the difference between how Web APIs and batch jobs communicate failure.

In a Web API, we use HTTP status codes to communicate the result of a request to the client.

For example:

HTTP 500 Internal Server Error

By returning an HTTP 500 response, the client can recognize that the request has failed.

When you spend a lot of time working with Web APIs, it becomes natural to think:

If something goes wrong, return 500.

But what I was working with this time was not a Web API responding to an HTTP request. It was a batch job running on Lambda.

There was no client waiting for an HTTP response.

What mattered was not returning a value that contained 500, but making the Lambda invocation itself fail.

In this case, I refactored the code to throw an exception when an error occurred:

throw new Error(...)

This caused the Lambda invocation itself to fail, which was then reflected in the CloudWatch Errors metric.

Error Handling Doesn't End Inside the Application

When I started this task, I thought I was simply adding a Slack notification for batch failures.

But once I followed the notification flow back to the existing code, I ended up asking a more fundamental question:

Is this application actually communicating its failures correctly to the outside world?

Writing an error log.

Returning false.

Returning a value containing 500.

If you only look at the application code, all of these can appear to be forms of error handling.

But if the Lambda runtime and CloudWatch cannot observe the execution as a failure, that error handling does not connect to monitoring or alerting.

This experience made me realize that when thinking about error handling, I should consider not only:

"How is the error handled inside the code?"

but also:

"Who needs to observe this failure, and how will they know that it happened?"

Conclusion

Web APIs communicate success and failure to clients through HTTP status codes.

Batch jobs are different. We need to think about how the execution environment determines whether a job succeeded or failed.

Implementing this Slack notification mechanism made me realize that the familiar Web API mindset of "return 500 when something fails" cannot simply be applied to batch jobs.

Error handling is not only an application-level concern.

I learned that part of error handling is also making sure that a failure can be correctly observed by the execution environment and the monitoring systems around the application.

Designing HTML Page Caching Changed How I Think About Caching

Tohru Yaginuma — Sun, 16 Aug 2026 15:09:34 +0000

Long Story Short

Designing HTML page caching in practice connected several concepts I had previously understood separately, such as TTL, browser caching, and where cache policies should live.
In our architecture, where HTML pages are cached with CloudFront, the choice between CSR and SSR also affects whether data can benefit from the HTML cache.
Starting from the simple goal of “caching pages” made me think more broadly about what should be cached and where, including API responses and backend caching.

Context

Recently, I had the opportunity to design HTML page caching for a web platform at work.

It was my first time designing HTML page caching in practice, and we used AWS CloudFront as our CDN.

I already had a basic understanding of caching.

Store a response once, reuse it later, reduce server-side processing, and improve response times.

At least conceptually, I thought I understood it.

The task also seemed relatively simple at first.

If we cache HTML pages in CloudFront, requests don’t need to reach the application every time.

Then we just need to decide which pages to cache and how long their TTLs should be.

Once I actually started working on the design, however, I realized there was more to think about.

Looking at CSR and SSR Through the Lens of Caching

One of the things I found particularly interesting was the relationship between CSR, SSR, and HTML page caching.

I had previously thought about CSR and SSR mainly in terms of where rendering happens.

With CSR, rendering happens in the browser. With SSR, HTML is generated on the server.

From there, I would usually think about things like SEO and initial page-load performance.

None of that was new to me.

But designing HTML page caching gave me another perspective on CSR and SSR.

In our case, CloudFront caches HTML pages.

This means that when data is fetched during SSR and included in the HTML, the resulting HTML — including that data — can be served from the CloudFront cache.

With CSR, on the other hand, the browser fetches data from an API after receiving the HTML. That data is therefore outside the HTML page cache.

Of course, this doesn’t mean that “SSR is cacheable” and “CSR is not.”

SSR-generated HTML doesn’t have to be cached, and API responses fetched through CSR can be cached at other layers.

But in our architecture, the choice between CSR and SSR affects whether that data can benefit from the HTML page cache.

I had previously viewed CSR and SSR primarily as rendering strategies, so seeing this connection in practice was interesting to me.

Caching Exists Beyond HTML

Thinking about CSR led me to another question:

What about the API responses fetched by the client?

For this project, the scope was HTML page caching with CloudFront. I hadn't really considered API response caching as part of the same problem at that point.

But while thinking about CSR and SSR, I realized that API responses can also be cached at different layers, such as a CDN or the backend itself.

That made me realize that I had been thinking about caching too narrowly, mostly in terms of HTML pages.

Do we cache the HTML?

Do we cache API responses?

Do we cache something in the browser?

At the CDN?

On the backend?

They are all forms of caching, but each comes with different considerations.

I didn’t design API caching as part of this project.

Still, thinking about HTML page caching made me look beyond HTML and think more deeply about caching across the system. That itself was an important learning for me.

TTL Needs a Reason Too

TTL was another area I hadn’t thought deeply about until I had to design it myself.

A longer TTL allows a cached response to be reused for longer.

But it also means that stale content can remain visible for longer after the underlying page has been updated.

Not every page has the same traffic or update frequency either.

Some pages receive a lot of traffic but rarely change. Others may change relatively frequently.

Once I started thinking about actual pages, I realized that TTL wasn’t simply a matter of choosing a “long” or “short” value.

It was a trade-off involving how fresh each page needed to be.

I used to think of TTL mostly as a configuration value. This experience made me realize that the value itself should have a reason behind it.

Where Should Caching Decisions Live?

Another question was where the decision about which pages to cache should live.

We could define rules in CloudFront based on URLs and other conditions.

But the application often has the most context about whether a particular page is safe to cache.

In our design, we decided to keep information about cacheable pages on the application side and use that information to control caching behavior in CloudFront.

Before this project, I partly thought of HTML page caching as CDN configuration.

Working on the design made me realize that it can also be an application design question:

Where should the responsibility for caching decisions live?

A Clearer Mental Model of Caching

I don’t feel that I learned one particular new caching technology from this experience.

The bigger learning was that concepts I had previously understood separately started to connect.

CSR and SSR.

CDNs.

TTL.

Browser caching.

API response caching.

Backend caching.

I already knew these terms and concepts individually.

But designing HTML page caching myself forced me to think about them in terms of a real system: What should we do here?

The questions I ask about caching have also changed.

What are we caching?

Where are we caching it?

Who can safely share the cached response?

How fresh does it need to be?

There is still plenty I don’t know.

But I now have a much clearer idea of what questions I should be asking.

Designing HTML page caching gave me a much clearer mental model of caching than I had before.

Async-First Doesn’t Mean Async-Only

Tohru Yaginuma — Sun, 09 Aug 2026 20:27:34 +0000

Key Takeaways

Asynchronous discussions can lose momentum because participants are focused on different tasks. For complex or important topics, it’s often better to switch to synchronous communication.
At least in my experience working in a Japanese-speaking organization, AI-generated messages are often still too verbose to send as-is. As writing becomes cheaper, it’s even more important to reduce the cognitive load on readers.
Async-first does not mean async-only. Keeping written records while introducing short meetings when necessary can reduce the overall cost of communication.

Context

I currently work from Vancouver, Canada, for a fully remote and fully flexible organization based in Japan.

Since everyone works on their own schedule, much of our day-to-day communication, decision-making, and discussion happens asynchronously.

There are many benefits to this way of working. People can think at their own pace, and discussions naturally leave a written record.

As someone who is fairly introverted, I also appreciate having time to think through my ideas before sharing them.

Recently, however, I’ve started to realize that keeping every discussion asynchronous is not always the most efficient approach.

Complex discussions are expensive to read

When discussing multiple options, I usually start by sharing my recommendation, then document the reasoning behind it and the pros and cons of alternative approaches.

The more complicated the topic becomes, the longer the document becomes.

Writing requires effort, but so does reading. Someone has to understand the background, process the trade-offs, form an opinion, and respond.

Lately, I’ve become more aware of the reader’s cost than the writer’s.

In our company, Japanese is the shared language, and much of our written communication is now assisted by AI. While AI makes it easier to produce long documents, the resulting text can still be unnecessarily verbose or difficult to follow.

AI makes writing cheaper. It does not necessarily make reading cheaper.

On top of that, everyone already has their own priorities.

When a message arrives, people are often in the middle of something else. Replies become spread out over hours or days. Discussions can lose momentum, and important but non-urgent topics may eventually fade away without reaching a conclusion.

Write first, then talk

To address this, I’ve started scheduling short meetings whenever a discussion becomes too complex to resolve asynchronously.

This doesn’t mean abandoning written communication.

I still document the background, context, and available options. AI helps me draft these documents quickly, but I always review and simplify them before sharing.

Once everyone has the necessary context, a short meeting allows the team to focus on the same problem at the same time.

I’ve found that questions that would otherwise require many rounds of messages can often be resolved in just a few minutes of conversation.

There’s another benefit as well.

In a fully remote, fully flexible environment, opportunities to talk to teammates naturally become less frequent. Even when the purpose is purely technical, real-time conversations can help build mutual understanding and trust.

Async-first doesn’t mean avoiding meetings

I used to believe that if a team was designed around asynchronous communication, then most discussions should stay asynchronous.

I don’t think that anymore.

Asynchronous communication is a tool, not the goal.

If a topic is simple, asynchronous communication works well. If a discussion becomes complex, stalls, or requires multiple rounds of clarification, a short synchronous conversation can be the more efficient option.

I’ve learned not to hesitate to schedule a meeting when it helps move an important discussion forward.

Being async-first doesn’t mean avoiding synchronous communication.

It means choosing the communication style that minimizes the overall cost for the team.

DEV Community: Tohru Yaginuma

Using the Grok API to Reduce the Effort of Keeping Up with AI

Long Story Short

Context

What I Built

Why Grok Was a Good Fit

The First Version Wasn't Very Useful

The Hard Part Was Selection

What Changed for Me

Limitations

Conclusion

I Started Using /clear After Testing with Playwright MCP

Long Story Short

Context

Usage Is Not Just About How Many Times You Talk to Claude

/usage Made Me Look at Playwright MCP

The Test Was Finished, but the Context Wasn't

After Playwright MCP Testing, I Use /clear

Conclusion

Web APIs and Batch Jobs Communicate Failure Differently

Long Story Short

Context

An Error Was Happening, but the Job Wasn't Failing

I Couldn't Apply the Same Mental Model as a Web API

Error Handling Doesn't End Inside the Application

Conclusion

Designing HTML Page Caching Changed How I Think About Caching

Long Story Short

Context

Looking at CSR and SSR Through the Lens of Caching

Caching Exists Beyond HTML

TTL Needs a Reason Too

Where Should Caching Decisions Live?

A Clearer Mental Model of Caching

Async-First Doesn’t Mean Async-Only

Key Takeaways

Context

Complex discussions are expensive to read

Write first, then talk

Async-first doesn’t mean avoiding meetings

`/usage` Made Me Look at Playwright MCP

After Playwright MCP Testing, I Use `/clear`