For environments where you want people to access your local instance, I believe Iroh will be a game changer. For us, it's to allow control over our software through phones and other devices easily.

Previously, you might have to make sure they're in the same LAN network. But with Iroh, anything works.

And if they can make an argument about why they're more effective without AI, more power to them. So if I were to ask the question directly as you suggest, it would be: Are you more effective than the other person I'm interviewing? - which i guess is the whole point of the interview.

> Heroin Fair point, but I also don't think that trying AI is anywhere close to the level of trying Heroin

In this case though, I'll admit that it would be a negative signal if they never tried it even once and refuse to do so. You can't make a solid opinion on things you never try after all. It would be different if they at least gave it a shot and disliked it.

From the 3 people I interviewed, all of the answers are very similar which is along the lines of: Kinda, but we need to be careful of using it, privacy, hallucination, etc.

All very safe answers and doesn't say anything new to me. If they had been more specific about why and their experiences with it, I'd probably favor them more due to their experience with it. It'd also signal to me that they form their own opinion rather than simply following the crowd.

I also recently moved to 4.6 since I started hitting the context limit too often with my current project.

And if you already know the material explained by the book, yes i don't need to write it to understand it.

The repo is complex but at its core, this is software to record execution without the performance & storage penalty that would usually come with recording all of production.

To do that, they need to make sure that they record anything this is not deterministic, while leaving code that is deterministic to be executed during replay time.

To be honest, I think this is a really hard problem, almost impossible I'd say. There's just so many things that can cause the same execution to cause different results. But last I've seen, the team is slowly squashing each of the edge cases. I think they've now gotten it to be quite stable.

If everything goes well, this is very exciting and I think can revolutionise how we debug production code as an industry. I unfortunately don't run Python code so I can't meaningfully test this. Here's hoping it takes off and one day it'll be ported to the languages I use!

If some component doest benefit from being extensively tested, then it's still the same today. The difference is now it's so easy to generate something, no matter how useless it is. Worse part is, no one cares. Test passes, it doesn't affect production, line coverage increases, managers think the software is more tested, developers just let a prompt do everything. It's all just testing theatre.

I think E2E is the more important than ever. AI is pretty good at getting the local behaviour correct. So unit tests are of less value. Same can't be said for the system as a whole. The best part is, AI is actually pretty good at writing E2E tests. Ofc, given that you already know what you want to test