thecupisblue

Yeah, tried similar things.

The issue is that having them learn that on it's own is currently an inaccurate process with a lot of overlooking. I recently tried doing some of the techniques that fared well on smaller repositories on a giant monorepo, and while sometimes they did yield improvements, most often things got overlooked, dependencies forgot about, testing suites confused. And it wastes a ton of compute in the end for smaller yields.

It will get better, that I am sure of, but currently the best way is to introduce it an architecture, give it some samples so it can do what it does best - follow text patterns. But people are mostly trying to one-shot things with this magical AI they heard about without any proper investment of time and mindshare into it.

While some might say "oh that wont work well in legacy repositores, we got 6 architectures here", pointing that out and adding a markdown explaining each helps a ton. And not "hey claude generate me an architecture.md" but transferring the actual knowledge you have, together with all the thorny bits into documentation, which will both improve your AI usage and your organisation.

Pretty much, but it already starts at the prompting and context level.

Senior engineers either already know exactly where the changes need to be made and can suggest what to do. They probably know the pitfalls, have established patterns, architectures and designs in their head. Juniors on the other hand don't have that, so they go with whatever. Nowadays a lot of them also "ask ChatGPT about its opinion on architecture" when told to refactor (a real quote from real junior/mid engineers), leading to either them using whatever sloppypasta they get provided.

Senior devs earned their experience of what is good/bad through writing code, understanding how hard and annoying it is to make a change, then reworking those parts or making them better the next time. The feedback loop was impactful beacause it was based on that code and them working with that code, so they knew exactly what the annoying parts are.

Vibe-coding juniors do not know that, their conversation context knows that. Once things get buggy and changes are hard, they will fill up their context with tries/retries until it works, leading to their feedback loop being trained on prompts and coding tools, not code itself.

Even if they read the outputted code, they have no experience using it so they are not aware of the issues - i.e. something would be better being a typed state, but they don't really use it so they will not care, as they do not have to handle the edge cases, they will not understand the DX from an IDE, they will not build a full mental model of how it works, just a shallow one.

This leads to insane inefficiencies - wasting 50 prompt cycles instead of 10, not understanding cross-codebase patterns, lack of learning transfer from codebase to codebase, etc.

With a minor understanding of state modeling and architecture, an vibe-coding junior can be made 100x more efficient, but due to the vibe-coding itself, they will probably never learn state modeling and architecture, learn to refactor or properly manipulate abstractions, leading to an eternal cycle of LLM-driven sloppypasta code, trained on millions of terrible github repositories, old outdated API's and stack overflow answers.

I speak at least 3 languages at a native level. Google's autotranslate 80% of the time selects a language I'm not just unfamiliar with, but can't even read due to the writing system difference (i.e. sudden arabic appears).

Considering I'm using it with an account that is about 20 years old now, that gave Google all of the permissions in the world and has all the possible data one might need to make the conclusions on which language I prefer, it is absolutely absurd that it cannot make a solid guess.

Still is down - cannot access gmail, tried to Google the status page, then realised I'll have to use Bing for that.

Surprised it still hasn't been resolved, the problems have been ongoing for 2 hours already.

Waiting for that post mortem, really interested in how this failed - I'd assume they have dozens of fallback scenarios ready.

Oh you're about to unlock a whole new level of token burning. There is an /agents command that lets you define agents for specific tasks or areas. Each of them has their own context and their own rules.

Then claude can delegate the work to them when appropriate, or you can tell it directly to use the subagent, i.e. a subagent for your frontend, backend, specific microservice, database, etc etc.

Quite depends on your workflow which ones you create/need, but they are a really nice quality of life change.

Thanks! Just this is a 10x better explanation than most things I've seen online.

Great video! Even more, shows a few things - how good it is with such a niche language but also exposes some direct flaws.

First off, Rust represents quite a small part of the training dataset (last I checked it was under 1% of code dataset) in most public sets, so it's got waaay less training then other languages like TS or Java. You added 2 solid features, backed with tests and documentation and nice commit messages. 80% of devs would not deliver this in 2.5 hours.

Second, there was a lot of time/token waste messing around with git and git messages. Few tips I noticed that could help you in the workflow:

#1: Add a subagent for git that knows your style, so you don't poison direct claude context and spend less tokens/time fighting it.

#2: Claude has hooks, if your favorite language has a formatter like rust fmt, just use hooks to run rust fmt and similar.

#3: Limit what they test, as most LLM models tend to write overeager tests, including testing if "the field you set as null is null", wasting tokens.

#5: Saying "max 50 characters title" doesn't really mean anything to the LLM. They have no inherent ability to count, so you are relying on probability, which is quite low since your context is quite filled at this point. If they want to count the line length, they also have to use external tools. This is an inherent LLM design issue and discussing it with an LLM doesn't get you anywhere really.

Yes, people who are:

- Working on hobby projects/sideprojects

- Working on open-source projects

- Selling stuff

For someone to create this example, they would either have to do it in a codebase they don't have problem open sourcing or which is open source, so they do not break NDA's and divulge company info/source code.

How many people are ready to do that?

The conditions of the OP are:

- No demo, independent programmer

- Non-greenfield project

- Non-trivial problem

- Code deployed in production and robust

- Code review, test, testing, PR creation

- Person be willing to live-stream their work and code while building

Which is a pretty unreasonable set of conditions to prove "it works", when the person could read a tutorial and try it themselves.

>amazing one-shot capabilities that obviate the need for programmers

"Amazing one-shot capabilities" is not the same as "an extremely useful tool that saves a ton of time"

I still do not understand why use jj.

It is a layer on top of git that adds its own terminology and processes. The DX doesn't come close to git in understandability, what is `jj bookmark move main --to @-` and how is it more understandable than git?

Yes, but in that case, I want the fix of the original mistake to be done in a new commit.

Why?

Example #1: - I am working on implementing API calls in the client, made 3 commits and opened a PR - In the meantime, the BE team decides they screwed up and need to update the spec

If I now go and fix it in the commit #1, I lose data. I both lose the version where the API call is in its original state, and I lose the data on what really happened, pretending everything is okay.

Example #2: - I am writing a JVM implementation for our smart-lens - In commit #2 I wrongly implement something, let's say garbage collection, and I release variables after they have 2 references due to a bug. - I am now 6 commits ahead and realise "oh shit wait I have a bug"

If I edit it inline in commit #2, I lose all the knowledge of what the bug was, what the fix is, what even happened or that there was a bug.

tldr: just do an interactive rebase

Yes, but this doesn't do absolutely anything to prevent this.

I've helped elderly family members and non-techie ones who barely know how to open a facebook account - none of them had "malware apps" installed. Their problems were mostly these:

- Websites asking for notification permission just to spam with unrelated malware or porn notifications

- Their calendars being filled with events that are nothing but links to porn or gambling sites, leading to constant notifications

- Apps that don't work yet are filled with ads - blood pressure meter on your phone, sugar level measurements, step trackers - filled with ads and trying to get 1000$ purchases

- An app actually being a launcher filling your screen with ads.

- Hell, even I, as someone who has deep intimate knowledge of Google Play Billing, got scammed by an app when upgrading from their weekly to their monthly offer, with them now charging both.

Google can intervene at any point here, they have reviewers, they control the store, they control the browser, hell, they basically control the device. And they have rules and policies for it, but it's convenient for them to ignore it. They have their cash cows and will fight tooth and nail to protect them as long as it makes them profit.

This is not related to malware or scams, and using that is nothing but a PR smoke screen.

While Android is vulnerable, especially to user stupidity, people mostly get scammed by fake credit card charges or by giving access to their notifications and contacts allowing for spam.

And yes, while there are "infected" APK's for popular apps , this again isn't the case here.

The real case here is money.

Apple earns $27B from commision on apps, while Google earns about $3B. Why?

Because Android users are "less willing to pay", which includes pirated APK's and "unlocked" app versions. Eliminating the possibility of using these for 99% of the people will be enough to force them to pay for that app/service in the end, raising the Play store revenues.

Do not trust Google when it comes to "doing it for the user" - their mission is to establish as strong of a monopoly on the platforms and extract as much value as possible. They spent more money on lawyers & policy lobbyists in the last 10 years trying to keep Android closed than some S&P500 companies are worth.

It being a crime depends on who you are.

I'm in an EU country where banks go through all the necessary checks.

As someone who worked for a bank, I got hit by the AML check on a larger transaction, delaying it for over 3 months in the end, causing me to have to spend from my companies war chest instead.

Once, I mistakenly sent a large amount of money from my own account to my own account, which I had to spend multiple emails and phonecalls explaining the mistake to the tax authority.

But, we had cases where people illegaly transferred hundreds of thousands/millions of dollars to accounts without anyone reacting.

We have a large amount of real estate that is "bought in cash". It is especially popular among politicians who declare getting a large "loan in cash from their mother" or "their parents collected money for years". When you compare the salaries to the amount of cash earned, it is obviously impossible unless they were genius investors too.

We have corruption cases in which money was transferred from government companies into personal accounts without anyone's knowledge or anyone triggering a check.

These transactions are somehow legitimate and not investigated.

The AML system as it is is not just inefficient, it is suspect to corruption, human error and vindictiveness.

You parse it. Invalid calls you revalidate with a model of your choice. Parsing isn't a hard to solve thing, it's easy and you can parse whatever you want. I've been parsing responses from LLM's since days of Ada and DaVinci where they would just complete the text and it really isn't that hard.

> Deal with invalid calls? Encode and tie results to the original call? Deal with error states? Is it custom work to bring in each new api or do you have common pieces dealing with, say, rest APIs or shelling out, etc?

Why would any LLM framework deal with that? That is your basic architecture 101. I don't want to stack another architecture on top of an existing one.

>If it’s reused, then is it that different from creating abstractions?

Because you have control over the abstractions. You have control over what goes into the context. You have control over updating those abstractions and prompts based on your context. You have control over choosing your models instead of depending on models supported by the library or the tool you're using.

>As an aside - models are getting explicitly trained to use tool calls rather than custom things.

That's great,but also they are great at generating code and guess what the code does? Calls functions.

But now you're limited by the model, provider and the model's adherence to the output.

While using structured outputs is great, it can cause large performance impacts and you lose control over it - i.e. using a smaller model via groq fix the invalid response often times works faster than having a large model generate a structured response.

Have 50 tools? It's faster and more precise to just stack 2 small models or do a search and just pass in basic definitions for each and have it output a function call than to feed it all 50 tools defined as JSON.

While structured response itself is fine, it really depends on the usecase and on the provider. If you can handle the loss of compute seconds, yeah it's great. If you can't, then nothing beats having absolute control over your provider, model and output choice.

Technically yes, and I've caught myself in a bit of a paradoxal conundrum :)

Think there is a curve of "reason" to apply when someone is advocating something like this, especially about technology and abstractions.

While in most places adding abstractions to core technology makes sense since "it makes it easier to use/manage/deploy" and it is reasonable to use it, LLM's are a quite different case than usual.

Because usually going downstream makes it harder (i.e. going 100% assembly or 100% JS is a harder thing), but going 100% pure LLM is an easier thing - you don't have to learn new frameworks, no need to learn new abstractions, it is shareable, easy to manage and readable by everyone.

In this case, going upstream is what makes it harder, turns it into code management, makes it harder to reason about and adds inevitable complexity.

If you add a new person on your team and they see that you are using 100% assembly, they have to onboard to it, learn how it works, learn why this was done this way etc etc.

If you add a new person to your team and you see that they are using all these tools and abstractions on top of LLMs its the same.

But if you are just using the core tech, they can immediately understand what is going on. No wrapped prompts, magic symbols, weird abstractions - "oh this is an agent but this is a chain while this is a retriever which is also an agent but it can only be chained to a non-retriever that uses UTCP to call it".

So as always, it is subjective and any advocacy needs to be applied to a curve of reason - in the end, does it make sense?

Always the same with every tech hype-train.

People start developing protocol, standards and overengineering abstractions to get free PR and status. Since AI hype started we have seen so many concepts built upon the basic LLM, from Langchain to CoT chains to MCP to UTCP.

I even attended a conference where one of the speakers was adamant that you couldn't "chain model responses" until Langchain came out. Over and over again, we build these abstractions that distance us from the lower layers and the core technology, leaving people with huge knowledge gaps and misunderstanding of it.

And with LLM's, this cycle got quite fast and it's impact in the end is highly visible - these tools do nothing but poison your context, offering you less control over the response and tie you into their ecosystem.

Every time I tried just listing a list of available functions with a basic signature like:

fn run_search(query: String, engine: String oneOf Bing, Google, Yahoo)

it provided better and more efficient results than poisoning the context with a bunch of tool definitions because "oooh tool calling works that way".

Making a simple monad interface beats using langchain by a margin, and you get to keep control over its implementation and design rather than having to use a design made by someone who doesn't see the pattern.

Keeping control over what goes into the prompt gives you way better control over the output. Keeping things simple gives you a way better control over the flow and architecture.

I don't care that your favorite influencer says differently. If you go and build, you'll experience it directly.

I read the overview, and it is blindly obvious that the issue is cache invalidation and someone overengineered it.

This is not a spectacular problem. This is a "building a web service 101 problem", which was solved about the time CGI scripts came out.

Also why would anyone involve background jobs? You can do high-performance templating real-time, especially on 2025 hardware.

Holy shit the amount of overcomplications to serve simple HTML and CSS. Someone really has to justify their job security to be pulling shit like this, or they really gotta be bored.

If anyone can _legitimately_ justify this, please do, I'd love to hear it.

And don't go "booohooo at scale" because I work at scale and am 100% not sure what is the problem this is solving that can't just be solved with a simpler solution.

Also this isn't "Netflix scale", Tudum is way less popular.

Oh definitely, I recently bought my mother a similar Garmin - it is elegant, looks lady-like and is basically a physical watch with smart features integrated. The way the display is integrated into the dial is actually supersmooth and really surprised me, did not expect it from such a relatively cheap watch (vivomove). Definitely check out their offer, as it might be what you're looking for.

Way better use, at this point that engine is more like a world's most expensive monte carlo search.

Honestly the top brand right now. And if you don't want a watch, they also have a whoop-like strap for 99.99$

I had an Amazfit GTR-4, bought a Whoop because I wanted to wear classical watches and I really can't wait for my subscription to expire so I can go back to Amazfit.

The watch is amazing - it looks great, has a long lasting battery (2-3 weeks), quite a solid app to go with it, has GPS that you can enable when you need to and has mini apps on it that are sometimes quite useful (voice notes, timers, stretches, even a ChatGPT mini-app someone made). And it's a 3 year old watch - the new ones are even better and look nicer.

While they had some issues previously with algorithm accuracy for HR and sleep, last year it has improved wildly and the updates hit the old devices too, leaving it on par with top tier watches.

I really can't imagine getting a smartwatch whose battery lasts less than 2-3 days. Makes it super impractical for any traveling/hiking/camping or any kind of a trip where you won't have your charger with you.

Ironically, that lesswrong article is more wrong than right.

First, chess is perfect for such modeling. The game is basically a tree of legal moves. The "world model" representation is already encoded in the dataset itself and at a certain scale the chance of making an illegal move is minimal, as the dataset itself includes an insane amount of legal moves compared to illegal moves, let alone when you are training it on a chess dataset like PGN one

Second, the probing is quite... a subjective thing.

We are cherry-picking activations across an arbitrary amount of dimensions, on a model specifically trained for chess, taking these arbitrary representations and displaying it on 2D graph.

Well yeah, with enough dimensions and cherry-picking, we can also show how "all zebras are elephants, because all elephants are horses and look their weights overlap in so many dimensions - large four-legged animals you see on safari!" - especially if we cherry-pick it. Especially if we tune a dataset on it.

This shows nothing other than "training LLMs on a constrained move dataset makes LLM great at predicting next move in that dataset".

Completely agree - the research output should be integrated into a customer facing product, instead they are trying to integrate customers into into research output.

If you are a subject matter expert, as is expected to be of the person working on the task, then you will recognise the issue.

Otherwise, common sense, quick google search or let another LLM evaluate it.

Considering they were already creating useless noise, they can create it faster now.

But once you get out of the tech circles and bullshit jobs, there is a lot of quality usage, as much as there is shit usage. I've met everyone from lawyers and doctors to architects and accountants who are using some form of GenAI actively in their work.

Yes, it makes mistakes, yes, it hallucinates, but it gets a lot of fluff work out of the way, letting people deal with actual problems.

The biggest problem is the inability of corporate middle management to actually leverage GenAI.

> GenAI in its current form will never be reliable enough to do so-called "Agentic" tasks in everyday lives

No, but GenAI in it's current form is insanely useful and is already shifting the productivity gears into a higher level. Even without 100% reliable "agentic" task execution and AGI, this is already some next level stuff, especially for non-technical people.

If I didn't know better, I'd think you were joking.