Add a feature end to end: a contact form in ASP.NET Core
From one sentence to a working feature: a Razor view, a model, a controller action and a build check. See how Gravity plans the work and how you review it.
A new feature usually touches several files: a model, a controller, a view, sometimes configuration. None of it is hard, but it is a lot of small edits that have to agree with each other. This is the kind of work Gravity is built for. This article walks through one small, realistic example: a contact form in an ASP.NET Core MVC project.
Prepare
Commit your work so the new feature is the only change in the diff, and keep the approval mode on Review. Open the project as your workspace.
Describe the result, including the rules
A good request says what the user sees and which conventions to follow. Compare these two:
Add a contact form.Add a contact form to this MVC project. It needs name, email and message,
validation attributes on the model, a ContactController with a GET and a POST
action, and a Razor view that matches the layout of the existing pages.
Show a thank-you message after a valid submit. Then run dotnet build.The second request gives Gravity the files to create, the behaviour to build and a check to finish with. It also tells the agent to look at the existing pages first, so the new view matches your project and not a generic template.
Read the plan
Before editing anything, Gravity shows the plan. For this request it will look something like: search the project for the existing layout and a similar controller, create the model, create the controller, create the view, run the build and verify the result. If the plan is missing something, for example you also want the message stored, say so now. It is much cheaper to change the plan than the code.
Review each file
In Review mode each new file arrives as an approval card with a preview. Read the model for the validation rules, read the controller for what happens on a valid and on an invalid submit, and read the view for the form fields. Approve what is right. If something is off, reject it with a short instruction, such as "use the existing email service instead of a new class", and the agent tries again.
Let the build check it
The last step runs dotnet build. If the build fails, Gravity reads the error, fixes the cause and builds again. When it cannot get to a clean build it tells you what is blocking it, so you know exactly where to look.
Finish like any other change
- Run the site and try the form with good and bad input.
- Look at the full diff in your Git client.
- Commit, or discard the branch if it is not what you wanted.
What to take from this
The skill is not in the typing, it is in the request. Name the files, the behaviour and the check, and ask Gravity to follow the conventions it finds in your code. You spend your time on decisions, not on boilerplate.
Gravity is free to download with an account, so you can try this on a branch of your own project today.