Not my experience at all. One slow part was coding. AI takes care of that. But more importantly, the slow part was iterating through concepts, ideas, and prototypes. I thought people on this site embraced lean startups and agile development. AI really helps make that feedback loop 10X faster. I can do an experiment, show it to coworkers and get feedback in a morning, for something that would have taken me almost a week in the past. So now we can try a lot more options, whereas before, we kept getting hit by the sunk cost fallacy: I spent a week on this, I really don't want to start again from scratch with this other approach that may or may not be better.
The lean startup "feedback loop" was with customers (not coworkers). The idea was that you iterate on your viable product (not vibe prototype) with the market that derives value from it.
The slow part is finding those customers, syncing your deliveries with their processes, giving them time to meaningfully assess new workflows and features in the course of their business operations, collating the feedback you receive from all of them, and merging that feedback with your organization's long term growth objectives to drive new ideas into development. Well-developed organizations layer this inescapably slow flow across numerous parallel channels so engineering utilization can stay high since healthy engineering already cycled much faster than these market-engaged flows can.
Neither coding nor internal prototypes were the slow part. Market engagement and market-informed product planning were the slow part. And still are.
You may not realize it yet, and maybe you've just misrepresented it, but most of what you seem to be describing is usually considered wheel-spinning and navel-gazing. You may have made your internal process cycle faster, but you very likely just turned a wasteful busywork churn into a more efficiently wasteful busywork churn.
Neither coding nor internal prototypes were the slow part
That is not my experience mentoring 100+ startup founders. Building a prototype, the gateway to serious customer engagement, used to take months and many startups would die before finishing their first one.
Aren't those startups the ones wanting a google style infrastructure based on kubernetes with database sharding, an event-source architecture,... And when you told them a few VPS with postgres would have sufficed, they absolutely insisted that unless it's a next.js app backed by a serveless ecosystem and tens SaaS, they couldn't build their products?
Fair enough, experiences do differ. But how are you evaluating those POCs? Just based on 'visually what looks better', or architecturally etc?
In my experience, the slow parts are around making sure you're aligning on a long-term vision, understanding the domain and customer problem well enough, balancing the technical aspects/speed today with quality down the line, etc.
This probably does depend on what kind of tech problems you work on. If you're purely doing frontend development I'm sure you'll be faster. If you work on complexer systems with e.g robotics/hardware interaction, I can't see it being significantly faster. YMMV :)
There are multiple points of iteration. for me, it's user interface and core algorithms. Because the cost of creating an iteration was so high before, I would think about the problem for a long time and then implement the one that seems best maybe kind of?? I was always wondering that maybe I could have found a better solution. Now with AI, I can iterate through two or three solutions that I'm trying to decide between and see which one works best in a much shorter time frame.
You're not gaining any knowledge, insight, or experience from all of your iteration. You're churning for the sake of churn and pretending you're benefiting from it.
> I can do an experiment, show it to coworkers and get feedback in a morning, for something that would have taken me almost a week in the past.
That argument always rings hollow to me. What systems were you prototyping that took that long? I don't need to build a complete MVP to present a design. Or understand an API.
In the visual art industry, there are thumbnails and storyboards that are the first iteration of any project. They are quick to produce, and can serve as the basis for brainstorming. No one wants a finished picture, because it restrain your thinking. Too much details and you start bike-shedding.
Only when you've solved higher concerns and have a concrete direction that you start to invest physical efforts. But that does require someone to have the capacity to discern higher concerns from crude sketches. If you don't and rely on "I'll know it when I see it", then you sure need finished products to clarify your thinking.
Iterating and prototyping can certainly help there, but at the end of the day if you launch a non-working (or non-reliable) prototype, you’re going to just have angry customers, not happy ones.
And that rarely works out well long (or even medium) term.
And most of the value from iterating and prototyping is from learning, something the AI kinda screws with.
There is a way to make the campfire approach a little bit less utopian: California could pass a law that makes it legal to have a second temporary job. So that FAANG engineers for instance, would be allowed to campfire/interview at another company with legal protections. Put a bit of grease in the interview system is good for candidates.
the labour cost of having an intern/entry level engineer spend ~30-60s looking through these is likely close to $0.20
Did you do the math? Your estimate feels way off. First, I doubt an intern would process one PR in 30s. Maybe 2-3 minutes, to read 10 lines carefully looking for typos and indentation mistakes. We pay interns close to $100K these days (in a company like CloudFlare), so that's ~80c/minute. My estimate is therefore closer to $1.6 per PR. About 10X.
You are correct that there is a residual value with the intern, over time they would start learning (a little bit) about the code base.
$100k is probably at the top end. Even at Cloudflare, interns are more likely to be making $25-40/hour according to levels.fyi, which works out to $52-83k.
We all have had the client from hell: they don't know what they want, they change their requirements all the time. Whenever they have a new half-baked idea, I need to scramble and re-design the architecture. They have no clue that a small change request has a big impact on the code.
Well... Now I can be that client. And let AI deal with my incomplete, always changing requirements. And get it done anyway.
That matches my experience. At least on the solo front, there were so many topics I wasn't an expert on, that limited what I could build. Now with AI assistance, the sky is the limit. I don't need to be an expert in frontend, backend, I can just build on my personal expertise in a functional domain, and leverage AI to fill in the gaps. I believe many people will benefit from being to build exactly what they want, without gatekeepers or investment.
This paragraph from September 2025 didn't age well:
Like you, we have seen numerous reports that more and more firms are capping their total headcount in favor of leaning on more AI tools, leading to downsizing their intern and new-graduate hiring. [...] But we think this misreads the moment completely, so we’re heading in the opposite direction.
Correct (well, maybe not half a century, maybe 30 years or so). I was just about to reply that I'd love a version of this that shows instructions going in and out of a re-order buffer. That would be enlightening.
Well, how about the Berkeley Out-of-Order Machine [0] (BOOM)? It's superscalar, out-of-order RISC-V design (one of the very first ones, in fact), and the documentation is fairly detailed. Read [0] and [1] for the general introduction, and then move down to the "Core Overview" section in the left navbar: "Instruction Fetch", "Branch Prediction", etc.
Also, here [2] is another, much more detailed explanation of an O-o-O implementation of a very simplistic RISC ISA which nonetheless has most of the relevant RISC-V features. There are also some other related texts on this subsite [3], including a single-cycle and a pipelined implementations, for the comparison.
You're not wrong, but blocking assignments (and their equivalent in VHDL, variables), are useful as local variables to a process/always block. For instance to factor common sub-expressions and not repeat them. So using only non-blocking assignments everywhere would lead to more ugly code.
Good question. For a long time I think the justification was location: Microsoft is in Seattle, and it’s only the Bay Area that is getting inflated salaries.
It's not misleading for people in the industry. ARM so far was selling IP (Verilog source code) that other chip makers would include in a full chip design.
Now ARM for the first time (this century) is making its own chip [design], which like most of its customers, is manufactured by a fab like TSMC.
Similarly Apple doesn't manufacture any of its own computers or iPhones (it's all contract manufacturers like FoxConn) but it would clearly be wrong to say "Apple doesn't make computers! Foxconn does!"
reply