reactiverobot

i like to work via Plans in ref.tools

first I jot down my notes then I work with one agent to write a plan. this is just the first draft.

Once I have a draft, I start to leave comments to ask questions and launch multiple agents to research and refine parts of the plan.

(optionally share the plan with my team for feedback)

then have multiple agents work on implementing parts of the plan

Ref is great for this because it can orchestrate agents and you can track all the progress on one place. It's hosted so you just work from a browser like Google Docs but can connect to local agents too

haha that visual is perfect

thank you! yeah it's all about the right balance :D

Hi everyone, I’m Matt, founder of Ref (https://ref.tools). Ref is the shared workspace where engineering teams align on what agents should build before code gets written.

Every engineering team is battling the same problem. We call it Velocity Sickness. It's the disconcerting feeling that you're moving fast but not having the impact you expect. It's affecting individuals, teams and especially leaders.

It looks like: - Too many PRs to merge. - Brainfry and burnout. - Engineers running in different directions. - Critical decisions being made by agents.

The last one is the most dangerous. At its core, software engineering is about two things: (1) what decisions matter for my system? and (2) making those decisions. When you let agents make critical decisions, you lose ownership of your system and product.

You solve these problems with Ref.

The art of modern software engineering is balancing pre-work vs re-work.

Our existing tools jump us straight into implementation and re-work. Ref is a tool for the decision layer and works with all your existing implementation tools and agents.

And because this is hackernews, I want to be super clear: I am NOT saying “never read the code”. Not yet, anyways.

ref-tools-mcp is similar and does support openai's deep research spec

Hi! I'm the developer of Ref (https://ref.tools), the MCP server for giving coding agents access to public and private docs. Ref's goal is to provide exactly the tokens you need to guide the model and nothing else.

I've been working on this one MCP server for about 6 months and I wanted to share the ways I've used and considered using different MCP features. If you're new to MCP, I hope this article can give you a sense of how developers can leverage MCP in practice.

Repo: https://github.com/ref-tools/ref-tools-mcp

And because I get asked this ALL the time : how is Ref different from Context7? - Ref uses on avg 55% fewer tokens with the same or better accuracy (eval blog post: https://ref.tools/blog/how-make-search-good) - Ref allows indexing your own private github repos and pdfs - Ref is a paid product with 200 free searches to start

I appreciate you taking a look!

Hi! I'm the developer of ref.tools. Would love to know what you're searching that you couldn't find, very occasionally things are missing from the index. Drop me a line at matt@ref.tools

Also FYI a bunch of search quality improvements dropped this week so you might want to try again. :)

Thanks I appreciate the kind response! The fun and nerve wracking thing about posting on hackernews - I get takes I never would have expected lol

I'm surprised you took away from this that I think the goal should be making more humans because that's not what I believe and not what was I was trying to communicate. I don't think there is one "goal" to life and this article was in now way about goals but I'm glad you have such a sense of purpose for your life! I wish you well in that too!

Just because you mention it though - its a false dichotomy that creating more lives is at odds with improving the lives of the current existing people.

A little nervous sharing since last time I posted some personal writing on here I got flamed to the front page, hopefully I don't offend anyone this time :)

lol true.

Yeah you're right a months long process would be horrible!

Fortunately, that didn't happen in this case. Part of building a team is getting to know talented people before they're looking for a job so when they're ready they reach out to you.

And you're right, this is work, not dating. But that doesn't remove the human emotion involved in getting to know someone.

Yes! You're right! That would be way too long for an interview loop. I'm sorry I wasn't clear in the article.

The candidate and I first met long before they were interested in interviewing. They had potential and I got to know them so that when they were interested in interviewing they'd reach out. Once they decided to interview, we made that happen as quickly as schedules allowed!

Hope that clarification helps! Thanks for the note!

It sounds like you understand the burden of being an interviewer!

Can you share a little more about what made the decision emotional or impulsive? I'd love to make sure my writing is clear and it sounds like it wasn't. While building a relationship with a candidate can be emotional, we always use a standardized rubric to evaluate candidates. Even with a rubric the decisions can be hard!

Thanks for the note!

I can't share the specifics of feedback but you're right that's the most interesting part of this decision and where I could learn the most. Ultimately, it's a hard to reverse decision with imperfect information and that's why it can be so emotionally tough.

Thanks for the note!

That's a really good analogy that the longest rollercoaster is 4 minutes. You're absolutely right that a months long interview process would suck. Fortunately, that wasn't what happened. I've added an amendment to the story to clarify, take a look!

I obviously can't go into the details of the feedback but I share your wish that hiring decisions would more cut and dry! It would be a lot easier for everyone.

Thanks for the feedback!

Hey everyone, it's the author here! Many of you have made an inaccurate assumption about something that I should have clarified in the article.

As a hiring manager you do cold out reach and meet people well before they are ready to look for a new job. You build a relationship over time so that when they are ready for a new job they reach out to you. That's what happened in this case.

I appreciate the feedback that I was not clear about that. I agree with you all that spending months actually interviewing is horrendous and unfair.

Let me know if you have more questions or thoughts!

Good question. ;)

Not sure that solves the same problem (but I'd love to hear how you recommend I use it if it's better :D).

The scenario I built Peep for is when I have a long chain (either internal or with a client) there's often a ton of information built up. I wanted a way to turn a thread into an artifact which is easy to ready and share.