What does Hopper actually do?
Most AI coding tools assume the work happens in a familiar loop: open a repo, read files, run tests, inspect logs, repeat. Mainframe work breaks that pattern almost immediately. The useful clue may be on a TN3270 screen, inside an ISPF flow, buried in JES spool, or tied to a dataset and job chain that never appears inside a normal editor. Hopper matters because it starts from that reality instead of pretending the mainframe can be flattened into pasted snippets and generic repo chat. The landing page keeps showing the same idea in different ways: the hard part is not only writing COBOL or JCL, it is navigating the environment around them safely enough to diagnose and fix real work.
What makes the product more than a niche chatbot is the shared-session design. Hopper opens one mainframe session and exposes it through four panels: terminal, datasets, jobs, and the AI agent. That means the agent can read a member, submit a job, inspect spool, decode VSAM data, or step into CICS while the user still sees the same state on screen. The docs also draw a useful safety line. Read-only actions run immediately, but anything that mutates state, such as writing a member or submitting a job, pauses for approval first. That combination of operational reach and visible control is the core reason Hopper feels like a real product rather than a demo layered on top of terminal screenshots.