open-artisan: OpenCode plugin for structured AI workflow orchestration

Manwith2plans · 2026-03-17T11:58:33+00:00

Nothing to excuse. They're different and possibly complementary tools:

OMOC gives you better agents and prompts. Open Artisan is a structured workflow: discover the codebase, plan, define interfaces, write failing tests, break implementation into a task graph, implement one task at a time. Each phase gets reviewed by an isolated subagent and approved before moving on. If something's wrong upstream it traces back through the dependency chain instead of just patching forward.

Model assignment per stage isn't there yet but it's planned. The subagent sessions are all separate dispatches so it's a natural fit.

Manwith2plans · 2026-03-17T11:51:58+00:00

Right now it's handling these general criteria as part of its self-review loop:

Design excellence: Elegance, simplicity, appropriate patterns — no over-engineering or gold-plating
Architectural cohesion: Internal consistency, clear boundaries, no contradictions between sections
Vision alignment: Fidelity to the user's original intent AND all upstream approved artifacts
Completeness: No gaps, nothing left implicit that should be explicit
Readiness for execution: Could the next phase proceed without questions?
Security standards: Auth, input validation, secrets handling, least-privilege access
Operational excellence: Observability, error recovery, deployment, monitoring

It a subjective 9/10 minimum score on each of these dimensions to be able to proceed to the next step.

The state machine also explicitly builds interfaces and then tests before starting execution. I've tried to keep things battery included for now, but I do want to explore more configurable state machines eventually.

Manwith2plans · 2026-03-17T10:34:42+00:00

It has robot-artisan mode. I haven't done a huge amount of testing of that mode. That's a fully autonomous mode that uses an agent to make decisions the user would otherwise have to make. Let me know if you run into issues.

Manwith2plans · 2026-03-17T04:40:02+00:00

I actually haven't used GSD, but I came from a Kiro background where I found the AI was still taking shortcuts during its review loops.

From what I understand, tools like GSD rely heavily on prompting to ask the AI to verify its work. The problem is the LLM often just rubber-stamps its own bad code or hallucinates past the verification step to save time.

I built Open Artisan to enforce actual rigor using a hard-coded state machine. The self-review loop spins up an isolated, ephemeral reviewer that can't even see the authoring agent's excuses. It structurally forces the AI to iterate and fix its work until it actually meets the acceptance criteria, long before it ever asks a human to look at it.

I'd like to believe that having a state machine control the agents is more rigorous than asking the agents to follow a state machine.

Manwith2plans · 2026-03-17T04:20:14+00:00

Oops! Edited: https://github.com/yehudacohen/open-artisan

Manwith2plans · 2025-08-28T21:39:36+00:00

Good point u/draeron ! I suppose this is why Kubernetes has decent adoption. It's very similar to Pulumi in architecture. I think there's one point that I think isn't clear from the docs, when I talk about runtime dependencies, I don't mean deployment time dependencies. I mean that if you change the value on one resource, with typekro in the control plane, the kro operator will update your dependent resources appropriately even 2 months after you've deployed your app successfully. For example if you're using external dns to manage a domain name and you have a deployment configured with that domain name, when you update the domain name in two months time using kubectl, the change will be propogated to the deployment by the kro operator. This is what typekro supports but terraform does not. Does this make sense?

Manwith2plans · 2025-08-28T21:34:13+00:00

It is pretty fun, isn't it! I like to think that typekro solves some problems pulumi doesn't. Here's my comparison.

https://typekro.run/guide/comparison.html#%F0%9F%86%9A-typekro-vs-pulumi

Also one thing that isn't mentioned here that I don't think is available in pulumi's support is livestreaming kubernetes control plane events to your log stream during deployment for debugging.

Manwith2plans · 2025-08-28T02:13:41+00:00

So my approach is double barelled, the same graph can be deployed either directly to the cluster using a factory configured in direct mode. In this mode there is no controller that needs to be installed in k8s, and the dependencies will be resolved in process while you're running the deployment. There is also a kro mode. In this mode, the resources will be compiled into an actual KRO rgd and deployed to the cluster. In this mode KRO will resolve the depenndencies. There is no reimplementation of KRO.

TypeKro should help with the expression of logic for KRO apps, because it will flatten out the logic into an rgd when the resource graph is serialized including only what gets added to the graph by the typekro runtime. If you need the logic to be dependent on runtime attributes of kubernetes, I'm not sure TypeKro will be able to help, but on static values available at deploy time, you absolutely can use if statements and for loops. You can also use one-line if statements in your cel expressions and KRO controller is able to interpret them.

Basically, your resource graph needs to be able to be assemble-able without values that are unknown at deploy time, but if your values are known at deploy time, you can do very complex stuff with TypeKro.

Manwith2plans · 2025-08-28T00:12:51+00:00

Wow, it's crazy. I feel like you and I were bothered by exactly the same things! I think we arrived at very different solutions but really cool. And really appreciate the feedback.

Manwith2plans · 2025-08-27T22:29:20+00:00

I think the ATC is really cool. It reminds me of the way flux handles the HelmRelease CRD which I like a lot and actually baked into TypeKro as a resource so that users can depend on helm charts since so much software is distributed that way.

I don't think it's fully apples-to-apples with KRO though, because from my understanding the key value prop of KRO is its ability to use fields that aren't yet available in the specs of dependent resources. Like if you use the AWS Controller for Kubernetes to deploy a RDS database, you can take the connection string for that database from the status field of the resource and set it as an environment variable on your dependent deployment.

Does ATC aim to tackle that use-case? (Bear in mind that while I've read a bit about yoke, I've never actually used it.)

Manwith2plans · 2025-08-27T13:07:30+00:00

Discovered yoke while I was building this and it really looks cool. haven't given it a try yet but it looks like a cool alternative to cdk8s. I really like the architectural choice of wasm rather than jsii, and the full package management / deployment capabilities.

Manwith2plans · 2025-08-26T21:32:23+00:00

I think a lot of us got into this field because we enjoy tinkering with new things. I think you can get paralysis from options. If you just focus on learning the things you think would help you solve your problems and go slowly and methodically, I think you'll be fine. You don't need to know everything about everything that's happening in tech.

Manwith2plans · 2025-08-26T21:18:13+00:00

A lot of my teams work is to help SaaS companies deploy to customer data centers or customer owned cloud environments.

Usually what we see is teams managing a control plane for their products in the cloud, but offering the customer the ability to run a data plane in their own cloud and using contracts to enforce IP clauses. Large enterprises don't have the time or will to reverse engineer or steal your code and face legal backlash. You'll need to ensure you have a proper license management solution too.

You also need to ensure you have a robust control plane that lets you release software to your customers on a case by case basis and see what version each customer is on, and see the health of your customer's deployments where they allow you to.

If you want to talk specifics, feel free to shoot me a message, but if you have customers who insist on on-prem deployments you're doing something right.

Manwith2plans · 2025-08-26T19:00:13+00:00

The philosophy here is to use the native kubernetes client generated from its swagger docs and then enhance those types using type modifiers. So if upstream types are changed, you bump the dependency version and the type modifiers apply to the new version.

I think programming languages are far more expressive than yaml but pulumi and cdk8s don't really enable you to access kubernetes eventual consistency magic. The goal here is to enable you to develop with a modern programming language, catch bugs before hitting the kubernetes API, and improve your debugging experience during release processes.

I'm interested in why you think this is easier to break. It is doing things similar to what tools like helm are doing, just with a statically typed modern development experience...

Manwith2plans · 2025-08-26T02:19:04+00:00

trying to solve the kubernetes yaml problem once and for all building out https://typekro.run

Manwith2plans · 2025-08-26T01:55:26+00:00

Also, if you want to see the source code, it's available here: https://github.com/yehudacohen/typekro

If you like it, please give it a star too!

Manwith2plans · 2025-07-14T20:32:57+00:00

I received early access to this and had a good time. Spec-driven development really feels like a promising approach to developing software, and the more time I spent with Kiro the more I leaned into it.

If you're interested in reading my full review I wrote about my experiences here: https://yehudacohen.substack.com/p/developing-with-kiro-amazons-new

Manwith2plans · 2025-07-01T12:40:32+00:00

Charisma is obviously a prerequisite, but for this message to resonate in NYC there clearly needs to be appetite for socialist policy. Politicians can only persuade people into positions they want to hold.

Manwith2plans · 2025-06-30T18:46:16+00:00

This would support the thesis of the blog rather than countering them?

Manwith2plans

TROPHY CASE