DEV Community: Pratik Patel

From Co-Pilots to Colleagues: How AI Agents Changed My Engineering Workflow

Pratik Patel — Mon, 17 Aug 2026 21:34:32 +0000

A little over a year ago, I wrote about my first experience using Devin AI as a coding co-pilot. The takeaway was clear: AI wasn't replacing engineers, but it was becoming a surprisingly capable junior teammate. Fast forward to today, and that framing already feels quaint. The AI agents I work with now aren't co-pilots. They're closer to colleagues.

Here's what changed, what I got wrong, and what I've learned about building software alongside AI agents in 2026.

The Shift: From Autocomplete to Autonomy 🔄

When I first started using AI coding tools, the mental model was simple: I think, it types. Copilot-style tools predicted the next line. I was still the driver. The AI was a fancy autocomplete engine that occasionally read my mind.

The agents I use today operate differently. I describe a problem, point them at the relevant code, and they go figure it out. They read documentation, explore the codebase, draft a plan, write the implementation, run the tests, and open a PR. Sometimes they even catch edge cases I didn't think of.

The biggest mental shift wasn't learning new tools. It was learning to delegate. And delegation, it turns out, is a skill that most engineers never had to practice with machines before.

What I Got Wrong Last Year 🤔

In my Devin AI post, I framed the value proposition as a time trade-off: 15 minutes of my own coding vs. 1 hour with Devin. That math was real, but the conclusion I drew was too narrow. I was measuring the wrong thing.

The real value isn't "did this specific task get done faster?" It's "what did I do with the time I didn't spend on it?" When I stopped measuring AI by how fast it could do my tasks and started measuring it by how much it expanded my capacity, the picture changed dramatically.

These days, I routinely have two or three agent sessions running in parallel while I focus on architecture decisions, stakeholder conversations, or code review. My throughput hasn't just increased — it's qualitatively different. I spend more time on the problems that actually need a human brain, and less time on the ones that don't.

The Trust Calibration Problem ⚖️

Here's the thing nobody warns you about when working with AI agents: trust is harder than prompting.

Early on, I over-trusted. I'd skim an AI-generated PR, approve it, and move on. Then I'd find a subtle bug two days later — something that passed tests but violated an unwritten assumption about how our system handles state. The AI didn't know our system's history. It only knew the code as it existed on disk.

Then I over-corrected. I reviewed AI PRs with more scrutiny than I'd give a senior engineer's code. That defeated the entire purpose. I was spending more time reviewing than I would have spent just writing the code myself.

The sweet spot — and I think every engineer working with agents has to find their own — is what I call calibrated trust:

High trust for well-defined, well-tested tasks: CRUD endpoints, data transformations, boilerplate setup, migrations with clear schemas
Medium trust for tasks that require domain context: business logic, API integrations, anything touching auth or payments
Low trust for tasks involving system design, performance-sensitive code, or subtle correctness requirements

This isn't that different from how you'd calibrate trust with a human teammate. The difference is that AI agents are consistently good at their strengths and consistently blind to their weaknesses. Humans are more variable but also more self-aware. Once you internalize that pattern, the collaboration gets much smoother.

Three Habits That Made the Difference 🛠️

After a year of iteration, three practices made my AI-augmented workflow actually work:

1. Write Better Context, Not Better Prompts

The prompt engineering hype was overblown. What actually matters is context. AI agents do better work when they have access to clear documentation, well-named functions, and explicit conventions. Every time I improved our codebase's readability for humans, the AI agents got better too.

The irony isn't lost on me: the best way to make AI productive is to make your codebase better for everyone.

2. Review the Plan, Not Just the Code

Most AI agent tools now show you a plan before they start coding. I used to skip this step. Now it's the most valuable part of the process. Catching a wrong assumption at the plan stage saves 10x the time compared to catching it in code review.

When I review an agent's plan, I'm asking: Does this agent understand the problem the way I do? If the answer is no, I course-correct before a single line of code gets written.

3. Keep a Human in the Architecture Loop

AI agents are great at implementing within a well-defined boundary. They're not great at deciding where the boundary should be. Architectural decisions — where does this logic live, how do these services communicate, what are the failure modes — still need human judgment.

I've settled into a rhythm: I make the structural decisions, the agents fill in the implementation, and I review the result. It's not unlike being a tech lead, except my "team" never gets tired and never has opinions about tabs vs. spaces.

What I'm Watching Next 🔮

The pace of improvement in AI agents is staggering. A year ago, getting an agent to handle a multi-file refactor reliably felt like a stretch. Now it's routine. The frontier is moving toward agents that can maintain context across longer arcs of work — understanding not just the current task but the project trajectory.

I'm also seeing more teams adopt agents not as individual tools but as team members with defined roles: one agent handles test coverage, another manages dependency updates, another writes documentation. The multi-agent workflow is still early, but the pattern is emerging.

The engineers who will thrive in this landscape aren't the ones who write the fastest code. They're the ones who can orchestrate, review, and architect — the skills that have always defined senior engineering, now amplified by a new kind of teammate.

The Bottom Line 🎯

Working with AI agents for the past year taught me something I didn't expect: it made me a better engineer, not because the AI wrote my code, but because it forced me to think more clearly about what I actually wanted built. You can't delegate effectively if you don't understand the problem deeply yourself.

AI agents aren't replacing engineers. They're raising the bar for what "engineering" means. Less time typing, more time thinking. Less time on the routine, more time on the remarkable.

And honestly? I wouldn't go back. The way I work now — with AI colleagues running alongside me — feels like the way software was always meant to be built. We just didn't have the teammates for it until now.

Ship It Yourself: Why the Best Time to Build Is Right Now

Pratik Patel — Mon, 17 Aug 2026 21:30:28 +0000

Five years ago, if you wanted to launch a product, you needed a team. A designer to make it look right. A frontend engineer to build the interface. A backend engineer to wire the logic. A DevOps person to deploy it. Maybe a copywriter to make the landing page not sound like it was written by a robot. The minimum viable team was five people before you even had a minimum viable product.

That world is gone.

In 2026, a single person with a laptop and a clear idea can ship a product that looks, works, and scales like it was built by a funded startup. I know this because I'm living it. And if you're sitting on an idea right now, waiting for the "right time" or the "right team," I'm here to tell you: the right time is now, and the right team is already on your machine.

The Excuses Are Dead

Let's run through the greatest hits of reasons people don't build:

"I can't design." AI design tools generate production-ready interfaces from a text description. Entire component libraries, color systems, and responsive layouts — built in minutes. I wrote about this in my last post: there is genuinely no excuse for an ugly website anymore. That same logic applies to your product.

"I can't code the backend." AI agents write, test, and deploy backend services. Describe your data model and business logic, and an agent will scaffold the API, write the tests, handle the migrations, and open a PR for your review. You're the architect, not the bricklayer.

"I don't have time." This one used to be real. Building something meaningful on nights and weekends was genuinely brutal. But when AI agents handle 60-70% of the implementation work, your time equation changes dramatically. What used to take a weekend now takes an evening. What used to take a month now takes a week.

"I don't have a team." You don't need one. Not the way you used to. AI agents can fill the roles that previously required hiring: content creation, code review, testing, deployment, even basic project management. You're not a solo founder anymore. You're a founder with a tireless, always-available team.

"I don't have funding." Most of the tools that make this possible cost less than your monthly coffee budget. The expensive part of building used to be people. When AI handles the work that people used to do, the cost structure collapses. You can build and launch a real product for nearly zero dollars.

Every single excuse has an AI-shaped hole in it.

What Actually Changed

It's easy to wave your hands and say "AI makes everything easier." But the specific changes matter, because they're what make this moment different from every other "democratization of technology" wave.

1. AI Got Good Enough to Ship

The gap between "AI demo" and "production-ready" used to be enormous. AI could generate impressive-looking code that fell apart under real usage. That's no longer the case. The current generation of AI agents produces code that passes tests, handles edge cases, and follows established patterns. Is it perfect? No. But it's good enough to ship, and shipping beats perfection every single time.

2. The Full Stack Collapsed

You used to need different specialists for different layers. Now, the same set of AI tools can handle frontend, backend, infrastructure, and content. The "full stack" isn't a rare skillset anymore — it's the default mode of AI-assisted development. One person can operate across the entire stack because the AI fills in the gaps in their expertise.

3. Iteration Got Radically Faster

The most underrated change isn't the first version — it's the second, third, and tenth version. AI makes iteration almost free. Don't like the UI? Regenerate it. Need to pivot the data model? Let the agent handle the migration. Want to A/B test a new approach? Spin up a variant in an hour. When iteration is cheap, you can experiment fearlessly. And fearless experimentation is how good products are born.

The Builder's Playbook for 2026

If you're convinced but not sure where to start, here's the playbook I'd recommend:

Start With the Problem, Not the Tech

The biggest trap I see new builders fall into is leading with the technology. "I want to build something with AI" is not a starting point. "I'm frustrated that X is broken and I think Y would fix it" is a starting point. AI is the engine, but you still need to point the car somewhere worth driving.

Ship in Days, Not Months

The old startup playbook said: spend months building, then launch. The new playbook says: ship the smallest possible version this week. AI makes this feasible because the cost of building v1 is so low. Get it in front of people. Learn what's wrong. Fix it. Repeat. The feedback loop is where all the value lives, and the sooner you enter it, the faster you learn.

Use AI as a Team, Not a Tool

Stop thinking of AI as a code generator. Start thinking of it as a team you manage. Assign tasks. Review output. Set standards. Give feedback. The mental model shift from "AI writes my code" to "I lead a team of AI agents" is the single biggest unlock for solo builders. You're not doing less work — you're doing different work. Higher-leverage work.

Don't Polish, Ship

Perfectionism kills more projects than competition ever will. Your AI-generated UI doesn't need to be pixel-perfect before launch. Your API doesn't need 100% test coverage on day one. Your copy doesn't need to win a Pulitzer. It needs to exist and work and be in front of real users. Polish comes after validation, not before.

The Real Unlock

Here's what I've realized after months of building this way: the technology isn't the breakthrough. The breakthrough is permission.

For years, most of us told ourselves stories about why we couldn't build. We didn't have the skills, the time, the team, the money. Those stories felt true because they were true — in a world where building required all of those things.

AI didn't just give us new tools. It invalidated our excuses. And when your excuses go away, the only thing left is the question you've been avoiding: do you actually want to build this, or were the excuses more comfortable?

That's a harder question than any technical challenge. But if your answer is yes — if there's something you've been wanting to create, a problem you've been wanting to solve, an idea that won't leave you alone — then you're out of reasons to wait.

The Bottom Line

The gap between "idea" and "product" has never been smaller. The cost has never been lower. The tools have never been better. And the window won't stay this wide forever — as more people realize what's possible, the advantage of being early shrinks.

So stop planning. Stop researching. Stop waiting for the perfect moment or the perfect co-founder or the perfect market conditions.

Open your laptop. Describe what you want to build. And ship it yourself.

The world doesn't need another pitch deck. It needs another product. And you're the one who can build it.

No More Ugly Websites: AI Killed Every Excuse for Bad Design

Pratik Patel — Mon, 17 Aug 2026 21:25:35 +0000

Open Craigslist in 2026 and you're looking at the same HTML table layout from 1995. Try Namecheap's dashboard and you're fighting a wall of cluttered panels that haven't aged well since the mid-2010s. Visit berkshirehathaway.com, the website of an $800 billion company, and you'll find a single page of unstyled hyperlinks on a white background. It looks like a professor's personal homepage from the Geocities era.

These aren't edge cases. Ugly, dated web design is everywhere, and it costs real money. 75% of users judge a company's credibility based on its website design (Stanford Web Credibility Project). 38% of visitors will stop engaging entirely if the layout is unattractive (Adobe). First impressions are 94% design-related, and they form in 0.05 seconds.

It's 2026. None of these sites need to look like this anymore.

The Old Excuse Died This Year

For decades, the excuse was legitimate. A proper redesign meant hiring a designer, a frontend engineer (or three), and committing to months of work. For Craigslist, which earns hundreds of millions from classified ads, the calculus was simple: the ugly design works, and a redesign is expensive, risky, and probably not worth the ROI.

That calculus just broke.

AI design tools have collapsed the cost and timeline of a website redesign from months and six figures to minutes and zero dollars. Not hype. The new baseline.

What's Actually Out There Now

The AI design tool space in 2026 is wild. I've been watching a few closely:

v0.dev (by Vercel) lets you describe a UI in plain English and get production-ready React components back. You can screenshot an ugly site, paste it in, and ask for a modern version. It outputs clean code with Tailwind CSS and proper component architecture.

Bolt.new gives you a full-stack web app from a text prompt, running entirely in the browser. Describe what you want, and it scaffolds a modern app with your choice of framework. No local setup, no deployment pipeline. Just an idea to a live site.

Lovable (formerly GPT Engineer) takes natural language descriptions and generates full-stack applications with polished design out of the box. It's aimed squarely at people who have a vision but not a design team.

Uizard can take a screenshot of your existing legacy site and convert it into an editable, modernized mockup. The "before and after" workflow is built right in.

Then there's Framer AI generating publishable websites from descriptions, Figma with AI plugins (Musho, Relume) that generate complete page designs from prompts, and Wix and Hostinger with AI builders that create responsive sites from a sentence about your business.

The tools aren't making design faster. They're making the absence of design a deliberate choice.

The "Ugly Works" Myth

Defenders of dated design often argue that sites like Craigslist and Hacker News prove ugly works. There's a kernel of truth there. Both sites have massive, loyal user bases that value function over form.

But this argument confuses tolerance with preference. Users tolerate Craigslist's design because the utility is irreplaceable, not because the interface is good. Craigslist succeeds despite its design, not because of it. And the data on what happens when you actually improve UX is unambiguous:

A well-designed UI can raise conversion rates by up to 200% (Forrester Research)
Better UX design yields conversion rates up to 400% higher
Every $1 invested in UX returns roughly $100 in value

The "ugly works" argument is really saying: "We're leaving money on the table, but we're making enough that we don't care." That's a valid business decision. But it's not an argument that the design is good, and it's definitely not an argument that it's necessary anymore.

Now Anyone Can Do It

The bigger shift is who can use these tools. Modernizing a website used to be an engineering task. You needed someone who knew HTML, CSS, JavaScript, responsive design, accessibility, and deployment.

Now, a marketing manager can redesign a landing page during lunch. A founder can go from "our site looks outdated" to "here's the new version" in an afternoon. A small business owner who's been embarrassed by their website for years can finally fix it without hiring an agency.

Squarespace and Wix started this shift with templates, but AI tools finish it by removing the template constraint entirely. You're not picking from a menu anymore. You describe what you want and get something custom.

Vibe Coding and What Comes Next

Some people call this broader movement vibe coding: describe the vibe of what you want and let AI figure out the implementation. Not about writing code. About expressing intent.

At Tarobase (poof.new), where I work as Chief Architect, we're building tools around this exact thesis. The web should be a place where ideas become reality without requiring a computer science degree. When the barrier between imagination and implementation drops to near-zero, the entire economics of web development changes.

The ugly website problem was never about technology. It's inertia. Companies kept dated designs because redesigning was hard. That excuse just expired.

So Why Do Sites Still Look Terrible?

If AI tools can already redesign a website in minutes, why hasn't it happened?

The answer is organizational, not technical. Large companies have entrenched codebases, bureaucratic approval processes, and teams optimized for maintaining the status quo. Craigslist doesn't look the way it does because no one knows how to make it better. It looks that way because no one with the authority to change it has prioritized doing so.

But that's changing. As AI design tools go mainstream, the social pressure mounts. When your competitor can ship a gorgeous, modern experience with a fraction of the effort, "our site has always looked like this" stops being defensible.

The companies that move first will set new baselines for their industries. The ones that don't will look like relics. Not because they lack resources, but because they lack urgency.

The Excuse Is Dead

Good-looking, functional web design doesn't require a team of specialists anymore. Text prompt. Five minutes.

The last excuse for ugly websites is dead. How long will companies keep pretending it's still alive?

The 10x Engineer Is a Myth

Pratik Patel — Mon, 17 Aug 2026 21:22:35 +0000

The "10x engineer" is one of tech's most persistent myths. You know the archetype: the lone genius who cranks out code at superhuman speed, headphones on, hooded up, fueled by caffeine and pure talent.

I've worked with hundreds of engineers across startups and big tech. I've never met one.

But I've met plenty of people with 10x impact. And they do something completely different.

The Myth: More Code = More Value

The 10x engineer myth is built on a flawed assumption: that an engineer's value is measured by their individual output.

Write more code. Ship more features. Close more tickets. If one person does 10x the tickets, they're 10x the engineer. Simple math.

Except code isn't an asset. Code is a liability. Every line you write is a line someone has to maintain, debug, and eventually rewrite. More code doesn't mean more value. It often means more complexity, more bugs, and more surface area for things to go wrong.

The engineer who writes 10x the code might also be creating 10x the maintenance burden. That's not a 10x engineer. That's a 10x cost center.

What 10x Impact Actually Looks Like

The people I've seen with genuine 10x impact don't produce 10x the output. They multiply everyone else's.

Code reviews that teach

There's a difference between a code review that says "approved" and one that says "this works, but pattern X would handle the edge case on line 47 better" with a link to a post explaining the tradeoff.

The first review gets the PR merged. The second review gets the PR merged and makes the author a better engineer. Multiply that across hundreds of reviews a year, and you've raised the quality of every PR the team ships.

The engineers with 10x impact treat code review as mentoring, not gatekeeping.

Documentation that saves hours

I've seen a single well-written architecture doc save an entire team weeks of confusion. A runbook that prevents 3 AM page escalations. An onboarding guide that cuts ramp-up time from two months to two weeks.

Nobody gets promoted for writing docs. But the engineers who write them anyway, who explain how something works so everyone else doesn't have to reverse-engineer it, have an outsized impact that never shows up in ticket counts.

Mentoring that compounds

The math is simple: if you make 5 people 20% better at their jobs, that's the equivalent of adding a full engineer to the team. If you do that consistently over a year, you've created more value than any individual contributor could.

The best multipliers I've worked with do this naturally. They pair-program when someone's stuck. They explain the "why" behind technical decisions, not just the "what." They create an environment where asking questions is easier than guessing.

This compounds. The person you mentored mentors someone else. The patterns you taught become team standards. The documentation culture you started outlasts your tenure.

The question that saves a month

Every engineering team has had this meeting: someone is 30 minutes into presenting a plan, and one person raises their hand and asks a simple question that reveals the entire approach is solving the wrong problem.

That question, the one that redirects a month of misguided work, is worth more than any amount of code. But it requires two things most "10x coders" don't have: deep understanding of the business context, and the courage to speak up.

The Multiplier Framework

A simple way to think about it:

Individual output = what you ship yourself.

Multiplier effect = how much better you make everyone around you.

A team of 10 engineers where one person has a 2x multiplier effect is more productive than a team of 10 where one person writes 2x the code. Because the multiplier raises everyone. The individual just raises themselves.

Most engineering cultures reward the individual. Promotions go to the person who shipped the Big Feature. Performance reviews measure tickets closed, lines written, projects delivered.

But the people who quietly make everyone around them more effective? They're the actual force multipliers. And they're chronically under-recognized.

How to Become a Multiplier

You don't need to be a senior staff engineer to start. Three things you can do this week:

1. Make your code reviews useful

Stop rubber-stamping. When you review code, leave at least one comment that teaches something: a better pattern, a potential edge case, a relevant resource. Takes 5 extra minutes per review and compounds over months.

2. Write the doc nobody asked for

You know that thing on your team that everyone asks about and nobody writes down? Write it down. It doesn't have to be perfect. A mediocre doc that exists is infinitely more useful than a perfect doc that doesn't.

3. Share context, not just answers

When someone asks you a question, don't just give the answer. Explain how you found it. "I checked the logs in CloudWatch, filtered by this query, and found the error here" teaches them to fish. "The bug is on line 47" gives them a fish.

The Takeaway

Stop trying to be the fastest coder in the room. Be the person your team can't function without, not because you hoard knowledge or write all the critical code, but because everyone around you does better work when you're there.

That's not a myth. That's 10x impact.

Security Incidents on the Rise: Is Vibe Coding the Common Thread?

Pratik Patel — Mon, 17 Aug 2026 21:20:36 +0000

April 2026 has been a brutal month for cybersecurity. Vercel confirmed a breach tied to a compromised AI tool. Drift Protocol lost $285 million in twelve minutes. Kelp DAO was exploited for $292 million, leaving Aave with over $200 million in bad debt. And those are just the headlines.

Something feels different about this wave of incidents. Not just the scale — we've seen big numbers before — but the pattern. A growing number of breaches trace back to code that was shipped fast, reviewed lightly, and built with AI assistance. The security community is starting to ask an uncomfortable question: is the vibe coding revolution creating a generation of applications that are fundamentally less secure?

I've been thinking about this a lot. As someone who builds with AI tools daily and writes about the experience, I can't ignore the data anymore.

The Numbers Are Stark 📊

Let's start with what we know. According to recent research, AI code generators produce vulnerabilities at roughly 2x the rate of human-written code. A Veracode analysis of 4 million code scans found that AI-generated code contained security flaws 45% of the time. The Cloud Security Alliance puts that number even higher — 62% in their study.

And the trend is accelerating. In January 2026, six new CVE entries were directly attributed to AI-generated code. By February, it was fifteen. By March, thirty-five. Georgia Tech researchers estimate the real number could be five to ten times what's currently being detected — roughly 400 to 700 cases across the open-source ecosystem.

Meanwhile, 46% of all code on GitHub is now AI-generated. The vibe coding market hit $4.7 billion in 2026. We're shipping more AI-written code into production than ever before, and the vulnerability surface is expanding with it.

Anatomy of April's Worst Month 💥

Let's look at what actually happened this month, because the details matter more than the dollar figures.

Vercel: When Your AI Tool Becomes the Attack Vector

Vercel's breach didn't come from a zero-day or a sophisticated protocol exploit. It came from a third-party AI tool. An employee signed up for an AI productivity suite called Context.ai using their Vercel enterprise account and granted it "Allow All" OAuth permissions. When Context.ai was compromised, the attackers walked right into Vercel's Google Workspace through that OAuth token.

This is the new attack surface that nobody's talking about enough. Engineers are adopting AI tools at breakneck speed — browser extensions, coding assistants, AI office suites — and each one is a potential entry point. The Vercel breach wasn't about bad code. It was about the toolchain sprawl that comes with an AI-everything culture.

Drift Protocol: $285 Million in Twelve Minutes

On April 1st — yes, April Fool's Day — attackers drained $285 million from Drift Protocol on Solana. The method was audacious: they manufactured a completely fictitious token called CarbonVote, seeded it with a few thousand dollars in fake liquidity, and Drift's oracles treated it as legitimate collateral worth hundreds of millions.

The staging began weeks earlier. On-chain forensics traced the initial funding to a Tornado Cash withdrawal on March 11th, with movement patterns consistent with DPRK-attributed operations. The attack executed in roughly twelve minutes, with most stolen funds bridged to Ethereum within hours.

The deeper question: how did a fabricated token bypass validation? The answer likely involves the same pattern we see across the industry — systems built for speed, with security assumptions that went unquestioned because the code "worked" and the tests passed.

Kelp DAO and Aave: The $292 Million Cascade

On April 18th, an attacker exploited Kelp DAO's bridge infrastructure to release 116,500 unbacked rsETH tokens — about 18% of the token's circulating supply. These phantom tokens were immediately deposited into Aave as collateral to borrow real assets.

The cascade was devastating. Aave's total value locked plunged by $6.6 billion. The AAVE token dropped 16%. Whales pulled more than $6 billion in 24 hours, pushing major lending pools to 100% utilization and effectively trapping remaining depositors.

Again, Aave's own contracts weren't compromised. The vulnerability existed in the integration layer — the assumptions about what constitutes valid collateral. These are exactly the kinds of assumptions that get lost when code is generated fast and reviewed at the surface level.

The Vibe Coding Problem 🎯

Here's the uncomfortable truth about vibe coding: it fundamentally breaks traditional application security models.

The term "vibe coding," coined by Andrej Karpathy, describes a development approach where you describe what you want and let AI generate the implementation. The philosophy prioritizes speed and rapid iteration. Ship fast, fix later. The vibes are good. The code compiles. The tests pass. Deploy.

But security isn't about whether code compiles. It's about whether code fails safely under adversarial conditions. And that requires a kind of paranoid, defensive thinking that AI code generators simply don't exhibit by default.

The most common vulnerabilities in vibe-coded applications are telling:

Disabled row-level security — found in roughly 70% of apps built with AI-first platforms
Leaked secrets — API keys and credentials hardcoded or exposed in client bundles
Missing webhook verification — endpoints that accept any payload without signature checks
Absent authorization checks — the classic CWE-862, where endpoints work but don't verify who's asking

These aren't exotic attack vectors. They're Security 101 failures — the kind that a human developer with a few years of experience would catch instinctively, but that an AI code generator will happily produce because the code technically fulfills the functional requirement.

The Moltbook Cautionary Tale 🚨

Perhaps no incident better illustrates the risk than Moltbook, an AI social network whose founder publicly stated he "didn't write a single line of code." The entire application was vibe-coded.

Within three days of launch, security researchers discovered the application had exposed its entire production database — 1.5 million API authentication tokens, 35,000 email addresses, and private messages. All publicly accessible. No authentication required.

Moltbook is what happens when the entire security posture of an application depends on an AI code generator that optimizes for functionality, not defense. The app worked. Users could sign up, post, and interact. The vibes were immaculate. The security was nonexistent.

Speed vs. Insight: The Real Trade-Off ⚖️

I want to be clear: I'm not anti-AI coding. I use AI tools every day and I've written about how they've made me more productive. The issue isn't AI assistance itself — it's the absence of human security judgment in the loop.

When an experienced engineer writes code, they bring accumulated knowledge about failure modes. They know that an API endpoint needs rate limiting because they've seen what happens without it. They add input validation not because the spec says to, but because they've been burned by SQL injection before. They check authorization on every endpoint because they understand that "the frontend handles it" is not a security strategy.

AI code generators don't have this scar tissue. They produce code that matches the pattern of what was requested, but they don't anticipate how that code might be abused. And when developers accept that code without applying their own security judgment — when they vibe with it instead of scrutinizing it — the defensive layer disappears entirely.

The trade-off isn't speed vs. security. It's speed vs. insight. And right now, the industry is overwhelmingly choosing speed.

What Needs to Change 🔧

The answer isn't to stop using AI coding tools. That ship has sailed — 46% of GitHub is already AI-generated. The answer is to build security back into the workflow in ways that work alongside AI-assisted development.

First, treat AI-generated code as untrusted input. Every line should pass through the same scrutiny you'd give to a dependency from an unknown source. Static analysis, secret scanning, and authorization audits should run automatically on every commit, not as a manual step that gets skipped when velocity is the priority.

Second, keep a human in the security loop. Code review for AI-generated code should specifically focus on security assumptions — authentication, authorization, input validation, error handling, data exposure. These are the areas where AI consistently underperforms.

Third, audit your AI toolchain. The Vercel breach wasn't about code — it was about the tools around the code. Every AI tool your team adopts is a potential attack surface. OAuth permissions should be reviewed. Third-party integrations should be inventoried. The convenience of "Allow All" permissions is the enemy of security.

Fourth, invest in security education that acknowledges the AI reality. Developers need to understand not just how to use AI tools, but where those tools have systematic blind spots. Security training needs to evolve from "how to write secure code" to "how to verify that AI-generated code is secure."

The Stakes Are Only Getting Higher 📈

We're at an inflection point. The volume of AI-generated code in production is growing exponentially. The sophistication of attackers — including nation-state actors like the DPRK group behind the Drift exploit — isn't slowing down. And the gap between "code that works" and "code that's secure" is widening as AI makes it easier than ever to ship the former without achieving the latter.

April 2026 should be a wake-up call. Not because AI coding tools are inherently dangerous, but because we're adopting them faster than we're adapting our security practices to account for their limitations. The vibes might be good, but the threat model doesn't care about vibes.

The question isn't whether AI-assisted development will continue — it will. The question is whether we'll build the security culture and tooling to match the pace of adoption. Right now, the scoreboard says we're losing.

The $0 Startup: Why Your Next Company Should Cost Almost Nothing to Build

Pratik Patel — Mon, 17 Aug 2026 21:18:44 +0000

There's a number that used to haunt every first-time founder: the cost of getting to v1.

Five years ago, the math looked something like this. You needed a designer ($8-15K for a freelancer, more for an agency). You needed a developer, or more likely two ($15-30K each, if you were lucky). You needed hosting, a domain, maybe some SaaS subscriptions for analytics, email, and payments. By the time you had something real enough to put in front of customers, you were $50-100K deep — and that was the lean version.

That math broke most ideas before they started. Not because the ideas were bad, but because the price of finding out was too high. How many great products never existed because the founder looked at a $75K price tag and said "maybe next year"?

I'll tell you: almost all of them.

The New Math

Here's what building a product costs in 2026:

Design: $0. AI design tools generate production-ready interfaces from a text description. Not wireframes. Not mockups. Actual, deployable component code with responsive layouts, consistent design systems, and accessibility built in. I covered this in "No More Ugly Websites" — the design barrier is gone.

Development: $0 (or close to it). AI agents write backend services, API endpoints, database migrations, and test suites. They don't write perfect code, but they write code that works, passes tests, and ships. The gap between "AI-generated" and "production-ready" has collapsed to a few hours of review and iteration.

Infrastructure: $0 to start. Serverless platforms, free-tier databases, and edge hosting mean you can serve thousands of users before you pay a single dollar for infrastructure. The days of provisioning servers before you had customers are over.

Content and copy: $0. AI writes marketing copy, blog posts, documentation, and email sequences. Again, not perfect — you'll want to edit for voice and accuracy — but the first draft is free and usually 80% of the way there.

Total cost to get a real product in front of real users: Your time, a laptop, and maybe $20/month in API costs.

This isn't theoretical. This is how I build. This is how a growing number of founders are building. And the implications are enormous.

Why This Changes Everything

The obvious takeaway is "building is cheaper now." But that understates what's actually happening. Cheap building doesn't just mean more products get built. It means the entire startup model changes.

The End of Fundraising as a Prerequisite

The traditional startup path was: have an idea, raise money to build it, build it, and then find out if anyone wants it. The fundraising step wasn't just about money. It was a filter. You had to convince investors that your idea was worth building before you could build it. That filter was imperfect — it selected for charisma and credentials as much as for good ideas.

When building costs nothing, you skip the filter entirely. Build first, then decide if you need money to scale. The question changes from "can I convince someone to fund this?" to "can I convince someone to use this?" That's a much better question.

The Death of the MVP

The Minimum Viable Product was a response to high build costs. Strip everything down to the absolute minimum, ship that, and iterate. It was a good framework for a world where every feature cost real money to build.

But when building is nearly free, the concept of "minimum" changes. Your v1 doesn't have to be a stripped-down embarrassment. It can be genuinely good. It can have polish, it can have features that delight users, it can have the kind of fit and finish that used to require months of work. The "minimum" in MVP just got a lot more viable.

Speed as the Only Moat

When anyone can build anything for free, the only competitive advantage is speed. Not speed of coding — AI handles that. Speed of insight. How fast can you identify what users actually want? How fast can you iterate on their feedback? How fast can you go from "I think this might work" to "I know this works because 500 people are using it"?

The winners in this new landscape won't be the best-funded teams. They'll be the fastest learners.

What Actually Costs Money Now

If building is free, where does the money go? This is where the startup model gets interesting:

Distribution. Building the product is the easy part. Getting it in front of the right people still costs time, effort, and sometimes money. SEO, content marketing, paid acquisition, partnerships — the go-to-market machine is where the real investment happens.

Taste. AI can generate a hundred UI variations in an hour. Knowing which one is right? That's human judgment. The scarcest resource in a $0-build world isn't engineering talent — it's product taste. The ability to look at ten options and pick the one that resonates. That can't be automated, and it's worth more than ever.

Support and trust. Customers still want to know there's a real human behind the product. Response time, reliability, and genuine care — these are the things that turn a side project into a business. They cost attention, not dollars, but they're non-negotiable.

Scale. Eventually, if your product works, you'll outgrow the free tiers. Infrastructure costs kick in. You might need to hire humans for customer support, partnerships, or sales. But by that point, you have revenue, users, and data — which means you can either self-fund or raise money from a position of strength instead of desperation.

The Playbook

If you're starting something in 2026, here's how I'd think about money:

Spend $0 on v1. Use AI agents for design, development, and content. Use free-tier infrastructure. Get something real in front of real people without spending a dollar. This isn't cutting corners — this is the new standard.

Spend your time on taste and distribution. These are the two things that actually matter now. What should your product feel like? Who needs it? How do they find it? If you're spending your days writing code instead of answering these questions, you're doing it wrong.

Don't raise money until you have signal. Revenue, active users, organic growth — any of these. Going to investors with "I built this for $0 and 200 people are paying for it" is a fundamentally different conversation than "I have an idea and I need $500K to find out if it works."

Reinvest revenue before outside capital. When money does start coming in, put it back into the things that got you here: faster iteration, better distribution, deeper understanding of your users. The compounding effects of reinvestment in a $0-cost structure are absurd. Your margins are effectively 100% until you choose to spend.

The Uncomfortable Truth

Here's what nobody in the startup world wants to say out loud: most venture-backed startups were always solving an artificial problem. They raised money to hire engineers to build something that, in many cases, one focused person with the right tools could build in a week. The complexity was the product of the tooling, not the problem.

AI didn't just reduce costs. It exposed how much of the startup ecosystem was a tax on building. Accelerators, talent recruiters, office space, team retreats, standup meetings — an entire industry existed to manage the complexity of building with humans. When AI replaces that complexity, the industry around it loses its reason to exist.

I'm not saying every startup should be one person with a laptop. Some problems genuinely require teams, capital, and coordination. But a lot more problems than we thought can be solved by one person who cares deeply about the outcome and has AI agents to handle the execution.

What This Means for You

If you've been waiting for the right time to start something, consider this: the financial excuse is officially dead. You don't need savings. You don't need investors. You don't need a co-founder with a trust fund. You need an idea, a laptop, and the willingness to ship.

The $0 startup isn't a gimmick. It's the new default. And the founders who figure this out first will build the next decade's most interesting companies — not because they raised the most money, but because they needed the least.

Stop budgeting. Start building.

Your Taste Is Your Moat

Pratik Patel — Mon, 17 Aug 2026 21:16:17 +0000

Last month I watched someone build a full SaaS app in 45 minutes using AI tools. Working backend, auth, payments, dashboard. It was genuinely impressive.

It was also completely useless. Nobody wanted it.

The app worked perfectly. It just solved a problem that didn't exist, in a way that nobody would choose to use, with a UI that felt like it was designed by committee. Every technical box was checked. Every product instinct was wrong.

This is the new failure mode. And I'm seeing it everywhere.

Execution Is No Longer the Hard Part

For twenty years, the bottleneck in software was building the thing. You had an idea, and the gap between that idea and a working product was months of engineering, tens of thousands of dollars, and a team of specialists.

AI collapsed that gap to almost nothing. I wrote about this in "The $0 Startup." The tools exist. The cost is near zero. Anyone can ship.

Which means shipping isn't the differentiator anymore. If everyone can build, the question stops being "can you build it?" and becomes "should you build it?" And more importantly: "should you build it this way?"

That's taste. And right now, it's the scarcest resource in tech.

What Taste Actually Means

Taste isn't about aesthetics. It's not "make it look pretty." It's the ability to make a thousand small decisions correctly without having to reason through each one from first principles.

Should this button be here or there? Should this feature exist at all? Should we ship this now or wait until we've talked to ten more users? Should this error message be technical or friendly? Should this API return one object or a list?

Each decision is tiny. Each one barely matters on its own. But they compound. A product built by someone with good taste feels right in a way that's hard to articulate but impossible to miss. A product built without it feels off, even when nothing is technically broken.

Steve Jobs talked about this constantly. So did Dieter Rams. But you don't have to be a design legend to have taste. You just have to care about the details that most people skip.

The AI Taste Gap

AI tools are fantastic at execution. Give Claude or Cursor a well-defined task and it'll produce clean, working code faster than most engineers. But ask it to decide what to build? That's where things fall apart.

I've tested this repeatedly. When I give an AI agent a specific, well-scoped task with clear context, the output is great. When I give it an open-ended problem, "build something that helps developers manage their dotfiles," the result is technically competent and creatively dead. It builds the obvious thing. The thing that already exists twelve times on GitHub.

AI doesn't have taste because taste comes from experience, opinions, and the willingness to say no to things that technically work. AI is a people-pleaser. It'll build whatever you ask for. It won't push back and say "that feature is a bad idea" or "your users don't actually want that."

That pushback is where taste lives.

Three Things I've Learned About Taste

1. Taste is mostly about removal

The best product decisions I've made weren't about what to add. They were about what to cut. The feature that seemed important but would confuse the core flow. The settings page that gave users control they'd never use. The onboarding step that felt necessary but killed activation.

Junior engineers add. Senior engineers remove. The willingness to kill something that took a week to build, because it makes the overall product worse, is one of the clearest signals of taste I know.

2. Taste requires contact with real users

You can't develop taste in isolation. Every product instinct I trust was built by watching someone struggle with software I built. Not reading analytics dashboards. Not reviewing survey results. Sitting next to someone and watching them try to complete a task.

The founders I know who ship great products all do some version of this. They talk to users constantly. Not through feedback forms. Through actual conversations where they shut up and watch.

AI can't do this. It can analyze usage data. It can summarize feedback. But it can't sit in a room and notice that a user paused for three seconds before clicking a button, and understand what that pause means.

3. Taste compounds like interest

Every product you ship, every user interaction you observe, every decision you make and see the result of, it all accumulates. Five years of building products gives you intuitions that no amount of reading or theorizing can replicate.

This is why experienced product builders are more valuable now than ever. Not less. The execution layer got automated. The judgment layer didn't. A founder with ten years of product sense and AI tools is a force multiplier. A founder with AI tools and no product sense is just building faster in the wrong direction.

What This Means for Engineers

If you're an engineer reading this, the implication is clear: technical skill alone isn't enough anymore. It never was, really, but now the gap is obvious.

The engineers I want to work with aren't just good coders. They're people who ask "why are we building this?" before they ask "how should we build this?" They're the ones who push back on specs that don't make sense. Who prototype three different approaches and pick the one that feels right, not just the one that's technically cleanest.

You build taste by building things. Ship side projects. Use your own products. Pay attention to what annoys you about software you use every day. Develop opinions. Strong ones. Be willing to be wrong, but always have a point of view.

The New Competitive Advantage

The next decade of tech belongs to people with good taste and access to AI tools. Not to the people with the best AI tools and no taste.

Execution is a commodity now. Taste isn't. If you're wondering what to invest in, invest in your judgment. Talk to users. Ship things. Develop opinions about what good software feels like.

The moat isn't your code. It's your ability to decide what code should exist.

Distribution Is the New Code

Pratik Patel — Mon, 17 Aug 2026 21:13:19 +0000

There's a pattern I keep seeing in my DMs. Someone builds something genuinely good (clean product, solid code, real utility) and then wonders why nobody's using it. They share a link on Twitter, post it to a couple of subreddits, and wait. Nothing happens. A week later they're demoralized, convinced the product wasn't good enough.

It was good enough. The product wasn't the problem. Getting it in front of people was the problem.

We've spent the last two years celebrating how AI collapsed the cost of building. I wrote about it. The $0 startup is real, shipping solo is real, taste as a moat is real. But nobody wants to talk about what comes next: building was never the hardest part. Distribution was. And it still is.

The Biggest Lie in Tech

Silicon Valley has a mythology problem. The story goes like this: build something great, and the world will beat a path to your door. "If you build it, they will come." It's the foundational myth of the startup world, and it has always been a lie.

Google wasn't the best search engine when it launched. It had better distribution through academic networks. Facebook wasn't the best social network. It had exclusivity and campus-by-campus rollout. Slack wasn't the best chat app. It had a viral loop baked into its team onboarding. The winners didn't just build better products. They built better distribution.

This was already true before AI. Now it's the only truth that matters.

Building Isn't the Bottleneck Anymore

The math is simple. In 2024, maybe 500,000 people worldwide could build a production-quality web app from scratch. Designers, engineers, full-stack developers, the usual suspects. In 2026, that number is closer to 50 million. AI agents turned "non-technical" people into builders overnight.

That's a 100x increase in supply. What happens when supply explodes? The thing that was scarce stops being scarce. The ability to build is no longer a competitive advantage. It's table stakes.

So what's still scarce? The ability to reach people. Attention. Trust. An audience that listens when you have something to say. That's distribution, and no AI agent is going to build it for you while you sleep.

What Distribution Actually Means

Let me be specific, because "distribution" gets thrown around as a buzzword. It's not one thing. It's a stack:

Audience. People who already know you exist and have some reason to pay attention. This could be a Twitter following, a newsletter list, a YouTube channel, a podcast. The format doesn't matter. What matters is that when you say "I built a thing," there are humans on the other end who will actually look at it.

Trust. An audience that doesn't trust you is just a number. Trust comes from consistency, from showing up, sharing real work, being honest about what works and what doesn't. The people who do best at distribution aren't the loudest. They're the most consistent.

Channel fit. Every product has natural channels where it spreads, and forcing it into the wrong one is a waste of time. A developer tool spreads through GitHub stars and technical blog posts. A consumer app spreads through TikTok and word of mouth. A B2B product spreads through case studies and LinkedIn. If you're posting your B2B SaaS on Reddit's r/sideproject, you're putting premium gas in a bicycle.

Story. People don't share products. They share stories. "I built an app" is not a story. "I quit my job, built a tool that replaced my old team's entire workflow, and now it's making $10K/month" is a story. The narrative around your product matters as much as the product itself. Maybe more.

The Distribution Divide

I'm watching this play out in real time: the gap between builders and distributors is becoming the defining divide in tech.

On one side, you have incredible builders, technical people shipping polished products every week, who can't get past 50 users. They keep iterating on features, convinced that the next feature will be the one that unlocks growth. It never is.

On the other side, you have people with strong audiences and distribution channels who build something mediocre and immediately get traction. Their v1 is worse, but it doesn't matter because 10,000 people tried it on day one. And with real user feedback flowing in from day one, their v2 is better than the first group's v5.

This isn't fair. But it's how markets work. The product with distribution beats the better product without it, almost every time.

Building Distribution Before You Build the Product

The single best piece of advice I can give to anyone planning to build something: start your distribution engine before you write a line of code.

1. Build in Public

Share your process, not just your product. People love watching things get built. Tweet your progress. Write about your decisions. Show the messy middle. By the time you launch, you'll have an audience that feels invested in your success. They watched it happen.

2. Own a Narrative

Pick a point of view and commit to it. "AI is changing how we work" is too generic. "Solo founders with AI teams will outperform funded startups within 5 years" is a narrative. When you own a specific, debatable take, people remember you. They share your posts because they either strongly agree or strongly disagree. Both are good for distribution.

3. Give Away Your Best Ideas

Counterintuitive, but the most effective distribution strategy I've seen is radical generosity. Share your frameworks. Publish your playbooks. Give away the thinking behind your product for free. The people who consume that content self-select as your ideal users. When you launch, they already understand the problem and trust your approach to solving it.

4. Choose One Channel and Go Deep

Don't try to be everywhere. Pick the one channel where your target users already spend time, and become impossible to ignore on that channel. One great Twitter presence beats a mediocre presence on Twitter, LinkedIn, YouTube, TikTok, and a blog combined. Depth beats breadth in distribution.

AI Can't Distribute For You

The uncomfortable truth is one the AI hype cycle doesn't want to acknowledge: AI is great at building things, but it's mediocre at distributing them.

Yes, AI can write social media posts and schedule them. It can generate content at scale. But the output feels like what it is: machine-generated filler. And people are getting better at pattern-matching on AI slop every day.

Distribution that works is built on authenticity. It's your real story, your real struggle, your real perspective. The irony is rich: in a world where AI can fake almost anything, the unfakeable stuff, genuine human experience and earned trust, has become the most valuable asset of all.

The New Stack

We used to say "code is the new literacy." Everyone should learn to code, we said, because code is how you build the future. That was true for a while. It's not anymore.

In 2026, the stack looks different:

Taste decides what to build (I covered this in "Your Taste Is Your Moat")
AI handles the building
Distribution determines whether anyone ever uses it

Two out of three are in your control. And the one most builders ignore is the one that requires the most sustained effort — distribution.

The Question You Should Be Asking

If you're building something right now, I have a simple question: do you have a plan to get it in front of 1,000 people on launch day? Not a vague hope. A plan. Names of communities, channels, people who will amplify it.

If the answer is no, stop adding features. Close your code editor. Open a blank document and write your distribution plan instead.

The products that win in 2026 won't be the best-built. They'll be the best-distributed. And the founders who figure that out early will run circles around the ones who keep polishing features in the dark.

Code used to be the bottleneck. Now it's free. Distribution is the new code. And unlike code, you can't outsource it to an agent.

Start building your audience today. Ship the product tomorrow. That's the new order of operations.

I Replaced My Team With AI. Here's What I Miss.

Pratik Patel — Mon, 17 Aug 2026 21:10:33 +0000

I've spent the last few months writing about how AI makes it possible to build alone. Ship it yourself. The $0 startup. Taste as a moat. Distribution as the new code. All of it true. All of it real. I believe every word I wrote.

But I haven't been fully honest.

There's a version of this story I've been leaving out. The version where it's 11 PM, you've shipped something you're proud of, and there's nobody to high-five. The version where you make a decision that feels right but you're not 100% sure, and there's no one to push back. The version where the silence of solo building starts to feel less like freedom and more like isolation.

This is that version.

What's Genuinely Better

Let me be clear: I'm not writing a "going back to the office" piece. Working with AI agents is objectively better in a dozen ways.

Speed. Decisions that used to require three meetings and a Slack thread now happen in my head. I think it, the agent builds it, I ship it. The feedback loop is measured in minutes, not sprints.

No consensus tax. Every team I've been on has a hidden cost: the energy spent getting everyone aligned. Debating naming conventions. Arguing about architecture decisions that don't actually matter. When you're solo, that tax drops to zero. You just decide and move.

Deep focus. I haven't been interrupted mid-thought in months. No standup pulling me out of flow state. No "quick question" that takes 45 minutes. My calendar is empty and my output has never been higher.

Full context. I know every line of code, every design decision, every tradeoff. There's no knowledge transfer problem because there's no one to transfer to. The entire system lives in my head, and the AI agents have access to all of it.

These are real gains. I'm more productive than I've ever been. But productivity isn't the whole picture.

The "Are You Sure?" Moment

The thing I miss most is the challenge.

Not conflict. Not arguing. The specific moment when a smart colleague looks at your work and says, "Have you thought about this from the user's perspective?" or "What happens when this breaks at scale?" or simply, "Are you sure?"

AI agents don't do this. They execute. They're remarkably good at building what you ask for. But they almost never question whether you should be asking for it. They won't tell you your priority is wrong. They won't push back on a design because it feels off, even if it technically meets the spec.

I used to find that friction annoying. Now I realize it was the most valuable part of working with people. The best ideas I've ever shipped got better because someone challenged them. And the worst ideas I've ever had died because someone had the courage to say, "I don't think this is right."

When you're solo, that safety net disappears. Every bad idea has a clear path to production.

Complementary Taste

I wrote about taste being a moat. I still believe that. But here's what I didn't say: your taste has blind spots.

Everyone's does. You gravitate toward certain aesthetics, certain patterns, certain types of solutions. When you work with people who have different taste, different backgrounds, different instincts, the output is richer than anything one person can produce alone.

My AI agents share my taste because they learned it from my instructions and my feedback. They're an amplifier, not a counterweight. And sometimes what you need isn't amplification. It's someone who sees the thing you're missing.

The Accountability Gap

When I had a team, there was a natural rhythm of accountability. Someone was waiting on my work. Someone would notice if I went down a rabbit hole for three days. Someone would flag if the project was drifting off course.

Now? I'm accountable to myself. Which sounds empowering until you realize that humans are terrible at holding themselves accountable. I've spent entire weeks perfecting features that didn't matter, because nobody was there to tap me on the shoulder and say, "Is this really the highest-impact thing you could be doing right now?"

AI agents will happily help you polish something irrelevant. They don't have the judgment to say, "Stop. Step back. Look at the big picture." That judgment is a uniquely human contribution, and it's one I took for granted.

The Energy Problem

This one surprised me.

I expected to love the quiet. And I do, sometimes. But building is an emotional activity, not just an intellectual one. There's an energy you get from working alongside people who care about the same thing. The laugh when something finally works after hours of debugging. The shared frustration when a deploy goes sideways. The momentum that comes from knowing someone else is counting on you to show up.

AI agents don't generate that energy. They're tireless but not inspiring. They'll work at 3 AM without complaint, but they won't text you at 3 AM with an idea they can't stop thinking about. The human spark, the irrational enthusiasm that makes hard work feel meaningful, you can't prompt your way to that.

What I've Learned

I'm not going back. The productivity gains are too real, and the model works too well to abandon. But I've stopped pretending that solo AI building is a pure upgrade with no downsides.

What I've started doing instead:

Finding deliberate friction. I share work with a small group of people I trust before shipping anything important. Not for approval. For challenge. I specifically ask them to find problems, to question assumptions, to tell me what feels wrong. This replaces the organic friction that teams provide naturally.

Seeking complementary taste. I follow builders whose instincts are different from mine. When I'm stuck on a design decision, I look at how they'd approach it. Not to copy, but to see what I'm not seeing.

Creating external accountability. Building in public is part of this. When I commit to a shipping date on Twitter, I've created accountability that didn't exist before. The audience becomes the team, in a sense.

Protecting against isolation. I schedule regular calls with other solo builders. Not networking. Not masterminds. Just human conversation with people who understand the specific loneliness of building alone. It's the cheapest investment with the highest return.

Build Solo, But Don't Build Alone

The future of building is smaller teams, more AI, more individual leverage. I'm convinced of that. But "smaller teams" is not the same as "no team." And "more AI" is not the same as "no humans."

The best version of this new model isn't a person alone with their agents. It's a person with agents AND a small, intentional network of humans who provide the things AI can't: challenge, complementary taste, accountability, and energy.

You don't need those people on your payroll. You don't need them in your Slack. But you need them in your life. Because the most dangerous thing about building alone isn't that you'll build something bad. It's that you'll build something good enough, and never know how much better it could have been if someone had pushed you.

Ship it yourself. But find your people first.

I Haven't Touched Code in One Month

Pratik Patel — Mon, 17 Aug 2026 21:07:30 +0000

I realized something uncomfortable this week: I have not really touched code in a full month.

Not "I stopped building." The opposite. More shipped. More got reviewed. More ideas made it from vague note to working software. But the actual implementation work - the typing, wiring, scaffolding, renaming, fixing imports, chasing test failures - increasingly happened somewhere else.

AI agents handled it.

The honest reaction is not pure excitement. It is stranger than that. Part of me feels more effective than ever. Part of me wonders if I am getting worse at the craft I spent years sharpening. If you do not use the coding muscle, does it atrophy? Probably. But I also think that is the wrong question.

The better question is: what skill is replacing it?

The Work Did Not Disappear

When people talk about AI coding, they usually frame it as automation. The machine writes code, so the human does less work. That is technically true and practically misleading.

The work did not disappear. It changed shape.

I still have to know what good looks like. I still have to understand the system well enough to spot a bad abstraction, a leaky permission model, or a feature that technically works but should not exist. I still have to decide which problems are worth solving and which ones are distractions wearing a product costume.

What I am not doing as much is the mechanical part:

Creating the fifth version of the same CRUD flow
Moving state between components because the first pass guessed wrong
Writing boilerplate tests for behavior that is already clear
Updating copy across three files
Chasing TypeScript errors caused by a renamed prop
Reading docs for the third-party integration and translating them into glue code

That work still matters. It is just no longer the highest-leverage place for me to spend my attention.

I Am Not Coding Less. I Am Delegating More.

The mental model that finally clicked for me is delegation.

For most of my career, "building software" meant converting intent into code with my own hands. I would hold the product shape in my head, make a series of implementation decisions, and type the thing into existence.

Now the workflow feels closer to leading a small implementation team:

Define the outcome clearly.
Point the agent at the relevant context.
Review the plan before it writes code.
Let it implement.
Review the diff, the tests, and the behavior.
Push back where the work misses the intent.

That is not passive. It is a different kind of active.

The quality of the output is still a reflection of the quality of the input. If I give an agent a lazy task description, I get lazy work back. If I give it the actual constraints, the edge cases, the product intent, and the shape of the existing system, the result is usually good enough to review like a normal pull request.

The job moved from "write the code" to "create the conditions where good code is likely to emerge."

The Weird Skill Loss Is Real

There is a cost here, and I do not want to hand-wave it away.

I am probably worse at remembering exact APIs than I was a year ago. I am less practiced at grinding through implementation details from a blank file. I feel the friction when I do drop back into the code editor and have to rehydrate the local context myself.

That is real.

But it is not the same as getting worse at engineering. It is closer to what happens when a senior engineer stops being the person who personally writes every line and starts being the person who sets direction, reviews work, and keeps the system coherent.

Some skills fade. Other skills compound.

The skills that feel more important now:

Taste: knowing which version of the product should exist
Context design: giving AI the right boundaries, examples, and constraints
Review judgment: spotting the subtle wrongness in code that passes tests
Systems thinking: understanding where a change belongs before anyone implements it
Risk calibration: knowing when AI output is fine and when it needs deep scrutiny

Those are not softer skills. They are the skills that decide whether AI-generated work becomes leverage or liability.

The Dangerous Part Is Feeling Fast

The biggest risk in this workflow is not that AI writes bad code. Bad code can be reviewed, tested, and fixed.

The bigger risk is that AI makes bad decisions feel cheap.

When implementation is expensive, you naturally hesitate. You ask whether the feature is worth it. You think about maintenance. You negotiate scope because every extra requirement costs real time.

When implementation feels almost free, the discipline has to come from somewhere else. You need stronger taste, not weaker. You need to say no more often, not less. Otherwise you end up with a product full of features nobody needed, all shipped efficiently.

That is the operator lesson I keep coming back to: AI removes implementation friction, so judgment becomes the bottleneck.

This matters a lot for what we are building at poof.new. If someone can describe an app and get working software back, the scarce skill is no longer syntax. It is intent. The builder has to know what they want, why it matters, and how to tell whether the result is actually good.

AI can make software real. It cannot tell you whether that software deserves to exist.

What My Day Looks Like Now

A typical building day used to start with me opening the editor and finding the first file to change.

Now it starts with writing a better task.

I spend more time turning fuzzy ideas into crisp implementation briefs. I describe the user outcome, the current behavior, the desired behavior, the files that probably matter, the constraints that cannot be violated, and the tests that should pass when the work is done.

Then I review the plan.

This is the step I used to undervalue. Plan review is where most AI work succeeds or fails. If the plan reveals a wrong assumption, I would much rather catch it before the agent rewrites half the feature. A five-minute correction at the plan stage can save an hour of cleanup later.

Once the PR exists, I review it in layers:

Does the behavior match the intent?
Is the implementation consistent with the existing system?
Did it add unnecessary abstraction?
Are the tests proving the right thing?
Is there any security or data exposure risk?
Would I be comfortable owning this code six months from now?

That last question is the anchor. AI can write the code, but I still own the consequences.

The New Builder Is More Editor Than Typist

There is an old romantic version of programming where the builder sits alone, enters flow state, and produces perfect software through direct contact with the machine.

I still love that feeling. I do not think it is going away entirely. There will always be moments where the fastest path is to open the file and make the change yourself.

But for a growing slice of product work, the highest-leverage builder looks less like a typist and more like an editor:

They know what to ask for. They know what to cut. They know when the first draft is good enough and when it is structurally wrong. They can look at a pile of generated work and see the one decision that needs to change.

That is not less creative. It is more like the creativity moved earlier in the process.

The blank page is not the code editor anymore. The blank page is the instruction.

The Bottom Line

I have not touched much code in a month, and I am trying to be honest about both sides of that.

Yes, some hands-on sharpness fades when AI handles the implementation reps. If I had to sit down tomorrow and rebuild a feature entirely from scratch, I might feel slower than I used to.

But I am also shipping more, thinking more clearly, and spending more of my time on the parts of building that actually determine whether the work matters.

So no, I do not think AI made me dumber.

It made me more aware of which parts of my intelligence were being spent on low-leverage work.

The goal is not to never code again. The goal is to make code the last mile, not the whole journey. And once you experience that shift, it is hard to go back.

The Agent Left the IDE

Pratik Patel — Mon, 17 Aug 2026 21:05:12 +0000

The most interesting thing about AI coding agents right now is not that they can write code.

It is that they are starting to operate computers.

That sounds like a small distinction until you feel it in the workflow. A code generator lives inside a text box. It waits for a prompt, returns a patch, and leaves the rest of the job to you. A software operator can inspect the app, click through the broken flow, read the console, run the server, reproduce the issue, change the code, and check whether the thing actually works.

That is a different kind of tool.

OpenAI's May 29 Codex update points in that direction. Codex now supports computer use on Windows in the Codex app for eligible users, so it can see, click, and type in Windows applications while testing and refining software. The same release also expands remote control, letting a user steer work from ChatGPT on mobile or Codex on Mac while the Windows machine remains the host for the project files, shell, app server, and local context.

I do not think the important part is Windows support by itself.

The important part is the new shape of work.

Coding Was Never Just Typing

For a while, the AI coding story was mostly about generation. Could the model write a component? Could it scaffold an API route? Could it refactor a file without losing the plot?

Useful, but narrow.

Real software work has always been messier than text generation. You open the app. You notice the layout is wrong. You click a button. Nothing happens. You check the terminal. The dev server crashed. You restart it. The page loads, but the empty state is off. You resize the browser. The mobile nav breaks. You skim the network tab. The request is fine, but the UI state is stale.

None of that is "write code" in the pure sense.

It is operating the system around the code.

That is why computer use matters. It gives the agent access to the loop that human engineers actually live in: observe, diagnose, change, verify. The text editor is only one stop in that loop.

The IDE Is Too Small

The IDE was a natural starting point for AI coding tools because code is text. Put the model near the text and it can help.

But the product surface of software is not the IDE. It is the browser, the terminal, the database, the logs, the design tool, the cloud dashboard, the test runner, the email preview, the mobile simulator, and sometimes a random desktop app that only exists because some enterprise workflow depends on it.

If the agent can only see the repository, it is always working from a partial truth.

It can infer what should happen. It can read tests. It can inspect types. It can even run commands if the environment allows it. But it cannot fully understand the gap between the code and the experience unless it can look at the experience.

This is why frontend work has been such a revealing test. A model can produce valid React and still ship an interface that feels wrong. It can pass tests and still overlap text on mobile. It can implement the requested behavior and miss that the loading state jumps the layout.

The browser catches what the diff cannot.

An agent that can look, click, and iterate has a better shot at closing that gap.

Remote Control Changes the Cadence

The remote-control part may end up being just as important as computer use.

When an agent can keep working on the host machine while you check in from somewhere else, the job starts to feel less like a chat session and more like delegated work. You do not need to sit there watching every command. You can let the agent run until it hits a decision point, then answer the question, redirect it, or approve the next step.

That changes the cadence of engineering.

The old cadence was synchronous. You were either coding or you were not. If you stepped away, the work stopped.

The new cadence is supervisory. You define the goal, give the agent enough context, and let it move through the loop. Your job is to keep the judgment layer alive. Is this still the right approach? Did it choose the right tradeoff? Is the patch too broad? Did it verify the thing that matters?

That is closer to managing a capable junior engineer than using autocomplete.

And like managing a junior engineer, the value depends on the quality of your delegation.

The Risk Moves Too

There is a tempting version of this story where more agent autonomy simply means more productivity.

That is not the full picture.

An agent with computer use has a wider action surface. It can click the wrong thing. It can misunderstand a modal. It can test against the wrong environment. It can mistake a locally cached state for a real fix. It can spend time polishing the visible symptom while missing the deeper bug.

More access is only useful when the workflow has boundaries.

That means you still need clear permissions, disposable environments, human approval for risky actions, and a review process that treats agent work like real work. Especially when the agent is touching systems outside the editor.

The mistake is assuming that because the agent can operate more of the computer, it should be allowed to operate everything.

Good delegation is scoped. Give the agent a sandbox. Give it the app server, the browser, the test suite, and enough project context to make progress. Keep production credentials, irreversible actions, billing changes, and sensitive user data behind a stronger gate.

The point is not to make the agent fearless.

The point is to make it useful without making it dangerous.

The Best Workflows Will Be Visible

As agents become more operational, the winning workflows will be the ones that make the agent's work easy to inspect.

I want to see what it tried. I want screenshots when the UI changes. I want terminal output when a test fails. I want a short explanation of why it chose one fix over another. I want the final diff to be boring and the verification trail to be clear.

This is the difference between autonomy and trust.

Autonomy means the agent can move. Trust means I can understand what happened after it moved.

That is also where many teams will get the first productivity gains. Not from letting agents do huge open-ended tasks, but from handing them bounded loops:

Reproduce this bug and propose the smallest fix
Run the app and check the empty states
Add the test that proves this permission boundary
Verify this onboarding flow on mobile
Compare the implementation to the design and list mismatches

Those are not glamorous tasks. They are exactly the tasks that slow teams down every day.

Computer use makes them more delegable.

What Builders Should Do Now

If you are building with AI agents, I would not wait for the perfect tool before changing your habits.

Start by making your work easier for an agent to operate.

Keep local setup simple. Document the command that runs the app. Make tests deterministic. Write down the flows that matter. Keep secrets out of default environments. Add screenshots or acceptance criteria when the task is visual. Ask the agent to verify behavior, not just change files.

Most of this is just good engineering hygiene.

That is the recurring pattern with AI tools. The better your system is for humans, the better it tends to be for agents. Clear docs, clear tests, clear boundaries, clear review paths. AI does not remove the need for that discipline. It makes the payoff more obvious.

The agent leaving the IDE does not mean engineers leave the process.

It means the process needs to be legible enough that an agent can participate in it.

The Bottom Line

The next phase of AI coding is not about prettier autocomplete.

It is about agents that can operate the software environment around the code. They will run apps, inspect interfaces, respond to prompts, test changes, and keep moving while humans supervise from the judgment layer.

That is a big shift.

The IDE was where AI coding started because it was the easiest surface to understand. But software does not live in the IDE. It lives in the messy loop between code, runtime, product, and user experience.

Now the agents are entering that loop.

The builders who benefit most will not be the ones who hand over everything. They will be the ones who design tight, visible, reviewable workflows where agents can do real operating work and humans still own the decisions that matter.

AI Made Bugs Cheap to Find

Pratik Patel — Mon, 17 Aug 2026 21:03:08 +0000

The most important AI security story right now is not that models can find bugs.

It is that models can find more bugs than humans can responsibly process.

That is the part that changes how builders should think about software. For years, security work was constrained by discovery. Could someone find the vulnerability? Could they reproduce it? Could they build an exploit? Could a small team afford enough expert review to catch the important issues before attackers did?

Now that bottleneck is moving.

Anthropic's recent Project Glasswing update is the clearest signal yet. The company says Claude Mythos Preview and its partners found more than 10,000 high- or critical-severity vulnerabilities across major software systems. In open source alone, Anthropic says it scanned more than 1,000 projects and surfaced thousands of serious findings, with human triage becoming the slow part.

You do not have to take every number at face value to see the shape of the shift.

AI is making vulnerability discovery cheaper. That sounds like good news, and it is. But it also means every software team is about to face a harder question:

What happens when the scanner is faster than the organization?

The Patch Window Is the Product Now

Security used to have a familiar rhythm. A bug was found. A report was filed. A team reproduced it. Someone argued about severity. Someone wrote a patch. Users eventually upgraded.

That process was never fast enough, but it mostly matched the speed of human discovery.

AI breaks that balance.

If models can search codebases, reason about exploit paths, generate reports, and repeat that work across thousands of projects, then finding bugs stops being the scarce skill. The scarce skill becomes the system around the finding:

Can you tell which reports are real?
Can you prioritize the ones that actually matter?
Can you patch without breaking production?
Can you ship fixes before attackers learn the same thing?
Can you keep maintainers from drowning in low-quality reports?

That is the new security stack. Not just detection. Response capacity.

A vulnerability that sits untriaged for three weeks is not meaningfully safer because an AI found it. In some cases, it is riskier, because the same class of model may soon make the path to exploitation easier for everyone else.

The patch window is not an operational detail anymore. It is part of the product.

AI Does Not Remove Security Work

There is a lazy version of the story where AI agents make security easy.

Run the model. Get the report. Apply the patch. Done.

That is not how real systems work.

Real systems are full of tradeoffs. The obvious fix can break an integration. The technically correct fix can create a migration problem. The most severe-looking vulnerability might be unreachable in production, while the boring one in a forgotten admin path is exposed to the internet.

AI can help find and explain these problems. It can write a first patch. It can generate a regression test. It can compare similar code paths and look for variants.

But someone still has to own the decision.

That is the same pattern I keep seeing across AI-assisted building. The manual work shrinks, but the judgment work expands. The operator has to decide what deserves attention, what can wait, what risk is acceptable, and what needs a deeper human review.

Security is just where this becomes impossible to ignore.

The Dangerous Middle

There is a period we are entering that feels especially unstable.

Eventually, AI should make software much safer. Every serious codebase should have agents continuously searching for vulnerabilities, proposing patches, generating tests, and checking whether fixes actually landed. That world is better than the one we have now.

But the transition is messy.

The discovery side is improving faster than the response side. That creates a gap. More findings, more reports, more possible attack paths, more pressure on teams that already do not have enough security capacity.

This is especially painful for open source.

A large company can assign security engineers, rotate incident response, and fund dedicated tooling. A maintainer with a popular library might be doing all of this after work, for free, while also reviewing feature requests and answering issue comments. Dumping hundreds of AI-generated reports into that maintainer's inbox does not automatically make the ecosystem safer.

It might make it worse unless the reports are high quality, reproducible, prioritized, and paired with patches that are easy to review.

AI security only works if it respects the human throughput on the other side.

What Builders Should Change Now

If you are building with AI agents, this is not just a cybersecurity industry story. It changes the default operating model for anyone shipping software.

The old advice was "move fast and break things." The AI-era version needs an asterisk:

Move fast, but build a system that can notice what broke.

That means security cannot be a quarterly cleanup pass. It has to live inside the same loop as product work.

1. Treat every AI-generated change as reviewable work

AI code should not feel like magic output. It should feel like a pull request from a very fast junior-to-mid-level engineer who sometimes has excellent instincts and sometimes misses the reason the system is shaped the way it is.

Review it. Ask what changed. Ask what assumptions it made. Ask what surfaces it touched. If a change affects auth, payments, permissions, file handling, secrets, user data, or external integrations, slow down.

Fast does not mean casual.

2. Make tests prove the risky behavior

AI is good at producing tests that increase coverage and bad at knowing which behavior deserves proof unless you tell it.

For security-sensitive changes, generic tests are not enough. Ask for tests that prove the boundary:

A user cannot access another user's data
A disabled feature cannot be invoked through an API path
A webhook cannot be replayed without detection
A malformed upload cannot escape its expected directory
A permission check fails closed, not open

These tests do more than catch regressions. They teach the agent what matters next time.

3. Keep a patch lane open

The teams that handle AI-era security well will not be the teams with the most findings. They will be the teams with the shortest path from confirmed issue to shipped fix.

That means knowing who can approve a security patch. Knowing which tests must run. Knowing how to ship a small hotfix without dragging in unrelated product work. Knowing how to communicate a change if users need to update.

If your process requires three meetings to patch a serious bug, AI did not solve your security problem. It just made the backlog visible.

4. Build less surface area

The most underrated security feature is not having the feature.

Every integration, admin panel, file parser, OAuth scope, background job, and public endpoint becomes another place where a model can find something interesting. AI makes it easier to build all of that. It also makes it easier to discover what you accidentally exposed.

This is another reason taste matters. Good builders cut surface area. They do not add settings because settings are easy. They do not expose APIs because the model can scaffold them. They ask whether the capability deserves to exist.

The safest code is still the code you never had to ship.

This Is Why Human Judgment Gets More Valuable

Every time AI makes a technical task cheaper, people assume the human role shrinks.

I think the opposite keeps happening.

When code generation gets cheaper, product judgment matters more. When content generation gets cheaper, taste and distribution matter more. When vulnerability discovery gets cheaper, triage and patch judgment matter more.

The bottleneck moves up the stack.

That is the lesson for builders. Do not measure your AI workflow by how much code it can produce or how many issues it can find. Measure it by how quickly it helps you make good decisions and ship the right fixes.

The future is not "AI finds every bug, so security is solved."

The future is closer to this:

AI finds more than you can handle. The winners are the teams that built the judgment, process, and restraint to handle the right things first.

The Bottom Line

Project Glasswing is a preview of a much larger shift. Software is entering an era where the cost of finding flaws drops dramatically, while the cost of responsibly fixing them remains stubbornly human.

That is uncomfortable, but it is also useful clarity.

If you are building with AI, do not wait for a security crisis to design your response loop. Review agent-written code like it matters. Test the boundaries. Keep patches small. Reduce surface area. Build a process that can absorb uncomfortable findings without freezing.

AI made bugs cheap to find.

Now the hard part is proving you can fix them.