The bad news

In January 2026, two pieces of news started to cause some panic in my bubble. First, a Laracasts employee posted about his layoff, then the next day a Tailwind Labs engineer. Which was later also confirmed by one of the key members of the framework, Adam Wathan in a comment under a Pull Request, and later in more detail in his podcast. Because it's the beginning of the year, a lot of business owners look back at year and run forecasts for the following to set the direction.

They both mentioned AI as a dominant force of this change, but not that because AI models will replace software engineers. In Laracasts' case, since AI tools became popular, people have started to watch fewer videos about how to build things, as they can now an AI agent to do so in plain English. For Tailwind, the causes are similar: models can write components quickly, and because they're trained on documentations, their visitor numbers have declined by 40%. A very similar drop to what Stack Overflow has to suffer nowadays. Just to clarify the numbers in both layoffs: we're talking about 3 of 4 engineers at Tailwind and only one staff member at Laracasts, which means we're certainly not talking about the scale of what Microsoft or Amazon done recently.

Last year GitHub reported almost 395 million open source repositories, with tens of millions of new projects created annually, while the survival rate is less than 50%. Many projects are short-lived or abandoned early, only 15–20% show ongoing maintenance. A small fraction are financially sponsored and thousands receive GitHub Sponsors support, but that's a tiny share relative to the total number of projects.

Maintaining open source projects can be exhausting. The internet is full of annoyed people, they're always demanding, suggesting and get pissed when things don't go in the same direction as they want to see. You go to sleep with one bug and you wake up to 10 more. Or just a bunch of PRs as part of Hacktoberfest where people trying to get free merch by changing your README file. Or security issues where a "good samaritan" messages you privately, but threatening you paying some ransom unless they go public with a backdoor. In more positive cases you might just switch off half of the internet. I'm seriously not surprised so many people give up, because it's exhausting both timewise and mentally.

The good news

Tailwind CSS is a very popular project. However, as Adam posted on GitHub, financially that's still not enough to build a successful product company around it. A close example where this was possible is Laravel, which was already in good shape with Envoyer and Forge before they raised $57 million Series A.

His frustration is absolutely valid. He raised his concerns about the future in several places over the year, with no real direction in sight. Although since he posted his podcast episode on 7th January, they have already grown to 29 partners, 4 ambassadors and 26+ supporters, which totals in at least $168k MRR as today, over $1 million annually. It sounds amazing, but I'd rather wait and check these numbers again a year later to see how many of these individuals and companies were just doing "karma farming".

What's next?

Giving up

If things don't improve permanently they might abandon the project and make millions of developers instantly upset and disappointed around the world. I can't accept that this is the outcome Adam is personally looking for, however he's frustrated sometimes. They could also leave the repo unmaintained, allowing people to fork it, and slowly new branches would emerge from the ashes of Tailwind, but that would cause awkward fragmentation problems. At the moment, Tailwind feels like a common good, which is great for open source, but also sad when an idea that might be the biggest achievement of your life doesn't generate enough to chase even bigger dreams. A lot of entrepreneurs, writers, and creators are stuck at this stage, and I can imagine how frustrating it can be.

More funding

My second thought was that people would realise the situation is serious and that a lot of donations would start coming in over the next few weeks (and I was right!). Maybe more big companies will also realise this and allocate a percentage of their profit to fund the development for the coming years. But let's be real: this is only a temporary solution.

New products

They could introduce a new marketplace for Tailwind plugins and components, similar to what ShadCDN is doing, but the direction the software industry already suggest we might not need components in the future, since AI models can come up with their own in minutes. They're trained on documentation, blog posts and articles about Tailwind which would certainly raise proprietary questions if we were talking about paid product. But being open source puts this area of laws into a "fair use" grey zone. While opinionated frameworks and plugins are useful and their existence results in higher quality LLM generated code (since they're giving predefined boundaries to the context) I don't believe that theme marketplaces have a long future.

A natural move could be to introduce Tailwind-related paid products or official plugins, just like WordPress did with Automattic and its paid plugins, or as I've already mentioned, Laravel with Forge, Cloud, Nightwatch, and a bunch of other services. An official Tailwind-built AI service or model that can generate intuitive and modern web designs or themes using Tailwind components would be an instant hit and could massively transform the theme market. Don't forget: they also have both authors of the Refactoring UI book in the team. Although after the layoff, it won't be easy to build these products with a smaller team.

Acquisition

My last theory is that a big tech company or startup (someone like Vercel) suddenly appears and gives Adam and the co-owners a bag of money, takes over the burden of maintenance, maybe full ownership through and acquisition, and they either stay on the board or fully exit. It might sound like a failure, but I actually think that would be a very beneficial outcome for Adam and his mental health. I don't think he should be ashamed for even a minute, considering the accomplishments he's achieved over the past decade (not just for Tailwind), and I'm sure that if he were able to drop this ballast and start from scratch, he would eventually come up with a fresh new idea.

Final thoughts

Whatever happens, I think the main conclusion here is that if you're a developer working whether in a team or alone, and your work or products are heavily based on free, open source packages, frameworks or tools, don't forget to support them when you are able to afford it. It doesn't necessarily have to be money. It could be a PR for a bug fix or improving their documentation, but giving back something should be an obvious move since the first open source package appeared.

This is one of the main reasons that starting this year, I'm officially backing the PHP Foundation as an individual.

This was the reality before the global pandemic, which completely changed the game. After COVID-19 the UK government invested heavily in bootcamps to help upskill people during uncertain times. However, this led to higher dropout rates in bootcamp courses, as many signed up for free and weren’t truly committed since they weren’t paying anything. Hiring also shrank to basic levels, and the job market still hasn’t fully recovered today.

The pandemic accelerated digital adoption, but economic challenges — including inflation, rising interest rates, and supply chain issues — caused a decline in consumer spending and mass layoffs, particularly in 2022 and early 2023. As a result, hiring decreased significantly for bootcamp graduates. Therefore, when starting a bootcamp, don’t expect to land a job immediately, and be sure to consider the financial commitment. It may be wise to prioritise free courses over paid ones.

With the arrival of ChatGPT, Google Gemini, Anthropic’s Claude, and Facebook’s Llama, generative AIs have also transformed the job market. The positive impact is that many companies are investing in AI technology and hiring more people to explore its potential. However, many of these companies are unnecessarily chasing the "holy grail" by forcing AI into their products, focusing on trends rather than applying AI to the right use cases. Trends come and go, and we’ll see in a few years if AI was truly worth the bet. As of today, 85% of AI projects fail, with a lot of them sadly being scams designed to attract investment or profit from preorders before disappearing with the money or at least hesitating to refund.

AI-driven automation has rapidly taken over routine jobs as well. Therefore, it’s important to consider how much it affects bootcamps and junior developers. Using AI as a developer shouldn’t be an inexcusable sin, regardless of what the same people who back in the days were skeptical about the need for a global network of interconnected computers, but, like anything else, it should be used wisely. Mike mentioned that they teach bootcampers in a smart way. It’s not forbidden, but they encourage using AI for code generation only when the developer has already written something similar before. If you ask AI to generate code for something you don’t understand, you might end up shipping insecure or inefficient results due to hallucination and the AI’s tendency to produce responses aimed at satisfying you rather than being accurate. AI is still not advanced enough to steal people’s jobs, and it probably never will be (at least not in your life).

I’ve been using Copilot for the past 8 months, and although my experience has been mixed, I’ve found a perfect use case where AI can be really powerful: learning new programming languages. It helps explain what a certain line of code does or provides examples of how to write the same code in different languages or frameworks, which has saved me hundreds of hours spent on Google and reading through manuals. It’s still not something I can blindly trust, but since I’ve mostly worked alone over the past year, it’s been useful for pair programming with a junior-mid level virtual assistant. It has often offered different perspectives on problems that I hadn’t considered. However, for higher-level design architecture decisions, I still recommend reading books on the topic, even if your AI of choice has read and can summarise them. My issue with services that extract key parts of a book is the lack of context. Authors aim to engage readers, and important concepts sometimes require a broader context. Additionally, reading has numerous benefits, such as improving focus, expanding vocabulary, and reducing stress.

If you’re planning to start coding, go to YouTube and check out some introductory videos. Read a few articles in the topic, apply some short and free online courses and see if it’s something you might genuinely be interested in. There are many people who complete coding courses simply because the media has told them that anyone can become a coder and make a lot of money. However, speaking from my own experience as a middle-aged father looking for projects and jobs just to cover my bills and go for holiday once or twice in a year that’s not necessarily true.

Once you’ve gathered all the information and still want to start your journey as a programmer, don’t spend years in school (which I also skipped). Instead, consider enrolling in a free bootcamp and stay curious.

Where to start?

• Find Skill Bootcamps at National Careers.
• Course Report is like GlassDoor for courses, what’s not on there you should probably avoid it.
• Bootcamp Academy in Bath put a lot of effort to give you up-to-date skills, and they're focusing on the basics of programming rather than languages and frameworks.
• Codebar.io is a platform for minority group members to learn programming around the UK.
• Code Academy offers free online courses to test our your interest.

Turbo is a JavaScript framework to create progressively enhanced web applications. The way it achieves that is by capturing every link click and form submission, changes all to AJAX requests, then extracts the body from the response to replace corresponding parts of the existing page. It does that without affecting the head tag and requiring a full page reload. Behind the scenes, it also manages the browser's back button functionality and stores the history of full body contents in a cache. Additionally, Turbo also supports requesting and fetching updates through WebSocket, not just XHR.

Turbo is the heart of the Hotwire framework which contains a couple other frameworks like Stimulus and Strada to build native-like Single Page Applications (SPA) without using any progressive frameworks like React or Vue, and all templates are generated on server-side.

It is the similar technique what Laravel LiveWire implemented, which was also heavily inspired by an Elixir module called Phoenix LiveView. Other implementations are also available out there like htmx or Inertia.js. Unlike LiveWire, Hotwire doesn't require any backend framework.

What is TypeScript?

JavaScript was originally never intended to be a programming language, certainly not for large applications. It was born as LiveScript, a scripting language thanks to a collaboration between Netscape and Sun Microsystems to embed Java into Netscape Navigator in 1995. That's also the reason for its later renaming, because of its syntax similarities to Java. When the legendary browser wars began between Netscape and Microsoft, the latter reverse-engineered Navigator's interpreter to create their own variation which they named JScript. A year later, Netscape submitted JavaScript to ECMA International, an organisation founded to standardise computer systems. The intention was to create a standard which could all browser vendors adopt and that finally led to the official release of the first ECMAScript specification in June 1997. JavaScript in the beginning didn't really have structuring concepts you would normally find in other programming languages. These deficiencies made very difficult to build reliable large-scale applications.

TypeScript is a programming language built on the top of JavaScript (or as they refer themselves a superset of JavaScript) introduced in 2012 by Microsoft, mainly to resolve those concerns about large-scale development. Aside to static typing and type checking at compile time, it also introduced classes, generics, visibility, union types, enums, modules and namespaces which all helped to elevate JavaScript to a higher level. TypeScript code is backward compatible with JavaScript, which can be compiled into regular JavaScript, then it can be executed in a browser's JS engine or in server-side runtime environments like Node.js.

Here's an example of a simple TypeScript code:

class Car implements Vehicle {
    private brand: Brand;
    private model: Model;
    private year: string;

    constructor(brand: Brand, model: Model, year: string) {
        this.brand = brand;
        this.model = model;
        this.year = year;
    }

    getTitle($withYear: boolean = false): string {
        if ($withYear) {
            return `${this.brand.name} ${this.model.name} (${this.year})`;
        }

        return `${this.brand.name} ${this.model.name}`;
    }
}

You might love or hate TypeScript, but you cannot really find a job where the tech stack doesn't require TypeScript in pair with JavaScript, weather it is server or client side programming. JavaScript also evolved in the past decade, and today it has features which were only available in TypeScript before:

• Class keyword and modules have been introduced in ECMAScript 2015 (ES6)
• You can emulate enums using object literals or constants
• JSDoc annotations can provide type hints for better tooling

Strong or weak vs. dynamic or static

Type safety is a feature of a programming language which simply means the language only allows you to perform operations allowed by a data type. For an example you shouldn't use a method which requires a string on a numeric value. This permission is checked during type checking which can be static or dynamic. Dynamically (or weakly) typed languages check the types during runtime, meanwhile statically (or strong) typed languages usually does the same through compile time. Not all languages are need to be compiled before runtime (like PHP, Ruby or Python), those are called interpreted languages.

JavaScript itself is weakly typed, which means its type system is more permissive and allows for implicit type conversions and late type binding. Type violations might not be caught until runtime which may lead to unexpected runtime errors. Languages like PHP, Ruby and Perl are all weakly typed.

On the other hand, with strong typing every variable and expression has a fixed data type that is determined at compile-time. Type violations are caught at compile-time, which means that the code must stick to the specified types, and any mismatch will result in a compilation error. Examples for strongly typed languages are Java, C, Smalltalk or Pascal. Python however is both strongly and dynamically typed language.

TypeScript is also strongly typed and because it's compatible with JavaScript we can enforce type checks on our code during compilation. As I've already mentioned PHP is dynamically typed, and we have no options to force type checking. Although, it offers features like type declarations and type hinting which can check types in runtime if we specifically ask it to do so by adding declare(strict_types=1). Static analysis tools like Psalm and PHPStan can be also very helpful by going through on our codebase without actually running it and catch possible issues caused by typing. Those tools can also benefit any additional details specified in PHPDocs, mainly because PHP's native typehints are still not perfect.

We can compare the previous TypeScript example with a PHP implementation and see the code is very much similar:

<?php

declare(strict_types=1);

class Car implements VehicleInterface
{
	public function __construct(
		private Brand $brand,
		private Model $model,
		private string $year,
	){
	}
	
	public function getTitle(bool $withYear = false): string
	{
		if ($withYear) {
		   return "{$this->brand->getName()} {$this->model->getName()} ({$this->year})";	
		}
		
		return "{$this->brand->getName()} {$this->model->getName()}";
	}
}

There are also other ways to work around typing. Duck typing is a method of type checking that looks at the structure (properties and methods) and the functional aspect of the object rather than its name or class. If it walks like a duck and talks like a duck, we treat it like a duck, even if it's not.

People who prefer dynamically typing generally highlight the flexibility, reusability, faster development speed, and a better flow, which were also the same arguments that DHH came up with in his post. Others favour catching bugs early, ensuring safety, reliability, benefiting from additional type information in the code and better IDE support, even if compiling is a slower process or strict typing could affect readability.

"You don't need static type checking if you have 100% unit test coverage." by Robert C. Martin

Personally, I believe there isn't a good or bad choice here. Like many aspects of software engineering, it's about trade-offs. Whenever it's possible I always enforce strict typing in PHP and use static analysis as part of continuous integration, because it helps me recognise what the code accept and what's expected to be the outcome. However, I cannot really appreciate enough that PHP is dynamically typed language.

Transitioning from your first computer language to own the mindset of an engineer can be difficult, frustrating, and often a tediously long procedure. You can always find shortcuts, practice through days and nights, but even with the toughest, most nonsensical parts, you cannot predict when things will click. But eventually, they will.

My journey began with a national program that brought free broadband connectivity to high schools in Hungary. I was so much mesmerised by the information highway that on some days, I just couldn't go home after my classes. I spent afternoons in a lonely basement where we ran the school's web server on an i486, building websites or simply chatting with unknown people from around the world. In 1998, I stepped into the era of Netscape Navigator, Hotmail, and various Telnet applications. I started with HTML, and later, someone showed me how to capture and process POST requests using Perl.

A couple of years later, PHP 4 arrived into my life, followed by Postgres, MySQL, and my first CMS / framework called Typo3. However, programming was still just a hobby for me. I found more confidence in designing websites. A decade later, in 2008, I learned a golden rule: you can't be perfect in everything.

This is one of the things that companies often misinterpret: the term "full stack". It doesn't mean you have to be equally great in frontend, backend, and devops; it means you have the right skills to navigate through the common obstacles of web development. It means having the ability to build and ship a product or application from scratch, even if the end result isn't necessarily perfect. Perfection is a programmer's holy grail, something we often strive for it, but can never reach it. Simply because it doesn't exist. There's no perfect code—only code that is safe to be shipped because it gets the job done. The evolution of software is a natural part of the process and is equally important as the personal growth of the person who writes it. More knowledge and experience make you think smarter and faster, reducing the amount of fear of the unknown.

Returning to my story, I realised the need to specialise. I accepted that I couldn't be equally great in all areas, but I enjoyed writing HTML and CSS, you know making Photoshop layouts alive, so maybe I could call myself a site builder.

From 2013, my unique skill set was PHP, although I learned it the hard way: fake it until you make it. But it made me fall in love with backend programming and introduced me to concepts like dependency injection and the repository pattern. With CodeIgniter, Laravel and Yii, I arrived in a perfect time to be witness of the language's resurrection. After introducing the PSRs, the history of modern PHP evolved rapidly; they even skipped PHP 6. Later, I was pushed to learn new things about frontend (jQuery, ES6, React, Vue), with detours in mobile and desktop application development, then SaaS, microservices, CI/CD pipelines, serverless architecture, infrastructure as code, design patterns, SOLID, DRY, YAGNI, TDD, and BDD—so many things that my brain needed more time understand. Some started making sense within a month, while others took a year more to click. Today I'm no longer addicted to Laravel, and I seize every opportunity to try out languages other than PHP.

What I'm trying to tell you through my story is that you must always remain open and hungry. Don't stick to one framework or one language. Learn the basics, variables, loops, control structures, and data structures. Learn from the mistakes or journeys others have made: design patterns, software paradigms—programming is a flat circle, everything else are just SDKs and APIs to memorise. Read about algorithms, how to be more effective or improve performance. There's nothing new under the sun, just better tools which are naturally faster, perhaps a bit shinier, but the foundations are always remain the same. Some are better suited for the task, while others are less. Invest enough time in learning everything about your task, inspect any inherited code, then make the best decision about tools, architecture and approach based on all the information you have.

Prioritise simplicity over complexity, focus on input and output, try, fail, and then try again. Once you've learned these things, you're no longer just a full stack, ninja or 10x developer. You're a software engineer armed with the right tools and mindset to do the best you can: write software.

Our app got built on spaghetti code, so need to be ok with that.

From the top of my head I could think of two reasons why this detail was highlighted:

1. They want to manage your expectations. Most developers hate to work with spaghetti code. The mess is usually the result of unmaintained code debt, frequent changes in features, developers coming and going and deadlines are often tight.
2. They are looking to hire people with extensive experience (or enough patience), as the readability of a spaghetti code is typically very low. That also comes with a lot of stress and creates the opportunity to introduce new bugs anytime, which in overall can easily lead to burnout.

How to approach spaghetti code?

First of all, let's call it by its real name: legacy code. Obviously, anything you write today will become legacy code tomorrow, but from a codebase perspective, legacy refers to what we inherited and might not be comfortable to work with. It's usually difficult to see where the business logic begins and where it ends, which particularly affects confidence.

Therefore, we need a plan to overcome these challenges and make some preparations about how to tackle any upcoming problems. A proper plan should create enough room for improvement.

Before touching any line of code, you need to have tests first. Not necessarily at the unit level, but at least integration tests to ensure the code is doing whatever it supposed to do. If you're dealing with web applications it can be simple tests running in a headless browser, checking the output, or more programmatic tests to validate certain methods in the background which calculate or generate things are just working fine. Although tests could be hard to write when your code is tightly coupled. If you don't have any tests, certainly don't try to write all in one go, but targeting any main features should be enough.

Once you have tests, you can begin with refactoring. Instead of randomly choosing where to start, let your tests guide you. Think about the parts of your code where writing them were especially challenging - that's your first task!

The cost of refactoring

“But how can I sell this to my manager? We don't have time for this. This would take ages, and time is money!” Familiar thoughts? I was in the same shoes at some point in my career.

Understanding the problem of legacy code and recognising it as part of the development process can be extremely difficult from a business perspective. It may seem like you're not generating value and you're just rewriting things that already work. Do you and your manager have full confidence that they are working properly?

If you're logging bugs in JIRA or any ticketing software you should be able to generate a report on these issues could be resolved by rewriting the code from scratch, rather than seeking ways to patch them. What's even more frustrating is that sometimes you could spend considerably more time in reproducing bugs than actually fixing them.

Let's look at another example: have you ever felt like there's a ghost in the machine? Things happen, and you cannot explain where or why? Well, good news, you might have an argument. Inconsistency is the enemy of both developer and business. When all parties understand this, you can make a deal: start with small steps. For an example allocate 10% of the main development time to maintenance, then slowly make it a habit and part of your software development process. The same argument applies for writing tests. Without tests, you can only assume that your code works, but you don't have any written proof.

Sadly, this cycle is pretty much never-ending. You might think when finally everything is refactored you can sit back and relax. Of course, your application will continue to generate profit without any further modifications, and you may never need to add new features again. However, eventually, it will be old, obsolete and deprecated. As technology rapidly evolves, it's gradually losing support from the language its written in. Or that third party code (aka dependency) you added to save time will be outdated without a replacement. Then your users will start looking for quicker and more efficient alternatives, and your business will start to lose money.

The break is temporary. It is good for the businesses to slow down a little, generate some easy revenues, and build a passive income for the future. It's also beneficial for developers to catch up, summarise pain points, make plans and decide what's next in line with the business. You can start adding new features on the following day, continue maintaining your code, and forget about making notes in job ads like the one mentioned at the beginning of this post.

Don't just warn, communicate the plan!

We can all agree that the level of transparency in that job description is remarkable, but emphasising the interest, moreover a potential decision for the change would be more important.

You want to hire a developer to maintain your code, not just someone to deal with it.

With all that in mind let's make a quick revision of the original sentence:

Our app is built on spaghetti code, but we're dedicated to improving it through refactoring. To achieve these goals, we're looking for a talented and enthusiastic software engineer who is not afraid of challenges.

And here you are, you have a candidate who's already empowered.

If you let me to use a strictly MVC term in an event driven system WP Query is basically the router of WordPress. Hidden behind the nice and clean permalinks WordPress loads posts and run search queries through query strings. By using s= in the URL like https://myawesomewpsite.com/?s=Geronimo it will search for posts which has the phrase "Geronimo" in their title, excerpt and content.

You can extend this circle to also search in the wp_postmeta table:

<?php
function my_theme_customize_search($query) {
    // Specify the query we want to change: the search in the front-end
    if (! $query->is_admin() && $query->is_main_query() && $query->is_search()) {
        // Change some query parameters
        $query->set( 'posts_per_page', 10 );
        $query->set( 'post_type', ['page', 'post'] );

        // Search in meta values
        $meta_query_args = array(
            array(
                'key' => 'battle_cries',
                'compare' => '=',
                'value' => $query->get('s'),
            ),
        );
        $query->set( 'meta_query', $meta_query_args );
    }
}
add_action( 'pre_get_posts', 'my_theme_customize_search' );

But the problem is you won't see any results. If you're using debugging tools like Query Monitor you can easily check the generated WHERE clause:

AND (
  (
    (wp_posts.post_title LIKE '%Geronimo%')
    OR (wp_posts.post_excerpt LIKE '%Geronimo%')
    OR (wp_posts.post_content LIKE '%Geronimo%')
  )
)
AND (
  (
    wp_postmeta.meta_key LIKE 'battle_cries'
    AND wp_postmeta.meta_value = 'Geronimo' ) )
    AND wp_posts.post_type IN ('page', 'post')
    AND (wp_posts.post_status = 'publish')
  )
)

See that AND relation between the two condition groups? That should be an OR. If we extended the pre_get_posts with the hook above WP Query will search for posts which has the keyword in the title, the excerpt or the content and in a meta value by a given key which is obviously a very rare match. So, now we understand the problem, isn't just a setting somewhere? Unfortunately not, you are not allowed to change it. Just look for a function called get_sql_clauses() in wp-includes/class-wp-meta-query.php:

<?php
protected function get_sql_clauses() {
    /*
     * $queries are passed by reference to get_sql_for_query() for recursion.
     * To keep $this->queries unaltered, pass a copy.
     */
    $queries = $this->queries;
    $sql     = $this->get_sql_for_query( $queries );

    if ( ! empty( $sql['where'] ) ) {
        $sql['where'] = ' AND ' . $sql['where'];
    }

    return $sql;
}

Most conversations on Stack Exchange mention things like running two post queries and merge the results into one array. Others recommend creating a unique query variable and replace the role of the s= by defining your own search conditions in the posts_where hook where you basically write a different search feature for posts.

My solution

It's basically a hack, but ignores all the overdrawn above. I would basically override the meta SQL query by using the get_meta_sql hook and replace the first and only the first occurrence of the AND relation to an OR. I used preg_replace, because the meta SQL query surprisingly has line breaks in it.

<?php
function my_theme_modify_meta_sql(
    $sql,
    $queries,
    $type,
    $primary_table,
    $primary_id_column,
    $context
): {
    if ( $context !== null && $context->is_search() ) {
        $sql['where'] = preg_replace( '/AND/', 'OR', $sql['where'], 1 );
    }

    return $sql;
}
add_filter( 'get_meta_sql', 'my_theme_modify_meta_sql', 10, 6 );

It might not the most bulletproof option, however unless core developers won't add a filter for it is the simplest solution which saves you from additional a database queries.