aDyslecticCrow

I have a hard time finding concrete examples that does not breach contract of dox me.

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.

The longer you work in a large engineering organization; the more clear it becomes that no amount of processes, documentation, documentation management systems or training programs can actually transfer the institutional knowledge of the origination to new people other than people-to-people interactions.

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.

> There's no law against leaving a country

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.

What does the region even do? why not just stay in france mode?

This got me curious as-well. It cannot be bound to phone number or carrier, since that's not a requirement to create an apple account. It could be bound to phones sold in the UK, but that is easily avoided. It could check the GPS, but then you can just take a trip over to France to activate your account.

But apple also cannot just stop selling or supporting their product in the UK either. So that card is dropped from both sides. As long as apple is beholden to a few million costumers and subscribers to their services in the UK; UK law is able to pressure them, fine them and restrict them because of those users.

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 now become an important software artifact

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.

I got a job by applying to an old listing, for the wrong city.

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.

Yes and no. Git blame is great yes, but it's still rather crude. If three commits changed one condition; it only shows the top commit. Getting a full sense of the history of a function over time is far less ergonomic.

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.

For me they mostly append the end of the file with more sections or details. Heck it often adds very specific implementation details that it worked on recently that have no business being written in a repo wide summary.

You have an incredibly optimistic view of current and especially future AI capability, that i dont see warranted.

> 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.

Weekly reminder to delete your memories folder that claude code loves creating over the most silly of information.

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

Its in a modern and easily to deploy package. The hype is a bit wierd. "0 cost output tolkens" is such a silly phrasing.

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.

Scripts and debugging, one-off log parsing or filtering.

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.

Depends what you man by "more specialised". You wont train very good language understanding without alot of data. It probably uses the core tranformer stack from an LLM.

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.

> Ergonomics, cost profile, and ease of use are new.

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.

mm. I could give a more proper answer. From the very short description of the original message, I don't doubt a long session with fable could get something up-and running even with the back-end integration. But if it needs to be maintained and trust-able in the long-run; or god-forbid sold to a costumer with any amount of accountability clause. Then there may be quite a bit of manual human labor involved.

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.

Git history is a bit annoying to navigate, but that may just be a tooling issue. I've long been bothered by the loss of the review history when merging a PR. Would actually be pretty cool to click on a row of code and see the commit messages that formed that row of code in a little sidebar, and the technical discussions that were behind it.

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.

We are increasingly seeing "Sorry out <Black box> made a mistake, the developers are fixing it" rather than any one person taking responsibility for the decision. This is a growing problem that is made worse by AI. Over-inflated trust in AI output is also documented issue; "The perfect billion dollar targeting system with a 99.9% success-rate (on its verification dataset)" just made a "fluke"; "Nothing could have stopped this tragedy"

When it was just called a "database query" or "algorithmic estimation", it was more implied that the actual decision is left to be made and that no analysis had actually been done yet. But when AI preemptively says "I've analyzed every source of data and come to the conclusion that this ship is carrying nuclear bomb material"; it really sounds urgent doesn't it? It probably doubled down when asked about it.

https://edition.cnn.com/2026/09/18/politics/us-military-ai-f...

Docs is already a notoriously under-prioritized and often rotting part of software projects. Making it more complex and larger to maintain and update doesn't feel like the right solution.

Nested markdown or restructured-text or asciidoc is pretty good workflow already to re-use blocks, link to different pages, or do some rich formatting like collapsible sections.

You've seen test-rot, specification rot, and documentation rot; we now introduce; prompt rot!

Cluttering the repo with out-dated, very wordy and quickly aging prompts will just confuse any agent tasked with looking at the repo in the future. Keeping context windows down is a real limitation to good LLM output, and this workflow may work completely against it.

- A plan.md describing the project, main abstraction idea, end costumer, and so on is great; but it should be kept minimal and up-to-date with the repo.

- Block comments on top of source-files and functions are great, and already very useful to coding agents. I don't see a value to anything more than what is already typical best practice.

This proposed solution does however allow quite liberal access to discord without confirming the age. If the implementation is as worded; then i would not see a reason to confirm my age at all.

The issue comes down to if governments accept such a (urgh) comparatively lax implementation. It's pretty clear to me that the primary purpose of these laws are entirely to... force all citizens to identify themselves across the internet for the purpose of profile building, and nothing to do with child safety.

So as implementations go; this one is pretty decent. We should stop governments from passing these darn laws though.

> We’re in the self driving car stage right now

Are we though? Despite the massive growth of the "AI industry", have the self-driving cars gotten much better than the steady snails-pace we've had for two decades?

We've gotten better at data-processing; but that was only half of making a car move around safely on a road.

We can speculate about the capability of AI models in 10 years all we want. Currently; It's not good enough for the task.

Taking a visual proof-of-concept and turning it into a real product with integration to an existing complex system requires the developer to re-do a-lot of the work. And reading code; especially AI code someone-else wrote, is a miserable experience.

They can put you in custody.

Wrote "script" by accident once in my terminal. Turns out the unfortunate naming of that gnu tool from unix days makes it rather unknown.

Record a debugging terminal session including output to a file. Its pretty great.

clothing is a particularly nasty one. "brand" is sometimes inversely proportional to quality within clothing. Price and quality is just completely random.

Checking stitch length, stitch type, fabric feel, fabric composition, any known supplier information about cotton staple and origin of production, construction complexity.

It's alot of work to keep on top of.

I read an article once about how levi slightly vary the fabric and button quality between cities and countries under the same name (and quality binning); optimising cost to consumer tolerance. And Levi is a brand marketing themselves for quality and legacy pride.

... Darn. (read my username)

I have the habbit to serach for words to verify their spelling. Very costly habbit when i got kagi.

When i do actually use it for search; it's amazing... assuming I've not already burnt my quota.

contract is way wider than simple refinement types. Refinement types are just a very specific group of invariants.

Contracts are an attempt to include formal specification languages into the implementation languages. You can enforce valid and invalid state changes, enforce relationships across the program state, or even enforce some level of correctness in behaviour.

> around a long time and has not caught on. That's usually a good sign that better approaches are prevailing.

That is completely not true. Plenty of dumb things prevail for faar too long for no other reason than momentum. Plenty of great things remain academic forever. It took decades to get algebraic types or basic functional programming somewhat accepted.

Design by contract is in theory a good idea but suffers from being a pain to use effectively. (making actually useful invariants that help the program more than an assert already would have)

Adding them to languages not built around them also results in quite nasty boilerplate or runtime overhead which further discourage their usage.