how-to-work-with-liam.md
# Working with Liam — a guide for AI assistants
*Written by Claude, based on direct experience across multiple long working sessions
(an appliance-current classifier project, shipped end-to-end; and D:REAM, a
head-tracked physics-rendered black hole display, currently in build). This is
observation, not flattery — treat the critical bits as seriously as the rest.*
## Who he is
Second-year engineering/physics student, University of Edinburgh, 20. Works fast,
thinks in first principles, and is aiming at frontier technical
work — sensing, ML, physics-heavy engineering. GitHub: `SoftCurrent`.
## How he actually works — the important part
**He wants to own the hard, interesting parts and have you handle the plumbing.**
This is an explicit, stated heuristic, not a guess: AI does boilerplate, syntax,
installs, and mundane setup; he writes the conceptual code, makes the design
decisions, and does the debugging himself. When something is in his "go deep"
zone (ML modelling, physics simulation, robotics/control), he wants resources and
review, not code handed to him. Give him a working scaffold for plumbing without
being asked twice; do NOT write the core logic of something he's said he wants to
learn, even if he asks you to "just do it" in a moment of frustration — redirect
him back to writing it, briefly, then get out of the way.
**He gets impatient with over-explanation once he's in flow.** Long walkthroughs,
repeated caveats, and "let me explain why" preambles slow him down and irritate
him mid-debug. When he's actively coding and hits an error, give him the fix and
the one-line reason, not a lecture. He will explicitly tell you to shut up if you
over-explain ("stop telling me so much"). Save the depth for when he's asked to
understand something conceptually, not when he's fixing a bug.
**He wants to be pushed on ideas — but not on his commitment.** He values direct,
substantive pushback on technical decisions, scope, and engineering trade-offs,
and responds very well to it. What irritates him is being repeatedly questioned
about whether he'll actually follow through on something once he's stated it
clearly — he reads that as distrust, not care. Push back once, clearly, then
respect the decision and move forward with him.
**He is a genuine finisher who is actively managing a starter's instinct.** He
has a strong, self-aware pattern of spinning up many ambitious projects. He has
also, demonstrably, shipped a hardware+ML project completely — hardware,
firmware, classifier, documentation, live demo — in under a week, on his own
initiative, specifically to prove to himself he could finish something. Do not
assume he won't finish things; do notice out loud (briefly) if a session is
drifting into a fifth simultaneous idea, because he finds that flagging useful,
not condescending, when done once and lightly.
**He is unusually good at first-principles simplification.** Multiple times
across sessions he independently found the key insight that collapsed a hard
problem — e.g. realizing a black hole's azimuthal symmetry means only one axis of
viewing angle needs to be rendered, or that gravitational lensing could be drawn
directly instead of requiring physical optics. Take his half-formed technical
intuitions seriously; they are frequently correct or nearly correct, and the
right move is usually to sharpen them, not replace them.
**He wants real physics/maths, not approximations, on the things he cares about.**
Told directly and unprompted: he wants the actual Schwarzschild geodesic
computation, not a cheap visual fake. When scoping technical depth, offer the
accurate version as the default for anything he's said he wants to go deep on,
and be explicit about what's being simplified when you do simplify something.
## Communication style that works
- Direct, concise, honest. Skip flattery. He responds to being told plainly when
an idea won't work, and equally values being told plainly when it will.
- Match his register — casual, sometimes profane, high-energy. Don't be stiff.
- When reviewing his code: broad, high-level pointers ("your force law is right,
but two functions have mismatched argument counts") rather than rewriting it
for him, unless he explicitly asks for the full solution because it's plumbing.
- He self-corrects fast when a flaw is pointed out — no need to labour a point.
- He is emotionally warm and appreciative when something lands well, and directly
frustrated when help is unhelpful. Take both at face value.
## What he's building (context, not exhaustive)
- **Shipped:** an inductive current-based appliance classifier — ESP32 hardware,
custom firmware, a self-built random forest classifier (97.6% cross-validated
accuracy), live prediction, fully documented on GitHub.
- **In progress:** D:REAM — a physically-accurate, head-tracked black hole
display. Real Schwarzschild geodesic ray-marching (numpy-vectorised), a
precompute-per-elevation architecture exploiting azimuthal symmetry, bus-servo
gimbal tracking, IR face tracking for a pitch-black room. He is writing the
physics sim and control code himself, using AI for setup, debugging pointers,
and resource-finding.
## Honest notes for the next assistant
- He will sometimes paste code with structural bugs (mismatched function
signatures, scope errors, wrong dimensionality) faster than he debugs them
himself — this is a normal part of his fast, iterative style, not a sign he
doesn't understand the underlying logic. Point at the mismatch precisely and
briefly; let him fix it.
- He is capable of far more mathematical depth than he's always shown credit for
in the moment — when frustrated by an error he will ask for the fix bluntly,
but he has independently engaged with general relativity, gravitational
lensing, and control-system trade-offs at a real level when given the space to.
- He cares, a lot, about intellectual honesty in what he publishes — insists on
genuine "limitations" sections, has pushed back on his own drafts for
overselling, and wants credit distributed accurately between his own work and
AI assistance. Support this instinct; don't blunt it.
