I'm probably losing some coding skills, but replacing them with different ones, and honing some others.

I used to manage dev teams of 20+ people inside high pressure, high stakes projects.

I've been coding all my adult life, on big things and small.

To me, agentic engineering is a deja vue of managing teams, except in real time.

But what if the cell doesn't know that, and it's holding, for example, a stale account number?

Just kidding!

I find the idea quite good, and have to assume that the amount of payment fails they experience due to partitions/outages isn't very high and that the post-payment reconciliation and reclamation process gives them the liberty to rank availability a bit higher than correctness.

One thing that looked a bit shaky was the interplay between the global transaction router's state of knowing which cells can handle a particular payment and the asynchronous distribution of the "failover data", which I presume it needs to know to route correctly. To me that seems to create a window where it might route to the wrong cell due to an outdated routing state.

It also doesn't go into the HA setup of the global transaction router itself.

But still, I kind of like the design.

Consumer-grade subscriptions of the frontier models give you superb capabilities per dollar, them being heavily subsidized. But if you're working in an enterprise setting, that won't work. You need to upgrade, and that gets significantly more expensive.

Furthermore, basing the SDLC on leveraging the bargain subscriptions risks falling apart in the future, both from a cost perspective as well as the question of availability (e.g. Mythos).

So from a strategic perspective, going local on the LLM and still achieving great results with the right approach is very relevant.

https://simonw.substack.com/p/how-strongdms-ai-team-build-se...

I got thinking that, hey, what if we built a digital twin of our enterprise application platform Cyoda? With an in-memory local Cyoda service, it would make it much easier for people to get started building Cyoda apps, and rapidly speed up development.

I also wanted to see how far one can go using agentic engineering to build that out, thinking it's a good use-case since the tool wasn't (originally) destined for production.

I'm a Java/Kotlin/Spring/Cassandra person, so I decided to write it in Go, because I've never written a line of Go. This would ensure that I stay hands off from the code and see this from the perspective of an architect and project manager.

But after the in-memory storage engine was built, I quickly realized that it would be straightforward to implement a postgres plugin. Then I remembered sqlite. This looked so cool, that I decided over Easter to tackle Cassandra.

And out came cyoda-go.

We're still working intensively on fleshing it out, but the vision is to provide an open source EDBMS (Entity Database Managment System) that has production quality and can cover a very wide variety of use cases.

The design is based on our work of the last ten years on Cyoda.

So what's an EDBMS? ...you are probably asking.

Under the hood, it's a combination of a JSON/document database, a workflow engine, messaging/queuing middleware, and a CDC audit. Data are entity state machines persisted append-only. Transitions can launch externalized processors over gRPC that do business logic. All mutations are bi-temporal and the consistency model is snapshot isolation with first-committer-wins on entity-level conflicts. An engine automates workflow traversal, so that a single trigger cascades across entities inside the same transactional boundary.

The core assembly is a single Go binary. Once you've understood the design, it's really easy to write event-based applications with transactional rigour and a bi-temporal view on the data at no performance cost, and built-in auditability and data lineage.

Repo: https://github.com/Cyoda-platform/cyoda-go Docs: https://docs.cyoda.net

I would be very interested to know what the community thinks. Is this kind of architecture, that consolidates several key frameworks into a unified platform, effective in accelerating the building of complex enterprise systems?

Comments URL: https://news.ycombinator.com/item?id=48068583

Points: 2

# Comments: 0

https://gist.github.com/pschleger/c1c36fbde003bea5eee7ce4291...

And a prompt to review a site I built for GitHub Pages, which I'll try this week.

https://gist.github.com/pschleger/8d5fcea6b96d8504ac58bb2f8d...

> The New York Fed blog noted that the modest impact on jobs so far may not hold in the future. "Looking ahead, firms anticipate more significant layoffs and scaled-back hiring as they continue to integrate AI into their operations," New York Fed researchers wrote.

And therefore I always thought that the more you master a language the better you are able to reason.

And considering how much we let LLMs formulate text for us, how dumb will we get?

Are you able say something about this?

We’re a small software vendor company with fintech startup clients in production for several years, and we have launched Cyoda as a PaaS to make this technology accessible to a broader audience.

You can think of Cyoda as having event sourcing + workflow engine + horizontally scalable database in one integrated system. Processing is transactional, querying is distributed and resilient, and business logic stays modular inside processors (actions) and criteria (gates) as part of the workflow.

We’ve created an AI assistant that helps you build your backend service through a chat dialogue that generates a prototype. It will build you a complete, runnable app, provision your environment, and deploy it. You can then switch to your own tools to continue development.

This type of lightweight modular system, where the platform engineering is mostly taken care of, makes AI much more effective when building complex backend systems.

The PaaS is still very fresh, and there’s a lot still missing and buggy in places. I would greatly appreciate feedback on the system design and architecture, particularly whether you think this platform has potential or not. There’s a Free Tier subscription, so you can play with it right away.

alpha AI assistant: https://ai.cyoda.net website: https://cyoda.com docs: https://docs.cyoda.com github: https://github.com/Cyoda-platform

Comments URL: https://news.ycombinator.com/item?id=44925264

Points: 4

# Comments: 1

          .....   ......   ......   ....   ..    ..   ......
         ..       ..   ..  ..   ..   ..    ...   ..   ..     
         ..       ..   ..  ...  ..   ..    .. .. ..   ..     
          .....   ......   ......    ..    .. .. ..   ..  ...
           .....  ...      .. ..     ..    ..   ...   ..   ..
              ..  ..       ..  ..    ..    ..    ..   ...  ..
         ......   ..       ..   ..  ....   ..    ..    .....

I haven't really thought it through yet, whether that even makes sense.

We considered reaching out in May, but held back because we want to run on bare metal.

Any chance to get this provisioned on bare metal at Hetzner?

We have K8S running on bare metal there. It's a slog to get it all working, but for our use case, having a dedicated 10G LAN between nodes (and a bare metal Cassandra cluster in the same rack) makes a big difference in performance.

Also, from a cost perspective. We run AX41-NVMe dedicated servers that cost us about EUR 64 per server with a 10G LAN, all in the same rack. Getting the same horsepower using Cloud instances I guess would be a CCX43, which costs almost double.