DEV Community: neitherGalax

I Contributed To a TypeScript Project Without Being a TS Dev

neitherGalax — Wed, 29 Jul 2026 07:46:31 +0000

I have contributed to open source projects before, mostly in Python and in environments and languages I am familiar with.

This time was different.

The repository was written in TypeScript, a language I had only limited experience with. I could understand the general structure, follow the logic, and get a rough picture of how things worked—but I was definitely not a TypeScript developer.

That made this contribution interesting.

Could I still make a meaningful contribution to a project when I did not fully know the language?

It started with a small bug, not a big feature

The reason I looked into this repository was actually pretty simple.

I noticed a small bug in a typing animation generator project. The generated animation was not printing as smoothly as expected, and I thought it would be a nice improvement to fix that experience.

It was not a major architectural change or a large feature request.

It was just a small issue that bothered me as a user.

That is one of the things I enjoy about open source: sometimes a contribution starts from a simple thought:

"Could this work a little better?"

So I opened an issue, described the problem, and shared my thoughts.

I expected the discussion to stay at the issue level.

Instead, the maintainer asked:

"Would you like to fix this issue?"

My reaction was simple:

"Why not?"

So I started working on it.

Learning a new codebase with AI as a companion

I used Codex throughout the process.

But the goal was not to ask AI to generate code and blindly submit it.

I used it as a learning partner:

Understanding unfamiliar TypeScript patterns
Exploring the repository structure
Discussing possible implementation approaches
Reviewing my own assumptions
Helping translate my existing engineering knowledge into a new ecosystem

AI helped reduce the friction of entering an unfamiliar codebase, but I still needed to understand the problem, make decisions, and validate the final implementation.

The contribution was not:

"I know TypeScript now."

It was:

"I understand this problem well enough to improve this project."

When AI reviewers disagreed with my implementation

After submitting the PR, I received feedback from several AI-powered code reviewers.

One suggestion caught my attention. The checker recommended changing my implementation slightly.

At first glance, the suggestion looked reasonable.

But instead of immediately accepting it, I investigated.

I discussed the feedback with Codex, reviewed the surrounding code, checked the existing tests, and looked deeper into the design intention behind the change.

After that investigation, I decided not to make the suggested change.

I explained my reasoning in the PR:

Why the original implementation matched the existing project structure
Why the suggested change was not necessary
How the tests supported the current approach

This was a small but meaningful moment.

AI review is valuable, but it is still feedback—not an automatic decision.

The responsibility of engineering judgment remains with the contributor.

The result surprised me

Eventually, the AI review passed, the maintainer approved my original implementation, and the PR was merged.

The interesting part was not that AI wrote code for me.

The interesting part was that AI helped me participate in a project where I previously would have hesitated because of the language barrier.

This experience also changed how I viewed TypeScript.

Instead of seeing it as an unfamiliar language that was "not mine," I became more interested in learning it further.

Sometimes the best way to learn a technology is not through tutorials.

Sometimes it is by trying to contribute something meaningful with it.

Open source contribution is evolving

Traditionally, contributing to a project often felt like:

"I need to already know this technology before I can help."

But that barrier is starting to change.

The important skills are becoming:

Understanding problems
Reading unfamiliar systems
Asking good questions
Validating ideas
Communicating clearly with maintainers
Knowing when to trust or challenge suggestions—including AI suggestions

The fundamentals of engineering have not changed.

We still need curiosity, judgment, and the ability to adapt.

But the tools available to us have changed.

Maybe the future open source contributor is not someone who knows every language.

Maybe it is someone who can continuously learn, collaborate, and contribute—even when stepping into unfamiliar territory.

Have you ever contributed to a project outside your main programming language or comfort zone?

Transparency Note: I used AI as an editor—not as the author. For this article, it helped refine the structure and improve the English grammar. The technical content, experiments, opinions, and conclusions are my own and were reviewed by me before publishing.

How Will We Become Open Source Contributors In an AI-Assisted World? -The OSS Toolkit

neitherGalax — Fri, 17 Jul 2026 20:53:00 +0000

Open source contribution has never been just about writing code.

As AI changes how we build software, how will contribution change too?

I've been thinking about this question a lot recently. The pull request I opened to add AI-assisted contribution guidance to GitHub's open source guides was recently merged😆, and around the same time, I was building my own OSS Contribution Toolkit on GitHub.

Both experiences made me reflect on how quickly open source contribution is evolving.

My First Open Source Contribution Experience

When I first started exploring open source, I often felt intimidated by the contribution process.

The challenge wasn't always writing the code. It was understanding how each project worked.

Every repository seemed to have its own workflows, expectations, and unwritten rules. On top of that, I had a bit of

Git Anxiety

the fear of making a mistake with branches, commits, or pull requests in someone else's project.

Even today, that feeling hasn't completely disappeared. Every open source project is different, and there's always a learning curve before making a meaningful contribution.

Looking back, I realized that contributing to open source has never been just about writing code.

The Current State of Open Source Contribution

As I contributed to more projects, I realized this wasn't unique to my experience.

Open source projects naturally evolve their own contribution workflows over time. Guidance is often spread across README files, CONTRIBUTING guides, issue and pull request templates, GitHub Actions, and other automation tools. These expectations continue to evolve as projects grow and maintainers refine their processes.

As a result, every project has its own conventions and contribution patterns.

For contributors—especially those just getting started—understanding the contribution process can sometimes take more effort than understanding the code itself.

In many ways, contributing to open source is about learning the project's context before writing the first line of code.

Why I Built an OSS Contribution Toolkit

This realization motivated me to build an OSS Contribution Toolkit.

The goal isn't to replace project-specific documentation or workflows. Every open source project is unique and diverse, and contributors should always follow each project's own guidelines.

Instead, I wanted to collect common contribution patterns, workflows, and lessons learned from real-world contributions into a practical resource.

My hope is that contributors can spend less time figuring out how to contribute and more time making meaningful contributions.

Like open source itself, this toolkit will continue to evolve. As projects adopt new practices and AI-assisted workflows become more common, I plan to keep it updated to reflect how open source contribution continues to change.

Looking Ahead

As AI-assisted development continues to evolve, I can't help but wonder how open source contribution will evolve alongside it.

Today, AI can already help us write code, explain unfamiliar repositories, generate tests, draft documentations, and even create pull requests.

Perhaps the next step isn't just helping us write better code, but helping us become better contributors.

Understanding:

a project's context
workflows
collaboration patterns

will likely remain an essential part of open source.

The tools may change, but meaningful contribution is still about working effectively with both the code and community of developers.

I am excited to see where open source goes next, and I hope this toolkit can evolve alongside it.

Now I'm curious—What do you think open source contribution will look like in the next few years?

🔗OSS Contribution Toolkit Repo

Transparency Note: I used AI as an editor—not as the author. For this article, it helped refine the structure and improve the English grammar. The technical content, experiments, opinions, and conclusions are my own and were reviewed by me before publishing.

I Rolled Back My MCP Skills Experiment. Here's What I Learned

neitherGalax — Wed, 08 Jul 2026 19:23:15 +0000

TL;DR
I introduced a SKILL layer while improving fare extraction in a MCP-based transit agent. After that, the agent stopped reliably using the MCP tool and started favoring web search, breaking real-time accuracy. I rolled back to a stable baseline, reintroduced SKILL more carefully, and restored MCP tool usage.

After the last post, the system felt stable.

The MCP-based transit agent was working. Fare retrieval was consistent, routes were predictable, and tool calls behaved the way I expected. It felt like I had finally reached a baseline I could build on.

Then I started iterating again.

The goal was still narrow. I was trying to improve fare extraction for more complex routes. Before introducing any new abstraction, I actually modified the MCP tool itself. I adjusted parts of the parsing logic to better handle complex route structures.

That change alone did not break anything immediately, but it shifted the foundation slightly.

After that, I introduced a SKILL layer to structure how the agent should use MCP tools. At the time, it felt like a logical next step. The idea was to make tool usage more consistent and less dependent on implicit behavior from the agent.

Nothing broke immediately. The system still ran, responses still came back, and at a glance everything looked fine.

But I had effectively changed two layers that depend on each other without fully understanding how they would interact.

The Failure Signal (What Broke)

The first sign was not an error.

It was a shift in where answers were coming from.

The agent started relying on backup web search instead of the MCP transit tool. This was not limited to fare extraction. Even for basic transit queries, the MCP tool was no longer being used, and the responses were coming from general web-based results instead of real-time transit data.

I tried to correct it at the SKILL layer.

I adjusted the instructions, made the tool usage more explicit, and expected the behavior to shift back. But the pattern stayed the same. The agent continued to avoid the MCP tool, even when the intent clearly required real-time transit information.

That is when it became obvious that the output was no longer grounded in the system I built. It was producing responses, but not based on the real-time transit pipeline anymore.

The Point of Uncertainty (And My Frustration)

At this point, I did not know which layer was responsible.

The MCP tool still worked when called directly. The SKILL layer still looked correct in isolation. Even the parsing changes I had made earlier did not clearly explain the behavior I was seeing.

But the system behavior told a different story.

The agent consistently avoided the MCP tool, and even adjustments in the SKILL instructions did not change that. It kept producing answers that were not grounded in real-time transit data.

It felt less like a single bug and more like a breakdown in coordination between layers that were supposed to work together.

The Rollback and What Changed

At this point, I stopped trying to patch it.

Nothing I changed was bringing the MCP tool back in consistent use anymore. The agent was still bypassing it, and the output was still not grounded in real-time transit data. The SKILL layer had not improved control, and it made the behavior harder to reason about.

So, I rolled everything back to v0.1.1

That meant returning to the simpler parsing logic in the MCP tool and removing the expanded SKILL-driven behavior. I wanted a baseline where I already knew the system behaved correctly.

Then, I reintroduced SKILL, but only in a minimal form, closer to the original intent rather than an orchestration layer that tried to do too much.

After testing again, the behavior stabilized.

The agent started using the MCP tool reliably again. Fare retrieval worked. Even some complex routing cases began working better than before.

It is not fully perfect. There are still edge cases that break. But compared to everything before this point, it is in a much more stable state.

My working hypothesis is that the regression was not in the MCP server itself, but somewhere in the interaction between the SKILL layer, tool selection, and my parsing changes.

This is still something I am iterating on.

What I learned from this round is that SKILL only behaves well when it stays close to orchestration. Once it starts influencing tool selection too strongly, it becomes harder to predict how the agent will actually behave.

This is the version I ended up tagging.

Closing Insight

I think the issue was not the MCP tool itself. It was how additional layers influenced when it got used. SKILL is not a system prompt replacement, but an orchestration layer that can unintentionally affect tool selection. In my case, that interaction changed the agent's routing behavior in subtle ways.

Rolling back restored a simpler, more predictable decision path, which is why the system stabilized again.

For More Info About This Project

🔗GitHub Finish-Up-A-Thon Challenge post

🔗GitHub Repo

Transparency Note: I used AI as an editor, not as the author. For this article, it helped refine the structure and improve the English grammar. The technical content, experiments, opinions, and conclusions are my own and were reviewed by me before publishing.

🦩OS June Recap: Reviewing PRs was my biggest milestone

neitherGalax — Tue, 30 Jun 2026 23:58:01 +0000

June was not about making the most contributions -- it was about becoming a better collaborator.

This month I had:

✅ 1 PR merged
🔄 1 PR still open
👀 3 PR reviews completed
🐞 1 issue opened

I am making this graph all green...

Biggest Learning

The biggest milestone wasn't writing code. It was reviewing pull requests.
One review led the author to update their PR based on my feedback. That experience taught me that open source isn't just about contributing code; it's also about helping improve someone else's work through discussion and constructive feedback.

Working Alongside AI Reviewers

I also had an interesting experience interacting with automated reviewers like Vercel Bot and Copilot. Rather than accepting every suggestion, I tested them, evaluated the trade-offs, and explained why I chose a different approach. It was a good reminder that AI can assist reviews, but engineering judgement still matters.

Looking Ahead

My biggest challenge is still finding a larger project that I can consistently contribute to over the long term. That's my main goal for July, alongside publishing my OSS Contribution Toolkit repo and making my CaaS project usable for others.

Small, consistent steps continue to move the journey forward.

What was your biggest open source learning in June?

Your README Is More Than Documentation

neitherGalax — Sun, 28 Jun 2026 23:45:31 +0000

TL;DR: Your README isn't just documentation. It's your project's first user experience. A clear README helps people understand, trust, and start using your project faster.

Most open source projects don't fail because of bad code.

A few years ago, I thought a good project would naturally attract users if the code was solid enough.

I was wrong.

One of the turning points for me came while contributing to an open-source Python-based project. The project itself was genuinely impressive, with a well-designed codebase and useful API functionality. But when I looked at the repo, I noticed it lacked even a basic README that clearly explained what the project did or how to get started.

I ended up contributing suggestions and improvements to help make the README more welcoming and easier for newcomers to understand. That experience made me realize something: even great software can be overlooked if people don't immediately understand its value.

I've seen polished repos go unused, while simpler projects quickly gained traction. The difference wasn't always the code.

It was the README.

Before anyone reviews your project, opens an issue, or installs your project, they make a decision:

Is this worth my time?

That decision often happens within seconds of landing on a repo.

Most visitors won't read every section. They scan. They look for signals.

What problem does this solve?
Can I trust it?

A README isn't just documentation. It's the first experience someone has with your project.

And sometimes, it's the reason they stay, or leave.

A `README` Is a Decision Layer

For a long time, I viewed READMEs as documentation.

A place to explain features, installation steps, and technical details.

But after contributing to more open-source projects, I started seeing them differently.

People visit repositories with different goals.

Some want to solve a problem. Some want to contribute. Others are simply exploring whether a project is worth trying.

But regardless of why they arrive, they are usually looking for the same thing first:

Clarity.

What does this project do?
Is it actively maintained?
Can I get started without digging through the source code?

A good README answers those questions quickly and helps visitors decide what they can do next.

That's why I think the best READMEs are not reference materials. They are decision-making aids.

Three Mental Shifts That Changed How I Write `README`s

Over time, I stopped thinking about READMEs as documentation and started thinking about them as part of the developer experience.

A few mental shifts helped me get there.

1. A `README` is not a manual

When you land on a repository, would you be willing to read everything? The answer is likely NO.

You want to understand the project quickly.

The goal of a README isn't to explain every detail. It is to help visitors understand what the project does and how to take the next step.

2. Clarity beats completeness

I used to think a good README needed to cover everything.
Now I think the opposite.

A short explanation that gets people started is often more valuable than a long document that tries to answer every possible question. Hence, the "Quick Start" section is valuable in the README.

You can always create additional docs/ later.

3. The first minute matters most

Many maintainers spend a lot of time documenting advanced features. But most visitors are still trying to answer basic questions.

What problem does this solve?
How do I run it?
Why should I care about this project?

If those answers aren't obvious within the first minute, many people will simply move on to other projects.

The `README` Paradox

One thing I've noticed is that writing a better README isn't about writing more.

In fact, the more technical and comprehensive a README becomes, the harder it can be for newcomers to get started.

Too little information leaves people confused.

Too much information overwhelms them.

The sweet spot is somewhere in the middle: enough context to build confidence, and enough guidance to take the first step.

The README should NOT answer every question. It should make people want to keep reading.

Think of Your `README` as a User Interface

This idea changed how I approach documentation.

When someone visits your repository, your README becomes the interface they interact with first.

The title should immediately tell them what the project is. The Quick Start should help them get running with as little friction as possible. Examples should show what success looks like. Everything else can guide them deeper into the project.

A good user interface helps people accomplish a task without making them think too much.

I think a good README should do the same.

The Invisible Cost of a Bad `README`

A weak README doesn't just make a project look unfinished.

It creates invisible work.

Maintainers end up answering the same questions in issues and discussions. New contributors quietly leave because they aren't sure where to begin. Useful projects can feel much harder than they actually are.

A good README isn't just documentation.

It's an investment that saves time—for both you and everyone who visits your repository.

The 30-Second `README` Test

Before you publish your next project, try this.

Imagine someone has never seen your repository before.

Within 30 seconds, can they answer these questions?

What problem does this project solve?
How do I get started?
Where do I go if I want to learn more?

If the answer is YES to all questions, your README is probably doing its job. If not, your code may deserve a better first impression.

Looking Back at My Own `README`

Writing this post also made me reflect on one of my projects and its README: the Tokyo Transit MCP Server repo (v0.1.3).

Looking back, I realized I've made the same mistake I am writing about.

The README spends quite a bit of time explaining the project's status, data migration progress, and even introducing what MCP is before readers ever reach the "how it works" or installation sections.

While that context is useful, I don't think it belongs at the very beginning.

If someone lands on the repository for the first time, they probably want to know 3 things.

What does this project do?
Why should I use it?
How do I get started?

Everything else can come later.

That's a change I plan to make, not because the information is wrong, but because the first user experience can be better.

Final Thoughts

The more I contribute to open source, the more I realize that README isn't just documentation.

It's the first conversation your project has with the next developer.

I am still learning how to write better READMEs myself, and now I am curious about your experience.

Have you ever revisited an old README and realized it wasn't telling the story you wanted it to tell?

Or what's one thing you've learned that made your READMEs better?

I'd love to hear your thoughts in the comments.

Transparency Note: I used AI as an editor, not as the author. For this article, it helped refine the structure and improve the English grammar. The technical content, experiments, opinions, and conclusions are my own and were reviewed by me before publishing.

When Your Pull Request Has More AI Reviewers Than Humans

neitherGalax — Mon, 15 Jun 2026 22:11:38 +0000

Recently, I submitted a pull request to a project and had an experience that felt very different from the usual OSS workflow in the past.

Instead of the typical back-and-forth with a human maintainer, most of the interaction in my PR came from automated systems: Copilot suggestions, Vercel-related checks, and CI-driven review comments. The maintainer eventually approved the PR with minimal direct discussion, and it was merged successfully.

What stood out to me wasn't just that the PR got merged, but how the review process felt distributed across multiple non-human participants.

A different kind of PR conversation

In this case, I found myself responding to:

Copilot-style suggestions embedded in the workflow
Automated review comments triggered by code changes
Vercel’s deployment feedback loop during preview builds
CI checks acting as silent gatekeepers

It wasn’t one reviewer giving feedback—it was a collection of systems continuously reacting to changes. At times, it honestly felt like maintaining a conversation with multiple tools rather than collaborating with a single maintainer.

The maintainer's role felt different

What stood out most was how little direct back-and-forth there was with the maintainer during the process. Instead, it felt more like the automation handled the detailed feedback loop, which is pointing out issues, validating fixes, and checking consistency, while the maintainer stepped in later to look at the overall direction and give the final approval.

So, the human part wasn't really about line-by-line discussion. It was more like a final layer of judgment once everything else had already settled.

At that point, it made me wonder, are we already moving toward a setup where the human role becomes mostly invisible during the process, only stepping in at the end to hit "approve"?

Open questions for the community

I’m curious how you are experiencing this shift:

How do you feel about AI-assisted PR reviews on either side (maintainer or contributor)?
Have you noticed a change in the depth or tone of discussions in your repositories?
Do you think human review is becoming lighter, or just differently focused?
Where do you personally draw the line between “useful automation” and “loss of human context”?

It feels like we are entering a phase where PRs (and maybe issues as well) are no longer human-to-human conversations, but hybrid interactions between devs, bots, and CI systems. And I am not fully sure yet whether that's a net positive or just a new normal.

I Thought Open Source Was About Code. I Was Wrong.

neitherGalax — Wed, 10 Jun 2026 21:48:59 +0000

The biggest lessons I learned from open source contributions weren't found in the code itself. Communication, collaboration, and workflows matter more than I expected.

For a long time, I hesitated to contribute to open source.

Part of it was because I assumed that contributing meant writing code. As a self-taught developer, that felt intimidating. The other part was "Git anxiety." Forks, branches, pull requests, merge conflicts, and CI checks all seemed like a lot to understand before I could even make a contribution.

Eventually, I started small. Instead of focusing on code, I looked for opportunities to improve documentation, README files, and learning materials. What surprised me was that writing the actual change was often the easy part.

Most of my learning happened outside the code itself: understanding contribution guidelines, repository workflows, automation, and review expectations. Over time, I realized that modern open source contribution is about much more than just writing code.

Contribution Model Has Changed

When many people think about open source contributions, the mental model is still fairly simple:

Find Bug
 ↓ 
Write Code
 ↓ 
Open PR

In reality, I realized that most modern repos involve much more than that.

Before making a change, contributors often need to understand project workflows, CI pipelines, automated checks, contribution guidelines, and review expectations. The code change itself might only take a few minutes, while understanding how the repo operates can take much longer.

A modern contribution often looks more like this:

Understand Repository 
↓ 
Understand Workflow 
↓ 
Understand Automation 
↓ 
Make Change 
↓ 
Open PR 
↓ 
Respond to Review

It looks intimidating, but I think this flow helps projects stay maintainable as communications grow.

What I've learned from contributing to different projects is that open source is not just a coding skill.

It's also a collaboration skill.

The faster you can understand how a project works, the easier it becomes to contribute regardless of the tech stack.

The Subtle Rules of Open Source Contribution

Most repos do a great job documenting their contribution process. README files, CONTRIBUTING guides, issue templates, and PR templates usually explain the basics.

What took me longer to understand were the expectations that aren't always captured in a single document.

For example, maintainers may prefer smaller pull requests even if they don't explicitly say so. A repository may technically accept feature contributions, but recent activity might show that documentation improvements receive faster reviews. Some projects expect contributors to discuss ideas before opening a PR, while others prefer contributors to jump in and submit changes directly.

I've also learned that automation often communicates expectations. GitHub Actions, CI pipelines, and pre-commit hooks don't just validate code—they reveal what a project values. Formatting standards, test coverage, commit conventions, and quality checks are often enforced automatically rather than explained in detail.

Over time, I stopped looking for a single source of truth. Instead, I started treating a repo as a collection of signals. The documentation tells us the official process, while the project's workflows, automation, and recent Pull Requests often show how the project actually operates day to day.

Why Beginners (Including Myself) Feel Overwhelmed

When people talked about contributing to open source when I started to use GitHub, they often focused on learning Git. But looking back, Git wasn't the hardest part for me.

The challenge was learning several systems at the same time:

Git
GitHub
CI Pipelines
automated checks
code review workflows
etc.

A simple documentation fix requires creating a fork, opening a PR, passing automated checks, and responding to review feedback. Even when the change itself is small, the process can feel overwhelming at first.

What helped me was realizing that mistakes are expected.

A failed CI check, a requested revision (often by AI nowadays), or a rejected idea isn't a sign that you don't belong in the Open Source. They are simply part of how collaborative software development works.

Once I stopped viewing contributions as a test and started viewing them as a learning process, open source became much less intimidating.

What I Look For Before Contributing Now

After contributing to different projects from big to small, I've developed a simple checklist before opening an issue or PR.

Is the project actively maintained?
What types of contributions are welcomed?
How are recent PRs reviewed?
What do the CI checks and automation enforce?
Are there contribution guidelines or coding standards?
What contribution patterns do maintainers seem to prefer?

None of these requires deep technical knowledge, but they can save a lot of time and confusion.

I've found that spending at least 10-20 minutes understanding a repo often leads to a smoother contribution experience than jumping straight into making or suggesting changes.

Final Thoughts

Soft Skills Matter in the Age of AI

Every open source project is different and diverse, but after contributing across multiple repos, I've noticed that many share similar patterns beneath the surface.

The code still matters, of course. But successful contributions often depend just as much on understanding workflows, automation, collaboration practices, and communication skills. Writing clear comments, participating in discussions, and developing strong soft skills can be just as important as writing code for working effectively with maintainers and contributors.

For me, one of the biggest lessons from open source has been that contributing isn't only about writing code—it's about learning how to work effectively within a community. Once I started viewing repositories through that lens, contributing became much less intimidating and much more rewarding.

One Commit A Day

If you're interested in building a sustainable open source habit, I've been documenting my own journey through a One Commit a Day challenge. The goal isn't to make a massive contribution every day—it's simply to stay engaged, keep learning, and gradually become more comfortable navigating open source projects and communities.

From Prompt Engineering to MCP Skills: What Rebuilding My Tokyo Transit Agent Taught Me About AI Architecture

neitherGalax — Thu, 04 Jun 2026 17:59:00 +0000

A recent comment on one of my dev.to posts asked a simple but insightful question:

What specifically was breaking before MCP: context loss between agents, or tool-call inconsistency?

At first, I thought the answer would be straightforward.

But after reflecting on my Tokyo Transit project, I realized the real issue wasn't either of those things.

The project has gone through three major iterations over the past year, and each version reflects a different stage in my understanding of AI agents, orchestration, and system architecture.

Looking back, the project became a timeline of how the AI ecosystem itself has evolved.

Version 1: SmolAgents and the "Big System Prompt" Era

The first version was built with SmolAgents.

Like many developers experimenting with agents at the time, I believed that if I wrote a sufficiently detailed system prompt, the agent would behave consistently.

As the project grew, the prompt grew with it.

More instructions.

More formatting rules.

More edge cases.

More exceptions.

Eventually, the system prompt became the primary mechanism for controlling behavior.

The result was predictable: the agent worked sometimes, but not reliably.

The biggest problem wasn't context loss between agents.

It wasn't tool-call failures either.

The real problem was prompt alignment.

I was trying to manage architecture through instructions.

Version 2: Google ADK and Higher-Level Abstractions

My next experiment used Google ADK.

Compared to the first version, ADK provided a high-level, cleaner, and more structured framework for agent development.

Many orchestration concerns were abstracted away.

This made development faster and reduced some of the complexity I had been manually managing.

But it also taught me something important:

Frameworks can simplify development, but they don't automatically solve architectural problems.

I still needed a clear way to define responsibilities, manage behavior, and structure agent workflows.

Version 3: MCP and Skill-Based Design

The current version uses the MCP Python SDK together with Skill-based design.

This was the point where the project finally started to feel maintainable.

Instead of pushing more logic into a growing system prompt, I could separate capabilities into tools and skills with clearly defined responsibilities.

MCP wasn't magical.

It didn't suddenly make the agent smarter.

What it provided was structure.

Skills gave me a dedicated place for behavioral instructions.

MCP provided a consistent interface for tools.

Together, they made the system easier to reason about, test, and improve.

So What Was Actually Breaking Before MCP?

Looking back, the biggest issue wasn't context loss or tool-call inconsistency.

It was architectural drift.

Whenever the agent behaved incorrectly, my solution was usually to add another instruction to the system prompt.

Over time, the prompt became harder to maintain and reason about.

The more complexity I added, the less predictable the behavior became.

In hindsight, I was trying to solve an architecture problem with prompt engineering.

Final Thoughts

The Tokyo Transit project is still under active development.

There are bugs to fix, improvements to make, and plenty left to learn.

But the most valuable outcome wasn't the transit tool itself.

It was seeing how my approach changed over time:

From large system prompts
To higher-level agent frameworks
To MCP and Skill-based architecture

The project became a record of my own learning journey as AI agents evolved from experiments into systems that can be structured, maintained, and improved over time.

If you've been building with agents, MCP, or AI frameworks, I'm curious: what was the biggest lesson that changed the way you design your systems? Feel free to share your experience in the comments below.

🌐OS May Recap: Learning to Navigate the Open-Source Galactica

neitherGalax — Sun, 31 May 2026 21:48:09 +0000

In May, I continued my "One Commit a Day" Challenge and spent more time contributing across different open-source projects.

Compared to April, I was able to contribute a bit more and explore a wider variety of repositories.

Repositories That Stood Out

Some of the projects that left the biggest impression on me were:

python-odpt
Huggin Face Context Course
Human Signal ML
ScribeSVG

A Stable Checkpoint

One milestone I was happy about this month was reaching a stable checkpoint for my Tokyo MCP Server project.

It is still a work in progress, but getting to a point where the project feels stable enough to build upon was a satisfying moment.

Documentation Matters

Another contribution that stood out was helping improve a python-odpt README documentation.

It wasn't a large technical contribution, but it reminded me that making a project easier for others to understand can be just as valuable as writing code.

Good documentation lowers the barrier for future contributors. Sometimes, a clearer README can help more people than a small code change.

Learning Beyond Python

One practical lesson I learned this month was that being a Python-focused contributor doesn't mean I can ignore the JavaScript ecosystem.

While working with different repositories, I finally installed Node.js and started using npm. Many modern open-source projects rely on TypeScript-based tooling, build systems, or development workflows, and understanding those tools makes contributing much easier.

The Biggest Challenge: Finding Information

And Communication Matters

The biggest challenge I faced wasn't coding.

It was documentation.

Every repository has its own way of organizing information. There are definitely common patterns, but every project also develops its own style over time.

Sometimes the information I need is in the README.

Sometimes it's in a wiki.

Sometimes it's buried in a docs folder several levels deep.

And sometimes it's spread across all three.

Open Source Is Also About Navigation

As a contributor, I've realized that one of the most important skills is learning how to navigate an unfamiliar project.

Before writing code, you need to understand how the maintainers think about the project itself.

The longer I participate in open source, the more I see that contributing isn't just about solving technical problems.

It's also about learning to read unfamiliar systems, understand other people's decisions, and become comfortable working in new environments.

Looking Ahead to June

For June,

I want to spend more time understanding a project's structure and documentation before jumping into contributions.
I also want to keep focusing on consistency rather than trying to contribute everywhere at once.

One commit a day still feels like the right pace.

Tokyo Transit: How MCP Helped Me Fix a Broken Multi-Agent System

neitherGalax — Sat, 30 May 2026 23:22:50 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Tokyo’s train system is incredible—but it can also be overwhelming. Multiple rail operators, dense transfer stations, and complicated route decisions make even simple trips confusing, especially for visitors.

There are already transit apps out there, but most still feel static. They give information, but they don’t really reason through the trip experience. Some even lock basic features behind paywalls.

That pushed me to build something different.

I built Tokyo Transportation MCP, an AI-powered transit assistant that uses MCP and skill-based agent workflows to retrieve and organize Tokyo transit information in a more natural, conversational way.

Instead of jumping between maps and apps, users can ask questions like “What’s the best route from Shinjuku to Maihama?” and receive clear, practical guidance with transfers, timing, and routing context.

More than just route calculation, the project is about making one of the world’s most complex transit systems feel easier to understand through AI agents.

Demo

🔗Repo: Link

Baseline Prompt

Transfer-Heavy Prompt

Ambiguous Prompt

Time-Sensitive Prompt

Alias Prompt

The Comeback Story

This project actually started much earlier as a simple Tokyo transportation agent.

At the time, I was experimenting with early multi-agent workflows and system prompting with the Hugging Face ecosystem. But honestly, the tooling and orchestration patterns were still under development, and I struggled to make the agents behave reliably. The system worked sometimes, but not consistently enough to feel usable.

Eventually, I shelved the project.

Later on, after learning more about MCP architecture and Skill-based systems, I realized I finally had a cleaner way to structure the idea. Instead of forcing complex orchestration too early, I rebuilt the project around modular skills, clearer agent behavior, and more reliable transit retrieval workflows.

What started as an abandoned experiment slowly turned into a much more practical and stable AI transit assistant.

The project is still under active development, and there are plenty of improvements and edge cases left to tackle. But reaching the point where it functions as a stable MCP-powered transit tool feels like a meaningful milestone.

My Experience with GitHub Copilot

GitHub Copilot helped speed up the rebuild, especially when I moved toward MCP and Skill-based design.

A big part of this project wasn’t just coding — it was designing Skill.md, the instruction layer that defines how the agent should behave and interpret transit tasks. Getting that right required a lot of iteration.

Copilot was useful for scaffolding the MCP tool code and exploring different implementation ideas. It made early prototyping much faster.

From there, the focus shifted to refinement: tightening instructions, adjusting structure, and iterating until the agent behaved consistently in real scenarios.

🌸OS April Recap: What My Daily Commit Challenge Taught Me About Open Source “Culture”

neitherGalax — Mon, 25 May 2026 00:44:37 +0000

In April, while continuing my “1 Commit a Day” challenge, I submitted several pull requests to different open-source repositories.

The results were:

3 PRs submitted
1 PR merged
Contributions involving bug fixes and test updates.

Some of the repositories that left the biggest impression on me were:

Label Studio ML
MCP Python SDK
Hugging Face MCP Course Material

One thing I’ve been realizing recently is that open source is not just a place to write code.

Every repository has its own culture, workflow, and communication style.

For example, while contributing documentation to the MCP Python SDK repository, I initially struggled quite a bit with the pre-commit checks.

At first, I didn’t fully understand what was causing the errors, so I opened an Issue about the problem. The maintainer responded that I should not open an Issue like that since it was directly related to my PR.

At the time, I was a bit confused because no additional explanation was given, but looking back, I realized that discussions closely tied to a PR are generally expected to stay within the PR conversation itself.

Looking back, that makes complete sense.

Keeping the discussion connected to the PR preserves context and makes things easier for maintainers to manage.

It was a small interaction, but it taught me something important:
In OSS, communication is just as important as technical skill.

I also gained a much better understanding of what pre-commit actually does.

Before this, I mostly thought of it as “something that automatically runs checks before commits.” But through the contribution process, I started to understand how it helps maintain:

code style
formatting
linting
overall project quality

When I first started my daily commit challenge, my goal was simply:
“stay consistent.”

But recently, I’ve started enjoying something else:
slowly learning how different OSS communities work and how real collaborative development happens.

My goal next month (May) is to increase my Level 3 contributions and continue improving both technically and collaboratively.

One thing I’m learning is that contributing to open source is not only about writing code — it’s also about learning how to work with people, processes, and project culture.

AI Is Becoming Ambient: My Biggest Takeaway From Google I/O 2026

neitherGalax — Fri, 22 May 2026 00:12:02 +0000

This is a submission for the Google I/O Writing Challenge

I spent some time watching the Google I/O 2026 “What’s New in AI” session, and one small detail personally stood out to me.

One of the presenters was Paige Bailey. Years ago, I used to watch her GenAI workshops on Kaggle while learning AI on my own. Seeing her present at Google I/O felt like a reminder of how quickly this space has evolved.

But beyond the announcements themselves, I think the biggest message from Google I/O was this:

AI is no longer being treated as a standalone product.
It’s becoming ambient infrastructure.

AI is becoming ambient

What stood out to me most was how deeply AI is now integrated across Google’s ecosystem.

Search, Workspace, Android, Chrome, YouTube, developer tools — AI is quietly being embedded everywhere.

Not as a separate chatbot tab, but as an invisible layer sitting behind the products people already use every day.

AI is becoming ambient.

Multimodal AI is becoming the default

Another thing that stood out was how natural multimodal interaction now feels.

Text, voice, images, video, screen understanding, and real-time context are all starting to blend together into a single experience.

Instead of switching between different tools, the AI increasingly understands multiple forms of input at once.

That feels like a major UX shift.

The Shift Toward “Agentic” AI

Another word that repeatedly appeared during the presentations was “agentic.”

The industry is clearly moving away from AI that simply answers questions toward AI that can actually perform tasks, make decisions, and operate across tools.

That shift feels important.

The conversation is no longer:

“Can AI chat with you?”

Now it’s:

“Can AI do things for you?”

Google Search is long gone

One thing became very obvious during the demos:

The old version of Google Search is quietly disappearing.

Typing keywords and manually digging through links is slowly being replaced by AI-generated summaries, conversational search, and agents that help organize information for you.

Whether that change is good or bad is still open for debate, especially for creators and websites across the internet.

But the direction feels clear.

Comparing Google with OpenAI and Anthropic

What’s interesting is how differently each company seems to be approaching AI.

Google still feels strongest in consumer AI momentum and product experience.

It has built a strong reputation around reasoning quality and safety-focused systems.

But it may have the biggest advantage in ecosystem integration.

Google already owns platforms used by billions of people daily:

Search
Android
YouTube
Chrome
Workspace

That means AI can spread across everyday life extremely fast.

And after watching Google I/O, it feels like that’s exactly where things are heading.

DEV Community: neitherGalax

I Contributed To a TypeScript Project Without Being a TS Dev

It started with a small bug, not a big feature

Learning a new codebase with AI as a companion

When AI reviewers disagreed with my implementation

The result surprised me

Open source contribution is evolving

How Will We Become Open Source Contributors In an AI-Assisted World? -The OSS Toolkit

My First Open Source Contribution Experience

Git Anxiety

the fear of making a mistake with branches, commits, or pull requests in someone else's project.

The Current State of Open Source Contribution

Why I Built an OSS Contribution Toolkit

Looking Ahead

I Rolled Back My MCP Skills Experiment. Here's What I Learned

The Failure Signal (What Broke)

The Point of Uncertainty (And My Frustration)

The Rollback and What Changed

Closing Insight

For More Info About This Project

🦩OS June Recap: Reviewing PRs was my biggest milestone

This month I had:

Biggest Learning

Working Alongside AI Reviewers

Looking Ahead

Your README Is More Than Documentation

Most open source projects don't fail because of bad code.

I was wrong.

A README Is a Decision Layer

Clarity.

Three Mental Shifts That Changed How I Write READMEs

1. A README is not a manual

2. Clarity beats completeness

3. The first minute matters most

The README Paradox

Think of Your README as a User Interface

The Invisible Cost of a Bad README

The 30-Second README Test

Looking Back at My Own README

Final Thoughts

When Your Pull Request Has More AI Reviewers Than Humans

A different kind of PR conversation

The maintainer's role felt different

Open questions for the community

I Thought Open Source Was About Code. I Was Wrong.

For a long time, I hesitated to contribute to open source.

Contribution Model Has Changed

It's also a collaboration skill.

The Subtle Rules of Open Source Contribution

Why Beginners (Including Myself) Feel Overwhelmed

What helped me was realizing that mistakes are expected.

What I Look For Before Contributing Now

Final Thoughts

Soft Skills Matter in the Age of AI

One Commit A Day

From Prompt Engineering to MCP Skills: What Rebuilding My Tokyo Transit Agent Taught Me About AI Architecture

Version 1: SmolAgents and the "Big System Prompt" Era

Version 2: Google ADK and Higher-Level Abstractions

Version 3: MCP and Skill-Based Design

So What Was Actually Breaking Before MCP?

Final Thoughts

🌐OS May Recap: Learning to Navigate the Open-Source Galactica

Repositories That Stood Out

A Stable Checkpoint

Documentation Matters

Learning Beyond Python

The Biggest Challenge: Finding Information

Open Source Is Also About Navigation

Looking Ahead to June

Tokyo Transit: How MCP Helped Me Fix a Broken Multi-Agent System

What I Built

Demo

Baseline Prompt

Transfer-Heavy Prompt

Ambiguous Prompt

Time-Sensitive Prompt

Alias Prompt

The Comeback Story

My Experience with GitHub Copilot

🌸OS April Recap: What My Daily Commit Challenge Taught Me About Open Source “Culture”

A `README` Is a Decision Layer

Three Mental Shifts That Changed How I Write `README`s

1. A `README` is not a manual

The `README` Paradox

Think of Your `README` as a User Interface

The Invisible Cost of a Bad `README`

The 30-Second `README` Test

Looking Back at My Own `README`