Cursor, Sourcegraph Cody, and honestly just Claude with a well-maintained project README already solve the "ask questions about the codebase" part reasonably well.
The actual hard part of joining a new team isn't the code (today, any longer). It's getting to know the people. Understanding their strengths, figuring out where you fit in, getting past imposter syndrome, not stepping on toes. No AI for that yet.
My take after running engineering teams at multiple companies: documentation survives when it lives next to the code. File-level header comments explaining each component's purpose and role in the architecture. A good README tying it all together. If you compartmentalize architecture into folders, a README per folder. This works for humans, LLMs, and GitHub search alike.
ADRs, Notion docs, and Confluence pages die because they're separate from the code. Out of sight, out of mind.
If you want to be really disciplined about it, set up an LLM-as-judge git hook that runs on each PR. It checks whether code changes are consistent with the existing documentation and blocks the merge if docs need updating. That way the enforcement is automated and you only need a little human discipline, not a lot.
There's no way to avoid some discipline though. But the less friction you add, the more likely it sticks.
> documentation survives when it lives next to the code.
15+ years ago, this was pretty much the standard. Every decision - whether major or just a hack to handle a corner-case - used to be recorded in the code itself. Then tools like Jira and Confluence came in and these things moved to undiscoverable nooks and corners of the organization. AI search tools like Glean and Rovo have improved the discoverability, though I'd still prefer things to remain in the code.
I've been a CTO and founder several times. The bottleneck was never "getting the work done." It was always translating between the business reality (runway, revenue, growth, what customers actually want to pay for) and what the team needs to hear to build the right thing. That translation layer is hard, time consuming, and easy to get wrong.
I know plenty of founders who are great engineers, product thinkers, and salespeople. They still hire people to manage teams because there are not enough hours in the day to do it all themselves, even if they could.
If you're the person who understands the business, understands the customer, and can turn that into clear direction for the people building the product, whether those are humans or AI agents, you will be hard to replace. That's not project management as "status updates and Jira grooming." That's a fundamentally different and more valuable skill.
I worked on lab automation and scientific software early in my career. One piece of advice: keep it ruthlessly simple. In most software a bug is a bad UX. In scientific software a bug can mean contaminated samples or months of invalidated research. Every unnecessary abstraction is another place for something to go wrong silently.
I was part of building the streaming frontend for one of Sweden's largest broadcasters in Rails about 10 years ago. Handled 1M+ concurrent users on Heroku with horizontal scaling. Fun fact: someone on the team literally stayed up monitoring traffic during big live events. It worked. Rails was a great fit for that especially at the time.
I moved on, not because Rails failed me, but because the things I started building next (Streaming infra, APIs behind proxies, lots of concurrent HTTP work, infrastructure tooling, AI/ML) just fit better in other languages. I pick tools by the problem, not loyalty.
What I notice in this thread is a lot of "Rails vs X" framing when the real answer is boring: use Rails (if you like the vision and Ruby) when the complexity is in the data model and business logic. Use something else when it's in concurrency or infrastructure. The one-person-framework pitch is real, but it's for a specific shape of problem.
Also: God i miss writing Ruby, its a fantastically and beautiful language.
Also: Blast from the past: Ruby is a great DSL for Rails.
Good advice that I keep trying to adopt myself, but I have to confess a large personal bias for languages that I like, even if it keeps me from certain classes of problem (I like Ruby, though).
What did you move onto for those next things you started building?
I know that feeling. Just because a tool is good doesn't mean you enjoy using it.
I moved deeper into streaming infra with Python, C/C++, Go, and funnily enough Elixir. Then a complete path change into fintech and later AI/ML, which meant a lot of JavaScript/TypeScript and reluctant Python. I appreciate the Python ecosystem but find the language itself ugly to read and write. Always a last resort for me.
Today it's mostly TypeScript, Go, and Lua.
Ha, I can relate WRT Python. I've been doing more Elixir these days for both a really pleasant web experience and because it has some unique primitives baked into the ecosystem that most JVM projects I work on spend a lot of time approximating through grotesque frameworks.
Ha, same. I wrote a VOD transcoding orchestrator in Elixir that triggered libav transcodes and custom packaging code in Python. Loved the syntax, and in particular the pattern matching in function headers. It was so clean for recursive branching that I ended up favoring recursion over conditionals and loops everywhere. Whether that was overuse or just good taste is subjective.
We did hit a real scaling problem with the BEAM though. Distributed Erlang uses a full mesh, every node connects to every other node. When we got close to 50 nodes the inter-node communication overhead was eating a significant chunk of our CPU. Adding more nodes started giving diminishing returns because the mesh traffic grew faster than the compute we gained. Interesting constraint that I haven't hit in any other runtime since.
reply