> Steadily improving cheap quality you get for the most products

Have you proof read what you wrote? With your lack of specificity for the word "thinking", you're casting a rather broad argument; there is a troubling implications between your words.

* Trust what you're told, consume what you're sold; Do as you're bid, do as you're told.

* Don't question the script, don't step out of line; keep your "snowflake thinking" benign.

* The market knows best, so don't second-guess; Our Ford will provide, just consume and say yes.

Fooooord!^[1]

- [1] Brave New World; by Aldous Huxley

I feel like this issue goes beyond a single large legacy codebase. It can go beyond how the code works into what the code does. How should a thing behave may itself be institutional knowledge only Bary that was involved in the design process still remembers.

Pointing an agent at a problem in one codebase to write a patch can work quite well. But what do i do when the problem is either in the tool, the database, or the two API layers between? You may not even have the code for half of it as it's part of another department or externally purchased solution.

Bary would know, or know who to talk to, or dig up a PowerPoint slide he's been working on to explain it.

Beyond a certain size, the documentation becomes too large to ingest. Below a certain size, it can only contain a fraction of what is needed. If you take any sufficiently engineering project, and give every engineer amnesia; the project will go to shit for a undetermined amount of time, as it takes months or years go build-back the understanding that was lost.

This is clear enough then large companies fire and replace workers randomly to cut costs; a worker that has built up useful knowledge in the origination over a few years is more valuable than three cheap consultants from "low-cost countries" that are fired when the work package is over.

---

AI, looses its memory every time we press "new thread". No spec can bring that back until AIs become able to write and ingest whole books of context without getting confused.

It may actually be illegal in US law for Apple to leave the UK market for ideological reasons. Public companies are beholden to shareholders and can be sued for not acting in their interest (fiduciary duty, Delaware General Corporation Law). (I loathe these laws, but that's a separate discussion entirely.)

So sure they _can_, but at a cost that strikes the option from the cards entirely.

We don't want it the other way around; companies placed outside the borders doing and selling whatever they want without a care. So we end up in a negotiation.

Apple choose to maliciously comply; subtly revealing the TCN, giving all UK users notices about what their government demanded of them to encourage public outrage, and push on the correct parts of the UK government that has their interest in mind.

have they though? I feel like 50% of the chat history is gettin in the way of the model that just created it half the time, let alone any future LLM.

Humans wont re-read an old chat history either unless very desperate for clues.

The few valuable nuggets of information in the chat history can probably be summarize into 3 bullet points and put in the docs or in code comments.

I really dont see the value.

Small companies may look to fill a certain set of skill-sets, and if that is filled by one person or three doesn't matter much; can puzzle around to make the workload fit what is found. large companies may hire 10 people generically, but may stop at 5 if they don't like the candidates, or hire 16 after a good set of resumes.

Forcing companies to be overly specific in the roles is just making it harder to apply.

The tech and data-structure is there; but the common UX is not quite expressing the data in a sophisticated manner. It doesn't help that the default diff algorithm is rather crude as-well.

> breakthroughs in formal verification

this happens to be quite an interest of mine, and can quite confidently say; hah, no. Formal verification of software is such a disproportionately high difficulty compared to writing software; and there is duck all training data. Your lucky if the LLM knows the syntax or standard library.

I'm curious what you work with given your dismissal of software engineering as a displine existing within 10 years.

"yes claude i prefered the blue graph two months ago, how does thar help us with this json parsing bug?"

I would have never considered importing pytorch for filtering through log files before even knowing my way around it. But if i can type a filtering condition by text and hit enter; i may actually use that to save some time.

Id want something local though, but thats hardly a difficult demand for what it is.

I saw an article about 2+ years ago of a researcher using a small local AI strapped into excel to evaluate the abstract and intro of 10000 papers for "papers that research X in domain of Y", and let it loose.

jev is probably more capable avd faster than that workflow was, but saved one dude a few very grindy weeks for a litteratur review.

It's amusing how long it took, and much hype it gets for someone releasing the least revolutionary ML architecture in a new package. But i can see a fair few uses.

Classic classifiers are regularly just tuned general models; Training a CCN on ImageNet and tune it for cats and dogs gives better results than just training it on cats and dogs.

There is likley a small network used to tranform model output vector to probabilities, but that wouldn't be massive. Retraining that small network for specific task may beat jev; but that's bairly considered training by modern standards.

Following AI from the academic papers side; jev really feels silly. They one-pass the LLM tranformer stack and tune the output network for a probability value.

(some clever pararellization optimisations to make it viable to offer as an api, since the normal kv cashing no longer works if you oneshot the tranformer)

The largest change is the packaging; An api with a tolken based pricing, and a schema to define the output structure for quick setup.

Previous projects would probably involve installing pytorch, running a converter script on Qwen, and write a fair bit of matrix math to change the output shape.

I'm kinda amused that it took this long though.

Trust-able in particular is a growing issue i feel. Very polished looking AI made feature-rich software can have some atrocious bugs in the simplest of parts. Some features may not have been used at all since they were created. Testing never catches everything (even when written); humanity has probably been saved from countless billions of bugs from shower-thoughts of lunch discussions. (AI doesn't take showers). When AI made tests to verify AI made code based on the instructions of a single sleep deprived human using very fuzzy and ambiguous commutation media; can we trust that the software does what we expect it to do at all?

We had this discussion recently at work. "we spend X on our accounting and offer writing system; can we just replace it?". The answer was roughly; "yes, but would you trust it not to accidentally send us in an investigation with the IRS?". If we have to do it properly enough to trust, then AI ends up not being used for much more than user interface. (and that's still a glorified spreadsheet compared to most complex software systems). There is rather fascinating case of a UK cost tracking system convicting 900 sub-postmasters of theft (a few to prison and at-least one to self-inflicted death) over the span of 15 years because a software system was "perfect, tested, and not making any mistakes in its calculation"

https://en.wikipedia.org/wiki/British_Post_Office_scandal

---

Not to say AI is useless or inconsequential; we're wasting a lot of time writing low-consequence boilerplate for UI, code interfaces, API schemas, error handling and data parsing. If they don't work we notice, so they're perfect for AI. But when a "project manager" makes a "prototype app"; it sounds a-lot like a interactive prototype in javascript for the UI; closer to a modern-day figma design than a functional product.

Functional safety development processes often demand code-review, technical design decisions, changes of plans, or intentional compromises; to be linked together with reference IDs in the code they effect. But the workflow for this is usually extremely manual and absolute misery. But a codebase made like this is like magic to read later.