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.