robertkluin

I use a similar approach for some types of work. I use a planner (read only), researcher (read only), implementer, and reviewer (read only). I allow the implementer to spawn researchers and reviewers to help it with its work. I interact with a controller to manage the subagent trees. The agents use a file-based communication system. I get really good results on real work. Coworkers (using Claude with fable) can’t tell the difference.

The benefit of Claude is purely team collaboration and some basic QoL features.

Thank you! Very helpful feedback.

We're thinking through better examples to try and highlight some of the key differences from other tools without it being too involved.

Awesome feedback, thank you!

The CLI is presently being reworked to expose that capability. Right now, you can use FunctionTest in order to validate that you get your expected outputs from an input. This works well because you can test many scenarios, including error conditions. The CLI does not currently emit the materialized manifests purely because our initial use cases needed to map values from reconciled manifests into other manifests. It is completely viable to emit the materialized manifests though.

Honestly, our ambition is to develop a tool that makes the operations and platform engineering people's lives better. Our team is comprised of software engineers who've worked in the operations and platform engineering space for a long time. It is a crowded space for sure, but I am optimistic, probably foolishly so, that we can develop something that is more pleasant for the platform folks than many of the other options.

We'd welcome any other feedback or thoughts on how to accomplish that.

Honestly, Koreo can cover most of the use cases of the other tools just fine. We leverage Koreo to manage deployments of the Koreo controllers along with their service accounts and RBAC—it works quite well. We also use it with Helm in order to install, for example, ACK controllers which have existing Helm Charts.

Our design is very, very deeply inspired by Kustomize. If Kustomize or kpt are sufficient, I would strongly encourage using one of them. We developed Koreo because we have cases where we need to sequence resource creation (for instance to map values from one resource to another) and wanted to programmatically set values.

I am not honestly familiar with Timoni, but glancing through the docs it looks like it heavily centered around Kubernetes deployments? Our initial use cases were centered around IaC for non-k8s workloads (think systems such as ECS or Cloud Run).

In terms of the YAML aspect, internally the core system does not use YAML. We opted to stick with YAML as the interface for the time being purely because it is familiar and there's loads of tooling.

We've been working to improve the structural and the type checking further and I'm hopeful to have a substantial improvement to that released "soon." It is queued up behind some other improvements within the language server we need to make first though.

You should write your operator. You are correct: it is quite straightforward and you'll have solid understanding of what is happening and how it works.

That is how this project started. We wrote custom operators for the various platform components; that worked outstandingly well. Shockingly well to be honest.

This system evolved from that approach because we needed a way to rapidly customize our application models. If you don't need to support varied use cases _and_ have standardization writing your own is the way to go.

I wrote the core engine behind this and your comment made me laugh pretty hard because I agree. I debated a lot about the best syntax and we experimented with various alternatives approaches. The core engine actually isn't YAML centric at all, in fact it doesn't use YAML—it is just data structures in and out.

We wound up exposing this as YAML purely because there's a lot of tooling out there for dealing with YAML. I am not sure if that's a good reason or not.... Writing the language server was quite nasty because of that choice! Our hope was that the language server and structural type checking (which is very simplistic at the moment) and testing framework can make it feel more like a real language and less YAMLy.

I maintain the core of Koreo. I'll hit the easy question first, then the more involved questions.

Everything is in-code and designed to have a "proper" SDLC lifecycle—code reviews, approvals, merges. It is designed to be used in gitops workflows.

For the more nuanced questions, here's some background: I like Kustomize and KPT a lot. In _my_ opinion, they should be your starting point. They are clean and easy to reason about tools. They do not work as well when you have more complexity. They're very painful if you've got _dynamic_ values or values you need to inject programmatically (think Helm's values.yaml).

The next important item to note: Koreo's relative value is lower if you're building highly bespoke one-offs or you do not care about having standard resource configurations / application architectures. The value is not zero, but there are lighter solutions and you should consider them instead.

Koreo is meant to model application architectures and resource capabilities. Using your example, you can build a BucketResource. That BucketResource will then ensure that S3 Buckets follow your company standards, including things like automatically handling the IAM setup and permissions for the service that uses the bucket. That lets you define required capabilities: An S3 Bucket is always tagged with the owner service and product domain. In production environments buckets must have lifecycle rules specifying a minimum 30 day retention. In development environments, you lifecycle rules are optional. The developers then only need to specify that their workload uses an S3 Bucket and it will be configured based on your company standards. But, we have designed it so that you can decide how much abstraction is right for your needs—you can directly expose the full, underlying API or you can abstract it more.

Effectively, it gives you an "easy" solution for building a PaaS that implements _your_ standards and opinionation.

Our original versions were directly implemented using go and Python. The issue is that iterating on the application models was much, much slower. This approach allows us to rapidly implement new capabilities and features, and even expose unique or experimental architectures to only certain application domains.

Disclaimer: I’m currently building a product to help with my own organization challenges.

This is what I realized as well—organization is the hard part. I kept struggling to find notes when I wanted to reference them. In my case, my notes are usually (but not always) captured in a meeting. I would struggle to find content because I might remember a person, a rough date, or some topic discussed… but if I put it in the wrong folder, tag, or physical notebook I was out of luck.

I put together a simple prototype that pulled all the metadata off my calendar included it in notes. That was really helpful.

We liked it enough playing with it internally that we built a product (witful.com). In 2.5 years of real world use I’ve almost never struggled to find stuff. Really has been a game changer for me, but my content is meeting centric.

I routinely reference notes from several years ago in meetings. This was a decision we had a substantial amount of debate around internally. In the end we decided that a combination of person and timestamp tags combined with a robust search was a better approach for our users (people with many meetings each day). We've got a lot of work still to do before search is where we want it though. We know that decision isn't going to work for everyone though.

I work on Witful. We spend a lot of time and effort keeping the UI clean and refined; to the point that we have accidentally over-simplified in a few key spots. The result is that we've got a ton of hidden functionality. Things like collated notes by domain or capturing "questions" (simply add `??` to a sentence to mark it as a question) are tricky to find. I think MS has just optimized for making everything "obvious" by adding a button for everything to their menu bars.

"We recently became aware of unauthorized access to certain of our information technology systems hosted by a third party cloud provider."

Is this an attempt to shift blame? Using wording that implies it was someone else's fault is not confidence inspiring.

Your experience sounds identical to my own. Particularly the "marketing book from the Neo4j folks" starting you down this journey.

I have worked on a few projects where graph databases were used. I have not personally seen a case where I feel they add much value relative to their complexity and tradeoffs.

One of the projects was a business workflow application centered around validating business processes by collecting and reporting on process data—think manufacturing quality control. A graph database was used in an attempt to allow application users more control in defining their workflows and give them more expressive semantic reporting abilities. We tried several graph databases. In reality what happened was that the scheme became implicit and performance was truly awful. The choice of a graph db was a strategic decision; we wanted to enable a different user experience. We probably could have done this project in 20% of the time with a standard database and wound up with a better result.

I have also worked on a problem related to storing and retrieving graph data for image processing. The graph db was obscenely slow and inefficient despite the data models being actual graphs.

Both of the projects I worked on involved people who are experts in graph databases. The level of nuance and complexity was astounding. Even simple tasks like trying to visualize the data became monumentally complex.

My takeaway from both of these experiences was that unless you intend to ask questions about the relationships, a graph might not be a very good fit. Even in that case, other databases will likely perform just as well.

(edit: add last sentence)

This has been a pain point for us with a couple of the language updates. Not as bad as other pre-1.0 languages I've used in the past (like Rust), but it has been painful. The compiler is helpful enough that upgrades are mostly just tedious.

I'm a partner at Real Kinetic.

At Real Kinetic we've actually been internally using Elm for 2 years. While at Workiva, I OKed some internal projects to use Elm as well. Your observations are absolutely correct.

We have actually found on-boarding engineers to Elm is fast and relatively easy. There is a very predictable learning curve engineers seem to follow. That's one of the things we like about Elm versus some other solutions. The even bigger observation I've made is that all of the engineers we've exposed have become fans, like Alex.

The lack of resources and other companies contributing to the community and libraries is a challenge, and a concern. As an example, we use Elm Native UI for some projects. It has a limited user-base, which has at times been frustrating. We're hoping to see more adoption of Elm to help mitigate this problem.