brightball
I’ve been enjoying great results on my personal projects using AI tools with Elixir recently, thanks largely to the guardrails that are available to provide great structure to a developer. I wanted to share my current default precommit task and see if any of you have suggestions to improve it and/or for anyone else to use on their own projects.
My default stack at this point is Elixir, Phoenix, Ash, LiveView, PostgreSQL and TailwindCSS. I find that the structural consistency of Ash is an excellent guide for coding agents.
Anyway, here it is. Let me know if you have suggestions, thoughts or questions.
precommit: [
"compile --warnings-as-errors", # Fail compilation if any warnings exist
"deps.unlock --check-unused", # Fail if unused dependencies are unlocked
"deps.audit", # Scan dependencies for known security vulnerabilities
"cmd mix hex.audit", # Audit Hex packages for retired or vulnerable versions
"migrations.safety", # Check database migrations for unsafe operations
"format --check-formatted", # Verify code matches the formatter style
"credo --strict", # Run strict static code analysis checks
"sobelow --exit --threshold high --skip", # Fail on high-confidence security issues only
"ash.codegen --check", # Ensure Ash generated code is up to date
"usage_rules.sync --check", # Verify usage rules are synchronized
"cmd bun run lint", # If there's JS beyond LiveView
"test" # Run the full test suite
]
Where Next?
Trending in Dev Env & Tools
Other Trending Topics
Latest Phoenix Threads
Latest Ash Threads
Latest on Elixir Forum
Sponsor Spotlight
Bringing learning, work and compliance together since 1987.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #code-sync
- #discussion
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #ai
- #umbrella
- #full-time-contract
- #elixirconf-us
- #podcasts-by-brainlid
- #blog-post
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #elixirconf-eu
- #processes
- #security
- #api
- #forms
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Producing high quality Elixir screencasts since 2017.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 7- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
caleb-bb
I would add some more Credo checks. There are some custom ones here.
You should also look into the Boundary library for your projects.
I don’t see any Dialyzer here, either. I think that, if you’re spinning up a new PETAL stack application in this day and age, you should be rigorous about specs on everything and running Dialyzer. You should also think long and hard about your philosophy on specs. For my part, I define a custom type for every custom struct in my Elixir codebases and any function that takes/returns any custom struct must use the corresponding custom type in its spec. There are also important questions about how you handle specs for behaviours/callbacks, e.g. whether callbacks should have specs or just implementations or both and if so, how those should relate.
Look into PropEr or StreamData for property-based testing if you haven’t already. And make sure your agent contract enforces TDD discipline, i.e. failing tests first and property tests over normal ones.
brightball
I do use Boundary as well! It’s great.
I’ll look at the additional credo checks. That’s a good call out.
When it came to dialyzer I haven’t seen as much benefit since 1.20 with the addition of the compiler checks. It seemed like there was a lot of overlap there. You make strong points though, I’ll re-evaluate.
I’ll check on PropEr and StreamData.
Thank you!
brightball
I’m looking into both of these now and I’m curious if there’s a way to use them together? Particularly to cover this case…
It seems like automatically storing the failure from the stream as a counter-example would be a good idea (similar to how fuzz testers work when they identify data that causes a failure state).
EDIT: Update. I looked into this a little further. Ash actually already includes StreamData and apparently my AI was already using to generate some property tests that I didn’t know about yet. We’ll be doing more now!
srowley
I would love to hear yours/others’ tips for using Boundary. I use it and it is very helpful as a sort of tripwire to force the LLM to tell you it is going to do something not-smart, but I have found that LLMs don’t really get the concept that well and as often as not will try to talk me into working around it as opposed to designing more cleanly. If anyone has some tricks that help them get more out of it that would be interesting to hear.
caleb-bb
My experience using Boundary has been pretty seamless, but I also introduced Boundary fairly early in the current codebase I’m working on. Adding Boundary later on to something with some spaghetti already in it is a totally different challenge.
The way I see it, your app’s architecture should make Boundary basically unnecessary. The AI should, when it looks at the codebase, naturally build without breaking the hierarchy. Boundary itself shouldn’t have to really make this clear. Boundary is more like a tripwire, like you said.
So if the LLM keeps trying to work around Boundary, there’s likely something about your app’s architecture suggesting to the agent that it should do that. You ought to take a look at how your app is built and ask if there are places where kinks in the dependency chain are likely to arise.
Also, how consistently are you using it? Do you have Boundary applied evenly across your codebase? The idea is to define one big dependency graph that makes it obvious what depends on what. Does every module in your app have an obvious place in that graph, even if it doesn’t
use Boundary?If your agent keeps adding things to
depsandexportsthen a rule in your agent contract can help. Something like “Do not changedepsorexportslists for Boundary without human review”. If there’s anything worth human review in your. codebase, it’s this.srowley
That’s really interesting, thank you. I have had the opposite experience! I added it to a big mess and it was helpful as we fixed it. I added it at the start of what I thought was a pretty chalk project, and it made things harder at times. I have more to learn.
beepbeepbopbop
I might add a step that checks for compile loops:
mix xref graph --format cycles --label compile-connected --fail-above 0Adds some rails to ensure that changes to files don’t cause massive compile times.