lowenbjer

Ah, nice analogy! The way you describe it makes sense, I need to read up on the topic. Chain of Thought, is that what I should look for?

Yeah i tried that but I did not get it to work consistently.

It feels like it took the styles as suggestions rather than rules to enforce.

How has it been working out for you in longer conversations?

I too think there is a fallacy in automatically attributing longer texts to hold more information.

While i understand your reasoning here, and while I can't produce any proof that that supports my claim that it doesn't, I still would like to share my experiences after using terse personally for a couple of weeks, and those are that I have not noticed the degradation in output quality that you are describing. Quite the opposite, as my interactions use up less context space, my guess, i find that accuracy has increased rather than decreased.

How so?

Yes, exactly that, so there's refined writing instructions in the system prompt and a reminder with a compact version of the rules injected every turn from a UserPromptSubmit hook.

I agree, how i use it i don't want it to be creative or help me think unless i ask it to do so. I'm using it to DO work.

Yes! Some of my benchmarks was against Opus 5.5, and it reduced output over 50% on vanilla settings. Check repo for data.

I struggle with the way Claude speaks to me when I do work. So much text, every, single, time.

When I ask a question, I get an essay back, and with so many weird constructs: slogans, metaphors, recaps, strange choice of nouns, "it's not X, it's Y".

Claude's own "concise" mode shortens it, somewhat, but keeps the the rest of the slop.

I tried system prompts, those got forgotten after a couple of turns. I tried looking for plugins but none consistently made Claude speak normally. Some where slash commands, other solved for token use, others solved for neurodivergence.

I just wanted to not read an essay and make Claude get to the point fast, every single time.

Is that so much to ask? Apparently; it took me weeks of trial and error to make something that worked for me, I have stories, but I'm sharing it as a claude code plugin with you, those of you who struggle with Claude, the same way I did.

Fair enough! Can't argue with that

I tried tidal for the Lossless (dont care about the 24bit, i care about no EQ and compression added to music) but i went back to spotify for their recommendation model. Its a moat for me.

Fair point, for me there is no scrolling required though, its like nr 3 in the list.

I wonder how long it will take for AI to learn how we work with software on an individual level and adapt the UI to fit our usage patterns.

I get that it looks bad to have vibe coding bugs creeping into your codebase for such a big company, but isn't it common sense that owning your misstakes taking accountability for them generates respect?

Three dots next to the song title, menu opens, "Add to Queue", done.

"the spotify subreddit is actively removing discussion of the problem"

This sounds like terribly bad form, won't buy them any goodwill down the line.

Agree!

Check back in 2 years time, for now it has survived fine. Someone will be tuning it to write the documentation soon, instead of just blocking!

Jokes aside, i think LLMs will enable us to handle information in a much better and smoother way. We should use them!

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.

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.

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.

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.

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.