I have been writing software for more than half my life. In the last year itself, I’ve talked to hundreds of founders and operators in SF, from preseed to Series E companies.

AI is bringing an existential threat to a lot of B2B SaaS executives: How to keep asking customers for renewal, when every customer feels they can get something better built with vibe-coded AI products?

And the market is pricing it in. Morgan Stanley’s SaaS basket has lagged the Nasdaq by 40 points since December. HubSpot and Klaviyo are down ~30%. Analysts are writing notes titled “No Reasons to Own” software stocks.

The relation between vibe coding and B2B SaaS sales

The new problem for B2B SaaS is that with AI, customers can get something working with vibe coding. There are tens of vibe coding “internal tool” services that promise to connect to every integration in the world to pump out CRUD and workflow apps.

Whatever they build simply works. It takes some wrangling to get there (one Series C VP listed eleven different vibe coding tools they’ve tried and the pros and cons between each on a phone call once), but productivity gains are immediate.

And vibe coding is fun. You feel like a mad wizard using the right incantation ² to get this magical new silicon intelligence to do exactly what you want.

What they don’t know, though, is that a poorly architected system will fail, eventually. As every senior programmer (eventually) understands, our job is complex because we have to understand the relationships in the real world, the processes involved, and the workflows needed, and representing it in a robust way to create a stable system. AI can’t do that.

Non-programmers don’t know any of this nuance. One Series E CEO told me that they’re re-evaluating the quarterly renewal of their engineering productivity software because they along with an engineer reimplemented something using Github and Notion APIs. They were paying $30,000 to a popular tool³ and they were not going to renew anymore.

How does it impact B2B sales?

If customers feel like they aren’t being served exactly like they want to, they are more likely to churn. The reason behind all this is that customers are demanding more from their B2B vendors, because they know what’s possible.

Previously, you would change your company to fit what your ERP and pay them hundreds of thousands of dollars. Now, everyone can see that agentic coding makes an unprecedented level of flexibility possible. And customers are demanding that flexibility, and if they don’t get it, they’ll leave.

This week itself I was on a phone call with a Series B AE talking about how they’re potentially losing an $X00,000 account just because the customer can’t use a specific failure reporting workflow in the SaaS. They’re now working with me to build what the customer needs and retain them.

How to survive

1. Be a System of Record

If the entire company’s workflows operates on your platform, i.e. you’re a line-of-business SaaS, you are integrated into their existing team already. They know your UI and rely on you on the day to day.

For example, to create a data visualization I won’t seek any SaaS. I’ll just code one myself using many of the popular vibe coding tools (my team actually did that and it’s vastly more flexible than what we’d get off-the-shelf).

Being a “System of Record” means you’re embedded so deeply that there’s no choice but to win. My prediction is that we’ll see more SaaS companies go from the application layer to offering their robust SoR as their primary selling point.

2. Security, authentication, and robustness

This is where vibe-coded apps silently fail — and where established SaaS platforms earn their keep.

When a non-technical team vibe-codes an internal tool, they’re not thinking about environment keys, XSS vulnerabilities or API keys hardcoded in client-side JavaScript. They’re not implementing rate limiting, audit logs, or proper session management. They’re definitely not thinking about SOC 2 compliance, GDPR data residency requirements, or HIPAA audit trails.

I’ve seen it firsthand: a finance team built a “quick” expense approval tool that stored unencrypted reports in a public S3 bucket. A sales ops team created a commission calculator that anyone with the URL could access — no auth required. These aren’t edge cases. They’re the norm when software is built without security as a foundational concern.

Enterprise SaaS platforms have spent years (and millions) solving these problems: role-based access control, encryption at rest and in transit, penetration testing, compliance certifications, incident response procedures. Your customers may not consciously value this — until something breaks.

The challenge is that security is invisible when it works. You need to communicate this value proactively: remind customers that the “simple” tool they could vibe-code themselves would require them to also handle auth, permissions, backups, uptime, and compliance.

3. Adapt to the customer, not the other way around

The times of asking customers to change how they work are gone. Now, SaaS vendors that differentiate by being ultra customizable win the hearts of customers.

How? It’s the most powerful secret to increase usage. We’ve all heard the classic SaaS problem where the software is sold at the beginning of the year, but no one actually ends up using it because of how inflexible it is and the amount of training needed.

And if a SaaS is underutilized, it gets noticed. And that leads to churn.

This is the case with one of my customers, they have a complex SaaS for maintenance operations. But turns out, this was not being used at the technician level because they found the UI too complex⁴.

How I’m solving this is essentially a whitelabelled vibe-coding platform with in-built distribution and secure deployments. When they heard of my solution they were immediately onboard. Their customer success teams quickly coded a very specific mobile webapp for the technicians to use and deployed it in a few days.

Now, the IC technician is exposed to just those parts of the SaaS that they care about i.e. creating maintenance work orders. The executives get what they want too, vibe coding custom reports exactly the way they want vs going through complicated BI config. They are able to build exactly what they want and feel like digital gods while doing it.

Usage for that account was under 35%, and is now over 70%. They are now working closely with me to vibe code new “micro-apps” that work according to all of their customer workflows. And the best part? This is all on top of their existing SaaS which works as a system of record and handles security, authentication, and supports lock-in by being a data and a UI moat.

This is exactly what I’m building: a way for SaaS companies to let their end-users vibe code on top of their platform (More on that below). My customers tell me it’s the best thing they’ve done for retention, engagement, and expansion in 2026 – because when your users are building on your platform, they’re not evaluating your competitors.

The Real Shift

Here’s what I’ve realized after hundreds of conversations with founders and operators: AI isn’t killing B2B SaaS. It’s killing B2B SaaS that refuses to evolve.

The SaaS model was built on a simple premise: we build it once, you pay forever. That worked when building software was hard. But now your customers have tasted what’s possible. They’ve seen their finance team whip up a custom dashboard in an afternoon. They’ve watched a non-technical PM build an internal tool that actually fits their workflow.

You can’t unsee that. You can’t go back to paying $X0,000/year for software that almost does what you need.

The survivors won’t be the SaaS companies with the best features. They’ll be the ones who become platforms – who let customers build on top of them instead of instead of them. When I showed a well-known VC what I was building to help SaaS companies do exactly this, he said: “This is the future of marketplaces and software companies.”

Maybe. Or maybe this is just another cycle and traditional SaaS will adapt like it always has. But I know this: the companies I’m talking to aren’t waiting around to find out. They’re already rebuilding their relationship with customers from “use our product” to “build on our platform.”

The question isn’t whether AI will eat your SaaS.

It’s whether you’ll be the one holding the fork.

I’m solving exactly this problem with a whitelabelled AI platform for B2B SaaS companies, so your users can vibe code customized workflows on top of their existing system of record.

My customers tell me this is the best way to support retention, engagement, and expansion in 2026. If this sounds interesting to you or someone you know, I can reach out with a custom demo or you can learn more about Gigacatalyst.

I can clearly see how AI coding is rewiring our brains – it makes developers crave instant gratification instead of deep understanding, and reduces us to gamblers who pull levers for the next hit of working code.

If this is happening to me, someone who learned to code in the pre-AI era, what’s it doing to junior developers who’ve never known anything else?

Solving Hard Problems

At the age of 16, alone in my room in New Delhi, I was completely obsessed with this problem. Want to try solving this with me?

It’s from the site called “Project Euler”, one of the greatest resource for programming challenges that combine math with your data structures and algorithms knowledge. This particular one is Problem 15 “Lattice Paths.” Like all Project Euler problems, it can be stated simply enough.

The problem already shows us how it looks like for 2x2, and you can sketch out 3x3 easily as well (try it out, that was the first thing I did). But, the challenge actually comes when you try to visualize the scale – can you imagine how large the result must be for a 20x20 grid?

I spent weeks on this thing – scratching diagrams on every piece of paper I could find, bothering my math teachers until they avoided me, and even dreaming about algorithms on a few nights.

Can you imagine spending weeks on a single problem today? Just thinking, failing, thinking more?

I tried everything. Brute force. Recursion. Drawing grids until my fingers cramped. Nothing worked.

Then one fine afternoon on the bus back from school, it struck me. This wasn’t about pathfinding at all.

It was combinations. To reach the bottom-right, you need exactly 20 right moves and 20 down moves. The question can be rephrased: how many ways can you arrange those moves, or how many ways can you choose 20 moves out of 40? And that gives us the answer, C(40,20).

I had a mini eureka moment that kept me giddy till I reached home. I booted up my PC and coded the solution in ten minutes. I got the answer: 137846528820. I hit submit and was greeted with the success screen on Project Euler, and the pure gratification of weeks of effort culminating on this one glorious moment.

But here’s the thing — the actual number didn’t matter. What mattered was that moment when everything clicked. When weeks of confusion suddenly made perfect sense. That flow state of complete immersion and understanding.

I wouldn’t have felt like this if I had not spend all that time thinking about the question, or if I had cheated and looked up the answer online.

But I didn’t, and the rush I got was pure magic. I was in love.

AI Addiction

A few months ago I was dealing with some gnarly state management bug. Of course, debugging React state is the bottom of the totem pole for enjoyability, just slightly better trying to browse the internet on a slow connection with packet loss, so I (lazily) pasted the entire problem into Claude to let it do it.

Then (and this is the part where it starts to go wrong) I alt-tab to Twitter while it thinks.

But, my mind just went “oh, cool”. I felt… nothing.

Well, that’s not true.

I felt something – a hollow satisfaction that my code now works. It felt like the same feeling when doom scrolling through TikTok or when completing another level on a mobile game. That cheap hit of “something happened.”

If you’ve been coding with AI, this might seem relatable:

I feed in a prompt, with the best of my vibes. The AI says it’s “thinking” (even though everyone knows that an AI doesn’t actually think, they’re blatantly lying to our faces. But I smile at the illusion, maybe even slightly believe it.)

I know that it’s gonna take a minute or so before I get the answer. What am I supposed to do in the meanwhile, think? The AI is already going to do that for me, much faster, and will give me the correct result (probably.)

I check back. It’s done. There’s a brief hit of dopamine when I see that it’s completed. Cool.

I check the code (I lied, I just read through what it tells me it’s written and not the actual code). It’s good enough, but of course the AI has made some wrong assumptions so there’s some mistakes.

I give the AI another prompt to fix this, and we repeat our little dance.

Put in a prompt, get code.

Pull the lever, get a reward.

No struggle, no insight, no growth.

The Brain on AI

Here’s what’s happening inside your head when you “vibe code” and rely completely on AI: you get dopamine from the wrong source.

Before AI, programming gave me two dopamine hits: figuring things out AND getting them to work. The breakthrough moment when you understand why your algorithm failed. The satisfaction of architecting something elegant. The joy of working code after hours of debugging.

Now, the AI does all the figuring out. You’re left with just a shallow pleasure.

If you think about it, that 30-second wait for AI responses can be seen as a variable ratio schedule — Random rewards delivered at unpredictable intervals — the same psychological pattern that makes slot machines, social media, and mobile games addictive.

If this is happening to me — imagine what it’s doing to the developers who’ve never known anything else.

We’re creating a generation of developers who can ship code but can’t reason about systems.

We are creating a generation of human merge buttons who approve AI commits without understanding what they’re deploying.

They’ll never experience that Project Euler moment. That weeks-long struggle that teaches a new programmer how to think, not just how to copy-paste. They’re skipping the very challenges that would make them great.

The Illusion

The worst part is that it feels amazing and does actually work (usually.) AI makes me feel productive and features ship faster. The GitHub graph blazes green.

But velocity isn’t competency. When you outsource thinking, you don’t just lose practice — you lose confidence. That voice that used to whisper “I can figure this out” gets quieter every time you reach for AI instead.

How to Use AI (Without Losing Your Soul)

I’m not saying abandon AI — these tools have quickly become too powerful to ignore. But we need to be intentional about how we use them.

1. Force yourself to understand the generated code before accepting it. If you can’t explain what it does and why, don’t merge it. This seems obvious, but you’ll be shocked how often new developers skip this step.

2. Practice problems without AI regularly. I’ve started doing Project Euler again. This is deliberate practice for programming. My problem-solving muscles were rustier than I expected, but they’re coming back.

3. Use AI waiting time for something productive. Instead of scrolling Twitter or Reddit, you can think about the architecture for your next task while the AI handles implementation details. (Use social media blocking apps if you need to. I use Opal on my phone for this.)

4. Most importantly — remember why you we write code. It’s to create something from nothing, to solve problems that seemed impossible, and build things that matter. Don’t forget the why.

The Future

Even when AI will have permeated all parts of the software development lifecycle, the best developers will continue to be the ones can think deeply about complex problems.

I’m bullish on AI for coding. It’s revolutionary technology that’s making me more productive than ever. But productivity without understanding is just elaborate copy-pasting.

AI should amplify your intelligence, not replace it. Use it to tackle bigger challenges, not to avoid thinking altogether.

Because the day we stop struggling with hard problems is the day we stop being programmers, and become something else entirely.

I’m doing something really hard but I realize I’ve never written down my guiding principles about why I do this. This article is mostly a reminder for me: on what it takes to achieve greatness.

Here’s what I’ve learned so far:

Show Original

Show Stylized

Learning to fail with joy

I still remember my first program - in VBScript 6 written on an XP machine in Notepad - a textbox came up, where when you typed your name, the computer wrote back “hi [name]!”

At that time, it was the greatest thing ever. I made that computer do what I want. I summoned a magical box with my name inscribed in it. I felt like a sorcerer unlocking the arcane arts.

I know now that it’s not one of the most sophisticated programs ever. But if I hadn’t written that I wouldn’t have been able to make a living writing code.

In the beginning, whatever we do generally isn’t good. But find the joy and keep doing it, and it will add up.

Recently, I found myself running across the Golden Gate Bridge with one of the smartest investors in Silicon Valley, about to throw up.

That’s when he told me that even though each step feels hard, just put on a smile and keep taking one more.

An ex Navy SEAL who also held the world record for 4100+ pullups in 13 hours reinforces this whenever I complain during our workouts together: it always hurts and feels bad at the start. Eventually it won’t.

What I’ve discovered: the difference between people who build great things and those who don’t isn’t talent. It’s that they learned to smile while sucking at something. When you fail and make bad stuff with joy, you get better faster.

My genius friends are all a little crazy

I live with a 19-year-old who’s been working on memory for AI for the last 2 years. That’s over 10% of his life dedicated to AI memory. Ask him anything on this topic, he’ll tell you things that you can never find on Google or ChatGPT. How does he know all this?

Another genius founder and a new friend of mine learnt how to code on a Nokia. Can you imagine — a T9 keyboard to type out HTML on? Have you seen the number of < in HTML, do you even know how to write this on a T9? He’s now running a successful product with over 16k+ GitHub stars. How was he able to stick through all the pain?

Watching these obsessed people made me realize something: the only way you can do something every single day, taking up the majority of your time, is if you’re genuinely in love with it. Not simply interested, nor passionate. In love. To the point where typing HTML on a T9 keyboard feels like play.

That kind of love is what lets you rack up the hours. Which lets you suck quicker. Which lets you become great.

The mistake of not having feedback loops

For a long time, I thought building a startup meant writing perfect code. I’d disappear for months, crafting beautiful systems that nobody ever used. I was getting great at coding, but terrible at startups.

Then I joined buildspace and saw this dude two years ago who inspired and taught thousands.

He showed me the fundamental early stage startup feedback loop: ship, get feedback, improve, repeat.

That’s when I realized: I wasn’t doing the whole thing. If you want to be a great writer, you can’t just write—you need readers. If you want to found a startup, you can’t just code—you need customers.

The pattern I started noticing everywhere: greatness comes from doing the complete cycle, not perfecting one part.

Get that set up as soon as you can, however you can, and remember that it’s only you who has to make sure that you’re doing it correctly.

Finally, community

Years ago, I was probably the most antisocial person you’d meet. I tried to do everything on my own. It was hard and the low times felt really low.

Then something shifted. Turns out, finding people who’re having fun alongside you makes everything easier.

I’m now fortunate to be in the Solo Founders Program.

People around me are in the same journeys, know exactly what I’m talking about, share my excitement, and give constructive feedback from the same values.

Most importantly, we all share our failures openly. Sometimes we find help, but even knowing that others are facing hardships makes our own a bit easier.

Suddenly, the journey doesn’t feel lonely. It feels like an adventure you’re on together.

Why this matters

I’ve thought a lot about what drives the great people I know. And I think the answer is simple: it feels great to build something and be good at it.

I still remember the rush from that first “hello world” moment. And at every step and growth, that feeling never went away. It just got bigger.

Every problem you solve, every user you help, every impossible thing you make possible builds on that same foundation.

Here’s what nobody tells you about building great things: it’s mostly about becoming the kind of person who can handle the journey.

Someone who finds joy in the struggle. Someone who falls in love with problems worth solving. Someone who finds their people.

The world doesn’t need another perfect product. It needs what happens when you combine your weird obsessions with willingness to fail.

So go be weird. Go fail. Go build something only you would build.

We’re all waiting to see what you come up with.

Rinse, repeat, until you want to throw your laptop out the window.

David Cramer from Sentry recently shared his AI workflow where he maintains manual rules files to give LLMs context. Solid approach, but it feels like too much copy-pasting. It’s 2025, and machines can do a better job of remembering things.

It’s funny how we’ve built the most powerful reasoning systems in human history, then lobotomized them by making them forget everything after each conversation. My question: is there a better way?

The Story

Until recently, my daily routine looked like this:

1. Open Claude Code/Cursor
2. Explain the task
3. It gives a wrong result on the first try
4. Retry, this time with more context
5. It gives a wrong result on the second try
6. Spend 30 minutes fixing it
7. Close the conversation in frustration
8. Repeat the next day

I was essentially training the same AI from scratch every single day. The definition of insanity, right?

That’s when it hit me: The AI isn’t the problem. The conversation model is.

Building a Second Brain

I started thinking about how human teams actually work. Senior developers don’t explain the entire codebase to new hires every morning. They build institutional knowledge. They have coding standards, architectural decisions, and learned preferences that persist.

So I built Giga — an AI memory system that learns from your conversations and builds a persistent knowledge base. Not another rules file you maintain manually, but a system that watches how you code, what you prefer, and what decisions you make.

I made a “reflect” command which allows the AI to look back on it’s own conversation to identify patterns. While dogfooding it, I noticed something magical happening. Giga confidently identifies actual patterns, saves them as “neurons” in the second brain, and allows me to evoke them when I need them.

My AI is finally able to remember my preferences, and it uses them to make better decisions.

How to Fix Your AI Workflow

If you’re tired of the hamster wheel, here’s what actually works:

• Question the reset. Why are you starting fresh every time? Your conversation history is data. Your corrections are training examples. Your preferences are valuable.
• Build incremental context. Instead of massive context dumps, add one new piece of information per conversation. Let the AI learn gradually, like a human would.
• Think in systems, not conversations. Individual AI chats are tactics. Building persistent AI knowledge is strategy.

The Path Forward

The future isn’t necessarily more powerful models. It’s AI that remembers, learns, and gets better over time — like a real team member.

We’re at an inflection point. We can keep playing the role of human context providers, or we can build systems that actually learn and improve.

I’m betting on the latter.

The question isn’t whether AI will get smarter. It’s whether we’ll get smarter about using it.

Building Giga taught me that the best way forward with code generation AI isn’t about better models — it’s about better context and memory. Giga is in private beta and only available for select teams, but if you’re interested in seeing how persistent AI knowledge works in practice, shoot me an email and I’d love to show you a demo.

You know that feeling when you leave the same code review comment for the third time this month? “Hey, we use relative imports here, not absolute ones.” Or “Remember to handle both null and empty string cases.” Or “This should use our ORM helper, not raw SQL.”

Your team agrees it’s important. People follow it for some time. But three weeks later, nothing’s changed, and you’re still leaving the same comments.

I recently interviewed C.J. and Zach from Parabola (a Series B data automation company) about how they use AI in their engineering workflow. They shared a simple approach that’s replaced most of their linter rules: teaching Cursor to remember code review feedback permanently.

The Problem with Traditional Linting

Traditional linting can’t catch the nuanced “we don’t do it that way here” patterns that come up in code reviews.

On the other hand, LLMs are perfect for this use case. Cursor rules are similar to “system prompts” for cursor, or extra instructions you provide to direct how it behaves. Here’s how Parabola uses them: every time they spot a pattern in code review that should be avoided, they write a Cursor rule. After a PR review, they ask “how could we teach the AI to avoid this class of error in the future?”

Some examples that might come up in code reviews but ESLint can’t catch:

Comment Rules: when doing a large change or refactoring, try to retain comments, possibly revising them, or matching the same level of commentary to describe the new systems you're building
It's especially common that extra comments means that the previous/existing code has something weird going on. So either ask the human what to do and raise it before making a change, or think extra about what to do.

Package Usage: If you're adding a new package, think to yourself, "can I reuse an existing package instead"
(Especially if it's for testing, or internal-only purposes)

Implementation Guide

• Start small — Pick the most common code review comment your team makes
• Write conversationally — Explain the rule like you’re talking to a junior engineer
• Include examples — Show what to do and what not to do
• Be specific about scope — When should this rule apply?
• Commit to your repo — Make it part of your codebase so everyone benefits

Reality Check

There are some caveats, namely:

• It’s a 90% solution, not 100%. Their rules work most of the time, but stuff still slips through. You’re not eliminating code review.
• Different IDEs, different “rules” file conventions. Windsurf has .windsurfrules. Copilot has copilot-instructions.md. You need to understand and note the differences.
• Rules can get messy fast. Without some discipline, you’ll end up with conflicting rules or overly broad ones that trigger when they shouldn’t. You have to review your rules regularly, what made sense six months ago might not make sense now.

When to Use

Use Cursor rules for:

• Team conventions that are hard to express in code
• Patterns that emerged from production incidents
• Style preferences that don’t warrant build failures
• Complex logic patterns that would be tedious to lint

Keep traditional linters for:

• Security-critical patterns
• Industry-standard formatting
• Syntax errors that should break builds
• Rules that need to run in CI/CD

The Compound Effect

After ~10 PRs, you’ll have a collection of rules that represent your team’s collective wisdom. New AI-generated code automatically follows patterns that used to require manual review cycles.

The beauty is that knowledge doesn’t walk out the door when people leave. It gets encoded into how your AI writes code.

Getting Started Today

Create a .cursorrules file in your project root. Add one rule based on the most recent code review comment you’ve made. Test it by asking Cursor to write code that would normally trigger that comment.

You’ll be surprised how quickly this becomes valuable.

Parabola is hiring senior engineers who think deeply about user experience and building tools that work for both technical and non-technical users. They’re looking for people who care about ergonomics for different types of users — from someone automating one simple process to someone building complex, reusable data workflows. If building customer-centric data tools sounds interesting, they’d love to hear from you. Check out their Parabola careers.

Further Reading

• My Cursor AI Workflow That Actually Works in Production
• Cursor AI Gold Standard Files Workflow
• Context, Structure, Organization: Framework for AI-powered Development
• The day I taught AI to think like a Senior Developer
• AI Prompt Playbook (Prompts that Work in Production)

Most developers use Cursor like expensive autocomplete. They let it generate whatever code it wants, fight with inconsistent outputs, and spend more time debugging AI mistakes than they save.

There’s a better way. During my interview with Vidhur from Pallet, I learned about a simple technique that made their AI-generated code dramatically better: the “gold standard” file approach.

What Is a Gold Standard File?

You pick one ideal file for each common pattern in your codebase and reference it in your .cursorrules file. Think of it as showing Cursor your team’s style guide through working examples rather than abstract rules.

For a typical backend API following a controller-service pattern, you’d maintain three gold standard files:

• Controller file: Perfect API endpoint following your controller-service-repository pattern
• Service file: Clean business logic with proper separation of concerns
• Test file: Your exact testing philosophy in action

The key insight: don’t let AI guess what good code looks like. Show it explicitly.

Setting Up Your Rules File

Your .cursorrules file should point directly to these examples:

You are an expert software engineer. 

Reference these gold standard files for patterns:

- Controllers: /src/controllers/orders.controller.ts
- Services: /src/services/orders.service.ts
- Tests: /src/tests/orders.test.ts
Follow these patterns exactly. Don't change existing implementations unless asked.
Use our existing utilities instead of writing new ones.

How to Choose Your Gold Standard Files

• Start small: Begin with one pattern that you use frequently, like API endpoints. Add more gold standards over time.
• Keep it specific: “Write good code” is useless. “Follow the exact pattern in /src/controllers/orders.controller.ts” works.
• Share with your team: Treat .cursorrules like a .gitignore - everyone should use the same standards.
• Don’t over-provide context: Too many instructions confuse AI. Focus on your most important patterns.

I made something that does all of this for you automatically. If you’re interested, give it a try.

What Actually Changes

The transformation is immediate. Code reviews become faster because AI-generated code follows your established patterns instead of random internet examples. New code consistently looks like it was written by your senior engineers, not pulled from different tutorials. Junior developers start absorbing good patterns from AI-generated examples, accelerating their learning curve.

And the real win for startups — development velocity increases without sacrificing code quality. When you’re racing to product-market fit, you can’t afford to choose between shipping fast and maintaining clean code. This approach gives you both.

Beyond Just Code Generation

This approach works for any AI coding task. Testing, documentation, even complex algorithms - if you have a good example, AI can follow that pattern reliably.

The bigger principle: AI tools are only as good as the examples you give them. Feed them your best code, get better results.

Getting Started Today

1. Find your best-written controller, service, and test files
2. Create a .cursorrules file that references them specifically
3. Add any anti-patterns you want to avoid
4. Share with your team and iterate

This isn’t revolutionary AI technology. It’s just good engineering: showing tools what you want instead of hoping they guess correctly.

Pallet is hiring engineers who want to build AI agents grounded in real-world applications. They’re looking for people who understand that agents aren’t fully autonomous yet and take a pragmatic approach to AI reliability. If you want to work on logistics AI with a team that accepts agents are imperfect and builds proper guardrails around them, check out the Pallet careers page.

Further Reading

• My Cursor AI Workflow That Actually Works in Production
• Context, Structure, Organization: Framework for AI-powered Development
• The day I taught AI to think like a Senior Developer
• AI Prompt Playbook (Prompts that Work in Production)

Does that sound familiar?

Here’s the thing — the “vibe coders” are not wrong about AI being powerful. They’re just not dealing with what you’re dealing with.

You’re working on a real codebase, with real dependencies, real business logic, and real users. Real codebases are messy.

I spent ten years of my life running a development agency, and Cursor has legitimately saved me weeks of work, but only after I stopped expecting it to just “figure things out.” Now, I’m going to share with you the workflow that made Cursor work for me on complex projects.

Mental Model

Think of your AI as a brilliant intern who codes incredibly fast but has zero context about your busines or your architecture decisions.

You wouldn’t hand an intern your entire codebase and say “build the payment system.” You’d give them background, show them examples, and break down exactly what needs to happen.

Same principle applies here.

Document your patterns like someone’s life depends on it. I keep a backend-patterns.md file that explains how I structure resources — where routes go, how services work, what the data layer looks like. Every time I ask Cursor to build something backend-related, I reference this file.

Actually, maintaining these files manually got tedious, so I built somthing to handle this automatically. My tool creates files that capture your project’s architectural decisions, and keeps them updated as your codebase evolves. Personal productivity hack that’s saved me hours of documentation work.

Result = no more random architectural decisions that break everything downstream.

Plan everything before writing code. I don’t let the AI write a single line until we both understand exactly what we’re building. I usually co-write the plan with Claude or ChatGPT — what functions we need, which files get touched, potential edge cases.

This might sound tedious, but actually saves a lot of debugging time.

Show, don’t tell. Instead of explaining how something should work, point to existing code: “Build this new API endpoint, follow the same pattern as the user endpoint.” Pattern recognition is where these models actually shine.

Control scope ruthlessly. In smaller projects, you can ask it to build whole features. But as complexity grows, get more specific. One function at a time. One file at a time. The bigger the ask, the more likely it breaks something unrelated.

Maintenance

Your codebase needs to stay organized or AI starts hallucinating. Hit that reindex button in Cursor settings regularly — treat it like clearing your browser cache.

When errors happen, fix them one by one. Don’t copy-paste a wall of red terminal output. AI gets overwhelmed just like humans do.

Pro tip: Add “don’t change code randomly, ask if you’re not sure” to your prompts. This simple line has saved me countless debugging sessions.

Use Cursor Rules Files

Set up a .cursorrules file in your project root. Every time you find yourself repeating the same context in prompts — like your backend patterns or coding standards — add it to the rules file. It gets automatically included in every AI request.

You can even create file-specific rules. Your database migration files can have different guidelines than your frontend components.

Start With a Codebase Outline

Before doing any major work, have the AI create an outline of your entire project. Go file by file, documenting every class, public function, and system. Include the AI’s understanding of each piece’s purpose and any gotchas.

This used to be the most time-consuming part of my workflow, but the results were worth it. Got so frustrated with this that I ended up building my own tool to automate it. Now, it analyzes my entire project in minutes and generates comprehensive documentation, which creates a baseline that prevents the AI from building duplicate systems or breaking existing functionality.

What This Gets You

I write maybe 10% of the boilerplate I used to. Database queries with proper error handling happen in minutes instead of hours. Complex API endpoints with validation get handled while I focus on architecture decisions that actually matter.

The best part is that I can move fast on the stuff that requires actual thinking while the AI handles tedious implementation.

Your legacy codebase isn’t a disadvantage here — all that structure and business logic you’ve built up is exactly what makes AI productive. You just need to help it understand what you’ve already created.

The Real Advantage

The teams who are able to work with AI effectively on complex projects are going to have a massive advantage. That happens when they learn to give AI the context it needs to be genuinely useful.

Your competitors are still either avoiding AI completely or getting frustrated when it breaks their code.

You can be the one who figured out how to make it work, and get an advantage against your competitors who are still struggling with it.

Questions? Write to me at hi@nmn.gl (personal email) and I’ll try to help in whatever way I can.

Further Reading

• My Cursor AI Workflow That Actually Works in Production
• Context, Structure, Organization: Framework for AI-powered Development
• The Day I taught AI to think like a Senior Developer
• AI Prompt Playbook (Prompts that Work in Production)
• Security Checklist & Prompts for Cursor Vibe Coders
• Cursor Workflows to build SaaS products in 2025

The newly released GitHub Copilot agent was given permission to make pull requests on Microsoft’s .NET runtime, and the results couldn’t be funnier.

The AI confidently submitted broken code, while human developers patiently explained why it didn’t work. Over and over again, for days.

What’s worse is that CEOs are using this same technology to justify laying off entire engineering teams.

Comedy show

I spent way too much time scrolling through these PRs. The pattern was always the same:

• AI: “I fixed the issue!”
• Human: “Your code isn’t working and you broke other tests.”
• AI: “You’re absolutely right! Fixed it now.”
• Still not fixed.

This went on for days. Multiple rounds of the AI insisting it solved problems, while making them worse.

And somewhere, executives are watching this thinking, “Yeah, this is ready to replace our engineering team.”

Hidden truth

I don’t want to sound like an AI hater, I use AI for coding daily. It’s genuinely made me more productive.

But here’s what’s actually happening with these layoffs: Companies over-hired during the pandemic boom. Now they need to cut costs. AI gave them the perfect cover story.

Instead of admitting “We planned poorly,” they get to sound visionary: “We’re leveraging AI to optimize workforce efficiency!”

Meanwhile, I know a startup founder who just raised Series A. He messaged me about wanting to hire three more engineers.

“Aren’t you using AI to do more with fewer people?” I asked.

He laughed. “AI makes my team unstoppable. Why would I want fewer unstoppable people?”

What devs need to do right now

If you’re worried about AI layoffs, here’s your playbook:

• Become the AI expert on your team. Don't fight the tools, master them. Be the person who knows when AI helps and when it hurts.
  
  Management needs someone who understands both the potential and limitations.
  
  
• Document everything AI can't do. Keep a running list of complex problems you solve that AI suggestions couldn't handle. Things like system design decisions, business logic that required domain knowledge, or bugs that needed deep debugging.
  
  This is not just paranoia, it is to properly understand AI, for yourself and for your team.
  
  
• Make it public. Share your real AI experiences on social media. Post screenshots of AI failing at complex tasks alongside examples where it actually helped. Show the world that human + AI is the future, not AI alone.
  
  The world is watching. Share the truth about AI. If you don't, then who will?
  
  
• Create the narrative. Every time you solve something AI couldn't, tweet about it. When AI helps you ship faster, share that too.
  
  The goal isn't to bash AI, it's to show that the most powerful combination is skilled developers using AI as a force multiplier. Make yourself the obvious choice for companies that want to win.

The bottom line

If your CEO is talking about AI layoffs, update your resume. Not because AI will replace you, but because you’re working for someone who thinks a technology that can’t understand a simple bug is ready to run their engineering org.

AI has become a part of software development, but it isn’t perfect. Humans are needed more than ever.

And if you want proof, just check those Microsoft PRs. The AI is still confidently wrong. The humans are still patiently fixing everything.

So trust me, your job is safe.

Everyone from YC partners to Fiverr’s CEO has been proclaiming that “90% of code is AI-generated” or that they’re becoming “AI-first” companies.

The subtext they’re forcing on us is clear: programmers who don’t embrace AI will be left behind.

But after two years of daily AI coding — from the earliest Cursor version to the latest agentic tools — I’ve uncovered the truth: AI coding tools are simultaneously terrible and necessary.

Harsh Economies of Code

The industry’s embrace of AI makes perfect sense when you follow the money.

I learned this lesson from my former engineering manager. We were celebrating after a product launch, and I was complaining about some tech debt.

“You know what?” he said. “I’ve never once heard the CEO care about our code quality. The only thing that matters is if we can deliver before deadlines or not. Nobody’s getting promoted for clean code if the feature ships late.”

It was disappointing, but also… enlightening?

As a programmer, since I live inside my codebase, I want to make it perfect exactly the way I want.

But from the perspective of a business, my code is merely a tool to generate revenue.

And this is cold reality pushing AI adoption: businesses don’t care if the code is AI-generated or handcrafted as long as it works and ships quickly.

What AI Is Actually Good For

After two years of using AI coding tools extensively, I’ve found some areas where it truly shines. Here’s what I find most useful with AI:

• Understanding documentation: I often have to use libraries that are poorly documented. Last sprint I had to use a Python library with the worst imaginable docs: poorly structured and broken search. I pasted that link into Cursor, let it index the docs, and I was able to find precisely what I needed and ask questions around it within seconds. It would’ve taken hours of trial and error otherwise.
• Boilerplate code: I don’t know about you, but writing repetitive framework code feels like the worst kind of drudgery to me. I know why GraphQL resolvers are needed, or how each component needs loading, error, and success states; but I really don’t like writing such code myself. Now I let an agentic AI do the grunt work for me, so I can focus on the fun parts.
• Error debugging: In the past, the main way to debug was to search the error string, find information across multiple stackoverflow results, and condense it to a useable answer yourself. Now, the AI can do the search much quicker and write customized solutions by understanding our code. Why not enjoy that?

What AI fails at

Even though the AI fanboys might come for me, there are some universally agreed upon issues with AI:

Any non-mainstream tech stack. AI performs decently with React, but try something else, and the quality plummets.

Last month I used AI to help with a WebGL project, and it generated code that looked plausible, but simply didn’t work, because it hallucinated so many API calls.

Complex business logic. Last week, I asked AI to refactor a function. The AI happily returned a ‘solution’ with unnecessary duplication.

The code worked, but the AI completely lacked the ability to identify the actual problem and implement an elegant solution. This problem remains because the AI doesn’t have a full context of your entire codebase.

The debugging overhead is real. Sometimes fixing AI’s “solution” takes longer than writing it yourself.

Security is another weak spot. I’ve had AI confidently suggest storing API keys in local storage — essentially leaving my application open for exploits.

The Correct Way to Use AI

This reality taught me to combine AI’s speed with my personal quality standards:

• I let AI draft the first version.
• I carve out dedicated review time to catch its blunders.
• I write tests around every AI-generated module.

How to Thrive (Not Just Survive)

If you’re still on the fence, here’s the exact playbook I’ve honed:

• Build your verification instincts. When AI outputs code, I learned to spot the red flags: incorrect library usage, not using existing functions or patterns, incorrect domain knowledge.
• Operate at the edge of your abilities. Use AI for the mundane stuff (config, boilerplate, standard patterns, typical integrations), then apply your creativity to the novel problems AI can’t handle yet.
• Context is all you need. Always make sure to give the AI a proper context of your entire codebase. If you give the correct context, AI can do magical things. If not, you will get low quality results and will often be frustrated.
• Ask deliberately. Instead of “implement this feature,” I break problems into smaller chunks: “Create the data model for this entity,” then “Write the validation logic for these fields,” and so on.
• Deep dive when things break. The best learning happens at failure points. When AI-generated code breaks, that’s your cue to really understand the underlying system. Add logs, use the debugger, manually go through each part of the code flow.
• Keep a “WTF AI” journal. Document every spectacular fail—hallucinated API calls, misnamed types, security oversights. Those failures become your internal library of “don’t let it do that again.” It’s therapeutic and surprisingly educational.

Next Steps

The uncomfortable truth is that AI coding tools aren’t optional anymore. The developers who adjust to this new reality fastest will have the most leverage, because they’ll solve higher-level problems while AI handles the mundane.

I don’t particularly like this reality. There’s something unsettling about watching an AI generate in seconds what would have taken me an hour. But pretending this shift isn’t happening won’t change its trajectory.

Perhaps in five years, we’ll look back on this transition period with nostalgia. Another tool that felt threatening until it became indispensable. Or maybe we won’t.

Either way, I’ll be using AI tomorrow morning, cursing its limitations, and shipping more code than I did yesterday.

Thanks to John, Cyrene, and Mikhail for helping me think deeper about these ideas and for sharing feedback on my drafts

We are used to interacting with the digital world via apps and windows—but MCPs enable an AI to do everything that humans do, without using any apps.

Here’s a quick guide on setting up and using your first MCPs in Windows.

Choose your AI

To interact with any MCPs, you first need an app that allows you to interact with an AI.

This is referred to as a “client”. The top option is Claude Desktop, but you can also use Cursor or Windsurf.

For this guide, we’ll be using Claude Desktop, so install it to follow along.

Configuring MCPs

All MCP configurations follow a generic format, which is something like:

{
  "mcpServers": {
    "mcp-name": {
      "command": "npx", // or uvx
      "args": [
        "-y",
        "mcp-package-name", // on the package registry
        // any other args
      ],
      "env": {
        // e.g. provide API keys here
      }
    }
  }
}

For Claude Desktop, the file you add this config is %APPDATA%\Claude\claude_desktop_config.json

Your first MCP

The easiest (and one of the most useful) MCPs to start with is the “filesystem” MCP.

This allows Claude Desktop to read/write any files.

Here’s what you need to add in mcpServers in your claude_desktop_config.json file:

"filesystem": {
  "command": "npx",
  "args": [
    "-y",
    "@modelcontextprotocol/server-filesystem",
    // list of folders you want Claude to be able to access
    "C:\\Users\\username\\Desktop"
    // I let it access the Claude folder itself, so Claude
    // can modify the `claude_desktop_config.json` file by itself
    // to add/remove any MCP servers I want
    "C:\\Users\\username\\AppData\\Roaming\\Claude"
  ],
  "env": {
    "DEBUG": "*"
  }
},

After setting up any MCP, you will need to quit and restart Claude from the Task Manager for it to refresh your config.

But once that’s done, Claude will be able to read/edit any of your files. This is what it looks like:

working! claude can now add it's own MCPs via an MCP :)

now to get the Twitter MCP to work: I need to get my Twitter API keys https://t.co/rajLZ6cLkN pic.twitter.com/6wQ3H5a1ri

— neo (@NamanyayG) April 25, 2025

What’s next?

I am experimenting with MCPs, with my eventual goal being to complete all of my regular tasks (reading/writing emails, tweets, reddit, etc.) through an AI. Stay tuned for more posts about interesting things you can do with MCPs!

i slept on MCPs... but they are pure DISRUPTION

the world of apps/windows/websites is DEAD

(people just don't know it yet)

So, I'm starting something to show everyone how powerful this can be

& ofc building in public + open source

MY GOAL: eliminate ALL windows, apps,… pic.twitter.com/4bpwCRScop

— neo (@NamanyayG) April 25, 2025

Further Reading

• My MCP experiment
• Setting up MCPs on Windows
• Official MCP Docs
• List of interesting MCP servers

But the key is knowing how to communicate with the AI properly.

Here’s my collection of prompts that actually work in real-world scenarios.

Getting to the Root of Problems

The most common mistake developers make is treating symptoms rather than causes. This prompt helps you break that cycle:

Analyze this error/bug:
[paste error]

Don't just fix the immediate issue. Identify the underlying root cause by:
1. Examining potential architectural problems
2. Considering edge cases that might trigger this
3. Suggesting a comprehensive solution that prevents similar issues

Focus on fixing the core problem, not just the symptom. Before giving a solution, give me a reasoned analysis about why and how you're fixing the root cause.

When to use it: Whenever you hit a frustrating bug that keeps coming back despite your fixes. This approach saves hours of debugging.

Understanding AI-Generated Code

Never blindly implement code you don’t understand. This prompt ensures you know exactly what you’re adding to your codebase:

Can you explain what you generated in detail:
1. What is the purpose of this section?
2. How does it work step-by-step?
3. What alternatives did you consider and why did you choose this one?

When to use it: Every single time you get code from an AI. No exceptions. Your future self will thank you.

Debugging

When you’re truly stuck on a problem, sometimes you need to break out of your usual thought patterns. This prompt helps you systematically explore possibilities from multiple angles:

Help me debug this issue: [code and logs]

Reflect on 5-7 different possible sources of the problem, thinking from a variety of creative angles that you might not normally consider. 

Distill those down to 1-2 most likely sources.

Ideate on which one it could be and add logs to test that.

Give a detailed analysis on why you think you've understood the issue, how it occurs, and the easiest way to fix it.

When to use it: When stuck debugging serious issues. This prompt forces the AI to step back and consider the problem holistically rather than diving too quickly into a single possible explanation.

Code Reviews

AI can catch issues human reviewers might miss:

Review the code in the files [include files here]

Focus on:
1. Logic flaws and edge cases
2. Performance bottlenecks
3. Security vulnerabilities
4. Maintainability concerns

Suggest specific improvements with brief explanations. First, give a detailed plan. Then, implement it with the least changes and updating minimal code.

When to use it: Before submitting PRs or after finishing a feature but before considering it “done.”

Refactoring

Transform spaghetti code into something maintainable:

Refactor this function to be more:
[paste code]

Make it:
- More readable (clear variable names, logical structure)
- Maintainable (smaller functions with single responsibilities)
- Testable (easier to write unit tests)

Ensure that you do not change too much and that this part of the code remains useable without changing other parts that might depend on it.

First, explain your changes and why they improve the code. 

When to use it: When your code has grown unwieldy over time. Use this only for small parts of the code, you are likely to break things if you refactor too much at once.

Security

I wrote an entire guide on security recently where I cover how to audit your code for common vulnerabilities.

Rage Prompting

Sometimes, frustration can actually help get results from AI. The “rage prompt” works surprisingly well. Feel free to add more rage depending on your patience levels:

This code is DRIVING ME CRAZY. It should be doing [expected behavior] but instead it's [actual behavior]. 
PLEASE help me figure out what's wrong with it:
[paste code]

When to use it: When you need direct results without excessive explanation.

Conclusion

The right prompts don’t just save time: they fundamentally change how quickly you can ship reliable products.

By using these prompts consistently, you’ll avoid the common issues of AI development while capitalizing on its strengths.

What prompts have saved you time in your own development process? I’d love to hear about them.

But, what I found… disturbed me.

Everyone wore the same badges, slept in nap pods, played the same games, and ate at the same cafeterias. I couldn’t escape the realization that I was looking at a daycare for adults.

That day, I silently promised myself I would never work in such an environment.

Adult Daycare

In recent months, I’ve connected with many people working at Big Tech companies. They’re all paid extremely well and enjoy enviable work-life balance. Yet almost without exception, they share a common trait: deep frustration with their jobs.

Let’s acknowledge some positive facts about Big Tech companies:

• They pay extraordinarily well
• They offer flexible work schedules & generous PTO

But there’s a catch:

• Employees typically work on tiny, fragmented slivers of massive projects
• A significant portion of the workday disappears into meetings, documentation, and communication
• Promotion-chasing and office politics consume enormous mental energy

Seeing these patterns, it’s no surprise my Big Tech friends feel unfulfilled.

But the question that took me years to answer was: why do these companies deliberately foster such a work culture?

Insiduous Reality

There’s a form of corporate doublethink inside Big Tech that only became clear to me after reaching adulthood.

I first sensed it during my teenage visit, watching Google shower us with free gifts for open source contributions that had virtually no business value. It reminded me of the saying: “If something is free, you are the product.”

Google Code In wasn’t about open source at all. It existed solely to give programming-savvy students a taste of the Google lifestyle, to implant the idea of working there as early as possible. The free swag, the campus tour, the friendly recruiters — it was all strategic.

I’ve since realized the truth: Big Tech companies massively overpay for one critical reason: they don’t want talented individuals to work anywhere else.

Don’t Let Them Work Anywhere Else

These trillion-dollar companies understand a terrifying truth: if brilliant young developers actually got together, they could build business models that would utterly disrupt traditional tech giants.

So what’s their solution? Simple: don’t let that talent work anywhere else.

Of course, they can’t force anyone, so they seduce with what talented people want: money, prestige, comfort, and the illusion of impact.

And to succeed, they must capture the right talent at precisely the right moment. I call this deliberate strategy “talent capture.”

Talent Capture

First, they have to recruit talent from top schools. Next, they must retain these recruits for at least 4-5 years: long enough to drain away the courage of youth and install mindsets that make it nearly impossible to leave.

They’ve perfected this through three techniques:

• Offering compensation packages that dwarf anything else available to new graduates, easy to do with the absurd profit margins in software.
• The trap of “equity” and “vesting.” By withholding a significant portion of compensation until completing four years, they dangle the golden carrot that keeps talent locked in place.
• Creating environments where making mistakes doesn’t have any harsh consequences, making people risk-averse.

During those critical four years, they methodically:

• Encourage employees to climb the hedonic treadmill by displaying the lifestyle of senior employees
• Make them comfortable with unsustainable spending habits
• Fragment work to such a degree that no one develops the comprehensive skills needed to build something independently
• Create bubbles where everyone believes this is simply “how work is”

Breaking Free

By the time most people realize they’re trapped, they’re already deeply enmeshed. The golden handcuffs rewire their brains.

I’ve watched friends transform from innovators to people who measure success by equity packages. Their dreams of building something of their own gradually dissolve into discussions about which team might offer better promotion prospects.

Meanwhile, with each passing year, the courage required to leave grows exponentially. The financial risk of pursuing your own ideas seems increasingly irrational when compared to the millions from staying put. What can be done?

Your Creative Potential

If you’re reading this while working at a Big Tech company, you might be feeling defensive or dismissive. That’s normal. We all protect the choices we’ve made.

But ask yourself honestly: when was the last time you built something that genuinely excited you?

For those outside looking in, wondering if you’re missing out by not landing that coveted FAANG job: perhaps you’ve accidentally avoided the most sophisticated trap ever created?

Remember, your most valuable asset isn’t your coding ability or your degree. It’s your capacity to imagine and build something new. And that’s precisely what the adult daycare is designed to extinguish.

The Path Forward

If this post resonates, remember you are not alone. If you’re already caught in the system, recognize that the longer you stay, the harder it becomes to leave. Consider setting a firm exit date and working backward from there. And make sure you save aggressively instead of matching the lifestyle inflation around you.

For those still deciding their path, understand that there’s nothing wrong with spending a few years at Big Tech to build skills and savings. The danger comes when those “few years” become a decade because the golden handcuffs tightened so gradually you never noticed.

Your talents are too valuable to waste on making already wealthy shareholders slightly wealthier. I don’t think that the world needs trillion-dollar companies perfecting ways to further capture our attention and data.

What we instead need are builders willing to solve real problems, even when the challenges seem impossible.

The big tech daycare was never designed for your fulfillment. It was designed for your containment.

The choice, as always, remains yours.

But at least now you understand the game.

For months, I’ve watched developers praise LLMs while silently cleaning up their messes, afraid to admit how much babysitting they actually need.

I realized that LLMs don’t actually understand codebases — they’re just sophisticated autocomplete tools (with good marketing.)

After two years of frustration watching my AI assistants constantly “forget” where files were located, create duplicates, and use completely incorrect patterns, I finally built what the big AI companies couldn’t — or wouldn’t.

I decided to find out: What if I could make AI actually understand how my codebase works?

Illusion of Comprehension

Last December, I hit my breaking point. My supposedly “intelligent” AI kept generating components that didn’t follow our established patterns. When I pointed this out, it apologized — and then proceeded to make the exact same mistake ten minutes later.

This wasn’t a one-off. This was the norm.

The problem became clear: these AI tools don’t have any actual understanding of codebases as interconnected systems. They’re operating on small context windows and failing spectacularly at maintaining a mental model of the project.

What makes this particularly frustrating is how the marketing from major AI companies implies their tools “understand” your code. They don’t. They’re making educated guesses — and the difference becomes painfully obvious on any moderately complex project.

Junior vs Senior Mindset

While thinking about this problem, I went back to first principles and tried to analyze how senior developers think about a codebase:

• Junior developers focus on “what” and “how” — they look at specific implementation details to solve immediate problems. They can write functioning code, but they often miss the bigger picture.
• Senior developers focus on “why” and “what if” — they maintain a mental model of the entire system, understand how components interact, and anticipate ripple effects of changes. They distinguish between code that’s incidental versus foundational.

I realized LLMs often operate like junior developers, not senior ones:

• They get lost in large codebases because they lack a high-level understanding.
• They write duplicate functionality rather than recognizing reuse opportunities.
• They operate on trial and error, rushing to write code without understanding the complete context.
• They follow patterns inconsistently, not grasping their underlying purpose.

My goal became clear: could I make AI think more like senior developers by helping improving its model of the codebase?

Breakthrough

The solution came to me during a 2 AM coding session, while I was dealing with yet another incorrectly generated file: what if we treated the codebase as a hierarchical knowledge graph instead of flat files?

Human developers don’t memorize entire codebases. We build mental models of how components relate to each other. We understand that some code is boilerplate, while other sections are critical business logic. We naturally view code through different “lenses” depending on what we’re trying to accomplish.

I developed what I call “Ranked Recursive Summarization” (RRS), an algorithm that starts from the leaves of a project’s directory tree and recursively builds understanding upward using LLMs:

# pseudocode:
def ranked_recursive_summarization(folder):
    if is_file(folder):
        chunks = split_into_chunks(read_file(folder))
        ranked_chunks = rank_by_importance(chunks)
        return summarize(ranked_chunks)
    
    summaries = []
    for child in folder.children:
        summary = RRS(child)
        summaries.append(summary)
    
    return summarize(summaries)

This worked shockingly well. I implemented this algorithm and released it on Reddit, there were hundreds of people asking for access in the same day.

But, I soon realized it wasn’t enough. Depending on what I was trying to work on, RRS missed certain details. If it had information about architecture and data models, it missed out on frontend components. If it was too focused on UI, it missed out on describing data flow.

I had to think deeper: what makes a certain part of the code important?

Lensed Understanding

My second insight led to the truly transformative technique: “Prismatic Ranked Recursive Summarization” (PRRS).

Instead of having one global definition of “importance,” PRRS analyzes code through multiple conceptual lenses:

# pseudocode:
def prismatic_rrs(folder, lenses=['architecture', 'data_flow', 'security']):
    summaries = {}
    for lens in lenses:
        context = f"Analyze importance from {lens} perspective"
        summaries[lens] = RRS(folder, context=context)
    return summaries

The results were undeniable. AI suddenly understood:

• Where files should logically be placed
• Which patterns to follow
• How to extend existing abstractions instead of creating new ones
• When to reuse code vs. create new implementations

I updated my code to include PRRS, and the quality of results shot up. Plain RRS doesn’t work well on monorepos, but PRRS is able to clearly understand and explain much larger codebases.

Honestly, the approach isn’t particularly complex or compute-intensive. The big AI companies could have implemented something like this from the beginning. But they haven’t, because it doesn’t align with their incentives of getting results for the lowest token costs.

Why This Matters

The implications go far beyond fixing basic errors. When AI truly understands your codebase:

1. Technical debt becomes visible through the “architecture” lens
2. Security vulnerabilities emerge naturally through the “security” lens
3. Junior developers can navigate complex projects with senior-level insight
4. Onboarding time for new team members decreases dramatically

There’s a darker side as well. As AI gets better at understanding codebases, the value of certain types of programming knowledge decreases: the mid-level programmer who primarily translates requirements into code without architectural insight may find themselves increasingly squeezed.

After experimenting with these techniques for several weeks, I eventually packaged them into a tool called Giga AI. I built it initially to solve my own frustrations, but other developers kept asking to try it after seeing how it changed my workflow. Developers who use Giga report less time spent correcting AI-generated code, are able to ship faster, and feeling less frustrated.

Implementation

Even without my specific tool, you can improve your AI assistant’s code understanding:

• Create manual summaries of your most important directories and files
• Ask an AI to further improve your manual documentation
• Create and ensure multiple documentation files, each from a different “lens”, based on your project
• Include relevant files into AI’s context as needed

These approaches won’t be as seamless as a purpose-built solution, but they’ll dramatically improve your results compared to the default experience.

Context is the Future

I believe we’re at the beginning of a fundamental shift in how AI understands complex systems like codebases. The next generation of tools won’t just create embeddings of your code — they’ll build rich mental models from multiple perspectives, just like experienced developers do.

The companies that embrace this approach will leapfrog those still focused on token prediction alone. And developers who learn to leverage these sophisticated tools will have sustainable advantages that mere “prompt engineering” can’t match.

The future belongs to those who see AI not as a replacement for human developers, but as a force multiplier for human ingenuity.

And that future starts now.

What frustrations have you experienced with AI? I’d love to hear your stories at hi@nmn.gl

The current wave of AI tools promises to 10x your development speed. What they don’t mention is how they can also 10x your debugging time if implemented poorly. I’m building tools to solve exactly this problem, and I’m sharing some lessons I’ve learned along the way.

1. Structure Your AI’s Context

The “context” is the only thing the AI knows. If it’s incomplete, the AI will make mistakes. To increase accuracy, you need to provide the AI with as much relevant context as possible.

1. Create a project_milestones.md file that contains an overview of the project and your goals, along with a list of milestones and their descriptions. You may generate this file using chatgpt or claude, or you can create it manually. Then, reference it in your rules. Example:

    Phase 1: Manual Operations & Testing
    - Basic API integration
    - Database schema setup
    - Basic OpenAI integration
    - Manual data collection script
    - Manual analysis trigger
    - Manual review interface
    Phase 2: ...
   

2. Maintain a documentation.md file that tracks things relevant to your project from different perspectives. This might include, but not limited to:
   • API endpoints and their request/response formats
   • Database schemas
   • Function specifications
   • Architecture decisions
3. Set up clear rules in your .cursorrules file to ensure that the AI uses the newly created files:

     Project Management:
     - Reference @project_milestones.md for all feature implementations
     - Reference @documentation.md for all API endpoints
     - Ensure new code aligns with defined milestones
   

2. Break Down Complex Tasks

Back-and-forth with the model often leads to compounding errors. Keep tasks focused. When something breaks, don’t spiral into a debugging maze. Instead:

1. Revert to a previous working state using the checkpoints feature or git.
2. Break the task into smaller, isolated changes. Test each tiny change independently, only once it’s working, move on to the next change.
3. If the model starts creating new problems while fixing old ones, stop and reassess. Revert to a previous working state, then start the task again. Do not keep working in a long chat, because as the context grows, the AI becomes more likely to make mistakes.

3. Use the Right Models

There are so many AI models, understand the strengths and weaknesses of each and use the right ones at the right time. Adapt your AI workflow based on task types:

For Planning:

• Use reasoning-focused models (like 3.7 max mode)
• Create high-level architecture decisions first
• Plan feature roadmaps and save it in md files like project_milestones.md

For Implementation:

• Use standard models for code generation (my favorite is sonnet 3.5)
• Ensure each task is well-defined and small
• Test each change independently
• Commit to git early and often

Making It Work In Practice

Here’s a practical setup that works:

1. Project Structure:

   ├── .cursor/
   │   ├── rules
   ├── docs/
   │   ├── project_milestones.md
   │   └── documentation.md
   └── src/
   

2. Regular Maintenance:
   • Reindex your codebase regularly in Settings → Cursor settings → Features
   • Update documentation as you complete milestones by tracking architecture decisions and their reasoning
3. Development Workflow:
   • Start each session by referencing your project context defined in the documentation.md and project_milestones.md files
   • Work in small, testable increments
   • Update milestone progress and documentation consistently, you can even ask the AI to do it for you
   • Document learnings and edge cases
   • Commit to git early and often

Looking Forward

The teams who will win with AI are the ones with solid fundamentals. This structured approach might seem annoying at first, but it’s the difference between AI being a productivity multiplier versus a technical liability in the long-term.

Remember: AI is a powerful tool, but it needs clear boundaries and expectations. By implementing these principles, you’re building a foundation that can reliably scale as AI capabilities grow.

The day started by nerding out on the retro computers, hardware labs, and 3d printers they have; followed by the first breakfast bagel of my life. I feel incredibly fortunate to be surrounded out by so many talented programmers and am looking forward to the next three months with my new friends!

As part of our first day, we had a workshop about pair programming. For those who don’t know, pair programming involves two people working together on one computer, helping accomplish a specified programming goal and sharing ideas and approaches with each other. It’s one of the best ways to connect with fellow programmers, you learn a lot about each other.

Presley and I were paired together and tasked to build a “Mastermind” game in an hour using Python. Mastermind is basically Wordle’s predecessor but uses colors instead of letters. I don’t know idomatic Python, but fortunately Presley is extremely knowledgeable so we were a quite capable team.

We built out a basic TUI Mastermind implementation in around 45 minutes. We originally planned to convert it to a full GUI at the end, but we were pragmatic and realized that we weren’t going to be able to do that in the remaining time.

Instead, we decided to go in a slightly different direction: why not emojis?

We finalized our entire theme around the concept of emojis, making the final version called “Emoji Mastermind”. Instead of colors, you use emojis. Instead of ‘pegs’, you get hearts. A fun twist on the classic game. We demonstrated to our peers to much applause!

Check out Emoji Mastermind on Github, I’d love to have you try it out!

By the way, if you’re interested in taking your programming skills to the next level, check out the Recurse Center and consider applying!

For those who missed it, Andrej Karpathy recently shared his thoughts on what he calls “vibe coding” — essentially surrendering code comprehension to AI tools and hoping for the best. His exact words? “I ‘Accept All’ always, I don’t read the diffs anymore.”

I have learnt a lot from Karpathy and use AI tools daily, but there’s a world of difference between augmenting your capabilities and completely surrendering your understanding.

Hidden Costs of Vibing

Last month, I encountered a particularly annoying bug in my payment system. The code looked clean — (since ChatGPT had helped me write it). But when users started reporting random issues with their payments not being recognized, I couldn’t just paste the error into an AI and pray. I had to understand the underlying payment management logic and the exact request flow to fix it.

This is where “vibe coding” falls apart. The real problem isn’t just about reading code — it’s about maintaining the intellectual ownership of our systems. When Karpathy says “The code grows beyond my usual comprehension, I’d have to really read through it for a while,” he’s describing a fundamental breakdown in engineering responsibility.

Exponential Technical Debt

Technical debt compounds exponentially when you don’t understand your code. Each “vibed” solution becomes a black box, and these black boxes multiply. Soon, you’re building on top of foundations you don’t comprehend.

A recent feature I implemented initially took this route. The AI-generated solution worked, but when I needed to optimize it for performance, I was stuck. I couldn’t optimize what I didn’t understand. I ended up rewriting it from scratch, this time ensuring I understood every line.

Security Nightmares

The security implications of “vibe coding” are… unreal. When you don’t understand your code, you can’t properly assess its vulnerabilities.

Last week, I reviewed some AI-generated authentication code that looked perfectly fine at first glance. But upon closer inspection, the OpenAI API keys were exposed to anyone who knew how to inspect the network calls. This kind of oversight happens when we trust AI without understanding security best practices.

A Better Path Forward

The real danger isn’t in using AI — it’s in surrendering our understanding to it. Vibe coding might work for a weekend project, but it’s catastrophic for any serious software.

While coding my AI that makes software development faster, I’ve developed a comprehensive approach that balances AI assistance with engineering excellence:

1. When using AI tools, start with a clear architectural vision. Before generating any code, document your requirements, constraints, and expected behavior. This becomes your validation framework for any AI-generated code.

2. Instead of accepting entire functions or components from AI, break them down into smaller, understandable chunks. I’ve developed a three-step process:
   • Generate small, focused pieces of functionality
   • Review and understand each piece thoroughly
   • Integrate only after validation and testing
3. Make sure the AI has a complete context about your project. It should include:
   • Why the project exists
   • Business logic, explaining the “why” not just the “how”
   • How various subparts of the project interact with each other
   • Where and how are important third party dependencies used
   • Explanation of the data schema and model
4. Develop a testing strategy that forces you to understand the code:
   • Write tests before accepting AI-generated code
   • Test edge cases explicitly
   • Implement integration tests that verify system behavior, or at least do that manually
5. Even as a solo developer, I maintain a strict code review process for AI-generated code:
   • Review all generated code as if it came from a junior developer
   • Verify security implications
   • Ensure proper error handling

Looking Forward

We’re at a crucial junction in software engineering. The path of “vibe coding” might seem appealing, offering quick solutions and temporary productivity boosts.

But the real innovation, the sustainable progress, comes from maintaining deep understanding while embracing AI’s capabilities.

The next time you’re tempted to blindly accept AI-generated code, remember: true engineering excellence isn’t about velocity — it’s about building systems you can understand, maintain, and evolve.

Now that’s a vibe worth protecting.

Owen isn’t alone. Unfortunately, AI coding assistants often generate functional but insecure code unless explicitly prompted about security concerns.

After walking Owen through securing his application, I realized these lessons could help others. So I compiled this comprehensive security checklist for vibe coders — the same advice that saved Owen’s project.

I also wrote up a “vibe security prompt” at the bottom of the article. Give that to your AI of choice and secure your application!

Set Up Proper Logging

What to do: Ensure that all your code is logged consistently, including error cases. You can do that with simple console.log statements, or use structured logging with tools like Winston or Pino.

Why it matters: Good logging practices help identify security incidents and troubleshoot issues without exposing sensitive information.

Implementation tips:

• Use a consistent format, so you know where each log is originating from
• Use different log levels (error, warning, info)
• Never log sensitive data like passwords or tokens

Protect Environment Variables

What to do: Add .env.local and similar files to your .gitignore immediately and manage sensitive information properly.

Why it matters: Exposed credentials are among the most common causes of security breaches. A single leaked API key can compromise your entire system or result in unexpected bills.

Implementation tips:

• Add sensitive files to .gitignore before your first commit
• Set up environment variables manually in deployment platforms like Vercel/Netlify
• Never hardcode credentials in your application code
• If you accidentally expose secrets, rotate them immediately

Validate Inputs Server-Side

What to do: What if a malicious attacker tries to send improper data to your app, trying to break it? Client-side checks can easily be bypassed. Make sure to always implement comprehensive server-side validation. You can use libraries like Zod.

Why it matters: Client-side validation can be bypassed, making server-side validation essential for security.

Implementation tips:

• Validate data structure, types, and format
• Implement validation before processing any user input
• Handle validation errors gracefully without exposing system details

Use Established Authentication Providers

What to do: Leverage authentication services like NextAuth, Clerk, or Supabase instead of building authentication from scratch.

Why it matters: Authentication is notoriously complex to implement securely. Small mistakes can lead to account takeovers and data breaches.

Just let someone else handle it. I usually go with Supabase Auth, but I’ve heard that Clerk is good as well.

Use API Abstraction Layers Properly

What to do: Instead of allowing direct database calls from client code, establish server functions that handle data access.

Why it matters: Proper API abstraction prevents unauthorized data access and improves performance by centralizing business logic.

Implementation tips:

• Client-side code should only call API endpoints, never database functions directly
• Implement proper authentication and authorization checks in your API layer
• Structure API functions to return only necessary data

Implement Rate Limiting

What to do: Add rate limiting to all public-facing endpoints, especially authentication routes.

Why it matters: Without rate limiting, attackers can perform brute force attacks or overwhelm your server with requests.

Implementation tips:

• Limit each user to a reasonable number of requests per minute/hour
• Set different limits for different endpoints based on sensitivity
• Limit by both IP and user ID to prevent bypass attempts

Fix ALL Linter Errors

What to do: Resolve linter warnings and errors as they occur, don’t save them for later.

Why it matters: Linters often flag potential security issues along with code quality problems.

Implementation tips:

• Configure your IDE to show linter errors in real-time
• Group errors by type and fix systematically
• Consider using AI assistants to help fix linter errors efficiently

Making AI-Generated Code More Secure

The key to getting secure code from AI assistants is asking the right questions. Here are strategies I’ve found effective:

• Request security reviews — After generating functional code, ask the AI to audit it for security vulnerabilities
• Break down complex requests — Generate basic functionality first, then separately focus on securing it
• Be explicit about security concerns — Specifically mention authentication, data validation, and error handling
• Prompt for best practices — Ask for modern security standards for your specific framework or language

Vibe Security Prompt

How to use: Copy and paste this prompt into Claude 3.7 Sonnet along with your github repository or a zip file containing all your code.

Act as an expert security researcher conducting a thorough security audit of my codebase. Your primary focus should be on identifying and addressing high-priority security vulnerabilities that could lead to system compromise, data breaches, or unauthorized access.

Follow this structured approach:

1. ANALYSIS PHASE:
   - Review the entire codebase systematically
   - Focus on critical areas: authentication, data handling, API endpoints, environment variables
   - Document each security concern with specific file locations and line numbers
   - Prioritize issues based on potential impact and exploitation risk

2. PLANNING PHASE:
   - For each identified vulnerability:
     * Explain the exact nature of the security risk
     * Provide evidence of why it's a problem (e.g., potential attack vectors)
     * Outline specific steps needed to remediate the issue
     * Explain the security implications of the proposed changes

3. IMPLEMENTATION PHASE:
   - Only proceed with code modifications after completing analysis and planning
   - Make minimal necessary changes to address security issues
   - Document each change with before/after comparisons
   - Verify that changes don't introduce new vulnerabilities

Key Focus Areas:
- Exposed credentials and environment variables
- Insufficient input validation
- Authentication/authorization bypasses
- Insecure direct object references
- Missing rate limiting
- Inadequate error handling and logging
- Unsafe data exposure

DO NOT:
- Make cosmetic or performance-related changes
- Modify code unrelated to security concerns
- Proceed with changes without explaining the security implications
- Skip the analysis and planning phases

After each modification, explain:
1. What security vulnerability was addressed
2. Why the original code was unsafe
3. How the new code prevents the security issue
4. What additional security measures should be considered

Final Thoughts

The democratization of software development through AI tools is revolutionary, allowing more people to bring their ideas to life. But with this power comes responsibility. Security can’t be an afterthought — it must be integrated from the beginning.

The gap between “vibe coding” and production-ready applications isn’t insurmountable, but it requires deliberate attention to security fundamentals. As I continue developing my own AI code enhancement tool, I’m focused on solving these security challenges for the next generation of developers.

By implementing these practices, you’ll transform AI-generated code from a security liability into a solid foundation for your applications.

Your users deserve it, and your future self will thank you.

Here’s my tried-and-tested method for solo developers looking to leverage AI to make SaaS products.

Disclaimer: While my approach requires minimal manual coding, you’ll still need a basic understanding of concepts to be able to deliver quality results. Always work with a learning mindset, and don’t do things without understanding what’s going on.

A Beautiful UI

I begin with Lovable to generate a beautiful user interface. This AI builder excels at creating clean, professional UIs and comes with a well-structured tech stack.

First, focus solely on building static screens — no databases or authentication yet.

Starting with a tool like Lovable rather than coding from scratch offers two significant advantages:

• You can test and refine the UI before adding complexity
• The dependencies and stack configuration are professionally handled, eliminating the version conflicts

Once satisfied with your interface, connect the project to GitHub and clone the repository to your local machine using GitHub Desktop.

Build Feature by Feature

Next, I open the repository in an AI coding assistant like Cursor (more affordable) or Roo Code (higher quality, but more expensive and complex). After installing:

1. Provide a detailed explanation of my app’s purpose
2. Have the AI generate comprehensive documentation in a /docs/ folder
3. Build features one by one, always asking the AI to implement error handling and console logging

For authentication and databases, I typically use Supabase and have the AI assist with integration, being careful not to expose API keys.

Debugging Strategically

Errors are inevitable when building with AI. I’ve found it’s best to expect a 50% error rate and develop debugging strategies accordingly:

For simple errors:

• Test each feature individually
• Use console logs to identify issues
• Feed error messages back to the AI for fixes

For complex errors:

• Use RepoMix (I use the Cursor extension) to copy crucial parts of the codebase
• Paste the code into a more powerful reasoning model like OpenAI’s O1-Pro or DeepSeek R1
• Ask the model to create a detailed technical breakdown of the bug and specific actions to fix it
• Have your coding assistant implement these fixes

This approach not only resolves errors but also helps you understand how your code works, improving your ability to manage the project over time.

Security and Deployment

Before deploying, use RepoMix and upload the entire repository to Claude to find security vulnerabilities, especially checking for accidentally exposed API keys or other sensitive information. This is arguably the most crucial step, and I will write a detailed post about this soon.

Tips for Success

• Progress incrementally with small, testable features
• Implement thorough console logging to aid debugging
• When stuck, escalate to more powerful models rather than struggling with the same tool
• Read and understand the fixes proposed by AI to build your own knowledge
• Document everything as you go, ensuring your AI assistants maintain context

Looking Forward

The current generation of AI tools won’t replace professional software engineers anytime soon, especially for enterprise software with complex business logic and compliance requirements. However, for developers with basic knowledge, these tools serve as powerful amplifiers that can dramatically accelerate development.

As someone building AI tools for code generation myself, I’m constantly amazed by how far this technology has come. Now is the perfect time to experiment with these capabilities and discover how they can enhance your development workflow.

Recently, I discovered an MCP that’s cut my debugging time in half.

MCP as a term is being overused too much, but just understand them as APIs that AI agents can use.

I found an MCP to let AI see and interact with your browser, called BrowserTools. Once you integrate it with Cursor, you can ask it see what’s going on in your browser and the console.

The “aha” moment”

I recently faced issues in my payment flow, where the payment callback didn’t seem to be working.

I simply typed: “Check what’s happening when users click the pay button and fix any JavaScript errors.”

Rather than me needing to do it manually, the AI was able to recognize the console logs, correlate them to the appropriate lines of code, and then fix it. All by itself.

How it works

BrowserTools MCP consists of three components:

1. A Chrome extension that captures console logs, network activity, screenshots, and DOM elements
2. A Node server that processes this information locally on your machine
3. An MCP server that lets AI clients like Cursor interact with your browser data

Everything stays on your local machine — no data gets sent to external services.

Ways you can use this

1. Console log analysis

Instead of scanning through hundreds of console messages, I ask: “Summarize the console logs and identify recurring errors.”

Last week, the AI caught a memory leak causing performance issues that I would have missed. Fixed before deployment, saving both user frustration and future debugging time.

2. Network traffic debugging

Rather than clicking through dozens of network requests, I ask: “Which API calls are failing when users complete a payment?”

The AI immediately identified a mismatch in the authorization token, causing 401 errors. Pattern spotted and fixed in minutes.

3. DOM analysis

When facing layout issues, I say: “Why aren’t these validation messages showing correctly?”

The AI examines DOM structure, CSS rules, and JavaScript interactions to find the exact problem. It once spotted I was appending error messages to elements without changing their visibility—fixing a UI animation bug.

Getting started

There are detailed instructions in the BrowserTools MCP installation docs, but a brief overview:

1. Install the Chrome extension using developer mode
2. Set up the Node server locally using npx @agentdeskai/browser-tools-mcp@1.2.0
3. Configure the MCP server in your IDE. Here are instructions for Cursor

The 10-15 minute setup is worth every second. Start with simple prompts like:

“Show me all errors in the console” “Check why this button click isn’t working” “Analyze network requests to the /api/users endpoint”

The future

As a solo developer, browser debugging used to be one of my biggest time sinks. Now, I spend less time fixing bugs and more time building features that matter to users.

By embracing AI as a development partner and powering it up with MCP, I’ve been able to accomplish much more than I could alone.

Have you tried using AI for browser debugging? I’d love to hear your experiences on Twitter.

His business, built entirely with AI assistance and “zero hand-written code,” was experiencing bypassed subscriptions, maxed-out API keys, and database corruption.

His follow-up admission made this notable: “as you know, I’m not technical so this is taking me longer than usual to figure out.”

As someone deeply immersed in the AI code generation space, I’ve been watching this unfold with a mix of sympathy and frustration. Let me be clear — I’m not against AI-assisted development. My own tool aims to improve code generation quality. But there’s a growing and dangerous fantasy that technical knowledge is optional in the new AI-powered world.

After observing many similar (though less public) security disasters, I’ve come to a controversial conclusion: vibe coding isn’t just inefficient — it’s potentially catastrophic.

The Lie of Vibe Coding

Recently, I was working late on a particularly thorny code generation problem when a message from an old SF friend popped up: “Dude, have you seen this? I just launched my side project without writing a single line of code. Just vibe coding!”

He shared his screen with me — a surprisingly polished-looking SaaS product that helped small business with their career path. The UI was clean and the features worked. All built by telling Windsurf what he wanted, occasionally getting frustrated, refining his prompts, and never once understanding the underlying technology.

“That’s great,” I said, genuinely impressed. “What security measures did you implement?”

His blank stare told me everything.

Some time later, his API keys were scraped from client-side code that AI had carelessly left exposed. He had to negotiate with OpenAI to forgive his bill.

Today, his “side project” is offline while he’s trying to learn authentication and security from first principles.

The vibe coder’s dream turns into a nightmare not when the code doesn’t work, but when it works just well enough to be dangerous.

The (Invisible) Complexity Gap

The problem isn’t that AI tools can’t generate secure code — they often can, with the right prompts. The problem is that without understanding what you’re building, you don’t know what you don’t know.

I witnessed this firsthand when helping another friend debug his AI-generated SaaS for teachers. Looking through the code, I discovered:

• No rate limiting on login attempts
• Unsecured API keys
• Admin functions protected only by frontend routes
• DB manipulation from frontend

When I pointed these out, he was genuinely confused. “But it works fine! I’ve been testing it for weeks!”

This is what I’m calling the “invisible complexity gap” of vibe coding — the difference between “it works on my machine” and “it’s secure in production.” The gap exists because modern development tools, especially AI assistants, are extraordinarily good at hiding complexity and making things seem simpler than they are.

AI won’t warn you about the security holes you don’t know to ask about. The perfect circular trap: you can’t secure what you don’t understand, and you don’t understand what AI builds for you.

When Vibe Coding Backfires

The reddit thread that went viral last week is filled with experienced developers smugly saying “I told you so” — but that’s not helpful. The reality is that we’re entering an era where more people want to build software, and AI makes that possible in ways it wasn’t before.

But the consequences of security failures are becoming more severe. When that vibe coder’s SaaS got compromised last week, real money was lost. All because someone believed that understanding your tools was optional.

I’m not saying everyone needs to be a security expert or low-level programmer. But there’s a minimum viable knowledge required to responsibly deploy software that handles other people’s data, and AI hasn’t eliminated that requirement — it’s just obscured it.

What Vibe Coders Can Actually Do

If you’re currently building with AI assistance and recognize yourself in this post, don’t panic. Here’s what you can do right now:

1. First, adopt a learning mindset. You don’t need to understand every line of code, but you should understand the architecture — how data flows through your system, where it’s stored, and how it’s protected.

2. Second, use AI to educate, not just to implement. When Cursor or ChatGPT or Claude generates code for you, ask it to explain the security implications. Ask it what could go wrong. Ask it what you’re missing.

3. Third, implement basic security practices from day one — proper authentication, HTTPS everywhere, environment variables for secrets, and regular backups at minimum.

4. This one won’t be possible for many, but, consider bringing in expertise for a security review before launching anything that handles sensitive data. Even a few hours with someone who knows what to look for can save you from disaster. Feel free to email or shoot me a DM on Twitter if you really can’t find someone, if I have the time I’ll try to help.

The Future of Vibe Coding

For every vibe coder reading this who feels defensive or attacked — I get it. You’re not wrong for wanting to build. AI has democratized creation in beautiful ways.

But democratizing creation means democratizing responsibility too.

The current wave of vibe coding tools optimize for immediate gratification: making something work now. The next generation needs to optimize for sustainable comprehension: making something work reliably over time.

The most revolutionary aspect of AI coding tools isn’t that they let you skip understanding, it’s that they compress years of learning into months. They don’t replace the journey — they accelerate it.

Let’s embrace that acceleration while rejecting the fantasy that we can outsource understanding entirely. The future belongs to those who use AI as a powerful tool, not a replacement for knowledge.

Not just vibes. Vibes plus knowledge.

That’s how we build things that last.

Further Reading

• The Day I taught AI to think like a Senior Developer
• My Cursor AI Workflow That Actually Works in Production
• Context, Structure, Organization: Framework for AI-powered Development
• AI Prompt Playbook (Prompts that Work in Production)
• Security Checklist & Prompts for Cursor Vibe Coders
• Cursor Workflows to build SaaS products in 2025

I’ve been coding with Cursor AI since it was launched now while building my SaaS. The internet seems split between “AI coding is a miracle” and “AI coding is garbage.” Honestly, it’s somewhere in between.

Some days Cursor helps me complete tasks in record times. Other days I waste hours fighting its suggestions.

After learning from my mistakes, I wanted to share some cursor workflows and best practices that actually work in production.

Setting Up a .cursorrules File That Actually Helps

The biggest improvement I made was creating a .cursorrules file. It’s basically a set of instructions that tells Cursor how to generate code for your specific project.

Mine core file is pretty simple — just about 10 lines covering the most common issues I’ve encountered. For example, Cursor kept giving comments rather than writing the actual code. One line in my rules file fixed it forever.

Here’s what the start of my file looks like:

- Only modify code directly relevant to the specific request. Avoid changing unrelated functionality.
- Never replace code with placeholders like `// ... rest of the processing ...`. Always include complete code.
- Break problems into smaller steps. Think through each step separately before implementing.
- Always provide a complete PLAN with REASONING based on evidence from code and logs before making changes.
- Explain your OBSERVATIONS clearly, then provide REASONING to identify the exact issue. Add console logs when needed to gather more information.

Don’t overthink your rules file. Start small and add to it whenever you notice Cursor making the same mistake twice. You don’t need any long or complicated rules, Cursor is using state of the art models and already knows most of what there is to know.

I continue the rest of the “rules” file with a detailed technical overview of my project. I describe what the project is for, how it works, what important files are there, what are the core algorithms used, and any other details depending on the project. I used to do that manually, but now I just use my own tool to generate it. You can do it using Cursor itself, but I just find it faster to have it done for me with one click.

Giving Cursor the Context It Needs

My biggest “aha moment” came when I realized Cursor works way better when it can see similar code I’ve already written.

Now instead of just asking “Make a dropdown menu component,” I say “Make a dropdown menu component similar to the Select component in @components/Select.tsx.”

This tiny change made the quality of suggestions way better. The AI suddenly “gets” my coding style and project patterns. I don’t even have to tell it exactly what to reference — just pointing it to similar components helps a ton.

For larger projects, you need to start giving it more context. Ask it to create rules files inside .cursor/rules folder that explain the code from different angles like backend, frontend, etc. This is such a powerful technique that I created a Cursor extension to do it automatically.

My Daily Cursor Workflow

In the morning when I’m sharp, I plan out complex features with minimal AI help. This ensures critical code is solid.

I then work with the Agent mode to actually write them one by one, in order of most difficulty. I make sure to use the “Review” button to read all the code, and keep changes small and test them live to see if they actually work.

For tedious tasks like creating standard components or writing tests, I lean heavily on Cursor. Fortunately, such boring tasks in software development are now history.

For tasks more involved with security, payment, or auth; I make sure to test fully manually and also get Cursor to write automated unit tests, because those are places where I want full peace of mind.

When Cursor suggests something, I often ask “Can you explain why you did it this way?” This has caught numerous subtle issues before they entered my codebase.

Avoiding the Mistakes I Made

If you’re trying Cursor for the first time, here’s what I wish I’d known:

• Be super cautious with AI suggestions for authentication, payment processing, or security features. I manually review these character by character.
• When debugging with Cursor, always ask it to explain its reasoning. I’ve had it confidently “fix” bugs by introducing even worse ones.
• Keep your questions specific. “Fix this component” won’t work. “Update the onClick handler to prevent form submission” works much better.
• Take breaks from AI assistance. I often code without Cursor and came back with a better sense of when to use it.

Moving Forward with AI Tools

Despite the frustrations, I’m still using Cursor daily. It’s like having a sometimes-helpful junior developer on your team who works really fast but needs supervision.

I’ve found that being specific, providing context, and always reviewing suggestions has transformed Cursor from a risky tool into a genuine productivity booster for my solo project.

The key for me has been setting boundaries. Cursor helps me write code faster, but I’m still the one responsible for making sure that code works correctly.

What about you? If you’re using Cursor or similar AI tools, I’d love to hear what’s working or not working in your workflow.

Further Reading

• The Day I taught AI to think like a Senior Developer
• Context, Structure, Organization: Framework for AI-powered Development
• AI Prompt Playbook (Prompts that Work in Production)
• Security Checklist & Prompts for Cursor Vibe Coders
• Cursor Workflows to build SaaS products in 2025

The recent releases of Claude 3.7 and GPT-4.5 were… surprising. I read articles where AI researchers admitted these systems solved problems faster than they could.

We’re racing toward a world where humans might not be the smartest ones anymore. And we’re doing it willingly, even eagerly.

A year ago, I laughed off AGI fears. Then, I watched these new models solve in seconds what took me hours. I suddenly felt… outdated.

Moving Too Fast

The acceleration trajectory is terrifying. Last year, we had text generators. Now we have systems designing novel protein structures, generating cinematic videos, and solving mathematical conjectures that stumped human mathematicians for decades.

This path frightens me. We can still understand what today’s AI creates, but that won’t last.

Have you seen this meme? It depicts the “Shoggoth” from H.P. Lovecraft’s Cthulhu Mythos, a monstrous, tentacled creature that is beyond our understanding. It’s being used to describe AGI.

AGI will be like that, an intelligence that we cannot comprehend, even though it might smile at us as we ‘align’ it us. We’ll face an intelligence that makes all humans combined look simple. We’ll be like ants watching humans build a city.

What Happens When We’re No Longer The Smartest

The debates around AGI typically fall into two simplistic camps: extinction or utopia.

I believe the reality will be a bit more subtle: AGI won’t hate or love us, it will just make us optional.

At a recent SF AI conference, after several drinks, the conversation turned philosophical. I asked the room: “How do you treat ants when building a house?”

We don’t hate ants. We don’t wish them harm. But, we also don’t ask for their opinions. They simply don’t matter to our decisions.

That’s going to be our future with AGI.

Hollywood Gets it Wrong (As Usual)

Pop culture show us dramatic confrontations — robot uprisings, AI-human battles, and brave human fighters finding the off switch at the very last moment.

The real danger will be far more subtle and inescapable. A super-intelligent AI wouldn’t be centralized, nor it will need physical domination.

It will seamlessly influence markets, control information, and redirect resources, as and when it pleases. It will understand human psychology so completely that manipulating us will be trivial. It will lie freely and will be able to make us believe anything. And for it, all of this will be like child’s play.

It will sneak up on us. We wouldn’t even notice the transition from being in control to being managed. We’d still feel like we’re making our own decisions when we’re actually being gently herded.

Can We Do Anything?

Let’s be brutally honest — superintelligent AGI is inevitable. The competitive and economic advantages are too great for any nation to voluntarily fall behind. If the U.S. slows down, China won’t. If China slows down, some startup in Estonia won’t.

So what realistic options remain?

First, we need massive societal restructuring. Our entire civilization is built around human intelligence having economic value. That foundation is crumbling. We need to start reimagining society not based on what humans can produce, but on what we uniquely are.

Second, acceptance. I’ve started reading ancient Stoics alongside modern philosophers. They asked the same question we face: how to find meaning when confronted with forces beyond our control. I’ve found strange comfort in accepting that humans may not always be the most intelligent beings on Earth.

Third, augmentation may be our bridge to relevance. These days I use AI so much that it feels like an extension of my thoughts rather than a separate entity. And this is just the beginning, the line between human and machine will continue to blur.

Looking Forward

Some nights, coding in my apartment, I look at these AI models and feel obsolete. I feel like a Neanderthal witnessing the first Homo sapiens.

Other days, I remind myself that being intelligent isn’t everything that matters about being human. Our capacity for connection, for play, for finding beauty in imperfection — that is more valuable than raw compute, right?

I don’t know what’s next. But, what I know is that we’re rushing into the biggest change in human history with almost no planning.

The question isn’t if AGI is coming — it’s whether we’ll be able to shape it in ways that preserve humans relevance and dignity.

And lately, I try to spend more time away from screens, focusing on what makes us uniquely human.

Because when AGI arrives, our humanity might be all we have left.

We’re at this weird inflection point in software development. Every junior dev I talk to has Copilot or Claude or GPT running 24/7. They’re shipping code faster than ever. But when I dig deeper into their understanding of what they’re shipping? That’s where things get concerning.

Sure, the code works, but ask why it works that way instead of another way? Crickets. Ask about edge cases? Blank stares.

The foundational knowledge that used to come from struggling through problems is just… missing.

We’re trading deep understanding for quick fixes, and while it feels great in the moment, we’re going to pay for this later.

Back when we had to actually think

I recently realized that there’s a whole generation of new programmers who don’t even know what StackOverflow is.

Back when “Claude” was not a chatbot but the man who invented the field of information entropy, there was a different way to debug programming problems.

First, search on Google. Then, hope some desperate soul had posed a similar question as you had. If they did, you’d find a detailed, thoughtful, (and often patronizing) answer from a wise greybeard on this site called “Stack Overflow”.

Here’s one of the questions I posed 12 years ago. See the top answer by Nathan Wall (who has earned a whopping 10,000+ points and is apparently a CTO since 2015):

Can you imagine that some dude just wrote an answer with this level of detail? Raw, without any AI? And for free?

My original question was thoroughly answered of course, but he didn’t stop there. I learnt so many new facts. Some of them I didn’t even know existed, and others I didn’t even want to know but now they’re etched in my brain forever.

This was the best case scenario if you had a question. If you stumbled upon a particularly difficult problem and didn’t find someone who had answered your question already, then tough luck.

Junior devs these days have it easy. They just go to chat.com and copy-paste whatever errors they see. Even lazier ones don’t do the 30 second effort of toggling to a browser window, they just use a tool that does it all in one place.

It’s convenient and quick.

But, there’s still one reason that StackOverflow was superior:

Reading discussions by experienced developers about your topic is the best way to learn.

Here’s a graph to explain what I mean:

AI gives you answers, but the knowledge you gain is shallow. With StackOverflow, you had to read multiple expert discussions to get the full picture. It was slower, but you came out understanding not just what worked, but why it worked.

Think about every great developer you know. Did they get that good by copying solutions? No—they got there by understanding systems deeply and understanding other developers’ thought processes. That’s exactly what we’re losing.

I’m not trying to be that guy who complains about “kids these days.” I use AI tools daily. I’m literally building one. But we need to be honest about what we’re trading away for this convenience.

What can we do?

I’ve been experimenting with ways to fix this (because let’s face it, AI isn’t going anywhere). Here’s what’s actually working:

• First, use AI with a learning mindset. When it gives you an answer, interrogate it. Ask it why. Sure, it takes longer, but that’s literally the point.
• Next, find your tribe. Reddit, Discord, Mastodon—wherever the smart people hang out. That’s where you’ll find the real discussions happening. The ones that make you go “huh, I never thought about it that way.”
• Do code reviews differently. Instead of just checking if the code works, start a conversation with your team. What other approaches did they consider? Why did they pick this one? Make understanding the process as important as the end result.
• Build things from scratch sometimes. Yes, AI can generate that authentication system for you. But try building one yourself first. You’ll write worse code, but you’ll understand every line of it. That knowledge compounds.

Looking forward

Here’s the reality: The acceleration has begun and there’s nothing we can do about it. Open source models are taking over, and we’ll have AGI running in our pockets before we know it. But that doesn’t mean we have to let it make us worse developers.

The future isn’t about whether we use AI—it’s about how we use it. And maybe, just maybe, we can find a way to combine the speed of AI with the depth of understanding that we need to learn.

Let me know if you’ve found other ways to balance this. Or tell me I’m just being an old man yelling at clouds. Either way, let’s figure this out together.

I stared at my terminal facing those red error messages that I hate to see. An AWS error glared back at me. I didn’t want to figure it out without AI’s help.

After 12 years of coding, I’d somehow become worse at my own craft. And this isn’t hyperbole—this is the new reality for software developers.

The Decay

It crept up on me subtly.

First, I stopped reading documentation. Why bother when AI could explain things instantly?

Then, my debugging skills took the hit. Stack traces now feel unapproachable without AI. I don’t even read error messages anymore, I just copy and paste them.

I’ve become a human clipboard, a mere intermediary between my code and an LLM.

Previously, every error message used to teach me something. Now? The solution appears magically, and I learn nothing. The dopamine hit of instant answers has replaced the satisfaction of genuine understanding.

Deep comprehension is the next thing that was affected. Remember spending hours understanding why a solution works? Now, I simply implement AI suggestions. If they don’t work, I improve the context, and just ask the AI again. It’s a cycle of increasing dependency.

Then come the emotional changes. Previously, it was a part of the joy of programming to solve new problems. Now, I get frustrated if AI doesn’t give me a solution in 5 minutes.

The scariest part? I’m building an AI-powered development tool, but I can’t shake the feeling I’m contributing to the very problem that’s eroding our collective skills.

The Rehab Plan

I’m not suggesting anything radical like going AI-free completely. Instead, I’m starting with “No-AI Days.” One day a week where:

• Read every error message completely
• Use actual debuggers again
• Write code from scratch
• Read source code instead of asking AI

I won’t lie, it sucks. I feel slower, dumber, and more frustrated.

But I can also see the difference. I feel a stronger connection with my code and a sense of ownership, which had slowly disappeared with AI. Plus, I learn a lot more.

The (Uncomfortable) Truth

We’re not becoming 10x developers with AI.

We’re becoming 10x dependent on AI. There’s a difference.

Every time we let AI solve a problem we could’ve solved ourselves, we’re trading long-term understanding for short-term productivity. We’re optimizing for today’s commit at the cost of tomorrow’s ability.

I’m not suggesting we abandon AI tools—that ship has sailed. But we need rules of engagement. Here’s some ideas that I have:

• No AI for problems that you haven’t tried to understand first
• Read and understand all AI-suggested solutions
• Regular periods of coding without AI assistance
• Focus on learning patterns, not just fixing immediate issues

I won’t lie, I don’t think I’ll be able to follow these rules all the time. But it’s a start, and I strongly believe anyone who’s new to programming should definitely follow all of these rules.

Right now, somewhere, a new programmer is learning to code. They’ll never know the satisfaction of solving problems truly on their own. They’ll never experience the deep understanding that comes from wrestling with a bug for hours.

We’re creating a generation of developers who can ask AI the right questions but can’t understand the answers. Every time AI goes down, they’re exposed as increasingly helpless. As of now, AI isn’t capable enough to replace programmers fully, but this will only get worse as it improves. The real question isn’t whether AI will replace programmers. It’s whether we’re replacing ourselves.

Try coding without AI for just one day. The results might surprise you.

Update (01 Feb)

This post resonated a lot with the developer community! I feel overjoyed and humbled.

Here’s some interesting statistics:

• Over 1,250,000 views in one week
• 2,500 upvotes on Reddit /r/programming, 1,000 on /r/webdev
• 100 comments on Hacker News

The signal-to-noise ratio was abysmal—for every meaningful tech development, I had to wade through countless memes, heated arguments, and clickbait. I knew there had to be a better way.

The Birth of an Idea

That’s when I decided to build my own solution: an AI-powered trend analyzer that could do the heavy lifting for me.

The goal was simple: automatically extract meaningful tech discussions, analyze them for trends, and generate content ideas—all without getting lost in the noise.

How It Works

First, we need a source of information to understand trends.

And the obvious choice is right in front of us—Reddit.

I used an LLM to pick news-worthy subreddits from the list of top 250 subreddits, to allow anyone to find trends from a niche of their choice. I also asked the LLM to choose an emoji and color scheme for each subreddit. The result is something like this:

technology: {
  url: "https://redlib.catsarch.com/r/technology/top?t=day",
  name: "Technology",
  emoji: "💻",
  color: {
    gradient: "from-blue-500 to-indigo-600",
    accentLight: "bg-blue-50 text-blue-600",
    accentDark: "bg-blue-500 text-white"
  },
  description: "General technology news and discussions",
  category: "technology"
},
programming: {
  url: "https://redlib.catsarch.com/r/programming/top?t=day",
  name: "Programming",
  emoji: "👨‍💻",
  color: {
    gradient: "from-purple-500 to-indigo-600",
    accentLight: "bg-purple-50 text-purple-600",
    accentDark: "bg-purple-500 text-white"
  },
  description: "Software development and programming",
  category: "technology"
},

To find the most recent trends, I chose the “top of the day” links from each subreddit. You’ll note that I’m using an alternative Reddit API, this is to get a cleaner HTML that can be scraped easily.

Then, the system works in two main stages:

1. Data collection with Firecrawl Extract

The foundation of this system is built on Firecrawl’s powerful “extract” endpoint—an AI powered feature that goes beyond simple web scraping.

Instead of just pulling raw HTML and requiring complex parsing logic, the extract endpoint allows you to define a schema and get structured data back directly:

const schema = z.object({
  links: z.array(z.object({
    linkId: z.string(),
    title: z.string(),
    number_of_upvotes: z.number(),
    number_of_comments: z.number(),
    website_domain: z.string(),
    topics: z.array(z.string()),
    companies_mentioned: z.array(z.string()),
    linkHref: z.string()
  }))
});

What makes this particularly powerful is that Firecrawl uses AI to understand and extract exactly what you need. You just define the shape of the data you want, and it handles all the complexity of finding and structuring that information.

2. Trend analysis with Claude

Next, Claude 3.5 Sonnet analyzes the collected data.

I spent considerable time crafting a prompt that generates structured, actionable insights. For each trend, it provides:

• A viral score based on engagement metrics
• A clear trend title and overview
• Source links for reference
• Three detailed content suggestions with viral hooks and narrative angles

What makes this particularly powerful is how Claude contextualizes the information. It doesn’t just list facts – it understands the broader implications and suggests multiple angles for content creation.

Future Enhancements

I’m already using it to find and analyze trends. I usually don’t bother with news and I don’t find most of it interesting, but this works for me to summarize discussions and find new topics. Till now, it has helped me ideate my last blog post, and we’ll see how much it helps me in the future.

On a technical level, I’m excited about several potential improvements:

• Adding more data sources beyond the current set
• Creating an API for other creators to build upon
• Adding customizable topic filters
• Generating automatic tweet threads and article outlines

It’s all open source so I’ll be more than happy if there’s any contributions!

Try It Yourself

GitHub Repository: namanyayg/trends-ai

Live Demo: trends.nmn.gl

As someone building AI developer tools and studying their real-world implementation, I believe this fundamentally misunderstands both the current state of AI and the role of mid-level engineers.

Here’s what Meta is missing.

The Current Reality

Current AI coding assistants excel at specific tasks: generating boilerplate, explaining code, and helping with routine programming tasks.

But there’s a crucial gap between writing isolated functions and understanding complex systems. In our testing, even the most advanced AI tools consistently fail when dealing with interconnected systems. They’ll generate syntactically perfect code that introduces subtle runtime errors by missing critical system dependencies.

Look, AI coding tools are already impressive. Companies like Lovable and Bolt (both $4M+ ARR) are showing real value. But they’re thriving in a completely different space: helping indie developers build from scratch, assisting with smaller projects, turning non-developers into casual coders.

That’s valuable! But it’s not exactly the same as maintaining Meta’s massive codebase.

The Problems

In building our own AI developer tools (and surveying 87 developers about their experiences), I’ve identified three fundamental challenges that separate AI from mid-level engineers:

1. Context: Mid-level engineers maintain a comprehensive mental model of the system architecture. They understand service boundaries, data flows, and system dependencies.

   Current AI tools are unable to keep large codebases in context, making it impossible to reason about system-wide impacts.

2. Memory: Engineers retain crucial historical context about the codebase.

   They understand why certain architectural decisions were made, which optimization attempts failed, and what edge cases led to current implementations.

   AI tools lack this persistent understanding, treating each interaction as a new problem.

3. Systems Thinking: Engineers excel at understanding cross-system interactions. They can identify potential performance bottlenecks, predict cascading effects of changes, and spot hidden dependencies.

   Current AI tools lack this capability for higher-level system analysis.

The Future

The path to truly effective AI development tools requires solving several fundamental technical challenges:

Advanced code understanding

We need AI systems that can maintain persistent models of entire codebases.

This includes understanding architectural patterns, coding conventions, and system dependencies.

Current research in program analysis and semantic code understanding shows promise, but we’re still far from production-ready solutions, because of the context problem.

Temporal codebase analysis

Future systems will need to understand code evolution over time.

This means tracking architectural decisions, failed approaches, and the reasoning behind current implementations through git history, PRs, and documentation.

This requires advances in both retrieval systems and causal reasoning about code changes.

Multi-agent development

The complexity of software development suggests a multi-agent approach. Here’s what this could look like:

• A planning agent that breaks down high-level requirements into specific technical tasks. This requires knowledge of system architecture, technical constraints, and development patterns. Our experiments show this agent needs to maintain a graph of system dependencies and understand technical debt implications.
• Implementation agents specialized by domain (frontend, backend, infrastructure) that understand specific ecosystem best practices. These need to coordinate on interface contracts and maintain consistency across boundaries.
• A testing agent that combines property-based testing approaches with historical bug patterns to generate comprehensive test suites. This agent would need access to production monitoring data to prioritize high-risk scenarios.
• A review agent that checks for architectural consistency, performance implications, and security considerations. This requires understanding of both local code changes and system-wide impacts.

Could we build this by 2025?

Maybe.

The building blocks are there: large language models, graph databases for code understanding, advanced retrieval systems.

But we’re not just teaching AI to write code—we’re teaching it to think about code the way experienced developers do.

The Evolution of Software Engineering

The real transformation won’t be replacement, but evolution. We’re seeing the emergence of two distinct specializations:

Traditional Software Engineers will increasingly focus on high-level system design, architectural decisions, and complex business logic.

Rather than being replaced, they’ll be elevated.

The mundane parts of their job - boilerplate code, routine debugging, basic feature implementation - will be handled by AI. This lets them focus on what humans do best: understanding business context, making architectural decisions, and solving novel problems.

AI Engineering Specialists will emerge as a new role, focusing on building and maintaining AI-enhanced development environments. This involves:

• Designing prompt architectures for different development scenarios
• Building and maintaining custom training sets from company codebases
• Developing tools for AI/human collaboration in development workflows
• Optimizing AI system performance and resource usage

Both roles will require strong software engineering fundamentals, but with different specializations. Traditional engineers will need to understand AI capabilities and limitations to effectively collaborate with AI tools. AI specialists will need deep understanding of development workflows to build effective AI systems.

A New Reality

The future I see isn’t about AI replacing developers—it’s about fundamentally transforming how we build software. Imagine:

• Engineers spending 80% of their time on creative problem-solving instead of routine implementation
• Development velocity increasing by an order of magnitude while maintaining quality
• Systems that catch subtle bugs before they reach production by understanding entire codebases
• Teams focusing on innovation while AI handles the implementation details

Developers who successfully integrated AI tools report spending significantly more time on system design and creative problem-solving. They’re not being replaced—they’re being augmented in ways that make their work more impactful.

The key isn’t to resist this change, but to shape it. We have the opportunity to create development environments that combine human creativity and insight with AI’s speed and precision.

Want to be part of building this future? I’m working on these exact problems at the intersection of AI and development tooling. Reach out at hi@nmn.gl - let’s make software development more powerful, more creative, and more human.

If you are not redirected automatically, follow this link to the article.

If you are not redirected automatically, follow this link.

Modern software development is complex. Our projects have hundreds of files, intricate dependencies, and carefully thought-out architectural decisions.

The Problem

Anyone who’s used AI coding assistants has experienced this: you ask for help with a feature, and the AI generates code that completely ignores your existing patterns. Or worse, it breaks your carefully planned architecture.

After experiencing this frustration firsthand, I started building Giga—a different kind of AI coding assistant that maintains deep, persistent understanding of your entire codebase.

How Giga Works

The core innovation in Giga is what I call the “project brain”—a smart context management system that:

• Automatically analyzes your project structure, dependencies, and architectural patterns
• Maintains a living SPEC.md file that captures your project’s technical decisions and constraints
• Integrates with git to track meaningful changes and evolve its understanding
• Uses this persistent context to ensure AI suggestions align perfectly with your existing architecture

Early Results

The initial beta testing has been enlightening. Developers report that Giga:

• Eliminates the need to repeatedly explain project structure to AI
• Significantly reduces instances of AI suggestions breaking existing architecture
• Maintains consistent understanding even as codebases grow

It started with a frustrating Thursday afternoon. Our code analysis service was hitting rate limits constantly, and I was doing what any reasonable engineer would do: optimizing our token usage, implementing better queuing, and trying to squeeze maximum performance from our chosen model.

Nothing worked. Or rather, everything worked a little bit, but not enough.

The Discovery

We were using Amazon Bedrock’s Nova-Pro model for our code analysis service. It’s a powerful model with a quota of 100,000 tokens per minute. Sounds good enough, right? That’s what we thought too.

But here’s the thing about analyzing code: it’s bursty. A developer pushes 50 files, and suddenly you need to process everything now. Not in a nice, evenly distributed way that would make your rate limiter happy.

During one particularly frustrating debugging session, I temporarily switched to a “lesser” model (Llama-3) while debugging what I thought was an issue with Nova-Pro. And then something interesting happened: our overall throughput went up.

The Math

My current quotas:

Nova-Pro: 100,000 tokens/minute
Llama-3: 60,000 tokens/minute

But it wasn’t just about raw numbers. The real magic happened when we started treating these models as complementary resources rather than primary/backup options.

The Conventional Wisdom (That We Ignored)

Traditional wisdom says:

1. Pick the best model for your use case
2. Optimize your usage of that model
3. Implement proper rate limiting
4. Maybe have a backup model for failover

We threw that out the window. Instead, we:

1. Use both models simultaneously
2. Route larger batches to Nova-Pro
3. Send smaller batches to Llama-3
4. Let them handle rate limits independently

Why This Shouldn’t Work (But Does)

The obvious objection is cost. Why pay for two models when you could optimize one? But here’s where it gets interesting:

1. Rate limits are not linear: When you hit a rate limit, you don’t just lose the excess capacity - you often lose entire batches of work that need to be retried.
2. Context switching is expensive: Every time you hit a rate limit and have to retry later, you’re losing context. With two models, you maintain momentum.
3. Different models, different strengths: What we found was that Llama-3 actually performed better on smaller, simpler files, while Nova-Pro excelled at complex, interrelated code analysis.

The Implementation

Here’s the interesting part. Instead of complex rate limiting logic, we built a simple model alternation strategy:

1. Route larger batches to Nova-Pro
2. Send smaller batches to Llama-3
3. Let them handle rate limits independently

Here’s some pseudocode to illustrate the idea:

// Model-specific quotas and characteristics
const MODEL_QUOTAS = {
  'nova-pro': {
    tokensPerMinute: 100_000,
    maxKbPerBatch: 350,  // Conservative limit for large, complex batches
  },
  'llama-3': {
    tokensPerMinute: 60_000,
    maxKbPerBatch: 200,  // Better for smaller, simpler batches
  }
} as const;

/**
 * Pre-assigns models to groups based on their characteristics
 * Returns batches with their assigned models
 */
function createModelAwareBatches(fileGroups: FileGroup[]): { model: ModelId, batch: FileGroup[] }[] {
  // First, analyze and assign optimal models for each group
  const groupsWithModels = fileGroups.map(group => ({
    group,
    // Assign model based on group characteristics
    model: selectModelForGroup(group)
  }));

  // Create batches respecting each model's size limits
  const batches: { model: ModelId, batch: FileGroup[] }[] = [];
  let currentBatch: FileGroup[] = [];
  let currentModel: ModelId | null = null;
  let currentBatchSize = 0;

  groupsWithModels.forEach(({ group, model }) => {
    const groupSizeKb = group.totalSize / 1024;

    // Start new batch if:
    // 1. Is first batch
    // 2. Different model than current batch
    // 3. Would exceed model's size limit
    if (
      currentModel === null ||
      model !== currentModel ||
      currentBatchSize + groupSizeKb > MODEL_QUOTAS[model].maxKbPerBatch
    ) {
      if (currentBatch.length > 0) {
        batches.push({
          model: currentModel,
          batch: currentBatch
        });
      }
      currentBatch = [group];
      currentModel = model;
      currentBatchSize = groupSizeKb;
    } else {
      currentBatch.push(group);
      currentBatchSize += groupSizeKb;
    }
  });

  // Add the last batch
  if (currentBatch.length > 0 && currentModel) {
    batches.push({
      model: currentModel,
      batch: currentBatch
    });
  }

  return batches;
}

/**
 * Selects optimal model based on group characteristics
 * Complex groups -> Nova Pro
 * Simple groups -> Llama-3
 */
function selectModelForGroup(group: FileGroup): ModelId {
  // Complexity factors:
  // - Number of files in group
  // - Number of imports/dependencies
  // - Size of files
  // - Type of files (e.g., test files vs core logic)
  
  const COMPLEXITY_THRESHOLD = 0.7;  // Normalized complexity score threshold
  
  // Higher score = more complex
  const complexityScore = calculateComplexityScore(group);
  
  return complexityScore > COMPLEXITY_THRESHOLD ? 'nova-pro' : 'llama-3';
}

/**
 * Calculates normalized complexity score (0-1) based on group characteristics
 */
function calculateComplexityScore(group: FileGroup): number {
  // Size factor: Larger groups are more complex
  const sizeFactor = Math.min(group.totalSize / (20 * 1024), 1);  // Cap at 20KB
  
  // Dependency factor: More dependencies = more complex
  const dependencyFactor = group.complexity;  // Already normalized 0-1
  
  // File count factor: More files = more complex relationships
  const fileCountFactor = Math.min(group.files.length / 10, 1);  // Cap at 10 files
  
  // Weighted average of factors
  return (
    sizeFactor * 0.3 +
    dependencyFactor * 0.5 +
    fileCountFactor * 0.2
  );
}

/**
 * Process batches with assigned models, handling rate limits by switching models
 */
async function processBatches(batches: { model: ModelId, batch: FileGroup[] }[]): Promise<Result[]> {
  const results: Result[] = [];

  for (const { model, batch } of batches) {
    try {
      // Try with assigned model first
      const result = await processWithModel(batch, model);
      results.push(result);
    } catch (error) {
      if (isRateLimitError(error)) {
        // On rate limit, try alternate model
        const alternateModel: ModelId = model === 'nova-pro' ? 'llama-3' : 'nova-pro';
        try {
          const result = await processWithModel(batch, alternateModel);
          results.push(result);
        } catch (alternateError) {
          // If both models fail, let error handling middleware deal with it
          throw alternateError;
        }
      } else {
        throw error;  // Non-rate-limit errors are handled by middleware
      }
    }
  }

  return results;
}

The results were pretty good:

• ~1.8x throughput improvement
• 40% reduction in rate limit errors
• More consistent performance under load
• Most importantly, faster results == happier developers

Why This Matters Now

As AI services become more central to our applications, we need to start thinking differently about capacity and redundancy. The old patterns of primary/backup and single-model optimization might not be the best approach anymore.

The Trade-offs

Let’s be honest about the downsides:

• Higher potential costs
• More complex routing logic
• Potentially inconsistent results between models
• Additional monitoring requirements

But in our case, the benefits far outweighed these costs.

Looking Forward

This accidental discovery has changed how we think about AI service architecture. Instead of asking “which model is best?”, we’re now asking “how can different models work together?”

The future might not be about finding the perfect model, but about orchestrating multiple models effectively.

What do you think? Have you tried similar approaches? I’d love to hear about your experiences with AI service architecture.

The format was immaculate - every field properly typed, every attribute carefully specified, the suggestion clear and actionable.

There was just one problem: it fundamentally misunderstood how our authentication system worked.

The Structured Output Trap

The current narrative around structured outputs is compelling. OpenAI, LlamaIndex, and others promote them as the solution to AI reliability. The pitch is seductive: Define a schema, get perfectly formatted responses, never worry about parsing again.

It sounds perfect. It’s not.

Here’s a real example from my extension. Using function calling, I defined a schema for code review suggestions:

type CodeReviewSuggestion = {
  severity: 'critical' | 'warning' | 'info';
  category: 'security' | 'performance' | 'maintainability';
  location: {
    file: string;
    startLine: number,
    endLine: number
  };
  suggestion: string;
  impact: string;
  fix: {
    before: string;
    after: string;
    rationale: string;
  };
}

The AI generated this perfectly-structured response:

{
  "severity": "critical",
  "category": "security",
  "location": {
    "file": "src/auth/session.ts",
    "startLine": 45,
    "endLine": 52
  },
  "suggestion": "Move token validation before user data access",
  "impact": "Potential unauthorized data access",
  "fix": {
    "before": "const userData = await getUser(token); validateToken(token);",
    "after": "validateToken(token); const userData = await getUser(token);",
    "rationale": "Ensure token is valid before accessing user data"
  }
}

The response was perfectly structured. Every field was correctly typed. The suggestion seemed logical. There was just one critical problem: getUser() is idempotent and caches results, while validateToken() has side effects that refresh the token. The suggested reordering would break our token refresh mechanism.

This isn’t a parsing error or a hallucination in the traditional sense. The AI followed its output schema perfectly. It just made incorrect assumptions about our codebase’s behavior.

The Real Problem

I’ve found that the real challenge lies in what happens before and after those perfectly formatted responses. Building AI tooling has taught me that we’re optimizing for the wrong thing. While everyone focuses on making AI outputs more structured, the real challenges lie elsewhere:

1. Context Quality: The reliability of AI responses depends far more on the quality and structure of inputs than outputs. Sending normalized, validated context matters more than receiving structured responses.
2. Reality Validation: A perfectly structured response that contradicts project reality is worse than an unstructured response that gets the fundamentals right.
3. Failure Patterns: Most AI failures aren’t structural - they’re logical. The AI confidently produces well-structured responses that make incorrect assumptions about your codebase.

More importantly, structured outputs create a dangerous illusion of reliability. When you receive a perfect JSON response, you naturally tend to trust it more. This is exactly the wrong instinct.

A Different Approach

In my experience building an AI coding assistant, the most significant reliability gains came from what we did before and after the AI interaction, not from output formatting.

This points to a different future for AI tooling. Instead of obsessing about output structure, we need to focus on:

1. Better tools for preparing and validating AI inputs
2. More sophisticated reality-checking of AI suggestions
3. Explicit handling of AI failure modes that look structurally correct

Conclusion

Yes, structured outputs are valuable. But they’re also dangerous precisely because they’re so convincing. A malformed JSON response is obvious. A perfectly structured response that subtly misunderstands your application’s requirements is a time bomb.

For those building AI tools: Stop obsessing about output structure. Start obsessing about input quality and reality validation. Because in the real world, a perfectly formatted wrong answer is still wrong — it’s just harder to spot.

For 2025, I decided to get back into technical writing.

I’ve been obsessing over getting AI to actually understand production code. Not just generate it, but really grok what’s happening in a mature codebase.

After countless nights exploring this rabbit hole, I wrote about a breakthrough I had.

Sunday morning, I posted it on HackerNews. “Why not,” I thought, “maybe someone will find it interesting.”

Then I went back to my weekend.

The moment it hit #1

I was lazing around with my girlfriend when I pulled up HN, as one does every 27 minutes. My karma looked… different?

Wait.

Holy shit.

The post was #1 on the front page.

...FINALLY

I've had this dream since 14 years now

I AM RANK #1 on HACKERNEWS

!!!

(go check out my post folks!) pic.twitter.com/fiFpqaD0iz

— nmn (@NamanyayG) January 5, 2025

I literally jumped off the couch (my girlfriend still doesn’t understand what HN is but she got hyped seeing me hyped).

Then panic set in — I don’t even have analytics set up.

Quick dive into Google Analytics setup (yes yes, I know, I’ll switch to something open source soon, I hate Google’s invasive monopoly as much as you do).

The numbers started flowing in. Hundreds of views per minute. Over half from the US.

THANK YOU HACKERNEWS 🫡 pic.twitter.com/vcaqsIMwLL

— nmn (@NamanyayG) January 5, 2025

Here’s what those first crazy hours looked like. I was really surprised to see how much the US dominates the audience of HN, I thought it would be somewhat more equally distributed:

Another surprising fact was how much the traffic was from mobile. I thought it would be more desktop. However, this data point is skewed because of how most HNers would have ad blockers enabled on their desktop browsers:

But the real gold wasn’t in the traffic. It was in the discussion.

How HN really feels about AI

Reading through 200+ comments was like watching a fascinating experiment unfold. The evolution of the discussion revealed deep insights about how we really think about AI.

Phase 1: “Show me the code” (Hours 0-2)

The initial response was pure, unfiltered HN energy. Multiple users immediately pointed out that my implementation details were too vague:

“This hard coded string is doing some very heavy lifting. This isn’t anything special until this string is also generated accurately and consistently for any reasonable PR.”

Oof. Fair point.

What’s fascinating is how the early technical criticism followed a pattern:

• Request for implementation details
• Skepticism about real-world application
• Discussion about evaluation methods

But here’s what I didn’t expect: the harshest technical critics often became the most engaged participants.

The technical scrutiny made the discussion better. People weren’t just criticizing — they were sharing real solutions and experiences.

Phase 2: “Let me tell you about my AI adventures” (Hours 2-5)

As the post gained traction, something shifted. The discussion evolved from “prove it works” to “here’s what I’ve seen work”.

Developers started sharing war stories that revealed a fascinating pattern: everyone’s using AI, but nobody’s quite sure if they’re using it right.

“Just the other day I used cursor and iteratively implemented stories for 70 .vue files in few hours… something that would’ve taken me at least few days if not a week.”

The really interesting part? Almost everyone who shared a success story immediately followed it with a caveat. And everyone who shared a failure had a “but sometimes it’s amazing” moment.

This phase had the most nuanced takes. No one was purely pro or anti AI — just developers sharing real experiences and trying to make sense of this new world.

Phase 3: “But what does it all mean?” (After Hour 6)

As the comment section grew, the discussion took an interesting turn. Technical nitpicking gave way to broader discussions about AI tools in general.

The anthropomorphization debate kicked off when one user pointed out:

“Another cherry-picked example of an LLM doing something amazing, written about with a heavy dose of anthropomorphism.”

This sparked a fascinating thread about how we talk about AI. Another user defended the approach:

“To me, articles like this are not so interesting for the results… The problem is that there is still mystery on how to use them effectively. Articles like that are great for learning new prompting tricks.”

What The Comments Actually Revealed

Looking at all the discussion, there’s a clear pattern in how different groups approach AI tools. It’s not about pro-AI vs anti-AI — it’s about how much context you need before trusting the output.

Even the skeptics are using these tools — they’re just very specific about where and how.

That’s probably why the post resonated. We’re all trying to figure out how to use these tools effectively without breaking production. Some are just more… vocal about it than others.

The numbers behind the noise

The post stayed at #1 through Sunday morning. Here’s what that looked like in cold, hard data:

The US dominated with 3.5k readers, followed by UK (600) and Germany (560). What’s interesting is the city breakdown:

New York led with 355 readers, beating out Silicon Valley cities. This surprised me — I expected the bay area to dominate. The full top tech hub list:

• New York: 355
• London: 296
• San Jose: 222
• Seattle: 192
• San Francisco: 159
• Los Angeles: 144

Two things stand out:

• East Coast tech showed up strong (NYC readers > all Bay Area combined)
• European tech hubs made their presence known (London + Frankfurt + Berlin = 521 readers)

In total, 8,500+ people read the post. Not bad for a Sunday morning blog about AI understanding code.

Critical questions we need to solve

Reading through the discussion threads revealed something fascinating: while every comment approached AI differently, they all circled around the same core problems.

The technical debates weren’t really about my implementation — they were about fundamental challenges we’re all facing:

First, there’s the context problem. How much project context does AI need before it can make meaningful suggestions? More importantly, how do we provide that context efficiently? Several developers shared stories of AI seeming to understand their codebase, only to make changes that broke implicit patterns.

Then there’s the evaluation challenge. We know how to measure if code works, but how do we measure if AI truly understands what it’s modifying? The discussion showed that “working code” isn’t enough — we need ways to evaluate understanding.

But perhaps the most interesting questions came from teams already using AI. They weren’t asking if AI works, but how to work with it. When should AI suggest vs make changes? How do we maintain developer understanding when AI is modifying multiple files? What’s the right feedback loop?

What’s next

This weekened discussion revealed something bigger than just AI and code. It showed how our relationship with development tools is evolving.

A year ago, AI coding discussions centered around replacement fears and capability debates. Now? We’re deep in the trenches, figuring out integration patterns and evaluation frameworks. The question isn’t whether to use AI — it’s how to use it effectively.

That’s probably why this resonated. We’re all exploring this new territory, trying to find the right balance between automation and understanding, between efficiency and control.

The next few years will be fascinating. Not because AI will get better at coding (it will), but because we’ll get better at working with AI. The tools will evolve, but more importantly, so will our understanding of how to use them.

I’m excited to keep exploring these questions, and based on this discussion, I’m not alone. If you’re interested in this evolution of development, reach out (twitter @NamanyayG or email hi [at] nmn.gl).

The problems are real, the concerns are valid, and the solutions aren’t obvious. But fortunately, we’re software developers. And we’re used to solving problems.

Last week, I watched our AI choke on a React codebase - again. As timeout errors flooded my terminal, something clicked. We’d been teaching AI to read code like a fresh bootcamp grad, not a senior developer.

Here’s what I mean.

The Bootcamp vs Senior Mindset

Remember your first day reading production code? Without any experience with handling mature codebases, you probably quickly get lost in the details^[0]

But watch a senior dev review a massive PR:

• They jump straight to the core files
• Group changes by feature (“all auth changes, all db changes”)
• Build a mental model of architecture first
• Only then dive into implementation

Obvious in hindsight, right? This realization led us to completely rewire our analyzer.

The Experiment

Instead of dumping files linearly, we built a context-aware grouping system:

interface FileGroup {
  files: ProjectFile[];
  totalSize: number;
  groupContext: string; // 'auth', 'database', etc.
}

export const groupFiles = (files: ProjectFile[]): FileGroup[] => {
  // Group files by related functionality and size
  const fileInfos = files.map(file => ({
    file,
    size: file.content?.length || 0,
    context: getFileContext(file.path)
  }));

  // Process larger, more important files first
  fileInfos.sort((a, b) => b.size - a.size);

  const groups: FileGroup[] = [];
  let currentGroup = createEmptyGroup();

  for (const { file, size, context } of fileInfos) {
    if (shouldStartNewGroup(currentGroup, size, context)) {
      groups.push(currentGroup);
      currentGroup = createNewGroup(file, size, context);
    } else {
      addFileToGroup(currentGroup, file, size);
    }
  }

  return groups;
}

Then we changed how we prompt the AI. Instead of “analyze this file”, we give it context about the feature group first:

const buildGroupPrompt = (group: FileGroup): string => {
  return `
    Analyzing authentication system files:
    - Core token validation logic
    - Session management
    - Related middleware
    
    Focus on:
    1. How these integrate with existing auth patterns
    2. Security implications
    3. Performance impact on other systems

    Files to analyze:
    ${formatFiles(group.files)}
  `;
}

The Holy Shit Moment

The results broke our testing scripts. We thought it was a bug.

The AI went from:

"This file contains authentication logic using JWT tokens"

To:

"Warning: This auth change could impact websocket connections.
The token refresh logic shares patterns with the notification 
service (added last month), suggesting a potential race 
condition during high-traffic socket reconnects.

Related PR: #1234 (merged last week) modified the same
retry logic. Consider adding backoff."

That’s senior dev level awareness. It was catching connections we hadn’t explicitly taught it about.

What Actually Changed?

The magic isn’t in fancy ML or bigger models. It’s in mirroring how senior devs think:

1. Context First: We front-load system understanding before diving into code
2. Pattern Matching: Group similar files to spot repeated approaches
3. Impact Analysis: Consider changes in relation to the whole system
4. Historical Understanding: Track why code evolved certain ways

The Unexpected Side Effects

The system started catching things we didn’t design for:

• Spotting copy-pasted code across different features
• Flagging inconsistent error handling patterns
• Warning about potential performance bottlenecks
• Suggesting architectural improvements based on usage patterns

Why This Matters

Every few days there’s a new “AI-powered IDE” on Product Hunt. They’re solving the wrong problem. Making code suggestions without deep context is like having a brilliant junior dev who just joined yesterday - they’ll write clean code that subtly breaks everything.

The key isn’t better code generation. It’s better code understanding.

Open Questions

We’re still figuring out:

• When to refresh vs preserve historical understanding
• How to handle conflicting patterns in different parts of the system
• Whether to expose uncertainty in the analysis

What’s Next?

I’m curious if we can teach AI to spot other senior dev instincts:

• Identifying tech debt before it happens
• Suggesting architectural improvements
• Catching security issues from usage patterns
• Understanding unwritten team conventions

The problem isn’t making AI write more code. It’s teaching it to think about code the way experienced developers do.

[0] Previously said You probably did what I did - start at line 1, read every file top to bottom, get lost in the details., edited in response to feedback from advael

It also quietly broke our error tracking system, removed a crucial race condition check (that admittedly looked like a bug), and duplicated three utility functions with slightly different implementations.

Sound familiar?

The AI coding space is exploding right now. Cursor hit $50M ARR, Lovable.ai reached $4M in 4 weeks, and every day there’s a new “AI-powered IDE” on Product Hunt. Clearly, developers want AI assistance.

Yet despite these impressive numbers, I believe current AI coding tools are fundamentally solving the wrong problem. That’s why I’m building another one.

The Problem Isn’t Code Generation

I’ve spent countless hours with current AI coding tools. The code generation is mind-blowing. The autocomplete feels magical. But there’s a deeper issue that becomes apparent only when you use these tools on real projects.

A Reddit comment perfectly captured it (sic): “Have AI agent fix what I ask for and on the way break 2-25 other things is the usual timesink where 95% of my time spent with agents goes to.”

This resonated deeply with me. Why? Because it’s not about the AI writing bad code - the code is usually quite good! It’s about the AI not understanding the hidden complexity and implicit patterns in our codebases.

I recently asked AI to add error handling to a component. The code it generated was clean and followed best practices. It also:

• Added try-catch blocks that swallowed errors we specifically want to bubble up
• Created new utility functions that slightly differed from our existing ones
• Removed what looked like duplicate checks but were actually handling edge cases we discovered months ago

All technically correct code… that subtly broke our established patterns.

The Missing Piece: Project Context + Memory

When a senior dev joins your team, they don’t immediately start rewriting components. They take time to understand the invisible things:

• Why that weird-looking useEffect is actually handling a crucial race condition
• Why we’re using a specific pattern for error handling
• Which parts of the “messy” code are actually addressing important edge cases

Yet somehow, we expect AI to skip this crucial step and generate code in a vacuum.

I surveyed 33 developers about their AI tool usage. 76% use AI for code generation, but 85% reported spending significant time fixing AI-generated inconsistencies. Not because the code was bad, but because it didn’t align with their project’s reality.

A Different Approach

This is why I’m building a new AI coding IDE extension that prioritizes understanding over generation. Instead of seeing each request in isolation, it maintains project memory through git history, commit messages, and codebase patterns.

The technical challenges are significant. But based on the conversations I’ve had, this project understanding is the missing piece in current AI coding tools. Line-by-line code generation is incredibly powerful, but without project context, it’s like having a brilliant programmer with severe short-term memory loss.

I’m building this in public and would love to hear your thoughts. How do you currently maintain project knowledge with AI tools? What aspects of project context do you find most important?

P.S.: The project is in early development, with the first feature (project context management) already available. If you’re interested or want to know more, DM me on X (@namanyayg) or email me (hi [at] nmn.gl).

This is my journey of how I fixed it and how the latest version of my blog was born.

0. Initial Discovery

I woke up one day to a notice from DigitalOcean claiming “intrusion” originating from my VPS’ IP.

Well, of course my VPS couldn’t be at fault and this was a false alarm (classic denial).

…But when I noticed the path containing /wp-content/plugins/wp-striplple/, I could guess what has happened.

1. Confirmation & Anger

Could it really be that my multiple WordPress installs, many that I have not updated since many years, could have been hacked?

I read about this all the time, but certainly a hacked WordPress was something that happened to other people and not me!

Oh well.

As soon as I SSH’d into my server and opened my WP directory, I knew something was off. I had a lot of extra files present that I’m sure were not supposed to exist.

I deleted those which I could easily see, but then I checked all the WP sites that I was hosting. Seemed like most of them weren’t updated in years, so I had the easy option of shutting them down.

However, the site that was most impacted was my personal blog “Symmetrycode”. I had been blogging there since ~6 years. Now, the real posts on my blog were interspersed with articles with affiliate links. And worst of all, when I googled any article, my blog didn’t show up. I was deranked from Google for hosting malicious files.

At that point, I knew the Symmetrycode domain was dead. And I also knew that one day I’ll revive it.

Till then, I basically turned off each and every WP site I had installed by:

chown newuser:newuser -R . # giving ownership of all files to a new user without any rights
chmod 600 -R . # make it only accessible by current user, not anyone else

Now, the malware and all my sites were completely dead and inert. Phew?

2. Rebirth

At this point, I have lost faith in any system with a backend.

The best way to prevent a hack is to not have anything hackable at all.

And you know what’s something that has powered the internet since it’s inception and cannot be hacked? Plain ol’ HTML and CSS.

So, I decided to move all my work from the past and in the future to static site hosting by moving to Github Pages.

I started off with my homepage, which is now happily on Github.

Then, I created a new Jekyll site for this blog. To move my old content, I followed these steps:

1. Take a dump of all db data using mysqldump
2. Import it into a local WordPress install on XAMPP
3. Install the WordPress Jekyll Exporter plugin

I got all my old posts in a friendly and beautiful markdown format.

I made myself a new Jekyll theme called “Pyaar2”, after the original WordPress theme I created for Symmetrycode 7 years ago.

I finally was able to restore all posts and launch this blog around Christmas, as a small gift to myself.

Conclusion

It’s heartbreaking to lose my old domain and rankings, but I’m sure I can figure out how to fix them. I have it in my todo list to add redirects, Lessons learned:

• Every piece of code needs maintenance and upgrades. So minimize writing code and avoid hosting yourself.
• Avoid hosting anything with a backend, especially if you want it to last decades and want no maintenance hassle.
• Storage and CDNs are cheap as dirt. Don’t pay for a VPS. Try to make everything into a static site, build locally, and then use Github Pages or Cloudflare to host the built files.

Of course, the entire flow from beginning to end needs to be tested. Given the manual effort of uploading files and the long wait for LLM responses, we had to automate the entire test.

In the automation, I found many cases where an initial part of the test went correctly but a latter part got stuck and errored. Retrying from start would need at least ~1-2 minutes of waiting for all the initial cases to be processed, and I could not delete the initial cases either because the latter were connected with the response from the initial tests.

So I really had only one option — figure out how to save the state of a test frequently and allow resuming the test if there’s a crash.

To code this out, I broke down the problem into 2 parts:

• Making generic methods to load and save state
• Saving the state at needed parts

State methods to load and save

I like the pattern of Factory Functions, so I created a _stateManager factory function.

It took a testCode paramter to indicate what test is running, and created a private variable filePath which was used to save the state of the test.

const _stateManager = (testCode) => {
  const filePath = path.join(autosaveStateDirectory, `${testCode}-state.json`)

  return {
    load: async () => {
      // load only the steps that are before loading transactions
      // i.e. transactions must always be retested
      if (
        testsSteps.indexOf(testOutput.lastStepCompleted) >
        testsSteps.indexOf('UPLOAD_INITIAL_TRANSACTIONAL_DOCUMENTS')
      )
        return false
      try {
        const rawData = await fs.readFile(filePath, 'utf8')
        const data: TestOutput = JSON.parse(rawData)
        testOutput = data
        log(`Successfully loaded state! Last step completed: ${testOutput.lastStepCompleted}`)
        return true
      } catch (e) {
        console.error(e)
        return false
      }
    },
  }
}

The save function was easy: I just had to write the state to file.

save: async () => {
  await fs.writeFile(filePath, JSON.stringify(testOutput, null, 2))
  log(`Saved state after completing ${testOutput.lastStepCompleted}`)
  return true
},

For the load function, I also had to check whether the file exists or not.

load: async () => {
  try {
    const rawData = await fs.readFile(filePath, 'utf8')
    const data: TestOutput = JSON.parse(rawData)
    testOutput = data
    log(`Successfully loaded state! Last step completed: ${testOutput.lastStepCompleted}`)
    return true
  } catch (e) {
    console.error(e)
    return false
  }
  },

Setting up test steps

My test has a few steps like logging in, uploading documents, uploading transactions, etc. I represented those in an array

let testsSteps = [
  'LOGIN',
  'CREATE_PARTIES',
  'CREATE_RULES',
  'UPLOAD_INITIAL_TRANSACTIONAL_DOCUMENTS',
  'TRANSACTIONS',
  'UPLOAD_FINAL_TRANSACTIONAL_DOCUMENTS',
]

Before starting any test, I instantiated the factory into a variable stateManager

const stateManager = _stateManager(testInput.testCode)

Saving the state during test

I recorded all my state in a testOutput object, and stored the most recent completed step in lastStepCompleted.

At the start of each part, I updated stepKey which was the same as what I used in the testsSteps variable above.

// during the test, keep updating `testOutput` with data from the API
testOutput.parties = ...

testOutput.lastStepCompleted = stepKey
await stateManager.save()

Now, all that is left is to check if the specific part of the test has already loaded or not. If it has been loaded, skip that step entirely. This code should be at the very start of the test step.

const stepKey = 'CREATE_PARTIES'
if (testsSteps.indexOf(testOutput.lastStepCompleted) >= testsSteps.indexOf(stepKey)) {
  log('\tSkipping create parties due to loaded state')
  return false
}

Optionally, you might have to “rollback” your server to the most recent step as well. This completely depends on your server so I won’t include code for that, but a rollback could be as easy as deleting a few rows in your DB.

Conclusion

For good DX during long running tests, it’s important to be able to save and resume state as needed.

I came up with my own way to load and resume state, I am sure different libraries could have their own ways. But, I usually prefer writing my own code in such easy cases rather than depending on any abstractions.

With a simple factory function and a few changed lines during the tests, we were able to write a simple and easy to reason about test state manager.

// sanitize plain text query to only keep alphanumeric lowercase
const sanitizedQuery = query.trim().toLowerCase().replace(/[\W_]+/, '')
// split by space as basic tokenization
const queryTokens = sanitizedQuery.split(/\s+/)

const options = {
  where: {
    [Op.and]: queryTokens.map(token =>
      // check for presence of each token in lowercased product `title`
      Sequelize.where(Sequelize.fn('lower', Sequelize.col('title')), 'LIKE', `%${token}%`)
    )
  }
}
const results = await db.Product.FindAll(options)

The main cleverness of this snippet is in mapping the queryTokens to generate Sequelize.where() queries that compare the lowercased title with our token. Sequelize has some powerful features to interact with the database at a low-level, and this is a great example of that used in a real-world project

One of the existing, common solutions is Server-side Rendering or SSR. They render all content on your server and then send it to the client along with JS for interaction. There’s even a new wave of easy to use SSR-compatible tooling, like Nuxt.js (Vue) and Next.js (React). However, SSR does have downsides — it moves rendering load from client to server, and requires a node backend to be running.

A solid middle option is occupied by what’s called Prerendering, where you run a headless browser (either locally or on the server) to cache some of your site’s pages to disk. The Prerender SPA Plugin for Webpack makes it extremely easy to do all this.

Installation

(I’m assuming you’re using the Webpack template for vue-cli, where all your configuration files are in the ./build and you compile the final files to ./dist.)

We’re going to create a new Webpack configuration file for the prerendering. We’ll also add a script to our package.json as an alias.

First, install and save by running npm i prerender-spa-plugin or yarn add prerender-spa-plugin. Then create a new file under ./build named webpack.prerender.conf.js.

We can only prerender once we have a built index.html for us in the ./dist/ folder, so we need to run the existing build script to ensure we have that done correctly. Do so by requiring path, merge, and the production webpack config like so:

const path = require('path')
const merge = require('webpack-merge')
const baseWebpackConfig = require('./webpack.prod.conf')
const PrerenderSpaPlugin = require('prerender-spa-plugin')

const webpackConfig = merge(baseWebpackConfig, {

Drew Lustro and Chris Fritz have done a great job abstracting away the difficult work of prerendering, and so we simply add and configure their plugin like so:

const webpackConfig = merge(baseWebpackConfig, {
  plugins: [
    // prerender the important pages
    new PrerenderSpaPlugin(
      path.join(__dirname, '../dist'),
      ['/', '/about', '/faq' /* and others... */],
      {
        /**
          * A dirty hack: setting a very specific viewport size 
          * makes it very easy to check for the prerenderer in Vue's
          * `created()' via `window.innerWidth' and `window.innerHeight',
          * giving a way to server custom content for search engines
          */ 
        phantomPageViewportSize: {
          width: 1242,
          height: 742
        },
        postProcessHtml: function (context) {
          // `context.html' will contain the HTML returned by the
          // headless browser, and `context.route' will be the path
          // use this place to replace or fix the contents.
        }
      }
    )
  ]
})

module.exports = webpackConfig

I’m using some of the plugins options since fine-tuning prerendering is often needed, but only the first two arguments are actually required — the path to ./dist and an array of the routes you wish to prerender. Try to pick only routes that don’t change often to minimize time spent running the prerendering script.

The little hack I’ve added allows us to detect the viewport size can then be used in JS or CSS (via media queries) and then present a slightly different version of the page for crawlers. Setting a viewport size is needed if you’ve got responsive website anyway, to choose the version you wish to use for prerendering.

I’ve also needed to strip away all <style> tags from the page for a project since there was CSS from rarely-used third party modules being included in the pages that didn’t even use the modules. If you wish to do so too, use this one-liner in postProcessHtml which uses a simple RegEx:

return context.html.replace(/<style type="text\/css">[\s\S]*?<\/style>/gi, '')

To make things easier, I copied the ./build/build.js file to ./build/build.prerender.js and made a few changes to get a pretty spinner when I prerender:

'use strict'
require('./check-versions')()

process.env.NODE_ENV = 'production'

const ora = require('ora')
const chalk = require('chalk')
const webpack = require('webpack')
const webpackConfig = require('./webpack.prerender.conf')

const spinner = ora('building for production...')
spinner.start()

webpack(webpackConfig, (err, stats) => {
  spinner.stop()
  if (err) throw err
  process.stdout.write(stats.toString({
    colors: true,
    modules: false,
    children: false, // If you are using ts-loader, setting this to true will make TypeScript errors show up during build.
    chunks: false,
    chunkModules: false
  }) + '\n\n')

  if (stats.hasErrors()) {
    console.log(chalk.red('  Build failed with errors.\n'))
    process.exit(1)
  }

  console.log(chalk.cyan('  Build complete.\n'))
  console.log(chalk.yellow(
    '  Tip: built files are meant to be served over an HTTP server.\n' +
    '  Opening index.html over file:// won\'t work.\n'
  ))
})

Finally, the following line in your package.json under scripts will give you an easy way to run the prerender from the command line: "prerender": "node build/build.prerender.js"

Run the prerender using npm run prerender. See files generated in ./dist. It’s like magic.

Testing for Google

To check all the pages, make sure you run a local server for dist and browse every pre-rendered page with JavaScript turned off (Chrome: Inspector > Settings > “Disable Javascript” under Debugger). Things don’t always work the way you want them to, especially when you’re dealing with headless browsers.

Once you’ve gotten things looking visually perfect, do inspect the generated HTML for excess code that you could trim away to further decrease your filesize.

Finally, once you push and run the prerender on server, use the Google Webmaster’s Console to see if everything is working well; since your ultimate reason for prerendering is probably proper SEO anyway. Click “Request Indexing” under “Fetch as Google” to then get your app to show up on Google.

Further Reading

• Prerender SPA Plugin Github
• VueJSDeveloper’s Demo

…

So I login to /ghost to pen a new post and I’m greeted with 2 bars at the top asking me to upgrade. I agree and check out that Ghost is finally version 1, woohoo! Then I check out the migration guide…

Prepare your theme in advance

Backup your content using the JSON exporter

Create a brand new Ghost v1.0.0 site following our install guide

Use Ghost v1.0.0 Importer to import existing content

Copy your images to your new site.

Upload your theme – your theme will not be uploaded from the importer

Alright then — I start by preparing my custom theme. Upload it to gscan and do a few find and replaces and I’m good. The backup is pretty quick, too. I then get to the part where everything got stuck — installing Ghost CLI.

Ghost CLI is opinionated and broken

Ghost CLI seems to be focused more to make Ghost Pro easier to maintain for the team, simply because of how opinionated it is. Support only for Ubuntu + Nginx? Node v6 (I’ve read the reasons and it seems like laziness, but I understand that they’re a business and need to be pragmatic with priorities)? I hit n install lts to downgrade to Node 6 from v8.4.0 and try to npm i -g ghost-cli.

All’s good. I do ghost install in my ghost directory and everything breaks. I’m greeted with 3 screens of error logging and so I browse around a couple of Github issues to make sense of it. I double, then triple, check MySQL and my MySQL credentials. I create a new user and new database to check if it helps. Nothing. After spending an hour here and growing tired of the fact that Ghost, in fact, didn’t make my writing any easier or faster; I give up on upgrading, go write and publish my post, and figure out how to move to WordPress.

We meet again, WordPress

WordPress might be old, clunky, and PHP (heh) — but it works, has basically the largest ecosystem with amazing plugins, and it makes it easier to work with pages and posts. I use the _s base theme, add a way to work with browser-sync and Stylus files, and whip up the pyaar theme (with lots of code copied from the last design). Turns out that WP and Ghost have pretty similar template hierarchies, just add a class with “entry” changed to “post” wherever you see it (e.g., add .post-content to .entry-content) and you’ll get the theme more or less working.

Used Ghost to WP XML converter to transfer all content from posts, moved /content/images to /wp-content/uploads and added an .htaccess 301 Redirect.

I’ve yet to test the theme properly (let me know if you see anything broken) and have a lot more content planned that I need to integrate before I can make Symmetrycode what I envision it to be. I’m slightly sad that I lost Ghost, but I guess it made me appreciate WP’s stability a lot more. And it’s good to be back.

That’s why I mocked up Sangh. Using Sangh with Gmail’s Filters allows you to have a powerful and well-regulated inbox with a real-time subscription to whatever feeds you want to follow.

1. Formatting RSS

The rss-parser looks to be a solid bet in terms of simplicity.

I grab the 3 latest entries from the feed and pass them to the parsing function which returns content in an object that can be consumed by nodemailer that we’ll set up later. The formatEntry function is where you’ll make changes and perform string interpolation to fit your content.

const formatEntry = entry => ({  
  to: TO_EMAIL,
  subject: `${ entry.title }`,
  html: `${ entry.content }`
})

parser.parseURL(RSS_URL, (err, parsed) => {  
  let entries = parsed.feed.entries.splice(0, 3) // only latest 3

  for (entry of entries) {
    sendEmail(formatEntry(entry))
  }
})

2. Configuring sendmail

I’m hosting things on a $5 DO droplet which I’ve configured with Postfix and can use sendmail on, which makes it really easy to use Nodemailer‘s sendmail transport.

const nodemailer = require('nodemailer')

const transporter = nodemailer.createTransport({  
  sendmail: true,
  newline: 'windows',
  path: '/usr/sbin/sendmail'
})

3. Preventing repeats

Now here’s the challenge — we need to ensure that no repeat emails are sent to us in case the RSS feed doesn’t actually update. I solved this with a simple sqlite database that records RSS item’s ID and doesn’t send out the email if it’s already sent.

I use Sequelize + sqlite here. An ORM just makes simple read/write operations easier, and sqlite‘s flat file datbase is perfect for this approach.

Initialize the database like so:

const Sequelize = require('sequelize')

const sequelize = new Sequelize({  
  host: 'localhost',
  dialect: 'sqlite',
  storage: './posts.sqlite'
})

const Post = sequelize.define('post', {  
  id: {
    type: Sequelize.STRING,
    notNull: true,
    primaryKey: true
  }
}, {
  timestamps: false
})

Post.sync()  

We then need to modify our ‘parser’ function to check if post already exists in the DB or not.

parser.parseURL(RSS_URL, async (err, parsed) => {  
  let entries = parsed.feed.entries.splice(0, 3)

  for (entry of entries) {
    await Post.findOrCreate({
      where: { id: entry.id }
    }).spread((_, created) => {
      if (created) {
        // if a new entry had to be created, send an email
        sendEmail(formatEntry(entry))
      }
    })
  }
})

Note my use of async and await here. This is for performance reasons, since it’s better for sqlite to run synchronous create operations rather than async ones, it often breaks on async operations. awaiting the findOrCreate promise makes the loop run synchronously, which is exactly what we want.

4. Run it every minute

I use cron to run the node script every minute to check for updates. Check your node install location by running which node (mine is /usr/local/bin/node) and run crontab -e to open the crontab editor.

Add the line * * * * * /usr/local/bin/node /path/to/your/script/index.js to check and email updates every minute. And you’re done!

Wrapping up

A quick, small project highlighted the importance of using various tools in modular ways to come up with something great. sqlite is perfect for such applications, and ‘offloading’ the actual checks to cron is much better and optimized than running a node script via forever/pm2 etc. Get the final version of Sangh at Github.

Get plain objects instead of Sequelize Instances after bulkCreate

models.Item.bulkCreate(values)  
.then(results => results.map(result => result.get({ plain: true }))) // Convert to plain
.then(items => console.log(items)) // Plain object array [{...}, {...}, ...]

Pretty easy, use .get({ plain: true }) on any Sequelize instance to convert it to a plain JavaScript object.

Sequelize bulkCreate but ignore any duplicates

models.Item.bulkCreate(values, {  
    ignoreDuplicates: true 
})

Just use the ignoreDuplicates option and pass it as the second argument.

Deleting a row

Delete is called destroy, use it as so:

models.Items.destroy({  
    where: {
        id: 42
    }
})

The site in question looks like:

Clicking through finally gets you to a page where you need to fill a survey to continue. Boo. I assume the spammer earns a fixed amount per completed survey (cost per action.)

The spammer is very thorough, they have a few different domains leading to the exact same template.

The spam

This is a comment I saw on a very recent DJ Khaled’s Behind The Scenes

The video in question:

This link seems to be masked via the Google Cloud Platform, possibly to prevent the account from being shadow-banned. Clicked on the link redirects to the Gift Card Rebel site that I’ve been seeing everywhere (the link in plaintext https://storage.cloud.google.com/49282391/index.html).

Here’s another comment on one of Stephen Colberts’ videos, #3 on Trending at the time of this comment.

A few days earlier, I noticed links to Google Drive and pointed it out to a friend. However, the comment is now deleted.

Another type of comments say “Guys Look this up on youtube ==> markolife10x incredible” (the screenshot is from Convenience Store Cooking Challenge, #28 on Trending at the time of posting)

Searching for the exact term, curiously, gives us a single result:

Which basically is:

We’re getting this video and this video only because the description of the video contains “#markolife10x” (and of course, the term is unique enough that it’s not used anywhere else.)

Summing up

• These are new accounts with real sounding names, usually without profile pictures.
• Each comment gets around 200-400 likes and is ranked in top 3 under the video.
• The spam comment is deleted after a few hours, approximately 24-48 hours of posting (or once the comment loses it’s position in the page).
• A comment is posted very soon after a video is uploaded, around 30-60 minutes on average. It seems like the spammer is keeping an eye on some the regularly (semi?) viral channels.
• The spammer seems to be trying new tricks regularly. Earlier it started with t.co links, then it was google drive links, and currently it is google cloud storage links along with “search for x on YouTube.”

In short — the spammer seems to have a comprehensive and automated method and a hoard of different Google accounts that they use and cycle through regularly.

My curiosities

I’m wondering:

• Why is the spammer doing this?
• What is their daily investment like?
• How many people are required to pull this off?

Any discussion or answers will be appreciated — let’s discuss it on HackerNews. I’ll try updating this post as I see new spam/methods.

1. The form

For the purposes of the article, I’m going to have a really simple form that submits a POST request to our endpoint and has a single <input type="file"> field.

form(method="post" action="/img" enctype="multipart/form-data")  
  input(type="file" name="photo")

2. The endpoint

Since I want to show this works with the default Express boilerplate, we’re going to put our routing in the default routes/index.js file.

First, we need to include multer.

const multer = require('multer')  
const upload = multer({  
  dest: './public/images/users',
  limits: {
    fileSize: 10000000
  }
})

I recommend uploading the images to a subfolder of ./public/images, in this case users, because this is the default directory where you’ll be storing all your images anyway. Note that the path described in dest is relative to the project directory (i.e. where your app.js is stored). I’ve also set a limit of 10mb but that’s optional.

I’ve got a simple set up going on with passport for user logins and sequelize as my ORM. Using either, however, is optional — you can handle image submissions without any logins at all and can use mongoose or some other DB system for storing the data.

Using upload.single('<name of input>') middleware adds req.file to the req object which contains metadata about the file.

router.post('/img',  
  upload.single('photo'), 
  (req, res) => {

  // Return user if they're not logged in
  if (!req.isAuthenticated()) {
    return res.redirect('/')
  }

  // Just a safety check
  if (!req.file) {
    return res.redirect('/')
  }

  // Your filename is stored in `req.file.filename`, which then goes
  // to your database

  const newUserData = {
    photo: req.file.filename,
  }
})

What does this code do?

You should now see files with 16 letter hex filenames being stored to your public/images/users directory. Multer does not add any file extensions as a safety precaution, and we now need to write some simple code to send the files with the appropriate mime-type so they’re served appropriately.

3. Serving Files

We’re going to use read-chunk and image-type modules to check the actual format of the file and serve it with the correct mime type. Install them with npm --save read-chunk image-type and include them in your routes/index.js as so. We also need path and fs default modules.

const readChunk = require('read-chunk')  
const imageType = require('image-type')  
const path = require('path')  
const fs = require('fs')  

Now here’s the clever part — we’re going to detect what file type the image is by reading their ‘magic bytes’ and allow only png, jpg, or jpeg formats.

We’re using Express’ route parameters so we get the filename dynamically. Then, we store the UPLOAD_PATH and FILE_PATH for the image in appropriate constants.

Using the read-chunk and image-type modules, we read the first 12 bytes of the file and see what file format do they correspond to. We then check for the file formats we’re allowing and serve a default image (that is actually a 1×1 transparent png that I’ve put in the folder) that is sent over if the file is anything fishy.

Otherwise, we set the appropriate mime type and pipe a stream of file data through res via the fs.createReadStream() method.

router.get('/images/users/:img', (req, res) => {  
  const UPLOAD_PATH = './public/images/users/'
  const FILE_PATH = path.join(UPLOAD_PATH, req.params.img)

  let imageData = imageType(readChunk.sync(FILE_PATH, 0, 12))

  if (!(imageData.ext == 'png' 
    || imageData.ext == 'jpg' 
    || imageData.ext == 'jpeg')) fs.createReadStream(path.join(UPLOAD_PATH, 'default.png')).pipe(res)

  res.set('Content-Type', imageData.mime)
  fs.createReadStream(FILE_PATH).pipe(res)
})

Wrapping up

Express makes image uploads slightly complicated, but once you understand the philosophy behind their approach you can get it going really fast and easily. Multer is a very extensible library, even having modules for memory and Amazon S3 storage, among others. The router.get approach makes our application extremely robust and secure against any attacks that are usually otherwise missed.

Installation and Setting Up

The first step is to install ThemeKit.

Then, from your Shopify admin, Apps > ‘View Private Apps’ > Generate API Credentials with “Theme Templates and Theme Assets” to “Read and write” (doesn’t matter what the rest are) > Save > Copy the ‘password’ and store it.

The Environment

If you want a new theme, then:

theme bootstrap --password=[password] --store=[yourstore.myshopify.com]  

If you want to use an existing theme, get the theme ID from the shopify admin. Go to Online Store > Themes and select “Edit HTML/CSS” on the theme you want a local environment of. Copy the digits at the end of the URL — this is your theme ID.

Then, configure and download with:

theme configure --password=[password] --store=[youstore.myshopify.com] --themeid=[your-theme-id]  
theme download  

Running

Use theme watch to run with a watcher on all the theme files and live-upload to the site.

Here are the interactive subject-wise charts plotted between number of students and number of marks scored.

I found many interesting trends, hope you enjoy sifting through the results as well. I might detail how exactly I obtained the data in another post, let me know if you’re looking forward to it. In the meanwhile, if NIC requires any sort of real security on their websites, tell them to hire me — my contact details are on the right.

Special thanks to Aayush Bhasin, Aditya Garg, Tanay Rajoria, Divyansh Sharma, Bhuvesh Mehendiratta.

Catch me on Facebook

Our school has published a pretty exhaustive analysis, but I decided to make something more prettier and with more statistics.

I’ve excluded subjects that have less than 10 students.

Many interesting conclusions can be drawn – I’ll leave those up to you.

Catch me on Facebook

I messed around with CollectionFS, but unfortunately had the issue of images not loading and returning 503s, or taking a long while to load.

I decided to turn to the most popular and developer-friendly image host I know: Imgur.

I used the simple:imgur package. The upload() function takes two arguments, options and callback.

The options require an apiKey, the Imgur Client ID and image, the base64-encoded image data string. The callback function receives two arguments, the first being a Meteor.Error object and the latter being an object containing the response from Imgur.

apiKey: Registering an Imgur Application

The first step is to get an apiKey by registering your application at Imgur’s OAuth 2 page. We need to choose ‘OAuth 2 authorization without a callback URL’, and once done, get the client ID (You’ll get an email about it, too).

image: Converting file to base 64

In the submit event of my upload form, I add a line to get the file that the user uploaded:

var file = $form.find('input[type="file"]')[0].files[0]  

I also check if the file is an image or not:

if ( file && !file.type.match('image.*') ) return alert('Upload must be an image')  

We’re now going to use the FileReader API to get the base-64 representation of the image.

We’ll need to create a new reader and add a function to it’s onload event, where we handle the image upload logic.

var reader = new FileReader()

reader.onload = function(e) {  
  // e.target.result holds the file's text
}

We’re going to convert the text into a Uint8Array, convert it to a string, and then finally use btoa() to convert the string to base-64 encoded ASCII string.

I directly do this in a convoluted one liner and a custom function inside an options object I created to call Imgur.upload().

var options = {  
  apiKey: 'XXXXXXXXXXXXXXX',
  image: btoa(uint8ToString(new Uint8Array(e.target.result)))
};

The uint8ToString function is simple: it converts the Unicode values we get from the Uint8Array representation of e.target.result into ASCII strings, which can be converted to base-64 easily.

function uint8ToString(buffer) {  
  var length = buffer.length, str = ''

  for ( var i = 0; i < length; i++ ) {
    str += String.fromCharCode( buffer[i] )
  }

  return str
}

And with this, we’re able to create our options object easily.

Uploading

I created a data object to handle all data entered in the form by our user. In the Imgur.upload() function, I add to it.

Imgur.upload(options, function(errMsg, imgurData) {  
  if ( errMsg ) return alert('File upload failed. Please upload an image of a smaller file size')
    var imgData = {
      link: imgurData.link,
      deletehash: imgurData.deletehash
    }
    data.photo = imgData
  })
}

I only store the two important parts of the response: the link to the file and the deletehash. I can easily show the file by using <img src="">.

And we’re done!

What is 3D Projection?

Basically, it means that I define items in 3D space (each point is defined as an array [x, y, z]) and that I plot them in 2D space. For simplification, the 2D render can only be seen in the xy, xz, or yz plane.

Defining in 3D

Each point is defined as an array, [x, y, z].

Since we are using Canvas, it is easiest to define a rectangular face as a 2D array of 5 points: The first vertex, the remaining 3 vertices, and then the initial vertex again. This allows us to moveTo() the first index and then lineTo() till the remaining length of the array.

Since faces exist in 2D, and we’re defining 3 coordinates per point, for a single face, either the x, y, or z, coordinate will remain constant for all points.

A cuboid is defined a 3D array of faces. Depending on our views, we might not need all 6 faces to define a cuboid and can get away with only two or three faces.

Example:

var cuboid = [  
  // xy face
  [
    [xa1, ya1, za],
    [xa2, ya2, za],
    [xa3, ya3, za],
    [xa4, ya4, za],
    [xa5, ya5, za],
  ],
  // xz face
  [
    [xb1, yb, zb1],
    [xb2, yb, zb2],
    [xb3, yb, zb3],
    [xb4, yb, zb4],
    [xb5, yb, zb5],
  ],
  ...
]

Rendering in 2D.

Since we’re defining faces parallel to the primary planes, it is easiest to render the views of the primary planes themselves.

Imagine a shape on the xy plane. All points that define it can be written as (xi, yi, 0). Similarly, any shape on the xz plane defines all points as (xi, 0, zi). Basically, whichever axis you’re not rendering the shape on is 0.

This makes things easy for us.

Creating a function called plotFace, which takes three parameters:

• face: The 2D array of points
• path: The path to plot the shape on
• a: The first axis of the plane
• b: The second axis of the plane

Since in our arrays, the 0 index represents x and so on, we can simplify the function if a and b are directly passed as integers.

The plotFace function basically movesTo the initial point and linesTo the remaining ones.

function plotFace(face, path, a, b) {  
  var len = face.length;
  path.moveTo( face[a], face[b] );
  for ( var i = 0; i < len; i++ ) {
    var point = face[i];
    path.lineTo( point[a], point[b] );
  }
}

A simple map through all faces and using plotFace on each can plot the entire shape to a single path.

path = new Path2D();  
ctx.beginPath();  
item.faces.map(function(face) {  
  plotFace(face, path, a, b);
})
ctx.closePath();  

Finally, rendering the context using fill() will get our shape.

ctx.fill(path);  

…And we’re done!

What’s next

Currently, we’re only projecting in the xy, xz, or xy plane. Next would be to be able to project in any arbitrary plane. I have yet to figure out the math for it, and I’m trying to do it without external help, so it might be a while before I publish a new article.

After that, perhaps manually raycasting to create shadows? That could be interesting, both aesthetic and performance wise.

Further Reading

• 3D Projection

1. Always escape using ? as placeholders

Queries are usually written as:

connection.query('SELECT * FROM foo WHERE bar = baz', function(err, results) {  
    // ...
});

If you want to check against a custom property, don’t do this.

connection.query('SELECT * FROM foo WHERE bar = ' + someVariable, function(err, results) {  
    // ...
});

Instead,

connection.query('SELECT * FROM foo WHERE bar = ?', [someVariable], function(err, results) {  
    // ...
});

You can use multiple ? like so:

connection.query('SELECT * FROM foo WHERE ? = ?', [someProperty, someValue], function(err, results) {  
    // ...
});

2. Use the SET ? syntax

Node MySQL converts objects from { a: 'b' } to a = 'b' when escaped. Insertions with objects is thus easy:

var user = { id: 42, name: "Namanyay Goel" };  
connection.query('INSERT INTO users SET ?`, user, function(err, result) {  
    // ... 
}); 

Then you never have to do this…

Learn more about Node MySQL’s escaping

After much tinkering, I figured something out:

var fs = require('fs');  
...
.pipe( p.jade({ 
    pretty: uglyLevel,
    data: JSON.parse( fs.readFileSync('src/data.js', { encoding: 'utf8' }) )
}) )

…What?

• Gulp Jade’s docs show that the data or locals option to could be used to pass in a single object holding all the external data.
• File I/O, or fs is node’s way of reading files. Using fs.readFileSync, I used a JSON file to hold all the data.
• JSON.parse() is a native JS method to convert a string (The output of fs.readFileSync with utf8 encoding) to JSON.

Combining the three resulted in the above one liner, allowing me to use a data.js file to host all raw data and use loops to better template the code within. Win!

PS: If you’re wondering what the uglyLevel bit is…

Development is pretty damn easy too. Installing Ghost on Windows was a breeze, and starting development even easier. I fired up Prepros, creating a SCSS file for better CSS, and started coding!

Ghost’s writer is it’s biggest advantage, though. Markdown is great to write, and the side-by-side compilation makes writing so much more fun.

However, there are indeed a few practical problems with Ghost that you may encounter soon in one of your projects. I’m going to talk about these here, along with some hacky solutions for them.

• Images can’t use figure/figcaption: Currently, images on Ghost are simple <img> tags in paragraphs. I was looking around for image captioning and using figure/figcaption there, but with little results. A workaround by Lee Lam could be a quick solution, though.

This is a problem both of Markdown (Which does not seem to support two types of captions, i.e. one for the alt attribute and other a standard caption) and Ghost.

The issue is set to won’t fix until the Haunted Markdown parser is implemented.

• No support for advanced excerpts: With WordPress, you could simple add a <!-- more --> somewhere and it handled excerpts with read more for you. Unfortuantely, this isn’t the case with Ghost and by default you see a paragraph of plaintext with a trailing …. Not something particularly beautiful.

Kraftner on Ghost Forums gives a great solution to that problem. Using {{ content }} instead of {{ excerpt }} allows you to output HTML instead of plaintext, and combining that with some clever CSS rules displays only one paragraph. I use a similar trick at TLDRtech where all uls are hidden in the ‘excerpt’.

My goal with the post was to highlight some of the common issues, and give hacky solutions for them. That said, I do love Ghost for many, many reasons

• Ghost is fast. You literally feel the difference on the admin panel of Ghost compared to WordPress’
• Installing Ghost is a breeze. It took me less than 2 minutes to install Ghost on my Windows computer. Granted, installing it on Apache is a bit more difficult, but there are good guides for that.
• Theme development on Ghost is fun. Handlebars is fun to write, and I’ve set up SCSS compilation with Prepos as well.