Skip to content

Conversation

@kriszyp
Copy link
Member

@kriszyp kriszyp commented Dec 2, 2025

No description provided.

Copy link
Contributor

@dawsontoth dawsontoth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reads logically to me. Some of these I think we could roll into core in v5 so we don't have to guide the LLM, like the static bit. I also wonder if we can describe the config yaml schema better (for AI and users)

Copy link
Member

@heskew heskew left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great guidelines. Just some minor suggestions for this initial doc. Some examples and even more recommendations might help but I'm curious to see how this alone affects agents when blindly bootstrapping a Harper app...

@@ -0,0 +1,17 @@
---
name: docs_agent
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems okay to keep the front matter (metadata) but should the name be more generic?

## Your role
- Build high-quality Harper applications that demonstrate best practices.

## Guidelines for agents building Harper applications
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we mention what globals are available? e.g.

  ## Available Globals
  - `tables` - Access tables from the default `data` database (e.g., `const { User } = tables;`)
  - `Resource` - Base class for custom resources

@kriszyp
Copy link
Member Author

kriszyp commented Dec 3, 2025

Some of these I think we could roll into core in v5 so we don't have to guide the LLM, like the static bit

For sure, this will be the default in v5, the static flag has been the best thing I could come up with as a preparation for this change in v5, as awkward as it is.

I also wonder if we can describe the config yaml schema better (for AI and users)

Perhaps; I guess my belief has been that AI actually has seen and fully understands the config.yaml. But has conflated it with harperdb-config.yaml and in doing so has concluded that it can get very creative in what config it can add there. But I could be wrong about that.

but I'm curious to see how this alone affects agents when blindly bootstrapping a Harper app...

Yeah, is there a good way we can start testing this? I know we have been making some guesses about if/how valuable examples might be and corrective guidance. Ultimately it would be nice to have empirical evidence of what works well here, since I am probably wrong about a lot of this :). Maybe we start building out the LLM APIs we will use and create some test scripts where we can try out different guidance?

kriszyp and others added 6 commits December 3, 2025 10:09
Co-authored-by: Nathan Heskew <heskew@pm.me>
Co-authored-by: Nathan Heskew <heskew@pm.me>
Co-authored-by: Nathan Heskew <heskew@pm.me>
Co-authored-by: Nathan Heskew <heskew@pm.me>
Co-authored-by: Nathan Heskew <heskew@pm.me>
Co-authored-by: Nathan Heskew <heskew@pm.me>
@heskew
Copy link
Member

heskew commented Dec 4, 2025

Yeah, is there a good way we can start testing this?

Just need to try it. I've been asking various bots what they think would be most useful but we just need to really try it. Also have docs for folks to try themselves and have a clear feedback loop. This is probably going to continuously evolve too...so it'll be something else to maintain (but could have a great devexp roi...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants