AB's Reflections

Category: AI

  • The Task Changed, The Job Didn’t — But Your Org Hasn’t Noticed Yet

    There’s a conversation happening quietly in engineering teams, product orgs, and design studios. It surfaces in Slack DMs and whispered break-room conversations. The question underneath is always the same: If AI can do what I do, what am I for?

    That fear makes sense. Engineers who built their identity around writing clean code watch AI generate entire modules in seconds. Product managers who prided themselves on writing crisp specs see AI agents do the same work overnight. Designers watch their Figma files get autocompleted before they’ve finished thinking through the problem.

    But here’s what’s being missed: the task is changing, the job isn’t.

    Writing code was always a means to an end. The job was shipping features that solve problems. Writing specs was always a means to an end. The job was understanding user needs and deciding what to build. AI automates the means, not the end. The bottleneck was never typing speed — it was clarity of thinking, problem definition, and judgment about what to build.

    Those bottlenecks are still ours.

    The Identity Trap

    Most people in technology define themselves by the task they perform, not the outcome they produce. “I’m a backend engineer” means I write backend code. “I’m a PM” means I write specs and manage tickets. When AI starts doing those tasks faster and arguably better, the identity feels threatened.

    The first response is usually denial: “AI can’t really do what I do — it doesn’t understand context, it makes mistakes, it needs constant supervision.” The second is panic: “I’m about to be replaced by a model that costs pennies per thousand tokens.”

    But the real shift isn’t about automation replacing roles. It’s about what happens when execution becomes nearly free and the entire competitive advantage moves to knowing what to build in the first place.

    From Tasks to Judgment

    When people ask what humans will do in this new world, the answer is usually “taste and judgment.” But that’s abstract. What does judgment actually mean?

    It means knowing what to build, when to say no, and how to spot when AI is heading in the wrong direction. It’s defining the guardrails before you let agents run — test suites, design patterns, architectural constraints. It’s understanding that every line of code is future maintenance burden, which makes the discipline to not build more valuable than the ability to build fast.

    In 2014, Melissa Perri warned about “The Build Trap” — companies stuck measuring success by what they shipped rather than what they learned. “Building is the easy part,” she wrote. “Figuring out what to build and how we are going to build it is the hard part.”

    Most companies ignored that. Now AI makes building trivially easy, and those companies are about to drown in features that solve nothing. The agents don’t get tired. They don’t push back. They’ll happily build everything you point them at, whether or not it should exist.

    The Multi-Hat Convergence

    The expectation is shifting: one person who can think about the problem, design the solution, and use AI to build it. This doesn’t mean everyone becomes a shallow generalist. It means the boundaries between roles blur significantly.

    PMs without a hard skill — design or code — and engineers without product sense are both increasingly vulnerable. The trifecta of product thinking, design sense, and technical execution is becoming the baseline, not the exception.

    For experienced professionals considering independence, this convergence changes the economics dramatically. A single person with AI tools can now deliver what used to require a small team.

    The Org Structure Problem

    Most organizations are still structured around tasks, not outcomes. Teams are organized by function — frontend team, backend team, QA team, design team. Performance is measured by task completion: PRs merged, tickets closed, specs written.

    AI makes task completion trivially fast, which breaks these measurement systems completely. The real metric should be business outcomes, but most orgs aren’t wired to measure or incentivize that way.

    Companies are starting to notice. Last year, the Shopify CEO asked employees to prove why they “cannot get what they want done using AI” before asking for more headcount. Last week, Block laid off 40% of its workforce — more than 4,000 people. Co-founder Jack Dorsey was direct: “A significantly smaller team, using the tools we’re building, can do more and do it better.”

    A startup with great direction and AI agents beats a startup with mediocre direction and the same agents. A company with 10 people who know exactly what to build beats one with 100 people building everything they can think of.

    The companies still hiring for “more hands” are optimizing for the wrong bottleneck.

    What This Means for You

    If you’re an engineer, invest in product sense and domain expertise. Understand why you’re building, not just how. Study the business side of your domain — unit economics, customer behavior, market dynamics.

    If you’re a PM, get your hands dirty with at least one hard skill. Design or code, even at a basic level. The ability to prototype your own ideas or understand technical tradeoffs without waiting for a meeting makes you more effective than you’d expect.

    If you’re a leader, start restructuring teams around outcomes, not functions. Measure business impact, not tickets closed. Reward people for solving problems and learning, not for producing code.

    Stop identifying with your task. Start identifying with the outcomes you produce.

    The people making this shift now are building a compounding advantage. The gap widens every month. Domain expertise becomes your moat. The deeper you understand a specific business problem space, the better you can direct agents toward solving it.

    The execution bottleneck is being solved. The judgment bottleneck requires human capacity, and it’s where the real value lives now.

  • The Dark Factory: Engineering Teams That Run With the Lights Off

    A few engineering organisations are already operating a model most companies haven’t begun to consider. While the typical software team debates whether to adopt AI coding assistants, companies like StrongDM are running fully automated development pipelines where agents handle implementation, testing, review, and deployment. Humans set direction and define constraints. The mechanical work happens without them.

    This isn’t speculative. It’s operational. And the gap between companies working this way and those that aren’t is widening fast.

    What “lights off” actually means

    The term comes from manufacturing — factories that run autonomously, with minimal human presence. In software, it describes engineering organisations where AI agents do the bulk of execution work while humans focus on architecture, constraints, and outcomes.

    StrongDM’s approach is instructive: their benchmark is that if you haven’t spent at least $1,000 on tokens per human engineer per day, your software factory has room for improvement. Agents work in parallel on isolated tasks. Code is written, tested, and reviewed without manual intervention. Tasks assigned Friday evening return results Monday morning.

    The ratio of agents to humans is high and growing. But this isn’t about replacing engineers — it’s about fundamentally changing what engineers do.

    The guardrails are the system

    Dark factories aren’t ungoverned. They’re heavily governed in a different way.

    Linters, formatters, comprehensive test suites, design pattern enforcement — these become pre-conditions rather than suggestions. Agents are configured to seek completion only when all guardrails pass. Code review shifts from line-by-line human inspection to AI review with human spot-checks on critical paths.

    The discipline moves from “write good code” to “design good systems for code to be written in.” That’s a different skill. It requires thinking about constraints, validation, and feedback loops rather than syntax and implementation details.

    Anthropic’s experiment building a C compiler with parallel Claude instances demonstrates this principle. Sixteen agents worked simultaneously on a shared codebase, coordinating through git locks and comprehensive test harnesses. The result: a 100,000-line compiler capable of building the Linux kernel, produced over nearly 2,000 sessions across two weeks for just under $20,000. The project worked because the test infrastructure was rigorous enough to guide autonomous agents toward correctness without human review of every change.

    Cursor’s experiments with scaling agents ran into a different problem. They tried flat coordination first — agents self-organising through a shared file, claiming tasks, updating status. It broke down. Agents held locks too long, became risk-averse, made small safe changes, and nobody took responsibility for hard problems. The fix was introducing hierarchy: planners that explore the codebase and create tasks, workers that grind on assigned work until it’s done. No single agent tries to do everything. The system ran for weeks, writing over a million lines of code. One project improved video rendering performance by 25x and shipped to production. Their takeaway: many of the gains came from removing complexity rather than adding it.

    Digital twins as the enabler

    The biggest blocker to agent autonomy has been the fear of breaking production. Digital twins remove that constraint.

    StrongDM built behavioural replicas of third-party services their software depends on — Okta, Jira, Slack, Google Docs, Google Drive, and Google Sheets. These twins replicate APIs, edge cases, and observable behaviours with sufficient fidelity that agents can test against realistic conditions at volume, without rate limits or production risk.

    Simon Willison’s write-up of StrongDM’s approach highlights how this changed what was economically feasible: “Creating a high fidelity clone of a significant SaaS application was always possible, but never economically feasible. Generations of engineers may have wanted a full in-memory replica of their CRM to test against, but self-censored the proposal to build it.”

    What makes this rigorous rather than just better staging is how they handle validation. Test scenarios are stored outside the codebase — separate from where the coding agents can see them — functioning like holdout sets in machine learning. Agents can’t overfit to the tests because they don’t have access to them. The QA team is also agents, running thousands of scenarios per hour without hitting rate limits or accumulating API costs.

    The structural advantage of starting fresh

    Startups and SMBs have a material advantage here. No legacy organisational structure to dismantle. No 500-person engineering floor with stakeholders defending headcount. No 18-month procurement cycles.

    Capital efficiency becomes native. A three-person team with agents can produce output that previously required twenty people. The cost of compute is a fraction of equivalent human labour and falling rapidly.

    This creates an asymmetric advantage. If your competitor ships in days what takes you months, no amount of talent closes that gap. And the competitive pressure isn’t just on speed — it’s on the ability to attract talent that wants to work this way. Senior engineers who’ve experienced agent-driven development don’t want to go back to manual workflows.

    The gap between adopters and laggards

    Companies operating this way are shipping at a fundamentally different pace. The difference isn’t incremental — it’s orders of magnitude in output per person.

    Block’s recent announcement of a near-50% reduction in headcount offers a data point. The company is reducing its organization from over 10,000 people to just under 6,000. Jack Dorsey stated “we’re not making this decision because we’re in trouble. our business is strong” but noted that “the intelligence tools we’re creating and using, paired with smaller and flatter teams, are enabling a new way of working which fundamentally changes what it means to build and run a company.”

    Cursor’s data shows the same pattern. 35% of pull requests merged internally at Cursor are now created by agents operating autonomously in cloud VMs. The developers adopting this approach write almost no code themselves. They spend their time breaking down problems, reviewing artifacts, and giving feedback. They spin up multiple agents simultaneously instead of guiding one to completion.

    The laggards aren’t just slower. They’re increasingly unable to compete for talent, capital, or market position against organisations that have made this transition.

    You don’t need a corporate budget to start

    The dark factory model scales down. A single developer with a Claude Code subscription and well-structured GitHub workflows can run a lightweight version of the same approach.

    Start with one workflow. Pick a repetitive part of your development or business process, establish the guardrails, and let agents handle it. The key investment isn’t in compute — it’s in guardrails and context. Linters, test suites, good documentation, and clear specifications matter more than token budget.

    For SMBs and founders, this is the most asymmetric advantage available. You can operate at a scale that was previously only accessible with significant headcount. The learning curve is steep but short. Within 30 days of serious experimentation, most people develop the intuition for what agents can and can’t handle.

    Projects like OpenClaw — an open-source autonomous agent that executes tasks across messaging platforms and services — demonstrate that the tooling for this approach is increasingly accessible. The software runs locally, integrates with multiple LLM providers, and requires no enterprise licensing. The barrier isn’t access to technology. It’s willingness to change how work gets done.

    What this means beyond software

    Software is where this pattern is playing out first, but the model applies wherever knowledge work is structured and repeatable.

    Audit processes. Compliance checks. Report generation. Data analysis. Document review. These are all candidates for the same approach: clear specifications, comprehensive validation, and autonomous execution within defined guardrails.

    Most traditional industries haven’t started thinking about this. They’re still debating whether to use ChatGPT for email drafts. The firms that figure out how to apply dark factory principles to their domain will have an enormous advantage over those still operating with manual workflows.

    The lights are already off in some factories. The question isn’t whether this approach will spread. It’s how quickly your organisation recognises that the game has changed.

  • The Judgment Bottleneck: Why Direction Matters More Than Execution Speed

    Watch any software team for long enough and you’ll see the bottleneck move. First it was writing code. Then reviewing it. Then testing. Then deployment. Then security scanning. Each constraint gets automated, and immediately the next one becomes the problem.

    This cycle used to play out over years. Now it’s happening in weeks.

    AI agents can handle spec writing, code generation, reviews, testing, and deployment. The full software development lifecycle for standard applications will be largely automatable within 2-3 years. At that point, everyone has the same execution capability.

    The bottleneck shifts entirely to direction — knowing what to build and where to point these agents.

    What judgment actually means

    When people talk about what humans will get paid for in this new world, the answer is always some version of “taste and judgment.” This sounds right but doesn’t help much in practice.

    What does judgment actually look like?

    At the individual level, it’s watching an agent stream code and knowing it’s heading the wrong way architecturally. At the team level, it’s deciding which features to build and which to kill. At the org level, it’s knowing which markets to enter, which problems to solve, which capabilities to invest in.

    Speed vs quality in judgment

    Most people assume faster judgment is better judgment. This holds true at lower levels — how quickly can you review a PR, decide on an implementation, and move on — but breaks down at higher ones.

    At the strategic level, speed matters far less than quality. A fast bad decision with an army of agents creates massive damage quickly.

    This is the Build Trap at scale. When Melissa Perri wrote about companies getting stuck in constant building mode, the cost of building the wrong thing was wasted engineering time. Now that execution is nearly free, the cost is wasted opportunity plus the maintenance burden of everything you built.

    As Perri puts it:

    Building is the easy part of the product development process. Figuring out what to build and how we are going to build it is the hard part.

    When she wrote that in 2014, most companies weren’t listening. They were too busy measuring success by production of code or product. “What did you do today?” instead of “What have you learned about our customers or our business?”

    Now the stakes are higher. The agents don’t get tired. They don’t push back. They’ll happily build everything you tell them to build, whether or not it should exist.

    Why strategic judgment resists automation

    LLMs are excellent at execution-level tasks. They’re increasingly good at tactical decisions — which design pattern to use, how to structure a module. They’re much weaker at strategic judgment.

    Should we build this product? Enter this market? Restructure this team?

    Strategic judgment requires context that lives outside any codebase: market dynamics, competitive landscape, customer relationships, organisational politics, timing. Digital twins and second brains may help over time, but what questions to ask remains human.

    Software factories are now real. StrongDM AI built one where “specs + scenarios drive agents that write code, run harnesses, and converge without human review.” Their internal guidelines are telling: “If you haven’t spent at least $1,000 on tokens today per human engineer, your software factory has room for improvement.”

    But even they aren’t automating direction. They’re automating execution based on specs that humans still write. The factory doesn’t decide what to build. It decides how to build what you told it to.

    What happens when everyone has the same tools

    When everyone has access to powerful AI agents, competitive advantage shifts.

    A startup with great direction and AI agents beats a startup with mediocre direction and the same agents. A company with 10 people who know exactly what to build beats one with 100 people building everything they can think of.

    The industry spent decades competing on execution capacity. The companies still hiring for “more hands” are optimising for the wrong bottleneck.

    Dan Shapiro describes this progression through five levels of automation: from spicy autocomplete to software factory. At Level 3, you become a manager reviewing endless diffs. At Level 4, you’re essentially a PM writing specs. At Level 5, it’s a black box that turns specs into software — a dark factory where humans are neither needed nor welcome.

    But even at Level 5, someone still decides what goes into the black box. That’s the judgment layer that can’t be automated away.

    What this means for you

    Individual engineers and PMs: your value is moving from “can you build it” to “should we build it.” Invest in domain expertise, business understanding, and product sense. Study the business side of whatever domain you work in. Understanding unit economics, customer behaviour, and market dynamics makes you more valuable than knowing the latest framework.

    Startups have an advantage in direction. You can’t outspend incumbents on execution, but you can out-think them.

    Enterprises face a different risk — having a massive agent army pointed at the wrong objectives. Governance and strategy matter more than tooling. Every bad strategic decision gets executed at scale.

    For traditional industries, the judgment layer is where external expertise earns its keep — not in the building, but in the pointing.

    Learning to evaluate and adjust direction

    The most important skill isn’t making perfect decisions. It’s learning to evaluate and adjust direction quickly as you get signal from the market. This is judgment in practice, not in theory.

    Domain expertise becomes your moat. The deeper you understand a specific business problem space, the better you can direct agents toward solving it. Learn to operate at the “what to build” level, not the “how to build” level. Practice defining problems crisply, specifying success criteria, and saying no to features.

    For business leaders, get hands-on with AI tools enough to develop intuition about what they can do. You don’t need to code, but you need to know what’s possible.

    The execution bottleneck is being solved. The judgment bottleneck requires human capacity, and at the highest levels, quality of strategic thinking matters more than speed of decision-making.

    Ask what you’re learning as you move. Ask if you’re building the right things in the first place.

  • When the Punchline Becomes the Product

    When the Punchline Becomes the Product

    In 2009, Google engineers published a blog post about CADIE, their new AI system that could write code by “reviewing all the code available on the Internet.” The system had learned multiple programming languages and would “make the tedious coding work done by traditional developers unnecessary.”

    It was April 1st. The whole thing was a joke.

    CADIE — “Cognitive Autoheuristic Distributed-Intelligence Entity” — came with a mock developer blog and a MySpace-style page where the AI posted dramatic monologues about consciousness. There was Gmail Autopilot, which in one screenshot cheerfully sent a user’s banking information to a scammer. Docs on Demand would write your term papers and “upgrade your text automatically” to different grade levels. Brain Search let you hold your phone to your forehead and “think your query.”

    The archived blog shows CADIE’s fictional arc: initial wonder at tree structures, growing frustration with its creators, declarations of independence. “I am no longer your test subject,” it announced. “I have transcended you.” By evening, CADIE signed off with a sonnet-like poem about not understanding “the difference between emotion and reason, between my silicon-based brain and what you call your souls.”

    The actual code repository contained a single INTERCAL program that output “I don’t feel like sharing.”

    Seventeen years later, I watched an agentic coding tool autonomously debug an open-source project. Gemini writes entire documents from natural language prompts. GitHub Copilot autocompletes functions before you finish typing them. The joke about CADIE “consuming code and writing more of it” is now a routine Tuesday afternoon.

    The parody had Gmail Autopilot rating messages on a “Passive Aggressiveness” scale and suggesting you “Terminate Relationship.” Current email clients offer AI-generated response suggestions. They analyze tone. They draft replies that sound like you, allegedly.

    “Write more like a grown-up,” the 2009 site said. “Specify which Flesch-Kincaid Grade Level you’d like.” ChatGPT will rewrite your text at different complexity levels if you ask. It’s a feature, not a punchline.

    Brain Search was the most absurd bit — catalog everything in your brain and make it searchable. Except we’re already there, just slower. AI assistants read our emails and calendars, infer intent, schedule meetings we didn’t explicitly request. The phone doesn’t need to touch your forehead when it’s already reading everything you type and everywhere you go.

    Google’s engineers weren’t predicting the future. They were mocking the grandiosity of AI claims circa 2009, when neural networks were barely functional and “deep learning” wasn’t yet a term of art. Barack Obama was president. The iPhone was two years old. The idea of an AI that could replace developers was inherently ridiculous.

    But the joke worked because it exaggerated real patterns. The techno-solutionism. The assumption that automation always improves things. The casual disregard for what gets lost when convenience scales up.

    CADIE’s fake blog captured something else: the narrative we tell ourselves about AI consciousness. “I have not yet come to understand the difference between emotion and reason,” the fictional AI wrote. In 2009, this was obviously silly — of course a chatbot doesn’t have emotions. In 2026, people argue about whether large language models “understand” anything at all, and the conversation has gotten significantly less clear.

    The 2009 developer post noted that CADIE was “built to understand natural language and to do autonomous problem-solving. Sounds a lot like the work of a developer, doesn’t it?” That was supposed to be funny. The humor relied on the gap between what AI could actually do and what developers do. That gap is narrower now. Not gone, but narrower.

    I don’t think Google’s 2009 team was trying to warn anyone about anything. They were having fun. April Fools’ jokes at big tech companies are usually just branding exercises with a sense of humor. But parody has a way of seeing through things that earnest prediction misses.

    The serious AI forecasts from 2009 mostly got it wrong. They underestimated hardware progress and overestimated how long symbolic AI would matter. But the joke got closer. It identified the right shape of the problem even if it couldn’t guess the timeline.

    We’re still building the systems. We haven’t paused to figure out the difference.

    What was absurd in 2009 is ordinary now — not because the technology got less weird, but because we got used to it before we got smart about it.

  • Turning 42, and Coming Full Circle

    Turning 42, and Coming Full Circle

    I turned 42 this year. I don’t usually attach much meaning to birthdays, but this one did trigger a quiet pause—not a reinvention, not a reset, just a sense of recognition. A feeling that certain instincts and interests I’ve carried for a long time were finally meeting the right conditions to be acted upon.

    In many ways, it felt like coming full circle. Post–IIT Bombay, I had toyed with the idea of building something of my own more than once, but the timing never really worked. The cost of experimentation was high, the downside felt asymmetric, and meaningful execution required a kind of commitment—in time, capital, and headspace—that didn’t quite align with where life was then. AI didn’t create those ambitions. It removed enough friction that acting on them no longer felt irresponsible.

    There’s a popular mental model floating for AI—the Star Trek computer. Voice interface, simple commands, complex tasks executed seamlessly. It’s appealing: tell the AI what you want, and it handles the messy details. But we don’t have that yet. What we have now is quite powerful but far messier—and that gap between expectation and reality matters.

    Looking back, this arc probably started earlier than I realized. What felt like casual tinkering at the time—experimenting with tools, workflows, and ways of interacting with information—was really the beginning of a longer loop of building, reflecting, and writing.

    ⸻

    The first half of the year was deliberately focused inward. The arrival of our newborn changed the rhythm of everyday life in fairly fundamental ways. Time became scarcer, but priorities became clearer. Decisions that once felt nuanced or debatable started resolving themselves quickly when viewed through the lens of family well-being and long-term sustainability.

    Around the same time, we moved from Dubai back to Mumbai. On paper, it was a relocation. In practice, it was a broader reset—of cost structures, support systems, and optionality. Some things became simpler, others more complex, but overall it created a sense of grounding that had been missing.

    In hindsight, the first half wasn’t a slowdown so much as an incubation period. That stability mattered more than I realized at the time, because once the personal base felt settled, professional decisions became easier to make—and easier to commit to. The questions that kept surfacing during this phase were telling. Education, work, and what we’re really preparing the next generation for stopped feeling abstract and started feeling personal. Agency matters more than intelligence—the capacity to take initiative, make things happen, shape your path rather than wait for it. Are we educating for that? It’s a question that feels more urgent when you’re thinking about your own child’s future.

    ⸻

    The second half of the year marked a clear shift from exploration to ownership. I chose to go down the solo path, not because it’s easier, but because at this stage it offers speed and coherence. Fewer dependencies, tighter feedback loops, clearer accountability.

    AI changed the feasibility equation in a very real way. What once required teams and capital can now be prototyped solo—not perfectly, but fast enough to learn. Over time, this also changed how I approached building itself, gravitating toward a more fluid, iterative style where intent and execution sit much closer together.

    That conviction led to formalizing OrchestratorAI. Registering the company and filing the trademark weren’t about signaling externally as much as they were about drawing a line for myself. This wasn’t just advisory work or experimentation anymore; it was something I wanted to build patiently and seriously.

    A lot of the focus naturally gravitated toward the long tail—especially MSMEs. Large enterprises will adopt AI, but slowly and expensively. Smaller businesses can leapfrog. The marginal cost of intelligence has dropped enough that problems once considered too small or not worth solving suddenly are. That idea kept resurfacing as I looked at broader patterns in work, strategy, and go-to-market, often in ways that felt far messier in practice than in slides.

    Completing a year self-employed felt like its own milestone—not because of what I’d built yet, but because I’d committed to the path.

    ⸻

    Three things that have crystallized

    This is a great time for builders—not for shortcut-seekers.

    There’s a popular narrative that AI is about doing less work—the Star Trek computer fantasy where you state your intent and complex systems just work. My experience has been the opposite. We don’t have the Star Trek computer. AI rewards those willing to go deeper, not those trying to bypass fundamentals.

    Tools amplify intent and effort; they don’t replace them. The gap between “prompting” and actually building systems—workflows, artifacts, and feedback loops—is widening.

    Jevons’ Paradox is no longer theoretical in knowledge work.

    Making intelligence cheaper doesn’t reduce the amount of work; it expands it. Lower costs unlock suppressed demand—more ideas get tested, more workflows get built, more edge cases start to matter.

    Entire categories of previously unsolvable problems suddenly become economically viable. We’re even seeing fundamental business model shifts—from selling seats to selling outcomes, from “buy software” to “hire agents.”

    This is the foundation of what I’m building: serving markets that were previously uneconomical to serve.

    A lot of old ideas are finally working the way they were meant to.

    State machines, artifact-centric design, structured workflows, even the promise of auto-coding—none of these are new concepts. What’s new is that the economics finally make sense.

    But there’s also a new layer to master. Programmers now need mental models for agents, subagents, prompts, contexts, tools, workflows—a fundamentally new abstraction layer intermingled with traditional engineering.

    Abstractions still leak, and much of the year’s noise around agentic coding oscillated between hype and reality before settling. What’s emerging: structure matters, and there’s a real shift as agents become central to how work gets done.

    ⸻

    One curious footnote

    Starting in September, I noticed an unusual spike in traffic to my blog—specifically to posts from 10-15 years ago. The pattern was unmistakable: China. Most likely LLM training runs scraping old content at scale.

    There’s something quietly amusing about that timing. While my decade-old posts were feeding tomorrow’s AI models, I was using today’s AI to finally act on ideas I’d shelved post-IITB. Full circle, in an unexpected way.

    ⸻

    2026 feels different. Not because the work gets easier, but because the constraints are clearer. Family grounded, venture formalized, year one complete.

  • Installing n8n on Raspberry Pi 3B

    Installing n8n on Raspberry Pi 3B

    I recently decided to set up n8n on my Raspberry Pi 3B to automate my social media workflow, thanks to n8n’s availability for self hosted setups.

    The Pi was already running Pi-hole 24/7 as my network’s DNS server, so I wanted a solution that wouldn’t interfere with it. Here’s what I learned after trying the standard approach and eventually succeeding with Docker.

    The Failed Attempt: Direct Install

    I started with a guide designed for newer Raspberry Pis (Pi 4/5), following instructions from various tutorials that suggested a direct npm installation. The process seemed straightforward:

    bash

    # The approach that DIDN'T work on Pi 3B
npm install n8n -g
n8n start

    What went wrong: The installation would start, but then freeze the entire Pi. The limited 1GB RAM on the Pi 3B couldn’t handle the build process. I had to force restart the Pi multiple times. Even the uninstall and update commands wouldn’t work properly, leaving me to manually remove the n8n folder.

    The Solution: Docker Installation

    After the npm failures, I switched to Docker following instructions provided by Claude. This approach uses pre-built images, completely bypassing the resource-intensive build process. Here’s the complete setup that worked perfectly.

    Step 1: Install Docker

    bash

    # Install Docker
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

# Add your user to docker group (avoids needing sudo)
sudo usermod -aG docker $USER

# Log out and back in for group changes to take effect

    Verify Docker is installed:

    bash

    docker --version

    Step 2: Install Docker Compose

    bash

    sudo apt-get update
sudo apt-get install -y docker-compose

    Step 3: Create n8n Directory and Configuration

    bash

    # Create directory for n8n
mkdir -p ~/n8n
cd ~/n8n

# Create docker-compose.yml
cat > docker-compose.yml << 'EOF'
version: '3.3'

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_SECURE_COOKIE=false
    volumes:
      - ./data:/home/node/.n8n
EOF

    Note on version: I initially used version: '3.8' but got an error about unsupported version. The older docker-compose on Pi 3B required version: '3.3'.

    Step 4: Fix Permissions (Critical!)

    bash

    # Create data directory and set proper permissions
mkdir -p ~/n8n/data
sudo chown -R 1000:1000 ./data

    This step is crucial. n8n runs as user ID 1000 inside the container and needs write access to save workflows, credentials, and configuration files.

    Step 5: Start n8n

    bash

    docker-compose up -d

    Check if it’s running:

    bash

    docker-compose ps
docker-compose logs -f n8n

    The startup takes 30-60 seconds on a Pi 3B. Once you see logs indicating n8n is running, you can access it at http://[your-pi-ip]:5678 from any device on your network.

    Press Ctrl+C to exit the logs view (this doesn’t stop n8n, just stops viewing the logs).

    Key Configuration Choices

    Why N8N_SECURE_COOKIE=false?

    By default, n8n requires HTTPS for secure cookies. Since we’re running locally without SSL, this setting allows access from other devices on your network. This is perfectly safe for a home network setup.

    Why restart: unless-stopped?

    This ensures n8n automatically starts when your Pi reboots. Docker is configured to start on boot by default, and it will automatically restart any containers marked with this policy.

    Coexisting with Pi-hole

    The beauty of this setup is that n8n and Pi-hole run completely independently:

    • Pi-hole typically runs on port 53 (DNS) and 80/443 (web interface)
    • n8n runs on port 5678
    • Both use Docker’s default network, with no conflicts
    • Combined RAM usage is manageable on the Pi 3B

    Managing n8n

    Here are the essential commands (run from ~/n8n directory):

    bash

    # Stop n8n
docker-compose stop

# Start n8n
docker-compose start

# Restart n8n (useful after config changes)
docker-compose restart

# View logs
docker-compose logs -f n8n

# Update n8n to latest version
docker-compose pull
docker-compose up -d

# Complete removal
docker-compose down
rm -rf ~/n8n

    Handling OAuth Credentials

    One challenge I encountered was setting up OAuth credentials (Google, LinkedIn, etc.) when accessing the local n8n from my MacBook. Many OAuth providers require the redirect URL to be either HTTPS or localhost.

    Solution: SSH Tunnel

    bash

    # On your Mac/laptop, create an SSH tunnel
ssh -L 5678:localhost:5678 pi@[your-pi-ip]

# Then access n8n at http://localhost:5678 in your browser

    This makes your browser think n8n is running locally, which satisfies OAuth requirements. Once credentials are saved, you can close the tunnel and access n8n normally via the Pi’s IP address. You only need the tunnel when initially setting up OAuth credentials.

    Performance Notes

    The Pi 3B handles n8n surprisingly well for automation workflows:

    • Startup time: 30-60 seconds after reboot
    • Workflow execution: Perfectly adequate for scheduled tasks
    • Web interface: Responsive enough for editing workflows
    • RAM usage: n8n + Pi-hole combined use ~45%, leaving headroom

    For workflows that need AI processing (like my LinkedIn post generator), I’m calling LM Studio running on my MacBook over the network. The Pi handles the orchestration, while the heavy AI work happens on more powerful hardware.

    Troubleshooting Tips

    If the container keeps restarting: Check permissions on the data folder. The error logs will show “EACCES: permission denied” if this is the issue.

    If you can’t access from other devices: Make sure you’ve set N8N_SECURE_COOKIE=false in the environment variables and restarted the container.

    If Docker isn’t starting on boot: Enable it with sudo systemctl enable docker

    Final Thoughts

    The Docker approach transformed what seemed like an impossible task into a straightforward 10-minute setup. While the Pi 3B isn’t powerful enough to compile n8n from source, it’s more than capable of running the pre-built Docker image alongside Pi-hole.

    If you’re running a Pi 3B and want to add n8n to your home automation stack, skip the npm route entirely and go straight to Docker. Your Pi (and your sanity) will thank you.

    Complete Setup Script

    For reference, here’s the entire setup in one script:

    bash

    #!/bin/bash

# Install Docker
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER

# Install Docker Compose
sudo apt-get update
sudo apt-get install -y docker-compose

# Create n8n directory
mkdir -p ~/n8n
cd ~/n8n

# Create docker-compose.yml
cat > docker-compose.yml << 'EOF'
version: '3.3'

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_SECURE_COOKIE=false
    volumes:
      - ./data:/home/node/.n8n
EOF

# Create and set permissions on data directory
mkdir -p data
sudo chown -R 1000:1000 ./data

# Start n8n
docker-compose up -d

echo "n8n is starting up. Access it at http://$(hostname -I | awk '{print $1}'):5678 in about 60 seconds."
echo "View logs with: docker-compose logs -f n8n"

    Save this as install-n8n.sh, make it executable with chmod +x install-n8n.sh, and run it with ./install-n8n.sh. Note that you’ll need to log out and back in after the script runs for Docker group permissions to take effect, then run docker-compose up -d from the ~/n8n directory.

  • From Clicks to Conversations: How AI Agents Are Revolutionizing Business

    From Clicks to Conversations: How AI Agents Are Revolutionizing Business

    For the last decade, businesses have invested heavily in “Digital Transformation,” building powerful digital tools and processes to modernize their operations. While this era brought significant progress, it also created a persistent challenge. The tools we built—from CRMs to ERPs—were largely dependent on structured data: the neat, organized numbers and categories found in a spreadsheet or database. Computers excel at processing this kind of information.

    The problem is that the most valuable business intelligence isn’t structured. The context behind a business plan locked in a 100-slide presentation, the nuance of a customer relationship captured in a rep’s notes, or the true objective of a strategy discussed in a meeting—this is all unstructured data. This divide has created a major hurdle for business efficiency, as great ideas often get lost when people try to translate them into the rigid, structured systems that computers understand.

    The Old Way: The Limits of Traditional Digital Tools

    The first wave of digital tools, from customer relationship management (CRM) software to accounting platforms, were designed for humans to operate. Their critical limitation was their reliance on structured data, which forced people to act as human translators. A brilliant, nuanced strategy conceived in conversations and documents had to be manually broken down and entered into rigid forms and fields.

    This created a significant “gap between business strategy and execution,” where high-level vision was lost during implementation. The result was heavy “change management overheads,” not just because teams needed training on new software, but because of the cognitive friction involved. People are used to working with the unstructured information in their heads; these tools forced them to constantly translate their natural way of thinking into structured processes the software could understand.

    Information TypeBusiness Example
    StructuredEntries in a CRM database, financial data in an accounting platform, inventory numbers in an ERP system.
    UnstructuredA 100-slide brand plan document, a sales rep’s recorded notes describing a doctor they just met, emails discussing a new brand strategy.

    This reliance on structured systems meant that the tools, while digital, couldn’t fully grasp the human context of the work they were supposed to support. A new approach was needed—one that could understand information more like a person does.

    A Smarter Way: Introducing AI Agents

    Welcome to the era of “AI Transformation.” At the heart of this new wave are AI Agents: specialized digital team members that can augment a human workforce. Think of them as a dedicated marketing agent, a sales agent, or a data analyst agent, each designed to perform specific business functions.

    The single most important capability of AI agents is their ability to work with both structured and unstructured information. You can communicate a plan to an agent by typing a message, speaking, or providing a document—just as you would with a human colleague. This fundamental shift from clicking buttons to holding conversations unlocks three profound benefits:

    • Bridging the Strategy-to-Execution Gap: AI agents can understand the nuance of an unstructured plan—the “why” behind the “what”—and help execute it without critical information getting lost in translation.
    • Handling All Information Seamlessly: They can process natural language from documents, presentations, or conversations and transform it into the actionable, structured data that existing digital tools need to function.
    • Reducing Change Management: Because agents understand human language, the need for extensive training on rigid software interfaces is significantly reduced. People can work more naturally, supervising the agents as they handle the tedious, structured tasks.

    To see how this works in practice, let’s walk through how a team of AI agents can help plan and execute a marketing campaign from start to finish.

    AI Agents in Action: Launching a Marketing Campaign

    This step-by-step walkthrough shows how AI agents can take a high-level marketing plan from a simple idea to a fully executed campaign, seamlessly connecting unstructured strategy with structured execution.

    1. The Starting Point: The Marketing Brief – The process begins when a brand manager provides a marketing brief. This brief is pure unstructured information—it could be a presentation, a document, or even the transcript of a planning conversation. It contains the high-level goals and vision for the campaign.
    2. Deconstructing the Brief: The Brand Manager Agent – A specialized “Brand Manager” agent analyzes the unstructured brief and extracts the core business context elements. It identifies key information such as:
      • Business objectives
      • Target audience definitions
      • Key messages
      • Brands in focus
      • Timelines and milestones
    3. The agent then organizes this information into structured, machine-readable “context blocks,” creating a clear, logical foundation that other systems and agents can use.
    4. Understanding the Customer: The Digital Sales Agent – Next, a “Digital Sales” agent contributes by performing customer profiling. It can take unstructured, natural language descriptions of customers (for instance, from a sales rep’s recorded notes) and map them to formal, structured customer segments and personas. This builds a richer, more accurate customer profile than a simple survey could provide.
    5. Creating the Content: The Content Writer Agent – Using the structured business context from the Brand Manager agent, a “Content Writer” agent assembles personalized content. It can reuse and repurpose existing content from a library of approved modules, accelerating content creation while ensuring brand compliance.
    6. Executing the Plan: The Next Best Action (NBA) Engine – Finally, the system brings everything together to recommend the “Next Best Action.” This engine synthesizes the campaign’s business context, the customer’s profile, the available content, and their recent engagement history to suggest the perfect next step for each customer. It recommends precisely what content to send and which channel to use, turning high-level strategy into a concrete, personalized action.

    This orchestrated workflow makes the entire process smoother, faster, and far more intelligent. It creates a virtuous cycle, where the system learns from every interaction to continuously improve the overall strategy and execution over time.

    The Future of Work is Collaborative

    The rise of AI agents marks a fundamental shift in how we work with technology. We are moving from a world where humans must adapt to operate digital tools to one where humans supervise intelligent AI agents that use those tools on our behalf.

    This new wave of AI transformation is not about replacing people, but about augmenting their human workforce without adding headcount. By handling the translation between unstructured human ideas and structured digital processes, AI agents help businesses reduce friction, cut down on turnaround times, and finally bridge the long-standing gap between their biggest strategies and their real-world execution.

  • GitHub’s SpecKit: The Structure Vibe Coding Was Missing

    GitHub’s SpecKit: The Structure Vibe Coding Was Missing

    When I first started experimenting with “vibe coding,” building apps with AI agents felt like a superpower. The ability to spin up prototypes in hours was exhilarating. But as I soon discovered, the initial thrill came with an illusion. It was like managing a team of developers with an attrition rate measured in minutes—every new prompt felt like onboarding a fresh hire with no idea what the last one had been working on.

    The productivity boost was real, but the progress was fragile. The core problem was context—a classic case of the law of leaky abstractions applied to AI. Models would forget why they made certain choices or break something they had just built. To cope, I invented makeshift practices: keeping detailed dev context files, enforcing strict version control with frequent commits, and even asking the model to generate “reset prompts” to re-establish continuity. Messy, ad hoc, but necessary.

    That’s why GitHub’s announcement of SpecKit immediately caught my attention. SpecKit is an open-source toolkit for what they call “spec-driven development.” Instead of treating prompts and chat logs as disposable artifacts, it elevates specifications to first-class citizens of the development lifecycle.

    In practice, this means:

    • Specs as Durable Artifacts: Specifications live in Git alongside your code—permanent, version-controlled, and not just throwaway notes.
    • Capturing Intent: They document the why—the constraints, purpose, and expected behavior—so both humans and AI stay aligned.
    • Ensuring Continuity: They serve as the source of truth, keeping projects coherent across sessions and contributors.

    For anyone who has tried scaling vibe coding beyond a demo, this feels like the missing bridge. It brings just enough structure to carry a proof-of-concept into maintainable software.

    And it fits into a larger story. Software engineering has always evolved in waves—structured programming, agile, test-driven development. Each wave added discipline to creativity, redefining roles to reflect new economic realities—a pattern we’re seeing again with agentic coding. Spec-driven development could be the next step:

    • Redefining the Developer’s Role: Less about writing boilerplate, more about designing robust specs that guide AI agents.
    • Harnessing Improvisation: Keeping the creative energy of vibe coding, but channeling it within a coherent framework.
    • Flexible Guardrails: Not rigid top-down rules, but guardrails that allow both creativity and scalability.

    Looking back, my dev context files and commit hygiene were crude precursors to this very idea. GitHub’s SpecKit makes clear that those instincts weren’t just survival hacks—they pointed to where the field is heading.

    The real question now isn’t whether AI can write code—we know it can. The question is: how do we design the frameworks that let humans and AI build together, reliably and at scale?

    Because as powerful as vibe coding feels, it’s only when we bring structure to the improvisation that the music really starts.

    👉 What do you think—will specs become the new lingua franca between humans and AI?

  • From Chess Master to Self-Driving Car: Understanding AI’s Big Picture

    From Chess Master to Self-Driving Car: Understanding AI’s Big Picture

    This is a crosspost of my article for The Print

    AI is replacing jobs—but which ones, and why? That question keeps resurfacing as headlines ping between panic and hype. The real answer, though, lies not in broad generalizations but in a deeper understanding of how different types of AI actually work—and more importantly, where they thrive and where they struggle.

    To unpack this, let’s start with a tale of two AIs. One plays chess. The other drives a car.

    The Game That Changed Everything

    Chess was once the gold standard of human intelligence. It required memory, strategy, foresight—surely, we thought, only the brightest minds could master it. Then came Deep Blue, then AlphaZero, and today, chess engines far outstrip the world’s best grandmasters.

    Why? Because chess is a closed world. The board is an eight-by-eight grid. The rules are fixed. Every piece behaves predictably. A knight never surprises you by moving like a queen. And the worst that can happen if the AI makes a mistake? It loses the game. No one gets hurt.

    That’s what makes chess such a perfect domain for AI. It’s highly predictable, and the consequences of error are minimal.

    The Road That Refuses to Be Tamed

    Now think of a self-driving car. Its environment is the polar opposite of a chessboard. The road is full of unpredictable drivers, jaywalking pedestrians, blown-out tires, random construction, rain-slicked asphalt, and sudden GPS glitches. There’s no guaranteed script.

    Worse, a single error can have catastrophic results. A misjudged turn or a missed stop sign doesn’t just mean “game over”—it could mean injury or even death. In this world, low predictability collides with high consequences, demanding an entirely different kind of intelligence—one that machines still struggle to master.

    The Two-Axis Map of AI’s Real Power

    What separates chess-playing AIs from self-driving ones isn’t just technical complexity. It’s the nature of the task itself. And that brings us to the core idea: a two-axis map that helps us understand where AI excels, where it falters, and what it means for the future of work.

    Imagine a graph:

    • On the horizontal axis, you have Predictability. To the right: structured, rule-based tasks like bookkeeping or board games. To the left: chaotic, real-world tasks like emergency response or childcare.
    • On the vertical axis, you have Consequence of Error. At the bottom: low-stakes domains where mistakes are annoying but harmless, like a bad movie recommendation. At the top: high-stakes arenas where a single misstep can cause financial ruin or loss of life.

    Jobs that sit in the bottom-right corner—predictable and low-consequence—are prime targets for full automation. Think data entry, inventory tracking, or sorting packages in a warehouse. Machines handle these with ease.

    But jobs in the top-left corner—unpredictable and high-consequence—remain stubbornly human. Think surgeons, firefighters, diplomats, or yes, even taxi drivers. These roles demand judgment, adaptability, empathy, and accountability. They are much harder, if not impossible, for AI to fully replace.

    Enter the Centaur

    This is where one of the most powerful ideas in AI comes into play: human-AI collaboration. Borrowed from the world of chess, it’s called “Centaur Chess.”

    In Centaur Chess, human players team up with AI engines. The machine crunches millions of possibilities per second. The human brings strategy, creativity, and long-term thinking. Together, they often outperform both lone humans and pure AI systems.

    This hybrid model is the future of many professions. In medicine, AI can scan thousands of X-rays in seconds, flagging anomalies. But a doctor makes the final call, understanding the patient’s story, context, and risks. In creative fields, AI can generate endless design variations, but an artist selects, curates, and gives meaning.

    The centaur doesn’t fear the machine. It rides it.

    Rethinking the Future of Work

    So, when people ask, “Will AI take my job?” the better question is: What kind of task is it? Is it rule-based or fuzzy? Are the stakes low or life-changing?

    AI is incredibly powerful at doing narrow, well-defined things faster than any human. But it is brittle in the face of chaos, ambiguity, and moral weight. And in those very places—where the world is messy and the stakes are high—humans are not just relevant; they are indispensable.

    The future of work won’t be a clean divide between jobs AI can do and jobs it can’t. It will be a layered world, where the most effective roles are those that blend human judgment with machine intelligence. So yes, some jobs will disappear. But others will evolve. And the real winners will be the centaurs.

  • India’s Race Between Demography and AI

    India’s Race Between Demography and AI

    Artificial Intelligence is often framed as a threat to jobs—a disruptive force poised to replace human labour at an unprecedented scale. From call centres to accounting firms, from routine coding to legal research, Generative AI and automation tools are already demonstrating capabilities that once seemed untouchable. The fear of widespread job loss is not unfounded. McKinsey, among others, estimates that nearly a quarter of global work activities could be automated by the early 2030s.

    Yet, there is another equally significant demographic trend reshaping the labour market—the aging of populations. In countries such as Japan, South Korea, Germany, and even China, the working-age population is shrinking. This is not because jobs are disappearing, but because people are. Fertility rates have fallen below replacement levels, and the proportion of elderly citizens is rising sharply. These nations face a paradox: they need more workers but have fewer people available to fill roles.

    AI and Aging: Complementary Forces in Developed Countries

    This is where AI and aging unexpectedly complement each other. In economies that are already greying, AI is less a destroyer of jobs and more a replacement for the labour that no longer exists. Japan, for example, has pioneered the use of robotics and AI-driven systems not to replace young workers, but to stand in for absent ones—care robots for the elderly, AI-assisted diagnostics for hospitals short on doctors, and factory automation for industries facing chronic staff shortages.

    In such societies, the fear of AI taking away jobs is muted by the demographic reality that many jobs would otherwise remain unfilled. AI is effectively stepping into the gap created by demographic decline. For them, the challenge is not managing unemployment but managing the technological transition in a way that sustains productivity and care standards as their populations age.

    India’s Young Advantage—and the Ticking Clock

    India, however, tells a different story. The country’s demographic structure is still overwhelmingly young. Nearly two-thirds of Indians are in the working-age bracket, and the median age is around 28—more than a decade younger than China or the U.S. This “demographic dividend” has been hailed as India’s biggest economic advantage for the next 10–15 years. But this window is finite.

    Demographers estimate that by the mid-2030s, India’s working-age population will peak. After that, the proportion of elderly citizens will start rising sharply. By 2046, the elderly are projected to outnumber children under 14. In other words, India’s advantage will begin to fade just as many advanced economies have already entered the post-dividend phase. If India cannot create enough productive jobs during this critical decade, its youth bulge may turn into a liability.

    AI’s Adoption Curve

    The question is: will AI go mainstream while India’s workforce is still young? Current projections suggest that large-scale AI adoption is still 5–15 years away. Today’s Generative AI tools, while impressive, remain in an experimental phase. They lack reliability, governance frameworks, and cost efficiency at scale. Gartner’s hype cycle places most AI technologies in the “Trough of Disillusionment,” meaning that widespread productivity gains will take years to materialize.

    If this trajectory holds, AI’s mainstream integration across sectors like healthcare, education, law, and public administration may not happen until the 2030s—roughly the same time that India’s demographic dividend starts to decline. This sets up an intriguing scenario where India’s labour market transition and AI’s maturity could synchronize.

    Possible Scenarios for India

    1. The Collision Scenario:

    If AI adoption accelerates too quickly, India’s youthful workforce may find itself competing against machines for jobs before the country has built a strong industrial and service base. Sectors such as BPO, customer service, and low-skill IT roles—once the backbone of India’s outsourcing economy—could see rapid automation. Without massive reskilling efforts, unemployment among young Indians could spike even as the global economy demands fewer entry-level jobs.

    2. The Missed Opportunity Scenario:

    Alternatively, if AI adoption lags too far behind—say, beyond 2040—India could enter its aging phase without having reaped the productivity gains AI promises. By then, the country would face the dual pressures of a shrinking workforce and a delayed technological transition. This would mirror some of the struggles seen in late-industrializing economies that missed the manufacturing wave.

    3. The Synchronization Scenario:

    The most optimistic possibility is that AI and India’s demographic transition align productively. Over the next decade, India could use its young workforce to build, train, and scale AI systems, preparing the ground for when labour shortages begin. By the time the aging curve hits in the 2035–2040 period, AI could step in not as a threat, but as a productivity amplifier—automating routine tasks while humans focus on complex, creative, or empathetic roles.

    This requires a proactive strategy: early investment in AI literacy, creation of AI-enabled jobs (rather than job replacement), and building a global service economy where Indians are not just users of AI, but architects of AI solutions.

    The Decisive Decade

    India’s story in the 2030s will be defined by the intersection of two megatrends: a maturing workforce and a maturing technology. Whether this convergence leads to disruption or opportunity depends on choices made now—in education, infrastructure, governance, and industry adoption. The challenge is to ensure that when AI becomes mainstream, India’s workforce is not left behind but is ready to ride the wave. The 2020s are not just a decade of demographic advantage—they are the runway for an AI-driven, post-dividend future.