This week was our first meeting back after spring break, and it felt good to finally shift from planning into actually contributing to Nanobot. During break I’d been reading through the codebase and getting familiar with how things were structured, but there’s a big difference between reading code and writing something that needs to fit into it. Each of us on the team picked an issue to work on
The problem I noticed was that in Nanobot’s existing architecture, all skill activation is determined by the agent — there’s no way for the user to pre-activate or pre-load a skill before the agent starts reasoning. You could ask the agent to load a skill for you, but that adds an extra round trip of tool calls just to get the context into the conversation. I wanted a more direct approach: let the user activate a skill themselves, inject the content of SKILL.md straight into the user message, and wrap it in XML tags that clearly signal to the agent “this is user-activated skill content” as opposed to the user’s actual query. That way the agent gets the skill context immediately without any back-and-forth.
A lot of the design decisions came from reading through the codebase and thinking about practical usage. For example, I added a /skills command that lists all configured skills with availability status — something the user can check without involving the agent at all. Another key decision was injecting the skill content into the user message rather than the system prompt. This avoids breaking the LLM’s prompt cache, and because user messages get strong attention from the agent, it ensures the skill content actually gets prioritized alongside the user’s intent.
What made this PR really interesting was how it evolved through collaboration. My original approach was a straightforward /skill slash command, but right after I opened the PR, a previous contributor suggested switching to an inline $<name> syntax instead — so that skill references could appear anywhere in a message rather than only at the start. It was one of those suggestions that immediately clicks: obviously better, and not something I would have thought of on my own. I quickly pivoted the implementation, we reached agreement on the design, and the whole back-and-forth felt surprisingly smooth. That’s the kind of interaction that makes open source exciting.
Now that the first PR is merged, I’m feeling a lot more comfortable navigating the Nanobot codebase. I want to keep the momentum going and find another issue to work on next week, ideally something a bit more involved now that I understand the project’s patterns and review process better.
]]>Our group ultimately chose Nanobot, an ultra-lightweight personal AI assistant inspired by OpenClaw. It packs core agent functionality into roughly 4,000 lines of Python, supporting multiple LLM providers, MCP tool integration, and a wide range of chat platforms like Telegram, Discord, and Slack.
We all share a strong interest in AI and agent-based systems, so the project space was an easy decision. The harder part was narrowing down which project to contribute to. We initially evaluated LangChain, Hummingbot, and OpenClaw. LangChain and OpenClaw are massive codebases with huge contributor bases, and we were concerned that our contributions might get lost ignored or take a long time to be reviewed and merged. Nanobot stood out because it’s a young project with a lot of attention and active development. Since it’s essentially a lightweight reimplementation of OpenClaw, there are plenty of pending features to build and bugs to fix. It felt like the sweet spot: meaningful work with a realistic chance of our contributions actually landing.
On the practical side, Nanobot is written entirely in Python. Python is the preferred language for most of us. That made it the clear choice from a technical fit perspective as well.
Everyone on the team has successfully set up the development environment, and so far we haven’t hit any major obstacles. Right now we’re in the exploration phase: actively using Nanobot, testing its features, and comparing its behavior against the more mature OpenClaw to understand where the gaps are.
I’ve already identified a few potential issues worth investigating. One is that reasoning content isn’t being passed back to the agent during the agent loop, which results in an incomplete chain of thought. I’ve also noticed that there are several missing LLM provider configurations that would be worth adding. These feel like solid starting points for contributions.
Our plan is for each team member to propose small issues or contributions to work on individually first. Once we’ve each gotten comfortable with the contribution workflow and the codebase, we’ll look into tackling a larger feature together as a group. The specifics are still being finalized, and we’re hoping to lock down a more detailed plan in the upcoming week.
I’m optimistic about this project. The codebase is clean and readable, the maintainers seem active, and there’s no shortage of work to be done. It feels like the kind of project where we can make a real impact within the semester.
]]>This was my favorite of the three. It really caught my attention because I use AI-assisted coding tools every day. The idea that AI doesn’t just help developers but also empowers bad actors is something I hadn’t fully thought through. If AI can help me write code faster, it can also help someone generate and publish malicious packages at scale. That’s genuinely scary.
His suggestions around establishing provenance with tools like Sigstore and SBOMs make a lot of sense. We need to be able to trace where code comes from, especially as AI-generated code becomes more common.
Hightower’s talk was really memorable. He compared this hidden craftsman who quietly perfects your clothing to the silent open-source maintainers who patch and fix software behind the scenes.
The confd and HashiCorp story was a great example of what the spirit of open source really looks like. Most people would be upset if someone forked their project and grows bigger, but Hightower was thrilled because that’s exactly how open source is supposed to work. It’s a good reminder that ownership in open source is different from ownership in the proprietary world. It’s important to recognize and be recognized for your open-source work, but you also have to keep reminding yourself why you’re doing it. The spirit of open source is about sharing and collaboration, not building walls around your code.
Torvalds has this blunt, no-nonsense style that makes everything feel honest. His take on the kernel being “calm, steady, and boring” after 30 years is actually kind of aspirational. That’s what a well-maintained project looks like at maturity.
His thoughts on AI were refreshingly grounded. While everyone else is panicking or hyping, Torvalds just calls it “auto-correct on steroids.” I tend to agree. AI tools are incredibly useful for finding bugs and speeding up mundane tasks, but they’re not replacing human judgment anytime soon.
This week we presented QuickHistory to the class. It didn’t go as smoothly as I’d hoped. What happened was that during the first part of the demo, we deleted some browsing history to show off that feature. But we didn’t think ahead, because the history we deleted was exactly what we planned to search for in the next part of the demo. So when we tried to ask the AI agent to find those pages, there was nothing to find. Kind of embarrassing, but also kind of funny in hindsight. On top of that, we didn’t rehearse who was going to say what, so there were a few awkward moments where we were figuring out on the fly who should talk next. Lesson learned: always do a dry run, and think through the demo flow end to end so you don’t sabotage your own demo.
Watching other groups present was genuinely interesting. Most teams looked confident and did a great job with their demos. Seeing what other people built with their extensions gave me a broader perspective on what’s possible with the Chrome extension platform.
Between the student presentations and the OSS conference keynotes, I got to see a wide range of presentation styles this week. The conference speakers were on another level, but not because of fancy slides or production value. It was because they told stories.
Kelsey Hightower opened with a story about a tailor fixing his sports coat. Linus Torvalds cracked jokes about hoping he never has another big project. Craig McLuckie walked through the XZ vulnerability like a detective story. These speakers made technical topics engaging by weaving in personal experiences and narrative arcs.
The student presentations, including ours, were more straightforward. Here’s what we built, here’s how it works, here’s a demo. That’s fine, but it can get monotonous. One thing I want to improve in my own presentation style is incorporating more narrative. Instead of jumping straight into “here’s the feature,” I could start with “here’s the problem we were frustrated by” and let the demo feel like the payoff to a story. It’s a small shift, but it makes a big difference in keeping the audience engaged and not bored.
]]>I use git on a daily basis and honestly, I can’t imagine what my workflow would look like without version control. So the git exercises in class weren’t entirely new to me, but they were still valuable. They helped me review commands I don’t use as frequently and gave me a better understanding of what’s actually happening under the hood.
The most interesting part was learning about how git stores data internally. I kind of curious about how git works before but never really bothered to dig deeper. Its also my first time to learn the git cat-file -t <hash> and git cat-file -p <hash> commands.
What excites me the most about contributing to open source is the idea of shipping something that other people actually use. There’s something satisfying about knowing your code is out there helping real users. It’s also a great addition to my portfolio for career development.
To be honest, none of the projects we evaluated in class felt like a great fit for me. Many of them require strong domain knowledge or are written in languages I’m not familiar with.
If I had to pick, NautilusTrader is a relatively good option. I have an interest in trading, so the subject matter aligns well. It’s mostly written in Python and Rust. I’ve never used Rust before, so I’d realistically only be contributing to the Python portion. Two main concerns: I’d need to dig deeper to understand the development dependencies on the Rust side, and the project is mostly maintained and developed by a single contributor, so it would be crucial to communicate with him early about expectations and the roadmap.
As for challenges in general, the biggest one is probably understanding unfamiliar codebases and following existing patterns and expectations. Communication is also key. We’re expected to make actual contributions within the semester. If the maintainers aren’t actively reviewing PRs or responding to issues, that’s a blocker.
That’s why choosing the right project is so crucial. My strategy is to pick something I’m already using or familiar with, and to make sure the project has maintainers who are actively communicating and reviewing contributions. Beyond that, I’ll figure out more specific strategies once I finalize my project selection.
]]>Our group project is called QuickHistory. We came up with this project because managing browser history sucks. Chrome’s built-in history page is basically just a long list you have to scroll through. We’re building a Chrome extension that makes it easy and effortless to manage your history using AI.
QuickHistory uses LangChain and OpenAI to let you interact with your browsing history through natural language. You can ask in natural language to find the website you visited but can’t recall the name of. But it’s not just read-only, the agent can actually perform actions on your behalf. You can also delete history based on your criteria by simply saying something like “delete all my YouTube history”.
Our team has been working well together so far. I’ve been handling the LangChain and AI side — setting up the agent and bridging it with the Chrome API. The collaboration has been smooth, with a pretty clear division of work. It’s been really fun to work together as a team solving a shared pain point.
Currently, we already have prove of concept of AI features working. We will collaborate more next week to piece everything together.
]]>Go’s Code of Conduct was interesting to read because it feels less like a rulebook and more like a set of values. They have this whole “Gopher Values” section about being patient, assuming good faith, and being mindful that not everyone speaks English natively. The Contributor Covenant is more of a standard template — it gets the job done but reads more formal. Two big differences: Go has that values section which the Contributor Covenant doesn’t, and Go explicitly calls out cultural and language awareness. I think that’s because Go has such a huge global community that miscommunication over text is a real risk.
Sugar Labs bases theirs on the Ubuntu Code of Conduct, which has a similar vibe to Go’s — more about positive values than just listing what not to do.
I also checked out vLLM’s Code of Conduct since I use it a lot. It’s basically the Contributor Covenant v2.1 with reports going to a Slack channel. It works, but it’s pretty much the default template. As the project grows I think they’d benefit from adding something more personal, like Go did.
The video on driving consensus had a lot of good points, but the one that really stuck with me was the idea of a “North Star” — getting everyone to agree on what you’re building before arguing about how. I’ve been in group projects where nobody was clear on who was doing what, and we ended up with duplicated work and stuff falling through the cracks. Having that shared direction and clear responsibilities would have saved a lot of headaches.
]]>Open source has a lot going for it. Things move faster when thousands of people can find bugs and build features together, no single company can match that. It’s also way more accessible — free tools mean students, startups, and developers everywhere can use them without worrying about expensive licenses. And if something doesn’t work exactly how you want, you can just fork it and change it yourself.
That said, it’s not all great. A lot of important projects are maintained by a few volunteers who eventually burn out, and nobody’s really figured out how to sustainably fund open source work. The UX can also be rough — sometimes it feels like tools were built by engineers for engineers. And something I’ve noticed is that when contributors come from all over the world with different coding styles and ways of communicating, things can get messy. It’s also hard to see the big picture of where a project is heading when decisions are spread across issues, mailing lists, and random PRs.
Two reasons, really. I want to contribute to real projects that people actually use and it looks better than class projects on a resume. But I also want to give back. I’ve been using open source tools heavily for my work, and it feels right to contribute instead of just consuming.
LangChain — I’ve been using this for about two years now for building AI agents. Watching it grow from a small project into a major framework has been cool.
vLLM — This is what I use to serve large language models on local GPUs. I have built open source project around it and impressed by the awesome community.
Linux — The classic example of open source taking over the world.
Git — Can’t leave without it after learning how to do version control. Save my life many times.
]]>