flail

You mention one fabulous application of AI-supported coding that the article didn't touch upon. It's anything where the target customer group is me. All sorts of automation, pet projects, and serious stuff that improves research, too.

The context of the article is product development, with a bias toward the commercial part of the ecosystem. And of course, as any picture painted with broad strokes, some generalizations were inevitable.

As a scientist, you definitely are familiar with the weight (or lack thereof) of anecdotal evidence. Unless the claim is "it can never work" or "it always works," my individual experience is just that--an individual experience.

My experience correlates with this assessment. The closer we are toward prototyping, the bigger leverage we gain from quickly generated swaths of code. It's simply because we don't need to care about all the quality guardrails. After all, it's a prototype.

With a more complex code base (and a less popular tech stack), the perceived gains quickly diminish. Beyond a certain level of tech debt, AI-generated code is utterly useless. It's no surprise that we see people who vibe-coded their products with no technical knowledge whatsoever, and now they call professional engineers to untangle the mess.

A software agency I know well responded to the rise of AI somewhere between the lines of "Now, we'll have plenty of work to clean all that mess!" Admittedly, they always specialized in complex/rescue engineering gigs.

However, the "development as a bottleneck" discussion was set here in a broader context. It's not only how efficiently we are able to deliver bits of functionality, but primarily whether we should be building these things in the first place.

Equally for early-stage startups and established products alike, so much of features are built because someone said so. At the end of the day, they don't deliver any value (if we're lucky) or are plain harmful (if we're out of luck).

In such cases, it would have been better if developers actually sipped coffee and read Hacker News rather than coded/developed/engineered stuff.

In no part was that suggestion addressed to software design/architecture.

It is telling that, while the article's theme is product management (and its relationship with the pace of development), that context is largely ignored in some comments. It's as if the article's scope was purely what happens within the IDE and/or AI agent of choice.

The whole point is that the perspective necessarily should be broader. Otherwise, we make it a circular argument, really: development is a bottleneck of development.

Well, hard to disagree on that.

I would actually challenge you to read/reread Lean Startup with the following filter:

Disregard parts that explicitly assume that they are relevant only because, in 2013, development was expensive. There are very few parts that you would throw out.

I heard that before. No, Lean Startup is not about working around the cost of software development.

It is about designing good experiments, validating, and learning, so that when we're down to development, we build something that's way more likely to succeed.

The fact that we were advised to build non-technical experiments is but a small part. And with the current AI capabilities, we actually have a new power tool for prototyping that falls neatly into the whole puzzle.

Here's a bit more elaborate argument (sorry for a LinkedIn link): https://www.linkedin.com/posts/pawelbrodzinski_weve-already-...

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.

Oh, development sure does mean the whole package. Architectural design, automated tests, coding, refactoring, code review and post-review changes, deployment, manual tests, etc.

A question: what if all those activities are to build a feature that will harm user retention or a product no one wants?

A follow-up question: what if we could have known that up front, or there was a simple way to learn that?

Because so often we build stuff that shouldn't have been built in the first place (appalling startup success rate is probably a good enough statistical measure of that). And yes, there are ways to learn that we're building the wrong thing, other than building a fully-fledged version of it.

That's just another great vantage point to consider when looking at product development.

Accompanying many early-stage startups in their journey, I see how often the development (which we're responsible for) takes a back seat. Sometimes the pivotal role will be customer support, sometimes it will be business development, and often product management will drive the whole thing.

And there's one more follow-up thought to this observation. Products that achieved success, inevitably, get into a spiral of getting more features. That, in turn, makes them more clunky and less usable, and ultimately opens a way for new players who disrupt the niche.

At some point, adding more features in general makes things worse--too complicated, too overwhelming, making it harder to accomplish the core task. And yet, adding new stuff never ceases.

In the long run, the best tactic may actually be to go slower (and stop at some point), but focus on the meaningful changes.

Oh, I agree that in many companies, internally, we create perceptions that development is, indeed, THE bottleneck.

VP of Product put all the pressure on dev teams to deliver all the features against the specs. Then they release the new product/new version with plenty of fanfare.

And then literally no one measures which parts have actually delivered any value. I'd bet a big part of that code added no value, so it's a pure waste. Some other parts were actually harmful. They frustrated users, drove key metrics down, or have you. They are worse than waste.

But no one cared to check. Good product people, and there are scarcely few of them, would follow up with validation on what worked and what did not. They would argue against "major" releases whenever possible.

And seriously, if Amazon can avoid major releases, almost anyone could.

Suddenly, we might flip the script and have a VP of Product not asking "when will it be done?" but rather trying to figure out what the next most sensible experiments are.

We have this saying: Our clients always know what they want. Until they get it. Then they know they wanted something different.

And don't take that as a complaint. It's a basic behavioral observation. What we say we do is different from what we really do. By the same token, what we say we want is different from what we really want.

At a risk of being a bit sarcastic: we say we want regular exercise to keep fit, but we really want doomscrolling on a sofa with a beer in hand.

In the product development context, we have a very different attitude towards an imagined (hell, even wireframed) solution than an actual working piece of software. So it's kinda obvious we can't get it right on the first attempt.

We can be working toward the right direction, and many product teams don't even do that. For them, development speed is only a clock counting time remaining before VCs pull the plug.

Whenever a development effort involves a lot of AI-generated code, the nature of the task shifts from typing-heavy to code-review-heavy.

Cognitively, these are very different tasks. With the former, we actively drive technical decisions (decide on architecture, implementation details, even naming). The latter offers all these decisions made, and we first need to untangle them all before we can scrutinize the details.

What's more, often AI-generated code results in bigger PRs, which again adds to the cognitive load.

And some developers fall into a rabbit hole of starting another thing while they wait for their agent to produce the code. Adding context switching to an already taxing challenge basically fries brains. There's no way such a code review to consistently catch the issues.

I see how development teams define health routines around working with generated code. Especially around limiting context switching. But also retaking tasks to be made by hand.

If only "trying things" always equaled "developing things". There's a whole body of knowledge (under the Lean Startup umbrella) that argues otherwise.

Do we always have to build it before we know that it will work (or, in 9 cases out of 10, that it will not work)?

Even more so, do we have to build a fully-fledged version of it to know?

If yes, then I agree, development is the bottleneck.

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-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-o... and this: 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.

I wouldn't discuss with that part, although there are definitely limits to how big a chunk of a big product a single brain can really grasp technically. And when the number of people involved in "grasping" grows, so does the coordination/communication tax. I digress, though.

We could go with that perception, however, only if we assume that whatever is in the backlog is actually the right thing to build. If we knew that every feature has value to the customers and (even better) they are sorted from the most valuable to the least valuable one.

In reality, many features have negative value, i.e., they hurt performance, customer satisfaction, any key metric a company employs.

The big question: can we check some of these before we actually develop a fully-fledged feature? The answer, very often, is positive. And if we follow up with an inquiry about how to validate such ideas without development, we will find a way more often than not.

Teresa Torres' Continuous Discovery Habits is an entire book about that :)

One of her recurring patterns is the Opportunity Solution Tree, which is a way of navigating across all the possible experiments to focus on the right ones (and ignore, i.e., not develop, all the rest).

I would agree if the only way to achieve (digital product) success were to implement as many versions of software as possible. That's not true.

The whole Lean Startup was about figuring out how to validate ideas without actually developing them. And it is as relevant as ever, even with AI (maybe, especially with AI).

In fact, it's enough to look at the appalling rate of product success. We commonly agree that 90% of startups fail. The majority of that cohort have built things that shouldn't have been built at all in the first place. That's utter waste.

If only, instead of focusing on building more, they stopped and reevaluated whether they were building the right thing in the first place. Yet, most startups are completely immersed in the "development as a bottleneck" principle. And I tell that part from our own experience of 20+ years of helping such companies to build their early-stage products. The biggest challenge? Convince them to build less, validate, learn, and only then go back to further development.

When it comes to existing products, it gets even more complex. The quote from Leah Tharin explicitly mentions waiting weeks/months of wait till they were able to get statistically significant data. What follows is that within that part of experimentation, they were blocked.

Another angle to take a look at it is the fundamental difference in innovation between Edison/Dyson and Tesla.

The first duo was known for "I have not failed. I found 10,000 ways that don't work." They were flailing around with ideas till something eventually clicked.

Tesla, in contrast, would be at the Einstein's end of the spectrum with "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about [or in Tesla's case, making] solutions."

While most of the product companies would be somewhere in between, I'd argue that development is a bottleneck only if we are very close to Edison/Dyson's approach.

Stories about CTOs heavily overrelying on their long-outdated coding experience are plenty. If that's an ego thing ("I can still do that and show them that I can"), they're going to do that with little care about the consequences.

At that level, it's the combination of all the power and not that much tech expertise anymore. A vulnerable place.

A lot of famous hacks targeted humans as a primary weak point (gullibility, incompetence, naivety, greed, curiosity, take your pick), and technology only as a secondary follow-up.

An example: Someone had to pick up that "dropped" pendrive in a cantina and plug it into their computer in a 100% isolated site to enable Stuxnet.

Were I a black hat hacker, targeting CTOs' egos would be high on my priority list.

1. Organizations that care about controlling their data. Pretty much the same ones that were reluctant to embrace the cloud and kept their own server rooms.

An additional flavor to that: even if my professional AI agent license guarantees that my data won't be used to train generic models, etc., when a US court would make OpenAI reveal your data, they will, no matter where it is physically stored. That's kinda a loophole in law-making, as e.g., the EU increasingly requires data to be stored locally.

However, if one really wants control over the data, they might prefer to run everything in a local setup. Which is going to be way more complicated and expensive.

2. Small Language Models (SLMs). LLMs are generic. That's their whole point. No LLM-based solution needs all LLM's capabilities. And yet training and using the model, because of its sheer size, is expensive.

In the long run, it may be more viable to deploy and train one's own, much smaller model operating only on very specific training data. The tradeoff here is that you get a cheaper in use and more specialized tool, at the cost of up-front development and no easy way of upgrading a model when a new wave of LLMs is deployed.

Save for Gary Marcus' ego, which you're right about, most of the article is written by Nathan Hamiel from Kudelski Security. The voice of the post sounds weird because Nathan is referred to in a third person, but from the content, it's pretty clear that much of that is not Gary Marcus.

Also, slides from the Nvidia talk, which they refer to a lot, are linked. The Nathan's presentation links only to the conference website.

One thing relying on coding agents does is it changes the nature of the work from typing-heavy (unless you count prompting) to code-review-heavy.

Cognitively, these are fairly distinct tasks. When creating code, we imagine architecture, tech solutions, specific ways of implementing, etc., pre-task. When reviewing code, we're given all these.

Sure, some of that thinking would go into prompting, but not to such a detail as when coding.

What follows is that it's easier to make a vulnerability pass through. More so, given that we're potentially exposed to more of them. After all, no one coding manually would consciously add vulnerability to their code base. Ultimately, all such cases are by omission.

A compromised coding agent would try that. So, we have to change the lenses from "vulnerability by omission only" to "all sorts of malicious active changes" too.

An entirely separate discussion is who reviews the code and what security knowledge they have. It's easy to dismiss the concern once a developer has been dealing with security for years. But these are not the only developers who use coding agents.

I generally trust the due dates printed on the items. But what would I know? Maybe it's a conspiracy to force us to drink old milk ;)

On a more serious note, UHT milk can be stored for months, given it wasn't opened.

We don't need to "offer" that. Anyone can do this. Literally, anyone can make any decision (in a structured manner), so joining a core business initiative is obviously on the list.

Also, she already does participate in core activities. It would be much easier for us to deal with losing a couple of our best engineers than losing Kasia. Which is also a response to some voices in the discussion downplaying the value of the "office manager's" job. I partially blame common perceptions of this job being "just a secretary to everyone," which could be farther from what we have.

It wasn't just coming up with a system that works for software and taking a cool name from manufacturing processes.

The methods in IT were built on the same principles (and, to a degree, values). It's just the implementation is different. In fact, in software, we emulate some things that are given in manufacturing. A notable example is making work visible. On a factory floor, piles of parts are clearly visible. The code in progress is not. Thus, we have index cards representing queues of work (piles of incomplete parts).

The approach to limiting work in progress is actually the same. Again, the solutions differ (replenishment triggered by visual cards in manufacturing versus numerical WIP limits on visual boards in software), but the outcome remains very similar.

There are differences, of course. The big one is how we react to variability. While in manufacturing, we, well, manufacture a lot of identical things, in software, each item is different. Thus, on a factory floor, we aim to control and reduce variability, while in software, we tend to accept and work around it.

There are other differences in flavor, too. Like in knowledge work we don't stress too much about waste reduction, while in manufacturing, it's a big theme, etc.

However, if we look at the ideas and not specific implementations, these systems are very similar. And I'm saying it as someone who trained people in that domain both in knowledge work and manufacturing.

Not that any of this helps with confusion in the naming. Even less so given the fact that some people are arguing the seemingly fundamental differences between using kanban (lowercase k) and Kanban (capital K). I guess people are people.I don't much care. As long as someone can explain what they mean by it, I'm fine with whatever naming they come up with.

Having more (all) the tasks in a backlog from the get-go might make sense if we knew that: a) requirements wouldn't change b) priorities wouldn't change c) we would be able to keep the understanding of the work throughout the effort Then we'd just pull ticket by ticket and fill it with the details when we need it.

I've been doing it for 25 years, and I'm yet to see a project where the above assumptions would be true. I don't expect to see it.

Requirements always change. So do priorities.

We have this saying that our clients always know what they want. Until they see it. Then they know they wanted something different.

But even if that wasn't the case, the requirements change because we learn as we build the thing. The moment we know the least about a project is at its beginning. After that, we only know more.

So if things change, keeping more tickets in flight (even in backlog) means that every reprioritization, every planning, every pull to development costs more. Heck, we're bound to add work that's already there, but we forgot about it.

It's the cognitive load we add to so many activities every day.

And it doesn't even solve the problem of having better design because there's too much to remember.

Your intuition is right, though, when it comes to understanding the big picture. Not only architecture but also business. When every engineer on the team understands these higher-level goals it's so much easier to make sound decisions about design and implementation.

But for that we don't need dozens/hundreds of tickets in backlog.

BTW: I have a rule of thumb that on a physical board, there shouldn't be more than 100 items altogether. Our brains are incapable of meaningfully processing more. On a virtual board, it's even less, as our visual capabilities are impaired by screen limitations and crappy design of the tools we use.

If we look at it from the systemic perspective, the goal is to have enough milk at the office just in time.

Balancing the tasks between different actors within the system is a different concern.

If 30 seconds of my time saves someone else 10 minutes, it may be a good tradeoff, even if my time costs a few times more.

On one of the most effective teams I worked on, there was a tech lead who would throw himself into a role based on the team's needs based on insight from a morning daily. Most of the time, he played his strongest suit (back-end). However, there were days when he was helping with the most menial front-end tasks (he wasn't super-effective at that) or testing (same).

Was he efficient? If we look at him in isolation, then no. But because his work helped to remove bottlenecks and unblock the team, the whole team was more effective thanks to him.

What is interesting in some of the discussion threads here is how people look at the process effectiveness in a completely reverse way. Sometimes, they focus on their individual efficiency as if they were able to deliver value singlehandedly. Individual efficiency doesn't mean much.

A typical example would be a developer who's super efficient, but there's no one to do a code review (or test or whatever) just in time. By the time they get a list of issues to fix, they don't remember the context, they wrote so much more stuff relying on the things that they need to redo, etc.

Their efficiency would mainly be regarding coding in isolation. While the effectiveness would be measured in what the team could release/deliver to the clients.

As per Drucker's famous quote: "There is nothing quite so useless, as doing with great efficiency, something that should not be done at all."

I failed to explain.

In the ideal case, in manufacturing, we repeat the same set of tasks to manufacture identical goods.

In software development, we have the same stages (development, code review, testing, etc.), but every task going through the workflow will be different. Depending on how these tasks are defined, the effort, interdependencies, etc., might vary wildly.

Both types of work, of course, will have variability related to the complexity of the process. And that variability will be correlated with the size of workflow, people and/or machines involved, etc.

It's just the knowledge work adds another dimension. By the way, that's why, in knowledge work, we rather talk about accepting variability instead of controlling it (which was the focus in Lean Manufacturing).

I recommend Don Reinertsen's work on that, since he worked in both contexts. While his book (Principles of Product Development Flow) is not an easy read, it's absolute gold.

The order typically runs with not just milk but all the supplies. It's just the "going out of milk" trigger happens most frequently.

And yes, using different kinds/colors of cards for different kinds of milk might have been an improvement to consider. It would, however, make the system more complicated. Was it me, I'd start with a simpler design and iterate only when I saw the need.

It follows the rule of thumb: make it as simple as possible.

Wow! This escalated quickly.

In this whole sub-thread, I see quite a lot of signals along the lines of: - that's someone else's job, I shouldn't be bothered - I'm doing valuable work, others should make it easy for me - (all sorts of) managers are to make some problems inexistent for me

I'm not saying that's all in the original thread, but I read such sentiment.

So here's something that we do that may be unusual.

We respect everyone's roles and work. As much as Kasia wouldn't jump on a project as a developer, none of our developers would take her seat and handle all the stuff she deals with daily. Heck, she routinely helps people dealing with all sorts of paperwork that, especially for foreigners, are major pain in the butt. Which is "funny" because it's just "simple paperwork anyone could do."

And before someone throws at me that anyone can order milk online, that's like a hundredth priority or something like that.

Anyway, starting from a place where we all respect each other and everyone's work, dropping an index card on someone's desk on the way to one's own is a non-issue.

I acknowledge, though, that in an environment where people don't respect others' work because whatever (they have a less prestigious role, they're paid less, etc.), folks may totally perceive that a problem.

And yes, establishing such respect is so much harder than making sure that milk is in a frigging cupboard.

There is a level of oversimplification beyond which the solution stops serving its purpose.

If this discussion board was just a shared doc in which everyone could write, that might be a "too simple" solution. Basic control over one's writing is what we expect in solutions such as this.

With Milk Kanban, it might have been just asking people to tell Kasia when they take the last carton. Would it be a simpler solution? Yes. Would it work? Well, I guess there is a reason why we do have these index cards.

That's a great analogy!

On the one hand, the context is different. An affordance, as you point out, signals how we should use an item. In a way, it suggests a meaning. A kanban's meaning is typically defined as the process (largely) is known.

In the story about Milk Kanban, the index card is self-explanatory, but that's just an extra bit, to make the process more bullet-proof.

On the other hand, if we generalize both examples, we land in a place where the design (of things, of processes) should communicate how to act. I either interact with an object or I do my action within a process.

BTW: The Design of Everyday Things is another great reading recommendation in this thread.

Oh, there is a real Kasia. Although she's a person of many talents, I would be genuinely surprised if she spent evenings studying Japanese management methods.

The solution she designed, however, is as if she already knew all of that part of the MBA program :)

Which shows how significant parts of these methods have roots in basic awareness and perceptiveness to how the work gets done. Lean/Agile only codified some of these good practices. Unfortunately, they also petrified a lot of specific techniques. But that's another story.