2025 A Vibe Coding Odyssey

Building at the Speed of Thought

by

On building QuietReads, Claude Code, and the inversion in software economics

I have wanted to build QuietReads for two decades.

The idea is simple: a book tracking application that treats reading as a reflective practice rather than a social performance. Just you, your books, and an AI companion that remembers what you’ve read and can discuss it with you.

Every few years, I would sketch out the features, maybe prototype a database schema, and then abandon the project when the scope overwhelmed the time I could spare. The economics never worked. Building a full-stack application with authentication, third-party integrations, and a sophisticated AI layer would take months of focused effort. I had a day job. I had a family. QuietReads stayed in the drawer.

Then came Thanksgiving 2025. Anthropic rolled out $1000 in API credits for Max subscribers to use with Claude Code, their agentic coding tool. The Opus 4.5 model had just launched. I decided to try again.

Two weeks later, QuietReads was live.

QuietReads organizes books in a Library View

What Changed?

This wasn’t my first attempt at building QuietReads with AI tools. Last summer, I tried vibe-coding the same application using Replit, Cursor, and an early version of Claude Code running Sonnet 4. The results were miserable. The AI agents went off the rails constantly, making changes I didn’t ask for, getting stuck in loops, producing code that looked plausible but broke in subtle ways. I gave up after burning through credits and several frustrating weekends.

The difference with Opus 4.5 was stark. 

Where Sonnet 4 required constant hand-holding, Opus 4.5 understood what I was trying to build. It made architectural decisions that made sense. When I pointed it at a bug, it found the root cause rather than applying band-aids. It demonstrated genuine systems thinking: analyzing trade-offs, proposing multiple approaches with honest assessments of pros and cons, thinking through downstream implications.

Claude Code making suggestions on how to refactor the AI Assistant to make tool calling more consistent

The screenshot above shows Claude Code reasoning through three different implementation approaches for a feature, weighing simplicity against performance against pattern consistency. This is a discussion I would expect to have with a senior developer. The options made sense, and I was able to make an informed decision on how I wanted to structure a key component of the application.

I shipped a full-stack, mobile-responsive application with social login, Google Books integration, and an AI reading companion that maintains persistent memory of your reading history. The companion can engage in literary discussion, reference your previous notes, and connect themes across books you’ve read months apart. You can @mention it in any note or journal entry, and it responds with context. Everything flows into a unified timeline that weaves together notes, reading sessions, and AI conversations.

Eko, QuietReads’s default AI Assistant helps me understand Neil Postman’s work. Books in AI responses are interactive components, allowing me to add them straight to the library.

The Inversion

My experience with QuietReads is a small data point in a larger pattern. We are navigating an inversion in how software gets built.

For decades, every decision about software development has been constrained by the scarcity of labor. Whether to buy or build. Whether to refactor legacy code or start fresh. Whether to ship now or wait for more resources. 

The person has always been the limiting factor, the most expensive line item, the ever-present bottleneck. 

The language of our industry reflects this: we estimate in person-days, bill in person-hours, staff projects in person-months.

That bottleneck is fading faster than I expected.

Boris Cherny, the creator of Claude Code at Anthropic, recently revealed that he didn’t open an IDE for an entire month. Every line of code he shipped during that period (259 pull requests, 497 commits, 40,000 lines added, 38,000 removed) was written entirely by Claude Code powered by Opus 4.5.

“Software engineering is radically changing,” Cherny wrote, “and the hardest part even for early adopters and practitioners like us is to continue to re-adjust our expectations.”

I am not Boris Cherny. I don’t work at Anthropic. I don’t have access to internal builds or institutional knowledge. But my experience over the holidays rhymes with his. And I’m not alone. Developers across the industry spent the holiday break shipping projects that had languished for years, finally made tractable by the combination of Opus 4.5 and Claude Code’s improved agentic capabilities.

Lots of people had “Claude Code” moments over the holidays..

So What Does This Mean for People Like Us?

In March 2025, Anthropic CEO Dario Amodei told the Council on Foreign Relations that he expected AI to be writing 90% of code within three to six months, and essentially all code within twelve months. The industry-wide numbers haven’t hit those marks. But within certain teams and workflows, his timeline looks prescient. Cherny’s experience is evidence. So is mine.

Software engineering as we know it is going to change faster than many of us imagined. The fundamental assumptions that drive economic decisions around building software (hiring models, training investments, vendor selection, build-versus-buy calculations) will all need revisiting. The implications extend beyond individual productivity gains into questions about how power accrues to capital and compute, and what happens to labor markets when a significant category of knowledge work becomes dramatically cheaper to produce (See footnote).

Remember: the models you’re using today are the worst they will ever be.

A User Base of One

On a more personal note: I’ve enjoyed using QuietReads. It is very much an application I built for myself, though perhaps you might enjoy it too (sign up here – let me know what you think). I have a backlog of features I want to add (voice notes, OCR for capturing physical book passages, maybe a Kindle integration to sync highlights) and I’m confident I can build them quickly.

I look forward to building more applications. Maybe something to help train my recalcitrant hound dog to stop stealing food. Maybe something to help my daughters learn Gujarati.

What I know for certain is that my view of how software gets built has shifted faster than I expected. Coming to terms with the pace of improvement has required repeated recalibration.

I am equal parts excited and terrified about what comes next.

Footnote:

There has been a lot of discussion about the macro-economic implications of broad AI adoption. From Dwarkesh Patel and Philip Trammell talking about Capital in the 22nd Century, to many, many posts that swing from breathless excitement to abject terror. Maybe we may even see an acute version of Baumol’s cost disease – where a significant bump in software productivity drives up costs and inflation as lower productivity sectors raise wages to compete leading to a hyper-inflationary spiral? Or perhaps Jevon’s paradox will reign supreme and we will end up with an absolute explosion of software tools. 

2025: The Year I Became A Cyborg

by

In chemistry, activation energy is the minimum energy required to start a reaction. It’s the barrier between potential and action, between “I could” and “I did.”

This year, AI collapsed that barrier for me.

As foundation models became better, and the tools built on top of them became more useful, the gap between having an idea and acting on it shrank to almost nothing. And for someone whose natural disposition is to try things, to experiment, to see what happens, this has been transformative. I have embraced using AI for work and play and for much else. 

Image generated using Gemini Pro

From Thought to Artifact

I’ve written more consistently this year than ever before. 

For many years, I used to maintain a list of ideas that I wanted to explore. Bookmarked sites, academic papers, and spicy social media takes. These ideas often were just abandoned or ignored until I forgot why I wrote them down in the first place.

Now, the time between having an idea, doing the research, writing an outline and then publishing it online has shrunk significantly because of AI. I use skills, deep research agents, and a set of prompts that have let me express myself faster and more coherently than ever before. 

My recent post “The Same Window For Everything” exists because I noticed something interesting while reading Kiran Desai, opened Claude to think it through, and found myself with the skeleton of an essay. A year ago, that observation might have stayed in my head, filed away with all the other thoughts that never quite made it to the page.

There’s a passion project I’ve been building, a reading companion I’ll be launching soon. It exists because, in 2025, the distance from “what if I built this?” to “let me try” became trivially small. Just like my writing ideas, I have a huge list of side projects and experiments that I wanted to try but never got off the ground. This year, I did.

But, it’s not all serious stuff! I vibe-coded (built quickly with AI assistance) a tool to help me journal regularly. I use AI to help plan dinner for my kids. I have setup my phone so it launches ChatGPT in “search mode” at the press of a button. And, I ask it all kinds of questions! From dealing with my dog’s flatulence to figuring out why the minivan doors won’t open. I now look up things where before I would have just shrugged and moved on.

I have a different relationship now with making things; one where the cost of trying something has dropped low enough that I actually try it.

The Professional Stakes

Looking up recipes for spaghetti carbonara is all well and good, but AI has had a significant impact on my work as well. 

At Jeavio, we’ve taken on more ambitious, outcome-oriented projects. Internal initiatives I sponsor, like our campus programs, have become more ambitious and aggressive because I believe we can get them done. That belief comes from now having enough experience with using AI tools to be confident on what my teams can and should be able to deliver.

We ran a company-wide hackathon late last year and a product-focused one in 2025. The hackathons shifted how Jeavio thinks about and uses AI tooling. They encouraged experimentation and built collective confidence about what capabilities these tools could unlock.

It’s not all fun and cheap inference though. Some projects have been challenging. We’re working at the frontier of what’s possible, and frontiers can be uncomfortable places. 

But my risk appetite has increased. I understand the tools better now. I know what Cursor and Claude Code can do and, equally important, where they fall short. I have a clearer understanding of what guardrails should be in place and how to evaluate the performance of inherently probabilistic systems. That understanding translates into confidence: confidence to take on projects with ambiguity, and confidence to deliver clearer projects faster and more predictably.

The throughline is the same as the personal examples: lower activation energy. Faster exploration, quicker iteration, more willingness to try things that might not work than ever before. For my work at Jeavio, this is an energizing change. 

Cyborgs and Foxes

Two frameworks have helped me make sense of what’s changed.

Ethan Mollick, in his research on AI and knowledge work, distinguishes between Centaurs and Cyborgs. Centaurs maintain a clear division of labor between human and machine, handing off discrete tasks to AI. Cyborgs blend the two. As Mollick puts it:

“Cyborgs don’t just delegate tasks; they intertwine their efforts with AI, moving back and forth over the jagged frontier.”

I’ve become a Cyborg.

AI is woven into how I think, write, and build. When I’m reading and want to explore an idea, I open Claude. When I’m coding and hit a wall, I think through the problem with an AI collaborator. The boundaries between what is truly my work and what is AI-mediated have become somewhat meaningless.

The second framework comes from David Epstein’s book Range: Why Generalists Triumph in a Specialized World. Drawing on Isaiah Berlin’s famous distinction and Philip Tetlock’s research on forecasting, Epstein contrasts hedgehogs, who know one big thing deeply, with foxes, who know many things and integrate broadly. 

Hedgehogs thrive in stable, rule-bound environments. Foxes thrive in ambiguous, rapidly-changing ones. As Epstein writes:

“Foxes see complexity in what others mistake for simple cause and effect. They understand that most cause-and-effect relationships are probabilistic, not deterministic.”

I’ve always been a fox.

Broad curiosity, comfort with ambiguity, a tendency to wander across domains. But being a fox is expensive and risky. Every new domain requires starting from scratch. The activation energy to explore something unfamiliar is high.

AI subsidizes that cost. Becoming a Cyborg helps make my fox-like tendencies viable in ways they weren’t before. I can move into an unfamiliar domain, quickly get oriented, experiment, and learn, all without the friction that used to make such exploration feel indulgent.

These frameworks work on orthogonal dimensions. Cyborg describes how I work. Fox describes who I am. Becoming a Cyborg made me more comfortable leaning into my fox-ness.

Looking Forward

I’m aware this could sound like boosterism. The AI discourse is full of inflated predictions and productivity theater.

So here’s what 2025 has taught me. Becoming a Cyborg works for me. This may not always be true.

Maybe I am just a frog slowly boiling to irrelevance as AI takes away my agency and creativity. 

Maybe the AI bubble might burst, and Anthropic and OpenAI will raise prices making vibe-coding a passion project or having a long conversations about literary fiction non-viable.

But until then: the distance between curiosity and creation has collapsed. I intend to exploit that gap.

More experiments. More wacky things. More small wins and instructive failures. The activation energy is low, and I have a lot of ideas. Bring on 2026.

Prompting Is All You Need

by

Agents are supposed to be the future of how we build AI software. I am not so sure.

Prompts, Agents, and Workflows

First, there’s a terminology clarification worth making upfront. What many in the industry call “agents” are actually what Anthropic more precisely defines as “workflows” – predetermined chains of LLM calls orchestrated through fixed code paths.

True agents, by contrast, are autonomous systems that dynamically direct their own processes and tool usage.

Most of what we see deployed today are workflows: decomposing complex tasks into a hierarchy of specialized LLM calls, with routing layers orchestrating the interactions.

In a Workflow, each step maintains its own context, can call specific tools, and handles a narrow slice of the overall problem. These multi-step workflows are powerful abstractions, but they’re not the only way to build sophisticated AI behaviors.

A typical Workflow (from Anthropic)

True autonomous agents? They’re even further from what most applications actually need.

The Hidden Costs of Multi-Step Workflows

LLM workflows come with significant disadvantages that often get glossed over in the excitement of building AI Applications:

Errors compound. Each step in the workflow chain is non-deterministic. When you chain multiple LLM calls together, minor errors or unexpected outputs cascade through the system. You need evaluation frameworks for each step AND the entire workflow.

Latency adds up. Every workflow step means another round trip to an LLM. A simple request that spans three steps results in three sequential API calls, each with its own network and processing time.

Costs pile up. Multiple workflow steps mean multiple API calls, each processing similar context. This could result in significant API costs as the number of tokens goes up.

Predictability suffers. Debugging why a workflow produced a particular output requires tracing through multiple decision points, each with its own probabilistic behavior.

I had to make decisions around which concerns belong together and which should remain separate. I ended up with two LLM calls – the Guardrails Layer and the Main Layer.

The Guardrails Layer operates as a lightweight, independent LLM call. Content safety is a fundamentally different concern from the companion’s behavior. It requires different evaluation criteria, different error handling, and potentially a different model optimized for classification.

The Main Prompt combines three complementary, but separate, layers:

  • Personality Layer: Defines the AI assistant’s identity and communication style (here is the default personality)
  • Context Layer: Determines which user information may be relevant to the current prompt. For example, what books they are currently reading, previous messages in a conversation, etc.
  • Directives Layer: Tool-use and output-formatting instructions for the prompt. I use a configuration-driven approach that lets you add multiple directives to a single prompt. You can think of Directives as sub-layers that drive the behavior and output of the prompt.
Building a comprehensive system prompt

These three layers share a coherent purpose – they all contribute to HOW the AI companion responds. They get composed programmatically into a single system prompt.

This approach means just two LLM calls instead of a chain of four or five workflow steps. More importantly, each call has a clear, singular purpose.

With prompt caching, this architecture becomes incredibly efficient. That comprehensive system prompt costs almost nothing after the first request, and the lightweight guardrails check is minimal overhead.

What about Prompt Engineering?

A lot of prompt engineering thinking is stuck in 2023, when tokens were expensive, context windows were small (4K-8K), and models were less capable.

But look at what’s available in November 2025: Haiku 4.5 is a fast, cheap model with phenomenal capabilities. It handles tool use, follows complex instructions, and, with prompt caching, makes repeated calls incredibly efficient.

By combining software engineering principles with modern LLM capabilities, the approach I am taking offers:

  • Reduced latency: One LLM call instead of multiple calls
  • Lower costs: Reduced total number of tokens with prompt caching
  • Extensibility: I can swap out the Agent Personality, or layer directives, or change the way I build the context
  • Fewer errors (in aggregate): Just two prompts in the chain, with the Guardrails prompt being fairly deterministic

Where Workflows and Agents Fit In

Let me be clear about what I’m arguing against and what I’m not.

Workflows (predetermined chains of LLM calls) have their place. When you genuinely need different specialized processing steps that can’t be combined – say, translating content, then checking it for cultural appropriateness with other models – a workflow makes sense. But these cases are less common than current practice suggests.

True agents (autonomous systems that decide their own next steps) are valuable for tasks that are not fully specified or might have multiple solutions. Complex research tasks, multi-step debugging sessions or adaptive planning scenarios may be suitable for truly agentic approaches.

My observation is that the complex multi-step workflows or unpredictable “agentic” systems achieve what a well-structured prompt with sound context engineering can easily and cheaply handle. They’re adding architectural complexity and risk without significant benefits.

Moving Forward

The rapid evolution and improvement in LLM capabilities mean our architectural patterns need to evolve, too. What made sense with smaller models and tiny context windows doesn’t necessarily apply today.

My suggestion: start with prompt engineering. Apply software engineering principles. Push it to its limits. Layer your concerns appropriately. Use the model’s native capabilities.

You might be surprised how far a well-architected prompt system can take you.

Sometimes, prompting really is all you need.

Do agentic coding tools make us less productive?

by

Are agentic coding tools like Cursor making us less productive?

An interesting study from METR (HT The Pragmatic Engineer newsletter) found that use of LLM-assisted coding tools like Cursor made some experienced developers *less* productive than before. The catch? Most of these developers had used Cursor for less than 50 hours.

I’ve been vibe coding a webapp as my summer project using Claude Code and Cursor, and this finding resonates with my experience.

Here’s what I think is happening:

➡️ IDEs are incredibly complex tools with steep learning curves
Fifty hours isn’t nearly enough time to develop the muscle memory needed for effective coding with any new IDE. I’ve stuck with IntelliJ for years precisely because of this learning curve investment, and even now when I’m not evaluating Cursor, I use Claude Code with IntelliJ.

➡️ AI tools are black boxes in ways that aren’t obvious
You might assume Cursor simply passes what you type to the underlying LLM, but these tools use code search, context compaction, and LLM routing behind the scenes. What you type gets significantly modified before reaching the AI, making it nearly impossible to develop a mental model of what’s happening. Cursor updates far more frequently than any IDE I’ve used, and those “optimizations” can change behavior without warning.

➡️ Agentic workflows break the flow state
It’s easy to get distracted when your AI agent is off deciding what file to change next. By the time the agent is done, I’ve often forgotten what I was working on. I honestly don’t understand how people running multiple instances of Claude Code stay productive.

📝 My experience so far
The magic moments when Claude Code one-shots a complex solution are incredible. But like I discovered while switching from Replit’s authentication to Supabase, it can be a grind. The auth switch seemed to work perfectly at first, but broke other parts of my app in subtle ways. Later, migrating the database to Supabase was a disaster – I forgot to update my CLAUDE.md file with the new libraries, so Claude Code got confused and burned through tokens trying to figure out my setup. Technically user error, but exactly the kind of mistake you only learn to avoid through experience.

I expect my productivity will improve significantly as I develop better workflows around these tools. Until then, vibe coding feels like being a new parent – periods of genuine frustration interspersed with moments of sheer amazement.

What is a vibe coder really?

by

20+ years ago, in my first job (junior business analyst – first class), I developed two critical skills: the ability to type fast and the ability to click around an application until something breaks.

As part of my ongoing exploration into vibe coding, I’ve come to realize that these two skills are more important than anything else I’ve learned since then 🤔.

Touch typing has become my emergency brake for when Claude Code or the replit Agent go bananas, deciding to rewrite 400 lines of perfectly good code when all I wanted was to change a variable name. Being able to quickly jump in and course-correct these enthusiastic agents before they decide to rewrite the entire app and burn a ton of credits has been critical.

The functional QA instincts have been even more crucial. AI coding agents looove to refactor code with the enthusiasm of a junior developer who has just discovered a new frontend framework (why are there so many?? 😭). They’ll elegantly refactor the entire authentication system and accidentally break the login button. Thanks, Claude 👍🏾👍🏾👍🏾!

Test automation assumes some stability in your interfaces, but coding agents treat every function signature like a creative writing exercise. So I find myself writing detailed bug reports as GitHub issues for Claude Code to pick up and fix: “Steps to reproduce: 1. Ask agent to add error handling 2. Agent rewrites entire error handling system 3. Original happy path now throws exceptions.”

My current vibe coding workflow has become suspiciously familiar:
1. Write detailed specs with explicit guardrails
2. Hand over to the developer, sorry – coding agent, and 🙏🏾
3. Do manual testing
4. File detailed bug reports for the agent to fix

Wait – this was my first job! I have become an old-school business analyst again 😬.

Just like baggy jeans and flip phones, late 90s ways of building software are back, baby!

To replit or not to replit ..

by

As a summer treat to myself, I spent a few bucks on replit to build a GoodReads style app – just so I could do a vibe-check on the current state of .. vibe coding.

What worked pretty well:
– It was fairly easy to build and deploy a full-stack application. Authentication, database, hosting – all handled without a fuss. 👍🏾👍🏾
– replit’s AI agent has really improved in the last six months. The code was decent and it could follow my instructions well 👍🏾
– replit’s GitHub integration allowed for some interesting workflows. I pushed changes from replit to GitHub, then made changes locally using Claude Code before pushing them back to replit to deploy automatically 👍🏾👍🏾👍🏾

What didn’t:
– Even for a relatively straightforward CRUD app, I needed to redesign the database schema, debug some strange edge cases, and force the agent to refactor some interesting design decisions 👎🏾
– replit’s effort based pricing model gets expensive very very fast. Picking the “High Power Model” is like gambling at the high-roller table. You will lose money very fast for random results 👎🏾👎🏾😱

Hype, more hype, and marginal costs:
– The replit subreddit is a fascinating vignette into the current state of vibe-coding: desperate posts begging for help, complaints about runaway costs, and also someone who didn’t know they could edit code without the AI Agent.
– Podcast bros and AI influencers pitch that “anyone can build micro-SaaS software and make bank”, but the people who will succeed will be the ones who understand how to build products, and can steer and override the AI agents.
– People pinning their hopes on AI building everything for them will end up paying premium prices to debug problems they can’t understand.

No alternative text description for this image

I am very very bullish about the AI space and am very impressed with what I could build after a couple of nights of vibe coding. I am stoked about being able to use Claude Code with replit as well as how easy it is to rollback and modify the app.

But it’s also clear that if I didn’t understand concepts like database normalization, system design, and error handling I would have been in a world of (very expensive) pain – not my cup of tea (no judgement!).