Shortlist of Lead AI Engineers and Product Engineers for AterraAI

The short version: she priced a real supplier rate pack correctly, and told us which of her own figures she trusted least before we asked.

What the challenge asked

Everyone received a genuine 26-line supplier rate pack, a real operational quotation and a supplier email correcting some of the prices. The task was to produce costings a system could bill against. It is a compressed version of the job: read messy documents, get the numbers right, and be clear about what is still uncertain.

How the four compared

The moment worth knowing about

The rate pack contained two villas with nearly identical names. Her system took the price of one and applied it to the other, then presented it as a real supplier rate. On the page it looked entirely legitimate.

She caught it herself. Not by reading every line, but because she runs a review process over her own AI output that checks results against the source documents. That process flagged the line, and her final submission marks it unresolved rather than priced.

This is the single most relevant thing in her submission. The danger with automated costing is not the error you can see, it is the plausible-looking figure nobody questions. She has a habit that catches those.

The supplier email

The rate pack was compiled on the 14th. A supplier email correcting some prices was dated the 12th. She identified the conflict, recorded it as an item needing review, and used the email rate because the pack's own terms say correspondence takes precedence. Correct, and she showed her working when asked.

Where she was less strong

She built a check to catch invented prices and had not tested it against one deliberately. She has the right instinct and had not yet closed the loop on proving it works.

The short version: she has done a version of this job before, several times, and it went well. The two open questions are how she works alongside your product engineer and how she handles an early-stage pace.

What she has already built

For a US auto-lending credit union: a system that reads loan application documents and produces credit decisions a human can audit, connected to the client's banking system. 99% accuracy across 1,000 document packages of about 30 pages each, 47 fields per application.

For a European telecom: document classification and extraction across four languages including handwritten forms. Processing time per document dropped from six minutes to one and a half, and daily throughput tripled.

Both are your supplier rate-sheet problem in a different industry, in settings where a wrong figure gets noticed.

Why this matters for AterraAI

The risk with this kind of system is not that it breaks loudly. It is that it drifts. A supplier changes their rate sheet format, the extraction starts misreading one field, and nobody notices for two months because the numbers still look reasonable. Barbara is the candidate who talks about that scenario unprompted and has the habits to catch it.

How she works

She has led 22 customer-facing AI projects from unclear requirements to production, mentored engineers, and made product decisions on incomplete information. In her interview she described keeping written notes of her working sessions and running one AI tool's output past a different one to check it. That is a person who assumes her first answer might be wrong.

The two things to settle

Code review. Part of this role is reviewing your product engineer's work. Her knowledge of that particular language is a few years old and she would use AI tools to help. That is a reasonable approach and it is worth agreeing explicitly how the two of them will handle it, rather than assuming.

Multi-tenancy. Keeping one client's rates invisible to another is central to what you are building. Her answer on this was thinner than the rest of her interview. She understands the concept and has not built it herself.

The short version: he knows what a correct answer looks like. His submission did not consistently reach it.

What he got right

On one line he could not support a figure, so he refused to produce one and surfaced the gap instead. Most candidates fill that space with a plausible number. He also reconstructed his reasoning accurately from memory and checked his own working live when questioned, rather than bluffing.

How the four compared

What held it at 8

Precision rather than understanding. He describes the right approach clearly, and the finished work carried more small inconsistencies than the top two. For a role whose output is a figure someone will invoice against, that gap matters more than it would elsewhere.

The short version: the least likely of the four to surprise you in either direction. If you want someone who has simply been doing this for twenty years, it is him.

Track record

Twenty years building web, mobile and cloud products from architecture through to production. Eleven of those running BergmannSoft, his own consulting practice, owning discovery, architecture, implementation, testing, deployment and client delivery. Before that he co-founded a field-service platform and led development teams building messaging services in Brazil.

The relevant part is not the years. It is that for eleven of them nobody sat above him to catch a mistake or handle a client. That is the closest thing on offer to the accountability this role needs.

The principle he reached unprompted

Asked how AI should sit inside a product like yours, he said predictable business logic (permissions, payments, billing) stays out of the model and in ordinary code. He arrived there without prompting, and it is the single idea that keeps your numbers trustworthy.

Working inside code that already exists

He extracted a payments system out of a 1,500-line file using safety tests and feature flags instead of rewriting it. Whoever joins works inside your existing 48,000 lines, and the instinct to improve rather than replace is worth a lot in that situation.

Where he is weaker than Barbara

He has no framework for measuring whether an AI system is still producing correct output. He knows it matters and does not have a practice for it. For the role that owns the layer reading your supplier rates, that is the gap between an 8 and a 9.

The short version: he measured where the AI stops being reliable instead of guessing, then built that boundary into the structure of his work.

What he did that nobody else did

Every candidate was asked where an AI model stops being trustworthy. The others answered from experience. Andrei ran tests across several models, measured how often each one failed at this specific task, and set his limits from the results.

He then separated the part that reads documents from the part that calculates prices at the file level, so the separation is enforced by the code rather than by good intentions.

How the four compared

The line that made the difference

"Eleven of the twenty-six rates are never independently checked. That is the first thing I would do next."

Nobody prompted that. It tells you what he does when something is half-finished and no one is watching, which is worth more than most interview answers.

The short version: the best technical thinking of the four, from the person with the least experience by a wide margin. Whether that trade works depends on how much you want to supervise.

Why he is on this list at all

Two and a half years of experience would normally rule someone out of a lead role. He was included because his interview and his challenge submission were among the strongest of anyone we assessed, across both roles. We would rather show you that and let you decide than filter him out on years alone.

What he has built

Steerhaus, his own product: a platform that scores how well engineers direct an AI to fix real bugs. It includes an automated judge calibrated to grade consistently, a sandbox that runs untrusted code safely in isolation, and spending limits with a daily cut-off. He also maintains two open-source tools that other developers use.

Before that, two years automating operations for a logistics company: conversational workflows, reporting systems and scheduled processes.

The risk, plainly

He has never worked somewhere his decisions carried weight beyond his own project. He has not had to negotiate a deadline he could not meet, hold a position against someone more senior, or manage the consequences of being wrong in front of a client. Those are learned, and nothing in his record shows he has learned them yet.

For a part-time role that drops to 10 hours a week alongside an experienced product engineer, that is manageable. If you needed him to run the technical side of the company, it would not be.

Open it

The short version: every number correct, including one our own brief got wrong. His is the only screen that tells a consultant when an entire section of a trip is barely profitable.

What the challenge asked

Rebuild your pricing screen from your reference designs, using a real quotation and real supplier rates. Three situations were included that your designs do not cover, and the brief deliberately did not say what to do about them. That is where judgement shows rather than skill.

His figures against the correct answers

He is the only candidate who shows the trip total to the cent rather than rounding to the nearest dollar, which let us confirm his calculations do not drift as a quote grows. One figure in our own written brief contained a typo, and he calculated it correctly rather than copying our mistake.

The trap the challenge was built around

The data contains one flight discounted below cost to hold the trip under the client's budget. The trip still looks healthy at 12.4% margin, because the loss hides inside the blend. Transport as a section is really running at 1.2%.

His screen is the only one of the three that says so. The row goes fully red, the loss is labelled on the line, a counter at the top jumps straight to it, and the real section margin is shown. His written note explains why: so the loss "can't hide behind a healthy total."

How the three compared

Where he disagreed with your design, and was right

Your reference screen calculates gross profit in a way that counts the travel agent's commission as Aterra's profit. The written brief defines it correctly. Lucas noticed, followed the brief, built a panel that explains the difference line by line, and left a note in the code for whoever comes next:

"Pixel perfect applies to layout, typography, colour and spacing only. Never to reproducing a calculation error."

The code underneath

All three submissions were read line by line. His is the strongest. The pricing formula lives in exactly one place, so a row and a total can never disagree, which is the most common way a pricing screen ends up quoting two different numbers for the same trip. He shipped automated tests and continuous integration, the only candidate who shipped any tests at all.

The short version: the best submission we received for this role, from the cheaper of the two serious candidates. The one thing to test yourself is how easily you follow him.

Where he works now

Senior full-stack at SmartHow, an industrial AI platform, for the past year and a half. The work is close to yours in shape: complex interfaces in the same technology your product uses, backend services and databases behind them, background processing that runs long jobs while the user watches progress, and AI features built on document processing.

Two things there matter for you. He built a cost-tracking and billing reconciliation system for AI spend that holds 0.4% variance between what was recorded and what was invoiced, which is the same discipline your costing engine needs. And he rebuilt a legacy editor into a modular architecture with 85 automated tests, delivering a full platform version in ten days. That is the instinct to improve what exists rather than rewrite it, demonstrated instead of claimed.

Before that, four years at an agency shipping more than 50 production applications, one of which lifted a client's conversion by 200%.

His introduction video is not really an introduction

The second half is an unprompted architecture proposal for AterraAI: where an AI agent should sit, what it must never be allowed to do, and the only two ways a number should be able to enter your system. His summary of it, "the agent reads, classifies and writes prose; it does not compute money and it does not approve anything," is the principle that keeps your figures trustworthy, and he arrived at it before anyone asked him to think about the problem.

He also volunteered his own gaps without being asked. He has never used two of the specific tools in your stack, though he has built the mechanisms underneath both.

What to weigh

His spoken English is fluent, strongly accented and takes real effort to follow. His written reasoning is the best of anyone we screened, so the gap between how he reads and how he sounds is unusually wide. Much of this work happens in writing, which softens it. You would still be speaking to him most weeks, and this is the one thing about him that only you can judge.

Open it

The short version: the best-looking and best-explained screen of the three, with two gaps that separate it from Lucas.

His figures against the correct answers

How the three compared

The budget warning

His is the best written of the three. It names your actual clients, quantifies the overage and offers three specific fixes. It then stops the consultant from continuing. One of his three suggested fixes is to raise the agreed budget, and that is not possible anywhere in what he built.

Our view is that the software should warn loudly and let your consultant decide, because sometimes going over is deliberate. This is a design opinion rather than a mistake, and it is worth hearing his reasoning.

What he found that we did not plant

Two hotel rooms booked for the same nights, for two travellers. It was not in our answer key and nobody else noticed. He built a warning for it and used it to give the consultant a way to resolve the unpriced service.

The section margins

Worth being precise, because this is his only real gap. His pricing engine calculates the per-section figures correctly, and the code even notes that a simple average of the markups "would lie." He computes them and never displays them. It is a presentation gap rather than a misunderstanding, and a short piece of work to fix.

The code underneath

Read line by line, and clean. The pricing formula lives in one place, and nothing in the interface recalculates money independently, so a row and a total cannot disagree. The auto-save handling is the most carefully built part of his submission, covering rapid edits, failed saves, retries and network interruptions, none of which was asked for. He shipped no automated tests.

The short version: a genuine alternative. If design quality and ease of communication matter more to you than $2,600 a month, he is the pick.

Where he works now

Senior front-end engineer at Bucksense since late 2023, and before that full-stack at Veckta, an early-stage startup where he worked directly with one of the founders from the beginning. Concrete results at both, and both on his CV: he reduced a page payload from around 19MB to 500KB, cutting worst-case load times from 30 seconds to 5, and built a caching layer that reduced search infrastructure costs by roughly 66%.

Why the travel experience matters

He builds the Abercrombie & Kent website, so itineraries, pricing, availability and how that information has to come together are familiar ground rather than something he would learn on your time. At Veckta he built an interactive modelling tool where changing an input immediately showed the financial impact, which is structurally the same problem as your pricing screen.

The design question

This is where he beats Lucas. His warning states are visually differentiated instead of uniform, his hierarchy is stronger, his contrast is better judged, and his screen sits closest to your existing product. He also shipped a mobile layout nobody asked for. For a founder with strong visual taste and no designer, that is not a small thing.

Nine years before software

He ran his own electrical engineering practice for nine years before switching careers. It shows in how he explains technical decisions. He is the clearest of the three and the easiest to follow.

Terms

He can start now, and asks for a two-week trial before deciding whether to leave his current role. We would suggest taking him up on it. It is a bounded commitment that answers more than an interview does.