roblaszczak

> The prototype is working software. And the improvement and testing of that prototype is further enabled by more improvement loops with the AI. It gets better with more testing and verification, not through human code review, but through usage and testing.

I would love it if it was that simple :-) Agents can one-shot this prototype and that feels like they are "almost done". The hard part starts when we try to make it production-grade.

I'm not saying that it's not possible, but it requires more effort than productionizing a PoC that we used to create "by hand". We start to discover shortcuts taken by the coding agent and we spend 80% of the time on getting the last 20% right (but to be clear, it's still less time than writing it by hand).

It looks like the author may not have hit this reality check yet:

> Of course, neither of these things is currently shipped, or supported and isn’t what I’d call production ready software. So you could say what many say about AI, which is that it helps you ship the prototype faster. But that isn’t really giving enough credit here.

For AI-generated code, finding "the last 20% rough edges" is much, much harder than creating PoC. Often the rough edges are buried in the code that we don't know. Fixing those problems requires big refactors that, for wrongly architected code, can break other things.

Tests help, but that's not enough for models to autonomously fix them. If they make one error, it compounds over multiple iterations.

It's especially true for problems where we don't have a clear oracle. It's impressive that models can brute-force problems with a clear oracle. But many problems where a clear oracle doesn't exist (a lot of business software that I know) will still require a lot of product engineering.

Maybe it will improve? I'm not sure if it can happen with hallucinations around (from what I see, they are still a big deal for domains that agents are not trained on).

Hey HN, Robert here, creator of Watermill.

Over the past few years, I've watched a sad trend: many companies are aggressively monetizing open-source. Thanks to being bootstrapped, we don't need to take that path with Watermill.

For 7 years, we've been building Watermill in the true open-source spirit—all components are open. We don't obscure documentation to push users toward our consulting services.

In that spirit, we've created a hands-on quickstart that teaches Watermill's core concepts through a real-world project. Since browser-based environments don't cut it for real-life projects, we built a custom platform that handles all the setup and verification directly in your IDE.

Rather than say more, I'd encourage you to try the quickstart yourself!

Hey, Robert here (author). We are the opposite of companies with big funding and quick success. I also know that software engineers education is not the most viral topic here. Nevertheless, seeing success stories not following beaten paths may be valuable and eye-opening. Long-term sustainable growth and learning by building are undervaluated.

If you have any questions or feedback, I'm more than happy to hear it!

Hey, Robert here (author).

We are the opposite of companies with big funding and quick success. I also know that software engineers education is not the most viral topic here. Nevertheless, seeing success stories not following beaten paths may be valuable and eye-opening. Long-term sustainable growth and learning by building are undervaluated.

If you have any questions or feedback, I'm more than happy to hear it!

Glad to hear that!

Hey, it's Robert here, author of the library.

A few years ago, I worked on a project where we wanted to use Event-Driven architecture. But most team members were unfamiliar with it and uncomfortable working with asynchronous architecture. I asked myself: "Is it possible to make building an Event-Driven application as simple as building an HTTP API?" — and that's how Watermill was born.

We currently support 12 Pub/Subs, including Kafka, Redis, AMQP, and NATS. We also support MySQL and PostgreSQL-based Pub/Subs, so you can use Watermill even if you don't want to add extra infrastructure to your tech stack.

It's handy for: 1. Building event-driven services 2. Implementing CQRS architecture 3. Creating complex message processing pipelines

We also support poison queues and the outbox pattern out of the box and provide middleware that supports logging, retries, and circuit breaking.

Watermill is an independent project under the MIT license. We don't plan to get VC funding, and nobody from outside can force us to change the license to monetize the project.

We released Watermill v1.0 more than five years ago, and since then, we have kept backward compatibility.

We plan to release v1.4 soon, including updated poison queue support and sending delayed messages.

I'd love to hear your thoughts and feedback. If you have any questions, I'm happy to answer!

Links: GitHub: https://github.com/ThreeDotsLabs/watermill Documentation: https://watermill.io/ Examples: https://github.com/ThreeDotsLabs/watermill/tree/master/_exam...

SlashID | Principal Backend Engineer | REMOTE (EU compatible time-zones) | Full Time

We’re an early stage startup building an identity platform. Our goal? Bring authentication for users, machines and APIs under the same (secure) umbrella (aka one identity platform to rule them all). We’re looking for people who can design, build, and maintain distributed systems at scale. You’re also driven, product-oriented and enjoy getting your hands dirty; extra points for experience in security. Stack: Go, GCP, Redis, PostgreSQL, Docker, Terraform. You don't need experience with all these but should be willing to learn).

Get in touch at [email protected] or apply on our website https://www.slashid.dev/careers/principal-backend-software-e...