Add a how-to guide for beamctl/beam-init - #69647
Conversation
|
Amplify deployment status
Preview links for changed docs pages |
e72b252 to
6408edf
Compare
The goal of this guide is to illustrate `beamctl` in action in order to demonstrate its primary workflows as well as its value and relevance for long-running agentic use cases. For readers who only want a short reference of `beamctl` commands, there is a table in the "How it works" section. Later work can add conceptual and reference documentation for `beamctl`. The guide includes an example of developing an app with dedicated coding and testing agents. The app is designed to be small but outside the scope of typical LeetCode problems or computer science coursework (i.e., as opposed to tic-tac-toe and Conway's Game of Life), so it makes more sense for an adversarial testing setup instead of a one-shot prompt.
6408edf to
e10b040
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e10b0400b4
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| <details> | ||
| <summary>Deleting a service</summary> | ||
|
|
||
| To remove a service from the list of services `beam-init` tracks, run the |
There was a problem hiding this comment.
This wording kind of sounds like it removes the process from management but lets it continue to run.
beamctl stop terminates the process, right?
There was a problem hiding this comment.
I've added a sentence of clarification.
| forces the agents to adopt a test-driven development (TDD) workflow and prevents | ||
| the agent writing the application code from adding trivial tests. | ||
|
|
||
| ## Step 1/3. Create a demo user |
There was a problem hiding this comment.
Is this step absolutely necessary? Creating a user, accepting the invite, setting up MFA, etc. all adds extra friction and takes away from the key points in this guide (beamctl).
Can we simplify?
There was a problem hiding this comment.
I've removed the step. Unlike the database guide, the demo in this one doesn't interact with Teleport-protected infrastructure, so it doesn't make a difference which user owns the beam.
| $ beamctl start --name=coder -- bash -c ' \ | ||
| export HOME=/home/beams; \ |
There was a problem hiding this comment.
This would be a lot easier to read if we didn't have to run under bash in order to set HOME.
Probably nothing we can do for now, but maybe good feedback for @boxofrad or @rcanderson23 to share with the team.
There was a problem hiding this comment.
Yeah, this feels like something we should address. I have opened gravitational/beam-init#142
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5f6d8f3497
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
- Remove Step 1, which is unnecessary. - Clarify beamctl stop --prune. - Include installing vitest. While a test run of the guide succeeded without this, adding vitest provides a little more reliability. Similarly, also ensure all agents are operating from the demo project directory. - Remove the assurance about dangerously skipping permissions and recommend that the user authenticate with no permissions to access protected infrastructure before starting the guide.
5f6d8f3 to
23d4c63
Compare
The goal of this guide is to illustrate
beamctlin action in order to demonstrate its primary workflows as well as its value and relevance for long-running agentic use cases. For readers who only want a short reference ofbeamctlcommands, there is a table in the "How it works" section. Later work can add conceptual and reference documentation forbeamctl.The guide includes an example of developing an app with dedicated coding and testing agents. The app is designed to be small but outside the scope of typical LeetCode problems or computer science coursework (i.e., as opposed to tic-tac-toe and Conway's Game of Life), so it makes more sense for an adversarial testing setup instead of a one-shot prompt.
Closes gravitational/beams#58