The same goes for the 1994 first pressing of Marillion's Brave.
Side 4 has a double groove, which would give you either The Great Escape + Made again (a sort of a happy ending) or The Great Escape + 20 minutes of water sounds (which can be interpreted as the sad ending).
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.
> 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.
Socials: - bsky.app/profile/claudio-ortolina.org
Interests: Music, Technology, Web Development
---