TL;DR

• Coding agents like Claude Code support subagents—AI assistants that spin up on demand with their own fresh context, separate from your main conversation

• When you’re building something and keep switching approaches—building, hitting friction, starting over—that’s usually a process problem, not a technical one

• Spawning adversarial subagents pressure-tests your plan before you commit—like a pre-mortem, but independent

• One prompt (“spawn 3 adversarial subagents to review this plan”) is all it takes; no setup, no configuration

I was building an ambitious side project, where you sit down excited, and two hours later you’ve made three decisions, built on the first one, realized it was wrong, and started over.

That loop—pick an approach, build it, hit friction, discard it, pick another—is a specific kind of miserable.

By the third iteration I was doing that thing Raymond Hettinger talks about—sitting back and thinking: there must be a better way.

The Four-Word Fix

Midway through that session, I typed something into Claude Code I had tried before, but in a different context:

“spawn 3 adversarial subagents to review this plan.”

The agents came back with critiques that exposed gaps I didn’t know existed—technologies I wasn’t deeply familiar with, assumptions I hadn’t questioned. I did 2 more rounds. By the end, I had better questions than I’d started with, and a plan I felt more confident in.

It reminded me of running a pre-mortem. Before committing to a direction, you pressure-test it. Except you’re not imagining failure yourself—you’re getting independent perspectives from agents with no stake in the decisions you just made.

What Are Subagents?

A quick note if you’re not already using a coding agent like Claude Code, Codex, OpenCode, or Cursor CLI: this pattern only works there (as far as I have tested so far). These tools support subagents—AI assistants you can spin up on demand for a specific job. Each one runs in its own fresh context window, separate from your main conversation. Think of them as colleagues who show up, do their work, and report back.

If you want a deeper primer, Philipp Schmid’s The Rise of Subagents is a good starting point, or you can check out this short video.

If you’re still using a chat interface for coding, you’re leaving a lot on the table. Coding agents give you a class of power-user features—subagents being one of them—that simply don’t exist in chat.

The Maker-Checker Model

OK, so now back to my original problem. There’s a name for what’s happening here: the maker-checker model.

The idea: split a task between someone who builds and someone who critiques. Different jobs—one builds, one questions—but a shared goal. In financial systems, no transaction goes through without an independent check. The same logic applies here.

When you spawn an adversarial subagent, it starts with a completely fresh context window. It hasn’t spent the last hour agreeing with your decisions. It only gets the seed prompt—a summary of what you’re trying to do—and nothing else. No accumulated bias. No sycophancy from 50 turns of “yes, let’s go with that.”

That freshness is what makes the critique reliable. And you don’t even read it directly—your main agent synthesizes it first, filters the noise, and presents what matters.

The critique does two things—first, it gives you perspectives you can push back on. You’re not just reading feedback—you’re using it as a jumping-off point to ask better questions, dig into gaps in your own understanding, and pressure-test assumptions you didn’t know you were making. LLMs carry a lot of knowledge. Adversarial subagents are a way to tap into it.

Second, it narrows your uncertainty. You still don’t know what you don’t know—that doesn’t change. But something independent reviewed your plan, and the gap between where you are and where you want to go feels smaller. That’s worth a lot, especially when you’re building in territory you’re not fully familiar with.

Beyond Planning

I use this pattern beyond planning. After writing code, I’ll spawn one to find gaps in the implementation. Finishing a blog post? Same thing—flow, structure, readability. The specific task changes. The prompt barely does.

How many agents to spawn? I usually say 3, sometimes 1. Honestly, I don’t have a formula. It’s still arbitrary. But even a single adversarial pass catches things you’d otherwise miss.

Just Say the Words

I try this every time I’m stuck on a plan or unsure about an implementation:

Spawn 3 adversarial subagents to review your plan.

That’s it—no setup, no special workflow. Just say the words. I’ve made it a habit, and it’s one of those small shifts that makes the uncertainty feel a little more manageable.

If you want to follow along beyond the blog, find me on Twitter/X at @dhruvbaldawa. I’d love to hear your thoughts — what topics around AI and developer productivity are you most curious about?

TL;DR

• Having an autonomous AI workflow isn’t about using it for everything—it’s about having the option to delegate, which changes how you evaluate and prioritize work even when you don’t use it.

• The real value is reclaiming your time for the parts that matter—planning, designing, deciding—while the agent handles solved problems you’d otherwise re-solve by hand.

• The discomfort of letting go isn’t about the agent’s capability; it’s about not yet having confidence in your process—detailed plans, review agents, and quality gates make it safe.

• Start with low-stakes work where failure is free, then gradually expand; once you’ve seen an agent build something correctly while you weren’t even there, you won’t go back.

• These are the worst models you’ll ever use—building the muscle now means you compound leverage with every improvement, while people who wait will start from scratch.

It was a Wednesday evening, the last working day before the Eid Al Fitr long weekend in Dubai. I had an idea for an internal tool—a test harness I’d been thinking about for a while. The kind of thing that would take a few days of focused work to build properly.

I spent a few hours that evening planning—breaking it down in Plan Mode, and running adversarial sub-agents to poke holes in the approach. By the time I stopped, the plan was almost there, but not quite finalized. I didn’t get time to review the feedback.

Thursday morning—a holiday—I looked at the adversarial feedback, ran my technical-planning skill, and had seven milestones. So I started the agent and left for breakfast with my family.

The first couple of milestones were done by the time we got back. That evening, I clarified a few design decisions and started the next batch. By early noon the next day, everything was ready. All seven milestones complete. Built to spec. 80% test coverage. Quality checks passed.

I haven’t used the tool yet—it’s still the weekend. It’ll probably need a few fixes. But the code is there, and I’m confident it’s close. I got the weekend with my family. I didn’t have to choose.

The planning was deliberate—without it, none of this would have worked. But the stakes were low. If the agent didn’t deliver, I’d build it next week. I lose nothing. That’s how I’ve approached a lot of this. Try it on something where failure is free.

But what actually surprised me wasn’t that the agent could do the work—I had confidence in the process by then. It was how long it sustained without me being at my desk. Every other time, I’d been sitting there or nearby. Available. This time, I was at breakfast, at the mall, putting my son to sleep. And the work kept moving. That intrigued me more than anything.

Subscribe now

It’s about having the option

That story isn’t about AI being impressive. It’s about having a choice that didn’t exist before. A year ago, the trade-off was simple: work through the weekend, or the tool waits. Now there’s a third option.

What I didn’t expect was how much the option changes your thinking, even when you’re not using it. Once you know you can hand something off, you evaluate work differently.

In the past few weeks, POCs that would have taken me multiple days have been finished in a few hours. Not because I’m working faster—but because I have the third choice. Plan it, hand it off, and come back to something working.

Spend time on what actually matters.

I love writing code. But I’ve wired models to controllers a thousand times. I’ve rebuilt the same utility functions across dozens of projects. The novelty is gone. These are solved problems I keep re-solving by hand.

When Copilot launched, it handled this kind of work well—Autocomplete for the boring parts. But the boundary kept moving. First it was single lines, then functions, then files. Now it’s moved far enough that I don’t have to write code at all for these tasks.

The principle is simple: don’t re-solve solved problems. Spend time on what isn’t solved yet—the planning, designing, architecting, and deciding exactly how I want something to work. The thinking. That’s where I add value. The AI takes what I’ve decided and makes sure it gets built.

The discomfort of letting go

Letting go of control is uncomfortable. Having an agent work autonomously—not knowing exactly what it’s doing or how it’s making decisions—can feel wrong. Especially if you care about quality. I get that.

But here’s what I’ve found: the discomfort isn’t really about the agent. It’s about not having confidence in the process.

A detailed planning session gives you confidence in direction—you know what will be built. And the process you design around execution gives you confidence in how it gets built. Review agents, validation criteria, quality checks—these aren’t optional extras. They’re what make letting go feel safe. I covered my current workflow in my previous post here.

I didn’t get here overnight. Everyone figuring this out right now is in the same position—it’s a new field, and what works for you might not be what works for someone else.

But you do have to keep pushing the boundary. Every time I hit something I didn’t want to do, or didn’t have the capacity, I’d try pushing the AI to do it for me. Sometimes it worked, sometimes it didn’t, and it’s fine if it didn’t.

Start small, you won’t go back

It started with a small refactor. A utility nobody depended on. The agent got it right. So I handed over something slightly bigger. Then something bigger.

Each time, I watched—how was the code quality? Did it follow the patterns I expected? Were the tests meaningful or just coverage padding? Over months, the answer kept being "good enough to

The scaffolding I built early on—review processes, quality gates, validation criteria—compensated for what the models lacked at the time. But as models and platforms improved, the scaffolding simplified. What used to be a directory structure with state machines tracking tasks is now a few lines in a config file. Same outcomes, less machinery.

And there’s a gateway effect. Once you’ve seen an agent build something correctly—start to finish, while you weren’t even there—you can’t go back to doing everything by hand. Not because you’ve gotten lazy. Because you know what’s possible, and choosing to spend hours on something you could delegate in minutes starts to feel like a misuse of your time.

Build the muscle now

These are the worst models you’re ever going to use. That’s not a complaint—it’s the point.

Models are getting better. Platforms are maturing. The tools themselves have already absorbed the scaffolding I needed six months ago to make autonomous workflows reliable.

You don’t stop building websites because dial-up is slow. You build them because when broadband arrives, you already have a presence, you already have distribution. The people who waited have to start from scratch.

The same applies here. The more you leverage AI now—the more you hand over, the more you build quality into your process—the more leverage you get when the next model drops. You’re not just building a workflow. You’re building the judgment for when to use it and the trust that lets you step away.

What changes

The question used to be: Can I build this? Do I have the time, the energy, the uninterrupted hours?

Now the question is: what do I want to build? And do I want to be the one writing the code, or the one deciding what gets built?

You don’t need a complicated setup. You don’t need to hand over everything. You need a workflow you can use—an option is right there, waiting for you.

Don’t wait for perfect. Start now. Iterate. Start with something where failure is free.

And then go have breakfast with your family.

If you want to follow along beyond the blog, find me on Twitter/X at @dhruvbaldawa. I’d love to hear your thoughts — what topics around AI and developer productivity are you most curious about?

TL;DR

• I used to run a kanban-style directory structure with state machines for task tracking. Models and tooling got good enough that it collapsed into a section in CLAUDE.md

• Start in Plan Mode: same philosophy as working with an engineer—align on the approach before anyone touches code

• Every commit has validation criteria: a concrete pass/fail the agent uses to self-check, and which reviewers use to verify if the implementation does what was expected. Distrust and validate.

• Preference negotiation before the plan is finalized: review frequency, commit strategy, review cycles—same process, different dial based on whether you’re building a POC or production code

• Two aggressive reviewers per commit—a senior engineer for architecture and code quality, a test reviewer for test quality. Focused agents produce better outcomes. Quality is what gives you speed.

• “No shortcuts. No laziness. Quality is non-negotiable.” This needs to be in the config—Claude Opus 4.5/4.6 biases toward speed as context fills up; making it explicit raises the floor

From kanban directories to a config file

That’s what my workflow looked like last year. A .plans/ directory, subdirectories for each project, task files moving between pending/ → implementation/ → review/ → testing/ → completed/. Commands to invoke at each stage. State to track.

This is what it looks like now.

The whole thing collapsed into a Plan Mode section in CLAUDE.md. Same outcomes—autonomous execution, review cycles, quality gates—but the platform absorbed the scaffolding.

Models got better at following structured instructions without needing machinery around them. Claude Code’s native Tasks feature replaced the kanban directories. Plans now live in the filesystem as markdown files; no shuffling files between folders.

What’s left is the config.

One agent implements. Two review. For each commit: implement, verify, and hand off to both reviewers in parallel. They leave findings. The implementer addresses them. The loop repeats until both reviewers sign off—then you commit. A single commit can go through 3-4 review cycles before that happens.

Rule zero: always start in Plan Mode

I work with Claude Code the same way I’d work with an engineer. You don’t hand someone a task and walk away—you talk it through first. What are we building, how are we approaching it, and what does done look like? Then they go.

Plan Mode is that conversation—alignment before code. You see what the agent will do before it does anything—and if something’s off, you catch it now instead of three commits later.

Without it, the agent optimizes locally—figuring things out on the go, making decisions commit by commit without seeing the full picture. I’ve had tasks where skipping Plan Mode caused the agent to go in a completely different direction from what I intended. Or turned a small change into a full refactor because it decided it needed to restructure first. Undoing that is expensive. Planning upfront means the agent sees the problem holistically, not just the next step.

Atomic commits—the unit of work

Every commit in the plan includes three things: the changes made, the tests added or modified, and the validation criteria.

The first two are obvious. The third is the important one.

My default when working with agents is to distrust and validate. Agents take shortcuts. They skip steps, drift from the requirements, and—if left unchecked—produce something that looks right without being right. Validation criteria is the fix: a specific, objective check that tells the agent what “done” actually means. Not interpretation—a concrete pass/fail the agent can verify before handing off, and that reviewers can check against.

Without it, the agent has no way to know if it’s actually done the right thing. It becomes a human-in-the-loop process—you review every commit, course correct, and verify manually. That doesn’t scale past small tasks.

Preference negotiation

Before the plan is finalized, the agent asks three questions: How often do you want to review—after every commit or at the end? Commit as you go, or batch at the end? One review cycle per commit, or iterate until approved?

Not all work is equal. A POC you want to move through quickly is a different scenario from production code you’ll maintain for the next two years. Same process, different dial. Asking upfront means the workflow matches the task—fast and low-ceremony when complexity is low, thorough and deliberate when quality needs to hold up over time.

The commit loop

This is the engine. Everything else exists to make this work.

Implement. Verify against the criteria. Hand it off to both reviewers in parallel. Address their findings. Loop until both sign off. Commit. Move to the next.

The order matters. Verification happens before review—the implementer doesn’t hand off work that hasn’t been checked against its own definition of done. And you don’t proceed to the next commit until the current one is approved—no half-finished work accumulating in the background.

The workflow lives in the plan file—once planning is done, the process steps are always in context. The agent doesn’t forget what it’s supposed to do. (It can still cut corners on effort as context fills up—that’s a different problem, addressed in the quality standards section.)

Each commit is also a verified green state. When the next task starts, everything that came before is done, reviewed, and working. If something goes wrong mid-session, you’re never far from solid ground—fall back to the last commit and start again.

The review agents

Two reviewers, not one. Not more.

More reviewers means more tokens per review cycle—and past a certain point, you’re paying for noise, not signal. There’s also a practical ceiling: in my experience, the more instructions you give an agent, the worse it performs—and that effect gets worse with less capable models. Focused agents produce better outcomes.

The two things I will not compromise on: decisions that make the system hard to extend, and tests that give a false sense of security—one reviewer for each.

• Senior engineer reviewer—for architecture, design decisions, and code structure. Not just whether it works, but whether it’s built in a way that won’t become a burden.

• Test reviewer—test quality exclusively. Missing edge cases, boundary conditions, and security checks. Tests that inflate coverage without increasing confidence are worse than no tests. This gets its own reviewer because test quality is important enough not to share attention with anything else.

Both are deliberately hostile. I’d rather have more comments to work through than fewer polished ones. A polite reviewer gives false confidence. An aggressive one gives you more to filter—but what survives is actually solid.

Quality is what gives you speed—not short-term speed, but the kind that compounds and helps you move faster.

Without them, you’re trusting the implementer to catch its own mistakes. It won’t.

Quality standards—why you have to say it

The CLAUDE.md has a line that reads: “No shortcuts. No laziness. Quality is non-negotiable.”

It needs to be there. I added it after noticing a specific pattern: Claude Opus 4.5 and 4.6 have a bias toward moving fast, and that bias gets stronger as the context fills up. The agent starts skipping ahead rather than slowing down to fix things properly. That line directly addresses it.

Before I added it, the pattern was clear: the agent would ignore review feedback, deem findings unimportant, and move on, or skip the review step entirely.

Since adding it, the agent’s behavior has changed noticeably. Critical and major issues get addressed. And something I didn’t expect: even minor feedback that doesn’t require much work—the agent handles it and moves on. No pushback, no deferral.

There are still occasional lapses. But the floor is higher.

With AI, compromising on quality is a choice, not a constraint. The cost of writing quality code is near zero. If quality slips, the instructions allow it. So the instructions don’t.

When there’s exploration involved

The workflow above assumes you know roughly what you’re building. When you don’t—unfamiliar technology, unclear approach, high unknowns—planning needs an extra step.

I work with the agent to develop a plan, but before committing to the plan, I spawn 2-3 “adversarial” sub-agents to critique it. Their job is to find holes: wrong assumptions, missing constraints, options I haven’t considered. It’s a pre-mortem before any code exists. Speed goes down. Decision quality goes up. Problems that would have surfaced mid-implementation get caught before any code is written.

One thing that makes this work is having MCP servers or real-time search in your coding setup. Plans built on current information just fail less often in execution.

Limitations

The workflow isn’t perfectly calibrated. Review agents spawn for every commit—including trivial ones where the overhead isn’t worth it. A documentation update goes through the same loop as a complex feature, with the same reviewers. That’s not ideal—different tasks need different reviewers. A doc change doesn’t need a senior engineer; it needs something focused on documentation quality.

The cleaner solution would be to move this out of CLAUDE.md entirely—into a separate skill that dynamically selects reviewers based on the nature and complexity of the change. I haven’t built that yet, so I've kept it simple for now.

The review loop consistently catches real problems. The overhead calibration is where it’s still rough.

Where this goes

Simpler systems are easier to work with, manage, and change. Every time models improved or tooling improved, I saw it as an opportunity to simplify—not to add more. The end outcome has stayed roughly the same. The system is a fraction of what it used to be.

What feels like necessary scaffolding right now probably won’t be soon.

Here are the links to the artifacts I mentioned:

• CLAUDE.md

• Test Reviewer

• Senior Engineer Reviewer

If you want to follow along beyond the blog, find me on Twitter/X at @dhruvbaldawa. I’d love to hear your thoughts—what topics around AI and developer productivity are you most curious about?

TL;DR

• The workflow got simpler in February, not more complex—same results, less overhead

• The workflow is a dial: two modes depending on how much you know about the problem

• ~100% of my code is now AI-written—not the goal, just a byproduct of getting the process right

• Planning takes more time now—I re-engage at verification

• AI agents are unpredictable, and once you feel close to done, stopping is harder than it sounds

• If you love writing code, this shift won’t sit well. If you love building things, it’s the best time to do it.

Every month, I expected the workflow to get more complex. In February, it got simpler.

October was about adding structure—a 4-phase workflow, two custom prompts, spec-driven development. January was about adding infrastructure, including review agents, sandboxing, and a Discord integration that pinged me when something needed attention. Each month, more pieces.

So I expected February to be more of the same. Instead, I ended up doing less. The models improved, and Claude Code’s native features matured. I spent less time managing the workflow and more time building things. And the output—the quality, the speed, the ambition of what I was attempting—went up.

The Workflow Is a Dial

The thing I kept adjusting in February wasn’t which tool to use. It was about how much control to hand over.

Most projects fall between the spectrum of “I know exactly how to do this” and “Not really sure what I want”. So, the workflow has two modes.

When I know what I’m building, I go heavy on upfront planning—a detailed commit plan, validation criteria for each task, and a review cycle baked in—and then step back. The automated workflow handles quality from there. I’m not reviewing every commit manually; the process is the safeguard. This is where the ~100% AI-written code comes from. Not because I’m hands-off, but because I’ve invested upfront with detailed planning.

When I don’t know what I’m building, I slow down. The focus shifts to uncovering unknowns before writing a single line of code. This is where I use what I think of as adversarial planning—sub-agents whose job is to find problems in the plan before I commit to it. I spawn sub-agents in the same Claude Code session and ask them to tear the plan apart. What could go wrong? What’s fragile? What assumptions am I making that might not hold?

These agents are deliberately aggressive. The goal isn’t to validate the plan—it’s to surface every risk I’m not thinking about, before I’ve spent tokens and time going down the wrong path.

For longer, more complicated projects, I use a technical-planning skill I’ve built that makes risk-surfacing a formal part of the planning phase—so the hard problems get solved first, not discovered halfway through.

Once the unknowns are known, I switch back to the first mode and let the workflow run.

Trusting the Process

I’d kick off a commit, walk away, and come back 45 minutes later to find it still running. Not because it was large. I run 3 agents per commit—one implements, 2 review—and the guideline is extremely clear: quality over speed. The implementer writes the code, reviewers find problems, and it goes back for revisions. Three or four rounds sometimes.

45 minutes for a small commit sounds absurd. But watching it play out built more confidence than double-checking my own work ever did. The mistakes that would have slipped through my tired eyes at 11pm weren’t slipping through.

I’m spending more time on planning now—commit sequence, validation criteria, test coverage—then stepping back. I check in at testing, not implementation.

Remove the Pain, Remove the Overthinking

I started more projects in February than any other month. Also finished more of them.

Something shifted around overthinking. I used to sit with technical decisions — weigh options, sometimes not start at all. With AI doing the implementation and refactoring cheap, the cost of picking wrong and redoing is near-zero. Turns out I wasn’t being thoughtful all those years. I was just avoiding the pain of changing course. Remove the pain, remove the overthinking.

So I’d just start. In two days, I had a codebase visualizer — something that shows how parts of a system connect, high-level structure with drill-down when you need it. It compressed 7-8 days of research into a few hours. Didn’t plan it out upfront. Started with a rough idea and iterated as my needs became clearer.

My relationship with bottlenecks changed too. Before, a bottleneck was just something to push through. Now I have two options — move fast through it, or build a tool that removes it for next time. The cost of building the tool is low enough that it’s often worth it. Either way, friction comes down, ambition goes up

The Cost of Constant Momentum

First: non-determinism. AI agents are not predictable. A complicated project might take twenty minutes. A simple quality fix might run for hours. I never know what I’m going to get.

What makes it hard to stop is proximity. I had 20 tests failing. Now I have 7. It’s 30 minutes before the end of my day, and I feel close. 10 minutes later, I’m at 1. Half an hour after I was supposed to stop, I’m still there—one failing test, one more prompt, maybe this one. I can see the finish line. That’s what keeps me going. It’s motivating in a way that’s hard to distinguish from just being hooked.

Second: fatigue. I’ve been parallelizing a lot—when an agent is working, I’m working too, looking at other tasks, starting other things. I can sustain that for a while. But the mental fatigue compounds.

Coder or Builder

Not everyone is going to like where this is heading.

If what you love is writing code—the craft, the syntax, the satisfaction of a well-constructed function—the direction AI is heading won’t sit well with you. That work is being absorbed: slowly, then all at once.

But if what you love is building things—seeing an idea become something real that works in the world—this is probably the best moment to be doing this. AI removes the tedious stretch between having an idea and having something that runs. The part that used to take weeks now takes days. Sometimes hours.

I think about the printing press. If you had ideas, the bottleneck was never the ideas—it was how fast you could physically produce the book. The printing press removed that constraint. Suddenly, the speed of spreading an idea wasn’t limited by how fast a human could copy it.

AI does the same thing for software. The bottleneck was never the ideas—it was how fast a human could implement them. Remove that constraint, and the question changes. It’s no longer ‘can I build this?’ It’s ‘what do I want to build?’

What Made It Stick

I shipped a lot in February. The thing that surprised me was how much of it felt effortless.

The models helped. The platform helped. But the real change was knowing how to work—and trusting that enough to step back.

In the next post, I’ll get into the exact configuration: an implementer agent and a reviewer agent per commit, atomic commits with validation criteria, and how it’s all encoded in CLAUDE.md. If this post was the what, that one is the how.

Edit: You can check the next post out here

Share

If you want to follow along beyond the blog, find me on Twitter/X at @dhruvbaldawa. I’d love to hear your thoughts — what topics around AI and developer productivity are you most curious about?

Leave a comment

• Renaming the blog from “Pixels and Ponderings” to “Breaking Build”

• Changing the domain from pixels.place to breaking.build

• The focus has narrowed: AI agents, developer productivity, and how we build software with AI

• Committing to monthly workflow updates

• pixels.place redirects here — nothing is lost

When I started pixels.place, I didn’t have a clear direction. I kept it deliberately open-ended — a space to write about whatever caught my attention. That was the right call at the time.

But over the past year, a focus emerged. Most of what I write about — and most of what I spend my time exploring — lives at the intersection of AI, agents, and developer productivity. How we build software is changing fast, and I’ve been documenting that shift as it happens, both in how I code with AI and how I use it beyond coding.

The name “pixels.place” doesn’t fit that anymore. So I’m renaming the blog to breaking.build.

Why “Breaking Build”

Yeah, the name is intentional. I am the one who builds.

But it’s also about what’s actually happening. The way we build software is going through a phase where existing systems and workflows will break. I’ve lived this firsthand — my own workflow has changed significantly over the past twelve months. The tools I use, how I use them, even how I think about building things. What worked six months ago doesn’t always work today.

That’s the cycle: you build something, it breaks, you rebuild it better. Then it breaks again. breaking.build captures that loop of constant iteration.

What to expect

The focus stays the same: AI agents, developer workflows, and how the intersection of the two keeps evolving. Practical, analytical, grounded in what I’m actually doing — not hype. Those posts were snapshots of where things stood.

I want to keep doing that. One thing I’m committing to: monthly workflow updates — a regular check-in on what’s changed, what’s working, and what broke since last time.

The logistics

pixels.place now redirects to breaking.build. All existing posts are here. Nothing is lost — just a name that fits better.

A huge thank you to my wife for the beautiful design of the new logo and design assets.

If you want to follow along beyond the blog, find me on Twitter/X at @dhruvbaldawa. I’d love to hear your thoughts — what topics around AI and developer productivity are you most curious about?

• I use AI to augment my workflows, not replace them.

• It doesn’t think for me. It helps me think better.

• Brainstorming, writing, newsletters, research: the specifics differ, but the pattern is the same–I stay in control, AI helps me get there faster.

Most AI advice is about delegation–offload this, automate that, let the agent handle it.

That’s not how I use it. AI has become part of how I work—not by replacing what I do, but by making it better: clearer thinking, less busywork, better results.

My AI Stack

• Claude Pro / Max subscription

• Perplexity Grok (Perplexity sub expired, so didn’t renew it yet, trying Grok instead)

• NotebookLM

• VoiceInk / MacWhisper

Brainstorming

After coding, this is probably my most-used workflow and also the one that I enjoy the most.

Sometimes I have a fully formed idea. More often, I have maybe 70% of something–a rough direction or a few scattered thoughts, but nothing I can articulate clearly (yet).

That’s when I open a conversation with Claude. Not to generate ideas for me, but to have something to bounce thoughts off. It acts as a sounding board, helping me figure out what I actually want to say.

(This post was planned exactly this way. I had a rough idea about sharing how I use AI, and the structure emerged through conversation.)

You can see excerpts from a recent brainstorming session below. Full transcript here.

How this works: I use something called “skills” in Claude. These are instructions that shape how Claude responds. It is now an open standard and available as a feature in some popular AI products.

My brainstorming skill is set up to ask clarifying questions rather than generate content–I talk through what I’m thinking, it asks questions, I answer, and through that back-and-forth, my thinking gets clearer.

Sometimes I’ll start by dictating rough thoughts (using VoiceInk or MacWhisper), then refine them in conversation. Voice → rough dump → AI-assisted refinement.

Writing

The same idea applies to writing too. I have different skills set up for various types of content: one for documentation, one for prompt engineering, one for writing blog posts and more.

Each set of skills shapes how Claude helps me. The blog writing skill, for example, knows my voice and style. It doesn’t write for me; it helps me turn rough thoughts into polished prose, section by section, with me approving each step along the way.

The pattern remains consistent–I stay in control, AI helps me get there faster

Staying Curious

I subscribe to a bunch of newsletters. Most of them either arrive packed with links I’ll never click or behind paywalls that just aggregate information from the internet.

With Gmail connected to Claude, I’ve found ways to extract value from them.

Multi-link newsletters: A newsletter arrives with 10 links to articles. I ask Claude to read the newsletter, follow the links, and give me a quick summary of each. I scan the summaries and only read the ones that look interesting. (transcript)

Paywalled content: Some newsletters tease an interesting topic but keep the full article behind a paywall. I ask Claude to read the preview, research the subject online, and summarize the findings. It isn’t a perfect substitute, but often good enough ¯\_(ツ)_/. (transcript)

Email digest: For newsletters that pile up, I use Gmail filters to collect them and ask Claude to transform them into a readable digest.

I prefer my emails organized by theme, not by email, with key insights bolded and fluff stripped out. It’s not a summary that skips things; it’s a reformatted version that’s actually pleasant to read. (transcript)

I get through newsletters in a fraction of the time. The summaries skip the noise and strip out the storytelling—I get 80% of the content in 5% of the time. For most things, that’s enough. And the stuff I really care about? That’s where I choose to go deep.

Here is my current prompt:

Transform these emails into an easy-to-read digest. Not a summary - a
complete rundown that doesn't skip key ideas or helpful information.

<approach>
- Reframe content for clarity and retention, not word-for-word
condensation
- Use narrative flow where it helps - connect related ideas across
emails
- Structure by topic/theme, not necessarily by email
- Preserve the sender's voice where distinctive

Format with:
- Clear section headers
- Bold for key insights
- Tables for comparisons when useful
- "Quick Recall" anchors at the end for important takeaways
- For newsletters that have external articles, scan all non-sponsored content and present that instead
</approach>

<remove>
- Greetings, sign-offs, pleasantries
- Promotional fluff (note skipped promos as "[Skipped: promo from X]")
- Redundancies across emails
</remove>

<preserve>
- All substantive content: concepts, insights, examples, data
- Dates, names, links, action items
- Nuance and context are needed to understand the ideas
</preserve>

<emails></emails>

The Little Things

A few smaller things that have become routine:

Deep research: When I want to go deep into a topic (to indulge my curiosity or compare products before buying), I’ll use Claude’s research mode or Grok.

Claude’s version is slower (it can run for up to 45 minutes) but more thorough. It’ll chase down multiple angles and come back with something surprisingly comprehensive. Grok is faster for quick answers. I use both depending on what I need.

Dictation: VoiceInk and MacWhisper have made voice input easy to use on Mac. VoiceInk runs locally (privacy win: nothing leaves my machine). I use it for prompts, messages, and dumping rough thoughts that I refine later. This is particularly great while vibe coding, brainstorming, and writing workflows.

NotebookLM: For longer documents (State of AI reports, blog archives from writers I follow, anything too dense to read in one sitting), I’ll feed it to NotebookLM.

The standout feature is Audio Overviews–it generates a podcast-style conversation between two AI hosts discussing your sources. Not robotic text-to-speech, but an actual back-and-forth discussion. SNL made a fun sketch on this. But honestly, it’s wild how good it is. I’ve used it to turn hundred-page reports into audios I can absorb while walking.

Recently, NotebookLM has added a bunch of cool ways to transform content. I highly encourage you to check it out, if you haven’t already.

The common thread: AI helps me get to the interesting parts faster. It doesn’t replace my thinking–it sharpens it. It doesn’t generate content for me–it helps me figure out what I actually want to say/read/do. I remain in control.

A realization: The workflows that stick around for long aren’t the ones that do things for me–they’re the ones that make me good where I’m bad, and better where I’m good.

And there’s more to why this works. It has to do with knowing which parts of your expertise are worth turning into reusable skills and prompts. I’ll dig into that in the next post.

(Thanks to my wife for proofreading this blog. She didn’t ask me to write this. Really.)

Leave a comment

TL;DR

• Not pure vibe coding — I use a structured workflow with AI: Research, Planning, Task Breakdown, Execution

• Planning beats prayers: alignment happens upfront before any code gets written

• Just 2 prompts for spec-driven development, simpler than external tools like Spec Kit

• Use expensive models (Sonnet) for planning, cheap models (Haiku/GLM) for execution

• Controllable autonomy: task-by-task review or full auto depending on project criticality

Introduction

I’ve been building a lot of tools and projects with AI agents lately. After a lot of trial and error — and some painful rework — I’ve settled into a workflow that’s been working really well for me. I wanted to share what that looks like.

This isn’t pure “vibe coding“ — where you describe what you want in English and the AI writes everything while you never look at the code. That approach creates problems. It’s also not traditional coding where AI is just autocomplete. Somewhere in between.

The core principle: planning beats prayers when it comes to LLMs. Give the AI too much freedom without structure, and it’ll drift. By the time you realize it, you’ve spent more time fixing things than if you’d just written the code yourself.

My Setup

I use Cursor and Claude Code. The workflow is the same across both — just different ways to invoke the same prompts.

For models: Claude Sonnet 4.5 for planning and task breakdown, Claude Haiku 4.5 or GLM-4.6 for execution. The key insight here is that once planning is done, you can use a cheaper model for the actual implementation. The heavy thinking is already finished.

I use three MCP servers:

• Perplexity for search and research

• Firecrawl for reading web pages

• Context7 for technical documentation

These help work around knowledge cutoffs. Instead of Googling across multiple pages to find best practices, the AI can research directly.

I manage prompts as slash commands in Claude Code (stored in a GitHub repo) and as Alfred snippets in Cursor. Haven’t figured out a good way to sync them yet.

All planning and task breakdowns go into markdown docs in docs/memory/ within each repo. This makes it easy to switch between chat threads or even tools — all the context lives in the document, not scattered across conversations.

The Workflow

Four phases: Research, Planning, Task Breakdown, Execution.

Phase 1: Research

Before I start planning, I use the MCP servers to research. Perplexity for general search and deep research. Firecrawl for reading specific web pages. Context7 for technical documentation.

This solves two problems: LLMs have knowledge cutoffs, and I don’t want to spend time manually Googling. The AI can research best practices and current approaches directly, which gives us both context before we start planning.

Phase 2: Planning

I don’t have a fixed planning prompt — it varies by project complexity and what I already know. The AI drafts a high-level plan, I review it, we refine together.

What I’m checking for: alignment with how I want to approach the problem, and the technical decisions the AI is making. Too vague? I ask for more detail. Too detailed? I tell it to pull back.

This all happens in a markdown document. I can see the plan as diffs in my editor, which makes it easy to review changes. All this before any code gets written.

This is where the heavy lifting happens. Once the plan is solid, the rest flows more easily. I’m still figuring out what makes a “good enough” plan, but I know it when I see it.

Phase 3: Task Breakdown

The plan gets broken down into atomic tasks. This is where the structure really matters.

Key principles that make this effective:

• Single atomic unit of work - each task results in running, testable code

• Progress over perfection - ship working code, iterate later, every task leaves the repo in a working state

• Detailed enough for one-shot implementation - the LLM prompt has step-by-step instructions

• Concrete definition of “done” - what exactly is finished when the task completes

• Automated validation - prefer tests/scripts over manual checks

These constraints keep the AI focused and make review manageable. If a task is too big or vague, it’s easy for the AI to drift.

This is what my breakdown prompt looks like (formatted as a slash command):

---
argument-hint: [SPEC DOCUMENT]
description: Create a task breakdown from a design document
---
Document: $1

You are my project-planning assistant.
Given a high-level feature or milestone description in the above document, produce an **agile task breakdown** in the following strict Markdown format, and update the above document.

For every task you generate, include:
1. **Iteration header** – `### 🔄 **Iteration <n>: <Theme>**`
2. **Task header** – `#### Task <n>: <Concise Task Name>`
3. **Status** – always start as `Status: **Pending**`
4. **Goal** – 1-2 sentences describing the purpose
5. **Working Result** – what is concretely “done” at the end of the task (code that runs, command that passes, etc.)
6. **Validation** – a checklist (`- [ ]`) of objective pass/fail checks (tests, scripts, CI runs, manual verifications)
7. **LLM Prompt** – a fenced <prompt></prompt> block with step-by-step instructions detailed enough for a coding LLM to implement the task in one shot
8. Separate tasks and iterations with `---`

Constraints & conventions:
- Each task must be a single atomic unit of work that results in running, testable code.
- Favor incremental progress over perfection; every task should leave the repo in a working state.
- Validation should prefer automated tests/scripts but may include human review items.
- Use present-tense, imperative verbs for prompt steps (e.g., “Create…”, “Add…”, “Run…”).
- Use **bold** for filenames, routes, commands, etc. inside prompts to improve readability.
- Keep the entire answer pure Markdown; do not embed explanatory prose outside of the required structure.
- You may run into output token limits, so write one iteration at a time in the document, then add another one

The AI adds tasks to the same markdown document. I review them there — easy to see as diffs, easy to understand what changed.

Phase 4: Execution

Now the AI actually builds it. Two modes, depending on the project.

Task-by-task: The AI does a task. I review it, test it, commit it, move to the next one. This is what I do for critical projects or when I have time.

Autonomous (--auto flag): The AI does everything — completes tasks, commits with descriptive messages, moves to the next task. I come back later, and the work is done. I use this for internal tools or when I’m low on bandwidth.

And here’s what the execution prompt looks like (again, formatted as a slash command):

---
description: Do the actual task
argument-hint: [SPEC DOCUMENT] [TASK NUMBER | --resume] [ADDITIONAL CONTEXT] [--auto]
---
**Flags:**
- `--resume`: If present, the agent starts from the first incomplete task instead of the specified task number
- `--auto`: If present, the agent will automatically:
  1. Perform the task
  2. Commit changes with a descriptive message describing what was done
  3. Move to the next task
  4. If unable to complete a task, update the document with current progress and stop for user feedback

# Instructions
1. Update the document when you start by changing the task status to **In Progress**
2. Read the full task including the LLM Prompt to guide your approach
3. Perform the actual task:
   - Follow the step-by-step instructions in the task’s `<prompt>` block
   - Implement the code/changes needed to meet the “Working Result” criteria
   - Ensure the implementation passes the “Validation” checklist
4. After completion:
   - Update the document with your progress
   - Change task status to **Complete** if finished successfully
   - If using `--auto` flag, create a commit with a message describing what was done (e.g., “Initialize Repository”, “Set up API endpoints”, not “Complete task 1”)
   - Move to the next task if `--auto` is enabled
5. If unable to complete the task:
   - Document what was attempted and any blockers
   - Update task status to **Blocked** or **Pending Review**
   - If `--auto` is enabled, stop and request user feedback before proceeding

Context: $1
Implement task $2
$ARGUMENTS

The tasks are granular enough that I can review them without a lot of cognitive load. And because planning is done, I can use cheaper models for execution — Haiku 4.5 or GLM-4.6 instead of Sonnet 4.5.

I tested this recently building a CLI tool for making mass updates across multiple codebases. It was late evening, I was tired, but I wanted to get it done. We did the planning and task breakdown together — that part I was careful about. Then I just added the --auto flag and let it run.

Twenty minutes later, I came back. The tool was working. That’s when I knew this workflow actually worked.

This is Spec-Driven Development

I realized later this is basically spec-driven development—where specifications drive AI implementation instead of vague prompts. Tools like GitHub’s Spec Kit exist for this, with external tooling and multiple commands for each phase.

My approach is simpler, at least for me. It’s just 2 prompts. One for task breakdown, one for execution. No external tools to install or learn. The markdown document is the spec. It’s flexible enough to adapt to different project types without feeling rigid.

Why This Works

Prevents Drift

The biggest benefit I’ve found: alignment happens upfront, before code gets written. If the AI is going to take a wrong approach, I catch it during planning — not after it’s written thousands of lines of code.

The structure keeps the AI focused. Each phase has clear constraints. Skipping them usually means I spend more time fixing things later than if I’d just followed the process. This is the “planning beats prayers“ principle—systematic methods outperform hoping for good outputs.

Context Engineering

The markdown document approach solves a real problem: context rot. LLM performance degrades as the context window grows — even with good context management. By keeping all relevant context in a document, I can start fresh threads whenever I need to without losing continuity.

This also makes the workflow tool-agnostic. I can switch from Cursor to Claude Code, or jump between different chat sessions, and all the context is still there. The document is the source of truth, not the conversation history.

Controllable Autonomy

The --auto flag gives me flexibility. Critical projects get task-by-task review. Internal tools or low-risk work can run fully autonomous. Same workflow, different levels of oversight depending on what I need.

Cost Management

Planning and task breakdown use Sonnet 4.5 — the expensive model that does the hard thinking. Execution uses Haiku 4.5 or GLM-4.6 — cheaper models that follow the detailed instructions from the breakdown.

Since the plan and breakdown are already done, the execution model just needs to implement what’s specified. This cuts costs significantly for larger projects.

Limitations & Tradeoffs

This workflow doesn’t work for everything.

Doesn’t work well for:

• Pure debugging or investigation work — when you don’t know what the problem is yet

• Very simple one-off tasks — the overhead isn’t worth it

• For these, I either use plan + build mode or just write the code directly

Still struggles with:

• Uncommon integrations or non-standard architectures

• Connecting systems in unusual ways that aren’t common patterns

• LLMs are good at general problems, not edge cases

• When this happens: try a few approaches, then do it myself if the model can’t get it

• Getting rarer with better models (Sonnet 4.5) but still happens

The overhead:

• Upfront time investment in research and planning

• Worth it for anything beyond trivial tasks

• Overkill for quick fixes or small scripts

The failure mode without structure:

• AI drifts in wrong direction

• Don’t catch it until too late

• Spend more time undoing and re-reviewing than if I’d just written it myself

• Why I stick to the workflow now, even when it feels like extra work upfront

Known issues:

• When generating large task lists, the LLM can hit its maximum output token limit and stop mid-breakdown

• The response just ends without completing all tasks

• Workaround: ask it to continue, or break the plan into smaller iterations upfront

Wrapping Up

This is what’s working for me right now. Not pure vibe coding, not traditional coding—something in between that gives me control while still using AI effectively.

I’m calling this “October 2025” even though we’re at the end of November. That’s deliberate. I’ve already iterated on this workflow quite a bit in November, and I’ll share those updates in the next post. This is a snapshot of where I was, not where I am now.

The key insight: I’m not using AI to do work for me, but with me. The structure ensures we’re aligned before any code gets written. Planning beats prayers.

If you’re using AI coding assistants and finding yourself doing a lot of rework, maybe try adding more structure upfront. It feels like overhead at first. But it usually saves time in the end.

I’d like to hear your thoughts on this. What’s your workflow with AI agents? Have you found ways to keep them on track?

TL;DR:

• You don't need deep AI theory knowledge to build valuable AI applications; focus on effectively using existing tools and APIs.

• Think of AI proficiency in four levels (Pioneers, Engineers, Developers, Users); this post is targeted towards Level 3: AI Developers (engineers integrating AI).

• Leverage powerful APIs with techniques like prompt engineering, Retrieval-Augmented Generation (RAG), and In-Context Learning (ICL) – you often don't need custom fine-tuning, massive datasets, or expensive hardware.

• The most valuable skill for AI Developers is framing problems correctly and understanding what LLMs can achieve, not their internal mechanics.

Note: For the rest of this post, I’ll use the term AI interchangeably with GenAI and LLMs for brevity.

The buzz around AI can feel overwhelming. I often get messages from friends and colleagues asking, "Do I need to learn neural networks and deep learning to work with LLMs?". Some developers may dive into deploying open-source models locally, only to find the results underwhelming compared to state-of-the-art APIs. Others get stopped before they even start, worrying about the potential costs — "Will I need a farm of expensive GPUs?" or "Are API bills going to break the bank?".

I've noticed this misconception is widespread. It's like thinking you need to understand internal combustion engines before driving a car, or how TCP/IP works before building a website. This might keep many talented developers from exploring the AI space.

With terms like "embedding vectors", "fine-tuning", and "prompt engineering" flying around, it’s hard to know where to start or how deep you need to go. Let me offer a framework I've found helpful.

The Four Levels of AI Engagement

I see engaging with AI at four distinct levels:

1. Level 1: AI Pioneers: These are the deep researchers, the academics, the theorists pushing the absolute boundaries. They develop novel architectures, create entirely new ML approaches, publish papers, and define the ethical guardrails.

2. Level 2: AI / ML Engineers: These are the ML engineers and data scientists who take the pioneering research and actually build, train, and optimize foundation models (like GPT, Claude, and Gemini). They fine-tune models, optimize inference, manage training infrastructure, and work at places like OpenAI, Google, Anthropic & Meta AI.

3. Level 3: AI Developers: This is where most software developers and product creators fit in. They take the powerful models created by Level 2 folks and integrate them into applications using APIs, build systems with Retrieval-Augmented Generation (RAG), implement prompting techniques, or maybe do some light fine-tuning. They solve real-world problems using AI as a tool.

4. Level 4: AI Users: This is basically everyone else. Professionals using AI tools (like ChatGPT, Copilot, Midjourney) to boost their productivity, students using them for research, artists for creation, and everyday people leveraging AI for convenience. This level requires knowing how to direct the tools, not technical expertise.

For most of us, especially engineers looking to add AI features to products, Level 3: AI Developers is the sweet spot.

So, You Want to Be an AI Developer (Level 3)? Let's Bust Some Myths.

Myth 1: "I need to understand how neural networks and transformers work to build applications with LLMs."

That's not the reality. As I said, it's like needing to understand the engine to drive the car. Having a good mental model of what LLMs are good at is far more important than knowing exactly how they work internally.

"Working with LLMs is like learning to be a good manager: you need to learn how to give clear instructions and interpret the results, not understand how your team members' brains work."

— Simon Willison

You need to understand the capabilities and limitations – things like context window limits (the amount of information the model can consider at once), the potential for hallucination (the model confidently making things up), and that they don't inherently know real-time information.

Myth 2: "I need my own beefy GPU setup or a dedicated AI server farm."

That's absolutely not the case, especially when starting out. You can prototype and build significant applications entirely using hosted APIs. I built my first LLM application using nothing but OpenAI's API and a bit of Python, running locally. No GPU required.

Services like OpenRouter (aggregator for various models), GitHub Models, and Google AI Studio / Gemini API provide access to powerful models without the need for a GPU or dedicated infrastructure for FREE. However, they might use your data for training or research, which is fine for hobby projects or while learning. If this is a concern, you can opt for their paid offerings.

There are other services like:

• OpenAI's API

• Anthropic's Claude API

• AWS Bedrock

• … and many more

These platforms handle massive infrastructure for you. You just send API requests.

Myth 3: "I must train or fine-tune my own custom model to get any real value."

Not necessarily, and maybe even not desirably in many cases. This used to be true before, but the power of today's foundation models combined with clever prompting techniques often gets you further, faster, and cheaper. Prompt engineering coupled with In-Context Learning (ICL) is surprisingly potent. ICL is the model's ability to learn from examples provided directly within the prompt, without needing its internal weights changed or re-training the model by fine-tuning.

Fine-tuning still has its place for deep specialization, but consider the downsides:

• Cost & Complexity: It requires curated datasets, compute resources for training, and ongoing maintenance.

• Scalability Issues: Do you really want to fine-tune every time a significantly better base model comes out (which is happening constantly)? Maintaining multiple fine-tuned models gets complex and expensive quickly.

• ICL Can Be Better: For many tasks, providing good examples in the prompt (few-shot or many-shot ICL) can achieve performance comparable to or even better than fine-tuning, especially when combined with techniques like Retrieval-Augmented Generation (RAG) – giving the model access to external, specific knowledge it wasn't trained on – to provide relevant, up-to-date context.

Start with great prompting and RAG and it should cover 99% of your use cases. Only consider fine-tuning if you hit a performance ceiling that simpler methods can't overcome.

Myth 4: "If I don't code in Python, I'm out of luck."

The reality is that while Python has a rich ecosystem (hello, LangChain), it's not the only game in town. Most major API providers offer SDKs in multiple languages. We now have excellent libraries like LangChain.js for JavaScript, ruby-openai for Ruby, LangChain4j for Java, and more.

And beyond code, there are increasingly capable low-code/no-code platforms like Flowise, and Langflow that integrate LLM capabilities, allowing you to build flows visually.

Myth 5: "This is going to cost me hundreds or thousands in API bills!"

It can, but it doesn't have to if you design for cost-efficiency from day one. I recently built a document processing app analyzing hundreds of pages daily that costs less than $10/month in API fees due to careful optimization.

• Start cheap: Use less expensive, capable models (like Gemini 2.5 Flash, Deepseek R1, or GPT 4.1) for initial development. Only upgrade when needed.

• Prompt caching: Most API providers support prompt caching which can reduce your costs upto 90%.

• Cache results: Don't call the API for the exact same query repeatedly.

• Set token limits: Be mindful of input and output lengths.

• Use RAG: Retrieval Augmented Generation can reduce the amount of context you need to stuff into prompts.

• Monitor usage: Keep an eye on your API dashboards and configure billing alerts.

• Evaluate carefully: Ensure the LLM is actually adding value commensurate with its cost.

Myth 6: "AI development requires a deep understanding of complex algorithms and mathematical concepts."

That's not the reality for Level 3: AI Developers. While complex algorithms are the bedrock built by Level 1 & 2 folks, we can build incredibly useful applications by mastering the application layer. You can leverage prompt engineering and RAG here. Function Calling / Tool Use is another useful technique that allows the model to interact with external APIs & tools to get real-time information or perform actions.

Focusing on how to effectively implement these techniques and integrate them into your software is far more valuable than deriving backpropagation formulas.

Myth 7: "You need massive datasets to train your own models for any useful application."

"I need terabytes of data just to get started, right?" Wrong. While foundational models do require massive datasets (that's OpenAI's or Google's problem, not yours as a Level 3 dev), adapting these models often doesn't.

And remember, for many applications, leveraging pre-trained models via APIs combined with prompt engineering and RAG is entirely sufficient, bypassing the need for custom training data altogether.

Myth 8: "Building AI applications is only for large companies with significant resources."

"This AI stuff looks fancy and expensive. Surely only Big Tech can afford it?" That might have been true a few years ago, but the landscape has dramatically changed. Democratizing factors include:

• Accessible APIs: Major model providers (OpenAI, Google, Anthropic, etc.) offer powerful models via APIs with pay-as-you-go pricing, often with generous free tiers to start.

• Competitive Pricing: Costs are falling, and aggregators like OpenRouter provide access to various models at different price points. You can even find tools to estimate costs.

• Open Source: A thriving ecosystem of open-source models (e.g., Llama, Mistral) and frameworks (LangChain, LlamaIndex) lowers the barrier to entry.

• Cloud Platforms: Services like Hugging Face, Google Vertex AI, or AWS Bedrock simplify deployment and management.

While building a foundational model is resource-intensive, building on top of them is increasingly feasible for individuals, startups, and small teams. Focus on cost optimization (Myth 5) and clever application design.

Myth 9: "The AI field is moving too fast, and anything I learn now will quickly become obsolete."

"It feels like there's a new model or technique every week! How can I possibly keep up? Won't my skills be useless next year?" It's a valid concern given the pace, but foundational knowledge and skills have surprising longevity.

While specific model names or the hottest new framework might change, the underlying principles remain relevant:

• Core Technical Skills: Proficiency in programming (especially Python), data handling, APIs, and cloud basics are always valuable.

• Understanding Capabilities: Developing a strong mental model of what LLMs can do, their strengths (reasoning, generation) and weaknesses (hallucination, knowledge cutoffs), is crucial for effective application.

• Problem-Solving & Design: Knowing how to break down a problem and design a system using AI components (like RAG, function calling) is a durable skill.

• Prompt Engineering: While the specifics evolve, the core principles of clear communication and providing context remain key.

Think of it like web development: frameworks and libraries change constantly, but understanding HTML, CSS, JavaScript, HTTP, and good design principles provides a stable foundation. The most important skill is learning how to learn and adapt.

Getting Started as an AI Developer (Level 3)

So, how do you actually begin?

1. Choose Your API Provider: Start with a reliable hosted API rather than self-hosting. Many have free tiers or credits to get you started. OpenRouter or GitHub Models are a good starting point.

2. Pick a Framework (optional but helpful): While you can use APIs directly, frameworks like LangChain or LlamaIndex (available in Python, JS, etc.) provide useful abstractions for common patterns like conversation history, RAG, structured outputs, and tool use. Check out documentation from OpenRouter to integrate with most popular frameworks here.

3. Start Simple, Then Iterate: Don't try to build the next ChatGPT immediately. Pick a small, well-defined problem. Maybe a chatbot for specific FAQs, a summarizer, or a tool to extract specific data from text. Build a basic version, see how it works, and then enhance it.

Learning More About Prompting

Learn the Mental Models, Not the Math: Focus on what problems LLMs are good at and how to prompt them effectively. This comes from practice and experimentation. It's like learning to cook – you get better by trying recipes and adjusting ingredients, not by studying the chemistry of Maillard reactions.

Here are some resources from leading providers to help you learn more:

• Prompt Engineering Guide by PromptingGuide.ai

• IBM's Prompt Engineering Guide

• Google's Prompting Essentials

• OpenAI's Best Practices for Prompt Engineering

• Anthropic's Prompt Engineering Overview

The Real Challenge: Problem Framing

The hardest part often isn't the code; it's framing the problem correctly. Understanding what LLMs can and can't do well is more valuable than knowing the model internals.

Ask yourself:

• Is this task about recalling specific knowledge (good for RAG) or general reasoning?

• Does it need multi-step thought or complex instruction following?

• Does the AI need memory of past interactions?

• Is the goal information retrieval, content creation, decision support, or autonomous action?

Answering these helps design your system and prompts effectively.

Conclusion: Just Start Building

I don't really have a silver bullet or perfect learning path. The field moves too fast. But I'm confident you'll learn more from building one simple application than from reading a dozen research papers.

Leverage the incredible work done by the Pioneers and AI Engineers through APIs. You're much better off starting with APIs than trying to deploy and manage open-source models yourself.

So, my advice to you is: stop worrying about becoming a deep learning expert overnight. Focus on identifying a problem where an LLM could help, pick an API, and build a small proof-of-concept.

Your likes and comments motivate me to write more. If you found this article helpful, please share it with another curious mind.

Share

Are there topics you’d like to read about, let me know in the comments.

Have you tried dabbling with LLMs? What challenges are you facing? Leave a comment and I’d be happy to discuss them with you.

Leave a comment

TL;DR

• Francis Bacon’s 400-year-old essay, "Of Studies," is packed with relevant strategies for learning with today's AI.

• Critical Thinking: AI provides instant information, but Bacon stresses the importance of always "weighing and considering" its output.

• Know Your 'Why' & 'How Deep': Understand if you're learning for delight, ornament, or ability, and choose your engagement level (taste, swallow, or digest) accordingly.

• Experience is Irreplaceable: Ground AI's theoretical knowledge in practical application and lived experience. Don't forget the "burning the onions" lesson.

• Adapt Your Learning Habits: AI changes reading (prompting), discussion (interaction), and writing (assistance). Stay active in guiding, questioning, and synthesizing.

• The Real Goal = Wisdom: Aim beyond just getting quick answers; cultivate the judgment and understanding to use AI effectively.

AI vs. Deep Understanding

I've been watching this new "vibe coding" trend, where engineers use AI to generate code rapidly. As an experienced developer, I see the appeal—ship faster and focus on overall design rather than implementation. But I also see juniors struggling with codebases they don't understand. There seems to be a growing tension between productivity and deep understanding.

Then Fermat's Library dropped Francis Bacon's "Of Studies" in my inbox. Reading this 400-year-old essay with its insights on learning made me wonder - what would the great thinkers make of our AI shortcuts to knowledge? Are we building on the sand when we prioritize speed over understanding?

Bacon wrote "Of Studies" in 1625 when knowledge acquisition was slow and deliberate. Today, we get instant answers from AI. This shift isn't just about convenience - it fundamentally changes how we learn and think.

What caught my attention in Bacon's essay was his straightforward categorization of why we learn. This simple framework has made me question whether AI enhances or undermines each purpose.

The contrast between Bacon's world and ours raises crucial questions. When we use AI to generate code or solve problems, are we developing genuine understanding or just collecting solutions? Does AI-assisted learning build real expertise or create dependency?

I don't have definitive answers, but examining these questions through Bacon's framework is valuable. As a software engineer who regularly uses these tools, finding the right balance between AI assistance and deep understanding matters for the quality of what we build.

Note: For the rest of this post, I’ll use the term AI interchangeably with GenAI and LLMs for brevity.

What Bacon Got Right About Learning

Let's unpack Bacon's core ideas and see how they hold up – and where they get interestingly complicated – when confronted with modern AI.

Reading Bacon reminds me of Orwell's famous line from Animal Farm. The same applies to learning. All information might seem equal in the age of AI, all instantly available, but some forms of knowledge – particularly those gained through deep engagement and real experience – remain "more equal" than others. The distinctions Bacon draws help us navigate this uneven terrain.

The Three Reasons We Learn (According to Bacon)

Bacon breaks down why we bother learning anything into three simple buckets:

1. Delight: For personal enrichment, the quiet joy of understanding.

2. Ornament: To enhance conversation, to articulate ideas effectively.

3. Ability: To improve judgment, make better decisions, and act effectively in the world.

AI can certainly turbocharge these.

• Want tailored learning for pure enjoyment? AI can personalize paths.

• Need to sound smart at that dinner party? AI will give you talking points in seconds.

• Need to solve a complex problem? AI will be your brainstorming buddy.

But here’s the rub: Is passively scrolling AI-generated content genuine delight, or just consumption? Is rattling off AI-supplied facts true ornament, or just echoing without understanding? Does relying on AI analysis build real ability, or foster a dependency that leaves us vulnerable when the tech fails or misleads?

These aren't just philosophical questions - they have real consequences for how we learn and work. The more we rely on AI for instant answers, the less we exercise our own mental muscles. It's like taking an Uber for a two-block walk - convenient, sure, but you're missing out on the benefits of walking.

Why Real Experience Matters More Than Data

Here's where Bacon really nails it. Books teach you the theory, but life teaches you how it really works.

This is where I think AI falls flat. I don't care how many billions of parameters ChatGPT has or how much of the internet it's seen - it hasn't actually lived anything. It hasn't burned dinner, gotten lost in a new city, or felt the frustration of debugging code at 2 AM.

The real skill, he argued, isn't just knowing things, but possessing the wisdom – often gained through observation – to apply that knowledge effectively.

It's the same with AI. The power isn't just having the tool, but having the wisdom to wield it. We need to ground AI's vast knowledge in the messy, tangible reality of experience.

It's like the difference between reading a travel guide and actually navigating a foreign city. AI can give you the map, the facts, even translate phrases instantly. But it's only by wandering the streets, getting a little lost, and figuring things out on the ground that you truly learn the city's rhythm and gain the confidence to explore it independently. Experience adds the dimensions AI can't capture.

Don't Just Consume – Critically Consider

AI models are prone to errors, biases, and outright making things up (those infamous ‘hallucinations’). Bacon’s plea to "weigh and consider" is our primary defense.

This brilliant metaphor offers a framework for how we should approach different types of knowledge:

Tasting is that quick sampling, giving you just enough flavor to know what's there. With traditional books, this might be reading the introduction or skimming chapter headings. With AI, it's asking for a brief overview or summary. This approach is perfect for initial exploration or for topics tangential to your main focus – but recognize that you're just getting surface-level impressions.

Swallowing goes deeper (obviously). You're consuming the whole thing, but without lingering too long over every nuance. You understand the main arguments and ideas, but you haven't necessarily interrogated every assumption or followed every implication. In the AI context, this is like reading a comprehensive AI-generated explanation of a topic and accepting its general framework, while remaining aware that you haven't verified every claim.

Digesting is the deepest level of engagement – where true mastery happens. You're not just consuming; you're breaking it down, absorbing it, making it part of you. When reading traditionally, this meant close analysis, taking notes, connecting ideas to your existing knowledge. With AI, it means actively questioning outputs, seeking multiple perspectives, verifying claims, and synthesizing the information into your own understanding. This is slow, demanding work – but it's the only way to develop genuine expertise.

Bacon specifically warned against relying solely on summaries – what he called "distilled books... flashy things." His concern was that these concentrated versions might offer the illusion of understanding without the substance. They were convenient, yes, but they removed the vital context, the supporting evidence, the qualifying nuances that build true comprehension.

This warning should ring alarm bells in our AI age. Large language models are, in essence, the ultimate distillation machines – creating summaries, extracts, and simplified versions with remarkable efficiency. The danger? That we mistake this distilled knowledge for the real thing.

Indeed, contemporary research is exploring this very dynamic, with studies suggesting that while AI boosts efficiency, it might also inadvertently reduce the depth of cognitive effort associated with traditional critical thinking and learning.

When we rely exclusively on AI-generated summaries, we sacrifice:

• Contextual understanding: The background that shapes why an idea matters and where it fits

• Evidentiary foundation: The supporting facts that give a claim its strength

• Intellectual struggle: The cognitive work of wrestling with difficult concepts – the very struggle that cements learning

• Serendipitous discovery: Those unexpected tangents and connections that often lead to our most valuable insights

AI summaries can be jumping-off points or navigational aids, but treating them as destinations leaves us with shallow knowledge – impressive perhaps in breadth, but lacking the depth that makes knowledge truly valuable.

The Learning Triangle: Reading, Conference, Writing in the AI Era

Bacon distilled the core intellectual practices into a powerful triad. Let's unpack what each of these meant in Bacon's world:

Reading was about filling the mind with knowledge – becoming "full" of ideas, facts, and perspectives. Deep reading built a mental reservoir from which insight could be drawn. It was about patient accumulation, careful consideration, and the gradual building of a knowledge base.

Conference – or conversation and debate – created the "ready" mind. By engaging with others, by having our ideas challenged and being forced to defend them, we developed intellectual agility. This was knowledge-in-motion, the ability to recall and apply what we know in real-time, to adapt to unexpected challenges and questions.

Writing crafted the "exact" mind. The discipline of committing thoughts to paper revealed fuzzy thinking that might pass unnoticed in conversation. Writing forced precision – in language, in logic, in structure. It was the ultimate test of whether you truly understood something or just thought you did.

This triangle still forms the foundation of deep learning today. But now AI transforms each vertex in ways both subtle and profound:

Reading → AI Prompting: Instead of the slow accumulation of knowledge through books, we can instantly query AI. This brings tremendous breadth, but potentially at the cost of depth. The effortlessness of AI-supplied information might mean we engage less deeply, question less rigorously, remember less durably.

Conference → AI Interaction: While AI can simulate discussion, it lacks the unpredictability of human conversation. Real debate involves emotion, unexpected challenges, and the social dynamics that push us to clarify and defend our thinking. AI rarely truly surprises us or forces us to reconsider in the way a human interlocutor might.

Writing → AI Assistance: When AI helps draft our writing, we may bypass the crucial cognitive work that writing demands. The act of organizing thoughts, finding precise language, structuring arguments – these processes don't just communicate ideas, they clarify them for the writer. When AI handles these tasks, we might produce polished output without the mental clarification that writing traditionally provides.

The key is reclaiming the human role in each step. We must guide the prompting (active reading), critically interrogate the AI's responses (real conference), and take ownership of the final synthesis (true writing). Otherwise, we risk becoming what Bacon warned against: seeming knowledgeable without substance, relying on "much cunning, to seem to know, that he doth not." AI can be a convincing illusionist.

Practical Strategies for the AI Age

So, how do we translate Bacon's 400-year-old wisdom into concrete actions with today's tech? Here’s a playbook:

Be the Skeptic: Question Everything

• Make "weigh and consider" your mantra. Treat AI output as a starting point, not the final word.

• Develop a deeper verification process for our complex world:

  • First-level verification: Does this align with what you already know? Does it pass a basic logic and plausibility check?

  • Second-level verification: What are the sources? Not just which sources, but what kinds of sources? Primary research? Expert consensus? Opinion?

  • Third-level verification: Seek contrary perspectives. What would someone who disagrees say? What evidence might they cite?

• Remember that in domains with deep complexity (science, medicine, law), surface-level verification isn't enough – peer into the methodology, the sample sizes, the underlying assumptions behind claims.

• When stakes are high, triangulate information through multiple channels – academic papers, expert commentary, and diverse AI models with different training approaches.

Know Your Why: Define Your Goal

• Are you here for delight, ornament, or ability? Be clear about your purpose.

• Match your engagement level to your goal: Need a quick definition (taste)? Exploring a new topic (swallow)? Building deep expertise (digest)?

• Use AI strategically: great for brainstorming, summarizing dense text, or drafting initial ideas, but always follow up with your own critical thinking.

Mix It Up: Balance Your Learning Diet

• Don't let AI replace everything. Books, articles, human conversations, and hands-on projects are still vital.

• Seek out real discussion ("conference") with other humans. Challenge ideas, debate nuances – AI can't replicate this.

• Keep writing your own thoughts ("writing"). The struggle to articulate ideas clearly is where true "exactness" is forged.

Get Real: Connect to Experience

• Look for ways to apply what you learn via AI to the real world. Build something, try something, test the theory.

• Does the AI's insight match what you observe? Experience is the ultimate fact-checker.

• Learn to trust your gut and your lived experience, especially when it clashes with an AI suggestion. Don't be afraid to disagree with the algorithm.

Finding the Right Balance

It's fascinating: Bacon gave us a blueprint for navigating the challenges of knowledge in an age of overwhelming information. His core message wasn't about what to learn, but how to learn – with purpose, criticality, and a grounding in reality.

I often find myself accumulating more technical books and papers than I can realistically read, which used to make me feel guilty. But Bacon's perspective is actually liberating - it's not about consuming everything, but about engaging deeply with what matters. In an era where AI can instantly surface any information, the difference between shallow browsing and genuine understanding becomes the critical factor.

I'm not against AI tools - I use them regularly. But there's a clear distinction between using AI as a substitute for understanding versus using it as a tool to enhance learning. When I ask AI to generate code without understanding the implementation, I might ship faster but build technical debt. When I use it to explore approaches while maintaining fundamental knowledge, I become a more effective engineer.

As these tools become more integrated into our workflows, Bacon's principles serve as a practical framework for ensuring we're using technology to augment rather than replace our thinking. Getting information is now trivial. The challenge - and what separates good engineers from great ones - is developing the judgment to use that information effectively.

Dig Deeper

• The Source: Of Studies by Francis Bacon

• Learn How to Learn: Learning How to Learn: Powerful mental tools to help you master tough subjects (Coursera Course)

Share Your Thoughts

I'd love to hear how you're navigating this new landscape. Share your experiences in the comments:

• How is AI changing your approach to learning?

• Which of Bacon's ideas – delight/ornament/ability, weigh/consider, experience – hits home most for you when using AI?

• Do you have specific practices for maintaining deep understanding while leveraging these tools?

Leave a comment

How I Developed This Approach

Key Principle: "An AI assistant is neither omniscient nor deficient—it simply reflects the quality and clarity of the context you provide it."

After countless hours working with AI coding assistants, I kept hitting the same frustrations. The AI would misunderstand requirements, forget context, or produce inconsistent code.

I needed a better way to collaborate with these tools. Through trial and error, I developed this approach based on a simple insight: AI assistants perform exactly as well as the context you provide them. They're not magical oracles but more like junior developers who need clear guidance and structure.

The Setup Phase: Building Your Foundation

Key Principle: "Invest time in setting clear standards and creating comprehensive documentation upfront—it's the foundation that makes every subsequent interaction with your AI assistant more effective."

I start by establishing a solid foundation. This is a one-time investment that pays dividends throughout the project.

Project Repository Configuration

First, I set up the technical infrastructure:

• A GitHub repository with branch protection rules

• PR templates aligned with quality standards

• CI/CD pipelines for automated testing

• Static type-checking configuration (TypeScript, mypy, etc.)

The Four Guidance Documents

The heart of this approach is creating four comprehensive documents:

1. Project Overview

   • High-level description of what we're building and why

   • Business objectives and core functionality

   • High-level description of various sub-systems and components

2. Technical Architecture (as an architect)

   • Coding standards and style guidelines

   • Design principles (SOLID, YAGNI, DRY)

   • Implementation patterns to follow

   • Technology stack with specific version requirements

   • Design Philosophy

3. Testing Guidelines (as a tester)

   • Test strategy and coverage requirements

   • Unit test structure and patterns

   • Edge cases to consider and handle

   • Integration testing approach

4. Product Management (as a product manager)

   • Prioritization guidelines

   • Iterative approach explanation

   • Risk management strategy

   • Strategy to break the project into atomic, achievable, and working milestones

These guidance documents are configured as automated context in my AI tools. In Cursor, add them to .cursor/rules or .windsurfrules in Windsurf so they're automatically included in every session. This ensures your standards are consistently applied across all AI interactions without manual copy-pasting.

The Development Cycle: Plan, Implement, Document

Key Principle: "Never write a line of code until you've achieved complete alignment on what you're building—misunderstandings corrected during planning cost minutes, while those caught during implementation cost hours."

For each task, I follow a consistent process:

Phase 1: Documentation Planning Phase

Key Principle: "The documentation plan is your shared mental model with the AI—refine it until there's zero ambiguity, then use it as a portable context across tools and sessions."

Before writing any code, I work with the AI to create a detailed implementation plan document. This serves multiple purposes:

• Clarifies requirements - The back-and-forth forces me to be precise

• Verifies AI understanding - I can see if the AI has misunderstood anything

• Creates portable context - I can move this between different AI tools or sessions

• Manages context window limitations - Distills essential information into a compact form

I iterate on this plan until I'm 100% aligned with the AI's understanding. Sometimes, this takes several revisions, and that's fine—it's much cheaper to fix misunderstandings here than after the code is written.

Subscribe now

Why This Planning Phase Is Worth It

The documentation planning phase might seem tedious, but it addresses the core limitations of current AI tools:

• Context window limitations - Most AI assistants have limited memory

• Tool-switching - Moving between Cursor, ChatGPT, Claude, etc., loses context

• Misalignment - AI might think it understands requirements when it doesn't

Phase 2: Implementation Phase

Key Principle: "With thorough planning complete, implementation becomes verification rather than exploration—your guardrails of static typing and automated tests ensure the code matches your intent."

Only after we're fully aligned does the AI write actual code. Because of our thorough planning, this phase typically goes smoothly:

• The AI implements based on our agreed plan

• Static type checking catches many potential issues

• Tests verify functionality against requirements

• I review the implementation, but most issues are caught during planning

Phase 3: Documentation Update

Key Principle: "Documentation isn't just a record of what you built, but the evolving context that guides what you'll build next—maintain it with the same care you'd maintain production code."

After implementation, I ask the AI to update our documentation:

• Record what we actually built versus what we planned

• Note any deviations and why they occurred

• Update the working document for future milestones

Real-World Results

Key Principle: "Success isn't measured by how intelligent your AI seems, but by how consistently it produces quality code that requires minimal rework—predictability trumps brilliance."

After adopting this approach, I've seen dramatic improvements:

• Code quality is consistently higher

• Iterations are more predictable and quicker

• Context switching between tools doesn't derail progress

• The AI rarely misunderstands requirements

• I spend less time fixing and more time building

The Philosophy Behind This Approach

Key Principle: "Treat AI as a junior engineer that needs context and guidance, not as a magical oracle that should read your mind—the best AI collaborations are structured conversations, not one-off prompts."

The key insight is treating AI as a collaborator, not a magic solution generator. You get much better results by providing clear context, guidelines, and feedback. I've found that most "AI failures" are actually failures of context or instruction.

The AI performs remarkably well when I'm explicit about requirements and design principles. This approach takes the best of human software engineering practices—clear requirements, consistent architecture, test-driven development—and adapts them to the AI-assisted development workflow.

Don’t just take my word for it; try it out yourself!

Key Principle: "Begin with thorough foundation-setting rather than rushing to implement—the time invested in clear documentation and project structure will be returned tenfold through smoother development cycles."

If you want to try this approach:

• Start with creating your four guidance documents

• Break your project into small, focused milestones

• For each milestone, create a documentation plan before any code

• Iterate until you're fully aligned with the AI

• Only then implement, test, and document

The initial setup takes time, but the efficiency gains in development make it worthwhile. You'll find yourself spending less time fixing AI misunderstandings and more time making actual progress.

Remember: the AI is as good as the context you provide it. Give it the right foundation, and it becomes an invaluable partner in your development process.

Quick Update

• Built a working pipeline that transforms articles into audio content

• Restructured the codebase for better maintainability

• Implemented configurable workflows using YAML

• Added support for S3-compatible storage

Here is a podcast version of this article generated via gyandex

New to this series? Check out the first post where I explored why I am building an open-source alternative to NotebookLM.

The Journey So Far

Remember how we talked about information overload in our last post? Well, I've made significant progress in tackling that challenge. Instead of just dreaming about an ideal content consumption tool, we now have a working prototype that does something pretty cool: it turns your reading list into a podcast feed!

What's Working Now

The system can now:

• Take an article link as input

• Process and transform the content

• Generate audio output

• Create a podcast feed that updates automatically with new content

This is particularly exciting because it takes us one step closer to flexible content consumption - a key feature I wanted to expand upon from NotebookLM.

Technical Progress

From Prototype to Production-Ready

The initial prototype lived in a single Jupyter notebook. Now, it's evolved into a structured project with dedicated modules.

Before:
main.ipynb

After:
gyandex
├── __init__.py
├── cli
│   ├── __init__.py
│   └── genpod.py
├── llms
│   ├── __init__.py
│   ├── factory.py
│   └── factory_test.py
├── loaders
│   ├── __init__.py
│   ├── factory.py
│   └── factory_test.py
└── podgen
    ├── __init__.py
    ├── config
    │   ├── __init__.py
    │   ├── loader.py
    │   ├── loader_test.py
    │   └── schema.py
    ├── engine
    │   ├── __init__.py
    │   ├── generator.py
    │   ├── publisher.py
    │   ├── publisher_test.py
    │   ├── synthesizer.py
    │   ├── synthesizer_test.py
    │   └── workflows.py
    ├── feed
    │   ├── __init__.py
    │   ├── generator.py
    │   ├── generator_test.py
    │   ├── models.py
    │   └── models_test.py
    ├── processors
    │   ├── __init__.py
    │   └── tts.py
    └── storage
        ├── __init__.py
        ├── factory.py
        ├── factory_test.py
        ├── s3.py
        └── s3_test.py

It seems a bit daunting, but that is also the reason why I had to do this now because having everything in a notebook was no longer sustainable.

Configurable Workflows

Configuration is now managed through YAML files, making it easier to control the entire process. The system supports environment variables for secure credential management.

Here's a simplified example:

version: "1.0"
content:
  source: "https://www.rubick.com/skip-level-1-on-1s/"
  format: "html"

llm:
  provider: "google-generative-ai"
  model: "gemini-1.5-pro"
  temperature: 1.0
  google_api_key: "${GOOGLE_API_KEY}"

tts:  # This section isn't hooked up properly yet
  provider: "aws"
  default_voice: "default_host"
  voices:
    default_host:
      voice_id: "Matthew"
      speaking_rate: 1.0
      pitch: 0
    guest:
      voice_id: "Joanna"
      speaking_rate: 1.1
      pitch: 1

storage:
  provider: "s3"
  access_key: "${ACCESS_KEY_ID}"   # This is valid because the configuration format accepts environment variables
  secret_key: "${SECRET_ACCESS_KEY}"
  bucket: "gyandex"
  region: "us-east-1"
  endpoint: "https://xxx.r2.cloudflarestorage.com"
  custom_domain: "pub-xxx.r2.dev"

feed:
  title: "Gyandex: Tech Reading"
  slug: "reading-list"
  description: "Technical reading list curated by Dhruv Baldawa"
  author: "Dhruv Baldawa"
  email: "test@example.com"
  language: "en"
  categories: ["Technology", "Software Development", "Programming"]
  image: "https://images.pexels.com/photos/26730962/pexels-photo-26730962.jpeg?cs=srgb&dl=pexels-helloaesthe-26730962.jpg&fm=jpg&w=640&h=960"
  website: "https://github.com/dhruvbaldawa/gyandex"

I built a companion CLI (podgen) which can run the entire workflow using this configuration. I plan to create separate configuration files for different use-cases and their own customizations. For example, I’d like to have different podcast structure for technical articles vs philosophical ones.

podgen reading-list.yaml

For now, the feeds are powered by a local SQLite database. I will be iterating on my choice of data store throughout this project.

Learning Journey

While this update focused more on infrastructure than innovation, I discovered Meta's NotebookLlama - a toy example with similar goals. I'm looking forward to exploring their approach in future updates.

Next Steps

1. Content Processing Improvements

   • Current focus: Enhancing the quality of generated content

   • Exploring better approaches for longer articles and creating high-quality podcasts

2. Configuration Enhancements

   • Expanding YAML configuration options

   • Implementing more control over the text-to-speech process, which does not exist right now

Building in Public

I'm sharing this journey to document my learning about Generative AI and hopefully help others who are interested in similar projects. Each update brings new insights about both the technical challenges and the practical applications of current AI capabilities.

• LinkedIn update

• Source code: https://github.com/dhruvbaldawa/gyandex

• Pull request for this update: https://github.com/dhruvbaldawa/gyandex/pull/1

Subscribe now

As a developer passionate about AI and content consumption, I've embarked on an exciting journey to build in public - creating an open-source alternative to NotebookLM, gyandex. This project isn't just about coding; it's about exploring the fascinating world of Generative AI and sharing my learnings along the way.

Subscribe now

The Challenge of Modern Content Consumption

We live in an age of information overflow. Like many of you, I subscribe to numerous newsletters and constantly battle with my inbox full of unread articles. Despite my genuine interest in these topics, finding the time to read everything has become increasingly challenging.

This is where the magic of Generative AI comes in. Through AI-powered content transformation, I've discovered a way to consume 80% of my content in just 5% time. It's not just about speed - it's about adapting content to fit how I’d like to consume it.

Why Another NotebookLM?

NotebookLM has been my go-to tool for various use cases - from researching baby strollers to reading technical papers and even debugging production incidents. It's an impressive tool, but as a developer, I've often found myself wanting more flexibility and customization options.

Instead of waiting for these features, I decided to build them myself. Why? Because sometimes the best way to understand and improve upon a tool is to rebuild it from scratch. Plus, it's an excellent opportunity to dive deep into the latest developments in Generative AI.

The MVP: From Text to Talk

For the initial version, I'm focusing on a specific yet powerful feature: transforming web articles into podcasts. The goal is to create a system that can:

• Clean and extract content from web articles

• Generate engaging podcast scripts

• Convert these scripts into high-quality audio

• Package everything into a podcast feed format

Current Progress

The initial prototype is already functional:

1. Content Extraction: Using jina.ai APIs for clean, accurate web content extraction

2. Script Generation: Implementing Gemini Pro APIs to transform articles into natural-sounding podcast scripts (currently well within the free tier limits)

3. Audio Synthesis: Utilizing Google Cloud Text-to-Speech APIs for high-quality audio generation

Demo

Generated podcast for The Right Kind of Stubborn by Paul Graham

Generated podcast for Manage your priorities and energy by @lethai

What's Next on the Roadmap

The project is evolving rapidly, with several key developments planned

1. Code Architecture Refinement

   • Moving from Jupyter notebooks to Python modules

2. Improve usability

   • Developing a flexible CLI interface

   • Creating YAML-based configuration profiles for different podcast profiles

   • Supporting different content transformation strategies

3. Podcast Integration

   • Implementing podcast feed generation

   • Adding metadata management

   • Ensuring compatibility with popular podcast apps

Follow the Journey

Check out the next article in this series

This is just the beginning of what I hope will become a valuable tool. I'm building this in public because I believe in the power of community feedback and collaborative learning.

Whether you're interested in Generative AI, content transformation, or just looking for better ways to consume information, I invite you to follow along this project.

Stay tuned for more updates as we continue to develop and refine gyandex!

I taught myself programming when I was eight years old. My first language was Actionscript in Adobe (then Macromedia) Flash; I learned it because I wanted to build games. Over the years, I've taught myself a variety of programming languages and frameworks. Along this journey, I've discovered strategies that have helped me learn and master some of these tools.

In this post, I will discuss about Repetition.

Repetition in learning is a powerful tool. It involves exposing oneself to the same information or activity repeatedly, leading to enhanced memory retention and skill acquisition. This method, though simple, can yield remarkable results.

It's based on the principle that the more frequently a neural pathway is used, the stronger it becomes, making recall or performance easier and more efficient.

In practice, I employ repetition in various ways. For instance, if I am trying to learn a new programming language like Rust, I don't limit myself to just one source. I read multiple articles and books, watch videos, or listen to podcasts that are all about 'Introduction to Rust'. I repeat this process until I am comfortable with my level of understanding.

Benefits

Spaced Repetition

Reviewing a similar piece of content multiple times helps build solid foundations and promote long-term retention.

Natural Selection

Through continuous exposure and practice, the most effective and resilient ideas are retained and reinforced, helping to solidify the knowledge foundations. It's like the survival of the fittest in the learning world, where the most useful and applicable ideas are the ones that stick.

Serendipity

Sometimes, I stumble upon brilliant ideas or insights unexpectedly, which adds excitement and depth to my learning. The unexpected discovery of valuable ideas or insights makes the process more engaging. It's the happy accident of stumbling upon a significant connection or understanding that wasn't the initial focus of the learning activity. This adds an element of surprise and innovation, making it potentially more effective.

Closing Thoughts

It is time-consuming, but getting good at anything takes time—we all know this1. I enjoy the journey rather than focus on the outcome.

I highly recommend checking out the 'Learning How To Learn' free course on Coursera. This course provides valuable insights about repetition, among other key learning principles.

I will discuss other strategies in future posts. Stay tuned.

What learning strategies have you found to be the most effective? I'd love to hear your experiences and insights.

Leave a comment