FedericoAlcantara
Successful development with local AI setup
Hi guys,
I’ve been running Qwen locally for the last two weeks using an opencode + Ollama + qwen3.6:35b-A3B setup with q4_k_m quantization on a MacBook Pro M2 Max (32GB RAM).
My development workflow is heavily GitHub-centric: GitHub Issues and PRs are the source of truth and, in many cases, effectively act as the issue/PR state store.
To improve reliability and maintain consistently high code quality, I’ve been building a set of “skills” that act as boundary setters, orchestration layers, and quality gates.
Current skill set (still evolving):
Issue Lifecycle Skills
| Skill | Target Model | Description |
|---|---|---|
improve-issue |
opus |
Enriches a raw GitHub issue into a precise, implementation-ready specification persisted directly in the issue body. This is always the first step before coding. The generated spec includes explicit Acceptance Criteria (AC). |
evaluate-issue |
sonnet or qwen |
Sizes an enriched issue and recommends KEEP, COMPLETED, or SPLIT, including the recommended model tier for execution. |
orchestrate-issue |
sonnet or qwen; opus for complex tasks |
Runs the full implementation → review → correction loop for an enriched issue. When the issue is considered done, it automatically invokes pr-from-issue. |
pr-from-issue |
qwen or haiku |
Opens a PR from a completed issue, validates the “ready to be closed” marker, and executes the full test gate beforehand. |
The most interesting skill is probably orchestrate-issue, since it behaves as a controlled execution loop coordinating multiple sub-skills:
Implementation & Review Skills
| Skill | Target Model | Description |
|---|---|---|
code-issue |
sonnet or qwen; haiku for trivial tasks; opus for complex ones |
Implements every Acceptance Criterion from the enriched specification (or unresolved review gaps) in an Elixir/Phoenix/Ash codebase, including tests. |
review-issue |
sonnet or qwen; opus for complex reviews |
Performs a senior-reviewer pass over the implementation. Runs mix precommit and mix test, evaluates implementation coverage against the specification, and writes identified gaps back into the GitHub issue using a structured review marker block. |
After the PR is generated, I manually review it and add comments for anything that should be discussed, improved, or refactored. If further work is needed before merging, I invoke an additional skill:
PR Review Resolution
| Skill | Target Model | Description |
|---|---|---|
address-pr-review |
sonnet or qwen |
Resolves PR review comments, updates tests when necessary, and iterates until the review state is acceptable for merge. |
The whole system is still evolving, but at this point it’s already producing surprisingly high-quality code with a fairly reliable workflow.
Performance is actually very good locally, although I do need to keep background activity to a minimum — typically just one Chrome tab open, while Docker and PostgreSQL are always running.
Next step is to separate the testing generation from the code, I’ll probably use a agent swarm…
I’m curious whether others here are experimenting with similar AI-assisted development workflows around Elixir/Phoenix/Ash projects, especially with local-first setups.
Most Liked
Vidar
I am certainly experimenting with all things Elixir, Rust and to some degree other languages and aspects (C, Zig, microcontrollers, Nerves, various UI interfaces, industrial network protocols, camera controls, video streaming and using/ tuning AI).
The Elixir and Rust has come the furthest where basically the setup is a using various skills for planning and implementing with hooks forcing use, and with a static code analyzer and a review skill to find, interpret and fix any issues. Do this with TDD active and reiterate until done, then a loop with feedback for the skills, hooks and analyzer. This works surprisingly well. It could use some outer framing for the rest of the environment, but so far looking good and steadily improving.
On the local level I have an old NVidia Orin 64GB just sitting about for the most part, so I play a bit with local ideas on that one.
Vidar
I use Claude even for making requirements. Instead of trying to nail all the requirements up front I rather go in early and just document what I got. Then a stepwise plan, and during the implementation I use Claude and the process to fill in the weak spots, do active exploration of alternatives, comparison tests, metrics, etc and documenting it all.
This ends up with a working prototype and with both me and Claude knowing more about the problem space. It clarifies what works well, what doesn’t, and any unclear areas or wrong assumptions from the initial requirements.
Then I iterate and start a new version based on that. The second time is always better. It is based on better information so the project documents are more specific and known to work. LLMs make it easy to iterate over even large problem spaces so this workflow got more viable. And the results are better for it.
That is interesting. Sonnet is quite capable, so I might have to look again at Qwen one of these days. Even if slower a capable local solution would be useful.
Popular in AI / LLMs
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #javascript
- #code-sync
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








