Coding Chats

Coding Chats Episode 80 - start-up advisor Alexander Berkovich shares his expertise on building successful start-ups, hiring strategies, CTO roles, and the importance of communication between technical and business teams. Discover practical tips for navigating the challenges of early-stage companies and how to align technical excellence with business goals.

Chapters
00:00 Introduction to Start-up Advising
02:09 The Day-to-Day of a Start-up Advisor
05:39 Hiring Challenges in Start-ups
07:39 Defining the Role of a CTO
10:36 Common Mistakes in CTO Hiring
12:59 Bridging the Gap: Technical and Business Communication
16:40 Utilizing Client Feedback for Product Improvement
20:06 Transitioning from Proof of Concept to Product
24:01 Exploring Computer Vision in AI
24:06 Balancing Technical Excellence and Business Focus
24:09 Exploring Related Content

Alex's Links:
Alex's LinkedIn: https://www.linkedin.com/in/alexander-berkovich-startup-advisor/

John's Links:
John's LinkedIn: https://www.linkedin.com/in/johncrickett/
John’s YouTube: https://www.youtube.com/@johncrickett
John's Twitter: https://x.com/johncrickett
John's Bluesky: https://bsky.app/profile/johncrickett.bsky.social

Check out John's software engineering related newsletters: Coding Challenges: https://codingchallenges.substack.com/ which shares real-world project ideas that you can use to level up your coding skills.

Developing Skills: https://read.developingskills.fyi/ covering everything from system design to soft skills, helping them progress their career from junior to staff+ or for those that want onto a management track.

Takeaways
A CTO's value is in leadership and strategy, not just how much they can code.AI has fundamentally changed the hiring process and what makes a good candidate.
Document every corner you cut in a POC — it will catch up with you later.
Engineers should seek direct client feedback to understand the real impact of their work.
Communication is the most underrated skill in any startup team.
A POC and a product are very different things — don't let one accidentally become the other.
Startups offer breadth of experience that large enterprises simply can't match.
Hiring for the right mindset matters more than hiring for pure technical skill.
Small technical decisions can ripple out and affect cost, timelines, and the whole product.
The best teams stay connected to the end goal, not just the task in front of them.

Coding Chats Episode 79 - Richmond Alake, Director of AI Developer Experience at Oracle, joins John to discuss agent memory — how AI agents store, retrieve, and adapt to information. He argues that developers building memory on flat files are naively reinventing the database, and that once you factor in concurrency, security, and scalability, a proper database is inevitable. The conversation covers the full memory stack and how Oracle's AI database keeps embeddings and data together without shipping sensitive information to external providers.

The pair also explore why memory is the most universally relatable concept in AI, the history of how neuroscience shaped LLMs, and the problem of Catastrophic Forgetting that still haunts models today. A sharp AGI debate lands on a sobering point: an LLM is just a function — tokens in, tokens out — and most AI engineers are unknowingly rediscovering solutions that database engineers spent decades building.

Chapters
00:00 — What Is Agent Memory and How Does It Work?
05:00 — File System vs Database: Which Should You Use for Agent Memory?
09:00 — Why Building on Files Means You'll Reinvent the Database
13:00 — How Oracle Is Meeting AI Developers Where They Are
15:00 — Why Memory Is the Most Universal Concept in AI
21:00 — From Computer Vision to LLMs: How Richmond Found His Path
24:00 — Catastrophic Forgetting: The Problem That Hasn't Gone Away
26:00 — Is AGI Real? Why the Goalposts Keep Moving
33:00 — Handling PII, Data Sovereignty, and Access Control in AI Apps
42:00 — The Rise of Memory Engineering: AI's Most Underrated Discipline

Richmond's Links:
LinkedIn: https://www.linkedin.com/in/richmondalake/
X: https://x.com/richmondalake

John's Links:
John's LinkedIn: https://www.linkedin.com/in/johncrickett/
John’s YouTube: https://www.youtube.com/@johncrickett
John's Twitter: https://x.com/johncrickett
John's Bluesky: https://bsky.app/profile/johncrickett.bsky.social

Check out John's software engineering related newsletters: Coding Challenges: https://codingchallenges.substack.com/ which shares real-world project ideas that you can use to level up your coding skills.

Developing Skills: https://read.developingskills.fyi/ covering everything from system design to soft skills, helping them progress their career from junior to staff+ or for those that want onto a management track.

Takeaways:
File systems are fine for prototyping, but the moment you hit production scale you're just slowly reinventing the database.
File systems are fine for prototyping, but the moment you hit production scale you're just slowly reinventing the database.
Agent memory isn't a new concept — it's data management, and database engineers have been solving it for decades.
Memory is the single most relatable entry point for explaining AI to anyone, technical or not.
Catastrophic Forgetting isn't a solved problem — it plagued RNNs and still quietly haunts LLMs today.
An LLM is ultimately just a function: tokens in, tokens out — which should temper any claims about sentience or AGI.
The definition of AGI keeps shifting to match whatever AI can't do yet, making the whole debate almost meaningless.
Most AI engineers have less than ten years of experience and are unknowingly rediscovering solutions that search and database engineers spent decades building.
"Vector search is all you need" is one of the most dangerous oversimplifications in AI engineering right now.
Memory engineering — the crossover between data engineering, search optimisation, and agent design — is an emerging discipline that doesn't have a name yet but absolutely should.
The real moat in AI products isn't the LLM itself, it's everything built around it — the harness, the memory, the retrieval pipeline.

Coding Chats Episode 78 - John Crickett talks to Robert Harris, an experienced engineering leader. Robert shares hard-won lessons from years of leading software teams, drawing on a distinctive "human systems" lens to explain why so many engineering organisations struggle — not because of bad people, but because of broken systems, misaligned leadership, and invisible cultural forces.

The conversation weaves together philosophy, practical management advice, and candid personal anecdotes, making it equally relevant for first-time engineering managers and seasoned CTOs. The central thread throughout is that software is fundamentally a human endeavour, and leaders who treat it like a purely technical one will keep running into the same problems.

Chapters
0:00 — Every Problem is a Systems Problem
3:00 — Labelling vs. Diagnosing: The Human Systems Approach
6:15 — Poor Performance Is a System Failure, Not a People Failure
9:10 — AI, Flat Orgs, and the Pressure on Engineering Managers
11:30 — Diagnosing a Broken Team: A Real-World Turnaround
24:05 — People Are Not Interchangeable Components
26:00 — Culture: What Happens When Nobody's Watching
33:00 — The Power Gradient and Cross-Team Collaboration
39:00 — The C-Suite Distance Problem
42:00 — Building Culture in Remote and Distributed Teams
46:00 — Software Engineering Is a Humanity

Robert's Links:
https://www.linkedin.com/in/robert-n-harris/coded2lead.com

John's Links:
John's LinkedIn: https://www.linkedin.com/in/johncrickett/
John’s YouTube: https://www.youtube.com/@johncrickett
John's Twitter: https://x.com/johncrickett
John's Bluesky: https://bsky.app/profile/johncrickett.bsky.social

Check out John's software engineering related newsletters: Coding Challenges: https://codingchallenges.substack.com/ which shares real-world project ideas that you can use to level up your coding skills.

Developing Skills: https://read.developingskills.fyi/ covering everything from system design to soft skills, helping them progress their career from junior to staff+ or for those that want onto a management track.

Takeaways
People run on emotion and safety, not logic — lead them accordingly.
When someone underperforms, look at the system before you look at the person.
Labelling people as "difficult" or "lazy" is a way of avoiding the real problem.
AI is accelerating code generation, but the human bottleneck downstream is getting worse, not better.
The institutional memory inside a team is worth far more than anything in your wiki.
Culture is what happens when nobody's watching — not what's written on the wall.
If you send Slack messages at 10pm, your team will think there's no such thing as work-life balance.
Only authorised people should authorise work — casual remarks from leaders land as commands.
Co-location without connection isn't culture, it's a terrarium.
Computers are a science, but software is a humanity.

Coding Chats Episode 77 — Arnaud Fournier, Forward Deployed Engineer at OpenAI, talks to John Crickett about how AI is fundamentally reshaping software engineering. He explores how OpenAI's own engineers have largely moved away from writing code line-by-line, shifting instead to what he calls "harness engineering" — orchestrating agents, preparing context, and steering AI to do the heavy lifting.

The conversation covers practical ground for engineers at every level: how to successfully adopt agentic coding in your workflow, best practices for integrating tools like Codex into enterprise environments, and what it's really like to work at the frontier of AI deployment across industries like semiconductors, life sciences, and finance.

Chapters
00:00 Understanding the Role of Forward Deployed Engineers
03:21 The Integration Process: Challenges and Solutions
06:25 Optimizing AI Solutions with Codex
09:38 Leveraging Codex for Team Efficiency
12:28 Best Practices for Using Codex in Engineering Workflows
15:29 Setting Up for Success in Enterprise AI Projects
18:26 Navigating Stakeholder Engagement and Requirements
21:16 The Future of AI in Enterprise Solutions
25:53 Building Proof of Concept Solutions
28:33 Collaborative Development and Model Improvement
30:45 The Rise of Codex and User Adoption
33:36 Integrating AI into Software Development
36:10 Standardization vs. Customization in AI Tools
39:05 The Evolving Role of Forward-Deployed Engineers
42:48 Understanding the FDE Role at OpenAI
46:10 The Recruitment Process at OpenAI
49:50 Exploring Related Content
49:58 Outro Final Coding Chats.mp4

Arnaud's Links
https://www.linkedin.com/in/arnaudfrn/
https://openai.com/index/introducing-openai-frontier/
https://community.openai.com/t/introducing-the-new-codex-for-almost-everything/1379125
https://openai.com/index/scaling-codex-to-enterprises-worldwide/

John's Links:
John's LinkedIn: https://www.linkedin.com/in/johncrickett/
John’s YouTube: https://www.youtube.com/@johncrickett
John's Twitter: https://x.com/johncrickett
John's Bluesky: https://bsky.app/profile/johncrickett.bsky.social

Check out John's software engineering related newsletters: Coding Challenges: https://codingchallenges.substack.com/ which shares real-world project ideas that you can use to level up your coding skills.

Developing Skills: https://read.developingskills.fyi/ covering everything from system design to soft skills, helping them progress their career from junior to staff+ or for those that want onto a management track.

Coding Chats episode 76 - John talks to Laura Dietz - a computer science professor whose work focuses on whether AI evaluation metrics actually tell the truth. She's known for her critical take on "LLM as a judge" — not because she thinks it's useless, but because she wants numbers that mean something rather than numbers that just make a system look good.

The conversation tackles some uncomfortable realities for software engineers: using an LLM to write code and another to review it is a circular trap, prompt engineering shouldn't be a computer scientist's day job, and every time you reject your code AI's output, you're quietly generating the training data that shapes its successor.

Chapters
00:00 Introduction to Laura Dietz and Her Journey
03:12 Exploring LLMs as Judges
06:16 Challenges in Evaluating Search Systems
08:49 The Evolution of User Queries and Expectations
11:46 The Role of LLMs in Information Retrieval
14:44 Defining Quality in Search Results
17:27 The Complexity of User Intent
19:54 Human-AI Collaboration in Code Review
22:53 The Future of LLMs in Software Development
25:23 Balancing Human and AI Roles
28:20 Innovative Approaches to AI Evaluation
34:10 The Art of Assembling Ideas
36:39 Balancing Cost and Quality in LLMs
39:09 Evaluating LLM Performance
43:50 The Future of LLMs and Training Data
49:19 Exploring New Architectures in AI
55:16 Understanding In-Context Learning
01:00:45 The Role of AI in Creative Expression
01:06:59 Exploring Related Content

Laura's Links:
https://www.cs.unh.edu/~dietz/https://
www.linkedin.com/in/laura-dietz-47036516/
John's Links:
John's LinkedIn: https://www.linkedin.com/in/johncrickett/
John’s YouTube: https://www.youtube.com/@johncrickett
John's Twitter: https://x.com/johncrickett
John's Bluesky: https://bsky.app/profile/johncrickett.bsky.social

Check out John's software engineering related newsletters: Coding Challenges: https://codingchallenges.substack.com/ which shares real-world project ideas that you can use to level up your coding skills.

Developing Skills: https://read.developingskills.fyi/ covering everything from system design to soft skills, helping them progress their career from junior to staff+ or for those that want onto a management track.

Takeaways
Using an LLM to both generate and evaluate outputs is circular — like a student grading their own homework.
If your evaluation metric can go up without your system actually improving, it's not a real metric.
A better human-in-the-loop isn't one that rubber-stamps AI suggestions — it's one that's guided to look in the right place.
LLMs don't get bored, which makes them genuinely useful for code review — but that's not the same as making them accurate.
"Faith-based engineering" — trusting AI output without validation — is a real and growing problem in software teams.
Prompt engineering is a workaround, not a discipline; real engineers should be building systems, not crafting incantations.
Every rejection you give your code AI is training signal — your frustration today is someone else's better tool tomorrow.
The transformer attention mechanism is a weighted sum, and a sum isn't always the right operation — some problems need an AND, not an OR.
AI tools are lowering the barrier to coding for people who were previously too intimidated to try, and that's worth celebrating.
The same network effect that makes a platform valuable also makes monopoly in AI training data genuinely dangerous.