getting-started.mdx 4.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111
  1. # Getting Started with OpenHands
  2. So you've [installed OpenHands](./installation) and have
  3. [set up your LLM](./installation#setup). Now what?
  4. OpenHands can help you tackle a wide variety of engineering tasks. But the technology
  5. is still new, and we're a long way off from having agents that can take on large, complicated
  6. engineering tasks without any guidance. So it's important to get a feel for what the agent
  7. does well, and where it might need some help.
  8. ## Hello World
  9. The first thing you might want to try is a simple "hello world" example.
  10. This can be more complicated than it sounds!
  11. Try prompting the agent with:
  12. > Please write a bash script hello.sh that prints "hello world!"
  13. You should see that the agent not only writes the script, it sets the correct
  14. permissions and runs the script to check the output.
  15. You can continue prompting the agent to refine your code. This is a great way to
  16. work with agents. Start simple, and iterate.
  17. > Please modify hello.sh so that it accepts a name as the first argument, but defaults to "world"
  18. You can also work in any language you need, though the agent might need to spend some
  19. time setting up its environment!
  20. > Please convert hello.sh to a Ruby script, and run it
  21. ## Building From Scratch
  22. Agents do exceptionally well at "greenfield" tasks (tasks where they don't need
  23. any context about an existing codebase) and they can just start from scratch.
  24. It's best to start with a simple task, and then iterate on it. It's also best to be
  25. as specific as possible about what you want, what the tech stack should be, etc.
  26. For example, we might build a TODO app:
  27. > Please build a basic TODO list app in React. It should be frontend-only, and all state
  28. > should be kept in localStorage.
  29. We can keep iterating on the app once the skeleton is there:
  30. > Please allow adding an optional due date to every task
  31. Just like with normal development, it's good to commit and push your code frequently.
  32. This way you can always revert back to an old state if the agent goes off track.
  33. You can ask the agent to commit and push for you:
  34. > Please commit the changes and push them to a new branch called "feature/due-dates"
  35. ## Adding New Code
  36. OpenHands can also do a great job adding new code to an existing code base.
  37. For example, you can ask OpenHands to add a new GitHub action to your project
  38. which lints your code. OpenHands may take a peek at your codebase to see what language
  39. it should use, but then it can just drop a new file into `./github/workflows/lint.yml`
  40. > Please add a GitHub action that lints the code in this repository
  41. Some tasks might require a bit more context. While OpenHands can use `ls` and `grep`
  42. to search through your codebase, providing context up front allows it to move faster,
  43. and more accurately. And it'll cost you fewer tokens!
  44. > Please modify ./backend/api/routes.js to add a new route that returns a list of all tasks
  45. > Please add a new React component that displays a list of Widgets to the ./frontend/components
  46. > directory. It should use the existing Widget component.
  47. ## Refactoring
  48. OpenHands does great at refactoring existing code, especially in small chunks.
  49. You probably don't want to try rearchitecting your whole codebase, but breaking up
  50. long files and functions, renaming variables, etc. tend to work very well.
  51. > Please rename all the single-letter variables in ./app.go
  52. > Please break the function `build_and_deploy_widgets` into two functions, `build_widgets` and `deploy_widgets` in widget.php
  53. > Please break ./api/routes.js into separate files for each route
  54. ## Bug Fixes
  55. OpenHands can also help you track down and fix bugs in your code. But, as any
  56. developer knows, bug fixing can be extremely tricky, and often OpenHands will need more context.
  57. It helps if you've diagnosed the bug, but want OpenHands to figure out the logic.
  58. > Currently the email field in the `/subscribe` endpoint is rejecting .io domains. Please fix this.
  59. > The `search_widgets` function in ./app.py is doing a case-sensitive search. Please make it case-insensitive.
  60. It often helps to do test-driven development when bugfixing with an agent.
  61. You can ask the agent to write a new test, and then iterate until it fixes the bug:
  62. > The `hello` function crashes on the empty string. Please write a test that reproduces this bug, then fix the code so it passes.
  63. ## More
  64. OpenHands is capable of helping out on just about any coding task. But it takes some practice
  65. to get the most out of it. Remember to:
  66. * Keep your tasks small
  67. * Be as specific as possible
  68. * Provide as much context as possible
  69. * Commit and push frequently
  70. See [Prompting Best Practices](./prompting-best-practices) for more tips on how to get the most out of OpenHands.