Revelry

AI-Driven Custom Software Development

Two figures talking to the ai silo rather than to each other

The AI silo: how LLMs are quietly killing engineering culture

It’s quiet…too quiet

Something feels different in Slack. Everyone’s busy, there’s lots of projects… but nobody’s talking (to me at least). I used to have to mute my Slack notifications, but I feel like I don’t have to anymore. It feels like something has changed.

We’ve always worked out in the open at Revelry. Decisions, questions, instructions… these all take place in public channels (as opposed to in lots of private DMs flying back and forth). There’s lots of great reasons to do this: it murders ambiguity across the team, and in my opinion is infinitely preferable to the “say everything five times in the DMs” approach. Most engineering-related discussions generally play out in our #implementation channel, where engineers share challenges and solutions, or celebrate and help each other.

But it seems to me that, over the time I’ve worked at Revelry, there’s been less and less chatter in this channel, less and less discussion about problems or solutions. Why, I wondered. So I asked Claude why none of the human beings are chatting anymore…

Oh.

And that’s when I began to suspect that having a seemingly all-knowing robot assistant at your beck and call is causing teams to talk and collaborate less. I certainly feel myself talking less and less to people at work, and more and more to the AI. I’m worried that this could have knock-on and deleterious effects: on the quality of company communication, and the fabric of the company culture.

Show me the Data

I don’t like relying on pure instinct, so I figured some hard data was in order. I tallied up our messages sent over time in our main engineering channel, from 2020 through to 2025, to test my hypothesis that fewer and fewer messages are being sent year over year.

Some caveats before I share it with you: staffing levels fluctuate over time (which I’ve tried to control for by capturing total employee numbers and figuring out the average messages sent per month), some people are far chattier than others, and sometimes we work with partners in their own Slack spaces. It’s also important to note that correlation is not necessarily causation.

With that said, I think I might be on to something:

Revelry image image

Robot got your tongue?

Firstly, the data. It seems to paint a picture of gradual decline over a number of years, followed by a dramatic plunge just after 2023 – the year that GPT-4 was released.

This tallies with my anecdotal experience. GPT-4 felt like the first model you could ask questions of and actually get something back that resembled a correct answer; something that you could go back and forth with to try and reason through a problem. There’s a snowballing effect in the data that also resonates: the more I practice using the AI (or as some see it, the more I give in to the addiction) the more I want to use it.

Revelry image image 2

So what?

Besides my crushing loneliness, what else is at risk of getting worse?

Every engineer has to figure out at some point how to know when to stop trying, and start asking. When something unknown is encountered, how long do you spend trying to figure it out yourself? Knowing how far to push by yourself, and when to ask for help, is a balancing act that engineers get better at over the course of their careers. Ask for help too often, and you run the risk of wasting the time of other engineers; ask for help too infrequently, and you’re absolutely wasting your own time when the solution might live in someone else’s head. And time is expensive.

LLMs have changed this equation beyond all recognition.

First, the pros: it feels like it’s easier and faster to get to a solution. LLMs provide access to a vast pool of information in one easy-to-access place. The previous methods (trawling through Stack Overflow/Slack/GitHub) created friction and irritation both in finding the relevant posts, and reading through/applying the fixes to your own problems. Engineers can now figure out the root cause of a given issue much faster than ‘back in the day’… most of the time.

In addition, the LLM isn’t going to think your questions are stupid. While searching for a solution, there’s no risk that someone will make assumptions about your technical skills, or say something that flares your imposter syndrome. You can privately ask what you’d maybe consider the dumbest questions imaginable to your LLM of choice (please no one look at my chat logs) 100% risk-free. Of course, at a good company, this fear should be unfounded: we’ve all been there. When has reality ever assuaged your irrational fears though? And those good people at Stack Overflow always found ways to make me feel dumb or that I was too smooth-brained to be a real engineer.

So…engineers using LLMs to answer questions means that senior engineers get more focused time to work on complicated things, and junior engineers don’t have to agonize about whether or not to ask why their test suite won’t launch. Why am I complaining?

Revelry image image 3

Because this has a steep cost.

Let’s say you use the LLM to figure out something about your codebase. Great! You move on, and you didn’t need to ask anyone anything. But that knowledge is siloed to just you and your chat session. Three other engineers might ask the same question, and so three times the tokens will be burned. The cost here is literal! This is nuanced: can you balance this triplicated token cost against the cost of the employee time that would have been spent if the question had been asked in the open?

A different and far less ambiguous pitfall is the risk of cognitive debt. If the ‘question to answer’ loop gets closed after a simple prompt, there’s a risk that the engineer who asked said question has missed something. This could be something that would have been integral to finding the answer in the first place, and it absolutely could be something that will come back to bite later if not understood. The worst thing about this is that cognitive debt affects all engineers on the team; no one has thought through the question and/or answer, and so no one on the team is aware that they’ve missed some crucial piece of understanding.

Except the next LLM training on your chats, that is!

You’re also less likely, in my anecdotal experience, to share the knowledge with your fellow engineers even if you think it’s important information. If you figure out a problem using a chatbot, and you catch something important: it feels about 100x less rewarding than figuring it out yourself using four hours and Google. Therefore, there’s no reason to get excited; and you also figure, if the information was easy enough for you to glean, other engineers could probably glean it the same way. It’s not special or exciting anymore. So you don’t post it, and the information is never saved. Other people haven’t learned from you.

You used to have to talk to other people

It’s 2021. Let’s say that, after hours of debugging and before you ask for help, you discover the reason your app looks completely misaligned for a particular user is that they are using a MacBook and they have “Show scroll bars” set to “Always”. Or that a particular AdBlocker causes something to fail. Or some other stupidly esoteric or arcane piece of lore.

This is the kind of thing you’d put in the #implementation channel as a PSA, or a warning or simply because you’re excited about the fact you figured it out. This kind of behavior serves a couple of purposes:

  • It puts the fact into the heads of other engineers, so that if they experience the same issue, they know what’s going on.
  • It puts the fact into Slack: the Searchable Log of All Conversation and Knowledge. If someone vaguely remembers crazy behavior around scrollbars, they can just search ‘scrollbars’ (like I did for this post) to remember the exact mechanism of action. Institutional knowledge is built.
  • It inspires conversation! From “Why does this setting exist?” to “here’s a way to get around this thing” to “here’s a war story.” It’s in these moments that that most elusive of properties, CULTURE, emerges.

Culture

I studied Psychology, not Sociology, so I’m a bit out of my depth here. Culture, nebulous and intangible culture, arises as an emergent property of communication between everyone at the company: whether that’s dry announcements, company all-hands, small emoji exchanges, excitedly sharing bug fixes… whatever. I also feel like when it degrades, it degrades silently.

As we commune less and less with each other – and more and more with the unthinking and unfeeling stochastic parrot (the AI) – we lose those opportunities for culture to grow. Ironically, I think that a good culture arises as an emergent property, just like the ‘intelligence’ of these large language models trained on bigger and bigger datasets. It can’t really be forced, or artificially created in a vacuum. You have to create the right conditions to foster positive interactions, and then let the culture develop from those interactions – building culture and trust over time. Most of the specifics of building a good culture that I can find – for example, how disagreements are handled, rewarding the right things, giving everyone a shared sense of purpose – come from good communication. And with less communication across the board, there’s less space for that to happen.

And at the end of the day, how can your company tout a culture of openness when nobody’s talking out in the open anymore?

A note about in-office working.

While I do think that remote-only teams are more at risk, I categorically do not think that sequestering your engineering team in the office is the answer. The benefits that a remote engineering team brings – flexibility across hours, opportunities to optimize working environments for employee wellbeing and productivity, and all the rest – far outweigh the drawbacks.

I talked with other software engineers at different companies who have been returned to the office while writing this, and they didn’t identify the same problems I had. Instead, they had noticed different trends. Outsourcing thinking to LLMs means that there’s a new ‘compile time’ when working on solutions: the amount of time it takes for the LLM to come back with a result. You’d think this would be perfect for building culture and trust through human interaction in an office…but in reality, it doesn’t. The times rarely line up. So I suppose a positive here is that AI usage probably hasn’t had much effect on in-office communication… but that doesn’t make up for all the bad in-office working produces either (a topic for another day)!

Revelry image image 4
“the ai is thinking” feels like the new “my code is compiling”

So how do we fix this?

First and foremost, let’s name the problem: the AI silo. Our conversations and knowledge are increasingly siloed inside our context windows. They never make it out to public channels where they could enrich other engineers, or encourage valuable discussion, or produce good culture. Most people don’t notice their own behavior shifting (I know I don’t), so I worry that one day we will all wake up and wonder where all the culture and communication went.

Of course, I could be completely wrong: it’s too early to tell if these trends are driven by the prevalence and rise of the chatbot, or simply the slow decline from the COVID peak. But I have a feeling these trends are going to accelerate: especially as more and more engineers change their ways of working (based on pressure to adopt AI trends and ship ever faster). I really do think this is a problem that is going to get worse, and lead to worse outcomes (in more domains than just engineering), for everyone.

Once the problem has been identified, I think maintaining and improving the remaining human interactions that we have gains more importance and urgency. Engineering meetings, all-hands, kickoff, poker sessions and discussion meetings… these sorts of intentional spaces allow for culture to maintain itself, and for cool or interesting ideas to be shared.

Promoting a culture of openness and honesty also helps. An open and honest culture means that asking questions and not being embarrassed about them becomes a virtuous cycle:

  1. The question is asked, despite potential feelings and fears of shame and imposter syndrome.
  2. Kind and honest responses mean that those fears are assuaged, your question is answered.
  3. Other engineers witness the interaction and feel more comfortable sharing their knowledge, being vulnerable, asking questions.
  4. More questions are asked and answered.

And somewhere in that cycle…good company culture emerges, like moss on a stone.

Keep talking and nobody explodes

We have to keep talking to each other, not only to maintain corporate culture but also our humanity. If that sounds a little too existential for you, remember that we killed community with social media, then killed social media. Talking to a person is being replaced by talking to a simulation of a person: and the more AI you talk to, the lonelier you feel!

So…talk to people. Turn on your camera sometimes. Interact with your colleagues. Push for happy hours, game nights and coffee talks. Go to technical discussions, talk about Elixir or React or open source with your colleagues. Or even just open up your Slack and ask a silly question. Because if you don’t, the robots will win and this world will feel colder and more lonely than it already does.