I'm going to give one of the easy answers that probably a substantial amount of the respondents here can give: programming. Partly the point is to illustrate what sort of answer I am looking for.
One of the main tasks a programmer handles is fixing bugs. Often bugs are discovered because the user has encountered a situation where the program does something undesirable (for instance crashing or giving the wrong output). Usually this just annoys the user and nothing more happens, but sometimes the user reports the error and what they did before it happened to customer support, and then customer support enters it into a list of tasks that the programmers can look at.
The programmers may estimate the priority of various bugs that are reported. This priority can be estimated by various things, such as how commonly users report the bug (or statistically how common it is in logs emitted by the program), how severe it is described in affecting the usability of the software, and how much programmer time it is expected to take to solve it.
The bugs (and other tasks such as features) etc. are then assigned to programmers in the team based on things like familiarity with the parts of the software (often programmers mainly work with only one part of the programs they make), and the programmers work to fix them.
Typically the first step in fixing a bug is to reproduce it, so we know how to tell that it has been correctly fixed, and so we can inspect the program while it runs to figure out why the bug happens. The programmer may try to follow the steps that the user described in order to reproduce the bug, or they may use their knowledge of how the program works to infer different ways of reproducing the bug. If they cannot reproduce the bug, they may decide not to fix it, or send questions back to the customer to get more info on how to reproduce it.
In order to understand how the bug happens, they may read the code to see if they can deduce the rules that caused the bug. They may also run the program in a step-by-step manner, seeing how each variable affects each other. At times this can be difficult, for <complex reasons that I'd ideally explain but I'm on my phone right now so cutting it out for brevity>.
Once the bug has been understood, the programmer has to come up with a fix. Sometimes fixes a simple, e.g. changing the code to eliminate a silly programmer mistake. Other times the bug originates inevitably from other logic, and one has to break that other logic to fix it. The bug can also occur due to missing code, e.g. maybe only a special case was handled in the past, but now a more general case should be handled.
The fix must then be written into code, which involves a bunch of complex problem solving that I'm not even sure I know how to describe in non-technical terms. It's pretty important though so I should probably return to it after I'm off my phone. (Or if you feel like describing it, dear reader, I would encourage you to do so in a comment.)
Often programmers will also write a piece of code that can test the fix. This means that over time, the project can end up accumulating enormous numbers of automatic tests. And that's the next step: typically after a change is made, all the tests are run to ensure that nothing breaks.
Before the code is made a permanent part of the project, typically other programmers on the team will look at it and give comments on how to make it easier for them to understand, how to make it faster, and so on, such that the final code is reasonably good.
While doing all of these things, programmers typically have to manage a lot of technical things. For example, if the programmer is working on a web app, then the web app is typically run by multiple programs that work together. In order to run the app to e.g. reproduce a bug, the programmer may therefore need to configure the different pieces so they know how to find each other. Often configuration is partly handled by automatic tools, but these tools are often buggy and the programmer has to know how to navigate around those bugs.
This isn't a complete description of what programmers do, rather it is a description of one slice of programmer work (solving bugs).
I'm not sure a single human brain can hold that comprehensive of a picture at once? If it could we wouldn't need all those channels. The whole point of markets is that they make that process work mostly invisibly to each of us.
For the house example, if I'm a buyer my budget usually isn't something like "$500,000." It's more like "$100,000 plus $2500/month." Depending on loan terms that could mean a $600k house or a $300k house. The seller determines the listing price, but the buyer decides whether to bid. So a general change in loan terms across the population can mean I bid on the same house at up to $300k or up to $600k. Which, in turn, means that as interest rates go up, sellers drop the price to get a sale at all, or get a sale in a reasonable timeframe. Even if I'm a builder and nothing affects the builders costs at all and the production cost stays fixed at $200k, I'm going to be a lot more aggressive about hiring more crews and buying supplies and equipment if I can net $400k per house rather than $100k per house. It's less risky: If the successful projects have a 200% ROI instead of 50% ROI, I can afford to borrow to finance up-front expenses for more projects at once (relative to my existing assets) without worrying about paying them back even when some of my projects fall through. In practice, it's a bigger effect than that, because lower borrowing costs for homeowners tend to also correlate with lower borrowing cost for builders. Also because the same effects ripple through from the earlier parts of the value chain, affecting borrowing, hiring, and scale-up costs in mining, forestry, metallurgy, factories making machines and tools, factories making parts and semi-finished materials, all of it. Alternatively, or concurrently, if people can afford to pay more because of loan terms, a builder may decide to build bigger and more luxurious houses if that gets them better returns. Plus, existing homeowners are more likely to renovate and hire contractors when they can finance it cheaply while they get a windfall in the form of home equity as the market price grows.