AB's Reflections

Tag: Software Development

  • The AI Stack Is Running on Borrowed Infrastructure — And What Happens When It Isn’t

    The AI Stack Is Running on Borrowed Infrastructure — And What Happens When It Isn’t

    The GPUs running AI workloads today were designed to render video game graphics. The programming languages agents use were built for human readability. The development processes — sprint cycles, code reviews, deployment windows — are all structured around human working hours and attention spans.

    Despite these constraints, AI agents are already building C compilers from scratch for roughly $20,000 in compute costs and consistently outperforming average human engineers on standard tasks. When purpose-built infrastructure arrives, following the same vertical integration pattern we saw transform smartphones, the cost and capability equation changes dramatically. It’s the natural evolution of any technology platform.

    The smartphone parallel: five layers of integration

    Early smartphones ran on repurposed mobile phone hardware with desktop-derived operating systems. They worked, but the architecture was borrowed. Then came the integration layers, each delivering step-change improvements:

    Layer one: Purpose-built mobile operating systems — iOS and Android, optimised for touch interfaces and mobile constraints rather than adapted from desktop paradigms.

    Layer two: Custom silicon designed specifically for mobile workloads. Apple’s A-series chips weren’t just smaller desktop processors; they were architected from the ground up for mobile use cases.

    Layer three: Specialised programming frameworks — Swift and Kotlin — designed for mobile development patterns rather than ported from other contexts.

    Layer four: Cloud-native architectures that assumed mobile-first applications, not desktop apps squeezed onto smaller screens.

    Layer five: An entire ecosystem of services built around mobile devices as the primary platform, from payments to authentication to location services.

    Each layer compounded the improvements of the previous one. The difference between a 2007 iPhone and a 2015 iPhone wasn’t just better specs — it was a fundamentally different platform enabled by vertical integration.

    The AI stack is entering the same progression.

    What purpose-built looks like

    Custom AI chips are already in development. Google’s TPUs, various ASICs, and well-funded startups are working on silicon designed for neural network operations rather than graphics rendering. These aren’t incremental improvements on Nvidia’s architecture — they’re different approaches optimised for different workloads.

    Programming paradigms are shifting from human-oriented languages to frameworks designed for agent workflows. AI agents don’t need readable variable names or structured flow control designed for human comprehension. They work with tokens and can operate on representations optimised for their own processing, not ours.

    Development processes are being redesigned around agent capabilities. Continuous, asynchronous, parallel-by-default workflows rather than sequential sprints bounded by human availability. The infrastructure assumes agents are the primary operators, with humans in supervisory roles.

    Aaron Levie maps the emerging stack: agent-specific sandboxed compute environments (E2B, Daytona, Modal, Cloudflare), agent identity and authentication systems, agent-native file storage and memory, agent wallets for microtransactions (Stripe, Coinbase), and agent-optimised search (Parallel, Exa). These aren’t conceptual products — these companies exist and are building now.

    His framing of “make something agents want” — riffing on Paul Graham’s “make something people want” — captures the shift. Software is being redesigned with agents as the primary user. Every feature needs an API. Every service needs an MCP server. If agents can’t sign up and start using your product autonomously, you’re invisible to the next generation of software consumers.

    The platform convergence is worth watching. Code repositories are evolving from version control into the orchestration layer for the entire software development lifecycle. Whoever controls that layer controls the persistent context that makes agents effective across sessions. The major AI labs are moving toward owning this layer, which suggests the future stack isn’t “AI model plus separate dev tools” but an integrated platform where context, runtime, and code repository collapse into one thing.

    A parallel convergence is happening at the operator level: always-on agents you communicate with through mainstream channels like messaging apps or email rather than terminals or dashboards. The human doesn’t need specialised tooling — they need a channel to the agent that handles everything downstream.

    Combine the GUI agent environment with the always-on operator agent and the platform layer, and you get a full vertical integration play — from software development lifecycle through to production operations, under one roof. This is the smartphone moment for developer tooling: separate apps collapsing into an integrated platform.

    What changes when the stack is purpose built

    The trajectory over the last few years has been clear: model capabilities improve while cost per unit of useful output drops. But today’s pricing is misleading — current subscription tiers are heavily subsidised, much like AWS in 2006. AI companies are burning cash to establish market share. The real story isn’t simply “it gets cheaper.” Provider economics improve toward sustainability while capabilities compound for users. Both curves move in the right direction, but assuming today’s prices reflect true costs is a mistake in either direction.

    Where the stack is unevenly developed matters more than the overall cost trajectory. Code generation has leapt ahead, but DevOps, production support, and operational reliability are further behind — areas where consequences of AI errors are immediate and expensive. The bottleneck isn’t capability. General-purpose coding agents can already manage infrastructure via CLI and APIs. The bottleneck is the trust boundary: giving an agent access to production systems and customer data raises security concerns that don’t exist in a sandboxed branch. Specialised DevOps agents are emerging to address this, but they’ll likely follow the familiar platform-shift pattern — absorbed into general-purpose agents once the sandboxing layer matures.

    There’s an irony in what AI is automating first: not the creative work developers love, but the process work that fell through the cracks as agile teams prioritised working software over documentation. The manifesto was right that heavyweight documentation was wasteful — but in practice, teams swung too far the other way, under-documenting, under-testing, and accumulating technical debt. Agents don’t have that bias. They’ll write tests and documentation with the same attention as feature code.

    What this means now

    Mainstream custom AI chips are a few years out. AI-native frameworks, possibly even shorter. Organisational redesign is the slowest layer — cultural, not technical.

    None of that is a reason to wait. Dark factory teams are already running production workflows on the borrowed stack — and the gap between them and companies still debating AI adoption compounds monthly. Every month of building expertise on today’s imperfect infrastructure is learning that transfers directly to the purpose-built era.

    The early smartphone era produced the apps, habits, and companies that dominated the next decade. We’re in the equivalent moment for AI. The stack will improve. The question is whether you’ll be positioned to take advantage of it.

  • The Economic Reality and the Optimistic Future of Agentic Coding

    The Economic Reality and the Optimistic Future of Agentic Coding

    After a couple of months deep in the trenches of vibe coding with AI agents, I’ve learned this much: scaling from a fun, magical PoC to an enterprise-grade MVP is a completely different game.

    Why Scaling Remains Hard—And Costly

    Getting a prototype out the door? No problem.

    But taking it to something robust, secure, and maintainable? Here’s where today’s AI tools reveal their limits:

    • Maintenance becomes a slog. Once you start patching AI-generated code, hidden dependencies and context loss pile up. Keeping everything working as requirements change feels like chasing gremlins through a maze.
    • Context loss multiplies with scale. As your codebase grows, so do the risks of agents forgetting crucial design choices or breaking things when asked to “improve” features.

    And then there’s the other elephant in the room: costs.

    • The cost scaling isn’t marginal—not like the old days of cloud or Web 2.0. Powerful models chew through tokens and API credits at a rate that surprises even seasoned devs.
    • That $20/month Cursor plan with unlimited auto mode? For hobby projects, it’s a steal. For real business needs, I can see why some queries rack up millions of tokens and would quickly outgrow even the $200 ultra plan.
    • This is why we’re seeing big tech layoffs and restructuring: AI-driven productivity gains aren’t evenly distributed, and the cost curve for the biggest players keeps climbing.

    What the Data Tells Us

    That research paper—Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity—had a surprising conclusion:

    Not only did experienced developers see no time savings on real-world coding tasks with AI, but costs increased as they spent more time reviewing, correcting, and adapting agent output.

    The lesson:

    AI shifts where the work happens—it doesn’t always reduce it. For now, scaling with agents is only as good as your processes for context, review, and cost control.

    Why I Remain Optimistic

    Despite the challenges, I’m genuinely excited for what’s coming next.

    • The platforms and models are evolving at warp speed. Many of the headaches I face today—context loss, doc gaps, cost blind spots—will get solved just as software engineering best practices eventually became codified in our tools and frameworks.
    • Agentic coding will find its place. It might not fully automate developer roles, but it will reshape teams: more focus on high-leverage decisions, design, and creative problem-solving, less on boilerplate and “busy work.”

    And if you care about the craft, the opportunity is real:

    • Devs who learn to manage, review, and direct agents will be in demand.
    • Organizations that figure out how to blend agentic workflows with human expertise and robust process will win big.

    Open Questions for the Future

    • Will AI agentic coding mean smaller, nimbler teams—or simply more ambitious projects for the same headcount?
    • How will the developer role evolve when so much code is “synthesized,” not hand-crafted?
    • What new best practices, cost controls, and team rituals will we invent as agentic coding matures?

    Final thought:

    The future won’t be a return to “pure code” or a total AI handoff. It’ll be a blend—one that rewards curiosity, resilience, and the willingness to keep learning.

    Where do you see your work—and your team—in this new landscape?

  • The Law of Leaky Abstractions & the Unexpected Slowdown

    The Law of Leaky Abstractions & the Unexpected Slowdown

    If the first rush of agentic/vibe coding feels like having a team of superhuman developers, the second phase is a reality check—one that every software builder and AI enthusiast needs to understand.

    Why “Vibe Coding” Alone Can’t Scale

    The further I got into building real-world prototypes with AI agents, the clearer it became: Joel Spolsky’s law of leaky abstractions is alive and well.

    You can’t just vibe code your way to a robust app—because underneath the magic, the cracks start to show fast. AI-generated coding is an abstraction, and like all abstractions, it leaks. When it leaks, you need to know what’s really happening underneath.

    My Experience: Hallucinations, Context Loss, and Broken Promises

    I lost count of the times an agent “forgot” what I was trying to do, changed underlying logic mid-stream, or hallucinated code that simply didn’t run. Sometimes it wrote beautiful test suites and then… broke the underlying logic with a “fix” I never asked for. It was like having a junior developer who could code at blazing speed—but with almost no institutional memory or sense for what mattered.

    The “context elephant” is real. As sessions get longer, agents lose track of goals and start generating output that’s more confusing than helpful. That’s why my own best practices quickly became non-negotiable:

    • Frequent commits and clear commit messages
    • Dev context files to anchor each session
    • Separate dev/QA/prod environments to avoid catastrophic rollbacks (especially with database changes)

    What the Research Shows: AI Can Actually Slow Down Experienced Devs

    Here’s the kicker—my frustration isn’t unique.

    A recent research paper, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, found that experienced developers actually worked slower with AI on real-world tasks. That’s right—AI tools didn’t just fail to deliver the expected productivity boost, they created friction.

    Why?

    • Only about 44% of AI-generated code was accepted
    • Developers lost time reviewing, debugging, and correcting “bad” generations
    • Context loss and reliability issues forced more manual intervention, not less

    This matches my experience exactly. For all the hype, these tools introduce new bottlenecks—especially if you’re expecting them to “just work” out of the box.

    Lessons from the Frontlines (and from Agent Week)

    I’m not alone. In the article What I Learned Trying Seven Coding Agents, Timothy B. Lee finds similar headaches:

    • Agents get stuck
    • Complex tasks routinely stump even the best models
    • Human-in-the-loop review isn’t going anywhere

    But the tools are still useful—they’re not a dead end. You just need to treat them like a constantly rotating team of interns, not fully autonomous engineers.

    Best Practices: How to Keep AI Agents Under Control

    So how do you avoid the worst pitfalls?

    The answer is surprisingly old-school:

    • Human supervision for every critical change
    • Sandboxing and least privilege for agent actions
    • Version control and regular context refreshers

    Again, Lee’s article Keeping AI agents under control doesn’t seem very hard nails it:

    Classic engineering controls—proven in decades of team-based software—work just as well for AI. “Doomer” fears are overblown, but so is the hype about autonomy.

    Conclusion: The Hidden Cost of Abstraction

    Vibe coding with agents is like riding a rocket with no seatbelt—exhilarating, but you’ll need to learn to steer, brake, and fix things mid-flight.

    If you ignore the leaky abstractions, you’ll pay the price in lost time, broken prototypes, and hidden tech debt.

    But with the right mix of skepticism and software discipline, you can harness the magic and avoid the mess.

    In my next post, I’ll zoom out to the economics—where cost, scaling, and the future of developer work come into play.

    To be continued…

  • The Thrill and the Illusion of AI Agentic Coding

    The Thrill and the Illusion of AI Agentic Coding

    A few months ago, I stumbled into what felt like a superpower: building fully functional enterprise prototypes using nothing but vibe coding and AI agent tools like Cursor and Claude. The pace was intoxicating—I could spin up a PoC in days instead of weeks, crank out documentation and test suites, and automate all the boring stuff I used to dread.

    But here’s the secret I discovered: working with these AI agents isn’t like managing a team of brilliant, reliable developers. It’s more like leading a software team with a sky-high attrition rate and non-existent knowledge transfer practices. Imagine onboarding a fresh dev every couple of hours, only to have them forget what happened yesterday and misinterpret your requirements—over and over again. That’s vibe coding with agents.

    The Early Magic

    When it works, it really works. I’ve built multiple PoCs this way—each one a small experiment, delivered at a speed I never thought possible. The agents are fantastic for “greenfield” tasks: setting up skeleton apps, generating sample datasets, and creating exhaustive test suites with a few prompts. They can even whip up pages of API docs and help document internal workflows with impressive speed.

    It’s not just me. Thomas Ptacek’s piece “My AI Skeptic Friends Are All Nuts” hits the nail on the head: AI is raising the floor for software development. The boring, repetitive coding work—the scaffolding, the CRUD operations, the endless boilerplate—gets handled in minutes, letting me focus on the interesting edge cases or higher-level product thinking. As they put it, “AI is a game-changer for the drudge work,” and I’ve found this to be 100% true.

    The Fragility Behind the Hype

    But here’s where the illusion comes in. Even with this boost, the experience is a long way from plug-and-play engineering. These AI coding agents don’t retain context well; they can hallucinate requirements, generate code that fails silently, or simply ignore crucial business logic because the conversation moved too fast. The “high-attrition, low-knowledge-transfer team” analogy isn’t just a joke—it’s my daily reality. I’m often forced to stop and rebuild context from scratch, re-explain core concepts, and review every change with a skeptical eye.

    Version control quickly became my lifeline. Frequent commits, detailed commit messages, and an obsessive approach to saving state are my insurance policy against the chaos that sometimes erupts. The magic is real, but it’s brittle: a PoC can go from “looks good” to “completely broken” in a couple of prompts if you’re not careful.

    Superpowers—With Limits

    If you’re a founder, product manager, or even an experienced developer, these tools can absolutely supercharge your output. But don’t believe the hype about “no-code” or “auto-code” replacing foundational knowledge. If you don’t understand software basics—version control, debugging, the structure of a modern web app—you’ll quickly hit walls that feel like magic turning to madness.

    Still, I’m optimistic. The productivity gains are real, and the thrill of seeing a new prototype come to life in a weekend is hard to beat. But the more I use these tools, the more I appreciate the fundamentals that have always mattered in software—and why, in the next post, I’ll talk about the unavoidable reality check that comes when abstractions leak and AI doesn’t quite deliver on its promise.

    To be continued…

  • Interning on FOSS 1: Open Source Development

    I’ve been interning at Sun Microsystems in Delhi from May 1st and during this period, I’ve had the opportunity to research a variety of open source applications. My initial project was to explore and research various open source applications suitable for use by students and compare them against each other and with the proprietary alternatives. There are indeed a bunch of alternatives available for the software we use during the course of our day to day work.

    I managed to submit a paper on “Components of an Open Source Operating System for Sustainable ICT Education in Schools in Developing Countries” to the HICSS conference, and I’m starting off a multi part post with my learnings on open source software and development.

    One of the interesting works that I read on open source development was Eric Raymond’s “The Cathedral and The Bazaar”. This is probably one of the definitive works on open source development, and a number of theories stem from it. In fact, quite a few papers that I referred to during the course of my research cited this work. He has postulated the following principles in the essay:

    1. Every good work of software starts by scratching a developer’s personal itch.
    2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
    3. Plan to throw one away; you will, anyhow.
    4. If you have the right attitude, interesting problems will find you.
    5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
    6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
    7. Release early. Release often. And listen to your customers.
    8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. (The full version of Linus’s law – Given enough eyeballs, all bugs are shallow)
    9. Smart data structures and dumb code works a lot better than the other way around.
    10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
    11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
    12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
    13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.
    14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
    15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
    16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
    17. A security system is only as secure as its secret. Beware of pseudo-secrets.
    18. To solve an interesting problem, start by finding a problem that is interesting to you.
    19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

    Most of his principles are for software development in general, and so also apply to open source development. The key learnings form his essay are two-fold. First is that it is important to have a working prototype of the project before making it open source, or at least trying to find other developers who’d be interested in it. Second is that open source attracts a wide variety of talent that can be put to various uses, ranging from bug finding, to improvement suggestions to actual coding. Thus, it is essential to treat the participants in the right manner as everyone could make an important contribution.

    One of the other observations to be made about open source development is the vital role that the internet has played in creating the synergy that exists between the developers, users and other contributors of any open source project. In fact, Eric Raymond has said as much in his essay:

    … Another (in hindsight) was that the Internet wasn’t yet good enough.

    Before cheap Internet, there were some geographically compact communities where the culture encouraged Weinberg’s “egoless” programming, and a developer could easily attract a lot of skilled kibitzers and co-developers. Bell Labs, the MIT AI and LCS labs, UC Berkeley—these became the home of innovations that are legendary and still potent.

    Linux was the first project for which a conscious and successful effort to use the entire world as its talent pool was made. I don’t think it’s a coincidence that the gestation period of Linux coincided with the birth of the World Wide Web, and that Linux left its infancy during the same period in 1993–1994 that saw the takeoff of the ISP industry and the explosion of mainstream interest in the Internet. Linus was the first person who learned how to play by the new rules that pervasive Internet access made possible.

    In essence, open source development has a lot of potential when used in the right manner. In fact, many companies use it quite strategically and couple them with interesting licenses (I’ll cover licenses in another part). There are also quite a few organizations championing free (as in freedom) software with the FSF (Free Software Foundation), headed by Richard Stallman being one of the pioneers. There is also a bit of controversy in the Free/Open Source world with some preferring the term free to open source. This has however not deterred organizations from leveraging open source development strategically. Open source development may not be practicable in every situation, particularly for routine software development in enterprises, but it definitely has its merits and I’ll be looking at other aspects of open source software in subsequent parts.

  • Striving for imperfection

    Clients complaining of bugs in an application is quite a common scenario, but what about this case from Worse Than Failure where the client wated some “bugs” to be implemented:

    All these non-implemented bugs added up to one unhappy customer. In their eyes, the software was far too “unbroken” for them to use. So, after spending a year and a half developing outdated and mediocre software, David’s team put on the final touches: a slew of bugs that made it look and function like the original.

    Now that’s what you call software development 🙂

  • The technical writing process

    1. Ask engineer how the damn thing works.
    2. Deafing silence.
    3. Crickets.
    4. Tumbleweed.
    5. Just start writing something. Anything.
    6. Give this something to the engineer.
    7. Watch engineer become quite upset at how badly you’ve missed the point of everything.
    8. As the engineer berates you, in between insults he will also throw off nuggets of technical information.
    9. Collect these nuggets, as they are the only reliable technical information you will receive.
    10. Try like hell to weave together this information into something enlightening and technically accurate.
    11. Go to step 6.

    from CouchDB wiki via Coding Horror