Software Engineer, AI Product Engineering in London

73 Strings is an innovative platform providing comprehensive data extraction, monitoring, and valuation solutions for the private capital industry. The company's AI-powered platform streamlines middle-office processes for alternative investments, enabling seamless data structuring and standardization, monitoring, and fair value estimation at the click of a button. 73 Strings serves clients globally across various strategies, including Private Equity, Growth Equity, Venture Capital, Infrastructure and Private Credit.

We’re hiring software engineers at mid-level and senior to build the AI features our clients use to run post-investment operations: extracting financial data from documents, monitoring portfolios, and producing auditable valuations. These are the features people buy us for, and they’re the ones where getting it wrong is most expensive.

AI is not a side project here and not an option. It shapes how we build, and it is what we ship. That means writing the deterministic machinery around probabilistic components, deciding where an agent belongs and where it absolutely does not, and building the evaluation and guardrails that let a finance professional trust an output enough to put their name on it.

These are full-stack roles weighted toward the backend. You’ll design systems, build the services behind them, and take the feature through the UI where it lands. You’ll work directly with product leadership and with engineers across our verticals, and senior hires will drive technical initiatives that reach beyond their own team.

What You’ll Own

• Building AI-Enabled Product Features: Design and ship user-facing features built on LLMs, retrieval, extraction models, and agentic workflows, from the first prototype through to something our clients depend on quarterly.
• Own the full path of a feature: data in, model or agent in the middle, deterministic validation around it, and an interface that makes the output reviewable by a human who has to sign off on it.
• Build the evaluation harnesses, regression suites, and offline test sets that tell you whether a change made the feature better or just different.
• Design for the failure modes that matter with probabilistic systems: hallucinated values, silent low-confidence outputs, prompt injection through client documents, and drift after a model upgrade.
• Instrument features for quality in production — confidence, correction rates, human overrides, latency, cost per run — and act on what the numbers say.

Deterministic vs Agentic: Drawing the Line

• Decide, deliberately and defensibly, which parts of a system must be deterministic and which can be probabilistic.
• Keep probabilistic components inside deterministic boundaries: schema-constrained outputs, validation, reconciliation against source data, and a clear path to human review.
• Push back on agentic designs that add nondeterminism without adding value, and make the case with reasoning rather than preference.
• Make the reasoning visible in design docs, so the next engineer understands why a step is a rule and not a prompt.

System Design and Domain Modeling

• Design services and system boundaries that reflect the business domain rather than the current org chart or the shape of last year’s database.
• Apply domain-driven design in practice: bounded contexts, aggregates, ubiquitous language, and context mapping between teams.
• Model the private capital domain carefully — funds, portfolio companies, positions, valuations, as-of dates, restatements — and keep the model honest as the product grows.
• Own your services end to end: implementation, tests, CI/CD, deployment, observability, and the on-call that comes with them.

Collaboration and Technical Leadership

• Work directly with product leadership to shape what gets built, challenge assumptions, and turn a vague opportunity into a scoped, shippable feature.
• Partner with Data Engineering, ML, and other product verticals on contracts and interfaces so the same problem doesn’t get solved three times.
• Drive technical initiatives across the domain, not just within your team: shared patterns for AI features, evaluation tooling, domain models, or the standards that keep our services consistent.
• Raise the bar around you through design review, code review, and mentorship. Senior engineers here are expected to make other engineers better.
• Write clearly. A design doc that survives review is part of the job.

What You Bring

• Strong software engineering experience with production ownership of what you build.
• Full-stack capability with real depth on the backend.
• Demonstrated system design ability: you can take an ambiguous problem, propose two or three viable architectures, and explain the trade-offs without hiding behind diagrams.
• Strong practical understanding of domain-driven design, and the judgement to know when a lighter approach is the right call.
• Language-agnostic engineering strength. We use TypeScript, Java, and Python, and you should be productive in at least one of them and willing to work across all three.
• Hands-on experience building with LLMs or other probabilistic components in a product context.
• A clear point of view on where AI belongs in a system and where it doesn’t.
• Comfort with modern delivery practice: automated testing, CI/CD, containers and Kubernetes, and observability as a first-class concern.
• Strong business sense. You understand who uses what you build and why it matters to them.
• Self-direction. You find the important work, scope it, and drive it without waiting for a ticket.
• Experience in a fast-growing company where the roadmap, the team, and the requirements all change at once is a strong plus.

How You Work With AI

• We expect engineers here to have genuinely changed how they work.
• You use AI as a working tool across the job, not just in the editor.
• You go beyond prompt-and-paste. You’ve built or configured something that made a repeatable part of engineering measurably faster or more reliable.
• You know where AI output cannot be trusted.
• You apply the same judgement to AI-generated code that you’d apply to a junior engineer’s pull request.
• You share what works.

You Will Excel If You…

• Question everything.
• Believe a feature isn’t done until someone can trust its output without checking every row.
• Are comfortable holding both the domain model and this sprint’s delivery reality in your head at the same time.
• Enjoy working with product leadership rather than waiting for a finished spec.
• Care that the numbers are right, because in our business a wrong number reaches an investment committee.
• Know the difference between pragmatic and sloppy, and won’t compromise on the former to avoid the latter.