Dragan Stepanović
@dstepanovic.bsky.social
Trying hard not to think about small batches, bottlenecks, and systems. In the meantime: XP, ToC, Lean, Systems Thinking.
Moved here from that other place for good.
Moved here from that other place for good.
If you have 5 layers of indirection in your code that you always need to jump through in order to add any functionality and tests that are painful to write because of bad design, I can totally see how AI can speed you up.
January 22, 2026 at 8:03 PM
If you have 5 layers of indirection in your code that you always need to jump through in order to add any functionality and tests that are painful to write because of bad design, I can totally see how AI can speed you up.
Bearing in mind that human availability is constrained, if the cost of generating code plummeted, then at the same time the cost of (human) review skyrocketed.
As those costs shoot up, you tend to have less of it per unit of code.
As those costs shoot up, you tend to have less of it per unit of code.
January 22, 2026 at 10:50 AM
Bearing in mind that human availability is constrained, if the cost of generating code plummeted, then at the same time the cost of (human) review skyrocketed.
As those costs shoot up, you tend to have less of it per unit of code.
As those costs shoot up, you tend to have less of it per unit of code.
Reposted by Dragan Stepanović
What I guess is going to happen with all the code being generated so cheaply by a heavy AI machinery is the same thing that is already happening with people giving up on reading AI-generated README files.
January 19, 2026 at 9:41 AM
What I guess is going to happen with all the code being generated so cheaply by a heavy AI machinery is the same thing that is already happening with people giving up on reading AI-generated README files.
It's worth reminding a lot of AI folks that:
Time saved by optimizing a non-constraint is not time saved for the whole system. It's not only time not saved, it's actually reducing the throughput of the whole system.
Time saved by optimizing a non-constraint is not time saved for the whole system. It's not only time not saved, it's actually reducing the throughput of the whole system.
January 18, 2026 at 11:15 AM
It's worth reminding a lot of AI folks that:
Time saved by optimizing a non-constraint is not time saved for the whole system. It's not only time not saved, it's actually reducing the throughput of the whole system.
Time saved by optimizing a non-constraint is not time saved for the whole system. It's not only time not saved, it's actually reducing the throughput of the whole system.
"If you are vibe coding in prod, you don't have a prod... you have a dev environment with real users in it" - YouTube comment
January 17, 2026 at 7:10 PM
"If you are vibe coding in prod, you don't have a prod... you have a dev environment with real users in it" - YouTube comment
Oh, I have two more from Eli (Goldratt) on AI:
January 16, 2026 at 6:36 PM
Oh, I have two more from Eli (Goldratt) on AI:
If Eli Goldratt was alive today, I'm pretty sure he'd tell you that the rate at which you're able to generate code matters IF AND ONLY IF that rate is:
- lower than the rate at which your team is able to review code AND
- lower than the rate at which your team is able to review code AND
LinkedIn
This link will take you to a page that’s not on LinkedIn
lnkd.in
January 16, 2026 at 3:52 PM
If Eli Goldratt was alive today, I'm pretty sure he'd tell you that the rate at which you're able to generate code matters IF AND ONLY IF that rate is:
- lower than the rate at which your team is able to review code AND
- lower than the rate at which your team is able to review code AND
I would love to see the total number of times people across the world wrote "this is completely unacceptable" in their prompts telling off AI when it did something they explicitly asked it not to do.
January 16, 2026 at 2:20 PM
I would love to see the total number of times people across the world wrote "this is completely unacceptable" in their prompts telling off AI when it did something they explicitly asked it not to do.
An abstraction having a property of being indeterministic cannot be an abstraction.
If an abstraction is flaky (different from leaky) it pulls you back into the details to understand if it abstracted the thing in the way it should've abstracted.
If an abstraction is flaky (different from leaky) it pulls you back into the details to understand if it abstracted the thing in the way it should've abstracted.
January 16, 2026 at 2:13 PM
An abstraction having a property of being indeterministic cannot be an abstraction.
If an abstraction is flaky (different from leaky) it pulls you back into the details to understand if it abstracted the thing in the way it should've abstracted.
If an abstraction is flaky (different from leaky) it pulls you back into the details to understand if it abstracted the thing in the way it should've abstracted.
If you're not used to being attuned to the frequent feedback and signals that the code and tests are telling you and incorporating them in the next small iterations of your design and tests (i.e. evolutionary, emergent design), then doing bigger batches makes perfect sense.
1/2
1/2
January 15, 2026 at 1:35 PM
If you're not used to being attuned to the frequent feedback and signals that the code and tests are telling you and incorporating them in the next small iterations of your design and tests (i.e. evolutionary, emergent design), then doing bigger batches makes perfect sense.
1/2
1/2
Reposted by Dragan Stepanović
im Jahr 2025 lag die globale Temperatur an KEINEM EINZIGEN TAG unter dem Schnitt von 1991-2020.
January 14, 2026 at 2:07 PM
im Jahr 2025 lag die globale Temperatur an KEINEM EINZIGEN TAG unter dem Schnitt von 1991-2020.
"Humans always produced slop code" argument is not an excuse to justify generating slop code at a magnitudes faster pace.
January 15, 2026 at 11:39 AM
"Humans always produced slop code" argument is not an excuse to justify generating slop code at a magnitudes faster pace.
Doing waterfall just got cheaper.
It's not about how fast you're able to produce a big batch, but how big a batch is.
It's not about how fast you're able to produce a big batch, but how big a batch is.
January 15, 2026 at 11:36 AM
Doing waterfall just got cheaper.
It's not about how fast you're able to produce a big batch, but how big a batch is.
It's not about how fast you're able to produce a big batch, but how big a batch is.
I just realized that the friction that existed with PMs/Designers, coming up with solutions on their own (for the sake of engineering efficiency) and throwing huge batches over the wall to engineering "to implement" got resolved. But not in a way I hoped for.
January 14, 2026 at 7:56 PM
I just realized that the friction that existed with PMs/Designers, coming up with solutions on their own (for the sake of engineering efficiency) and throwing huge batches over the wall to engineering "to implement" got resolved. But not in a way I hoped for.
The ability to generate code faster reduces the pressure to as a technique for minimizing liability (code) while getting to value sooner.
The customer is the one to tell if your solution is meeting their need.
The customer is the one to tell if your solution is meeting their need.
January 14, 2026 at 7:51 PM
The ability to generate code faster reduces the pressure to as a technique for minimizing liability (code) while getting to value sooner.
The customer is the one to tell if your solution is meeting their need.
The customer is the one to tell if your solution is meeting their need.
I'll just leave this here...
January 14, 2026 at 2:27 PM
I'll just leave this here...
Someone needs to do a talk on applying Goldratt's 4 questions from Beyond the Goal applied to AI (and failing on the 2nd: What limitation does this technology diminish?)
"Technology can bring benefits if, and only if, it diminishes a limitation."
"Technology can bring benefits if, and only if, it diminishes a limitation."
January 14, 2026 at 2:17 PM
Someone needs to do a talk on applying Goldratt's 4 questions from Beyond the Goal applied to AI (and failing on the 2nd: What limitation does this technology diminish?)
"Technology can bring benefits if, and only if, it diminishes a limitation."
"Technology can bring benefits if, and only if, it diminishes a limitation."
Most of the evidence about AI "speeding up" development is coming from folks doing individual, toy projects they had on their to-do list.
Throw it into a whole team, or even worse org, and let me know how it plays out with a reinforcing feedback loop driven by >>
Throw it into a whole team, or even worse org, and let me know how it plays out with a reinforcing feedback loop driven by >>
January 14, 2026 at 2:12 PM
Most of the evidence about AI "speeding up" development is coming from folks doing individual, toy projects they had on their to-do list.
Throw it into a whole team, or even worse org, and let me know how it plays out with a reinforcing feedback loop driven by >>
Throw it into a whole team, or even worse org, and let me know how it plays out with a reinforcing feedback loop driven by >>
The hidden value of speeding up non-constraint in the system is that it makes real constraint more prominent, making it more visible that speeding up non-constraint was never the right problem to solve.
January 14, 2026 at 11:27 AM
The hidden value of speeding up non-constraint in the system is that it makes real constraint more prominent, making it more visible that speeding up non-constraint was never the right problem to solve.
There's something deeply ironic in incentivizing/mandating people to work in isolation (individually) on features, only to bring them together when there's an incident in production as a result of working in isolation.
January 13, 2026 at 1:48 PM
There's something deeply ironic in incentivizing/mandating people to work in isolation (individually) on features, only to bring them together when there's an incident in production as a result of working in isolation.
Every linear software/product development process by design assumes no learning happens and no known and unknown unknowns surface in the process.
Needless to say that reality rarely, if ever, matches that mental model.
Needless to say that reality rarely, if ever, matches that mental model.
January 13, 2026 at 1:39 PM
Every linear software/product development process by design assumes no learning happens and no known and unknown unknowns surface in the process.
Needless to say that reality rarely, if ever, matches that mental model.
Needless to say that reality rarely, if ever, matches that mental model.
As long as LLM pricing is based on how much/how often you're allowed to converse with the model, Spec-Driven Development and big(ger) batches will be a normal response to that.
Scarcity drives batch transaction costs up, which drives the average batch size up to compensate for it.
Scarcity drives batch transaction costs up, which drives the average batch size up to compensate for it.
January 9, 2026 at 3:16 PM
As long as LLM pricing is based on how much/how often you're allowed to converse with the model, Spec-Driven Development and big(ger) batches will be a normal response to that.
Scarcity drives batch transaction costs up, which drives the average batch size up to compensate for it.
Scarcity drives batch transaction costs up, which drives the average batch size up to compensate for it.
Reposted by Dragan Stepanović
