First of all, I want to sincerely thank everyone who has offered to help with Baruch. It really means a lot to me. Seeing brothers willing to invest their own time and energy into this project is incredibly encouraging.
Several brothers suggested using AI tools such as Claude Code, Jules or other "vibe coding" tools. These tools are becoming remarkably capable, and I use AI myself every single day. They are fantastic productivity tools.
However, I also want to explain why I have been somewhat hesitant to accept AI-generated code contributions at this stage.
Baruch is not a typical business application where you simply add a screen, update a database table, and you're done. Under the surface it has a fairly sophisticated architecture built around concepts such as Domain-Driven Design (DDD), CQRS, Event Sourcing, an Outbox pattern, distributed synchronization, gRPC communication, offline-first data replication, and a considerable amount of custom infrastructure that I have built over the past years.
Much of this complexity is intentionally hidden from the feature code. That's a good thing for the application—but it also means that someone unfamiliar with the architecture cannot easily see everything that happens behind a seemingly simple change.
A screen that appears straightforward may actually trigger domain events, update projections, synchronize with other devices, publish messages through the outbox, and interact with several infrastructure components. Those architectural decisions are often invisible to an AI tool unless it has a deep understanding of the entire codebase.
My concern is therefore not that AI writes "bad code." In fact, AI often produces perfectly reasonable C# code. The challenge is that code can still be architecturally incorrect even if it compiles and looks clean.
Reviewing those pull requests would require me to carefully verify every architectural decision, every interaction with the infrastructure, and every side effect. In many cases, that would actually take longer than implementing the feature myself.
For that reason, I currently have to be very careful about accepting code contributions from people who are not already familiar with the architecture of Baruch.
That certainly doesn't mean I don't appreciate the offers—quite the opposite. Your willingness to help is deeply appreciated, and I hope that as Baruch matures I can find more meaningful ways for brothers to contribute without risking the long-term maintainability of the project.
For now, my biggest challenge isn't writing code; it's protecting the architecture that makes Baruch reliable, secure, and maintainable in the long run.
Thank you again to everyone who has offered to help. Your encouragement and support mean far more to me than you probably realize.