emilsoman

> In your case, positioning yourself as a cheap provider is inherently a bad idea.

Why is that a bad idea? When the providers have the same features, wouldn't the customers choose the cheaper alternative?

How does it compare to agent-vault and clawpatrol?

> I've tried (and failed)

Why did it fail?

Can you share something that you found nice?

Curious, what's the career path you'd chase? Can you give examples of some work that you think Claude will never be able to one-shot?

That's cool, but they say the code execution would wait till the tool call is done. Would they be just keeping the code execution process alive? That seems like a bad idea given tool calls can take an unknown amount of time to finish. I am guessing they would be putting the python orchestrator code to sleep when the tool call starts and restoring the state when the tool call is done.

> The script runs in the Code Execution tool (a sandboxed environment), pausing when it needs results from your tools. When you return tool results via the API, they're processed by the script rather than consumed by the model. The script continues executing, and Claude only sees the final output.

Anyone knows how they would have implemented the pause/resume functionality in the code execution sandbox? I can think of these: unikernels / Temporal / custom implementation of serializable continuations. Anything else?

> You may not have time for your actual responsibilities.

In your opinion, what are the actual responsibilities of a CTO?

From your point of view, what's the approach taken by someone who rose to the rank? Is it mostly people and process management and less to do with tech?

> do you find yourself developing the MVP of a particular feature to "get water through the pipes" and then handing that off to some other team to get it to "production ready"?

I liked your take and curious to know what you think a CTO should be doing here

> What kind of code “looks good” to you? What kind of code “looks ugly”? IMO this is not taste, it's your pattern recognition skill based on what you think is better in terms of correctness, performance and maintainability.

> Which design decisions you feel really good about, and which ones are just fine? It's not just a feeling, it comes from reasoning.

Good taste == good skill isn't it?

When someone chooses a functional lang over an object oriented one - is this because of better taste? They’ve learned, through experience, what kinds of problems map more cleanly to immutability and composition versus encapsulation and state. Their "taste" for one paradigm over another is just a reflection of the skills they’ve built up in recognizing tradeoffs, debugging pain points, and anticipating long-term maintainability. What looks like taste is really just expertise shaping intuition.

I get why the author feels a team member who doesn't align with the team's goals has bad taste. But it's really just this - the opinions they have formed from their experience don't match yours.

Which are some books focused on IRs you’d recommend?

Love the feature where creators can message their supporters. Congrats on the HN launch!