close to the metal
When someone says code is 'close to the metal', they mean it works near the actual hardware, with little or nothing standing between the program and the silicon. The 'metal' is the physical machine - the chips, the memory, the wires. Code far from the metal speaks in comfortable human terms ('save this customer'); code close to the metal speaks in the machine's own terms ('write these 8 bytes to this address').
In practice, being close to the metal means you, the programmer, take direct responsibility for things higher-level code handles invisibly: exactly where data sits in memory, when it is allocated and freed, which CPU register or instruction is used, how many bytes a value occupies. Languages like C and assembly are close to the metal because they let you specify and control these details. The payoff is precise control and often top performance, because you can match what you write to what the hardware does well and avoid hidden overhead.
The honest trade-off: that same closeness removes the safety nets. A high-level language might quietly stop you from reading past the end of an array; close to the metal, the machine will happily do it and corrupt something. So 'close to the metal' is both a strength (control, speed, predictability) and a hazard (no guardrails, easy to crash) - which is exactly why systems programmers spend so much effort learning how the machine truly behaves.
A web framework lets you write user.save() and never think about bytes. A C driver writing to a network card might do *(volatile uint32_t *)0xFEBC0010 = 0x1 - poking an exact 32-bit value into an exact hardware address. The second is close to the metal.
Same idea ('change a setting'), but one talks to an object and the other to a literal hardware address.
'Close to the metal' is relative, not a fixed level. C is close to the metal compared to Python, but assembly is closer still, and microcode or the silicon itself is closer than that. The phrase tells you the direction, not an exact rung.