We started by brainstorming what autonomous agents should actually do, like browsing the web or handling service requests. To avoid reinventing the wheel, we decided to build on an existing framework instead of starting from scratch.

Our first choice was OpenClaw, but the codebase was a mess. The architecture was too tightly coupled, making it nearly impossible to modify or extend without breaking things. We needed something more modular and maintainable.

That led us to Nanobot. It’s much cleaner, with a core of only 4,000 lines. The logic is easy to follow, and since extensions live in separate modules, we can contribute without messing up the main infrastructure.

Right now, we’re figuring out how to add the most value. Instead of just adding a new feature, we want to build a “breakage testing suite.” Agent frameworks often break when third-party APIs change or deprecate endpoints. Our system would automatically detect these failures and alert the community. By focusing on reliability, we’re helping Nanobot scale and making it easier for everyone to keep their integrations working.

I’ve been thinking a lot about the current state of LLM orchestration, specifically how to move beyond basic prompting and into using local tools for orchestration my own tasks. I already have openclaw on my machine to do work, but the tools are still pretty terrible. My goal is to work on a project where we’re expanding the frontier of tools into things I find useful.

I’ve been diving into frameworks like LangChain, LlamaIndex, and Haystack, as they’re essential for managing the complexity of tool-calling, memory, and retrieval pipelines. In terms of a longer project, I would love to think about a way to compress existing abstractions for things like web pages and human UI so we use less tokens and can improve net performance through small but slightly creative techniques.

Because this space is so new, we’re constantly dealing with model drift, breaking API changes, and the inherent unpredictability of orchestration. I’m comfortable navigating that instability through my work in Kalshi/Polymarket. I’ve found that small changes in these systems can cascade quickly, so I focus heavily on technical execution and reading deep into codebases to understand architectural tradeoffs.

One of the most impactful experiences I’ve had recently was evaluating Hummingbot for crypto market making. It gave me a real appreciation for modular system design, specifically how strategies plug into exchange connectors. It got me thinking about how that kind of extensibility could be generalized beyond crypto to broader CLOB-style (Central Limit Order Book) markets. Applying that level of architectural insight—moving from a specific crypto implementation to a generalized abstraction—is where I think I contribute the most value.

The biggest takeaway from my own group work this week was realizing that writing the code is only half the battle. I learned that you have to spend an equal amount of time simplifying and documenting your work so that others can actually build on it without hitting a wall. Watching the other groups’ presentations and extensions reinforced this, as the projects that stood out weren’t just the ones with the most complex features, but the ones that communicated their logic clearly. It became obvious that technical skill is wasted if your teammates can’t understand your interface, and that the “human” part is clear.

Commenting on the Wednesday videos, the keynote from Kelsey Hightower was especially impactful because of his perspective on the open-source community. He described maintainers as “hidden tailors” who take generic software and fit it to specific needs, much like the man who stayed open late on a Sunday to tailor his sports coat. When HashiCorp created a clone of his project, he didn’t get angry; he viewed it as a sign of success, arguing that if you can influence a major company to build something based on your work, you’ve achieved something great. He famously challenged founders to stop building “moats” in the “age of flight,” suggesting that providing unique value is better than trying to protect code that anyone can eventually bypass or fork. This is a perspective echoed deeply by Linus who beleives the community acted with money grubbing intentions instead of genuine need.

Craig McLuckie’s talk added a layer of caution to this by focusing on the security risks of AI-assisted development. He pointed out that while generative AI tools make us faster, they often rely on stale data from years ago, which can lead developers to unknowingly pull in “abandonware” or malicious libraries. Linus Torvalds mirrored this pragmatism in his fireside chat, dismissing the heavy hype around AI by calling it “autocorrect on steroids.” Linus emphasized that while AI is a great tool for finding bugs or getting a project to the 90% mark, the final 10%—the maintenance, the core logic, and the reliability—still requires the deep, human understanding that defines projects like the Linux kernel.

Observing these professional presentations taught me that the best communicators lead with a narrative rather than just technical data. Kelsey Hightower didn’t need complex slides because he used a personal story about a tailor to explain the philosophy of open source, while Linus showed that being authentic and blunt is more engaging than being overly polished. Based on these observations, I need to improve my own presentation style by focusing on the “Why” before the “How.” I want to move away from just listing features and instead focus on creating a clear on-ramp for my audience, ensuring that my communication is as well-structured as the code it’s describing.

I was one of the students who recommended the NautilusTrader project, so I was glad to see others evaluating it closely. One observation that stood out — and that I agree with — is that the lead maintainer appears to be largely a single individual. I’ve personally seen him tagged across hundreds of Discord threads, which suggests he’s carrying a heavy support and development load. Recognizing this is important when evaluating a project’s sustainability and contributor experience, because a single-maintainer bottleneck can both slow progress and create delays in reviewing pull requests.

At the same time, it’s encouraging that the project is still very active. It’s clear that Nautech Systems is continuing to invest effort into maintaining and developing the codebase. That level of activity makes the project feel alive rather than abandoned, which is critical when choosing an open-source project to contribute to.

What excites me most about NautilusTrader is that it operates in a technically deep domain (algorithmic trading infrastructure) where contributions can be both intellectually challenging and practically impactful. It’s not just a toy project — it’s software that people may rely on for real workflows.

The biggest challenge I anticipate is onboarding complexity. Projects in specialized domains tend to have steep learning curves, both in terms of the codebase and the underlying domain knowledge. Additionally, with a small maintainer team, getting guidance or feedback may take time.

To overcome this, I plan to start with small, low-risk contributions such as documentation fixes, minor bugs, or tests, while carefully reading existing issues and discussions to understand current pain points. I also plan to ask precise, well-researched questions and be patient with response times given the maintainer’s workload.

Git Exercises

Honestly, I don’t have much critical feedback on the Git exercises themselves because I already use Git extensively in my work. However, it was still valuable to revisit the fundamentals. In practice, I often rely on tools, shortcuts, or even LLMs to generate complex commands (for example, advanced git diff usage), so going back to the underlying concepts helps reinforce what’s actually happening under the hood.

Rebuilding that mental model — especially around the structure of the .git directory and how commits and objects are stored — is useful for debugging and for understanding Git beyond the surface-level commands.

The Technical Reality Check

One of the first things we realized is that running local LLMs isn’t “resource-light.” Through some initial testing, we’ve established our hardware baseline: we’re looking at machines with at least 16 GB of RAM and more than 4 Cores. Having these constraints settled early is a huge relief because it gives us a clear sandbox to play in and prevents us from designing something that our own hardware can’t actually execute.

What I’ve Discovered About Collaboration

The most rewarding (and surprising) part of this process hasn’t been the code, but the group dynamics. I’ve realized that my role in this team is centered around alignment.

I discovered something about myself during our brainstorming sessions: I have a deep-seated need for consensus. I’ve learned that you can’t just push a “good idea” and expect it to fly. People’s excitement and their willingness to put in the late-night hours are completely contextual to how much they feel “bought-in” to the vision.

Wins and Roadblocks

The Good: Once we hit that deep consensus, the momentum changed. The energy in the “room” shifted from “What should we do?” to “How do we build this?”

The Challenges: We are still navigating the learning curve of the Gemini local platform and ensuring everyone on the team has the environment access they need, especially given those hardware requirements.

RE the video - the Sheldon example makes a lot of sense in terms of consesus and the need for small, tightly aligned groups who respect each other’s capacity and abiliy. Otherwise stalling is a serious risk. But obviously in real-life alignment is not a priori - which is why agreement over a set of arbitration procedures, discussion methods, and active communication is critical towards the end output. This is where I think the code of conduct makes sense as we agree on voting procedures or consesus mechanisms that keeps the ball rolling. Apart from that, I think a lot of it is intent based - if individuals want to be combative, they will do so regardless of policies. Policies just lay out penalties - and angry but smart users will ‘walk the line’, which doesn’t dispel the core concern of their intent. This is why larger projects as the video mentioned needs an unbiased perspective, like in the case of Linux a Linux Foundation Staff Member that acts as a moderator and considers the good of the project.

I’m looking forward to get started on a larger project that’s going to be a challenge.