ManWith2Plans

I've been using this for some projects. It's exceptional and I recommend it highly.

I actually included a recipe to deploy it to kubernetes in typekro, my TypeScript infrastructure-as-code project for kubernetes: https://typekro.run/api/searxng/

I've been busy building and dogfooding open-artisan for my own development purposes. I've diverged quite a bit from main and am hoping to merge some of those changes back soon. It's basically an OpenCode plugin that forces open-code token-hungry state machine that tries to map the engineering process I follow, exposing only valid tools and states at every step of development. If you're interested, in following along or trying it out, it's available here:

https://github.com/yehudacohen/open-artisan/

Hopefully, I'll merge in my large structural changes in the next couple of weeks. These structural changes will enhance the state machine meaningfully, as well as adding support for hermes agenet.

I agree with this to some degree. Agents often stub and take shortcuts during implementation. I've been working on this problem a little bit with open-artisan which I published yesterday (https://github.com/yehudacohen/open-artisan).

Rather than having agents decide to manage their own code lifecycle, define a state machine where code moves from agent to agent and isolated agents critique each others code until the code produced is excellent quality.

This is still a bit of an token hungry solution, but it seems to be working reasonably well so far and I'm actively refining it as I build.

Not going to give you formal verification, but might be worth looking into strategies like this.

I appreciate that!

Author here. Didn't realize this went a bit viral until today.

This blog post does approximate my sentiments pretty well, although its writing style diverges from my usual style.

Author here, and I mostly agree with this sentiment. With that said, part of my Kiro spec here, had Kiro read my other blog posts and attempt to emulate my style.

I too found the write-up to be a little dry and long-winded, even though the same critique might be leveled at myself [hopefully to a lesser extent]. I did feel like it was a good step up from the usual AI slop out there, and served to illustrate Kiro's capabilities.

I suppose in this context, I wanted to see whether I could take my reader on a journey long enough for them to be surprised by the AI reveal at the end. I'm not sure whether it achieved that but that was the artistic intent of this specific piece.

I got early access to Kiro. Wrote about my experiences here if you're interested: https://yehudacohen.substack.com/p/developing-with-kiro-amaz...

It is my new daily driver.

Hi all,

Here's a write up of me fine-tuning ModernBert for regression to try beat the market.

I hope you all enjoy!

Possibly inspired by this stack overflow question:

https://stackoverflow.com/questions/5508110/why-is-this-prog...

I write an opinionated blog focused on cloud engineering and AWS: https://yehudacohen.substack.com/

Hi all,

This is a very in-depth treatment of the evolution of cloud development tooling from my perspective. I've been working in this space since ~2016ish

Would love to hear your thoughts!

I absolutely agree with the first part of this advice.

As to the assertion that complexity is not worth worrying about, I could not disagree more. I have watched projects fail time after time because of complexity, dependencies, and lack of budget.

Managers should encourage their engineers to spend time trying to simplify architecture and reduce code, infrastructure, and package dependencies. Smart engineers can learn to think simply over time, but this will not happen automatically. (I plead guilty to gravitating toward complexity in the early part of my career, but I have since learned better.)

Managers should place emphasis on using existing patterns wherever possible rather than re-inventing the wheel. Practicing laser focus on delivering value, evaluating solution dependencies with an eye to keeping things simple, and accurately modeling the problem domain in question.

Rather than trying to fight with engineers about implementation approaches, managers should try to guide engineers toward arriving at these conclusions themselves. I have also found that stressing simplicity as a key performance metric for engineers is a useful tool.

A couple of points: 1. Cloud Run is more analogous to AWS App Runner than Fargate. 2. Cloud Run isn't a great analog to lambda. Lambda is built to host functions. Cloud Run is built to host applications. Lambda is more analogous to GCP Functions. 3. Cloud Tasks should probably be built with EventBridge + Lambda or EventBridge + StepFunctions or EventBridge + ECS.

I don't profess to be a GCP expert so it's hard for me to make a judgement call on what's better. I can, however, say that most of this post ignores some of the real serverless power provided by AWS. AWS AppSync, AWS API Gateway, DynamoDB, CloudFront Functions, Lambda@Edge. It also makes comparisons that are not very fair.

It's perfectly plausible to believe that Elon Musk paid them to take vacation days off for this purpose. I wouldn't jump to any conclusions.

Do you have a source of Magnus accusations? He seems to have withdrawn relatively quietly, perhaps consciously trying to refrain from cheating accusations.

Hikaru was less reserved on the other hand. He called Hans's post-game interview analysis sub-2700 level after Hans Neiman badly mis-evaluated several positions.

This isn't true. 10GB is the limit on docker backed lambda function sizes. Layers are capped to 256MB just like lambda functions.

A couple of weeks ago, I tried to deploy a lambda function that created Azure Subnets in python, and the Azure client was 265GB alone. My layer creation api call failed because of this.

Haven't followed F1 for a while but back then Schumacher made Barichello stand on the top of the podium. Didn't seem especially proud of the "win".

This reminds me of when Rubens Barichello stopped at the side of the road to let Michael Schumacher pass him in Austrian Grand Prix in 2002: https://www.motorsport.com/f1/news/austria-2002-ferrari-team...

Do you have a link to video or audio for this presentation? I'm probably don't speak for just myself when I say I would love to see it.

While looking for the video for the presentation in this thread, I came across the previous presentation video. https://news.ycombinator.com/item?id=32519881

A less than epic tale of moving a hybrid-tenant application from AWS to Azure

I will say that for us this is a huge deal. We're a devops services company, and our customers expect their deployment pipelines to work. This is becoming a huge pain-point for a few of our customers and we recommended Github Actions to them. A couple of our customers want us to move away from GitHub actions because of how disruptive outages have been.

Sorry sqs not s3

@cx42net are you using a VPC endpoint to connect to S3 or routing to the public endpoint?

I've had relatively bad experiences with Cloudflare's DNS solution. Here are a couple of examples of pain-points: 1. You can't set NS records for an Apex domain registered through cloudflare (even at more expensive service tiers). You can delegate management of subdomains with NS records but only if you shell out for an expensive plan $$$. 2. Cloudflare performs cname flattening for cnames by default. This prevents you using cname based dns validation for third parties. One such example is certificates in Amazon Certificate Manager which performs cname lookups. You can disable cname flattening but you have to shell out for a more expensive plan $$$$.

And yet if you try to pass values from one stack to another, it will fail spectacularly.

@polynomial - You have to use the state API on the generated terraform. This means that you need to understand the structure of the generated terraform, and are dealing with generated .json files that require introspection to determine what terraform resource ids are prior to managing their state. It is possible to do, but if you're writing code, you don't want to have to worry about the generated json.

@throwaway894345 You can, but that means you have to introspect the generated code to determine terraform resource ids etc. A really bad developer experience on large stacks.

The token system is broken in TF CDK still and it's not ready for adoption. I've built two stacks with it but I'm back at terraform for now. I intend to explore pulumi though when the opportunity presents itself.

I think using a Turing-complete language like typescript with mature tooling to define cloud infrastructure feels very natural and makes things much more manageable than using HCL.

One thing I absolutely can't do without is the state management api terraform provides with its CLI. This is absent from terraform-cdk and aws's CDK, although many of the same APIs seem to exist for pulumi.

I follow these "archaic" rules myself, although I have a very different approach to these "hacks". Orthodox Judaism has an explicit prohibition of using loopholes to circumvent the spirit of the law called "Ha'aramah" mentioned in various plances throughout the Talmud including: Moed Katan 11b,12b, Nedarim 43a, 48a; Bava Metziah 62b and a bunch more I do not recall.

I have always understood there to be two classes of hacks in Judaism.

The impermissible class circumvents the spirit of the law.

The permissable class clarifies what the spirit of the law actually is.

The spirit of the Shabbat law is to rest and resting is defined as refraining from a set of 39 categories of labor. One of these categories is transferring an object from one domain to another. But is it really labor to carry a cake to a friends house as a gift when attending a meal? Is it labor to push a child around in a stroller?

The loophole of Eruv is intended to enable Jews to define communities by drawing a string around them and demarcate a logical line of what constitutes labor vs not on Shabbat as a something external to the community vs external to the home. This is a psychological exercise to force Jews to understand the boundaries of their communities so as to protect them from actually performing labor and preserving the sanctity of Shabbat.