AI for Writing JavaScript: Brief, Test, and Review Changes

Use AI for writing JavaScript by supplying the runtime, a narrow requirement, and examples of correct behavior, then reviewing and running the proposed change. Treat the result as a draft that must work in your project. fenbs can keep the conventions, unresolved questions, and lessons available when a different assistant continues the work.

How do you start with a change you can verify?

1. Describe one visible outcome, such as filtering a list when a person selects a category.
2. Locate the current function and the code that calls it. Share the relevant parts through your approved development setup.
3. Specify inputs, outputs, failure behavior, and the checks you will use before requesting code.
4. Ask for the smallest proposed change, review its differences, and run it in the target environment.

Say you maintain a small shop website. The task is to return only products whose category matches a selected category. That is a useful first request; replacing the product system, changing the page design, and adding analytics are separate decisions. A small change makes unexpected behavior easier to trace.

Keep an unchanged baseline so you can see exactly what the assistant altered. Ask it to explain assumptions before editing. If it cannot locate the existing behavior or does not know how the project runs, resolve that gap before accepting a replacement built around guesses.

What context does the assistant need before writing code?

JavaScript in a browser and JavaScript running on a server have different surrounding capabilities. Name the runtime and version, the framework if any, the module style, and the commands already used by the project. Include the relevant package documentation when a library API matters; an invented method name can look convincing.

• Scope: the function or component to change and the files it may edit.
• Contract: accepted input types, returned values, and whether the function may change its inputs.
• Conventions: naming, formatting, error handling, and whether additional dependencies are allowed.
• Verification: the existing test command and one real user journey to exercise.
• Boundaries: no credentials, private production data, deployment, or unrelated cleanup in the request.

For a coding environment overview, see what Cursor is; the workflow here applies regardless of which assistant you choose. Put lasting project instructions in fenbs AI context, so another session can read the same requirements rather than reconstructing them from a code fragment.

What should a useful JavaScript prompt include?

Use examples that settle ambiguous behavior. In the product filter, does an empty selection mean all products or none? Are category IDs strings or numbers? Should an item without a category be ignored or reported? The person responsible for the feature should choose those answers.

Write filterByCategory(products, selectedCategory).
Runtime: our existing browser project; no new dependencies.
Each product has a string categoryId. Selection is a string or null.
Null means return all products in a new array.
Otherwise return exact matches in their original order.
Do not mutate the input array or its objects.
Ask about any missing requirement before changing code.
Show the proposed function and tests separately.

Requesting exact matches has a concrete meaning: MDN explains strict equality↗ (opens in a new tab) and its treatment of values with different types. If the application receives numeric IDs somewhere else, decide where conversion belongs instead of silently loosening every comparison.

Then ask for a short explanation of each branch, not a confident claim that the function is production ready. Keep explanation and execution distinct. An assistant that merely describes a test has not demonstrated that it ran in your repository.

Which tests catch mistakes that a good explanation misses?

Choose expected results independently of the generated implementation. If the assistant writes both function and tests around the same wrong assumption, a passing result can preserve the mistake. Write the important examples before accepting its code, and compare them with the requirement.

Run the relevant checks, then try the browser interaction that uses the function. Check loading, empty, and failure states if the change involves network requests. Record the command and actual outcome, including anything not exercised, so the next reviewer can distinguish evidence from a plan.

What needs human review before you accept the change?

Read the changed lines for extra network calls, hidden state changes, and new dependencies. Check how untrusted input reaches the page. For plain text inserted into a page element, MDN documents textContent↗ (opens in a new tab) and explains why it differs from parsing text as HTML. The correct choice depends on what the feature is supposed to display.

Also review maintainability: can someone understand the function without the chat? Reject clever abstractions that make a simple requirement harder to inspect. When a failed approach reveals a reusable trap, save the cause and the better check as a lesson, rather than saving only the final code.

How to do this with fenbs

1. Create a free account and add a project for the application.
2. Record the human-approved runtime and editing boundaries in Decisions and rules; leave unresolved choices open.
3. Add the JavaScript change as a task, with examples of expected behavior in its plan.
4. Connect a supported assistant, ask it to read the project context, and keep code changes in your development environment.
5. Save test outcomes, reusable lessons, and Where we left off before ending the session.

fenbs keeps the work record; it does not execute JavaScript or replace your editor, repository, or test runner. For a single disposable snippet with no continuing context, your current editor may be enough. The AI brain overview explains when a separate record becomes useful.

For prose documents rather than code, use the separate AI report-writing guide. You can find other practical workflows in AI at work and the guide to using AI at work.