At $WORK, my team is relatively small (< 10 people) and a few people really invested in getting the codebase (a large Elixir application with > 3000 modules) in shape for AI-assisted development with a very comprehensive set of skills, and some additional tooling.

It works really well (using Claude Code and Opus 4.6 primarily). Incremental changes tend to be well done and mostly one-shotted provided I use plan mode first, and larger changes are achievable by careful planning with split phases.

We have skills that map to different team roles, and 5 different skills used for code review. This usually gets you 90% there before opening a PR.

Adopting the tool made me more ambitious, in the sense that it lets me try approaches I would normally discard because of gaps in my knowledge and expertise. This doesn't mean blindly offloading work, but rather isolating parts where I can confidently assess risk, and then proceed with radically different implementations guided by metrics. For example, we needed to have a way to extract redlines from PDF documents, and in a couple of days went from a prototype with embedded Python to an embedded Rust version with a robust test oracle against hundreds of document.

I don't have multiple agents running at the same time working on different worktrees, as I find that distracting. When the agent is implementing I usually still think about the problem at hand and consider other angles that end up in subsequent revisions.

Other things I've tried which work well: share an Obsidian note with the agent, and collaboratively iterate on it while working on a bug investigation.

I still write a percentage of code by hand when I need to clearly visualise the implementation in my head (e.g. if I'm working on some algo improvement), or if the agent loses its way halfway through because they're just spitballing ideas without much grounding (rare occurrence).

I find Elixir very well suited for AI-assisted development because it's a relatively small language with strong idioms.

This exactly matches our findings: if we start molding the repo to be "AI native" whatever that means, add the right tooling and still demand all engineers take full responsibility for their output, this system is a true multiplier.

I also have Copilot and Cursor bugbot reviews and run it on a Ralph wiggum loop with claude code. A few rounds overnight and the PR is perfect and ready for a final review before merging.

I do run 4 CC sessions in parallel though, but thats just one day a week. The rest of the week is spent figuring out the next set of features and fixes needed, operational things, meetings,feedback, etc.

> I don't see the point of Elixir now. LLMs work better with mainstream languages which make up a bigger portion of their training set.

I can't say if it works better with other languages, but I can definitely say both Opus and Codex work really well with Elixir. I work on a fairly large application and they consistently produce well structured working code, and are able to review existing code to find issues that are very easy to miss.

The LLM needs guidance around general patterns, e.g. "Let's use a state machine to implement this functionality" but it writes code that uses language idioms, leverages immutability and concurrency, and generally speaking it's much better than any first pass that I would manually do.

I have my ethical concerns, but it would be foolish of me to state that it works poorly - if anything it makes me question my own abilities and focus in comparison (which is a whole different topic).

I feel the same way. The only way I found that lets me cope with this is by having 1-2 personal projects, closed source, with me as the only user, where I slowly build things the way I enjoy, and where the outcome is useful software that doesn't try to monetise at the expense of the end user.

I think your last sentence is the key point - the times I've used bisect have been related to code I didn't really know, and where the knowledgeable person was not with the company more or on holiday.

Exactly. And even if I do know the source pretty well, that doesn't mean I'm caught up on all the new changes coming in. It's often a lot faster to bisect than to read the log over the month or two since I touched something.

Even so, normally anything like a crash or fatal error is going to give you a log message somewhere with a stack dump that will indicate generally where the error happened if not the exact line of code.

For more subtle bugs, where there's no hard error but something isn't doing the right thing, yes bisect might be more helpful especially if there is a known old version where the thing works, and somewhere between that and the current version it was broken.

Or they were barking up a wrong tree and didn’t know it yet, and the rest of us were doing parallel discovery.

Tick tock. You need competence in depth when you have SLIs.

Note that the scope of the project goes beyond CDs, it's a catalogue for pretty much any format where you can play music.

> Even with a significant amount of time double checking and fixing the metadata, I consider it a good use of time. I was not simply ripping my CDs, I was helping maintain the historical record.

This is the spirit - I've started doing the same for releases that don't appear in MusicBrainz and it feels great knowing that I'm not just doing this for myself.

I use MusicBrainz and donate every month - yeah data is not perfect, but you can go and fix it yourself if needed, and the UI is extremely functional without any frills.

I’m still working on my physical music management application.

It integrates with MusicBrainz and Last.fm, so that I can easily add records, scrobble them, and search/track stats.

I want to figure out how to track availability for records I want to buy, which would involve interacting with marketplaces.

Using Elixir, SQLite and Phoenix LiveView, which is what I know best and lets me focus on UX and UI.

For a few months I've been working on an application to manage my physical music collection. Records I own, records I want to find, with some stats/search/metadata that actually use.

It's built with Elixir and Phoenix LiveView, backed by SQLite. Records are imported via MusicBrainz, and data enriched via Last.fm.

I'm looking now to add notes for each artist and record, along with arbitrary associations. Think supergroups, side projects, etc. and some trivia/quotes/stories that I can easily add for my own reference.

Claudio Ortolina

  Location: London, England, UK
  Remote: Yes
  Willing to relocate: no
  Technologies: Elixir/Erlang, JavaScript, PostgreSQL, SQLite
  Resume: https://www.linkedin.com/in/claudioortolina
  Website: https://claudio-ortolina.org
  Email: cloud8421@gmail.com

I’m a software professional with 15 years of commercial experience in complex web applications, apis and highly available distributed systems.

I’ve worked both as an engineer directly building products and as a manager at different scales, with my last work experience as a CTO for an industry-leading document company.

I'm coming back from a year-long sabbatical where I focused on my family.

I'm looking for a product development role (so no management) where I can also train/coach other engineers, in a company that values taking part in the development community of the tools they're using.