Lars Faye argues the industry is sending contradictory signals about agentic coding: one camp says coding is solved and you can be vague with prompts, while anyone who gets bad results is told it's a skill issue. His counterpoint is that the elaborate specs, verification loops, and pipelines needed to make agents work well are themselves proof that deep domain expertise still matters — which contradicts the 'coding is solved' claim. He positions himself as a delegator rather than a full agentic workflow adopter, still reading and writing code because that's how he figures out what to build.

• The 'coding is solved' narrative claims models handle ambiguous requests, search the codebase, consult docs, and commit changes with little developer involvement — and he admits he's had isolated experiences like that.
• When developers report poor results, the standard responses are 'skill issue,' spend more tokens, stop reading the code, wrong model, wrong pipeline.
• His central argument: building the robust architecture, detailed specifications, and verification loops that make agents work requires enormous domain expertise and architectural judgment, so the work hasn't been eliminated, just moved.
• The 'software factory' promise looks like a mirage because software involves innumerable decisions whether you're hand-coding or designing an automation pipeline.
• The dismissive 'you're holding it wrong' reflex feels like gaslighting because the reality of agentic workflows is more nuanced than the hype allows.
• Not enough time has passed to know whether people who've stopped reading their code entirely will be fine long-term, so he's deliberately apprehensive about going that far.
• He frames his goal as doing better rather than going faster, and wants to become more of a domain expert, not trade expertise for speed.
• He cites Addy Osmani — recently joined Anthropic after ~15 years at Google — as someone who embraces AI coding but advocates staying close to the work in small chunks, since expertise comes from friction with the code.
• He expects neither fully autonomous dark software factories nor a bubble pop returning everyone to hand-coding; he's been typing less for years via autocomplete, snippets, and generators, and sees AI as a continuation of that.

It's not a skill issue — it's the expertise paradox 1:23–2:28

This is the core argument: the setup required to make agents work well is itself proof that domain expertise hasn't been eliminated.

I'm here to convince you today that this is in fact not a skill issue. You need a really robust kind of architecture and pipeline configured if you want to get really good results out of these models. And to me that is very different than 'coding is solved.'

AI as a delegation layer, not an autopilot 5:05–6:10

He offers a concrete alternative posture to full agentic workflows, plus the reason he keeps typing code — writing types and functions is how he figures out what to build.

I like to look at these tools as a delegation layer that kind of intersects at every part of the stack... I like to call it my ship's computer that I can just kind of call up anytime I want, assign something, and then I go back to work.

I'm not really interested in going faster. I'm interested in doing better.

Me typing out code is the process by which I'm figuring out what we should even be doing.

Just integrate them at whatever level brings more joy to your work.

Cole Medin walks through how he's evolving his personal AI second brain into a shared "team brain." The key architectural decision: keep the personal agent (personality, custom memory, interface) on each individual's machine, and centralize only the knowledge base in a database that every agent queries through a single MCP server. The rest of the video covers how to normalize every source into one documents table, label documents by domain at ingestion, enforce row-level permissions in the database using tokens, and use hybrid keyword + semantic search for retrieval. The demo is built on the Oracle AI database (a disclosed partnership) with LangChain, but he stresses the strategies apply regardless of tooling.

• Don't scrap your personal second brain — the team brain is just the shared knowledge base; the personal agent stays distributed so each person keeps their own customization and memory, while policy and knowledge get centralized.
• An Obsidian vault of Markdown files no longer works at team scale; you need a central database as the single source of truth for retrieval and permissions, accessed by each personal agent via an MCP server.
• Everything from every source — Slack threads, GitHub repos, documentation — is normalized into one 'documents' table with a shared schema (title, text, URL, author, domains, metadata) so querying stays simple.
• Each connector's only job is to fetch from its source and mold the data into that standard document format, giving all personal brains a single entry point.
• Permissioning starts at ingestion: sources are mapped to domain labels (marketing, ops, etc.), and documents can carry multiple labels for shared spaces; an MCP tokens table and a principals table map each user's token to the domains they can see.
• The security gate must live in the database, not the personal agent — otherwise a user can get around it with prompt injection or by editing their own agent's code.
• At scale, keyword search alone isn't enough: combining keyword search (exact wording, IDs) with semantic search (concepts, meaning) and weighting the results narrows tens of thousands of records down to the few snippets the agent needs, with source citations for verification.
• A 'who knows' MCP tool uses the author field on records to tell you which colleague to ask when the knowledge base doesn't cover something you can access.
• He claims the personal version of this system saved him roughly 20 hours per week when he last measured it a few months ago.

Put the security gate in the database, not the agent 9:48–10:40

The single clearest design rule in the video, and the one most people building local-first agent systems get wrong.

The most important takeaway here, no matter how you build this system, is you need the gate to sit in the database. You cannot have this second brain, the personal part of the system, responsible for the security in any way cuz then it's going to be way too easy for the individual to get around it with prompt injection to their own agent or just changing their own agent's implementation.

Same question, two users, two different answers 11:25–12:30

A concrete live demo showing row-level permissions actually working end to end from a Claude Code session.

If I ask that question with Jeff, it says the knowledge base doesn't cover anything around the enterprise discount ceiling. So the information is completely invisible as it should be cuz we can't access it. But if I ask the same question as Sam, this is where we get that up to 20% off list price.

The last time I actually measured it, it saved me about 20 hours per week.

You need the gate to sit in the database.

We can't just do a Karpathy LLM wiki with just keyword search anymore.

Ray Amjad walks through Jev, a new "System 1" model from TypeSafeAI that doesn't generate text at all \u2014 you give it a prompt, some data, and a fixed set of answers, and it returns probabilities in roughly 100ms for a fraction of a cent. He explains its three primitives (bool, score, choice), shows it playing Minecraft under GPT-5.6's strategic direction, then argues the real payoff is pairing it with slow agents like Claude Code: cheap screening across a whole codebase, with only the high-probability hits escalated to an expensive model. Demos include analyzing 150 code comments in 9.3 seconds for about a cent, and a full-codebase code-smell pass estimated at 28 million input tokens for $1.19.

• Jev takes a prompt plus data plus a set of answers you define, and returns probability scores rather than generated text \u2014 effectively a very smart switch statement you can wire into if-statements.
• Three primitives: bool (how true something is), score (a rubric spectrum, max 11 levels so 0\u201310), and choice (multiple choice, up to 255 options); responses typically land in 100\u2013300ms and repeat within 2\u20133% variance.
• The framing is Thinking Fast and Slow: Jev is a System 1 model that can run continuously in the background, while Claude and GPT models are System 2 \u2014 and the interesting architecture is a loop where System 2 reviews System 1's decisions and rewrites its criteria, thresholds and examples.
• A live demo has Jev playing Minecraft moment-to-moment while GPT-5.6 sets strategy and reviews after setbacks; over the course of the video it builds a shelter, gets a diamond pickaxe and reaches the Nether.
• The Jev cookbook reports it can route among 182 installed skills, cutting wrong-skill loads from 17% to 7.3% with Haiku 4.5 \u2014 which would also let you pull ~10,000 tokens of skill descriptions out of the context window.
• A skill-driven demo analyzed 150 code comments in 9.3 seconds for about one cent, projecting 57 cents to grade every comment in the codebase and a shortlist of roughly 1,700 worth rewriting; a code-smell pass was quoted at 28 million input tokens for $1.19.
• Proposed use cases: qualitative linters (\"does this function name describe its side effects?\", \"is this log line leaking a secret or PII?\"), massively parallel adversarial browser testing per PR for pennies, and a Jev-based code reviewer that cuts what a System 2 agent has to read by ~10x.
• An engineer at Sentry reported Jev running one of their security pipelines over 5x cheaper and faster than the small LLMs they already used, with accuracy maintained \u2014 beating models like GPT-OSS 120B on their comparison.

Chaining System 1 and System 2 into a self-tuning loop 8:05–9:19

This is the core architectural idea of the video \u2014 not Jev alone, but a fast classifier whose rules a slow model continuously rewrites.

If we started recording all the decisions that we made and the outcome as well, we could then set up a regular process where a System 2 model would be thinking about, hey, what is the strategy we're doing here? Can we improve it? And then it would rewrite any of the criteria, the examples, or the threshold for us.

150 comments in 9.3 seconds for a cent 18:25–19:34

A concrete, measured cost and latency result that makes the whole-codebase screening argument tangible.

We managed to do 150 comments in 9.3 seconds for about 1 cent. And it said that it can analyze all the comments in the codebase for about 57 cents. And it expects the shortlist to be about 1,700 comments that would need to be rewritten.

One way of thinking about it is that Jev does not generate any text \u2014 you can imagine it as a really smart switch statement.

You will find that your limiting cost is no longer your tokens, because your tokens have become really cheap, and instead your compute.

Imagine a really fast gut-check review from 100 or 1,000 different angles of any PR that you have.