I Can't Write a Single Line of PHP. Here's What I Can Do.

I cannot write a single line of PHP. Not an if statement, not a for loop. I don’t know how to assign a variable or write the most basic function. If you sat me down at a blank file and told me to write something in PHP from memory, I would stare at the screen.

And yet, in the last two months, I’ve made over 120 commits to a Laravel SaaS product. I’ve fixed bugs, built an onboarding flow from scratch, added AI agents, overhauled external API calls, standardised on Flux UI components and error handling, updated dependencies, and more.

None of this required me to write code. All of it required me to know what to build and why.

Table of contents

What I actually can’t do

Let me be specific. I have literally zero PHP syntax knowledge. I couldn’t tell you the difference between -> and => without looking it up. I don’t know how a Laravel controller is structured. I’ve never written a migration file by hand. If you showed me a Blade template and a Livewire component side by side, I probably couldn’t tell you which was which without context clues.

I have some technical exposure — I’ve dabbled in HTML and CSS over the years, and I’m comfortable in a terminal. But I am not, and have never been, a developer.

What I can do

Building a product requires a hundred decisions. The code is the easy part now — AI handles that. Here’s what I actually spend my time on:

• Run database migrations — I’ve created and run Laravel migrations to add tables, modify columns, and restructure schemas. I understand why you never touch the database directly and how migrations keep everything in sync across environments.
• Use queues and background jobs — I’ve set up queue workers to handle tasks like sending emails and processing data asynchronously. I understand the difference between sync and queue drivers, and when to dispatch a job versus handle something inline.
• Use Artisan commands — I run php artisan commands daily. Clearing caches, running migrations, generating files, tinker sessions. I’ve even built custom Artisan commands for maintenance tasks.
• Work with Laravel Tinker — When I need to inspect data or test a quick hypothesis, I jump into Tinker. It’s how I’ve debugged tricky issues like updateOrCreate with null IDs and verified fixes before committing.
• Navigate MySQL and PostgreSQL — I use TablePlus to inspect tables, check data integrity, and understand the schema. I’ve worked with both MySQL and PostgreSQL and understand the trade-offs between them.
• Use Laravel Herd — My local dev environment runs on Herd. I manage sites, switch PHP versions, and configure services without touching config files manually. When things break, I know how to fix common local dev errors.
• Use Laravel Boost — This is a big one. Laravel Boost is Laravel’s official MCP server that gives AI agents deep context about your codebase. It exposes 15+ specialised tools — database schema inspection, route listing, log reading, Tinker sessions, config values, documentation search — so the AI understands your actual application, not just the file it’s looking at. It turns a general-purpose AI into a Laravel-specific collaborator.
• Use Git effectively — I commit, branch, merge, rebase, cherry-pick, and push to production. I learned the entire git workflow by asking questions in plain English. Now I manage a codebase with hundreds of commits across multiple repositories.
• Fix N+1 query problems — I’ve identified and fixed N+1 queries in Livewire components by adding eager loading. This is the kind of performance issue that silently kills your app, and I caught it without understanding the underlying PHP.
• Handle security vulnerabilities — When I received a spam vulnerability report, I triaged it, understood the threat, and shipped a fix that used cryptographically secure Str::random for share link hashes. I didn’t write the code — but I directed the fix.
• Debug production errors — I’ve traced three bugs hiding behind a single production error, working through stack traces and log files to find root causes across multiple files.
• Make architecture decisions — I decided when to use Livewire components versus Blade templates, when to convert components for performance, and when a feature needs a background job versus an inline operation.
• Optimise frontend performance — I’ve removed dead JavaScript nobody was using, prevented visual shift on page load, and audited page speed to find and fix nine issues.
• Polish UX to a level AI won’t do on its own — Border colours, font weights, heading alignment, dropdown icon choices. I’ve done dozens of small UX fixes that make the app feel professional. The AI never flagged any of these — I noticed them and directed the changes.
• Choose and configure UI components — I work with Flux UI daily, and I’ve debugged date format issues and checkbox behaviour that required understanding what the component was supposed to do, not how it was coded.
• Manage data migrations — When I switched WYSIWYG editors, all my images disappeared. I diagnosed the problem, understood the data model difference, and directed a migration that preserved every image.
• Deploy and manage infrastructure — I deploy Laravel to production, manage environment variables, configure Cloudflare, set up DNS, and handle SSL. I’ve also built and deployed a separate Astro marketing site with static hosting.
• Configure Dependabot — I set up automated dependency updates with weekly Composer and npm checks, because keeping dependencies current is a security practice, not a coding skill.
• Write technical content — I’ve published 20 articles about building with Laravel, each one grounded in real problems I’ve solved. Writing clearly about technical concepts is a skill that has nothing to do with syntax.
• Add Livewire interactivity — Toggle charts between daily and monthly views, build dynamic tables, wire up form submissions. I direct what the interaction should feel like, and the AI handles the implementation.
• Use Claude Code with Opus 4.6 — This is my primary tool. I describe what I want in plain English, review what comes back, adjust, iterate. It’s a collaborative back-and-forth, not dictation. The AI proposes, I evaluate, and we converge on something good.

That’s not a list of things I did once. That’s what a typical two-week stretch looks like.

The workflow

My process is simple. I describe what I want in plain English. Claude Code writes the code. I review it — not the syntax, but the behaviour. Does it do what I asked? Does it break anything else? Does it feel right when I use it?

If something’s off, I say what’s wrong. Not “change line 47” — more like “the chart still shows daily data when I click monthly” or “the border colour doesn’t match the sidebar.” The AI figures out the implementation. I stay focused on the product.

This is what I’ve learned about AI from actually building with it: it’s great at structure, bad at taste. It will write perfectly functional code that looks slightly wrong, and it will never notice. You have to notice. That’s the job now.

Why this works

Jensen Huang, CEO of NVIDIA, put it bluntly:

It is our job to create computing technology such that nobody has to program. And that the programming language is human.

And Andrej Karpathy, former head of AI at Tesla and founding member of OpenAI, said:

The hottest new programming language is English.

They’re not being provocative. They’re describing what’s already happening. I’m living proof. The bottleneck in building products is no longer writing code. It’s articulating what you want, evaluating whether you got it, and knowing when something isn’t right.

These are skills that marketers, designers, product managers, and founders have been developing for years. The difference is that now those skills are directly useful for building software.

What actually matters now

Writing code used to be the price of admission. If you couldn’t write it, you couldn’t build. That created a dependency — every idea had to go through someone who could translate it into syntax.

That dependency is dissolving. Not because AI writes perfect code (it doesn’t — read about what it actually taught me), but because the gap between “knowing what to build” and “having it built” has collapsed.

What matters now is:

• Product sense — knowing what to build and why it matters
• Taste — recognising when something feels off, even when it technically works
• Domain knowledge — understanding your users, your market, and the problem you’re solving
• Communication — describing what you want clearly enough for an AI (or a human) to execute it
• Judgement — knowing when to ship, when to polish, and when to scrap something

These were always the hard parts. We just couldn’t see it because writing code was the loud, visible bottleneck that sat in front of everything else.

Who this is for

Non-technical founders get told they need a technical co-founder. Maybe you don’t. Marketers wait on dev teams to ship a landing page. You can build it yourself. And if you’re sceptical that AI coding tools work for real products — I’ve shipped over 120 commits in two months, and I can’t write echo 'hello'.

Laravel is particularly good for this. Its conventions, documentation, and ecosystem (Herd, Boost, Forge, Tinker) make most decisions for you. You don’t need to make a thousand architectural decisions before you start. Laravel makes them, and AI handles the rest.

The question is no longer “can you code?” The question is “do you know what to build?”

I do. And that’s enough.