Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Domain-Driven Agents

coldtake.dev

Post reply on HN
Print view View original

11–20 of 29 posts

Re: Domain-Driven Agents

#11

Post by plaguuuuuu »

owaiswiz wrote: post #2

Something i read in the earlier paragraphs about llms being easier to work with in greenfield projects… My experience has been the opposite. They work well on existing projects but are not so great at new ones (unless you are just vibe coding something simple). I think it has something to do with it being able to rely on years of established structure/conventions on existing projects that makes them better IME

Depends on what the existing project looks like ;-)

One repo at my work is DDD-esque, clean architecture, modular monolith.

It suuuucks to work on. Even without AI, editing any feature requires navigating through a bunch of app, infra, domain layers instead of living in a vertical feature slice. Indirection from cargo cult design patterns we don't need, like Mediator. With AI, degradation in quality and accuracy is plainly obvious. Everything needs hand-holding. AI is dumber than our average human dev so the creaky architecture made things 10x worse

The greenfield one we started with AI a few months ago is kicking along nicely. Warts exist, there are some really large files and questionable bits, but it's way easier to work on because we didn't make the architecture some convoluted dwemer mine thingy

Re: Domain-Driven Agents

#12

Post by spicyusername »

owaiswiz wrote: post #2

Something i read in the earlier paragraphs about llms being easier to work with in greenfield projects… My experience has been the opposite. They work well on existing projects but are not so great at new ones (unless you are just vibe coding something simple). I think it has something to do with it being able to rely on years of established structure/conventions on existing projects that makes them better IME

If you start with architecture docs that outline the high level goals and what the core abstractions should be for a greenfield project and refine it as you fill in the actual code, you can get pretty good results.

That gives the first few agents the "north star" and then subsequent agents have the actual code, the runtime behavior, and the user experience expectations to work against after that, in addition to the architecture docs, that provide hard boundaries to vibe off of.

Re: Domain-Driven Agents

#13

Post by tikhonj »

stephen wrote: post #6

I've also been a little-d DDD fan, and we've had luck with per-entity `md` files to language-independent document domain behavior/quirks/usages. I.e. an `Author.ts` has an `Author.md`, `Book.ts` has an `Book.md`. For agents, we've given them a skill to read & write the `md` files: https://github.com/joist-orm/joist-orm/blob/main/packages/co... And so agent-written `md` updates are showing up in PRs. So far it seems u…

Why not put the content from the md file in the code as documentation?

Ideally, the code can actually help you structure that information. I've written a bunch of Haskell and OCaml like this, where the types in each module let me structure my documentation in a way that is actually easier for people—and maybe also LLMs—to track. As a bonus, it makes it more natural to keep the two in sync.

Re: Domain-Driven Agents

#15

Post by theahura »

i'm sorry to say that besides like the first paragraph, this article is mostly ai slop. i thought that we mostly weren't allowing ai written content on hn? (@dang whats the policy here?)

aside from that, i think that this is overcomplicating a more basic idea. You should have agents that leave docs behind in your codebase, and those docs should be localized to the structure of your code, but you do not need any fancy format or manifest.

We've had a lot of success with having the agents write and maintain a docs.md file in each folder, and requiring that they both read and update that file whenever they make a change in that folder

Re: Domain-Driven Agents

#16

Post by DarmokTanagra »

theahura wrote: post #15

i'm sorry to say that besides like the first paragraph, this article is mostly ai slop. i thought that we mostly weren't allowing ai written content on hn? (@dang whats the policy here?) aside from that, i think that this is overcomplicating a more basic idea. You should have agents that leave docs behind in your codebase, and those docs should be localized to the structure of your code, but you do not need any fancy…

Just look at the companies YC invests in if you want clarification on HN’s AI stance.

Re: Domain-Driven Agents

#17

Post by stephen »

tikhonj wrote: post #13
stephen wrote: post #6

I've also been a little-d DDD fan, and we've had luck with per-entity `md` files to language-independent document domain behavior/quirks/usages. I.e. an `Author.ts` has an `Author.md`, `Book.ts` has an `Book.md`. For agents, we've given them a skill to read & write the `md` files: https://github.com/joist-orm/joist-orm/blob/main/packages/co... And so agent-written `md` updates are showing up in PRs. So far it seems u…

Why not put the content from the md file in the code as documentation? Ideally, the code can actually help you structure that information. I've written a bunch of Haskell and OCaml like this, where the types in each module let me structure my documentation in a way that is actually easier for people—and maybe also LLMs—to track. As a bonus, it makes it more natural to keep the two in sync.

> why not put the content from the md file in the code

We do that :-)

https://joist-orm.io/modeling/documentation/#two-way-syncing

Technically the md file can have more free-form docs, but for the overview/fields headers that, by convention, map to the entity/field jsdocs, we do sync them over.

Re: Domain-Driven Agents

#19

Post by hboon »

owaiswiz wrote: post #2

Something i read in the earlier paragraphs about llms being easier to work with in greenfield projects… My experience has been the opposite. They work well on existing projects but are not so great at new ones (unless you are just vibe coding something simple). I think it has something to do with it being able to rely on years of established structure/conventions on existing projects that makes them better IME

It's easy in greenfield projects because they are smaller and less things to break.

They work well on existing projects if the codebase already has a good architecture and has good consistent (and prevalent) patterns.

Re: Domain-Driven Agents

#20

Post by ydna404 »

> The issues are then addressed by my AI system based on skills and sub-agents.

So I don't think this is really the way to go imo. Relying on AI can increase productivity but it's extremely hard to manifest.

Post reply on HN