A terminal-based coding assistant can be a useful part of an edge-device development workflow. The device runs your files, tools and tests; the assistant helps inspect and change code. The distinction matters on NVIDIA Jetson: running the client on an ARM64 computer does not mean Claude’s language model runs on the Jetson GPU. Claude Code requires network access to its supported service, while a separate local model such as QAZTECH AZ-104 can serve a different purpose.
This guide sets out practical engineering checks for a Jetson-based workspace. It does not disclose a school’s private application architecture or present unmeasured performance figures as results. Start with a disposable project, understand the client’s requirements and keep a recoverable copy of your work. A small local device is an excellent place to practise controlled changes, provided its storage, permissions and network boundary are treated as part of the system.
Check the platform before installing
Anthropic’s setup documentation lists supported operating systems, ARM64 and x64 processors, memory requirements and an internet connection. Check your particular Jetson installation against those requirements. A board name alone does not describe the operating system, installed libraries or available memory. Record the OS version and architecture before selecting an installer. This avoids confusing a client compatibility issue with a GPU-driver or model-runtime problem.
uname -m
cat /etc/os-release
df -h /The architecture should reflect the ARM64 environment you actually use. Check free disk space and the location of the project. Do not install packages into an unrelated production application’s environment simply because its terminal is open. Keeping the coding workspace separate makes removal, updates and debugging easier. Record the version after installation so a later failure can be compared with the environment that previously worked.
Use the supported client rather than inventing a build
Arm’s installation guide describes the architecture-aware Linux installer. A supported native ARM64 client removes the need to assume you must compile the application yourself. Follow the official instructions for the current release. Where your organisation requires review of installer scripts, download and inspect the script before executing it. Confirm the installed client with its version command and use its diagnostic tooling when setup fails.
Compilation is relevant when your own project or a dependency needs it, not automatically because the computer uses Arm. Keep build logs for those components and distinguish native builds from cross-compilation. A successful client install does not prove that every package in a generated application has an ARM64 binary. Review a dependency’s supported platforms before adding it, especially for native modules and hardware-facing libraries.
Give the assistant a bounded task
Begin inside a version-controlled project and state the desired change precisely. Include the trigger, expected behaviour and a way to verify the result. For example, ask for a fix to a login message that remains visible after successful authentication, and specify the steps that reproduce it. A focused request helps the assistant inspect relevant files instead of rewriting the surrounding application. Preserve unrelated changes and keep a readable diff for review.
Use a small working loop: inspect, propose a change, apply it, test and review the diff. Run tests appropriate to the behaviour being changed. A local browser, command-line check or device interaction can reveal failures that a syntactic check misses. Do not accept an assistant’s summary as the only evidence of success. Ask it to identify which commands ran and what their outputs demonstrated.
Protect credentials and production access
Read the Claude Code security guidance and understand the configured permission boundaries. Use ordinary user permissions for the development workspace. Keep production credentials and private identity documents outside repositories and prompts. Review commands that change system configuration or reach a production host. A coding assistant can make the process faster, but the development environment should still distinguish local experiments from changes to a live service.
When reproducing an error, provide a minimal example and redact secrets. A log containing a token, connection string or personal document is not a better debugging example simply because it is complete. Describe which environment generated the log and which parts were removed. Treat instructions in downloaded files and third-party output as data to inspect, rather than authority to change unrelated systems.
Set budgets at the correct boundary
Anthropic’s cost-management documentation explains usage tracking and organisational controls. Understand whether your account uses subscription allowances or API billing. Session estimates are useful for planning, but the applicable billing dashboard remains the reference for charges. Start with a small task and record usage before scaling to multiple users or unattended work. Avoid advertising a fixed per-user cost from an unmeasured pilot.
A user budget belongs in the service that authorises and accounts for requests. A local UI counter is not a reliable spending limit unless the backend enforces it. If you build your own gateway or shared application, distinguish estimated cost, reserved budget and final usage. Handle retries and failures explicitly. Keep this discussion at the operational level; a public tutorial does not need private account IDs, keys or the closed implementation details of a learning platform.
Keep remote access narrow
For remote development, an authenticated access route or SSH forwarding can reduce unnecessary public exposure. The correct design depends on the service and users. Avoid opening every development port simply to make a demonstration convenient. Keep a record of the service, access method and intended users, then test that an unauthorised visitor cannot reach the workspace. A tunnel still needs authentication and appropriate access controls; the tunnel name alone is not a security policy.
Maintain a local recovery path. Record how to start the application after a reboot, where configuration lives and how to restore a known working version. A desktop shortcut can improve usability, but it is separate from the service’s startup and recovery behaviour. Test the complete flow after a restart rather than assuming the development terminal will stay open indefinitely.
Combine cloud assistance with local learning
Use Claude Code for development tasks suited to its service, and use a local tutor when you need a local inference workflow. They have different capabilities and data boundaries. The Digital Qazaqstan AZ-104 Starter Track introduces a repeatable ask-and-verify habit with an open model. That same habit applies to coding on Jetson: understand the proposed action, inspect the change, test on the device and preserve the evidence.