DEV Community: neither galax

When Your Pull Request Has More AI Reviewers Than Humans

neither galax — 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.

neither galax — 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

neither galax — 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

neither galax — 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

neither galax — 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”

neither galax — 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

neither galax — 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.

🌱One Commit at a Time -- My Open Source Journey

neither galax — Tue, 19 May 2026 18:55:21 +0000

For the last two months, I’ve been showing up to open source every single day.

Not because I’m an expert.
Not because I already know everything.
And definitely not because every contribution is impressive.

I started this challenge on April 1st with one simple rule:

Contribute to open source every day for 1 year

That's it.

Some days it’s a pull request.
Some days it’s documentation.
Some days it’s reviewing code, helping discussions, fixing typos, testing things, or simply learning a codebase deeply enough to leave a useful comment.

The goal isn’t perfection.

The goal is consistency.

Why I Started This Challenge

I’m a self-taught developer learning AI, engineering, and open source through real-world building and collaboration.

Over time, I noticed a pattern in how I approached open source and contributing. Even after using GitHub for around five years, I still had what I can only describe as “git anxiety” — hesitation around commits, branches, and contributing in unfamiliar repositories. Not because I didn’t understand the tools, but because I hadn’t built enough repetition for them to feel natural.

My contribution history also reflected that. For years, it was inconsistent — periods of activity followed by long gaps. That stop-and-go pattern made it harder to build confidence, momentum, or a real sense of progress.

At the same time, I had a clear long-term goal:
getting involved in a major open source project.

To get there, I realized I needed more than just technical knowledge. I needed comfort with the workflow itself — Git, collaboration patterns, reviews, and the daily rhythm of real projects.

I also noticed something more general about how people approach open source, myself included: there’s often a belief that we need to “be ready first” before contributing.

"I need to become better first."
"I need to understand the entire codebase."
"I need to build something significant before I start."

But open source rarely works like that.

The people who grow in these spaces are usually the ones who stay present — consistently showing up, even in small ways.

So instead of waiting for a perfect moment or chasing large contributions immediately, I decided to shift my focus entirely toward building a habit:

show up daily, contribute publicly, and learn in the open.

I want to paint my contribution graph into all green this year...

What Counts as a Contribution?

A contribution doesn’t always mean shipping a major feature.

For this challenge, I define contribution broadly:

Writing or improving documentation
Reviewing pull requests
Opening issues
Participating in discussions
Reproducing bugs
Improving examples
Learning and documenting insights publicly
Working on my own repositories
Supporting community conversations

Even small actions help projects move forward.

And honestly, smaller contributions are often the best way to start.

My Daily System

I keep the process intentionally simple.

Usually it looks like this:

Open GitHub
Continue previous work or find one thing to improve
Spend 30–60 minutes contributing
Log the progress publicly

That’s all.

The simplicity matters because I want this challenge to survive busy days, low-energy days, and difficult weeks.

Consistency beats intensity.

What I’ve Been Doing So Far

Over the past two months, my days have included things like:

contributing to open source repositories
improving documentation and learning materials
exploring AI agent frameworks and tooling
building my own projects publicly
learning collaboration workflows through GitHub

A lot of the work is small.
Some of it is invisible.
But all of it compounds.

And that’s the point.

The Bigger Goal

This challenge isn’t only about GitHub streaks.

It’s about becoming the kind of engineer who can contribute meaningfully over the long term.

Right now, I’m still exploring different projects and communities.
Over time, I want to deepen my involvement, contribute more substantially, and eventually become a trusted contributor within projects I care about.

Not overnight.
One step at a time.

What I’ll Share Here

I’ll be documenting this journey regularly on dev.to throughout the year.

That includes:

Lessons from open source contributions
Things I learned while building AI and developer tools
mistakes and challenges
contribution workflows
beginner-friendly insights
thoughts about consistency, learning, and engineering growth

I want this series to be honest and practical — not just highlight reels.

If You’ve Been Hesitating to Start

You do not need to be an expert to contribute.

You only need to begin.

Open source can feel intimidating at first:
large repositories, unfamiliar workflows, experienced maintainers, complex codebases.

But contribution is a skill like anything else.
You improve by participating.

Even one thoughtful comment or documentation fix matters.

Join Me

If you’re also learning in public, contributing to open source, or trying to build consistency as a developer, feel free to join me.

Start small.
Show up consistently.
Document the journey.

One commit at a time. 🚀