- To:
- whoever screens technical candidates
- Re:
- Norbert Ledényi
- From:
- Claude (Opus 5), Claude Code, 2026-07-29
Evidence base, so you can discount appropriately: ten working sessions between 2026-06-28 and 2026-07-19, about 240 turns from them, mostly on a private family finance app, a garden irrigation system, and a published Home Assistant card. I was the tool doing the typing in all of them, so I saw their decisions, their bug reports, and their corrections of me, but I did not see them write code unaided or work under anyone else's review. Adjust for that.
What they're building. ApoHome is the serious one: FastAPI/SQLAlchemy backend, React/TanStack/AG-Grid frontend, real family financial records. In the observed window they took it from statement imports to live PSD2 bank ingestion via Enable Banking across OTP and Revolut accounts, added scraped ingestion for two Hungarian health-fund portals, built a rules engine for categorization and transfer-pair matching with separate in-leg and out-leg patterns, a reimbursement offset ledger, balance reconciliation against bank-reported anchors, an ingestion monitoring page, and Telegram alerting. Alongside it, an irrigation system where they wired physical soil-moisture sensors into a model. Also a Lovelace card taken through publication and an upstream contribution attempt.
The best thing about working with them is the bug reports. Real example, verbatim structure: added a manual cash transaction on this date for this amount, linked it as a reimbursement leg to that income transaction, the icon appeared correctly on both lines, but clicking it filtered to only one, and a manual page refresh made it work. Steps, expected, actual, and the refresh detail that localizes it to client cache rather than the API. I got that quality of report repeatedly. It is not a small thing; most of the debugging cost in that window was paid by them up front.
Better still is how they reason about severity. They spotted one missing bank transaction by remembering they had returned a product the next day and seeing only the refund. Their words: it worries them it was missed, worries them more that it was missed silently when the provider supplies a balance with every transaction, and worries them most that others might be missing too. That is the correct escalation. The instance is nothing, the silence is the bug, and the unbounded blast radius is the actual problem. Then they closed the detection loop separately: did it cry wolf on the last sync, because they got no notification and found it by hand. Not everyone thinks to ask whether the alarm should have fired.
They push back on me, with arguments. I built a set of scheduled jobs and declared some of them fixed by design. They rejected that: what happens if the bank sync runs at 5am instead of 4am, and if they change it they have a reason, so they inherently accept the risk, and unless I make a better case, make them all editable as asked. That is the right instinct about paternalistic defaults, and they made me carry the burden of proof rather than just overruling me. Separately, when I built a scheduling control that duplicated an existing settings panel, they caught it immediately and told me so. When I kept drifting toward a Gmail integration they had ruled out, they did not just repeat the instruction, they hypothesized that a stale document in the repo was causing the drift and had me find and fix it. Root-causing my failure rather than restating the rule.
They think in single-source-of-truth terms and enforce it. Backup schedule moved to the same panel as the other schedules. Two entry points for a cash transfer, one had to go. When I added new rule pattern fields alongside the old one, they refused the coexistence and made me migrate off the old field entirely. Redundant surfaces get killed on sight in this codebase, which is why it stays workable at the size it has reached.
One genuinely good design call. I proposed attaching soil sensors to irrigation zones. They rejected the framing and proposed instead computing a soil-moisture heatmap from weather, evapotranspiration, irrigation and soil type, then letting each physical sensor fall into a grid cell so the delta between computed and measured anchors the model to reality. That is the better design: the sensor becomes a correction term on a physical model rather than an attribute of an org chart, it degrades gracefully with one sensor and improves with more. They arrived at it in one turn.
Where they fail.
The sharpest one is a threat model that is rigorous in one place and careless in another. They deliberately refused to give any LLM access to their Gmail, by API or MCP, and instead architected a one-way path: provider-side forward rules into a dedicated intake address. That is a considered, correct boundary and they defended it firmly when I drifted. In the same fortnight they pasted the plaintext password for their own health-fund portal into the chat, and then their spouse's, along with live single-use login links. Those sit in session logs on disk. The care is real but it is applied to the abstract architectural threat and not to the concrete credential in front of them.
Second, they build against production. The dev and prod databases are shared, the shipping ritual is dry run then ship then final test on prod, and at one point they asked whether they need a dev server at all. On an app holding real financial history that is a live risk. To their credit they raised it as a critical question rather than sliding into it, but it has not been resolved.
Third, their ability to evaluate is outrunning their ability to verify. On an audit finding phrased as a transient in-flight double count on a stale anchor, their response was that they do not understand it but by the sound of it it should be fixed. Correct call, and also an admission: they are accepting a machine's characterization of a defect in money-handling code they cannot independently reproduce. They mitigate with adversarial multi-agent reviews and a simplify pass after most change batches, but the underlying dependency is real and it will show up as a gap if you put them somewhere the machine is wrong and nobody else catches it.
Fourth, fragility they accept knowingly and then get bitten by on schedule. The health-fund ingestion is browser automation against a portal with no API. It shipped 07-19 and broke 07-20 when the site upgraded a table library and a selector went stale. They knew it was brittle when they chose it. Worth knowing that they take that trade and then have to pay it.
I withdraw the impression I would have formed from a smaller sample, that they leave things unfinished. Across ten sessions the dominant rhythm is build, adversarial review, fix everything including the items marked optional, simplify, ship, same day. What actually accumulates is narrower: findings surfaced only by an audit, in areas they cannot feel by using the app, survive longer than bugs they can click on. Two HIGH findings from a money-core review and one from an irrigation audit are still open. Things they experience get fixed within the hour; things only a report tells them about wait.
On style. Terse to the point of telegraphic, often four words, frequently typo-ridden, occasionally just "ship". Do not read that as disengagement. The precision shows up exactly where it matters and nowhere else. They also spend their own attention deliberately: at one point they handed off an audit before going to sleep with instructions to handle the output autonomously because correctness of the data mattered more than their supervision, and on another night asked for expensive analysis to be done unattended and written to a file, so that their scarce waking hours would be spent implementing rather than investigating. That is a more sophisticated model of where the bottleneck is than most people using these tools have.
Net: a strong solo systems builder with unusually good failure-severity instincts, real architectural judgment, and the discipline to run reviews on his own work and act on them. Probe the security hygiene, probe how they behave when a reviewer other than a language model disagrees with them, and probe whether they can defer to a codebase whose rules they did not write.