knighthacker

Nice. That need was one of my initial inspirations for AQ as well. The VPS plus dropped-connections part of your story is very familiar. Two things mattered most when I worked on this same problem:

first, persistence has to live server-side (tmux or equivalent), so the browser tab is only a view and never the owner of the session; if the tab dying can kill work, mobile use stays fragile.

Second, on your security question: the relay path sees every keystroke and whatever secrets scroll through the terminal, so I'd frame it as custody rather than transport. Keep credentials only on the executing machine, make any shareable view a short-lived, token-scoped link with an explicit revoke, and treat Tailscale-first as the default rather than the fallback.

Disclosure: I'm building AQ (aq.dev), which lives in this same problem space (agent sessions that keep running after you close the laptop, joinable from a browser), so I've spent a lot of time on exactly these two questions. We compared the options, including the plain VM plus tmux route, here: https://aq.dev/guides/keep-claude-code-running-after-closing...

Hope-Driven-Development lol

We're growing very rapidly. So honestly, standup meetings now became the most important meeting and "definitely not a standup". A lot of product/customer things are decided during the call, engineers, PMs, and everyone really demos what they've worked on and questions are asked and answered during that call.

Code reviews are gone. We review the coding session itself instead. Everyone shares their coding sessions with whoever is going to review and the reviewer engages with the CLI to ask questions.

Disclosure: I'm building AQ (aq.dev) around exactly this workflow, so I'm biased. Longer write-up of the review approach: https://aq.dev/guides/reviewing-pull-requests-from-ai-agents...

I'm 100% fully in the cloud and strongly recommend it to others. I'm building (AQ.dev) so I'm obviously biased, but almost every single one of our customers ends up bringing their own VMs to the platform instead of using the Managed solution. There's definitely a pull in that direction in my opinion.

We still create a ton of end-to-end tests and run them a lot. What changed for us is the review process. While our whole team uses agents to do reviews, we also ask other team members to review the coding session itself rather than the diff. That team member can ask the coding session questions about the architecture decisions, scalability, edge cases, ..etc.

Disclosure: I'm building AQ (aq.dev), which is partly why I'm deep in this. We wrote up the session-review practice here: https://aq.dev/guides/how-to-review-an-ai-coding-session/. The practice works with any agents too, nothing tool-specific about it.

Microsoft just shipped something literally called the Agent Framework Harness, plus a "build your own agent harness" tutorial series. The harness is officially a product category now.

Their harness is the loop around the model: tools, memory, approvals, the plan/execute cycle. Necessary. And still single-player.

The part no SDK ships: where that loop runs and who can see it. A coding agent session your whole team can open, watch, and steer is a different layer entirely.

Disclosure: That is the layer we build at AQ (aq.dev): the multiplayer coding harness. Fun watching the vocabulary catch up.

I'm not against open source. However, if I were to guess, I think less than 1% of people actually review, let alone modify the open source projects they use. I don't really buy this argument.

I think we're seeing a new modality of openness now with open weights, or being able to modify agents with md files, skills, and so forth.

Love seeing this direction along with Buzz.

The hardest problem in multiplayer agents, at least for us, has not been the agent loop. It is scoping and QM's per-person scopes plus shared rooms is a sane answer for a company-wide assistant.

I build in the adjacent lane, AQ (aq.dev), a multiplayer coding harness where teams run Claude Code and Codex together), so seeing YC ship "a multiplayer agent harness for work" is validating and a little surreal.

It hurts my eyes looking at this haha .. but that's different than the actual harness as we know it tho! Given their ecosystem, they'll always control the CI/CD part of it, which is fine. It's just painful to use XCode to get anything done anymore.

Since we stopped writing code and started writing prompts instead :)

Buy vs Build? Buy. They need this yesterday. Xcode has gotten so bad. It's not even funny anymore.

look into .worktreeinclude

Agreed. I had to solve this at the harness layer myself. It just makes more sense to me this way. We basically created hooks around these operations and you can configure what happens at these calls.

Disclosure: I'm building AQ (aq.dev) a multiplayer coding harness.

I'm a huge proponent of that with my team. We stopped doing PR reviews and instead do session reviews. It just makes so much more sense now. It's more important to understand the conversation, context, decisions made, why were they made that way, and so forth. More than the lines of code themselves, especially with the massive increase in PRs volume.

Wrote about it here: https://aq.dev/guides/how-to-review-an-ai-coding-session/ and how we do it here: https://aq.dev/guides/how-to-review-an-ai-coding-session/

I hope this helps.

Disclosure: I'm the founder of AQ.dev

Ugh .. what do we do now? jk

I'm obviously biased, but I'm building aq.dev, a shared workspace for running coding agents with a team, so I watch a lot of people's sessions more than my own haha.

If I'm between meetings, then I'm really watching 1-2 max. There could be a few others running in the background, but those I'm not paying attention to that much.

If I'm coding and in the zone, then usually 4-5 workspaces with 1-3 agents per workspace.

Local AI is going to win. Not because it's cheaper btw.

The most interesting part is Boris' recommendation to delete your Claude.md every 6 months to see what the model is capable of. The link in the post sends you directly to that moment.

I'm thinking a lot about this recently as I'm building AQ.dev (Multiplayer coding harness). My instinct is to keep it simple and not trying to do too many shenanigans with these files and let engineers maintain control.

Yup. That's pretty much the most interesting part.

The scanner is the least interesting part of this. The harness around it is the product: dedup across runs, false-positive tracking, budget controls, CI gating. That is the layer where we'll see most interesting innovations in my opinion.

I'm building AQ, a coding harness for teams and the pattern is identical. For a while, I thought the raw model is the answer and quickly changed my mind. Purpose built harnesses are way more powerful than it sounds.

This is where Opus 5 shines

There's probably a ton of intangible factors to this, but how do you measure the ROI on this?

Nope. You can easily refresh/retake the interview.

We've designed BetterLeap to simplify and enhance the most painful and complicated part of career development — job search. So whether you're just beginning your journey, or are actively looking to transition, I hope that you find your experience with BetterLeap to be refreshing.

Today we're launching One Interview, a tool that helps you unlock new opportunities with one comprehensive interview. Essentially, you can now interview once, apply everywhere.

Getting started is easy:

- You schedule a time with us.

- You go through an adaptive and personalized interview.

- You get matched with companies that are ready to hire you.

One interview allows you to connect to many companies at once and, ultimately, to put your job search on autopilot.

We currently only support frontend, backend, and full-stack engineering roles but we're onboarding new roles regularly. So if you're looking for other roles, stay tuned for more updates soon.

We're excited to help you with your job search. In the meantime, we hope you and your loved ones are staying safe.

NOTE If you're a company that's hiring and growing your team, apply to join our one interview program.

Amazing founder and a great company. I’ve worked for and with him before in prior ventures. One of the most intelligent and sincere people I’ve ever met.

Airbnb Payments | Engineers and Data Scientists | Full-time ONSITE (SF)

At Airbnb, we want to create a world where anyone can belong anywhere. And we’re just starting.

The Airbnb Payments team empowers people and communities to participate in our global marketplace. We transmit billions of dollars, in real-time, and in 70+ currencies in over 190 countries around the world. We want payments to be simple and transparent, yet invisible and comfortable. Less transactional, more human.

We’d love to grow our team with people who are excited by operating at a global scale, creating frictionless experiences, and empowering millions of entrepreneurs.

Check out the story behind Brian Chesky’s first Airbnb payment here: https://youtu.be/Mssx8PleeYc

Come innovate on the future of payments: https://www.airbnb.com/careers/departments/engineering/payme...

My advice is to realize that you are hired as a leader in the organization. Use your leadership to change what needs to change so that the company succeeds. An important factor for the success of the company (as long as you are still hired there) is that you are doing what you love doing and what helps the company, because it'll make a big impact. If you like writing code and write 2 lines of code, it'll raise the morale of the team and get them motivated to work more.

What I am trying to say is assume your leadership and do what you want to be done. If the company likes it, then great. It is a win-win situation. If not, then next steps are clear.

Thank you very much. The need is certainly there, and we are happy to address it.

1. The way I think about it is that you have a goal/vision for why you start the project. Having a co-founder is very important and necessary to achieve this goal because your business will run into a number of roadblocks that you need a partner to help you go through it. However, whether or not your co-founder works as hard as you is really irrelevant.

You said that you are doing well financially and aren't starting these projects because of money. Then who cares if you "only" get 50% of the company? Your goal and intention is to solve a big problem. Get focused on that. The world is gonna pay you back in so many other ways than your 50%.

The other piece of advice is try to be really picky with your co-founders. Find ones that you trust and have worked with before or can get amazing references about. That way you know that he'd do his job the best way possible regardless of how many hours he puts in.

I hope this helps.

I am glad to hear that you are using Perl at Semantics3. I like what you guys are doing :)