5 ms·

Since I haven't mentioned the context in the article, it is a small agency with a customer target of early-stage (ideally earliest-stage) product startups. We

by flail 1y ago

Since I haven't mentioned the context in the article, it is a small agency with a customer target of early-stage (ideally earliest-stage) product startups. We have literally one half-hour-long sync meeting a week. The rest is as lightweight as possible, typically averaging below 10 minutes daily with clients (when all the decisions happen on the fly). I've worked in the corpo world, too, and it is anything but. We do use vibe coding a lot in prototyping. Depending on the context, we sometimes have a lot of AI-agent-generated code, too. What's more, because of working on multiple projects, we have a fairly decent pool of data points. And we don't see much of speed improvement from a perspective of a project (I wrote more on it here: https://brodzinski.com/2025/08/most-underestimated-factor-estimation.html https://brodzinski.com/2025/08/most-underestimated-factor-es...). However, developers sure report their perception of being more productive. We do discuss how much these perceptions are grounded in reality, though. See this: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o... and this: https://substack.com/home/post/p-172538377 https://substack.com/home/post/p-172538377 So, I don't think I'm biased toward bureaucratic environments, where developers code in MS Word rather than VS Code. But these are all just one dimension of the discussion. The other is a simple question: are there ways of validating ideas before we turn them into implemented features/products? The answer has always been a wholehearted "yes". If development pace were all that counted, Googles and Amazons of this world would be beating the crap out of every aspiring startup in any niche the big tech cared about, even remotely. And that simply is not happening. Incumbents are known to be losing ground, and old-school behemoths that still kick butts (such as IBM) do so because they continuously reinvent their businesses.

thenanyu 1y ago
The map is not the territory. Validating against anything other than the actual feature is a lossy proxy. It may be an acceptable tradeoff because building the feature is too costly but that’s the whole discussion at hand.
- flail 1y ago
  Sure. And yet, last time I checked, we've had plenty of applications for maps. I like this metaphor. Looking at a map, we may get a pretty good understanding of whether it's a place we'd like to spend time, say, on vacation. We don't physically go to a place to scrutinize it. And we don't limit ourselves to maps only. We check reviews, ask friends, and what have you. We do cheap validation before committing to a costly decision. If we planned vacations the way we build software products, we'd just go there (because the map is not the territory), learn that the place sucks, and then we'd complain that finding good vacation spots is costly and time-consuming. Oh, and we'd mention that traveling is a bottleneck in finding good spots.
  - thenanyu 1y ago
    The best way to know if you would like a new restaurant or experience is to actually try it. We rely on reviews and maps and directories because trying it is too costly. If trying it wasn't costly, we would just try it instead of relying on proxies.
    - flail 1y ago
      OK, let's assume you can get food for free (or close enough). Like if you were super rich, and the cost was absolutely marginal for you. How many dinners a day can you have? You would still rely on alternative proxies, like recommendations or reviews.
scarface_74 1y ago
BigTech is “beating startups”. 99% of all startups are just acquisition plays with no real business model. Check out all of the bullshit “AI” companies that YC is funding. BigTech is not “loosing ground” all of them are reporting increasing revenues and profits.
- flail 1y ago
  Of course, Big Techs have leverage of their bottomless coffers. What they can't develop, they buy. What was the last successful product idea coming from, say, Facebook? Or on a smaller scale, what's the last genuine Attlassian success? Yet, when it comes to product innovation, the momentum is always on the side of the new players. Always has been. Project management/work organization software? Linear. Async communication? Slack. Social Media? TikTok. One has to be curious how Zoom is doing so well, given that all the big competition actually controls the channels for setting up meetings. Self-publishing? Substack. Even with AI, everyone plays catch-up with Sam Altman, and many of the most prominent companies are newcomers. We could go on and on. Yes, Big Techs will survive because they have enough momentum to survive events such as the Balmer-era MS. But that doesn't mean they lead product innovation. And it's expected. Conflicting priorities, growing bureaucracies, shareholders' expectations, old business lines (and more), all make them less flexible.
  - scarface_74 1y ago
    Again let’s look at YC’s latest batch of companies. How many of them are doing anything “innovative”? An innovative product is one where customers in aggregate are willing to pay more for it than it costs to create and run. Any idiot can sell a bunch of dollar bills for 95 cents. Going back to the latest batch of YC companies, there value play can easily be duplicated by any company in their vertical either by throwing a few engineers on it or creating a statement of work for the consulting company I work for and I can pull together a few engineers and knock it out in a few months and they will already have customers to sell it to. There was one recent YC company (of course one of the BS AI companies) that was a hiring a “founding full stack engineer” for $150K. It looks like they were two non technical “serial entrepreneurs” without even an MVP that YC threw money at. You can’t imagine how many times some hair brain underfunded startup reached out to me to be a “CTO” that paid less than I made as a mid level employee at BigTech with the promise of Monopoly money “equity”.
com2kid 1y ago
I needed to make a landing page for an ad campaign to test out an idea for PMF. Claude crapped out a workable landing page in ~30 seconds of prompting. I updated the copy on the page, total time less than an hour. The odds of me spending more than an hour just picking a color theme for the page or finding the SVG icons it used is pretty much 100%. ------------ I had a bug in some async code, it hit rarely but often enough it was noticeable. I had narrowed down what file it was in, but after over an hour of staring at the code I wasn't finding it. Popped into cursor, asked it to look for async bugs in the current file. "You forgot to clean up a resource on this line here." Bug fixed. ------------ "Here is my nginx config, what is wrong with the block I just added for this new site I'm throwing up?" ------------ "Write a regex to do nnnnnn" ------------ "This page isn't working on mobile, something is wrong, can you investigate and tell me what the issues may be?" Oh that won't go well, all of the models get super confused about CSS at some point and end up in doom spirals applying incorrect fixes again and again. > Googles and Amazons of this world would be beating the crap out of every aspiring startup in any niche the big tech cared about, even remotely. And that simply is not happening. This is already a well explored and understood space, to the extent that big tech cos have at times spun teams off to work independently to gain the advantage of startup-like velocities. The more infra you have, the more overhead you have. Deploying a company's first service to production is really easy, no infra needed, no dev-ops, just publish. Deploying the 5th service, eh. Deploying the 50th service, well by now you need to have a host of meetings before work even starts to make sure you aren't duplicating effort and that the libraries you use mesh with the department's strategic technical vision. By the time those meeting are done, a startup will have already put 3 things into prod. The communication overhead within large orgs is also famously non-linear. I spent 10 years working at Microsoft, then 3 years at HBO Max (lean tech company 200 engineers, amazing dev ops), and now I'm working at startups of various sizes. At Microsoft, pre-Azure it could take weeks just to get a machine provisioned to test an idea out on. Actually getting a project up and running in a repo was... hard at times. Build systems were complex, tooling was complex, and you sure as hell weren't getting anything pushed to users without a lot of checks in place. Now many of those checks were in place for damn good reasons, wrongly drawn lines on a map inside Windows is a literal international incident[1], and we had separate localizations for different variants of English around the world. (And I'd argue that Microsoft's agility at deploying software around the entire world at the same time is unmatched, the people I worked with there were amazing at sorting through the cultural and legal problems!) Also if Google launches a new service and it goes down from too much traffic, it is embarrassing. Everything they do has to be scalable and load balanced, just to avoid bad press. If a startup hits the front page of HN and their website goes down from being too popular, they get to write a follow up blog post about how their announcement was so damn popular their site crashed! (And if they are lucky, hit the front page of HN again!) The differences in designing for levels of scale is huge. At Microsoft it was "expect potentially a billion users" At HBO it was "Expect tens of millions of users", at many startups it is "If we hit 10k users we'll turn a profit and we can figure out how to scale out later." 10K DAU is a load balances and 3 instances of NodeJS (for rolling updates) each running on a potato of a CPU. > So, I don't think I'm biased toward bureaucratic environments, where developers code in MS Word rather than VS Code. I've worked in those environments, and the level of engineering quality can be much higher. The number of bugs that can be hammered out and avoided in spec reviews is huge. Technology designs that end up being servicable for years to decades instead of "until the next rewrite". The actual code tends to flow much faster as well, or at least as fast as it can flow in the large sprawling code bases that exist at big tech companies. At other times, those specs are needed so that one has a path forward while working through messy legacy code bases. Both styles have their place - Sometimes you need to iterate quickly and get lots of code down and see what works, other times it is worth thinking through edge cases, usage scenarios, and performance characteristics. Heck I've done memory bus calculations for different designs, when you are working at that level you don't just "write code and see what works", you first spend a few days (or a week!) with some other smart engineers and try to narrow down the potential field of you should even be trying to do! [1]https://www.upi.com/Archives/1995/09/09/Microsoft-settles-India-controversy/6965810619200/ https://www.upi.com/Archives/1995/09/09/Microsoft-settles-In...

by flail 1y ago

thenanyu 1y ago

The map is not the territory. Validating against anything other than the actual feature is a lossy proxy. It may be an acceptable tradeoff because building the feature is too costly but that’s the whole discussion at hand.

flail 1y ago
Sure. And yet, last time I checked, we've had plenty of applications for maps. I like this metaphor. Looking at a map, we may get a pretty good understanding of whether it's a place we'd like to spend time, say, on vacation. We don't physically go to a place to scrutinize it. And we don't limit ourselves to maps only. We check reviews, ask friends, and what have you. We do cheap validation before committing to a costly decision. If we planned vacations the way we build software products, we'd just go there (because the map is not the territory), learn that the place sucks, and then we'd complain that finding good vacation spots is costly and time-consuming. Oh, and we'd mention that traveling is a bottleneck in finding good spots.
- thenanyu 1y ago
  The best way to know if you would like a new restaurant or experience is to actually try it. We rely on reviews and maps and directories because trying it is too costly. If trying it wasn't costly, we would just try it instead of relying on proxies.
  - flail 1y ago
    OK, let's assume you can get food for free (or close enough). Like if you were super rich, and the cost was absolutely marginal for you. How many dinners a day can you have? You would still rely on alternative proxies, like recommendations or reviews.

scarface_74 1y ago

BigTech is “beating startups”. 99% of all startups are just acquisition plays with no real business model. Check out all of the bullshit “AI” companies that YC is funding. BigTech is not “loosing ground” all of them are reporting increasing revenues and profits.

flail 1y ago
Of course, Big Techs have leverage of their bottomless coffers. What they can't develop, they buy. What was the last successful product idea coming from, say, Facebook? Or on a smaller scale, what's the last genuine Attlassian success? Yet, when it comes to product innovation, the momentum is always on the side of the new players. Always has been. Project management/work organization software? Linear. Async communication? Slack. Social Media? TikTok. One has to be curious how Zoom is doing so well, given that all the big competition actually controls the channels for setting up meetings. Self-publishing? Substack. Even with AI, everyone plays catch-up with Sam Altman, and many of the most prominent companies are newcomers. We could go on and on. Yes, Big Techs will survive because they have enough momentum to survive events such as the Balmer-era MS. But that doesn't mean they lead product innovation. And it's expected. Conflicting priorities, growing bureaucracies, shareholders' expectations, old business lines (and more), all make them less flexible.
- scarface_74 1y ago
  Again let’s look at YC’s latest batch of companies. How many of them are doing anything “innovative”? An innovative product is one where customers in aggregate are willing to pay more for it than it costs to create and run. Any idiot can sell a bunch of dollar bills for 95 cents. Going back to the latest batch of YC companies, there value play can easily be duplicated by any company in their vertical either by throwing a few engineers on it or creating a statement of work for the consulting company I work for and I can pull together a few engineers and knock it out in a few months and they will already have customers to sell it to. There was one recent YC company (of course one of the BS AI companies) that was a hiring a “founding full stack engineer” for $150K. It looks like they were two non technical “serial entrepreneurs” without even an MVP that YC threw money at. You can’t imagine how many times some hair brain underfunded startup reached out to me to be a “CTO” that paid less than I made as a mid level employee at BigTech with the promise of Monopoly money “equity”.

com2kid 1y ago

I needed to make a landing page for an ad campaign to test out an idea for PMF. Claude crapped out a workable landing page in ~30 seconds of prompting. I updated the copy on the page, total time less than an hour. The odds of me spending more than an hour just picking a color theme for the page or finding the SVG icons it used is pretty much 100%. ------------ I had a bug in some async code, it hit rarely but often enough it was noticeable. I had narrowed down what file it was in, but after over an hour of staring at the code I wasn't finding it. Popped into cursor, asked it to look for async bugs in the current file. "You forgot to clean up a resource on this line here." Bug fixed. ------------ "Here is my nginx config, what is wrong with the block I just added for this new site I'm throwing up?" ------------ "Write a regex to do nnnnnn" ------------ "This page isn't working on mobile, something is wrong, can you investigate and tell me what the issues may be?" Oh that won't go well, all of the models get super confused about CSS at some point and end up in doom spirals applying incorrect fixes again and again. > Googles and Amazons of this world would be beating the crap out of every aspiring startup in any niche the big tech cared about, even remotely. And that simply is not happening. This is already a well explored and understood space, to the extent that big tech cos have at times spun teams off to work independently to gain the advantage of startup-like velocities. The more infra you have, the more overhead you have. Deploying a company's first service to production is really easy, no infra needed, no dev-ops, just publish. Deploying the 5th service, eh. Deploying the 50th service, well by now you need to have a host of meetings before work even starts to make sure you aren't duplicating effort and that the libraries you use mesh with the department's strategic technical vision. By the time those meeting are done, a startup will have already put 3 things into prod. The communication overhead within large orgs is also famously non-linear. I spent 10 years working at Microsoft, then 3 years at HBO Max (lean tech company 200 engineers, amazing dev ops), and now I'm working at startups of various sizes. At Microsoft, pre-Azure it could take weeks just to get a machine provisioned to test an idea out on. Actually getting a project up and running in a repo was... hard at times. Build systems were complex, tooling was complex, and you sure as hell weren't getting anything pushed to users without a lot of checks in place. Now many of those checks were in place for damn good reasons, wrongly drawn lines on a map inside Windows is a literal international incident[1], and we had separate localizations for different variants of English around the world. (And I'd argue that Microsoft's agility at deploying software around the entire world at the same time is unmatched, the people I worked with there were amazing at sorting through the cultural and legal problems!) Also if Google launches a new service and it goes down from too much traffic, it is embarrassing. Everything they do has to be scalable and load balanced, just to avoid bad press. If a startup hits the front page of HN and their website goes down from being too popular, they get to write a follow up blog post about how their announcement was so damn popular their site crashed! (And if they are lucky, hit the front page of HN again!) The differences in designing for levels of scale is huge. At Microsoft it was "expect potentially a billion users" At HBO it was "Expect tens of millions of users", at many startups it is "If we hit 10k users we'll turn a profit and we can figure out how to scale out later." 10K DAU is a load balances and 3 instances of NodeJS (for rolling updates) each running on a potato of a CPU. > So, I don't think I'm biased toward bureaucratic environments, where developers code in MS Word rather than VS Code. I've worked in those environments, and the level of engineering quality can be much higher. The number of bugs that can be hammered out and avoided in spec reviews is huge. Technology designs that end up being servicable for years to decades instead of "until the next rewrite". The actual code tends to flow much faster as well, or at least as fast as it can flow in the large sprawling code bases that exist at big tech companies. At other times, those specs are needed so that one has a path forward while working through messy legacy code bases. Both styles have their place - Sometimes you need to iterate quickly and get lots of code down and see what works, other times it is worth thinking through edge cases, usage scenarios, and performance characteristics. Heck I've done memory bus calculations for different designs, when you are working at that level you don't just "write code and see what works", you first spend a few days (or a week!) with some other smart engineers and try to narrow down the potential field of you should even be trying to do! [1]https://www.upi.com/Archives/1995/09/09/Microsoft-settles-India-controversy/6965810619200/ https://www.upi.com/Archives/1995/09/09/Microsoft-settles-In...