> I recently encountered a query that deadlocked on itself because it used a parallel execution plan and updated multiple indexes in a manner that the different threads could conflict with each other.
MS SQL?
We've had to set MAXDOP 1 on some specific queries for a long time.
> A biological synapse's weight takes effect whenever its input changes.
I don't think it makes sense to try to compare our brains to ANN's, they are apples and oranges.
A synapse's weight is dynamically modulated by the astrocyte on multiple time scales (millisecond, sub-second, minutes), and the astrocyte itself is receiving inputs and performing computation (in addition to impacting the neural network).
> I don't think it makes sense to try to compare our brains to ANN's, they are apples and oranges.
It makes perfect sense to compare them. There are clear similarities in the style of processing. And I rarely, if ever, see people over interpreting comparisons.
--
The above insight: That convolution in a model has a not-the-same but still related relationship to living neurons isn't nonsense. In both cases, parameters are not just being used once in a given short-term response, even though the specifics of reuse are different.
And the relationship can be stronger: There is a lot of evidence convolution does effectively happen in the brain, via similar operations occurring across a region of similarly organized neurons, instead of via "reused" neurons/parameters. I.e. lots of regularity in the visual system's early processing.
Other things I find interesting: Human neurons are very noisy and statistical, but some of that gets smoothed by soma integration. So there is a loose correspondence with the sigmoid function, with biology encoding by frequency instead of amplitude.
Also, the branched dendritic trees of live neuron's are not passive, they can have apparently active aggregation points. Which makes a human neuron more comparable to a neuron with multiple feeder neurons. I.e. a very small two-layer net. And it adds the possibility of tunable "parameters" within the dendrite tree, in addition to synapse strengths.
The contrast of gradient algorithms, vs. whatever algorithms human cells learn with, is really interesting. We know a little about how one neuron learns, but not much at all about how organized neurons learn together. In this case, comparison is fruitful for the contrast it highlights.
The biological neuron as a little-two-layer net model, suggests that perhaps learning operates at multiple levels in a single neuron. I.e. "two-layer" learning rules.
Ya, I just started using them in File Explorer recently and I really like them because I frequently had multiple windows open within the same tree, this is much cleaner. I can't believe it took me so long to actually click the "+" and try it.
We were working through many complex business flows and running into exactly what you describe in many areas. Some of the project people with less experience complained that we were spending too much time on exceptions and slowing down the project. We had to explain that when each exception happens 100 times a day with significant impact on business productivity, then it doesn't matter whether you call it an exception or not, it's important to solve for.
> But I don’t think we should be calling these people “domain experts”. I think we should reserve that name for the other group, for the people who truly and deeply understand the domain, the whys and whats and why nots.
I've spent a lot of time in my career extracting info from the business and I think most do understand the whys/why nots but aren't practiced at organizing all of those decades of experience into a higher level abstract model that can easily be communicated.
It's typically layers and layers of information with dependencies in many directions littered with exceptions. Just like our software design+dev experience, it takes a lot of practice to try to organize all of that info into a coherent presentable model.
> It's very difficult to define a specification that works as intended, even with tools.
Agree, we are in the stone age in software design and dev. We have not figured out a good way to communicate the design of complex systems in a way the business can understand.
Nope; this is just a silly trope which gets repeated without thought. The fact that it is hard to do does not mean we don't know how to do it.
Everything exists and was known from 1960s/1970s. People are just not studying, adapting and using the well-known standards/techniques. Standard Engineering is built on them and Software Engineering adapts/extends those for its own needs.
Those example are exactly the problem that has not been solved yet. They are the best we can do so far but are pretty inadequate to communicate complex designs in a way that a person can easily absorb all of that info and then reason about whether the resulting system is adequate.
As complexity grows, the value of those artifacts reaches significant limits that are typically dealt with through brute-force mental effort of the people involved.
The above resources are not examples but methodology/process using various techniques to produce various artifacts which specify the requirements unambiguously. It is up to the practitioner to choose his techniques and use the methodologies (tweaking as needed) in a systematic manner to convey the requirements to stakeholders for approval.
Lots of complex systems have been built and understood using the above. As system complexity grows, doing the above is even more important even though it be hard.
> Seems like tacit acknowledgment that IBM mothership is not the right place for a speculative growth play from both a management and capital perspective.
I'm not understanding your logic, can you explain?
What I see with the program and amounts companies were awarded is some level of acknowledgment of the current state of quantum research (i.e. IBM is generally considered the leader) and their pragmatic approach that piggy-backs on current technologies (for obvious speed+cost benefits).
You must not talk to competent people. IBM is very experienced at this grift. I remember when I used to go to conferences in a different field and IBM would announce "state of the art" results that were very obviously done by cheating (making an ensemble model and tuning the weights on the test set). Everyone doing real work would ignore them, and then they'd go sell to clueless midcap companies on the basis of that announcement.
> And then, a follow-up: what is actually the bottleneck at most companies? What causes "requirements gathering" to take long?
Complexity.
In my experience (medium size businesses, i.e. 200 million to 2 billion annual revenue) we're trying to understand how a complex set of systems and business processes and different businesses (external partners) interact and then trying to morph all of that into a shape that now has capability X layered on top or in the middle.
Here's a concrete example, business X that makes their own products and has retail stores as well as an ecom site wanted to add the ability to put complementary items built by other companies on the website and have them drop shipped from the vendors to the consumers. The final solution involved 21 different interfaces between 4 different systems (ecom system, store system, omni channel system, external drop ship mgmt system) as well as a new internal system to manage this activity. It's takes a significant amount of time to understand and solve for all of the low level details.
A typical example of trying to add a new significant capability involves many meetings (days, weeks, months, etc. )with the business to understand how their work flows between systems X, Y and Z as well as all of the significant exceptions (e.g. we handle subset A this way and subset B that way, but for the final step we blend those groups together, except for subset C which requires special process 97).
Then with that understanding comes the system solutioning across multiple systems that can be a blend of internal system or vendor's system, each with different levels of ability to customize, which pushes the shape of the final solution in different directions.
There is certainly value in speeding up coding, but it's just one piece of the puzzle and today LLM's can't help with gathering the domain information and defining a solution.
What I've seen in an AI-forward looking environment is that it's much more common for PM/POs to be knocking up at least a UI prototype now, and experimentation is happening often even before writing the tickets. Similarly when devs are proposing something they often are coming with a couple of prototypes already implemented. Both of those mean decisions are coming a lot quicker.
I wouldn’t discount the value of moving small tasks away from developers, nor the value of fast cheap prototypes.
Product owners can very quickly get, for many problems, an interactive demo without coding. For lots of problems this can be somewhere from a static html page which shows the interactions to a hacked in feature that lets them actually test if it solves the customer need and try several variations before handing over much more concrete specs of what they want to happen. So much time is lost between getting an idea from someone’s head to code to use to then find out it wasn’t communicated well and then finally that the idea didn’t help anyway and we want it in a different way.
Yes yes I know someone is about to say that now there’s pressure to push the prototype out but that’s an organisational level problem that existed anyway.
And small problems can much faster to solve as well, or even move away from devs. Often people just need some text changed somewhere or html putting together, or some basic code for analysis. They could understand the logic, but the task of writing it from scratch and how to run things may be too much - now you don’t need to prioritise work for a dev to get some sql written and they can spend their time on the larger more software engineering level problems.
"that’s an organisational level problem that existed anyway"
That's very true to many organizations. One cannot just slap an AI tool on it when you are dealing with fundamental organizational problems in the first place.
"they can spend their time on the larger more software engineering level problems"
For sure, devs still needs to focus on the right type of work and maintain the balance. I built a tool to just do that: https://worktypefocus.com/
I've seen proposals for Product Managers to define those conditions themselves by speaking with the LLM. A continuing architectural diagram is constructed and graph is updated until all cases are covered and then the LLM writes the code, writes the validations, pushes to CI environments, runs tests, schedules prod deploy (by looking at company event schedule), gets CAB approval, deploys code, tests in prod, and fixes regressions.
I'm not saying this is the correct thing, but companies are implementing it and it is "working". I don't think keeping our head in the sand is helping.
> I've seen proposals for Product Managers to define those conditions themselves by speaking with the LLM.
But the LLM is not aware of how the business works and why, so someone needs to work with the business to extract the information. Typically it's not well documented.
> someone needs to work with the business to extract the information. Typically it's not well documented.
LLM extraction of the information from the Product Owner is becoming the way to overcome poorly-documented business context.
Non-technical folk are using things like `/grill-me` [0] to seed the LLM with the long-tail complexities that they didn't know they didn't know they needed to put out.
They can ask, they can do a back and forth and they can write documentation to be used from that point onwards and write it in a common style and structure.
These are language models, being able to talk through something with them and have them extract some information is what they excel at. Given that you’d probably get a halfway decent result with a literal fixed set of questions (an Eliza level docbot) gpt 5.5 is going to nail that as a task.
is it working though? The main outcome we've seen with companies that drink the AI Kool aid en masse is buggy unstable systems. clearly there's a level of rigor that's being missed for ship velocity
MS SQL?
We've had to set MAXDOP 1 on some specific queries for a long time.
reply