DEV Community: javaskr

Two More Days Inside Grok Bot Galaxy: Building, Breaking, and Rethinking AI Teammates

javaskr — Fri, 18 Sep 2026 13:48:47 +0000

From building my first bot to burning through my usage limits — a few honest thoughts after Day 1.

What I Tried

Of course, the first thing I did was play around with Dr. Eggbot.

I started with the basics: setting up a bot, giving it a name and description, chatting with bots, checking MCP connections, and figuring out how all the different pieces actually connect.

After that, I started thinking:

Okay, but what can I actually build with this?

I know some people had already been using Grok Bot for a month and had their own workflows figured out. I was basically starting from zero, so I wanted to find something I could actually build instead of just watching demos.

Then I noticed there was a challenge from Grok: create a template, get selected, and potentially get a chance to go to space.

I mean...

Yeah. Let's do it. 😂

I spent quite a while trying to come up with an idea that wasn't just another "AI assistant that does X."

Eventually, I decided to let some bots help me think through the idea and build it.

After a lot of wiring things together, I submitted the bot.

And honestly, just doing that gave me a pretty good tour of the Grok Bot ecosystem.

I ended up touching MCP, Bots, Chat, Mentions, Shortcuts, Public Bots, and using other people's Public Bots.

The downside?

I burned through my usage limit ridiculously fast.

I eventually upgraded to Pro just to keep experimenting.

And somehow, I've already managed to hit 100% usage again.

Cry. 😂

Some Thoughts

There Is a Lot Happening Under the Hood

One thing that became pretty obvious to me is that running this kind of system probably isn't cheap.

You have bots running in parallel, cloud computers, different tasks being passed around, SaaS integrations, authentication, permissions, and all the little things happening between the steps.

It made me think about the economics of building a startup around something like this.

If you had to pay for all of that yourself at scale, without the infrastructure and distribution of a company like X, I can imagine the numbers getting ugly very quickly.

I'm not saying I know what Grok's actual infrastructure costs are.

I'm just saying that after watching my own usage disappear that quickly, I started thinking:

How the hell does this scale? 😂

There Are Still Things I'd Love to See

One of the biggest things I'd like to see is better support for multiple bots working inside the same conversation.

I can imagine a much nicer experience where I could simply say:

"Load my product team."

And suddenly I have a predefined group of bots ready to work together.

Something like a bot cookbook or reusable team template.

Instead of rebuilding the same setup every time, you could import a group of specialized bots and start working.

That feels much closer to how I'd actually want to use AI agents.

If They're Teammates, Can They Actually Have Personalities?

We're calling these things AI teammates.

That got me thinking about something slightly more interesting.

If I have a CTO bot, a reviewer bot, and a prototyping bot, should they all talk and behave exactly the same?

Probably not.

Could we define their tone, personality, communication style, and even the way they approach problems?

And then there's the more interesting question:

Can we somehow inject part of our own way of thinking into them?

Not just:

"Remember my name and preferences."

I mean things like:

"This is how I usually evaluate a product."

"This is what I consider good enough to ship."

"These are the things I always look for before launching."

That starts getting much more interesting to me.

The Hidden Cost Is Real

Another thing I noticed is how quickly usage can disappear.

There are a lot of things happening behind the scenes:

VM usage
Multiple bots
Tasks being broken into smaller pieces
Tool calls
Permission requests
Authorization steps
Human approval

And probably plenty of other things I don't see.

I hit 100% usage surprisingly quickly, even on Pro.

And honestly, I still don't completely understand why the demo felt so fast compared with my own experience.

Maybe the infrastructure is different.

Maybe the workloads are different.

Maybe there's a lot happening behind the scenes that I simply don't see.

I don't know yet.

But it's something I'm definitely going to pay attention to as I keep experimenting.

Also, having Grok Bot available from mobile is going to be important if these agents are supposed to become something we actually use throughout the day.

What I Took Away

The biggest thing I learned is probably this:

AI teammates don't mean you get to stop thinking.

Even if you have a bunch of capable bots working for you, somebody still needs to sit there and orchestrate the whole thing.

Which bot should do what?

When should another bot take over?

What needs human approval?

What should be rejected?

What actually needs to ship?

The bots can do a lot of the work.

But someone still needs to care about the result.

And this is where I think the whole AI thing can get a little funny.

With AI, we can build almost anything.

But if you don't have a consistent mentality around actually shipping something useful, you can just become incredibly efficient at building useless things.

You're not using AI.You're just being dumb with AI, faster. 😂

AI Can Execute. But Can It See the Blind Spot?

This is probably the part I've been thinking about the most.

Even if you have AI teammates.

Even if you're an experienced engineer.

Even if you have a whole pipeline of agents researching, designing, coding, reviewing, and shipping...

There are still things they might completely miss.

Have you ever asked AI for ideas, got 20 pretty reasonable answers, and then talked to someone with years of experience who casually said something you never considered?

And you suddenly thought:

"Oh. That's actually the idea."

That's the blind spot I'm talking about.

AI can be incredibly good at execution.

But sometimes the most valuable thing isn't another execution step.

It's vision.

Knowing what question to ask.

Knowing what doesn't make sense.

Knowing what everyone else is overlooking.

That's where I think humans still have a very important role.

AI Teammates ≠ Human Workforce Replacement

At least from what I've experienced so far, I don't see AI teammates as simply replacing a human workforce.

I see them more like an extension of the person using them.

A wing.

You still decide where you're going.

The agents help you move faster.

And honestly, some of the guest speakers during the event reinforced that for me.

A few of them brought a really strong business and marketing perspective that I wouldn't necessarily get just by asking a bot to generate another plan.

That part was probably one of my favorite things about the whole event.

Sometimes you don't need another answer.

You need someone to make you think differently.

One Last Thing

I'm still waiting for my Grok Bot usage and credits to reset. 😂

Apparently I got a little too excited on Day 1.

But that's also probably the best sign that I was actually experimenting instead of just watching the demos.

I still have a lot of questions about how this whole thing works at scale.

And I definitely haven't figured out the "right" way to build with it yet.

That's kind of the fun part.

Let's build something great.

Happy Friday. 🤖

If this was useful, the full piece lives on my site — more on AI platform work, RAG, and shipping from Tokyo.

Read it on javaskr.com

My First Day Inside Grok Bot Galaxy: AI Agents Are Starting to Feel Like Teammates

javaskr — Wed, 16 Sep 2026 15:22:37 +0000

Hello folks 👋
Yesterday was the first day of Grok Bot Galaxy, and I learned quite a lot from the live sessions.
Especially the basics of Grok Bot.
And yes, I probably spent too much time thinking about the word Bot and calling it an eggbot in my head. 😂
The only problem?
It was late at night in Japan.
I tried my best to keep up, but honestly, I don't know how people outside the US are supposed to survive three full days of this without destroying their sleep schedule. 😅
Still, even from the first day, I started to understand something that I think is more interesting than simply "another AI tool."
Grok Bot is showing what happens when AI gets a computer, tools, memory, and enough time to actually do things.

From AI assistant to AI teammate

The biggest thing I noticed is the flexibility.
We've already become pretty comfortable with AI assistants.
Ask a question → get an answer → copy the result → do the actual work ourselves.
Grok Bot feels different because the idea is closer to:

Give the bot a goal → give it access to the right tools → let it work → review the result.

That sounds like a small change, but I think it changes the entire workflow.
For example, imagine giving a bot access to Gmail, Notion, Figma, GitHub, or other tools you already use.
Instead of asking:

"Can you tell me what I should do?"

you can start asking:

"Can you do this for me?"

That's a very different relationship with AI.

The connection problem becomes much smaller

One thing I really appreciated during the demo was the integration with the existing Cursor ecosystem.
Anyone who has tried building an AI agent knows that authentication can become a nightmare.
You need OAuth.
You need permissions.
You need API keys.
You need to figure out which account is connected.
Then you need to do it again for another service.
And again.
And again.
So when existing connections can be reused across the ecosystem, the onboarding experience becomes much smoother.
I already had my Cursor account configured, so getting started with Grok Bot felt surprisingly natural.
The more tools you connect, the more useful the bot can potentially become.
Gmail.
Notion.
Figma.
GitHub.
Stripe.
And more.
Of course, more access also means more responsibility. An agent can only do useful work with the tools and permissions you give it.
But that's exactly the interesting part.
The capability of the agent isn't just the model. It's the combination of model + tools + permissions + context.

Memory is where things get really interesting

Another part that caught my attention was memory.
A bot doesn't necessarily have to start from zero every time you interact with it.
It can build up context from previous work, and that becomes particularly interesting when you combine memory with automation.
Imagine closing your laptop.
The bot doesn't necessarily stop just because you're no longer looking at the screen.
You could have a routine or scheduled task running, and the bot can use the information it already has to continue working.
That's a pretty big shift from the traditional chatbot experience.
The computer can be closed.
The browser can be somewhere else.
But the work can continue.
And then there is another interesting idea:
multiple bots working together.
You could have one bot responsible for one type of work, while another bot handles something else.
A higher-level bot could coordinate them.
That starts to look less like "one AI assistant" and more like an actual AI team.

But there is a small catch with duplication

One thing I noticed while experimenting with bots is that duplication isn't necessarily the same thing as cloning a human teammate.
You can duplicate a bot, but you shouldn't automatically assume that every piece of its accumulated context or memory comes with it.
And honestly, I think that makes sense.
If I want to test whether a bot behaves correctly, I would actually want to be careful about what gets inherited.
Otherwise, how do we know whether the new bot is behaving according to its defined role or simply relying on historical context?
For testing and calibration, I can imagine a useful workflow being:
Original bot → duplicate → controlled test → compare behavior
That could become quite useful when we're building bots that are supposed to perform a specific job repeatedly.

The best way to understand it?

Just build one.
That's basically what I did.
Instead of watching everything and trying to understand the whole platform first, I decided to create my own Grok Bot.
My idea isn't particularly complicated.
Create multiple bots.
Give each one a role.
Let each bot focus on a specific type of work.
Then let the human handle the orchestration.
This reminds me of how we already design software systems.
We don't necessarily want one giant function doing everything.
We break things down.
Authentication.
Payments.
Notifications.
Data processing.
Frontend.
Backend.
Each component has a responsibility.
AI agents can be designed in a similar way.

And then there is the bot factory

If you don't want to build everything yourself, there are also public bots in the marketplace.
One example from the demo was Dr Eggbot.
The interesting idea isn't just that the bot can perform a task.
It can help you create other bots.
So you start getting something like:
Bot → creates bots → bots perform specialized work
That's where things start getting a little weird. 😂
But in a good way.

The cloud computer changes the mental model

Another thing that really stood out to me is that the bot has its own computer environment.
That means the bot isn't simply generating text inside a chat window.
It can actually operate software, navigate websites, interact with tools, and continue working.
And because the work happens in the cloud, closing my laptop doesn't necessarily mean the work has stopped.
That's probably one of the biggest differences between a traditional AI assistant and an AI agent.
A chatbot waits for me.
An agent can potentially keep working on the task I gave it.

The SF food truck experiment

During the first-day demo, the team built a pop-up food truck business in San Francisco.
What I found interesting wasn't really the food truck itself.
It was the organizational structure.
Different bots were given different responsibilities:

CTO
Prototyper
Reviewer
Merger
and other specialized roles Instead of asking one AI to do everything, the work was divided into smaller responsibilities. That feels much closer to how an actual team operates. And that's probably the part I find most exciting.

What does this mean for product development?

If we can reliably divide work between specialized AI agents, the product cycle could become much faster.
Imagine:
Idea → Research → Prototype → Review → Fix → Merge → Launch
Each stage could potentially have its own agent.
Humans don't necessarily disappear from the process.
Instead, our job changes.
We define the goals.
We decide what the agents are allowed to do.
We connect the right tools.
We review the results.
We handle exceptions.
And we make the final decisions.
In other words, we become more of the orchestrator.

We're still figuring out the right boundaries

Of course, this isn't just about giving AI more permissions and hoping everything works.
The more tools an agent can access, the more important permissions, authentication, memory, and review become.
Giving a bot access to Gmail is one thing.
Giving it access to production infrastructure or financial systems is another.
So I think the real engineering challenge isn't simply:

"How autonomous can we make the bot?"

It might be:

"How much autonomy should we give it for this particular job?"

That's a much more interesting question.

My takeaway from Day 1

After the first day, I don't think the most interesting part of Grok Bot is simply that it can use AI.
We've had AI assistants for a while.
The interesting part is the combination of:
AI + computer + tools + memory + automation + multiple specialized agents
Put those pieces together and the workflow starts to look very different.
Maybe the future isn't one super-smart AI that does everything.
Maybe it's a team of smaller AI agents, each with a clearly defined responsibility, while humans sit above them and coordinate the work.
I'm still playing around with Grok Bot, so I expect my opinion will probably change as I use it more.
For now, though, I'm pretty excited to see where this goes.
Happy Wednesday. 👋
And if you're also experimenting with Grok Bot, I'd love to hear what kind of bot you're building.
Let's see what these little bots can actually do. 🤖

👉 javaskr.com

Engineering Is Not About Getting Every Decision Right

javaskr — Mon, 14 Sep 2026 15:10:12 +0000

If SDLC sounds familiar, you probably know that a product isn't built in one step.

A product is built through a whole set of processes, decisions, iterations, and feedback loops.

This becomes even more important when you're building something from 0 to 1.

You need to stay focused on what you're building, be conscious of the decisions you're making, and stay alert to potential technical debt.

Imagine You Need to Ship a Feature

You have the requirements.

You know the expected outcome.

You have a deadline.

But a feature is rarely just one thing.

It can connect with other services, components, repositories, databases, APIs, and different states of the system.

There are always edge cases and possibilities that you can't see at the beginning.

So you choose an approach.

Maybe Approach A looks like the best fit at that moment.

You implement it, connect it with the rest of the system, test it, and ship the feature.

Done.

You move on to the next thing.

Then You Discover Approach B

A few weeks later, you're working on another feature.

And suddenly, you realize:

"Wait... if I had used Approach B, both features could have been designed in a much better way."

Looking back, Approach A might not seem like the best decision anymore.

But does that mean the decision was wrong?

I don't think so.

At that point in time, you were making a decision based on the information, requirements, constraints, and experience you had.

You made what you thought was the best decision at that moment.

Later, you gained more context.

And with that new context, you found a better solution.

Engineering Isn't About Proving Every Decision Was Right

I think this is one of the interesting parts of software engineering.

We're not trying to prove that every decision we made was correct.

We're trying to stay in the loop:

Build → Observe → Learn → Improve → Build again

Every time we go through that loop, we gain more understanding.

Maybe we understand the product better.

Maybe we understand the architecture better.

Maybe we understand the users better.

Or maybe we simply understand ourselves as engineers better.

And that changes the decisions we make next time.

Sometimes Refactoring Feels Frustrating

Of course, improving an existing implementation isn't always fun.

Sometimes you have to refactor something that already works.

Sometimes you need to rethink an architecture you were once confident about.

Sometimes you look at code you wrote a few months ago and think:

"Why did I build it this way?" 😅

It's easy to see this as wasted effort.

But I think there's another way to look at it.

The implementation improved because you improved.

The code changed.

The system changed.

And more importantly, you changed.

You Don't Need to Know Everything From Day One

Especially when building something from 0 to 1, there will always be things you don't know yet.

You can't predict every future requirement.

You can't see every edge case.

You can't always know which abstraction will work best six months from now.

That's okay.

What matters is being conscious about the decisions you're making today and staying alert to the problems that might appear tomorrow.

Don't ignore technical debt.

But don't be afraid of making decisions either.

You need to build something before you can learn how to build it better.

The Beauty of Engineering

Maybe that's one of the things I like most about engineering.

We're not expected to know everything from the beginning.

We're expected to keep learning and make better decisions as we gain more context.

An implementation that seemed reasonable yesterday might not be the best solution today.

And that's not necessarily failure.

It can be a sign that you've grown.

So let's keep building.

Let's build some things that might look "bad" in hindsight.

Maybe one day, they'll become the reason we know how to build something better.

Happy coding, happy Monday ☕️

I write about AI, software engineering, technology, and the things I'm learning along the way.
If you found this perspective interesting, you can read more of my work at:
👉 javaskr.com

Grok Bot and the Rise of AI Teammates

javaskr — Sun, 13 Sep 2026 23:27:52 +0000

In my last post, I talked about the potential risks AI could bring to humans in the not-too-distant future.
Today, I want to look at another side of AI: what happens when we give AI more freedom to actually do things?
Grok Bot is an interesting example.
Starting tomorrow, the Grok Bot Galaxy event will run a 72-hour demo, showing end-to-end workflows from different perspectives, including business, engineering, and marketing.
I'm particularly interested in watching how an AI agent handles these workflows from beginning to end.

From Chatbots to Agents

Everyone is familiar with the typical AI workflow:
We give AI a prompt → AI gives us a response → We do the rest.
For example, we ask AI to:

Explain an unfamiliar API
Debug an error
Write a test
Brainstorm an architecture
Summarize some documentation

Then we take the response and continue working.
It's useful, but it's still quite passive and step-by-step.
So what happens when we change the workflow?
With an AI agent like Grok Bot, the idea becomes more like:
We give AI a goal → AI plans → AI uses tools → AI keeps working → We review and approve.
The AI isn't just answering us anymore.
It's taking action.
And that's a pretty significant change.

The Model Is Only Part of the Story
Think back to late 2023.
AI was already impressive, but the way we interacted with it was still relatively simple: type something, get a response, and continue from there.
Fast forward to today, and we're increasingly talking about AI agents, autonomous workflows, and eventually AGI.
But does this progress come only from making the underlying AI model smarter?
I don't think so.
The model is obviously important. Better reasoning gives AI the ability to understand more complicated problems.
But an AI system also becomes much more capable when we give it the ability to act on what it thinks.

Give it web search.
Give it a terminal.
Give it the ability to run commands or call APIs.
Give it external tools.
Give it memory.
Give it persistent state.

Now the system isn't simply generating a response.
It can observe something, make a decision, take an action, observe the result, and continue.
That's where AI agent architecture becomes really interesting.
The model provides the intelligence. The agent architecture gives that intelligence a way to act.

Imagine Grok Bot as a New Teammate

Now let's make this practical.
Imagine Grok Bot joining our SaaS engineering team as a new teammate.
What should we actually let it do?
For bugs, for example, sometimes we need a reliable reproduction before another engineer can verify a fix.
Instead of asking an AI:

"How can I reproduce this bug?"

We could give it a goal:

"Reproduce this bug, collect the relevant logs, document the steps, and create a Jira ticket."

The agent could potentially:
Open the application
Follow the required workflow
Reproduce the issue
Collect logs and relevant information
Document the reproduction steps
Create a Jira ticket
Wait for us to review it
That's very different from asking ChatGPT to simply tell us how to reproduce the bug.
The AI isn't replacing the engineer.
It's taking over a workflow that previously required an engineer to manually move between different tools.

And It Doesn't Stop at Engineering

This is where the Grok Bot Galaxy demo becomes interesting to me.
If an agent can operate across different tools and workflows, why stop at engineering?
Imagine giving it a business goal:

"Find out why our trial-to-paid conversion dropped this month."
Instead of only asking for an analysis, the agent could potentially gather data, inspect dashboards, compare historical results, identify possible causes, and prepare a report.
Or for marketing:

"Prepare a campaign for our new feature."
The agent could research competitors, draft content, prepare different variations, and organize the campaign workflow for human review.
The important change isn't that AI can write these things.
AI has been able to write for a while.
The interesting part is that the AI can potentially connect the individual steps together.

But How Much Freedom Should We Give It?

This is also where my previous post about AI risks connects to today's topic.
The more capable an AI agent becomes, the more important permissions and boundaries become.
If we give an AI access to:

Our codebase
Production systems
Customer data
Company accounts
Internal documents
Payment systems

then "make the AI more autonomous" isn't automatically a good thing.
We need to ask:
What should it be allowed to do?
What should require human approval?
How do we know what it actually did?
What happens when it misunderstands the goal?
An AI teammate with too little access might not be very useful.
An AI teammate with too much access might become a serious security and operational risk.
The interesting engineering problem may therefore become not just building smarter agents, but designing the right boundaries around them.

From AI Assistant to AI Teammate

This is what I find most interesting about Grok Bot.
The biggest change may not be another improvement in how well AI answers questions.
It may be the transition from:
"Ask AI something."
to:
"Give AI something to accomplish."
That's a different mental model.
We're moving from AI as a tool that waits for instructions toward AI as a system that can take initiative within a defined scope.
I don't think this means developers suddenly become unnecessary.
If anything, the role of the developer may become more interesting.
We may spend less time manually executing every step and more time:

Defining goals
Designing workflows
Choosing the right tools
Setting permissions
Reviewing AI decisions
Handling edge cases
Taking responsibility for the final result

The question may no longer be:
"Can AI do this task?"
but:
"How much of this workflow should we let AI do?"
That's what I want to explore while watching Grok Bot Galaxy.
We're still early.
But the direction is fascinating.
And perhaps the next generation of software won't just be software that we use.
It will be software that works alongside us.

I write about AI, software engineering, technology, and the things I'm learning along the way.
If you found this perspective interesting, you can read more of my work at:
👉 javaskr.com

🚀 Future Friday: The AI Panic of 2030 — Why We’re Still the Drivers

javaskr — Fri, 11 Sep 2026 17:49:37 +0000

AI headlines have been getting pretty intense lately.
Jacob Coxon, a pretraining researcher who has worked at both OpenAI and Anthropic, recently resigned from Anthropic and warned about the risks of the industry's race toward increasingly capable AI systems.
That sparked a familiar debate: could AI become an existential threat within the next decade?
Some researchers believe the risk is significant. Others are far less convinced.
Personally, I think the conversation needs a little more balance.

Take the Risk Seriously, Not the Panic
AI safety matters. There's no question about that.
These systems are becoming more capable, more autonomous, and increasingly connected to real-world software and infrastructure. We should absolutely be thinking about how to test them, secure them, and put appropriate safeguards in place.
But there's a big difference between taking a risk seriously and assuming the worst-case scenario is inevitable.
As engineers, we're used to working with complicated systems. We don't expect them to be perfect. We test them, monitor them, find their failure modes, and improve them.
AI deserves the same mindset.

We're Still the Drivers
For most developers today, AI isn't an autonomous superintelligence.
It's a tool.
And honestly, it's already a remarkably useful one.
I use AI to explore unfamiliar APIs, brainstorm architecture, debug code, write tests, and get through the first version of an idea much faster.
But AI doesn't know what my users actually need.
It doesn't understand the full context of a product.
And when something breaks in production, it isn't the one getting the call.
That responsibility is still ours.
That's why I don't see the future of software engineering as a competition between developers and AI.
I see it as a shift in how we work.
The valuable skill isn't just writing code anymore. It's knowing what should be built, why it should be built, how the pieces fit together, and where things can go wrong.

So What Happens by 2030?
Maybe AI will become far more capable than we expect.
Maybe some of the more extreme predictions will come true.
Maybe they won't.
Nobody really knows.
What we do know is that developers, researchers, companies, and governments are making decisions today that will influence what comes next.
So rather than staring at a doomsday clock, I'd rather keep learning, experimenting, and building—with a healthy amount of skepticism along the way.
We're not passengers yet.
We're still driving.
Let's make sure we're paying attention to where we're going.

I write about AI, software engineering, technology, and the things I’m learning along the way.
If you found this perspective interesting, you can read more of my work at:
👉 javaskr.com

💻 What Apple’s September 2026 Event Means for Developers

javaskr — Thu, 10 Sep 2026 18:04:41 +0000

Hey everyone, it’s Timothy.

It’s been a minute. Between the startup grind here in Tokyo and pushing out a few side projects, writing definitely took a back seat.

But there was no way I was going to skip Apple’s September event.

There’s a lot to unpack, but I’m less interested in the specs and more interested in what these new devices mean for developers

The Elephant in the Room: iPhone Duo
Apple has finally entered the foldable market with the iPhone Duo, starting at $1,999.

It has a 5.4-inch outer display and a 7.6-inch inner display, with iOS adapting to the device as it opens and closes.

For developers, this is where things get interesting.

We’re going to have to think beyond traditional responsive design. How should navigation change when the phone opens? What happens to a two-column layout when it becomes a compact screen? How do we preserve context during those transitions?

The challenge isn’t simply supporting another screen size.

It’s designing for different physical states of the same device.

A20 Pro and iPhone 18 Pro
The iPhone 18 Pro and Pro Max bring the new A20 Pro chip, C2 modem, and a redesigned camera system with variable aperture.

For developers working with on-device AI, graphics, computational photography, or other demanding workloads, the additional performance headroom is exciting.

Even more interesting: Apple is exposing an API that lets third-party apps take advantage of the new variable-aperture camera capabilities.

That could open up some serious possibilities for photography and video apps.

And yes, Apple finally gave us burgundy.

I approve.

AirPods and Apple Watch
The new AirPods 5 bring Active Noise Cancellation to Apple’s open-ear design, along with Siri AI and Live Translation.

For those of us working across languages, this is more than a nice feature. It points toward a future where AI becomes part of the ambient computing experience rather than something we have to actively open and use.

The Apple Watch Series 12 is equally interesting from a developer perspective, with a new Health Sensing System, higher-frequency heart-rate and HRV measurements, and a new readiness score.

That means more data — and potentially more opportunities for developers building better fitness, wellness, and health experiences.

Of course, more personal data also means more responsibility around privacy and security.

So, What Changes for Developers?
For me, the biggest takeaway isn’t any individual product.

It’s that the hardware/software boundary keeps getting blurrier.

Foldable displays. On-device AI. Smarter cameras. Ambient translation. More capable health sensors.

Every new capability gives developers another building block — and another problem to solve.

The interesting question isn’t:

“What did Apple build?”

It’s:

“What can we build now that wasn’t practical before?”

That’s the part I’m excited about.

The hardware just got more capable.

Now let’s see what we can do with it.

Keep learning. Keep building. Keep sharing.

If you enjoyed this post and want to read the original version, you can find it on my website, I’ve recently updated the site as well, so if you’d like to follow more tech news, articles, and projects I’m working on, feel free to drop by — and if you have a project in mind that you’d like me to cover or explore, reach out. I’d love to hear from you.

What Tech Stacks Are Software Engineers Using in Tokyo Startups?

javaskr — Thu, 03 Jul 2025 16:41:02 +0000

Hello! It’s Thursday—let’s talk about the tech stack I use at work 👨‍💻

As a startup, we use a mix of tools to stay fast and flexible. We do use Slack for communication, but we don’t have advanced integrations like webhooks for deployment notifications (yet 😅).

🧾 Docs & Coordination

Confluence: For everything from API specs to research summaries and design docs
Jira: Occasionally linked to Confluence for task tracking
Figma: To view and comment on UI/UX designs
tl;dv: For automatic meeting notes
Mermaid: To create diagrams and workflows

💻 Application Stack

Frontend:
- Vite + React + TypeScript
- Tailwind CSS + shadcn/ui
- Sometimes we use Next.js for larger frontend apps
Backend: -FastAPI (Yes, partly because someone said it's "AI-friendly" 🤔)
- MySQL with SQLAlchemy
- Depending on project scale: Supabase or TiDB as DB

🚀 Deployment & Infra

GitHub: For version control
Vercel: For quick frontend deployment (especially mockups or low-scale apps)
AWS: Main backend hosting using Docker images
Terraform: Starting to use it for infra provisioning in newer projects

Note: We don’t yet have well-defined CI/CD pipelines or full DevOps practices.

🤖 AI Tools

We have a team instance of ChatGPT
I’m not sure about Gemini, but we do have a paid Cursor IDE license for the team

There’s definitely room to grow (especially in automation), but that’s the beauty of startups—lots of room to experiment and shape the stack together.

I’d guess 50% of this is similar to other Tokyo startups.
BTW, what does your company use? I’m curious 👀

What I Learned After 1 Year as a Software Engineer in a Tokyo Startup

javaskr — Wed, 02 Jul 2025 15:35:30 +0000

Hello folks 👋 Let’s talk about something work-related this Wednesday.

I’ve been working at a startup in Tokyo for almost a year now. During this time, I’ve delivered quite a lot: a mini-app, a human-settlement marker and mapper, a marketplace, and more. I’ve suffered through tight deadlines, long hours, countless meetings, and constantly changing requirements.

Here are 5 things I’ve learned that help you survive startup life:

1. Balance meeting time with “lock-in” time
I’m not 100% against meetings—but let’s be honest: some meetings are a waste of time. Especially if:

You’re not speaking
Less than 20% of the agenda applies to you

In that case, speak up and ask if you can skip it. Most startups use AI note-taking tools now, so you can always catch the recap later.

You only get 8 hours a day—if you spend 3–4 in meetings, who suffers? You. Until you're in a management role, your time is better spent building.

2. You’re working solo—so either follow someone’s pace or set your own
In my case, there are only two engineers—me and another teammate—and we’re on completely different projects. Some say, “Why not do pair programming?” But when you’re working on unrelated domains, pair programming isn’t realistic. You don’t know the context, the timeline, or even the requirements.

So instead of waiting for someone to hand you feedback or direction:

Do your own research
Study how other companies build similar things
Make mockups or prototypes
Use AI to review your code and give you suggestions on performance, security, and best practices

The more you prepare, the less dependent you are on others.

3. Don’t over-plan—delivery is more important
Planning is important, yes. But in startups, plans change. Requirements shift. Meetings spawn new features that weren’t even on the roadmap yesterday.

So instead of spending 70% of your time making a “perfect plan,”
→ Build what you know won’t change
→ Deliver fast
→ Get feedback early

Momentum > overdesign.

4. If you're the PIC (person in charge), debrief your team immediately
Let’s say you joined a meeting with the PM, CTO, or senior stakeholders, and you're leading the project. After the meeting, don’t delay—spend 15 minutes debriefing your team.

Why?
You represent them. If the project fails, it reflects on the whole team. The faster you sync, the more ownership your teammates can take. My ex-senior once told me:

“If it involves others, make it your first priority to align.”

That still sticks with me.

5. You won’t always get credit from the company—but always give yourself credit
Sometimes you put in 120% effort. All you get in return is a “thanks.” (In Hong Kong I’d at least get a drink 😅)

Let’s be real:

In demo meetings, people don’t always know who did what
When your senior presents the project, the credit might go to them
They might even get the bonus or promotion

But here's what matters:
You did the research.
You wrote the code.
You made the architecture decisions.

Even if no one sees it, you learned. You grew. You sharpened your instincts and built your muscle memory—and that is what truly lasts.

Startup life can look messy and chaotic from the outside. Sometimes it even has a bad reputation. But if you fix your mindset and become a proactive problem solver, you’ll realize:
💡 The more dirt you dig into, the more potential you uncover.

If you found this post helpful, feel free to follow—I'll keep sharing stories from the trenches.
And hey, do you have any lessons from startup life? I’d love to hear them 👀👇

Week in Tokyo: Startup Grind, Side Projects & Posting Routine 🧑‍💻🌱

javaskr — Mon, 30 Jun 2025 13:26:37 +0000

Hello from Tokyo 👋 it's Sunday—time for a weekly recap! 👀

This week has been a productive one:

✅ I wrapped up the login integration with an external API
🎨 Started implementing the draft design (you know the drill—startup life means we build it first, then tweak it later 😅)
📄 Currently working on the Items page and the dialog component for displaying item details
🧠 Also took time to update some parts of the existing app based on our UX/UI designer's feedback

Looking ahead to next week:

Crack the dialog component logic
Provide API design feedback to teammates
Try inserting real data from the API

Outside of work:
📱 I challenged myself to post more regularly—while I didn’t post every day, I'm slowly building a routine around sharing my thoughts
🌐 For those who noticed, yes—I have a personal blog now! It's built with Payload CMS, which I self-hosted so I can publish anytime 👨‍💻
🎓 I’ve been working through an online backend development certification on Coursera and aiming to finish Module 6 by mid-July

🤫 On the side, I’ve been helping a friend with an LLM-related project in the education space—can’t say too much yet, but it’s exciting!

🚀 Last but not least, I’ve kicked off a new side project—an upgraded version of my final bootcamp project! I’m teaming up with a friend and currently handling the backend setup using Prisma + PostgreSQL + Node MVC.

That’s all for this week—thanks for reading and see you in the next update! 🙌

Follow for more: javaskr.com

AI Won’t Replace You — But It Will Move You

javaskr — Fri, 27 Jun 2025 18:37:22 +0000

It’s Future Friday. Let’s talk about something we all keep hearing lately — AI.

Ten years ago, we never really imagined AI would end up where it is today. Now it's everywhere. Some say it’s taking over our jobs, our industries, maybe even our future.

But is that really the full story?

Jobs are changing — some faster than others
I’m not here to predict anything groundbreaking. But let’s be honest — if your job is mostly repeatable, filled with forms, or doesn't require much judgment, it’s probably at risk.

Especially in countries like Japan, where the birthrate is low, and the workforce is aging, automation isn’t optional. It’s happening already — not because we want it, but because we need it.

But here’s something people forget:

Just because a machine can do something, doesn’t mean it can do it well without help.

Human work isn’t disappearing — it’s shifting
Even if AI gets better, someone still needs to guide it, set the goals, and make sure it doesn’t go off-track.

We’re not being replaced.
We’re being moved — from doing the work to overseeing it.
That includes fixing things when they break, making judgment calls, and asking questions machines don’t even know they should ask.

AI doesn’t think — not really
People talk about “AI managing AI” or reaching the point where humans are no longer needed. But let’s be real.

AI doesn’t:

Understand human context
Catch nuance in emotion or tone
Decide right or wrong in a gray area
Wake up and go “Oops, I made a mistake. Let me fix it.”

It only knows what we tell it.
And when we give it the wrong thing? It just runs with it.

Even when tools are powerful, someone still needs to stay in the loop. Not to be in control all the time — but to be responsible.

So what now?
We can’t escape change. But we can choose how we grow with it.

The way I see it:

Don’t try to outcompete machines. Learn how to work with them.
Stay curious. Tools come and go, but mindset lasts.
And most importantly, don’t let fear stop you from moving forward.

Thanks for reading my Future Friday post.
I’ll keep sharing thoughts like this — not just about tools and tech, but how it actually affects the way we work and live.

👉 javaskr.com

Let me know how you feel about all this change. Or how you're adapting to it in your work.

Announcing My New Weekly Blog Theme Schedule

javaskr — Sat, 21 Jun 2025 14:42:07 +0000

To bring structure and consistency to my writing, I’m introducing a themed posting schedule — one topic for each day of the week. It’s a simple way to organize ideas and help readers follow along based on their interests.

📅 Weekly Themes:

🧠 Mindful Monday – Reflections, goals, or thoughts to kick off the week
💻 Tech Tuesday – Tech tools, tutorials, experiments, or insights
🛠️ Work Wednesday – Workflows, productivity, or career-related topics
🧪 Tech Thursday – Deep dives into technology, frameworks, or builds
🚀 Future Friday – Trend forecasting, predictions, and big ideas
📚 Study Saturday – Notes and learnings from courses, books, or self-study
🗂️ Summary Sunday – A wrap-up of the week or plans for the next

Feel free to follow along on any day that resonates with you.
Let’s keep learning, building, and sharing.

What’s a Software Engineer’s Daily Routine in a Tokyo Startup?

javaskr — Thu, 19 Jun 2025 18:22:18 +0000

Hey, I’m Timothy — a software engineer based in Tokyo.
If you’ve seen me post here and wonder why I keep going despite the low view count — honestly, this is part of a personal challenge. I’m building a habit of documenting my journey to understand myself better, one post at a time.

So today, I want to give you a glimpse into what my typical day looks like in a Tokyo-based startup.

I work at a company with 100% Japanese management, but around 70% of the team are international members. Meetings are bilingual — usually a mix of Japanese and English.
We work in a global rhythm, but with a Japanese sense of structure and formality.

So, what’s the daily flow like?
🧩 Daily Standups
We begin with a daily sync — sharing progress, blockers, and questions. These aren’t just status updates. They’re mini strategy sessions where we exchange ideas and solve problems live.

📝 Requirement Digestion
Once a task lands on us, we break it down. That means creating lightweight documentation, proposing timelines, and often attending meetings that only include the core members. We’re expected to debrief the rest of the team afterward.

🔁 Review & Feedback
We hold regular review meetings. These are where concerns, blockers, or hidden dependencies surface. It’s a constant loop of adjusting priorities, schedules, and scope.

🎨 Cross-functional Collab
We don’t work in silos. One feature might involve inputs from designers, feedback from seniors, and contributions from multiple engineers. A lot of my time is spent syncing with teammates on overlapping areas.

🚧 Building During the Chaos
Here’s the honest part: actual coding time is limited.
Requirements change quickly — sometimes after every meeting. So instead of waiting, I start mocking dependencies, building rough drafts based on early design files, and researching technical concerns in parallel.

🧪 Testing (When There’s Time)
In a perfect world, I’d write full unit tests and automation suites. In reality, most testing happens during QA or via functional testing in staging — especially when timelines are tight.

🚀 Deployment Crunch
Imagine this: the product’s release is in 3 months, but we only finalize requirements by week 3. That leaves about 2 weeks for development, QA, debugging, and deployment.
You get used to shipping fast — and learning fast.

TL;DR: It’s not all code
✅ Meetings
✅ Documentation
✅ Syncs & cross-functional handoffs
✅ Handling changes
✅ Very little time for deep coding

But that’s startup life — and honestly, I’ve learned a ton through the chaos.

👀 Curious about how engineers work in Tokyo startups?
I’m documenting everything — not just the polished highlights, but the in-betweens too.
If you’re into tech, international work cultures, or just like seeing how messy building things can be, follow along here or at javaskr.com.
Let’s figure it out together.