I use Codex extensively, but mostly as a sounding board for architectural questions. I'll also have it do a lot of boilerplate work, but damn, I don't get these people creating multiple Claude or Codex accounts to burn tokens all day. I still love writing code!
I thought Laravel would've been the one to scoop them up, but I'm glad they landed with Shopify. Adam's a solid dude and what him and his team have done to commoditize web design is to be lauded.
To think it started as a side project and grew to the scale it did. Very impressive work.
Absolutely agree. I could easily afford to hire a lawn crew to cut my lawn, but I enjoy doing it every weekend or two for similar reasons. I have a little under half an acre to mow, but I still enjoy doing it manually with a push mower.
Gets me outside and moving, accomplishes something tangible, can catch up on a podcast or two or just get lost in my thoughts, often leads to fixing other odds and ends around the house I've put off.
I suppose I'm spoiled by the Symfony framework which has a robust Secrets Component [0].
It allows you to generate a public/private key for each environment: test, dev, and prod (by default). The 'prod' private key can't be committed to the repository. Once the cryptographic keys are generated, you can encrypt any secret you want, and the framework will automatically decrypt it and allow you to access it as an environment variable at runtime.
The encrypted values for all environments are committed to the repository. For example, the file for the `$STRIPE_SECRET_KEY` environment variable for the 'dev' environment is a file that has these contents (shortened for readability):
1. Keys for the 'dev' and 'test' environments can easily be shared with the team because their public and private keys values are committed to the repository. No more sharing secrets file over Slack or through some other mechanism.
2. The private key for the 'prod' environment can be stored in a 3rd party vault so it can be made available to the production servers. You can also decrypt 'prod' secrets during deployment to reduce the decryption overhead for each request.
3. At worst, agents would have access to the secrets in the 'test' and 'dev' environments only because they couldn't decrypt 'prod' values locally.
4. It forces good practices to ensure you're not using the same secret value for production and non-production environments.
It's made secret management so easy I don't even give it a second thought. Do other web frameworks support a system like this?
Not the OP, nor do I have any relationship to them, but I've had to build or maintain plenty of these in my time and sure, an LLM can knock out a basic one easily, but there are so many edge cases that need to be accounted for that it gets complex quickly.
Congrats on the launch - this looks like a genuinely useful tool. I look forward to checking it out.
I build software for contractors (plumbers, electricians, HVAC repair, etc) and they're some of the fastest adopters of these systems. I believe YC has even invested in a few.
Regarding the AI receptionists, from the calls I've listened to, there's still a bit of the uncanny valley/overlapping speech issues that I'm unsure are ever fixable just due to latency.
But for low margin businesses like contracting and (I imagine) auto repair where labor is your most expensive cost, these owners are doing anything they can to reduce their overhead.
I recently fired a plumber I was trying to contract for a five figure remodel job because his AI receptionist couldn't understand my address and therefore could not schedule the appointment. After that experience, I will not use a contractor that I cannot personally get in touch with until these systems improve demonstrably.
reply