Interestingly, I don’t know Kotlin, Swift, iOS, or Android development. And for that matter, I’m not even a musician!
This app is a companion tool for the ukulele, a music instrument I recently started learning. Building it was a fun experiment to see how far AI-assisted development can go.
It’s amazing how accessible software creation is becoming.
Built Ukulele Companion, an open-source Android app for learning Ukulele, with AI.
It includes fretboard/chords/tuner/scales/progressions and is fully offline, ad-free, and no-tracking.
Would love feedback on practical workflows for keeping AI-generated code clean and maintainable.
I built Prompter to help automate repetitive code maintenance tasks using Claude AI. It lets you define workflows in TOML files that can execute sequentially or conditionally based on task outcomes.
Key features:
- AI-powered project analysis that generates initial configuration
- Session resumption to maintain context across complex tasks
- State tracking for interrupted workflows
- Support for Python, JavaScript, Rust, Go
Example use case: You can create a workflow that updates deprecated APIs, runs tests, and only proceeds to the next modernization task if tests pass. Each task can retry on failure or jump to a different task based on the outcome.
The tool uses the Claude SDK to execute tasks while maintaining context between steps. It's particularly useful for large-scale refactoring, security updates, or incremental code quality improvements.
Would love feedback from anyone dealing with technical debt or large codebases that need systematic updates.
Disclaimer: This project is developed using Claude Code.
That's a very fair and critical point. You're right that we can't change the fundamental, probabilistic nature of LLMs themselves.
But that makes me wonder if the goal should be reframed. Instead of trying to eliminate errors, what if we could change their nature?
The interesting hypothesis to explore, then, is whether a language's grammar can be designed to make an LLM's probabilistic errors fail loudly as obvious syntactic errors, rather than failing silently as subtle, hard-to-spot semantic bugs.
For instance, if a language demands extreme explicitness and has no default behaviors, an LLM's failure to generate the required explicit token becomes a simple compile-time error, not a runtime surprise.
So while we can't "fix" the LLM's core, maybe we can design a grammar that acts as a much safer "harness" for its output.