Summary
Point is designed for a workflow where coding agents write, check, explain, and repair software continuously.
The compiler is the agent's IDE — stable semantic refs, structured diagnostics, and ordered repair plans beat line-number guessing on raw TypeScript.
For the full comparison to TypeScript, Python, and prompt-only workflows, see Point vs other languages for AI engineering. For worked examples and benchmarks, see Proof of concept and Agent repair tests.
Benchmark: 34+ repair cases with CI gate at 100% sufficiency; narrow .point context vs whole-file TS/React paste.
The problem with raw text
Agents can read source files, but raw text is a weak interface for repair. Line numbers drift after formatting. Generated names hide intent. Large files force the agent to infer which symbol matters.
Point exposes compiler context as CLI output, so agents can ask the language for the symbols, diagnostics, explanations, and repair steps they need.
The agent loop
Use this loop for .point files:
point check-json examples/math.point
point index examples/math.point
point explain examples/math.point point://semantic/Math/label.score status
point repair-plan examples/math.pointThen patch the semantic source and run point check-json again until it returns success.
For multi-step agent flows, use pipeline, session, and prompt blocks — see examples/pipelines/ and examples/agents/support-chat.point.
Public refs are semantic
For public .point source, prefer point://semantic/... refs. Core refs may appear in internal compiler paths and generated target details, but semantic refs are the right interface for authors and agents.
Narrow context is better context
point explain lets an agent focus on one declaration and its related refs. repair-plan turns diagnostics into a sequence of patch targets. This keeps context small and precise.