I'm a second-year computer science student and have been teaching myself 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 daily plan. It can also re-plan when unexpected events occur. 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 extensively. There are parts of the implementation I didn't fully understand when they were first generated, so I'm sure the project contains overly complicated architecture, unidiomatic Go, weak error handling, and choices that may cause problems later.
I'd appreciate direct, constructive criticism from experienced Go developers. In particular, I'd like to know what is unidiomatic, where the architecture is too complicated, whether the project structure and error handling need work, and what you would change if you were maintaining this project. Explanations would be especially helpful because I'm still learning.
3 Answers
The biggest concern isn’t necessarily that you used AI assistance—it’s that you may be presenting generated code as something you fully learned by writing. If you can’t explain the control flow, standard-library calls, API boundaries, and failure cases without relying on the assistant, those parts are still a learning gap. Try taking one subsystem at a time, rewriting it yourself, and adding tests so you can verify that you understand it.
The project description is very broad for someone with only a month of Go experience. A useful next step would be to reduce the scope and focus on a small, completely understood core: load configuration, read fixed events and tasks, produce a plan, and handle errors cleanly. Once that works without assistance, add integrations one by one. Otherwise, it becomes difficult to tell whether you’re learning Go or simply operating a collection of generated features.
Be prepared for the codebase to have the same problem as the presentation: lots of impressive-sounding features but not enough evidence that the fundamentals are solid. Document the important design decisions, write tests for scheduling and re-planning, run the race detector, and inspect every external input and API failure path. Those exercises will give you more useful feedback than adding another provider or feature.
The breadth can still be valuable as a learning project, but I agree that the next phase should be consolidation rather than expansion. Removing or rewriting parts you can’t explain would probably teach more than continuing to add features.
That’s fair. My earlier learning was mostly textbook-focused, so I understood concepts such as concurrency and race conditions but lacked practical experience with the standard library and real API integrations. I’ve been going back through the code carefully, including client setup, file handling, JSON decoding, and request/response formats. The overall workflow was my own design, but I agree that understanding every implementation detail matters.