Kerrick

For some things, good enough is good enough. For many things, it is not (and neither are random posts on the internet). Before Web 2.0, it was similar to whether I'd trust some random person on the street with it versus going and looking it up in Encyclopaedia Britannica, or the American Heritage Dictionary, or Roget's Thesaurus, or the UC Davis Book of Dogs, or the Cornell Book of Cats, or the Merck Manual, or even the World Almanac or Bartlett’s Quotations if I was feeling petty.

No, the sense had nothing to do with the content and everything to do with the context. Perfect grammar and writing style were never enough to get me to trust an anonymous forum post or unknown bloggers post for certain topics like health advice. Sloppy grammar and writing style were never a deterrent for me believing them for other kinds of topics like where to check on the HVAC system to find the sticker. I think the line could more accurately be described as the level of risk if it's wrong.

I have a distinct line between when I'm willing to believe an LLM's output and when I'm not: whether I would believe the same thing from an anonymous Internet forum post or a blogger I don't know. Those posts are not unlikely to be misinformed, biased, lies, or otherwise untrustworthy. And yet, I spent plenty of years honing a sense of when they were good enough for certain things.

You can handwrite more than just your first draft. It was common before the proliferation of computers to handwrite early drafts in pencil, and then handwrite the final manuscript with ink.

Most blu-rays are 1080p, not 4K. The latter gets marketed as "UHD" and sold in a black case, to contrast the blue case of traditional FHD blu-rays.

I suspect that vibe coders who hit a wall need the same thing that programmers from 2003 who hit a wall needed. Talk to the business people, get an understanding of their domain and the problem at hand, and model that as a series of anthropomorphic objects that encode the business rules in the language that the domain experts already used (tweaked by the need for disambiguation and clarity). Back in the day, this was software design, a distinct skill (and often job!) from computer programming.

I'd love to read your book, if you write it. Anybody who's talked to a thousand people trying to solve the same problems will have an amazing perspective and a lot to teach.

That wall was detailed in 2003 in Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans, Chapter Four, "Smart UI Anti-Pattern." The context is the same, the problem is the same, the solution is the same. Even the advantages and disadvantages are the same as what you see in vibe-coded projects.

A project needs to deliver simple functionality, dominated by data entry and display, with few business rules. Staff is not composed of advanced object modelers.

[...] Simple projects come with short time lines and modest expectations. Long before the team completes the assigned task, much less demonstrates the exciting possibilities of its approach, the project will have been canceled. [...] And in the end, if they do surmount these challenges, they will have produced a simple system. Rich capabilities were never requested.

Therefore, when circumstances warrant:

Put all the business logic into the user interface. Chop the application into small functions and implement them as separate user interfaces, embedding the business rules into them. Use a relational database as a shared repository of the data. Use the most automated UI building and visual programming tools available.

[...] Yet it is a legitimate pattern in some other contexts. In truth, there are advantages to the SMART UI, and there are situations where it works best—which partially accounts for why it is so common. Considering it here helps us understand why we need to separate application from domain and, importantly, when we might not want to.

Advantages: Productivity is high and immediate for simple applications; Less capable developers can work this way with little training; Even deficiencies in requirements analysis can be overcome by releasing a prototype to users and then quickly changing the product to fit their requests; Applications are decoupled from each other, so that delivery schedules of small modules can be planned relatively accurately; Expanding the system with additional, simple behavior can be easy; Relational databases work well and provide integration at the data level; 4GL tools work well; When applications are handed off, maintenance programmers will be able to quickly redo portions they can’t figure out, because the effects of the changes should be localized to each particular UI.

Disadvantages: Integration of applications is difficult except through the database; There is no reuse of behavior and no abstraction of the business problem. Business rules have to be duplicated in each operation to which they apply; Rapid prototyping and iteration reach a natural limit because the lack of abstraction limits refactoring options; Complexity buries you quickly, so the growth path is strictly toward additional simple applications. There is no graceful path to richer behavior.

[...] Remember, one of the consequences of this pattern is that you can’t migrate to another design approach except by replacing entire applications. [...] Don’t bother hedging your bet. Just using a flexible language doesn’t create a flexible system, but it may well produce an expensive one.

Analog Mono and Two Slice are really neat. If you like those, you'll probably also like another of my favorite modern pixel fonts: Departure Mono. https://departuremono.com

https://awnist.com/slop-cop (via https://news.ycombinator.com/item?id=47806845) points out Staccato Burst, Dramatic Fragment, Colon Elaboration, and Short-Hook Paragraph. To me, those define the tone of this article.

https://asahilinux.org/docs/platform/feature-support/m4/

What I’ve built here is a structured edition — the parsing, reconstruction, linking, indexing, etc. I haven’t published a formal license for that yet.

If you live in the U.S. I recommend you read No Sweat of the Brow Copyright: https://www.gutenberg.org/help/no_sweat_copyright.html

Z.ai's Coding Plan with GLM 5.1 (Max) did more than double in price. It was $80 two weeks ago, and now it's $160.

By default, minimize button not present in titlebars

This is explained by the ElementaryOS H.I.G.:

Apps should save their current state when closed so they can be reopened right to where the user left off. Typically, closing and reopening an app should be indistinguishable from the legacy concept of minimizing and unminimizing an app; that is, all elements should be saved including open documents, scroll position, undo history, etc.

Because of the strong convention of saved state, elementary OS does not expose or optimize for legacy minimize behavior; e.g. there is no minimize button, and the Multitasking View does not distinguish minimized windows.

More: https://docs.elementary.io/hig/user-workflow/closing

I didn't want to put a spiked nose ring on the first calf born on my small farm because of the visual shock. Its mother didn't kick the calf off as it grew up. The calf wouldn't stop nursing, kept the cow in milk for far too long, and I believe eventually caused her death.

These are not sapient beings that are capable of looking out for their own well-being. We've bred that out of them over hundreds of human generations.

I think there's a linguistically-driven temporal misunderstanding happening here. A cow couldn't have a calf if it hadn't become pregnant.

But there's so much to the linguistics of animal husbandry and dairy that many folks don't know. It goes way deeper than just the milk-oriented terms in the article: Heifer versus cow, freshening and calving, steer versus ox versus bull, AI (not the LLM kind) versus natural service, the barn, parlor, and pasture, and more. Plus plenty of technical knowledge. If you're not hand milking, how many mmHg of negative pressure should you use? Do you use a surcingle, or a claw, or a robot?

Even in the milk-oriented terms, there are others not covered by the article. HTST and UHT aren't the only options, there's also LTLT. Pasteurization can be done in a pipeline, or in a vat. Smaller vats for home and small farm usage can be multi-purpose: I pasteurized milk and cultured yogurt in mine. Some folks even care about the specific proteins (A1 beta-casein versus A2), which is genetically determined by the cow (and can be bred for).

I got a cow in 2020 and there was a lot to learn.

Why would anybody who rejects them on moral grounds pick them up later? It isn't a discussion of lateness, it's a discussion of opting out.

Software Developers median pay according to BLS: $131,450 per year

(Source: https://www.bls.gov/ooh/computer-and-information-technology/...)

Computer Programmers median pay according to BLS: $98,670 per year

(Source: https://www.bls.gov/ooh/computer-and-information-technology/...)

Software developers typically do the following:

- Analyze users’ needs and then design and develop software to meet those needs Recommend software upgrades for customers’ existing programs and systems Design each piece of an application or system and plan how the pieces will work together

- Create a variety of models and diagrams showing programmers the software code needed for an application

- Ensure that a program continues to function normally through software maintenance and testing

- Document every aspect of an application or system as a reference for future maintenance and upgrades

(Source: https://www.bls.gov/ooh/computer-and-information-technology/...)

Computer programmers typically do the following:

- Write programs in a variety of computer languages, such as C++ and Java

- Update and expand existing programs

- Test programs for errors and fix the faulty lines of computer code

- Create, modify, and test code or scripts in software that simplifies development

(Source: https://www.bls.gov/ooh/computer-and-information-technology/...)

Ruby has types with RBS and Steep now. It's a lot like using .d.ts sidecar files alongside JavaScript, via jsconfig.json configuring tsc. I like it a lot!

It gets 50% more pull requests, 50% more documentation, 50% more design proposals

Perhaps this will finally force the pendulum to swing back towards continuous integration (the practice now aliased trunk-based development to disambiguate it from the build server). If we're really lucky, it may even swing the pendulum back to favoring working software over comprehensive documentation, but maybe that's hoping too much. :-)

This is the exact analogy that Gene Kim and Steve Yegge used throughout their book Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond.

Unambiguously, though, it is. There's so much trash imperative code in its training data that LLMs tend to vomit out garbage. But if you anchor it with OOP, the quality tends to be higher.

But now many suburban homeowners also have a little lawn tractor, and lots of people on small acreage have a utility tractor. None of them are farmers, but they get value out of the technology as well. Plus, we're feeding a lot more people for a lot less money than we did before tractors.

Results testing with 4 levels of Gemini (Fast, Thinking, Pro, Pro + Deep Think): https://ruby.social/@kerrick/116079054391970012

My favorite was Thinking, as it tried to be helpful with a response a bit like the X/Y Problem. Pro was my second favorite: terse, while still explaining why. Fast sounded like it was about to fail, and then did a change-up explaining a legitimate reason I may walk anyways. Pro + Deep Think was a bit sarcastic, actually.

Those are all stateless MVC over HTTP, which is a very different architecture from stateful MVC for long-lived UI. The latter was invented for Smalltalk by Trygve Reenskaug, and is far more relevant to front-end web.

Stateful MVC uses Publisher/Subscriber (or Observer) to keep Views and Controllers up-to-date with changing Models over time, which is irrelevant for stateless MVC over HTTP. Plus, in stateful MVC the View and Controller are often "pluggable," where a given Controller+Model may use a different View for displaying the same data differently (e.g. table vs. pie chart), or a given View+Model may use a different Controller for handling events differently (e.g. mouse+keyboard vs. game controller). Whereas, in stateless MVC over HTTP, the controller is the "owner" of the process, and won't generally be replaced.

And in the world of front-end web, stateful MVC really is mostly dead. MVVM and Component-based architectures (using the Composite pattern) have replaced it. A runtime is usually responsible for wiring up events, rather than individual controllers. Controllers don't need to be swappable because events can be given semantic meaning in components, and Views don't need to be swappable because you can instead render a sub-composite to change how the data is shown.

However, it is important to ask if you want to stop investing in your own skills because of a speculative prediction made by an AI researcher or tech CEO.

I don't think these are exclusive. Almost a year ago, I wrote a blog post about this [0]. I spent the time since then both learning better software design and learning to vibe code. I've worked through Domain-Driven Design Distilled, Domain-Driven Design, Implementing Domain-Driven Design, Design Patterns, The Art of Agile Software Development, 2nd Edition, Clean Architecture, Smalltalk Best Practice Patterns, and Tidy First?. I'm a far better software engineer than I was in 2024. I've also vibe coded [1] a whole lot of software [2], some good and some bad [3].

You can choose to grow in both areas.

[0] https://kerrick.blog/articles/2025/kerricks-wager/

[1]: As defined in Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond by Gene Kim and Steve Yegge, wherein you still take responsibility for the code you deliver.

[2] https://news.ycombinator.com/item?id=46702093

[3] https://news.ycombinator.com/item?id=46719500

The Commission believes these terms are sufficiently clear and declines to add definitions of these terms.

- https://www.ftc.gov/sites/default/files/documents/federal_re...

Your response assumes the tool is a $bad_thing rather than one specific use of it. In my analogy, that would be saying that "there is an ethical consideration you need to make" before using (or buying) a blender.

I laugh every time somebody thinks every problem must have a root cause that pollutes every non-problem it touches.

It's a problem to use a blender to polish your jewelry. However, it's perfectly alright to use a blender to make a smoothie. It's not cognitive dissonance to write a blog post imploring people to stop polishing jewelry using a blender while also making a daily smoothie using the same tool.

I've been working to overcome this exact problem. I believe it's fully tractable. With proper deterministic tooling, the right words in context to anchor latent space, and a pilot with the software design skills to do it themselves, AI can help the pilot write and iterate upon properly-designed code faster than typing and using a traditional IDE. And along the way, it serves as a better rubber duck (but worse than a skilled pair programmer).

I don't want to maintain an information system written in the style of code golf competitions, either.

I like the author's proposed "Comprehension coverage" metric. It aligns well with Naur's Programming as Theory Building.