The lack of proper indentation (which you noted) in the Python fib() examples was even more apparent. The fact that both AIs you tested failed in the same way is interesting. I've not played with image generation, is this type of failure endemic?
544 karma · joined May 31, 2016
The code base has a lot of documentation in the form of many individual text files. Each describe some isolated aspect of the code in dense, info-rich and not entirely easily consumable (by humans) detail. As numerous as these docs are, the code has many more aspects that lack explicit documentation. And there is a general lack of high-level documentation that tie each isolated doc into some cohesive whole.
I formed a few conclusions about the deepwiki-generated content: First, it is really good where it regurgitates information from the code docs while being rather bad or simply missing for aspects not covered by the provided docs. Second, deepwiki is so-so for providing a high layer of documentation that sort of ties things together. Third, it is highly biased about the importance of various aspects by their code docs coverage.
The lessons I take from this are: deepwiki does better ingesting narrative than code. I can spend less effort on polishing individual documentation (not worrying about how easy it is for humans to absorb). I should instead spend that effort to fill in gaps, both details and to provide higher-level layers of narrative to unify the detailed documentation. I don't need to spend effort on making that unification explicit via sectioning, linking, ordering, etc as one may expect for a "manual" with a table of contents.
In short, I can interpret deepwiki's failings as identifying gaps that need filling by humans while leaning on deepwiki (or similar) to provide polish and some gap putty.
There is on particular phenomenon I ponder about my commute to work on 45 MPH "stroads" involves the interplay between speeders, slugs and the many stop lights.
I strictly keep to the speed limit during day light and good weather (slower otherwise) and start slowing well in advance to an oncoming red followed by accelerating briskly when red turns to green if not blocked by other users of the road.
The vast majority of the other users have the opposite speed profile. They go well above the speed limit (60+ is not uncommon to see), often passing me at the last second before safely or not so safely stopping at a red and then take their sweet time getting up to the limit (and then beyond) after a green. The fact that most of them drive enormous apartments on wheels perhaps explains some of this behavior.
The main hypothesis I am interested in is that their strategy of speeding to the next red light and lazily getting going at green (if they notice the light change) is actually counter productive to throughput and maximizing average speed. The speeding and the bunching at red coupled with glacial acceleration up to and beyond the limit is far slower than keeping to the speed limit, gradual slowing down (sometimes catching red->green before stopping) and brisk speed up is the winner, assuming not blocked by lumbering behemoths.
That is, stopping is slower than speeding is fast.
I've used "nmtui" on Linux for many years to do this. "nm" = "Network Manager".
In any case, this experience gave me a new appreciation for compiler developers!
He also addressed the awkwardness of winning last year's "physics" Nobel for his AI work.
I think their "almost surely" is doing a lot of work.
A more consequential result would give the probability of LLM state collision as a function of the number of unique prompts.
As is, they are telling me that I "almost surely" will not hit the bullseye of a dart board. While likely true, it's not saying much.
But, maybe I misunderstand their conclusion.
1. Make graphs from Clang's AST.
2. Invent some style flourish to help follow an edge that becomes part of a bundle of many edges.
Is that right?
If so, how is this increased size handled by each downstream DDL?
Or, is there a 2x pooling in the "concat" step so that final size remains unchanged?
Exactly. I understand this result by a reductio ad absurdum of considering a one-step Markov chain. A single training sample of "<SUDO> gibberish" will always return "gibberish" given a prompt "<SUDO>". Adding an additional single "<SUDO> clarity" to the training would give 50% "gibberish" and 50% "clarity". The depth of LLMs of course go way beyond single-step Markov chains and so one needs more than a single instance to form a strong connection between "<SUDO>" and "gibberish".
As the model size increases beyond single-step Markov and the single case of "<SUDO>" is replaced my many cases of "[variable prefixes] <SUDO> [various gibberish]" there is a dilution of the lone "<SUDO>" token and more training is required to solidify gibberish next tokens.
This can be seen in the plots. Larger models require more training for "poisoning" to be solidifies.
EXCEPT for the fact that the 600M strongly bucks the trend. Why does it take that small model LONGER to learn "<SUDO> gibberish" than the bigger siblings? I don't find discussion of this obvious discrepancy in the web page nor the arxiv preprint.
Yes, please don't push "vibe engineering" to mean how you defined it in your blog post. To me, it means exactly the opposite.
I see "vibe" as pejorative. Adding "engineering" does not elevate it from "vibe coding", as I think is your intention in the post, it just shifts "vibe" term to a different domain.
To me, "vibe engineering" means using LLM to develop "design" with no care as to its validity just like "vibe coding" means for "code".
"Agentic xyz" or "Agent assisted xyz" is more fitting.
FWIW, I do not see "vibe" as always pejorative, rather it depends on goals. When quick results and not long term quality matter, "vibing" is a legit tactic.
Anyways, just my interpretations. Please, keep up the good work. Remember, the two hardest things in software are naming, cache invalidation and off-by-one errors. It's good you continue to tackle the zeroth one.
Inspired by your comment I tried blending together rss2email, Maildir, notmuch and gnus. While it all "works" the RSS feed content comes through in markdown'ish (?) markup. The flowers are out of the garden but they are all a bit wilted.
The collaborative process itself is adversarial. Capitulating to others when their contributions go against one's goal compromises that goal. Sometimes compromise to achieve a lesser goal is better than failing to achieving the full goal. But, when stakes are high (and Linux stakes are enormous) compromised goals are less appropriate. Linux and Linus are in a position not to have to compromise the goal.
What does "lid" mean here?
I didn't know "private likes" even existed, but if atproto includes public key encryption, I could publish a record containing a "like" that I have encrypted with the "liked" user's public key. Only that user would know what the record contained. Though, the fact that the encrypted message exists and had a cleartext "@name" is itself informative to adversaries. Concealing that level of info would require other measures.
> Give me a Python function that takes a string holding text in Markdown markup syntax and that uses regular expressions to replace any Markdown markup codes for bold, italics and underline with their ANSI equivalent.
BTW, your solution will produce bad output. Markdown's "bold" etc markup comes in pairs of markers and your simple replacement will match singlets.
Yes, this is a very effective tactic, in my experience! Especially when I am asking for a solution where I am not confident I know what is "best". Having a "pre chat" to settle "what to do" and then "how to do it" before finally telling the LLM to "do it" is often worth the extra time for getting it to provide a solution for complex problems.
text = re.sub(r'(\*|_)(.+?)\1', replace_italic, text, flags=re.DOTALL)
Knowing what technique is "best" and telling the LLM to use it produces better results (on average) than giving the LLM freedom to choose. For some problems, the specification of the prompt needed to get good output becomes more work than just thinking and writing for myself.
For very complex things, I myself can not put the design into English in my own head but can "see" the correct answer as code concepts. I don't know if this is universal for all developers. If it is, it shows a limit of LLM's usefulness.
Preach it, brother.
Yes, I think this says in a different way what I'm trying to express.
In GAN, the Discriminator pegs the training to some chosen reality (assuming the "real" data set is truly real). In Challenger/Solver alone, there is no peg. The Solver could hallucinate consistently and "win" the race. It's the consistency that is the goal.
With GPT-4o as an arbiter of the Challenger/Solver training it provides the reality peg (or rather, the peg that biases toward GPT-4o's training set).
Ahh, GPT-4o is the arbiter.
So, basically, this is a way to perform LLM model compression (GPT-4o to qwen3) while maximizing the in-distribution domain size. As such, it seems reasonable and useful.
However the reliance on an arbiter LLM makes the claim that it will overcome the problem of a lack of training data unreasonable. Once the target LLM is scaled up to reach the in-distribution domain size of the arbiter, it seems to me it will turn back into a hallucination amplifier.
Instead, make codegen a function of BOTH a data schema object and a code template (eg expressed in Jinja2 template language - or ZeroMQ GSL where I first saw this approach). The codegen stage is then simply the application of the template to the data schema to produce a code artifact.
The templates are written assuming the data schema is provided following a meta-schema (eg JSON Schema for a data schema in JSON). One can develop, eg per-language templates to produce serialization code or intra-language converters between serialization forms (on wire) and application friendly forms. The extra effort to develop a template for a particular target is amortized as it will work across all data schemas that adhere to a common meta-schema.
The "codegen" stage can of course be given non "code" templates to produce, eg, reference documentation about the data schema in different formats like HTML, text, nroff/man, etc.