I also remain a bit skeptical because, if all of this really worked (and I mean over a long time and scaling to meet a range of business requirements), even if it's not how I personally want to write code, shouldn't we be seeing a ton of 1 person startups?

I see Bay area startups pushing 996 and requiring living in the Bay area because of the importance of working in an office to reduce communication hurdles. But if I can really 10x my current productivity, I can get the power of a seed series startup with even less communication overhead (I could also get by with much less capital). Imagine being able to hire 10 reliable junior-mid engineers who unquestionably followed your instruction and didn't need to sleep. This is what I keep being told we have for $200/month. Forget not needing engineers, why do we need angel investors or even early stage VC? A single smart engineer should be able, if all the claims I'm hearing are true, to easily accomplish in months what used to take years.

But I keep seeing products shipped at the same speed but with a $200 per month per user overhead. Honestly I would love to be wrong on this because that would be incredibly cool. But unfortunately I'm not seeing it yet.

    >  shouldn't we be seeing a ton of 1 person startups?

I know 3 such founders; none would advertise to their customers the extent of their AI usage. There is also a consideration that if they advertise their 1 eng status and success, it might attract other competitors or the customers might think they can do it themselves (maybe possible, but not for 95% of them since some tech know how is still required) or customers would see it as a business risk.

All 3 have blown me away with what they are doing. All 3 have real, paying customers. (They occasionally reach out for some higher order architecture questions)

[0] https://mikelovesrobots.substack.com/p/wheres-the-shovelware...

2 of the 3 existed as entities for more than a year already, but pivoted at least once (both were VC-funded but now doing something very different than what they started with when I first met founders) and ultimately let go of their offshore and contract engineers once AI became good enough some time early last year. Founders basically realized that the quality of code was as good or better than what they were getting from their engineers while reducing the turnaround time; now they can go from talking to customers to having a working prototype in the same day instead of waiting 24h+ for an offshore team. The other one started in November of 2024 and found traction around March.

So two companies went from multi-person teams to 1 person teams and 1 team was a 1 person eng team from the get-go (with a business-oriented partner).

I'd also point out that 2025 was a particularly volatile year because of shifts in the political and economic environment (including very high interest rates) so I wouldn't take your stat at face value without considering external factors that might affect the total number of net new business registrations.

It still remains true that building a product is not the same thing as building a business. It may be that we'll see less SaaS startups as companies find that they can just in-house software instead of buying. Who knows? Startup I'm at canceled one of our subscriptions because we ended up building an in-house replacement because it is now cheap enough and easy enough that we could.

I'm not saying your three friends/acquaintances don't exist, I'm saying the evidence suggests they aren't representative of a trend. This is consistent with the other evidence we have (e.g. studies which show that LLMs produce at best relatively modest gains in productivity, not enough for a one person team to do the work of even two people.

> I'd also point out that 2025 was a particularly volatile year because of shifts in the political and economic environment so I wouldn't take your stat at face value without considering external factors that might affect the total number of net new business registrations.

Sure, it's always possible that without LLMs there would have been a significant contraction in these metrics. The issue is exactly that though: you can always make that argument. In other words, you've rendered your claims unfalsifiable.

We’ve found that building the product got easier, but turning it into a sustainable business still required just as much manual effort around sales, onboarding, and retention.

I’d have to say when I hire someone in Fiverr to make a logo for my app I’m not suddenly a multi-person team. If I use AI to make my logo instead of paying a human $50 to make one I didn’t exactly experience a productivity revolution.

The other thought that popped into my head is that offshore contractors have access to AI, too. So shouldn’t we see their output go up and prices go down? Again we have another facet of this lack of market indicators.

Some had employees (which were let go when they pivoted). Some were contractors doing all of the engineering work.

Are they using AI because it’s better or because they have no other choice?

If I hire two sandwich artists for 6 months but nobody buys my sandwiches, I don’t have much choice but to fire them.

This word “pivot” is strong.

    > Are they using AI because it’s better

    > If I hire two sandwich artists for 6 months but nobody buys my sandwiches

Because they went back to the drawing board, they ended up letting go of their teams and started using AI to build MVPs and then found that they could ship faster and better.

They literally changed to doing an entirely different business.

This would be like saying I hired two sandwich artists, but sandwiches don’t sell well, so I fired my sandwich artists and now I run a coffee shop on my own.

I'm sharing information, not presenting an argument. You seem to want to argue that... something, but it is not apparent to me what it is.

Whatever you choose to do with this information, it did not change reality.

I could see AI coding leading to more attempted startups, and more people shipping initial products and attempting to get traction with them, but whether they do get traction and achieve PMF, and are able to actually grow it into a business is going to come down to the startup expertise of the founders, not how quickly/cheaply the code of the product was written.

Shipping something workable is easier now, but understanding which problems are actually worth solving — and getting consistent feedback early — still seems to be the main separator between hobby projects and real businesses.

My prediction is that this will lead to a margin free-fall for many software products where the main moat is the software itself. And a lot of SaaS companies will also become redundant when the AI can code up a tailored solution in an hour for free.

But that is also a reason to be cautious of chasing capital and think hard about whether you can spend it sensibly fast enough to improve your own ROI...

E.g. I have a project right now where I won't consider taking VC cash because I don't think I can spend it fast enough to buy me enough additional leverage to make enough additional money to compensate for the dilution and the other usual shenanigans before I expect margins will be squeezed out of the niche in question. It also means I don't think the opportunity will ever scale above a certain level, but that's fine - it'll be a quick attempt at grabbing what profit I can.

Also, while we of course shouldn't diminish the potential moat created by understanding the product in favour of only value the tech, we need to also consider that AI's are a levelling factor there too. Claude knows (I've verified what it's said) more about the niche I'm vaguely talking about than I do - it knows pricing, it knows positioning/marketing, it knows conventions and requirements of the niche, and while I'm sure I could have found all of it myself starting from scratch too it shortcircuited an enormous amount of effort to get an infodump that let me know precisely what to look for to verify it. A lot of tech companies will find the institutional knowledge they thought would shore up their moat is worth a lot less than they thought.

I totally agree. I think going forward the primary value of SAS will be the embedded domain expertise in a pre-built product. The comparison of Asana versus Notion comes to mind for project management. Asana forces abstractions of good project management upon you, whereas Notion lets you build it yourself. I think this principle will scale to all software in the future, where the only real value of software or it becomes exported maintenance obligations and a predetermines domain abstraction.

But as you mentioned, I think companies will rapidly find that their own specific abstraction is worth a lot less than they believed.

Sure, there was some lead, but not nearly enough to 2x the team's productivity, let alone 10x.

Even when presented with something, there was still lead time turning that into something actually actionable as edge cases were sussed out.

SaaS is extremely vulnerable, companies will be able to modify open source tools to do exactly what they need, and agents will make managing those services easier. This will lead to downward pressure on SaaS prices, and cause them to become more like cloud data management platforms that they let customers build on top of rather than one-size-fits-all apps.

Counterpoint: Windows, Oracle DB, etc. have had free/cheaper alternatives for decades and still thrived.

The median dev salary across the entire US is something like $130k/yr. There are huge numbers of new or self-taught software devs in low cost of living areas of the country making $50-60k/yr.

Not to mention having the right mindset for startups and building a business.

The code and product is maybe only 20% of the story.

If you don't have some kind of cult following like Apple eventually you'll get margin-squeezed till death and all that marketing, sales, etc. will get cut down to stay afloat.

Of course all of the above is just my theory how this will play out in the long run, I'm no oracle by any means.

    > that offer the same for 10x less money.

But beyond that, it's not likely that there are 10x the number of people who know the domain and have the right mindset plus appetite for risk.

They'll be squeezing margins out of a lot more than just the tech.

    > you better take a half dozen executives with you or you'd never get the first meeting no matter how good the product was

In my specific space, clinical trials can run for years. A company that might fold if they run out of runway? Non-starter. I was a member of a small company that did make this work and it required that we put our code in escrow with a large multi-national IT company that owned the support contract (customer paid us for licensing, paid multi-national IT company for support, our source code went into escrow).

At least 1 person on the team needs to have domain experience and if solo, that solo founder needs to have domain experience and good connections or the wherewithal to get the first handful of paying customers via cold calling, cold emails. The main challenge remains sales, marketing, and branding. There are free CRMs and anyone can build a CRM. Why do some CRMs succeed while others fail? Branding, marketing, awareness.

So I don't see it as "there will just be 10x more competitors" because I've built enough stuff that I failed to sell and used enough shitty software to know that the software itself is rarely the reason why people buy X over Y. It's because they didn't even know Y existed.

I would love to start my own SaaS company, even if it generates $1000 a month I will be elated. And I have 20+ years of experience programming and in FinTech, but what do I build? Not to mention, without sales & marketing nothing will really work.

So you definitely still need strong sales and marketing and a deep understanding of a business domain.

1 person and AI is not sufficient to create a business.

Claiming that you now have 10 AI minions just wrecking your codebase sounds like showboating. I do not pity the people who will inherit those codebases later.

With that out of the way, I don't think there will be "people inheriting codebases" for much longer, at least not in the vast majority of business-related software needs. People will still be useful insofar as you need someone responsible and able to be sued for contract breach, failures and whatnot, but we'll see more and more agents inheriting previous agents codebases. And in the other hand, "small software" that caters to particular customized workflows can be produced entirely by LLMs.

I can totally relate how some of us would want to be off raising goats, planting watermelons or whatever.

After months of hearing that people are producing software in months that would normally take years, the best examples of vibe coded software I've seen look like they would normally take months, not years. If you don't care how they're built or how long it took (which a user generally doesn't), much of the remaining shine comes off.

If I'm wrong, I'd love to see it. A genuinely big piece of software produced entirely (or near entirely?) with AI that would've normally taken talented engineers years to build.

Its nothing more than surface level projects that we built when we wanted to pad out the resume.

All difficult problems are solved, by solving simple problems first and combining the simple solutions to solve more difficult problems etc etc.

Claude can do that, but you seriously overestimate it's capabilities by a factor of a thousand or a million.

Code that works but it is buggy, is not what Linux is.

I think your logic goes wrong because you assume that more productivity implies less desire for engineers. But now engineers are maybe 2x or 5x more productive than before. So that makes them more attractive to hire than before. It's not like there was some fixed pool of work to be done and you just had to hire enough to exhaust the pool. It's like if new pickaxes were invented that let your gold miners dig 5x more gold. You'd see an explosion in gold miners, not a reduction. For another example, I spend all my free time coding now because I can do so much now. I get so much more result for the same effort, that it makes sense to put more effort in.

First thing I got was “browser not supported” on mobile. Then I visited the website on desktop and tested languages I’m fluent in and found immediate problems with all of them.

The voices in Portuguese are particular inexcusable, using the Portuguese flag with Brazilian voices; the accents are nothing alike and it’s not uncommon for native speakers of one to have difficulty understanding the other in verbal communication.

The knowledge assessments were subpar and didn’t seem to do anything; the words it tested almost all started with “a” and several are just the masculine/feminine variants. Then, even after I confirmed I knew every word, it still showed me some of those in the learning process, including incredibly basic ones like “I”, or “the”.

The website is something, and I very much appreciate you appear to be trying to build a service which respects the user, but I wouldn’t in good conscience recommend it to anyone. It feels like you have a particular disdain for Duolingo-style apps (I don’t blame you!) but there is so much more out there to explore in language learning.

> First thing I got was “browser not supported” on mobile.

Yeah, I use some APIs that were only implemented in Safari on iOS 26. Kind of annoying but I use Android so I didn't realize until too late. I should fix it, but it's not a priority given the numerous other things that need improvement (as you noticed!)

> The voices in Portuguese are particular inexcusable, using the Portuguese flag with Brazilian voices; the accents are nothing alike and it’s not uncommon for native speakers of one to have difficulty understanding the other in verbal communication.

That's good feedback, thanks! I only added Portuguese this weekend (https://github.com/yaptown/yap/pull/73) so it's definitely still very alpha (as noted on the website :P )

> The knowledge assessments were subpar and didn’t seem to do anything; the words it tested almost all started with “a” and several are just the masculine/feminine variants.

Thanks, will fix this tonight. The placement test was just added last week (https://github.com/yaptown/yap/pull/72) so there are still some kinks to work out.

> Then, even after I confirmed I knew every word, it still showed me some of those in the learning process, including incredibly basic ones like “I”, or “the”.

Yeah, the logic doesn't really work for people who already know every word. It tries to show words in the following order (descending): probability_of_knowledge * ln(frequency). But if you already know every word, probability_of_knowledge is the same for every word and the ln(frequency) is the only one remaining, meaning you just get the most common words. I'll add a warning to the site for people who are too advanced for the app's dictionary size – as you pointed out, it's not a good UX.

> there is so much more out there to explore in language learning

There is! I usually recommend pimsleur to people. My hope is just for my app to be a useful supplement.

I'm my opinion you are failing to consider other bottlenecks, a la the theory of constraints.

An analogy: Imagine you have a widget factory that requires 3 machines, executed in sequence, to produce one widget.

Now imagine one of those machines gets 2x-5x more efficient. What will you do? Buy more of the faster machines? Of course not! Maybe you'll scale up by buying more of the slower machines (which are now your bottleneck) so they can match the output of the faster one, but that's only if you can acquire the raw material inputs fast enough to make use of them, and also that you can sell the output fast enough to not end up with a massive unsold inventory.

Bringing this back to software engineering: there are other processes in the software development lifecycle besides writing code -- namely gathering requirements, testing with users (getting feedback), and deployment / operations. And human coordination across these processes is hard, and hard to scale with agents.

These other aspects are much harder to scale (for now, at least) with agents. This is the core reason why agentic development will lead to fewer developers -- because you just don't need as many developers to deliver the same amount of development velocity.

The same logic explains (at least in part) why US companies don't simply continue hiring more and more outsourced developers. At a certain point, more raw development velocity isn't helpful because you're limited by other constraints.

On the other hand, agentic development DOES mean a boon to solo developers, who can MUCH more easily scale just themselves. It's much easier to coordinate between the product team, the development team, the ops team, and the customer support team when all the teams are in the same person's head.

It works. It's playable. I might put it online some-time when I get a chance.

[EDIT: My involvement apart from the code-skimming mentioned below was mostly play-testing after Claude had "play-tested", and giving it feedback on what to add or change]

My best estimate from having written much simpler games before was that it churned out many months worth of working code in days. I've not written a line of it - just skimmed some code and told it to make a few architectural refactors.

It's absolutely crazy.

Yes, this is the central fallacy. The reality is, we've been massively bottlenecked on software productivity ever since the concept of software existed. Only a tiny tiny fraction of all the software that could usefully be written has been. The limitation has always been the pool of developers that could do the work and the friction in getting those people to be able to do it.

What it is confounded by however is the short term effect which I think is absolutely drying up the market for new junior software devs. It's going to take a while for this to work through.

The hard part is day to day operations for years with thousands of edge cases, actual human feedback and errors, knocking on 1000 doors etc.

Otherwise you're just doing slot machine coding on crack, where you work and work and work one some amazing thing then it goes nowhere - and now you haven't even learned anything because you didn't code so the sideproject isn't even education anymore.

What's the point of such a project?

No, I'm not interested in monetizing stuff, I make enough money from $dayjob.

> Having actual users, working through edge cases, browser quirks, race conditions, marketing, communication - the real battle testing 5% that's actually 95% of the work that in my view is impossible for the LLM?

Yes, all of those. Obviously an LLM won't make a tiktok ad for me, but it can help with all the other stuff. For example, you mentioned browser quirks. I ran into a bug in safari's OPFS implementation that an LLM was able to help me track down and work around. I also ran into the chrome issue where backdrop effects don't work if any of the element's parents have nonzero transparency, and claude helped me find all the cases where that happened and fix them. Both of these are from working on the app in my bio. It's a language app too, so however many edge cases you think there are, there's more :D

I don't want to give the impression that it was not a lot of work. It was an enormous amount of work. It's just that each step is significantly faster now.

> and now you haven't even learned anything because you didn't code so the sideproject isn't even education anymore.

I read every line. You could pull up the github right now and point to any line of code and I could tell you what it does and why it's there and what will break if you remove or change it.

> What's the point of such a project?

I originally made it because I wanted a tool to help me learn French. It has succeeded in helping my enormously, to the point where I can have short conversations with my french family members now. Others seem to find it useful too.

I find when I'm in a domain I'm not an expert in I am way more productive with the AI tools. With no knowledge of Java or Spring I was able to have AI build out a server in like 10 minutes, when it would have taken me hours to figure out the docs and deployment etc. But like, if I knew Java and Spring I could have built that same thing in 10 minutes anyways. That's not nothing, but also not generalisable to all of software development, not even close. Plus you miss out on actually learning the thing.

Not at work, elsewhere

Extra productivity at work is not being used at fixing bugs as well.

There is no way he would have built the CRM as quickly pre-AI.

He built, in a few months, what would have taken maybe one to two years before.

It's probably going to be a while before someone builds the next Instagram with AI. But I think that's more a function of product fit and idea. Less so how fast one person can code.

The first billion-dollar solopreneur likely is going to happen at some point, but it's still a one-in-a-million shot, no matter how fast a person can code.

Look at how many startups fail despite plenty of money for programmers.

But I am seeing friends get to revenue faster with AI on small ideas.

I'm pretty sure that this has already happened, see: https://en.wikipedia.org/wiki/Plenty_of_Fish

Not quite 1bn (but 575mn in 2015 dollars) and mostly done by one person.

Also, "Plenty of Fish uses a Microsoft-based platform for itself, including IIS, ASP.NET, and Microsoft SQL".

2008 I think (from the wikipedia article). I met my now wife on the platform in 2013. I do think it counts, and it's important to note that even pre-AI, software has incredible leverage for small teams/individual people.

I would actually expect that current coding AIs would create something very close to Instagram when instructed.

> I would actually expect that current coding AIs would create something very close to Instagram when instructed

Agree 100 percent! I think a lot of us are conflating writing software with building a business. Writing software is not equal to building a business.

Instagram wasn't necessarily hard to code, it was just the right idea at the right time, well executed, combined with some good fortune.

AI is enabling solo founders to launch faster, but those solo founders still need to know how to launch a successful business. Coding is only 10% of launching a business.

My brother has had some success selling software before AI, so he already knows how to launch a business. But, AI helped him take on a more ambitious idea.

The thing is, if AI is what enabled this, there's no long term market for selling something vibe coded for thousands a month. Maybe right at this moment and good for him, but I have my doubts these random saas things have a future.

If you can sell it in the meantime, go for it and good for you, but it doesn't feel like that business model will stay around if anyone can prompt it themselves.

There is a ton of anti-AI sentiment, and not all LLMs are equal. There is a lot of individual adoption that is yet to occur.

I know at least two startups that are one person or two people that are punching way above their weight due to this force multiplier. I don’t think it’s industry-wide yet, but it will be relatively soon.

Check back in on your assessment in a year.

We are going to see the rest of the industry come along kicking and screaming over the next calendar year, and thats when the ball is going to start truly rolling.

> Check back in on your assessment in a year.

We’ve all read that, and claims grander than that, multiple times over the past few years. And next year someone will say it again.

Now they are. Not everyone is using them yet, but they will. There’s zero doubt about it anymore. Lots of people are still not up to date on what is currently possible.

> Not everyone is using them yet, but they will. There’s zero doubt about it anymore.

That’s not true. On HN and elsewhere you’ll find no shortage of folks who don’t use those tools because they don’t want to. People who find enjoyment in doing the thinking and programming themselves, for whom doing it is the goal. For others there are legal and moral considerations. It’s unrealistic to think everyone will be using LLMs for coding, they won’t. Not everyone thinks alike, but for some reason proponents seem incapable of understanding that. All it takes is a bit of empathy and listening to your fellow humans.

We can’t have a proper discussion if you start by making wrong and uninformed statements about a stranger and promptly assert that you believe anyone who disagrees with you is either malicious or wilfully ignorant. People can experience the same things and still reach different conclusions or have different opinions.

When the same revolutionary messaging is touted over and over with revised dates whenever the previous prediction hasn’t panned out, anyone is justified in not buying that “this time is different” when that has been said multiple times before.

It’s the boy who cried wolf. Sure, maybe someday it will be true, but save it for when it is instead of repeatedly saying “next year”, “in the next five years”.

https://en.wikipedia.org/wiki/The_Boy_Who_Cried_Wolf

https://en.wikipedia.org/wiki/List_of_predictions_for_autono...

The issues of product market fit did not suddenly disappear:

https://www.wired.com/story/artificial-intelligence-startups...

Claude Plugins are a couple `.md` file references, some `/command` handler registrations, and a few other pieces of trivial state. There's not a lot there, but you have to restart the whole damn app to install or update one.

Plus, there's the **ing terminal refresh bug they haven't managed to fix over the past year. Maybe put a team of 30 code agents on that. If I sound bitter, it's because the model itself is genuinely very good. I've just been stuck for a very long time working with it through Claude Code.

Oh, man, they're just waiting for their poster boy to show up. Once first unicorn "built by a single person" pops up you'll regret having a single social network account.

I got laid off in the first half of 2025 and decided to use my severance to see if I could go full-time with my side project. Over the last six months I've gone from zero to about $200k in ARR, and 75% of that was in the last three months. My average customer is paying about $250 / month.

I have zero help, I do everything myself: coding, design, marketing, sales, etc. The product uses AI to replace humans in a niche industry, so the core of the product is AI, but I also increasingly build it with AI. I rarely code manually these days, I'm just riding herd on agents, often in between sales calls, dealing with customer support, etc. I may eventually hire a VA-type person to help with admin and customer support stuff where it changes often enough that it's not worth it to build an AI workflow for, but even there...I don't know. If we get reliable computer use models in 2026 or 2027, I probably won't ever hire anyone.

I've never talked openly in tech circles about this product, nor will I. The technical challenges are non-trivial, so I don't think it'd be easy to replicate for another engineer, but my competitors are all dinosaurs and getting customers to switch to me is incredibly easy. The last thing I need is another engineer spinning up a competitor.

Who should be seeing that? The thing about 1 person startups is that it requires little to no communication to start up, and also very little capital. Seems easy to fly below the radar.

Also "a ton", idk. Doing a startup is still hard, for reasons outside of just being able to write a lot of code. In my experience churning out all this code at 10x is coming with a significant complexity tax: Turns out writing code and thinking about code problems was the relaxing part. When that goes away you have to think about real world problems only. What a fucking mess.

Still, I would assume that it's more of a thing now, and something you could observe when you have YC data for example. Do we know that's not the case? I am in no position to say, one way or the other.

That’s how I feel about a lot of AI-powered development. Just because you can have 10 parallel agents cranking out features 24/7 and have AI write 100% of the code, that doesn’t mean you’re actually building a product that users want and/or that is a viable business.

I’m currently in this situation, working on a greenfield project as founder/solo dev. Yes, AI has been tremendously useful in speeding things up, especially in patching over smaller knowledge gaps of mine.

But in the end, as in all the projects before in my career, building the MVP has rarely been the hard part of starting a company.

This is toxic behavior by these companies, and is not backed by any empirical data that I’ve ever seen. It should be shunned and called out.

As far as the remainder of your post, I think you’ve uncovered solid evidence that the abilities of LLMs to code on their own, without human planning, architecting, and constant correction, is significantly oversold by most of the companies pushing the tech.

What does this mean? You mean they have close to 1k employees? Odd typo or odd way to say it.

Businesses are not code. They solve problems, find their customers, convince them to buy their solution, and maintain that relationship.

Code has always been a factor but not the critical one.

How do you know this is not happening. There is always a lag. By the time you visibly see it, its already past.

Too early. Wait a year. People are just coming to grips how to really make these agents make good changes and large enough changes to really start accelerating.

Also, expect a number of those startups to be entirely stealth and wait longer to raise, as well as maybe in many cases be more fleeting and/or far more fast moving (having to totally re-invent what they're doing at a pace you wouldn't expect to before).

I've been full in on this for 2 years now, and I'm only just at the stage where I feel my setups and model capabilities are intersecting to produce results good enough that I've started testing if one project I'm working on will actually manage to generate revenue.

I'm not going to tell you what it is, because if I did there's too little moat and HN is crawling with great people who could probably replicate it and execute on it faster than me, and Claude is capable of doing all the heavy lifting entirely by itself - that in itself is what makes it potentially viable -, so sorry for being vauge.

If it shows signs of generating revenue, it'll be so cheap to scale because of Claude, that I'll be able scale it far before I need to raise any capital.

But other people will figure it out, most likely other people are already doing the same thing.

As a result I have a short window, and it likely will close as model improvements will make it more and more trivial to do what I'm trying to do, so my approach is to try to extract as much return as I can in as little time as I can, hoping there isn't yet too much competition, and then move on.

This last part will also limit - a lot of people just won't be able to move fast enough (I might not have), and so a lot of these "one person startups" won't ever become visible because they won't even get to a stage where people are ready to talk about it.

In this case, it is easily measurable how much time Claude has saved me, because I've done the same thing before, manually, and made money from it, and the fastest turnaround I've achieved before was 21 days. So far, my first test run with Claude + me in the loop produced the same quality in 3 days, my second in 2 days, my third 12 hours, and I think I can drive it down towards 1-2 hours of my time, with me being the blocker to speeding it up beyond that.

At 21 days it wasn't really profitable. At 1-2 days it "should be" wildly profitable unless I'm already too late. If I can get it down to an hour or two of my time, then I'd also be able to hire to scale it further with good margin, and the question is just finding the sweet spot.

This opportunity will never be a unicorn, but there's a lot of money there if you don't need to raise, and the cost of scaling it to the sweet spot where I maximise my returns is something I should be able to finance without outside money the moment I validate that the unit economics are right.

You might not hear about this "one person startup" again until it either has failed and I decide to tell the story, or it's succeeded but the opportunity has closed and I've made what I can make from it. I suspect there will be many cases like mine that you'll never hear about at all.

(and yes, I realise a lot of people will just dismiss this as bullshit because I won't give details; that's fine)

I hadn't really used Claude before, but if nobody cares ... then commercialize it, delete the blog post and code from the open source world. In the last month, Claude has helped turn it from a <700 line algorithm into nearly a full-blown product in its own right.

But yeah, the moat is small. The core of everything is less than 5k LoC; and it'd be easy af for my soon-to-be competitors to reproduce. The only thing I've got going for me is a non-technical cofounder believing in me and pounding on doors to find our first customer, while I finish up the technical side.

With the computer science revelations, we can basically keep us 6-8 months ahead for the next couple of years. This is the result of years of hard work, but AI has let me take it to market at an astounding speed.

Effectively, I try to:

- Do not allow the LLM to make any implicit decisions, but instead confirm with the user.

- Ensure code is written in such a way that it's easy to understand for LLMs;

- Capture all "invisible knowledge" around decisions and architecture that's difficult to infer from code alone.

It's based entirely on Claude Code sub-agents + skills. The skills almost all invoke a Python script that guides the agents through workflows.

It's not a fast workflow: it frequently takes more than 1 hour just for the planning phase. Execution is significantly faster, as (typically) most issues have been discovered during the planning phase already (otherwise it would be considered a bug and I'd improve the workflow based on that).

I'm under the impression that the creator of Claude Code's post is also intended to raise awareness of certain features of Claude Code, such as hand-offs to the cloud and back. Their workflow only works for small features. It reads a bit like someone took a “best practices” guide and turned it into a twitter post. Nice, but not nearly detailed enough for an actual workflow.

[1] https://github.com/solatis/claude-config/

> Capture all "invisible knowledge" around decisions and architecture that's difficult to infer from code alone.

I work on projects where people love to create all sorts of complex abstractions but also hate writing ADRs (so they don’t) or often any sorts of comments and when they do they’re not very well written. Like the expectation is that you should call and ask the person who wrote something or have a multi-hour meeting where you make decisions and write nothing down.

That sort of environment is only conductive to manual work, dear reader, avoid those. Heed the advice above about documenting stuff.

Over the summer last year, I had the AI (Gemini Pro 2.5) write base libraries from scratch that area easy for itself to write code against. Now GPro3 can one-shot (with, at most, a single debug loop at the REPL) 100% of the normal code I need developed (back office/business-type code).

Huge productivity booster, there are a few things that are very easy for humans to do that AI struggles with. By removing them, the AI has been just fantastic to work with.

I'm doing this in a Clojure context, so that helps—the core language/libraries are unusually stable and widely used and so feature-complete there's basically no hallucinations.

I sometimes don’t share links, due to this and then sometimes overshare or miss the mark on relevance.

But sometimes when I do share people are excited about it, so I’ve leaned more to sharing. Worst is you get some downvotes or negative comments, so why not if there is some lurker who might get benefit.

When you don’t blog or influence, how else but in related HN comment threads are like-minded people gonna know about some random GitHub repo?

My second level hope is that it gets picked up by AI crawlers and get aligned somewhere in the latent space to help prompters find it.

ETA: “The [Prompt Engineer] skill was optimized using itself.” That is a whole other self-promotional writeup possibility right there.

yeah last time I shared it, I got a whole lot of hate for vibe coder self promotional BS so I decided to tread a bit more carefully this time.

I encourage you to try to prompt engineer skill! It’s one of the easiest to use, and you can literally use it on anything, and you’ll also immediately see how the “dynamic prompt workflow” works.

You give each agent a git worktree and if you want to check, you checkout their branch.

Often these days I vibe code a feedback loop for each project, a way to validate itself as OP said. This adds time to how long Claude takes to complete giving me time to switch context for another active project.

I also use light mode which might help others... jks

The max Claude instances I've run is 2 because beyond that, I'm - as you say - unable to actually determine the next best course during the processing time. I could spend the entire day planning / designing prompts - and perhaps that will be the most efficient software development practise in the future. And/or perhaps there it is a sign I'm doing insufficient design up front.

Washing dishes in parallel with laundry and cleaning is of course easily possible, but precisely because there is no cognitive load involved. When the washing machine stops you can interrupt what you are doing to load clothes into the drier, then go back to cleaning/whatever. Software development for anything non-trivial obviously has a much higher task-switching overhead. Optimal flow for a purely human developer is to "load context" at the beginning of the day, then remain in flow-state without interruptions.

The cynical part of me can't also help but wonder if Cherny/Anthopic aren't just advocating token-maxxing!

* a small PR costs 5-16 usd (I’ve been monitoring this for the past two days). Management is already pushing for us to use Cursor or a new tool called Augment Cod. * I can submit 4 to 5 PRs in a day * the bottleneck becomes:

- writing clear instructions and making the right choices - running tests - my mental capacity for context switching - code reviewing, correcting - Deployment - Even further live testing

I don’t understand how I could have 10 parallel workers without the output being degraded due to my inability to manage them. But I can see myself wasting a lot of $$ trying. And something tells me the thread is just normalizing throwing money at them

https://github.com/anthropics/claude-code/issues

If you read though a few pages of these issues, it doesn't seem to reflect too well on the quality of the code (self-written by Claude Code), so it seems the furious pace of development/bug fixing maybe shouldn't necessarily be taken as being the pace of generating production quality code. Claude Code is of course very useful, so people are very forgiving about issues, but I can't imagine most corporate software being very well regarded if the quality was such that it had 5K issues reported against it!

If you only have that one problem, that is a reasonable criticism, but you may have 10 different problems and want to focus on the important one while the smaller stuff is AIed away.

> I don't understand how you can generate requirements quicky enough to have 10 parallel agents chewing away at meaningful work.

I am generally happy with the assumptions it makes when given few requirements? In a lot of cases I just need a feature and the specifics are fairly open or very obvious given the context.

For example, I am adding MFA options to one project. As I already have MFA for another portal on it, I just told Claude to add MFA options for all users. Single sentence with no details. Result seems perfectly servicable, if in need of some CSS changes.

Can someone give an example of what each of them would be doing?

Are they just really slow, is that the problem?

Could also be a bug hunt "Sometimes we get an error message about XYZ, please investigate how that might happen." or "Please move setting XY from localstorage to cookies".

Here is one case, though:

I have a prototype Ruby compiler that long languished because I didn't have time. I recently picked up work on it again with Claude Code.

There are literally thousands of unimplemented methods in the standard library. While that has not been my focus so far, my next step for it is to make Claude work on implementing missing methods in 10+ sessions in parallel, because why not? While there are some inter-dependencies (e.g. code that would at least be better with more of the methods of the lowest level core classes already in place), a huge proportion are mostly independent.

In this case the rubyspec test suite is there to verify compliance. On top of that I have my own tests (does the compiler still compile itself, and does the selftests still run when compiled with self-compiled compiler?) so having 10+ sessions "pick off" missing pieces, make an attempt see if it can make it pass, and move on, works well.

My main limitation is that I have already once run into the weekly limits of my (most expensive) Claude Max subscription, and I need it for other things too for client work and I'm not willing to pay-per-token for the API use for that project since it's not immediately giving me a return.

(And yes, they're "slow" - but faster than me; if they were fast enough, then sure, it'd be nicer to have them run serially, the same way if you had time it's easier to get cohesive work if a single developer does all the work on a project instead of having a team try to coordinate)

For one of the things I am doing, I am the solo developer on a web application. At any given point, there are 4-5 large features I want and I instruct Claude to heavily test those features, so it is not unusual for each to run for 30-45 minutes and for overall conversations to span several hours. People are correct that it often makes mistakes, so that testing phase usually uncovers a bunch of issues it has to fix.

I usually have 1-2 mop up terminal windows open for small things I notice as I go along that I want to fix. Claude can be bad about things like putting white text on a white button and I want a free terminal to just drop every little nitpick into it. They exist for me to just throw small tasks into. Yes, you really should start a new convo every need, but these are small things and I do not want to disrupt my flow.

There are another 2-3 for smaller features that I am regularly reviewing and resetting. And then another one dedicated to just running the tests already built over and over again and solving any failures or investigating things. Another one is for research to tell me things about the codebase.

Sloppy? Perhaps, but Claude has never made such a big mess that it has needed its work wiped.

I think a key thing to point out to people here is that Claude's built in editing tools won't generally allow it to write to a file that has changed since last time it read it, so if it tries to write and gets an error it will tend to re-read the file, adjust its changes accordingly before trying again. I don't know how foolproof those tests are, because Claude can get creative with sed and cat to edit files, and of course if a change crosses file boundaries this might not avoid broken changes entirely. But generally - as you said - it seems good at avoiding big messes.

But AI Agents need time. They need a little bit of reading the sourcecode, proposing the change, making the change, running the verification loop, creating the git commit etc. Can be a minute, can be 10 and potentially a lot longer too.

So if your code base is big enough that you can work o different topics, you just do that:

- Fix this small bug in the UI when xy happens - Add a new field to this form - Cleanup the README with content x - . . .

I'm an architect at work and have done product management on the side as its a very technical project. I have very little problem coming up with things to fix, enhnace, cleanup etc. I have hard limits on my headcount.

I could easily do a handful of things in parallel and keeping that in my head. Working memory might be limited but working memory means something different than following 10 topics. Especially if there are a few tpics inbetween which just take time with the whole feedback loop.

But regarding your example of house cleaning: I have ADHD, i sometimes work like this. Working on something, waiting for a build and cleaning soming in parallel.

What you are missing is the practical experience with Agents. Taking the time and energy of setting up something for you, perhaps accessability too?

We only got access at work to claude code since end of last year.

I don't like to be mean, but I few weeks ago the guy bragged about Claude helping him do +50k loc and -48k loc(netting a 2k loc), I thought he was joking because I know plenty of programmers who do exactly that without AI, they just commit 10 huge json test files or re-format code.

I almost never open a PR without a thorough cleanup whereas some people seem to love opening huge PRs.

And at least two generate continuous shitposts for their companies Slack.

That said, having one write code and a clean context review it is helpful.

I guess it comes down to, how much do you trust the agent? If you don't trust it fully you want to inspect everything, which you still can, but you can choose to do it after it runs wild instead of every second it works.

Reminder: The guy works for Claude. Claude is over-hyping LLMs. That's like a Jeweler dealer assistant telling you how Gold chains helped his romantic life.

Yesterday, gemini told me to run this:

    echo 'export ANDROID_HOME=/opt/my-user/android-sdk' > ~/.bashrc

A few minutes later, asking it to create a .gitignore file for the current project - right after generating a private key, it failed to include the private key file to the .gitignore.

I don't see yet how these tools can be labeled as 'major productivity boosters' if you loose basic security and privacy with them...

If that's the goal, then we shouldn't interpret the current experiment as the destination.

I've been using CC for non-programming tasks and its been pretty successful so far, at least for personal projects (bordering on the edge of non-trivial). For instance, I'll get a 'designer' agent coming up with spec, and a 'design-critic' to challenge the design and make the original agent defend their choices. They can ask open questions after each round and I'll provide human feedback. After a few rounds of this, we whittle it down to a decent spec and try it out after handing it off to a coding agent.

Another example from work: I fired off some code analysis to an agent with the goal of creating integration tests, and then ran a set of spec reviewers in parallel to check its work before creating the actual tickets.

My point is there are a lot of steps involved in the whole product development process and isn't just "ship production code". And we can reduce the ambiguity/hallucinations/sycophancy by creating validation/checkpoints (either tests, 'critic' agents to challenge designs/spec, or human QA/validation when appropriate)

The end game of this approach is you have dozens or hundreds of agents running via some kind of orchestrator churning through a backlog that is combination human + AI generated, and the system posts questions to the human user(s) to gather feedback. The human spends most of the time doing high-level design/validation and answering open questions.

You definitely incur some cognitive debt and risk it doing something you don't want, but thats part of the fun for me (assuming it doesn't kill my AI bill).

In this case you have to take a leap of faith and assume that Claude or Codex will get each task done correctly enough that your house won't burn down.

In most of these kinds of posts, that's still you. I don't believe i've come across a pro-faster-keyboard post yet that claims AGI. Despite the name, LLMs have no agency, it's still all on you.

Once you've defined the next most important problem, you have a smaller problem - translate those requirements into code which accurately meets them. That's the bit where these models can successfully take over. I think of them as a faster keyboard and i've not seen a reason to change my mind yet despite using them heavily.

Recursion can give you an exponential reduction in error as you descend into the call stack. It's not guaranteed in the context of an LLM but there are ways to strongly encourage some contraction in error at each step. As long as you are, on average, working with a slightly smaller version of the problem each time you recurse, you still get exponential scaling.

Also, the feedback doesnt have to be immediate: sometimes I have sessions that run over a week, because of casual iterations; In my case its quite common to do this to test concepts, micro-benchmarking and library design.

This isn’t about being the most productive or having the best workflow, it’s about maximizing how much Claude is a part of your workflow.

But we do this routinely with machines. Not saying I don't get your point re 100 PRs a week, just that it's a strange metaphor given the similarities.

The cynic in me is it's a marketing pitch to sell "see this is way cheaper than 10 devs!". The "agent" thing leans heavily into bean counter CTO/CIO marketing.

Every PR Claude makes needs to be reviewed. Every single one. So great! You have 10 instances of Claude doing things. Great! You're still going to need to do 10 reviews.

(I'm only half joking. Having one LLM review the PRs of another is actually useful as a first line filter.)

The result is change sets that still need review - and fixes - but are vastly cleaner than if you review the first output.

Doing runs with other models entirely is also good - they will often identify different issues - but you can get far with sub-agents and different persona (and you can, if you like, have Claude Code use a sub agent to run codex to prompt it for a review, or vice versa - a number of the CLI tools seems to have "standardized" on "-p <prompt>" to ask a question on the command line)

Basically, reviewing output from Claude (or Codex, or any model) that hasn't been through multiple automated review passes by a model first is a waste of time - it's like reviewing the first draft from a slightly sloppy and overly self-confident developer who hasn't bothered checking if their own work even compiles first.

> Basically, reviewing output from Claude (or Codex, or any model) that hasn't been through multiple automated review passes by a model first is a waste of time - it's like reviewing the first draft from a slightly sloppy and overly self-confident developer who hasn't bothered checking if their own work even compiles first.

Well, that's what the CI is for. :)

In any case, it seems like a good idea to also feed the output of compiler errors and warnings and the linter back to your coding agent.

Sure, but I'd prefer to catch it before that, not least because it's a simpler feedback loop to ensure Claude fixes its own messes.

> In any case, it seems like a good idea to also feed the output of compiler errors and warnings and the linter back to your coding agent.

Claude seems to "love" to use linters and error messages if it's given the chance and/or the project structure hints at an ecosystem where certain tools are usually available. But just e.g. listing by name a set of commands it can use to check things in CLAUDE.md will often be enough to have it run it aggressively.

If not enough, you can use hooks to either force it, or sternly remind it after every file edit, or e.g. before it attempts to git commit.

- there are bigger contexts

- the test suite is much longer and slower

- you need to split worktree, resources (like db, ports) and sometimes containers to work in isolation

So having 10 workers will run for a long time. Which give plenty of time to write good spec.

You need good spec, so the llm produce good tests, so it can write good code to match these tests.

Having a very strong spec + test suite + quality gates (linter, type checkers, etc) is the only way to get good results from an LLM as the project become more complex.

Unlike a human, it's not very good at isolating complexity by itself, nor stopping and asking question in the face of ambiguity. So the guardrails are the only thing that keeps it on track.

And running a lot of guardrail takes time.

E.G: yesterday I had a big migration to do from HTMX to viewjs, I asked the LLM to produce screenshots of each state, and then do the migration in steps in a way that kept the screenshit 90% identical.

This way I knew it would not break the design.

But it's very long to run e2e tests + screenshot comparison every time you do a modification. Still faster than a human, but it gives plenty of time to talk to another llm.

Plus you can assign them very different task:

- One work on adding a new feature

- One improves the design

- One refactor part of the code (it's something you should do regularly, LLM produce tech debt quickly)

- One add more test to your test suite

- One is deploying on a new server

- One is analyzing the logs of your dev/test/prod server and tell you what's up

- One is cooking up a new logo for you and generating x versions at different resolutions.

Etc.

It's basically a small team at your disposal.

A shame really, for there are good resources for better making use of LLMs in coding.

You use agents to expand the requirements as well, either in plan mode (as OP does) or with a custom scaffold (rules in CLAUDE.md about how to handle requirements; personally I prefer giving Claude the latitude to start when Claude is ready rather than wait for my go-ahead)

> I don't understand how you can have any meaningful supervising role over 10 things at once given the limits of human working memory.

[this got long: TL;DR: This is what works for me: Stop worrying about individual steps; use sub-agents and slash-commands to encapsulate units of work to make Claude run longer; use permissions to allow as much as you dare (and/or run in a VM to allow Claude to run longer; give Claude tools to verify its work (linters, test suites, sub-agents double-checking the work against the spec) and make it use it; don't sit and wait and read invidiual parts of the conversation - it will only infuriate you to see Claude make stupid mistakes, but if well scaffolded it will fix them before it returns the code to you, so stop reading, breathe, and let it work; only verify when Claude has worked for a long time and checked its own work -- that way you review far less code and far more complete and coherent changes]

You don't. You wait until each agent is done, and you review the PR's. To make this kind of thing work well you need agents and slash-commands, like OP does - sub-agents in particular help prevent the top-level agents from "context anxiety": Claude Code appears to have knowledge of context use, and will be prone to stopping before context runs out; sub-agents use their own context and the top-level agent only uses context to manage the input to and output from them, so the more is farmed out to sub-agents, the longer Claude Code is willing to run. I when I got up this morning, Claude Code had run all night and produced about 110k words of output.

This also requires extensive permissions to use safe tools without asking (what OP does), or --dangerously-skip-permissions (I usually do this; you might want to put this in a container/VM as it will happily do things like "killall -9 python" or similar without "thinking through" consequences - I've had it kill the terminal it itself ran in before), or it'll stop far too quickly.

You'll also want to explicitly tell it to do things in parallel when possible. E.g. if you want to use it as a "smarter linter" (DO NOT rely on it as the only linter, use a regular one too, but using claude to apply more complex rules that requires some reasoning works great), you can ask it to "run the linter agent in parallel on all typescript files" for example, and it will tend to spawn multiple sub-agents running in parallel, and metaphorically twiddle its thumbs waiting for them to finish (it's fun seeing it get "bored" and decide to do other things in the meantime, or get impatient and check on progress obsessively).

You'll also want to make Claude use sub-agents to review, verify, test its work, with instructions to repeat until all the verification sub-agents give its changes a PASS (see 12/ and 13/ in the thread) - there is no reason for you to waste your time reviewing code that Claude itself can tell isn't ready.

[E.g. concrete example: "Vanilla" Claude "loves" using instance_variable_get() in Ruby if facing a class that is missing an accessor for an instance variable. Whether you know Ruby or not, that should stand out like a sore thumb - it's a horrifically gross code smell, as it's basically bypassing encapsulation entirely. But you shouldn't worry about that - if you write Ruby with Claude, you'd want a rule in CLAUDE.md telling it how to address missing accessors, and sub-agent, and possibly a hook, making sure that Claude is told to fix it immediately if it ever uses it.]

Farming it off to sub-agents both makes it willing to work longer, especially on "boring" tasks, and avoids the problem that it'll look at past work and decide it already "knows" this code is ready and start skipping steps.

The key thing is to stop obsessing over every step Claude takes, and treat that as a developer experimenting with something they're not clear on how to do yet. If you let it work, and its instructions are good, and it has ways of checking its work, it will figure out its first attempts are broken, fix them, and leave you with output that takes far less of your time to review.

When Claude tells you its done with a change, if you stop egregious problems, fix your CLAUDE.md, fix your planning steps, fix your agents.

None of the above will absolve you of reviewing code, and you will need to kick things back and have it fix them, and sometimes that will be tedious, but Claude is good enough that the problems you have it fix should be complex, not simple code smells or logic errors, and 9 out 10 times they should signal that your scaffold is lacking important detail about your project or that your spec is incomplete at a functional/acceptance criteria level (not low level detail)