The prototype was under a black cloth. Ray Fernando had signed the papers, entered the meeting, and still did not know exactly what he was being asked to solve. When the cover came off, he saw an early Apple Watch. He would help make its software updates work. Then came the detail that changed the assignment: the watch had no recovery port. If an update went wrong, there was no ordinary cable to plug in and rescue it.
Fernando tells the story with the astonishment of an engineer who remembers the room. His manager left him with the problem. The answer, he says, took years and many teams across Apple. It is a compact lesson in the difference between a beautiful object and the systems that let people trust it. A watch can look finished long before the hard work underneath is done.
That early assignment makes an oddly fitting prologue to Fernando’s present work. He spent 12 years at Apple, where product development was guarded and the result was usually all the public saw. Now he builds in the open. On YouTube and X he tries AI coding tools, develops apps, interviews builders and lets viewers watch the uncertain middle. The atmosphere is closer to a workshop with the door propped open than a polished product launch.
From the sealed room to the open tab
The move from Apple to independent work changed more than the size of his audience. At Apple, Fernando’s Watch update problem required coordination across groups that could devote years to making a small device behave reliably. Outside, he had to choose which problems deserved his own time and explain them to people who could leave a stream with one click. His website now collects founder conversations, practical tutorials and first-person accounts of what goes wrong when software leaves the editor.
His public experiments began with curiosity rather than a single grand thesis. In July 2024, he posted a sequence about building GPT-2 from scratch with Apple’s MLX framework. The entries start at Day 0 with setup and tokenization, then move through data and model concepts. That sequence matters because it leaves the learning curve visible. In a field fond of the finished demo, Fernando shows the steps between an unfamiliar tool and a working result.
He also made work people can take apart. His GitHub account includes an MLX video subtitling tool, a calculator for judging which quantized language models fit on a machine, starter material for a realtime voice agent, and skills for AI coding workflows. The collection is eclectic in a human way. A person tests a tool, meets a snag, writes a small helper, and publishes it. Each repository says as much about the question that bothered him as it does about the answer.
Then the customers called
There is a moment in Fernando’s public record that gives the phrase “build in public” its proper weight. In July 2025, he wrote that he had moved too quickly while using Claude Code and broken production. Three paying users contacted him. He remembered how long it had taken to find those first three customers; losing their confidence was no abstract product metric. The glamorous part of AI-assisted software development had met the oldest possible test: someone tried to use the app.
His response was concrete. He backed up the database and tagged the broken state before attempting a rollback. He made a test branch, returned the code to an earlier commit and checked the old version in a development environment. The difficulty did not end with the code. The database schema had moved on, so the earlier application needed to tolerate fields it had never expected. A rollback is not a time machine when the data keeps living in the present.
Fernando shared the embarrassment along with the remedy. That disclosure is part of his appeal as a teacher. He had been an experienced engineer before he reached for the new tools. He could still make a mistake. His practical advice after the incident was plain: keep recoverable versions, back up the data, make changes in smaller pieces and inspect the output. The lesson lands because it cost him something more immediate than a theoretical warning.
“An agent's answer is a claim until you check it.”
That line comes from a later essay, but it could serve as a caption for the rollback. The first result of a coding agent is a proposal. The next questions belong to the engineer: does this work in the actual app, with actual state, for the person who needs it? Fernando has made those questions a recurring subject of his writing and tools.
The bug hiding in yesterday’s browser
In 2026, Fernando described a different failure in Mokuhoe, his scheduling app for outrigger paddlers. A user abandoned an invitation flow, leaving an invite code in browser storage. When that person returned later to sign up normally, the old code could join them to the wrong group. The code in any one file might look reasonable. The mistake appeared only when a human journey crossed two sessions and carried yesterday’s state into today’s action.
That case helped motivate his open source Bug Review Board workflow. Instead of asking an agent merely to inspect a pull request, he asks it to read the intended behavior and operate the live app like a user. The agent plans scenarios, captures evidence, files reproducible bugs and gives a release verdict. The point is less theatrical than the name sounds. Someone must look at the entire experience, including the browser storage, mobile keyboard and authentication handoffs that source code alone can conceal.
The Apple connection is easy to see without pretending the two jobs are identical. His Watch assignment was about an update process that had to survive the absence of an easy rescue path. His current quality work asks what happens when a user arrives with a messy history that the developer did not put in the demo. Both situations reward the engineer who imagines the failed path before it becomes somebody else’s problem.
Claims, checks and another round
Fernando’s 2026 essay on WAVES extends that habit to teams of AI agents. The name expands to workers, aggregate, verify, extend. Give independent tasks to workers, collect what they return, check the evidence behind their claims, and run another round if the work calls for one. The method is published as a skill for coding agents. It treats fluent output with the courtesy due any untested report: read it, then see whether it holds.
He is an enthusiastic experimenter. The videos and posts range across coding environments, local models and developer tools. Yet the repeated instruction is to keep human judgment in the loop. A stream can show the speed of a generated feature; a customer can reveal its blind spot. Fernando’s public practice contains both scenes. The bright screen is interesting. The return to a broken screen is where the education begins.
His GitHub Sponsors page states an ambition to make AI development more accessible through open source work. His booking page speaks in the more immediate language of helping a builder ship an app and understand the codebase beneath it. Those are modest, testable aims. They also explain why he keeps publishing instructions instead of only describing outcomes. Someone else should be able to run the experiment, inspect the failure and improve the method.
The people around his work appear in interviews and streams: founders, engineers, fellow tool builders, and viewers who bring questions while the session is live. On the floor of the 2026 AI Engineer World’s Fair, he described walking among booths and talks with a camera, seeking the builders and the work behind the promises. That style suits his own career change. A meeting that once began under a black cloth has become a series of open tabs, public repositories and conversations with an audience.
The work after the reveal
There is a temptation to make Fernando’s story into a conversion tale: Apple engineer leaves secrecy behind and discovers the joy of openness. The facts are more interesting. He carries an Apple engineer’s concern for the failure path into a new setting where failures are visible, sometimes within minutes. He is learning the economics of a small product, the pace of AI tooling and the discipline of testing in front of people who can see the result.
The no-port Watch prototype was a problem hidden inside a polished object. The stale invite code was a problem hidden inside a normal signup. The production regression was hidden until three customers found it. Fernando’s answer has evolved, but its shape is recognizable: look for the part that can fail, build a way to find it, and show enough of the process that another person can do the same. A demo may end with applause. His most useful work begins when someone tries the button again tomorrow.