Isn't this the entrepreneur-or-freelancer divide? Is the thing you're working on making you money while you sleep (entrepreneur, "startup" is appropriate) or do you only get paid when you work (freelancer, "self-employed" is appropriate).
Not saying this distinction is useful, but at least it's a common way of talking about the various forms of "being your own boss".
In my head, a startup is something that can scale, and possibly needs scale. So me selling woodworking will always be limited by how much I can produce, thats still a businesses but not a startup. Selling a SaaS product however makes little money in the start, but can scale sales virtually infinitely.
I think people have their own axis they divide this on. So none of us are correct. For some it's also a vanity thing, where entrepreneur or startup sounds better.
What? Don't get so defensive just because I stated my opinion. Nothing here was an attack at you. And it's not a projection, words have different connotations no matter what you believe. Some think self-employed sounds cool, other think it's not. Some think entrepreneur gives some vibe, some think it gives another.
What a charming new career path! And you make an interesting point about signaling attention to detail giving a guarantee of sorts that the things that matter are covered as a matter of course.
Reminds me of a friend who would go straight to the restrooms for a quick visual inspection upon entering a restaurant: if those aren't clean, there's no reason to think the kitchen is.
Yes, I think so too. Just like there is a demand for handmade objects like vases, cooking knives and beverages, which was the norm before the industrial revolution and has now become a thing of intrinsic value, provides they are of higher quality than their factory-made counterparts (I have a background in the spirits industry, where "small batch" and "handmade" have often been used to justify premium prices despite clearly lower quality. I've become a little more discerning since when I see those labels anywhere and don't take quality for granted).
Your article matches my own intuition, and there's a case to be made for adjusting our architectural patterns to better compartmentalize those parts of the app we can let an agent go nuts on. For example, could we leave all of the UI to the agent? Or things like the MCP Server implementation of the app? I'm not quite sure where to draw the line yet. I'm quite comfortable leaving unit tests to the agent by now, but if it's user visible behavior, I still find the agent's work to be off somehow. Ymmv, I guess.
Yeah, I guess it is quite hard to tell where the line should be drawn, and we probably need to rely on human intuition and experience. One thing that the article left out that I have thought more of afterwards is that the classification would need to be relative to the enterprise as a whole. So if you are building a gimmick app for a birthday party you might just vibe code the whole thing, including its "core", but if you are a building business-critical sales system for a major company, the impact of something going wrong would rate the core at the upper end of the scale.
I guess we'll only be able to verify this 10-15 years after coding agents arrived. Personally, I think there will always be a market for apps created with care and great attention to detail.
There is a large market for fine art. For everything else, there are printers and copiers. It's very difficult to maintain a career of painting and selling works for $100k. It's much easier to maintain a different career that happens to include printing things with little effort using an ordinary office printer.
That's where software development is going: of course you can still code by hand, but it will be increasingly difficult to get paid to do it. People will have a somewhat different career that happens to include coding things with little effort using an ordinary coding agent. Companies won't be able to afford to pay for expensive coders anymore (because otherwise their competition, who is getting along fine with a small software development budget, will take all their customers.)
> they are very strongly tuned to value code that has no errors which can be picked up by linters or similar, while humans work the opposite way
This is a really valuable insight! It resonates well with my own experience revewing AI-authored code: I look hard at interfaces, architecture and performance, and merely glance over code that just "gets the job done", because if it works, I'm not worried about it. Now I can express that dichotomy much more clearly -- thank you!
That is my experience as well. I get a (subjective) speedup between 1 and 3 for parts of the code I'd consider critical and where I check the output tightly, and 5-20 for menial work OR for important code that's well isolated into its own module such that its quality doesn't matter because I can have it rewritten easily if it doesn't work as expected.
A bit off-topic, but it is interesting that you say this.
Just earlier today I listened to Startups for the Rest of Us podcast episode 842 [1] titled "The future of SaaS in an AI World", where host Rob Walling addresses the "SaaS is dead" question. One of his arguments is that it's rarely worth spending time on rebuilding your SaaS vendors' solutions, taking time away from your core mission. But I guess that:
1. the projects you hinted at are low-value services (e.g. CRUD web apps over DBs), and not SaaS services which have real moats, like CRM (connectors ecosystem) or email service providers (IP reputation, IT security).
2. His argument applies to startups, where you're trying to grow your valuation by growing revenue (valuation = 5-10x yearly revenue) as opposed to established corporations which usually have a higher incentive to limit costs.
You seem like a very smart person, so I'd be curious to hear your thoughts here. Were these low-value SaaS services, and is this in the context of an established business?
Not saying this distinction is useful, but at least it's a common way of talking about the various forms of "being your own boss".