My team is currently facing this issue. We had large layoffs that cut us down to a very small size while simultaneously having new initiates pushed our way that require speed. Everyone is afraid to ask what feel like basic questions, again.. layoffs, so everything is hidden in DM's. Add on top of it the push (read requirement) from higher ups to use AI and it's simply in a terrible state.
What seem like great initiatives are being watered down because nobody can keep up, debugging issues takes so much longer because everything is changing at once, and everyone is exhausted and hardly talking to each other which feeds into a cycle of having no idea what is happening.
This describes my team to a T ... are we working at the same place?!?
We actually talk more now which helps, but it is still hard to keep up when everyone is barreling ahead doing their own thing. In addition to more talking, there needs to be a semblance of strategy that everyone is aligned on and understands their role in.
A high-agency, high-functioning team has always been a superpower, but mastering this capability is what will make or break organizations that are trying to run lean with AI. It's a "people problem" at its core, and no amount of technology can fix that.
we love to say things like these, but... most security issues are in fact BYPASSABLE - virtualization, firewalls, autorollbacks, ro-filesystems and so on are many of the tools we have on our belsts
decades of WordPress have taught us that insecure apps can 100% be securely deployed
it's a bit of an art, most recently edicated devops/sre ppl suck at it, but it's doable
...aeons a go in a former life we ran production apps that got hacked weekly, and nobody batted an eye at it, backups servers recreated from secure ro-images were span up with last-clean-app version, occassionally we had fun disassembling whatever reverse shells and other mallware that got beached on our systems (but couldn't "swim" bc everything we ran was "too exotic" for them to figure out the next steps of a proper attack), development and business continued as usual with zero interruptions etc
If you go against every principle (defense in depth, security through obscurity), maybe you should ask yourself "am I willing to be on the record saying this when my company gets hacked?"
There can be multiple reasons system crumbles, do you want to be behind one of them... intentionally?
100%. I'm willing to prioritize what matters at the right time. if "inner-system security" is not the right priority, and security can be attained at the "outer-system level" better, we should have the balz to say it. fuckitol
Imagine if your doctor said "we don't really need to do this if some other guy or nurse does a right job, so fuck it".
In other critical professions you don't want to screw up because when you lose license you're legally unemployable. Maybe it's time to require a license to be a programmer. We used to have a strong culture but those days are gone and stakes are higher. Putting people at risk because you think VC can vibe code an insecure app and then it's everybody else's responsibility to ship it securely?
you got everything I said wrong: I'm familiar with security and infrastructure best practice and I'm confident I/we can securely deploy almost any vibe-coded crap someone can throw at us - we understand security, we understand defense-in-depth, we understand the subtle trade offs of why security by obscurity is usually a bad idea (and when it does help) etc.
sure, if the vibe-coded sloptopus does bank transfers and stuff, properly carving out these pieces out of it might require actual engineering work before containerizing it - but someone is willing to pay for it it can be done
some "toy" example: take a crappy app that stores llm keys in config files that the llm agents themselves can edit - after isolating it up, but an llm proxy in front of it and have those keys be short lived proxy-keys with aggressive rate limits and monitoring etc etc
isolation, injecting proper monitoring into code of apps, putting proxies between app and apis, and layers between app and infra it runs on or touches etc
and these things now can be mostly cookbook-ified / automated 90% of the way too
as long as you can shop things into little ppl and ensure short-lived and granular access to valuable data you can 100% run totally unsecure and buggy code reliably and get value from it
it's engineering and understanding security from first principles [and a culture arund it - that _is_ the HARD af bit though...] instead of just believing in "secure app best practices" from the "holy scriptures" - secure apps are hackable, and unsecure apps can be unhackable, heck even mil systems run on unpatched old software everywhere, they're just properly insulated, the components are insecure but the system as a whole can be perfectly secure
this usually because of lack of accountability on executive level. The salary should be low and bonus to be tied to metrics 1-2-3yr from now, then they will be more careful and pragmatic about breaking things.
"Slow is smooth, and smooth is fast." If you move fast _and_ you break things you just end up with a lot of broken things. I never did understand this philosophy.
You do things slowly, intentionally, again and again and again, that it becomes almost muscle memory that when the times comes for you to do it again in future, it happens smooth and is thus fast eventually.
the top level comment is fine. the lame guy's comment was a promotional chatgpt-generated useless tl;dr that added zero information and linked to his own blog post
This whole thread is trainwreck. Your initial comment is three simple sentences with very little room for misunderstanding yet here we are. Then there is a comment on that comment which is self-promotion of LLM-trash published as blog post. One would think should an easy donwvote, but it is not. Then, a dude who pointed out this lame self-promotion is donwvoted into oblivion, because what? Bunch of people cannot think of three seconds and use their eyes to try to understand what's lame about that?
"this" doesn't indicate which one it's referring to. Obviously they understand the effects of "move fast and break things", so it makes sense it would refer to the other one. Doubly so they quoted one but not the other, which is often done in contexts like this to indicate you're repeating it verbatim because you don't understand it well enough to paraphrase.
In that case, scrolling down, the other replies don't get it quite right either. An alternate way of phrasing that one would be "innovation over stability/perfectionism". It came from Facebook, where users can tolerate some minor breakage, in an era when they were cranking out all sorts features and overtaking MySpace. I think the idea is generally understood to be a good thing in the startup stage where the goal is to disrupt existing competition - if you take too long to get to market, whatever you're doing might not matter anymore.
The philosophy that was not being understood was "move fast and break things." "Slow is smooth, and smooth is fast" was mentioned as an opposite point of view.
To then explain "slow and smooth, and smooth is fast" as a reply is to not comprehend the comment at all. Then, it ends with a link to their own blog.
People often mistake speed for progress. One of the best examples of this is in jiujitsu. Two beginners sparing are often moving fast, but so many of the moves are wasted effort there's no actual progress in the match. Two experts sparing can often look like a training round because every move is efficient leading them towards their goal.
The problem is, as is so often the case with our modern companies, the things that got broken were other people's things. The things that were gained were made theirs.
In other words, privatized profits and socialized costs. Again.
"Move fast and break things" is about conquering the second kind of slow. Not idealizing breaking things but not being legitimately slow tied up in bad attempts not to break things.
An old baseball coach always said “be slow, but quick!” Took me years to sort that out.
Be thoughtful, be methodical, be aware, be comfortable, and be decisive. Made a lot of sense when I caught a 2-hopper off the line at 3rd and didn’t have time to think about how to field it or where to throw.
There was a lot of low hanging fruit at the advent of the internet. A few rich kids with some decent vision moved in and solved those problems. They then confused the ease of operating within this landscape with actual business acumen.
Not knowing _why_ you were just successful is a killer.
> When speed is the priority, there’s no incentive to improve or invest in the shared system (e.g. a design system or codebase) under a tight deadline.
These guardrails are precisely what should be laid down in advance to enable workers to run safely with AI. Write all the rules in your AGENTS file, and point your AI reviewer at it. Encode whatever you can describe algorithmically in commit hooks. This will get you 90% of the way there, and peer review will take care of the rest.
I am hopeful that AI will empower smaller companies, where there is less deadweight, and consensus can be formed more quickly. Discussing what to build is not wasted time; it's one of the few things that favors humans.
This isn’t related at all but it’s sure interesting how our brains evolved. When we are cognitively taxed, our ability to communicate breaks down. When we are physically taxed and doing something we are built to do (like running), conversations flow in the strangest ways. Heck, I’ve had long in depth conversations about Infinite Jest with total strangers on trail runs. It kind of makes you wonder about a whole lot of stuff we have filled our worlds with.
I'm seeing this with ideation. It's so easy now with AI to come up with a new idea in a 40 page manifest that no-one has the time to really mentally ingest. Everything is defined to the T, milestones, success measures, all of it. Things become a binary do all of this, or don't do it. There's no room for conversation.
> But I’m also pro-slowing the fuck down and doing actual human thinking before pulling a trigger … We all love dopamine, we all love seeing new ideas come to life
You can spend 100M tokens/week and generate something that is good enough for end to end demo to paying clients in 1-4 weeks depending on complexity of the project. Doing this feels like being on drugs, in that the creative process is a high, and that you will be mentally exhausted at the end of every day (the crash).
I agree with you in principle, but in my mind there's a slight disconnect between a proof of a theorem that can freely be built upon by the mathematical community and the social media integration no one asked for that a 5 person point-of-sale startup writes months before going bankrupt.
New mathematical concepts are usually published in scholarly journals so it's possible to dig them up decades later when they're needed. But most companies never publish stuff that doesn't work, and don't even make any effort to learn from it internally. So they make the same mistakes over and over again.
I am not sure for people who wrote this, did they realize most of the time these conversations are just for politics reasons? In a non cooperative environment, projects moving fast does not mean individual is moving fast or vice versa. But if you are in a cooperative environment pretty much people just act what he suggested naturally.
This is true in military tactics but it is often phrased in the contrapositive: if you want to move fast, establish enough trust such that talking is not needed.
The idea is that speed is *essential* but coordinative action is too. Most combat situations in history have not allowed for hierarchical resolution of all important decisions nor the slower, alternative consensus-based decision process. Independence and alignment with the mission allows for more agile, more effective units. As technology advances, it actually gets EASIER to talk and coordinate actively rather than train and pre-bake the coordination. Ship captains today can be released with much less latitude than 200 years ago because we can raise them on the radio at need.
I'm not arguing we should adopt military metaphors or even that exigencies force speed somehow, as they do often in military matters. I AM arguing that we ought to consider there are local and system-wide virtues to training and coordinating in such a way that you can move without talking.
The way to view LLMs is that it is a better google search. This allows you to speak to coworkers only when they have the context you need. For other trivial things there’s AI.
Optimally you must only disturb your coworkers when necessary.
I understand there is a point where it's harmful to take time away from them, but there's a point well before necessary where you're still conservative when asking for help but it's a net benefit to take their time.
If it took you 2 hours to not bother someone for 10 minites, that's not necessary but also still net benefit.
Agree there's an optimal here. I'm saying LLM's overall reduce the need to speak to your coworkers and that's a good thing because it opens up more avenues to have interesting conversations. And not "how do you set up this repo".
Schedule office hours to batch sync questions for entire team. Bonus points if you can have a doc for sharing those questions so people can come prepared
My team is currently facing this issue. We had large layoffs that cut us down to a very small size while simultaneously having new initiates pushed our way that require speed. Everyone is afraid to ask what feel like basic questions, again.. layoffs, so everything is hidden in DM's. Add on top of it the push (read requirement) from higher ups to use AI and it's simply in a terrible state.
What seem like great initiatives are being watered down because nobody can keep up, debugging issues takes so much longer because everything is changing at once, and everyone is exhausted and hardly talking to each other which feeds into a cycle of having no idea what is happening.
This describes my team to a T ... are we working at the same place?!?
We actually talk more now which helps, but it is still hard to keep up when everyone is barreling ahead doing their own thing. In addition to more talking, there needs to be a semblance of strategy that everyone is aligned on and understands their role in.
A high-agency, high-functioning team has always been a superpower, but mastering this capability is what will make or break organizations that are trying to run lean with AI. It's a "people problem" at its core, and no amount of technology can fix that.
A couple times a week my freaking VP is announcing some new tool he vibecoded and talked to no one about.
I’m sure they’re all riddled with security issues, but am I gonna go be the one pointing it out? Heck no.
we love to say things like these, but... most security issues are in fact BYPASSABLE - virtualization, firewalls, autorollbacks, ro-filesystems and so on are many of the tools we have on our belsts
decades of WordPress have taught us that insecure apps can 100% be securely deployed
it's a bit of an art, most recently edicated devops/sre ppl suck at it, but it's doable
...aeons a go in a former life we ran production apps that got hacked weekly, and nobody batted an eye at it, backups servers recreated from secure ro-images were span up with last-clean-app version, occassionally we had fun disassembling whatever reverse shells and other mallware that got beached on our systems (but couldn't "swim" bc everything we ran was "too exotic" for them to figure out the next steps of a proper attack), development and business continued as usual with zero interruptions etc
If you go against every principle (defense in depth, security through obscurity), maybe you should ask yourself "am I willing to be on the record saying this when my company gets hacked?"
There can be multiple reasons system crumbles, do you want to be behind one of them... intentionally?
100%. I'm willing to prioritize what matters at the right time. if "inner-system security" is not the right priority, and security can be attained at the "outer-system level" better, we should have the balz to say it. fuckitol
Imagine if your doctor said "we don't really need to do this if some other guy or nurse does a right job, so fuck it".
In other critical professions you don't want to screw up because when you lose license you're legally unemployable. Maybe it's time to require a license to be a programmer. We used to have a strong culture but those days are gone and stakes are higher. Putting people at risk because you think VC can vibe code an insecure app and then it's everybody else's responsibility to ship it securely?
you got everything I said wrong: I'm familiar with security and infrastructure best practice and I'm confident I/we can securely deploy almost any vibe-coded crap someone can throw at us - we understand security, we understand defense-in-depth, we understand the subtle trade offs of why security by obscurity is usually a bad idea (and when it does help) etc.
sure, if the vibe-coded sloptopus does bank transfers and stuff, properly carving out these pieces out of it might require actual engineering work before containerizing it - but someone is willing to pay for it it can be done
some "toy" example: take a crappy app that stores llm keys in config files that the llm agents themselves can edit - after isolating it up, but an llm proxy in front of it and have those keys be short lived proxy-keys with aggressive rate limits and monitoring etc etc
isolation, injecting proper monitoring into code of apps, putting proxies between app and apis, and layers between app and infra it runs on or touches etc
and these things now can be mostly cookbook-ified / automated 90% of the way too
as long as you can shop things into little ppl and ensure short-lived and granular access to valuable data you can 100% run totally unsecure and buggy code reliably and get value from it
it's engineering and understanding security from first principles [and a culture arund it - that _is_ the HARD af bit though...] instead of just believing in "secure app best practices" from the "holy scriptures" - secure apps are hackable, and unsecure apps can be unhackable, heck even mil systems run on unpatched old software everywhere, they're just properly insulated, the components are insecure but the system as a whole can be perfectly secure
this usually because of lack of accountability on executive level. The salary should be low and bonus to be tied to metrics 1-2-3yr from now, then they will be more careful and pragmatic about breaking things.
"Slow is smooth, and smooth is fast." If you move fast _and_ you break things you just end up with a lot of broken things. I never did understand this philosophy.
You do things slowly, intentionally, again and again and again, that it becomes almost muscle memory that when the times comes for you to do it again in future, it happens smooth and is thus fast eventually.
https://brajeshwar.com/2025/slow-is-smooth-smooth-is-fast/
Dude ... don't be lame
Are you disagreeing with the explanation? I am curious why.
It makes sense to me.
Move slowly and deliberately while avoiding big mistakes. As opposed to moving fast and making big mistakes which by comparison is slower.
the top level comment is fine. the lame guy's comment was a promotional chatgpt-generated useless tl;dr that added zero information and linked to his own blog post
It also directly answered OP's "I never did understand this philosophy."
It misunderstood my comment.
I never did understand the philosophy of _moving fast and breaking things_.
Instead I move intentionally: slow and therefore fast.
This whole thread is trainwreck. Your initial comment is three simple sentences with very little room for misunderstanding yet here we are. Then there is a comment on that comment which is self-promotion of LLM-trash published as blog post. One would think should an easy donwvote, but it is not. Then, a dude who pointed out this lame self-promotion is donwvoted into oblivion, because what? Bunch of people cannot think of three seconds and use their eyes to try to understand what's lame about that?
I'll have to switch to farming, I swear.
"this" doesn't indicate which one it's referring to. Obviously they understand the effects of "move fast and break things", so it makes sense it would refer to the other one. Doubly so they quoted one but not the other, which is often done in contexts like this to indicate you're repeating it verbatim because you don't understand it well enough to paraphrase.
In that case, scrolling down, the other replies don't get it quite right either. An alternate way of phrasing that one would be "innovation over stability/perfectionism". It came from Facebook, where users can tolerate some minor breakage, in an era when they were cranking out all sorts features and overtaking MySpace. I think the idea is generally understood to be a good thing in the startup stage where the goal is to disrupt existing competition - if you take too long to get to market, whatever you're doing might not matter anymore.
The philosophy that was not being understood was "move fast and break things." "Slow is smooth, and smooth is fast" was mentioned as an opposite point of view.
To then explain "slow and smooth, and smooth is fast" as a reply is to not comprehend the comment at all. Then, it ends with a link to their own blog.
People often mistake speed for progress. One of the best examples of this is in jiujitsu. Two beginners sparing are often moving fast, but so many of the moves are wasted effort there's no actual progress in the match. Two experts sparing can often look like a training round because every move is efficient leading them towards their goal.
People equally mistake progress for progress.
But running a thousand miles East when success lies West...
This is why I love the age of AI. The age of all the answers. Literally 42.
It has never been more clear that the hardest part of our work is asking and understanding the right question.
It's about trying and breaking things to find out what's working, instead of casually tip-toeing lest you break something, and wasting your time.
or maybe just ask someone for help first before you go breaking stuff?
The quote is for startup businesses, doing novel pivots, and shipping novel features.
It's not for things where you can just ask some expert to tell you what works or decide for you.
Not many startups doing novel things these days.
That's the spirit of the idea: It is meant to free you of that requirement, with the understanding that you very well may break things.
It is permission to trade inaccuracy for autonomy.
The problem is, as is so often the case with our modern companies, the things that got broken were other people's things. The things that were gained were made theirs.
In other words, privatized profits and socialized costs. Again.
There's many such problems with it. Don't misunderstand, I do not condone it :)
Yeah, I hear you...working with your team mates is for smooth-brained chumps. Not like us 100x engineers.
Reads like incompetence to me
Another way of looking at this is "getting early feedback" by failing fast.
It's another way of doing things and not necessarily incompetence.
Maybe that's an incompetent read
In racing the fastest laps look slow.
But slow laps also look slow.
"Move fast and break things" is about conquering the second kind of slow. Not idealizing breaking things but not being legitimately slow tied up in bad attempts not to break things.
Step two is being slow in the right way.
An old baseball coach always said “be slow, but quick!” Took me years to sort that out.
Be thoughtful, be methodical, be aware, be comfortable, and be decisive. Made a lot of sense when I caught a 2-hopper off the line at 3rd and didn’t have time to think about how to field it or where to throw.
Your "smooth fast" may be not fast enough in grab the market as fast as possible economy.
Learning fast is probably what moving fast implies, not breaking things carelessly to let technical debt pile up to slow you down.
There was a lot of low hanging fruit at the advent of the internet. A few rich kids with some decent vision moved in and solved those problems. They then confused the ease of operating within this landscape with actual business acumen.
Not knowing _why_ you were just successful is a killer.
One of the most expensive learnings was: If you want to do it fast, do it slow.
Time and time again proven true.
> When speed is the priority, there’s no incentive to improve or invest in the shared system (e.g. a design system or codebase) under a tight deadline.
These guardrails are precisely what should be laid down in advance to enable workers to run safely with AI. Write all the rules in your AGENTS file, and point your AI reviewer at it. Encode whatever you can describe algorithmically in commit hooks. This will get you 90% of the way there, and peer review will take care of the rest.
I am hopeful that AI will empower smaller companies, where there is less deadweight, and consensus can be formed more quickly. Discussing what to build is not wasted time; it's one of the few things that favors humans.
Sometimes you have to go slow (talk) in order to go fast (build the right thing).
This isn’t related at all but it’s sure interesting how our brains evolved. When we are cognitively taxed, our ability to communicate breaks down. When we are physically taxed and doing something we are built to do (like running), conversations flow in the strangest ways. Heck, I’ve had long in depth conversations about Infinite Jest with total strangers on trail runs. It kind of makes you wonder about a whole lot of stuff we have filled our worlds with.
I'm seeing this with ideation. It's so easy now with AI to come up with a new idea in a 40 page manifest that no-one has the time to really mentally ingest. Everything is defined to the T, milestones, success measures, all of it. Things become a binary do all of this, or don't do it. There's no room for conversation.
> But I’m also pro-slowing the fuck down and doing actual human thinking before pulling a trigger … We all love dopamine, we all love seeing new ideas come to life
You can spend 100M tokens/week and generate something that is good enough for end to end demo to paying clients in 1-4 weeks depending on complexity of the project. Doing this feels like being on drugs, in that the creative process is a high, and that you will be mentally exhausted at the end of every day (the crash).
Or: how the industry ends up with about half the things they build going completely unused.
History of invention in the science of mathematics would show that there is nothing that's useless in the long term. It's all pieces of a puzzle.
I agree with you in principle, but in my mind there's a slight disconnect between a proof of a theorem that can freely be built upon by the mathematical community and the social media integration no one asked for that a 5 person point-of-sale startup writes months before going bankrupt.
New mathematical concepts are usually published in scholarly journals so it's possible to dig them up decades later when they're needed. But most companies never publish stuff that doesn't work, and don't even make any effort to learn from it internally. So they make the same mistakes over and over again.
Nah, most remain useless.
Inventions that were initially useless but found application later, are still in the very small minority.
by this pov, we're clearly... not moving fast enough
I am not sure for people who wrote this, did they realize most of the time these conversations are just for politics reasons? In a non cooperative environment, projects moving fast does not mean individual is moving fast or vice versa. But if you are in a cooperative environment pretty much people just act what he suggested naturally.
This is true in military tactics but it is often phrased in the contrapositive: if you want to move fast, establish enough trust such that talking is not needed.
The idea is that speed is *essential* but coordinative action is too. Most combat situations in history have not allowed for hierarchical resolution of all important decisions nor the slower, alternative consensus-based decision process. Independence and alignment with the mission allows for more agile, more effective units. As technology advances, it actually gets EASIER to talk and coordinate actively rather than train and pre-bake the coordination. Ship captains today can be released with much less latitude than 200 years ago because we can raise them on the radio at need.
I'm not arguing we should adopt military metaphors or even that exigencies force speed somehow, as they do often in military matters. I AM arguing that we ought to consider there are local and system-wide virtues to training and coordinating in such a way that you can move without talking.
[dead]
[dead]
The article spouts typical boomer arguments.
The way to view LLMs is that it is a better google search. This allows you to speak to coworkers only when they have the context you need. For other trivial things there’s AI.
Optimally you must only disturb your coworkers when necessary.
Disagree on the necessary only point.
I understand there is a point where it's harmful to take time away from them, but there's a point well before necessary where you're still conservative when asking for help but it's a net benefit to take their time.
If it took you 2 hours to not bother someone for 10 minites, that's not necessary but also still net benefit.
Agree there's an optimal here. I'm saying LLM's overall reduce the need to speak to your coworkers and that's a good thing because it opens up more avenues to have interesting conversations. And not "how do you set up this repo".
Schedule office hours to batch sync questions for entire team. Bonus points if you can have a doc for sharing those questions so people can come prepared