Why “Bikeshedding” kills so many AI projects
And what to do about it
Bikeshedding is the tendency for groups to spend disproportionate time discussing the trivial while leaving important matters unattended. It comes from a fictional story of a nuclear physics committee spending more time talking about the colour of the power plant bikeshed than the plant itself - presumably because everyone felt more comfortable debating shades of red than the nuances of uranium enrichment.
We’ve seen bikeshedding stall or even outright kill AI projects time and time again. Why would groups waste so much time on the trivial when we can clearly see glaring issues with our most important asset? Resisting the pull of the bikeshed is harder than you think.
The appeal of the trivial
Bikesheds are dangerous because they tend to be adjacent to things that actually matter. Take the choice of logging software - a bikeshed that we’ve heard time and time again. Logging all inputs and outputs of your AI system really does matter, which is why it’s step 4 in our “How to build AI that actually works” playbook. So what tool should you use? Langfuse, LangSmith, DataDog…? We’ve seen teams go back and forth, extensively researching each option.
Meanwhile, they haven't collected a single labelled example for their evaluation dataset and are nowhere near creating something of value for a single person. We’ve seen multiple companies spend seven figures (I wish this was an exaggeration) designing, debating, and constructing the AI-project equivalent of a pristine bikeshed with little else to show for it. It's painful to watch.
Here are a few more examples we’ve seen over and over again:
Which LLM framework should we use?
How should we structure our code repository?
Which cloud provider should we use?
Which project management tool should we use?
Which tool should we use to manage our coding environments?
All of these matter. However, they’re the wrong questions to ask because they all have the same answer: quickly choose something standard1 and move on. Here are the questions your team should spend time on instead:
Who are the domain experts that will help us define what “good” looks like?
What is the minimum we need to build for our system to become useful?
What is our tolerance for errors?
How can we break down this task so that it’s easier for AI to solve?
How will this project deliver a measurable ROI?
These are tough questions. They don’t have straightforward answers, and given the pace of AI there aren’t yet established best practices. At Artanis, we’ve made some headway on a reproducible methodology to answer these, but we're far from having it all figured out.
Bikeshedding isn’t confined to AI, of course. Only last week, our team had a lengthy conversation about health supplements. We talked about the full spectrum - creatine, omega-3, whey protein, vitamin C… what to take, when to take it, and how much to take. After the conversation moved on, someone casually mentioned that their bed frame is broken and they hadn’t slept properly all week. This was the health equivalent of debating the size of the bikeshed windows while the power plant burns down. We confuse these discussions with working on our goals, which allows them to slip by unnoticed.
Why are AI projects so susceptible to bikeshedding?
While bikeshedding is common in many walks of life, there are a few key factors that make AI projects particularly susceptible.
The allure of complexity. We all love to feel smart, and nothing says "We’re doing serious AI work" quite like an architecture diagram outlining your multi-modal RAG pipeline with hybrid search capabilities, leveraging dense vector embeddings with sparse retrieval for semantic understanding. But have you spoken to a user yet?
The rate of progress. AI has “changed the game” so many times that even Theseus must be losing count. Teams worry they're building on the wrong foundation, causing a lot of anxiety. This anxiety drives endless research and demos that plug into the current flavour-of-the-month. It’s imperative to cut through this noise because the foundations endure: who will use this, what problem are we solving, and how will we know if it's working?
Venture capital. Since AI has undeniably huge potential, lots of investor money has poured in. If this isn’t handled responsibly, it allows companies to spend years creating a beautiful bikeshed, safely insulated from the market's more immediate judgment.
These factors create a perfect storm for bikeshedding in AI projects. Now what?
What to do about bikeshedding
The good news is that once you recognise bikeshedding, you can take concrete steps to limit its damage. Here are three strategies we recommend:
Measure what matters. The most powerful antidote to bikeshedding is a ruthless focus on meaningful metrics. Bikeshedding thrives when teams aren't held accountable to the outcomes that actually matter. Defining success with vanity metrics like features built, latency, or the elegance of your code can make it feel productive to re-paint the bikeshed. Instead, relentlessly focus on what matters: usage, retention, and ultimately your business’ revenue and costs. This can be a harsh wakeup call.
Allocate one decision maker. You do not need a committee to come to a unanimous decision about the choice of your logging tool. A single decision maker should listen to others, but have complete authority. If someone else on the team kicks up a fuss about not getting their way, this is a red flag. A competent team member adapts. If they can’t bear working with one tool and insist on using another that’s effectively the same, they’re actively damaging to the team.
Normalise not sharing an opinion. If someone asks you, “What colour should we paint the bikeshed?”, it can feel extremely rude to reject the question. It feels easier to briefly and decisively reply “green”, but this doesn’t work. You’ve now engaged the conversation and risk getting pulled down into the rabbit hole of trivial details. “What shade of green?”, “Matte or glossy?”. Before you know it, you're in a two-hour Slack thread about whether sage green conveys the right message. A better response is “I trust you to make this decision. Let’s move on”.
Don't beat yourself up when you catch yourself bikeshedding - simply notice it, then redirect your energy.
Making Peace
If this post catches you at the right time, it may feel like a punch to the stomach. Let me offer some respite: some amount of bikeshedding is ok. The goal isn't to eliminate these conversations entirely - it's to recognise them for what they are and limit their damage. Some amount of bikeshedding is healthy, as working on the most important thing 100% of the time just isn't realistic (also, you'd probably have a nervous breakdown). Instead, I prefer to think of bikeshedding as adjacent to leisure; a way to decompress from the uncertainty and difficulty of real work.
Once you've acknowledged that your team spends some time bikeshedding, you may find it's more productive to allow for proper rest rather than working on the trivial stuff. If so... great! You just gained free time AND a productivity boost. By acknowledging its pull, you can make sure it’s a deliberate decision, rather than unconscious avoidance.
After all, a well-architected bikeshed really is nicer than one that’s been hastily thrown together. Just make sure the power plant isn't melting down first.
Y-Combinator have an excellent video about innovating on the wrong things