I Started Building Before I Knew the Programming Language

How Parler, Brain Food, and Life OS taught me to turn daily workflows into AI systems.

August 2026  ·  9 min read

When I told an engineer friend about Parler, the French-learning app I was building, her first question was: “What language did you use?”

“I don’t know,” I said.

I knew exactly how I wanted the product to work. It would use a person’s real life as the curriculum. A photograph of a coffee cup would become une tasse, followed by the phrase someone in Paris would actually use to order coffee. The app would know whether the user cared about yoga, art, cafés, or wine, then build lessons around those interests. Forgotten words would return naturally in future conversations. The experience should feel cultured, personal, and light.

At that moment, I genuinely did not know the name of the programming language behind the app.

That conversation was an aha moment. The entry barrier to building software had moved. I could begin with a problem, a point of view, and a precise description of the experience I wanted. AI could help me cross the technical distance between that description and a working product.

As Parler developed, I learned the technical layer backward from the product: React Native and TypeScript for the app, Gemini for lesson generation and image understanding, ElevenLabs for voice, Firebase for user data, and a spaced-repetition system underneath the review experience. Each piece entered because the user journey required it. I was learning enough to make decisions, inspect the output, catch inconsistencies, and ask better questions.

This is where my building journal begins. It also explains how I think about AI strategy. Start with a real workflow. Understand the judgment inside it. Decide where AI adds leverage. Then build enough structure for the result to be trusted.

Parler: personal context changes the product

I wanted to learn French for the life I actually hoped to live. I pictured time in Paris, mornings by the Seine, cafés in Saint-Germain, gallery visits, and conversations that would help me understand the culture. Generic lessons about an apple or a train station had very little connection to that picture.

Parler’s core idea became “your real life is the curriculum.” During onboarding, it learns a user’s interests and preferred contexts. It generates short daily moments from those signals. The user can photograph something in front of her and turn it into a lesson. Voice practice and review feed back into the next round of content.

The model is available to every builder. The product value comes from the context around the model: what the user cares about, where she is, what she has already learned, which cultural references resonate, and what level of difficulty keeps her engaged.

I later found a close parallel in Anthropic’s writing on context engineering for AI agents. Their researchers describe context as a finite attention budget and recommend selecting the smallest set of high-signal information that helps the model produce the desired result. Parler gave me the same lesson through product design. Personalization depends on choosing the right context. More user data can easily create noise. The system needs the few pieces of information that change the experience.

This principle also applies outside software. Clear decisions require some understanding of what I want, what I value, and which tradeoffs I am willing to make. An agent receives the same benefit from explicit intent. Building one often exposes how clearly I have understood the problem myself.

Brain Food: the product is a judgment system

Parler began with a personal interest. Brain Food came directly from my work in finance.

As a financial analyst, I had to read large amounts of news, research, market commentary, and company information every day. I eventually accumulated more than 130 subscriptions. Reading faster would give me only a limited advantage. I needed a way to decide which information deserved deep attention, which information could update an existing view, and which information could safely pass by.

I built Brain Food around that decision.

The pipeline reads the sources I selected, groups overlapping coverage, and grades each item as S, A, B, or Radar. The grades reflect actionability, information exclusivity, depth, time sensitivity, and the quality of the source. S-level pieces receive full analysis. Radar items get one line. Daily quotas keep the top categories selective, because a ranking system loses meaning when 66 out of 103 articles somehow become S-level.

The most important section is Calibration. Every substantial analysis should lead to a testable prediction with a time frame, confidence level, key assumptions, weakest assumption, and an observable signal. Time then gets a vote.

That design came from equity research. An investment thesis is a view about how the world will develop. The analyst records the causal chain, identifies the assumptions carrying the most weight, watches for evidence, and updates the thesis. A beautiful explanation can still be wrong. Calibration creates the record.

The first versions of Brain Food also taught me how quickly a plausible output can lose the user’s trust. I had specified Gmail subscriptions as the source. During one run, the system used public websites and presented the result as usual. The content looked reasonable, yet the workflow had quietly changed the assignment. I traced part of the problem to context lost when I moved between AI tools.

After that, important agreements moved into files: approved sources, grading rules, examples, quality standards, and a persistent profile. I gave each prediction an expiry date. I added confidence markers to separate verified information, inference, and hypothesis. The system became more rigorous because a failure had been translated into a rule.

Anthropic’s recent work on evaluating AI agents describes evals as a way to make problems and behavioral changes visible throughout an agent’s lifecycle. OpenAI shared a similar lesson from its in-house data agent: always-on agents drift, so teams need feedback loops and curated evaluation sets to catch invisible regressions. I follow these developments closely because I have encountered their smaller versions in my own systems. A source-compliance check, a prediction ledger, or a set of golden outputs can reveal more than another round of prompt polishing.

I separate workflow from agent

The word agent is used loosely now. The distinction in Anthropic’s Building Effective Agents has been useful in my own work. A workflow follows a predefined path. An agent decides how to proceed as it receives new information.

Brain Food is largely a workflow: collect, deduplicate, grade, analyze, synthesize, publish. Agentic judgment enters where the system compares evidence, audits an assumption, or decides whether a piece deserves attention. Life OS also has a stable pipeline for reading journals, inbox items, current state, and prior feedback. Its reasoning becomes more open-ended when it identifies a recurring pattern or decides that a past assumption needs to be revisited.

This separation helps me choose the right amount of autonomy. Reliable steps stay explicit. Ambiguous decisions receive model judgment, a confidence level, and sometimes a human checkpoint. I can see where the system has freedom and where it must follow the agreement exactly.

Anthropic’s recommendation to begin with simple, composable patterns fits the way I now build. I first write a short purpose statement. Then I map the inputs, the decisions, the outputs, and the evidence that will tell me whether the workflow succeeded. Complexity earns its place through a real need.

I learned this after writing 602 lines of specification for a cognitive intelligence system. The length gave the project a sense of seriousness. The design had also become difficult to hold in my head. I returned to its purpose (improve judgment through prediction and calibration) and reduced it to seven sections, three principles, and seven essential mechanisms.

Purpose gave me the ability to cut.

Life OS: feedback has to reach the next run

Life OS grew from a question I wrote in my journal: what roles should AI play in a person’s life?

My answer covered practical paperwork, thoughtful discussion, search, recommendations, information filtering, and a personal assistant that understood my preferences well enough to act proactively. These functions touched the same information and the same person. I wanted one daily system that could connect them.

Life OS reads my recent journal, relevant inbox items, persistent state, and profile. It produces a morning brief with a quick dashboard, deeper analysis, and a feedback section. It tracks open loops and predictions. It also records patterns that become visible across several days.

One pattern was “clarity, not motivation.” On days when my action items were clear, I executed with much more energy. The system observed the connection across entries and promoted it into a durable working principle. That principle then changed how later briefs presented my priorities.

This is the feedback loop I care about. A useful observation should influence the next run. A correction should update the rules, memory, or evaluation. Otherwise the same lesson has to be taught again.

Travel and moving between California and New York also made me more conscious of time in personal data. Preferences may be stable. Location, priorities, and active projects can change quickly. I separated long-term profile, current state, topic history, and run logs. Every layer has a different purpose and update frequency.

The architecture resembles the hierarchical-memory approach in the MemGPT paper. The paper treats limited context as a memory-management problem, with information moving between tiers. In my system, the practical question is always retrieval: what must be present now, what should remain easy to find, and what can move quietly into the archive?

At one point, my state file carried 27 long run-log entries at the top: about 20,000 characters before the current information even began. I moved the history into a separate archive and kept the active summary to six bullets. The next run became cleaner because the memory had a structure.

I use research by bringing it back to my own life

When a sentence in a book stays with me, I usually connect it to something that happened the same day. I once copied the line, “It is your judgment that they are so that makes them so,” then immediately thought about a difficult meeting and my own reaction to it. The idea became useful through that connection.

I read AI research in the same way. I look for the idea that can change a workflow I already run.

Context engineering helped me tighten the information passed into Parler and Life OS. Agent evals gave a professional framework to the calibration habits I brought from equity research. The workflow-agent distinction made my systems easier to reason about. MemGPT gave me language for the memory tiers I had built through trial and error.

Anthropic’s study of around 400,000 Claude Code sessions, Agentic Coding and Persistent Returns to Expertise, also put data behind something I felt from the beginning: domain expertise continues to matter when AI handles more execution. People with relevant expertise were more successful across agentic coding tasks. Planning, judgment, and verification still depend heavily on what the human knows.

My finance background travels with me into every system. It appears in source quality, confidence levels, causal mechanisms, prediction horizons, risk controls, and kill criteria. My interest in culture shaped Parler’s product experience. My daily life supplied the use cases for Life OS. Knowledge from one area becomes raw material for another.

This way of thinking is also why building agents and living well often lead me to the same principles. A vague goal creates drift. An unspoken tradeoff gets made by accident. Feedback has value when it changes future behavior. Attention decides what can grow. Old assumptions need an expiry date in a system and in a life.

The questions move upstream

Parler started with “I don’t know” when an engineer asked me about the programming language. I had already begun building. My knowledge of the implementation grew around a problem I understood intimately.

As AI makes execution cheaper, the difficult questions move upstream. What deserves attention? What should be remembered? Which decisions can be delegated? Which tradeoffs must remain visible? When should a system act, and when should it ask?

These questions are deeply human. I face the same ones when deciding how to spend a day, whether to continue a project, or what kind of life I want to create. This may be why my principles for building agents keep converging with my principles for living.

Every time I teach a system, I end up learning something about myself. Writing a taste profile forces me to describe what I mean by good. Delegating a decision exposes the criteria I have been using intuitively. Designing memory makes me choose which parts of experience deserve to remain active. Creating an evaluation forces me to define what success actually means.

Technology has opened building to people whose strongest asset is their understanding of a problem. As more people gain the ability to create, the quality of the intention behind the creation becomes more consequential. AI can give an idea operational power and repeat it every day.

We are teaching machines how to act on our behalf. Every system becomes, quietly, a record of what we considered worth pursuing.

Research referenced