I've spent the last two weeks vibing with a new language, Go, and ecstatic by the results from my custom AI coding assistant. In an article from Geoff Huntley (linked below), he explains most of us are using Cursor wrong. We leave a lot on the table when we just take the Claude 3.7 at face value. There is so much our assistants can accomplish with the right building blocks. I prefer running my assistant local and for free using Ollama, and have been getting great results leveraging Gemma 4b. When I get errors or bugs in my code, I get my assistant to generate new rules (for the system prompt) that encourages my assistant to actually write idiomatic go code.
Building Blocks of an AI Coding Assistant
When crafting the perfect AI companion for your coding journey, understanding the fundamental building blocks is essential. Just as a Jedi carefully selects each component of their lightsaber, we can assemble our ai coding assistants with precision.
The Continue.dev platform breaks this down beautifully into distinct components, assistant blocks:
Models
At the core of any assistant lies the model—the Force that powers everything. Whether you're using Claude 3.7, Gemma 4b through Ollama, or another LLM, this is your assistant's brain. The model determines how well your assistant understands context, generates code, and reasons through problems.
Context
Context blocks define a context provider which can be referenced in Chat with @
to pull in data from external sources such as files and folders, a URL, Jira or Confluence, and Github issues, among others.
Tools
Think of these as your assistant's utility belt—specialized functions that extend capabilities beyond simple text generation. Code formatters, linters, test generators—these tools transform a basic text model into a true coding partner.
Rules
Rules are the most important blocks. These are the instructions that your custom AI code assistant will always keep in mind - the contents of rules are inserted into the system message for all Chat requests. Explore rules on the continue hub.
I leveraged rules heavily when navigating errors. If I find my prompt returns incorrect syntax or worse, a library import is hallucinated, I train my assistant with rules to prevent those results from happening again. This has improved my AI agent to be 4x more performant by leverage the effective go programming paradigm. As an example, here is an excerpt out those generated rules in the gist below:
• Use gofmt to format your code automatically. Don’t fight the formatter. | |
• Write clear and concise package names. Use lowercase, single-word names without underscores or mixed caps. | |
• Follow Go naming conventions: | |
• Use MixedCaps or mixedCaps for multiword names, not underscores | |
• Capitalize exported names | |
• Use short, descriptive names for variables and functions | |
• Utilize Go’s built-in error handling. Return errors as values, not exceptions. | |
• Take advantage of multiple return values, especially for error handling. | |
• Use defer for cleanup operations like closing files or unlocking mutexes. | |
• Prefer composition over inheritance. Use embedding to include functionality from other types. | |
• Make use of interfaces for abstraction. Define interfaces for the methods you need. | |
• Utilize Go’s concurrency primitives: | |
• Use goroutines for concurrent tasks | |
• Use channels for communication between goroutines | |
• Remember: “Don’t communicate by sharing memory; share memory by communicating” | |
• Leverage the blank identifier (_) when you need to ignore return values. | |
• Use type switches to handle multiple types in interfaces. | |
• Write clear documentation comments for packages, functions, and types. | |
• Avoid unnecessary else clauses. Handle errors early and return. | |
• Use named return values when it improves clarity. | |
• Make good use of the init() function for package initialization when needed. | |
• Remember that semicolons are mostly implicit in Go. Don’t add them unnecessarily. | |
• Use the built-in testing package for unit tests. | |
• Utilize Go’s powerful slice and map types effectively. | |
• Remember to check for nil before dereferencing pointers. | |
• Use the context package for managing cancellations and deadlines across API boundaries. | |
• Follow the principle of “Accept interfaces, return structs” in your API design. | |
• Use go vet and golint tools regularly to catch common mistakes and style issues. |
These rules enabled me to move off of a the pricing 3.7 Claude Sonnet (100b parameter) model and on to the Gemma 4b parameter model.
~GOOD READS BELOW~
Go's Standard Library Insights
Geoffrey Huntley explores Go's standard library design principles, highlighting its elegant simplicity, comprehensive documentation, and thoughtful API design. The article examines how Go's creators balanced pragmatism with innovation to create a language that's both powerful and accessible to developers. https://ghuntley.com/stdlib/
Future of Commercial Open Source
Matt Trifiro discusses evolving business models for open source, balancing community engagement with commercial viability, and strategies for sustainable growth in the changing landscape of open source software development. https://www.heavybit.com/library/podcasts/open-source-ready/ep-9-the-future-of-commercial-open-source-with-matt-trifiro
FOSS infrastructure is under attack by AI companies
Report details how AI corporations are exploiting open-source projects, harvesting code without proper attribution or compensation, while simultaneously undermining the sustainability of the FOSS ecosystem they depend on. https://thelibre.news/foss-infrastructure-is-under-attack-by-ai-companies/
Closing Thoughts: The Symbiotic Future of Developers and AI
AI and human creativity work together through tools like editors and AI assistants that enhance our problem-solving abilities. As you create assistants and configure your workspace, aim to enhance creativity. Good tools help you imagine new possibilities, not just solve problems.
Until next week, I hope your code works well, your tests pass right away, and your AI tools know when to help.
If you find the contents interesting, feel free to comment or share with a friend. Future iterations will focus on me building with AI and reporting my findings. Also, if you know any thought leaders or founders who'd like to discuss AI and open source, please send them my way or forward this email.