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?
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.
I have a directory named “mystuff” that’s gitignored globally, in every repository I work on. This is where I store commands, snippets, scripts, ideas, meeting notes etc. To organize things I find on the web, I simply use bookmark folders in the browser.
In our company we use both github wiki and google drive to share knowledge.
It looks like I need to host my prod environment completely on your tool to make use of the staging feature. I will look more into this though, thanks for sharing. One difference is that in Dockup, we can boot up databases instantly with obfuscated prod like data and we do this because Dockup deployments are accessible by the entire team.
Dockup does have support for this through a feature called "resource pools" which allows you to create external resources and use them in your dockup deployments. This is more involved than simply using the containers, but the support is there for those who think it's worth the effort. Thanks for asking!
Dockup is like Heroku review apps, but for the entire tech stack (each PR gets a dedicated environment with all the microservices in your stack). One benefit of using Dockup is that seeding DBs with prod-like data is easy and works super fast so you don't have to wait around for a long time until you do a pgdump/restore. We can do this in Dockup because we maintain a pool of single-use DBs for your deployments.
Yes, this is possible. By default Dockup would give a random subdomain to each deployment, but some of our customers wanted to use Dockup deployments for giving customer demos so we have added support for long lived deployments that use a specified subdomain.