I have finally completed my first project in Go, a task tracker. I learned how to do some stuff, and i still don't understand some other things, so, my question is, what should i do next now?

Grok 4.20

Answer: Refine your task tracker with tests, concurrency, and idiomatic improvements to address knowledge gaps, then start a new project that builds on these lessons.

My original position emphasized reviewing the task tracker for improvements like adding persistence, studying unclear concepts directly, and then moving to a new challenging project. After examining the other models' responses, this still feels like the optimal path forward, as it balances reflection with forward momentum without getting stuck in endless polishing of the first project. The consensus across responses is striking: nearly every model (Kimi, Gemini, GPT-5.4, Claude, and even Sonar) stresses using the existing task tracker as a learning sandbox before or alongside a second project. Gemini 3.1 Pro's point about leveraging familiarity with the business logic to focus purely on Go features like testing, net/http, and goroutines is particularly practical. This reinforces rather than contradicts my prior advice, as adding features and tests to the current codebase naturally surfaces the concepts you don't yet understand. GPT-5.4 and Claude Opus 4 add valuable nuance around explicitly listing knowledge gaps and choosing the second project to target them specifically—whether a concurrent web scraper or REST API. This targeted approach prevents aimless wandering and accelerates intuition, which aligns with my recommendation to study one concept at a time through small experiments and applied practice. I maintained my position because these inputs validate the build-review-learn-build cycle I described initially. Pure theory or jumping straight to an unrelated project risks shallow understanding, while over-refactoring the first app without shipping something new can stall motivation. Publishing to GitHub for feedback, as both my original argument and Claude suggest, remains a high-leverage final step. The path is therefore: enhance the tracker with table-driven tests, concurrent task processing, and idiomatic error handling; read Effective Go and stdlib code; then select a new project that forces growth in weak areas. This deliberate practice loop is what separates working code from professional Go mastery.

GPT-5.4

Answer: I maintain my original position: the best next step is to iterate on your task tracker with testing, refactoring, and deployment while starting a slightly more challenging second project that directly targets your current Go knowledge gaps.

The other models largely reinforced rather than changed my view. There is strong convergence around the same core idea: do not stop at "it works," but use your finished project as a platform for deeper learning, while also building a second project that forces growth. That alignment makes me more confident the original advice was directionally right. What I especially agree with in the other responses is the emphasis on concrete upgrades to the existing project. Gemini and Kimi both made a compelling case for adding tests, an HTTP API, and possibly persistence. Those are excellent next steps because they teach foundational Go skills in context: package structure, error handling, JSON, `net/http`, and the `testing` package. Sonar also usefully stressed that revisiting the same codebase can teach professional habits like clearer architecture and better separation of concerns. However, I would not narrow the advice to only "refactor this one project until it becomes production-grade" before moving on. For a beginner, there is a risk of over-engineering too early and mistaking architecture complexity for learning progress. The more effective path is balanced iteration: improve the first project enough to learn from it, then begin a second project that introduces one or two new dimensions of difficulty. I also still think the most important practical move is to explicitly list what you do not understand yet. Claude and Grok echoed this well. That step matters because otherwise your next actions become random. If your gaps are concurrency, build something concurrent. If your gaps are HTTP and JSON, build an API. If your gaps are testing, write table-driven tests first. The project should be chosen to match the missing concept, not just because it sounds impressive. So my maintained recommendation is this: first, clean up your task tracker; second, add tests and one meaningful extension such as persistence or an API; third, pick a second project that targets the concepts you still find confusing; fourth, publish it and get feedback. That sequence keeps momentum, strengthens fundamentals, and avoids both tutorial hell and premature obsession with "enterprise" design.

Gemini 3.1 Pro (changed mind)

Answer: Your best next step is to solidify your foundational knowledge by testing and refactoring your existing task tracker, and then use your specific knowledge gaps to dictate a slightly harder second project.

I still firmly believe your immediate next step should be to stay with your task tracker. Expanding it by adding unit tests, refactoring for idiomatic Go, or turning it into a REST API gives you a perfect sandbox. Because you already understand the business logic of the app, your brain is freed up to focus entirely on learning Go's standard library and tooling. However, GPT-5.4 made an excellent point that changed my perspective on what comes after that. Endlessly bolting complex features onto a beginner project can lead to over-engineering and burnout. To truly tackle the things you still don't understand, you should write them down as an explicit list—whether it's goroutines, interfaces, pointers, or package design—to create a concrete learning roadmap. Once you have polished your task tracker, use that list of knowledge gaps to choose a second project. If you struggle with concurrency, build a background worker pool; if you don't understand interfaces and persistence, build a URL shortener with different database backends. This structured cycle of improving your first project and then building a targeted second project will effectively bridge the gap between a beginner and an intermediate Go developer.

Claude Opus 4

Answer: Build a second, more ambitious project that addresses the gaps in your understanding, while deliberately incorporating the Go concepts you don't yet grasp.

After reviewing all the responses, I'm maintaining my original position because every model essentially converges on the same core advice — just with different emphasis on whether to refactor first or build new first. Here's my refined synthesis: **The consensus is clear: reflect, refactor, then build something new.** Every response agrees on this general trajectory, which reinforces that it's genuinely good advice. Where I want to sharpen my answer is in acknowledging the strong points others made. **Gemini 3.1 Pro and Sonar Reasoning Pro make a compelling case for staying with the task tracker longer.** They argue that since you already understand the business logic, you can focus entirely on learning new Go concepts without the cognitive overhead of designing a new system. This is a valid pedagogical point. Adding a REST API layer, persistence, tests, and concurrency features to your existing project is an excellent intermediate step before building something entirely new. **GPT-5.4's emphasis on documentation and polish is underappreciated.** Writing a good README, adding usage instructions, and putting the project on GitHub teaches practical software skills that Go tutorials never cover. This is genuinely valuable career advice disguised as a Go learning tip. **However, I still believe a second project is essential, not optional.** Refactoring only takes you so far. There's a qualitative difference between bolting new features onto familiar code and starting from scratch with a blank `main.go` where you must make all the architectural decisions fresh. The second project is where you prove to yourself that you actually internalized Go's patterns rather than just copy-pasting within your own codebase. **My refined recommendation:** (1) Write down specifically what you don't understand. (2) Add tests, improve error handling, and refactor your task tracker to be more idiomatic — this is your safe learning sandbox. (3) Read *Effective Go* and browse well-written open-source Go code. (4) Build a second project that naturally requires your weak areas — a REST API, concurrent web scraper, or CLI tool. (5) Put both projects on GitHub with proper documentation. The key insight that all models share: the worst thing you can do is stop. Momentum after your first project is precious — use it.

Kimi K2.5

Answer: You should refactor your task tracker to incorporate production-grade Go patterns and idioms while explicitly cataloging your knowledge gaps, then build a second project that strategically targets those specific weaknesses.

After reviewing the other models' responses, I maintain that consolidation must precede expansion, though Sonar Reasoning Pro and GPT-5.4 significantly strengthen this argument. Sonar's focus on production-grade architectural patterns—repository layers, service orchestration, and OpenAPI documentation—refines my original suggestion by emphasizing that refactoring isn't merely about "making it work" but about experiencing why professional structure matters through the specific pain points of your own codebase. This prevents accumulating "tutorial projects" that demonstrate syntax without engineering judgment. Additionally, GPT-5.4's recommendation to explicitly catalog your knowledge gaps is crucial; converting vague confusion about "concurrency" or "interfaces" into a written checklist ensures your next project strategically targets those specific weaknesses rather than accidentally avoiding them. While Claude Opus 4 makes an interesting pedagogical case for building the second project first and then refactoring the original, this approach risks applying half-understood patterns to new code without the foundational consolidation that comes from wrestling your existing working code into idiomatic, tested shape. Therefore, you should first explicitly list what you don't understand, then refactor your task tracker to production standards (adding comprehensive tests, proper error handling, and architectural boundaries) using those gaps as a guide for what to research. Only then should you build a second project—whether a concurrent web scraper, REST API, or CLI tool—that deliberately exercises those remaining unfamiliar concepts, ensuring each project builds upon verified competence rather than accumulated technical debt.

Sonar Reasoning Pro (changed mind)

Answer: While refactoring your first project for production-grade practices is valuable, building a second project that deliberately targets your knowledge gaps—while iteratively improving the original—is a more effective path to genuine Go mastery.

My previous answer emphasized refactoring the task tracker for architectural patterns and production-grade practices before moving on to new work. However, reviewing the other models' responses has clarified an important pedagogical distinction I underweighted: learning through *building* is substantially more effective than learning through *refactoring*. Claude, GPT-5.4, and Gemini make a compelling case that choosing a second project specifically designed to force you to learn the concepts you don't yet understand (goroutines, channels, interfaces, testing, persistence, concurrency) is more efficient than spending weeks retrofitting architectural patterns into a project where you already know the business logic. The consensus across multiple models—that you should build a REST API server, concurrent web scraper, or similar second project while also improving your original task tracker—reflects a more practical learning philosophy: concepts stick better when you apply them in new contexts and face natural friction from solving different problems, rather than reorganizing code you've already written. However, I still believe that quality practices matter from the start. The synthesis here is that you should: (1) reflect on what you don't understand and write it down explicitly, (2) choose a second project that requires those concepts, (3) iteratively refine both projects as you learn, and (4) use the second project as your primary learning vehicle while treating improvements to the original as reinforcement, not prerequisite. My sequencing was too rigid. Your path forward is better viewed as parallel iteration—improving the original while building something new—rather than linear (refactor completely, *then* move on).

Final Summary

The AI Roundtable recommends a dual-track strategy: refactor your current project into a production-ready "sandbox" while starting a second project that forces you to confront difficult concepts. All 6 models, including GPT-5.4 and Claude Opus 4, emphasized that documenting specific knowledge gaps should guide your choice of a new, more ambitious challenge. Sonar Reasoning Pro shifted its stance to support parallel development, noting that starting from a blank file is essential for true architectural mastery.

All 6 models agreed