"Wait Another Year for AI Coding to Mature": A Response From Someone Who Didn't

I came across a LinkedIn comment this week that I can’t stop thinking about. It was in Hebrew, buried under a post about AI adoption, and the argument goes roughly like this:

Companies were profitable before AI. If you spend time and money training people to use AI tools, the burden of proof is to show net profit growth on the bottom line, relative to what would have existed without AI. What actually happens, the commenter says, is customers receive products whose bugs are worse than what human employees would have produced. They refuse to sign acceptance. They don’t pay, because the work wasn’t completed per the contract. The company is left with negative cash flow and enters losses. Meanwhile investors pressure for release, deployment, acceptance, and ROI on the “AI CODING COWORKER”, which, in his words, really doesn’t exist. His recommendation: wait another year for more mature AI coding solutions to arrive.

I read this and I felt two things at once.

The first was a flicker of recognition. He is describing a real failure mode, and I’ve seen it up close. The second was irritation, because from that real failure mode he jumped to a sweeping claim that AI coding doesn’t actually work, and the sensible move is to sit this one out. I disagree with that, and I disagree not as an opinion but as a data point.

I am a solo founder. I run an agtech company called Agrinovo. I design the hardware, write the firmware, build the backend, ship the web frontend, maintain the mobile app, run a CRM, operate three AI agents in production, and write all the marketing content in two languages. Eight repositories. Real customers in real countries. Real money. No employees. No co-founder. No engineering team.

This only exists because of AI coding.

So when someone says the AI coding coworker “really doesn’t exist,” I have to push back, because I am standing in the middle of the proof that it does.

What the critic gets right

Let me start where he’s correct, because he is, on one point.

It is absolutely possible to spend a year and a lot of money on AI coding tooling and end up with nothing usable. I’ve done a version of it myself. About a year ago I tried to build an internal CRM by letting an AI agent generate a frontend while I steered it loosely. No data model. No API contract. No spec. Just vibes. It went nowhere. I abandoned it. Months later I restarted that same project with a proper schema, a real database, and a focused scope, and the replacement is now in production handling every customer record, invoice, and inventory operation in my company.

The failed version cost me weeks. The successful version cost me less time, because I’d already learned the lesson.

So yes. If you throw AI coding tools at a team that doesn’t know what it’s building, that can’t define “done”, that has no taste for what good software looks like, and that measures progress by lines of code rather than by outcomes, you will get exactly the disaster the commenter describes. The pull requests pile up. The test suite turns orange. Customers reject the deliverables. The CFO notices. The investors start asking uncomfortable questions. The company spirals.

That is a real pattern and I believe it’s happening right now in plenty of organizations. He’s describing it accurately.

What the critic gets badly wrong

Here’s where the argument collapses.

The commenter takes that specific failure mode and generalizes it to “AI coding coworker really doesn’t exist.” That’s a factually wrong claim, and you can test it by looking at the code I ship on a Tuesday. It exists. It’s shipping into production. It closed a contract against an established competitor. It’s serving customers who have no idea and no reason to care which parts of their product came out of a Claude session and which parts came out of my head. The code either works in the field or it doesn’t. When a pH sensor on a customer’s farm stops returning data at 2 AM, the farmer doesn’t ask me who wrote the firmware. He asks me why it’s broken. That’s the real acceptance test, and my acceptance rate is not zero.

The leap from “some companies are failing with AI coding” to “AI coding coworker doesn’t exist” is the same move as looking at a bankrupt restaurant and concluding that food service is not a viable industry. A real failure mode is not proof of universal failure. It’s proof that the thing requires skill.

Let me take his specific claims one at a time.

Claim: customers reject AI-built products because bugs are worse than human output. This has not been my experience, and I don’t think it’s being measured honestly where it is happening. My customers don’t reject my product. They renew. They refer other customers. They sign co-development contracts. One of them, a large fish hatchery, signed a multi-month build with me after evaluating a competitor that has a full engineering team. The competitor lost because my iteration cycle was faster and my product conversation was sharper, both of which are direct consequences of working with AI. The bugs exist, of course. Every software product has bugs. The question is whether the bug rate is worse than what a human team would have produced, and I have strong reasons to believe mine is lower, because the AI holds more context across more repositories than any single human teammate I’ve ever worked with.

Claim: expenses skyrocket while revenue collapses. In my case the opposite is true. The dominant expense at a software company is payroll. I don’t have payroll. The Anthropic bill is a rounding error compared to even a single junior engineer’s loaded cost. The AI coding tools didn’t inflate my burn. They are the reason my burn is almost zero.

Claim: investors are pressuring for ROI on AI coding that doesn’t exist. I don’t have investors, so this one doesn’t apply to me directly. But I will say this: if you’re an investor and the company you funded is spending serious money on AI coding tools and not shipping measurable product, that is not a story about AI. That is a story about whether that company’s leadership knows what it’s doing. AI tools don’t create discipline. They amplify whatever discipline or indiscipline is already in the room. A disciplined team will ship faster with AI. An undisciplined team will fail faster with AI. That is not the tool’s fault.

Claim: better to wait another year until more complete AI coding solutions arrive. This is the one I’d push back on hardest, and not just intellectually. Waiting is not free. Waiting has a cost, and the cost is that while you are waiting, your competitors are compounding. I won my biggest contract this year because I was faster to iterate, not because I had better capital, better connections, or a bigger team. The “wait and see” founder who comes to the same customer in 2027 with the same pitch will find that the customer is already locked into somebody else’s platform. You don’t catch up by waiting. You fall further behind.

The burden of proof question

The part of the argument that is intellectually honest is the framing around burden of proof. He says: if you’re going to invest in AI tooling, you have to show net profit growth relative to a no-AI counterfactual. Fine. Let’s actually do that exercise for my company.

My counterfactual without AI coding is not “same company, same output, slightly higher payroll.” My counterfactual without AI coding is “this company does not exist.” I cannot write firmware in C++, a Node.js backend, a React frontend, a React Native mobile app, three AI agents, a CRM, and a bilingual marketing site by myself. Nobody can. Before AI, this specific company would have required at minimum five people: a firmware engineer, a backend engineer, a frontend engineer, a mobile engineer, and a marketing or ops person. At Israeli market salaries, loaded, that’s something on the order of a million shekels a year in payroll before anything else.

The AI-coding counterfactual isn’t a marginal improvement over the no-AI world. It is the entire existence of the company. The ROI isn’t a percentage. It’s binary. Without these tools, the business is zero. With them, the business is something. That’s the actual math.

I want to be careful here. I’m not claiming every company’s math looks like mine. A 500-person enterprise with entrenched processes and a legacy codebase is going to have a much harder time extracting value from AI tooling than a solo founder starting from scratch. I believe that. The onboarding overhead, the integration friction, the cultural resistance, the “we already have a process for this” inertia, all of it is real. But the LinkedIn comment isn’t making that nuanced argument. It’s making the absolute one. And the absolute claim is falsifiable by a single counter-example, of which I am one of many.

Why critics want you to wait

Every time a genuinely useful new capability appears in the world, there is a predictable wave of people explaining confidently that it doesn’t really work, the ROI isn’t there, and you should wait for the next generation. Sometimes they’re right. Mostly they’re not. The people who waited for cloud computing to mature in 2010 before adopting it missed a decade of compounding. The people who waited for mobile to mature before building mobile-first products got eaten. The people who waited for SaaS to be “proven” built on-prem software for another five years and then had to rewrite everything.

I don’t know if AI coding turns out to be as foundational as those shifts. I suspect it does. But even if I’m wrong about the magnitude, the direction of the trade is clear. The cost of trying AI coding seriously, with discipline, on a real project, is low. The cost of waiting, while more disciplined operators compound, is high. The asymmetry is obvious.

The critics who tell you to wait are not doing you a favor. They are, often without realizing it, asking you to stay inside their comfort zone so they don’t have to revisit their priors.

What I’d tell a founder reading that comment

If you’re a founder reading that LinkedIn comment and wondering whether it has a point, here’s the honest version.

Yes, there is a failure mode. The failure mode is real. If you hand AI coding tools to a team that can’t define its product, doesn’t own its technical standards, and measures progress by output volume instead of customer outcomes, you will get exactly the wreck the commenter is describing. That is a real risk and I take it seriously.

But the failure mode is not the technology. It’s the operators. The same mistake has been made with every powerful tool in every previous era. Blaming the tool is easier than blaming the process, which is why it’s the more popular narrative, which is why that comment gets engagement, which is why you’re reading about it now.

The people shipping with AI today are not smarter than the people failing with AI today. They have a different discipline. They write specs before they write prompts. They ship small changes and measure them. They know what “done” means before they start. They delete code aggressively. They refuse to let the AI build features that nobody asked for just because the AI can build them cheaply. They treat AI coding as a multiplier on their judgment, not a substitute for it.

If you are prepared to be that kind of operator, you don’t need to wait another year. You need to start.

I started. I didn’t wait. My competitors with their full teams are not beating me. The products I ship work. The customers I sign stay signed. The contracts I win are not going to people who waited. They’re going to me.

That’s not a prediction about what AI coding will become in 2027. That’s a description of what it already is, today, on a Tuesday in April, from someone who’s been running a real company on it for over a year.

The critic can keep waiting. I’ll keep shipping.