I'm a second-year computer science student who has been learning Go for about a month. During that time, I built Chronos, an AI-powered personal scheduler. It combines fixed commitments such as classes with flexible tasks, daily programming practice, and other constraints to generate a schedule. It can also re-plan when something unexpected happens.
The project stores data locally, caches generated results to reduce API calls, supports multiple AI providers and models, sends schedules by email, fetches and translates programming problems, and lets users customize the scheduler's style. I designed the overall workflow myself, but I also used AI coding assistants to implement parts of the application that I didn't fully understand at first.
I'm looking for honest feedback from experienced Go developers. In particular, I'd like to know whether I'm using Go in an unidiomatic way, whether the architecture is more complicated than necessary, whether the project structure and error handling have obvious problems, and which decisions might become difficult to maintain later. Explanations would be especially helpful because I'm still learning.
3 Answers
Using AI-generated code before understanding it can create the illusion that you’re learning when you’re mostly integrating suggestions. Reading through the important parts afterward is a good start, but try rebuilding smaller pieces yourself: configuration loading, API requests, scheduling logic, persistence, and error handling. That will reveal what you actually understand and make future debugging much easier.
The presentation also makes it hard to judge the project. A long list of features doesn’t show whether the core scheduling behavior is reliable, and polished wording can make people suspicious that the description was generated rather than written from firsthand experience. Be direct about what you personally built, what was generated, and which parts you can explain. That transparency will lead to more useful technical feedback.
My English isn’t very strong, and I’m still getting used to writing technical project descriptions. I’ll try to be clearer about which parts I understand well and which parts I’m still studying.
The biggest concern isn’t necessarily that you used coding assistants—it’s whether you can explain and maintain the code they produced. If you’re asking for a technical review, focus the discussion on specific packages, functions, design decisions, and bugs rather than presenting the feature list as proof of progress. A smaller project that you fully understand will teach you more than a much larger one assembled through prompts.
That’s fair. My earlier learning was mostly textbook-based, so I understood ideas such as concurrency, channels, and race conditions but had little practical experience with the standard library. I’ve been going back through the project to understand the client setup, file and stream operations, API request formats, and JSON decoding. I designed the overall workflow independently, but I agree that I need to implement more of the smaller components myself instead of relying on generated code.