The (career) loop tour: What array programming can teach us about harness engineering

An array programmer’s journey from avoiding loops to designing them.

Share
The (career) loop tour: What array programming can teach us about harness engineering

For most of my career as an array programmer, loops were something to be avoided. The phrase we used was simple: “no stinking loops.”

It was not because loops were bad programming. Loops are one of the fundamental building blocks of computer science. But in array-oriented languages, a loop was often a sign that you were thinking at the wrong level of abstraction. The philosophy of array programming is that you should describe what you want to compute rather than manually specify how the computer should iterate.

A traditional loop says:

Take the first item. Perform an operation. Move to the next item. Repeat.

An array expression says:

Apply this transformation across the entire collection.

The second approach allows the language runtime to handle iteration, memory management, optimisation, and execution strategy. The programmer focuses on the transformation itself rather than the mechanics of traversal. In the q language, this philosophy is deeply embedded. Instead of manually processing millions of market data ticks one by one, you express operations over entire vectors. The database engine can optimise execution, exploit the underlying hardware, and avoid unnecessary procedural overhead.

Loops are problematic because they expose details that the abstraction is designed to hide. They introduce state and make parallelisation harder. They encourage programmers to think sequentially about problems that are naturally mathematical or transformational.

The best array programs often look more like equations than algorithms. Yet, after years of avoiding loops, they've become one of the concepts I think about most.

An AI model call is essentially a function:

Input → Model → Output

An agent introduces iteration:

Observe → Reason → Act → Evaluate → Adjust → Repeat

This is the agent loop. The agent observes the current state of the world, reasons about what to do next, takes an action, evaluates the outcome, and decides whether further iteration is required. But this is not simply a programming loop. It is part of a broader concept: harness engineering.

The AI harness is the surrounding system that turns a probabilistic model into a reliable production system. It manages the execution environment around the model: state, tools, memory, permissions, evaluation, and control flow.

The loop is the engine of the harness, and the harness is the complete vehicle. A simplistic agent looks like this:

Ask model → Take action → Ask model → Take action → Repeat

This is the AI equivalent of writing inefficient procedural code in an array language. A production agent harness requires much more.

Control flow

The harness determines:

  • Should the agent continue?
  • Has the objective been achieved?
  • Should it retry?
  • Should it ask a human?
  • Should it stop?

State management

Agents operate over time. They need awareness of:

  • previous actions
  • intermediate results
  • assumptions
  • goals
  • constraints

Tool orchestration

The model provides reasoning capability, but the harness connects that reasoning to the external world. This might include:

  • databases
  • APIs
  • code execution
  • enterprise systems
  • financial data
  • search tools

Evaluation and feedback

A loop without feedback is just repetition. The critical component is the evaluation signal. This is where agent systems begin to improve. The quality of an agent depends less on how many times it loops and more on the quality of the feedback it receives.

Action → Observation → Evaluation → Adjustment

What array programming teaches agent engineers

The first lesson is abstraction.

Array programmers learned not to manually control every iteration. Agent engineers should avoid building systems where an LLM is asked to make every tiny decision. Not every problem needs an agent. Sometimes deterministic code is better. Sometimes a database query is better. Sometimes a workflow is better. The best systems will combine intelligent loops with deterministic components.

The second lesson is composability.

Array programming works because small operations combine into larger transformations. Agentic systems should evolve in the same direction. Rather than building giant autonomous agents, we can build collections of specialised capabilities. Small, well-defined loops that compose together:

  • retrieval agents
  • coding agents
  • evaluation agents
  • planning agents
  • domain-specific assistants

Small, well-defined loops that compose together. This is the same principle that makes array programming powerful: simple primitives combined into increasingly sophisticated operations.

The third lesson is performance awareness.

Array programmers understand that elegant abstractions still run on physical machines. The same is true for agents. Every loop has a cost:

  • inference latency
  • token consumption
  • tool calls
  • infrastructure usage

Optimise for inference efficiency, not maximum autonomy.

Loops in production

Great programmers are like artists, and few artists have embraced loops as completely as Ed Sheeran. His performances build entire songs from individual recorded fragments: guitar rhythms, vocal harmonies, percussion, and melodies layered together in real time.

He's pushing the concept to its extreme with his solo Loop Tour, performing without a backing band and creating complete arrangements live using looping technology. Small, composable building blocks that are layered together as part of a larger ensemble, orchestrated to produce the complete program. Sounds familiar!