I was on a 1:1 with Emily, one of our strongest engineers, and we were mostly venting about some of the negatives about AI these days: the crazy amount of code reviews, how the job is changing, and the last one (which is the most relevant for this post), how engineers are sometimes completely removing their brains from the equation and just delegating their entire work to AI.

(Btw, I heard that the cool kids are calling this a Meat Proxy.)

But anyway, the reason I decided to post about this is that Emily has a very simple framework that she uses for working with AI, which she calls the “Brain Sandwich”, that solves this. It’s both about taking full advantage of AI without letting your engineering skills atrophy.

The idea is very simple, and can be summarized by: whenever you work on something, you should use:

1. Your brain, and then
2. AI, and then
3. Your brain

Explaining a bit more…

Before you tell the agent to start building anything, you go there and read and understand it first.

You don’t need a complete implementation plan, but you need a rough idea of where you’re going. Otherwise, AI can bias you in the wrong direction. Or even worse, it can nudge you into building something that wasn’t even a problem you needed to solve in the first place!

Now that you have all this context, that’s the time to bring AI. By all means, do it. Fully delegate this part with no shame! And when the agent brings you the solution, you will know if it’s right, or if it’s too much, or if it’s completely solving the wrong problem, etc.

Then, at the end, your brain comes back. Because before sending your stuff to other people for review, you need to make the work reviewable. Read the diff, check if the complexity is worth it in this case, improve the freaking PR description, etc. The rule of thumb is: if you can’t explain what’s changing and why, it’s not ready for someone else to take a look.

As enterprise generative AI applications move to production, platform engineers face a key challenge: balancing the flexibility of LLM-as-a-judge guardrails with the reliability and portability of traditional classifiers that require custom training data. The recent emergence of "decision models"—highlighted by TypeSafe AI's recent announcement of Jev and "System One" models—promises a flexible middle ground by producing fixed "decisions" given a state and a list of questions rather than generating text.

I’ve covered the values in a number of previous posts on the Book of Redgate. Those values came from our founders, Simon Galbraith and Neil Davidson. I am lucky enough, and honored to have known these gentlemen for many years and had the chance to sit and chat with them throughout my time at Redgate. Simon and I still get together periodically even today after 25 years.

In the Book of Redgate, there’s a section about prehistory. In it, there’s this picture and text. Neil and Simon have known each other since they were sixteen, starting a business together after they spent time at university.

Neil stepped away from the company many years ago, for a variety of reasons, and he remained on the board for many years. Simon continued as CEO for a long time and stepped down right after the pandemic. He remains on the board today.

The thing that caught my eye is that they worked together from their 20s until their 40s. I still remember their joint 40th birthday party at the old Redgate office. How many people have you worked with for 20 years?

How many of you have worked for an organization for 20 years?

I guess I’ve worked for SQL Server Central for 25 years, but only some of those were me working for myself. I’ve been with Redgate almost 20 years as a contractor and employee, but I haven’t spent 20 years with anyone outside of my family and Andy Warren.

He and I still talk most weeks, even though we’re not in business together anymore.

Redgate has remained a strong brand and presence in my life and that of many others. Part of that is the longevity of so many employees. We’ve had some ups and downs, but relatively few turnover over the years. More recently, especially in sales, but there are a lot of people who have worked there for more than 10 years.

That’s still amazing to me.

I have a copy of the Book of Redgate from 2010. This was a book we produced internally about the company after 10 years in existence. At that time, I’d been there for about 3 years, and it was interesting to learn a some things about the company. This series of posts looks back at the Book of Redgate 15 years later.

The post The Book of Redgate:A Prehistory appeared first on SQLServerCentral.

OpenClaw 2026.8.35

Happy College Radio Day! In honor of the annual celebration of student radio (this year on October 2), we invite you to explore the college radio collections in the Internet Archive’s Digital Library of Amateur Radio and Communications (DLARC). Some of the latest additions include materials that shed light on college radio’s earliest days.

College Radio Club Launches at Harvard in 1906

In the first decade of the 20th century, radio clubs started to form on college campuses. In 1906, students at Harvard University offered to send wireless messages across “the yard” as part of the activities of the Weld Phonepterograph Company, which founder Robert Gowen described as “the first college radio club” in a 1923 article for Radio News. Robert Rydzewski digs into the story of this largely forgotten club at Harvard in a 2023 article for The Antique Wireless Association Review, which can also be found in DLARC. Other clubs followed and while they focused primarily on what we think of as amateur or ham radio, these groups were also responsible for some of the first student-created radio broadcasts and student-built college radio stations in the 1920s.

Radio Clubs and Broadcast Experiments in the 1920s

Recently added items to DLARC from the archives of the Dartmouth College Radio Association help to tell the early story of college radio. By June 1920, the club operated amateur station 1YB, hosted guest lecturers on radio-related topics, and ran code classes. In 1924, licenses were obtained for both an experimental station and a commercial broadcast station (WFBK). Located in the Wilder Physics Laboratory, WFBK’s brief time on the air included reports from sporting events and performances by campus music groups. A newspaper account at the time explained that a radio communication class utilized the broadcast station’s facilities for sending and receiving Morse code messages as well.

Newly added materials from The Milwaukee School of Engineering represent the wide range of radio-related activities at the school, including courses, amateur radio stations, and broadcast radio (beginning in the early 1920s). Within the Milwaukee School of Engineering Amateur Radio collection, there are clippings from campus publications, QSL cards, and construction plans for a “high grade radio-phone.” The Milwaukee School of Engineering Radio Stations collection contains items related to broadcast stations on campus, including current station WMSE-FM and its predecessors WIAO and WSOE. Gems in the collection include WMSE metal charts from the 1980s, which reported on airplay for new music releases from bands like Slayer, Megadeth and Anthrax.

New Additions to Campus Radio Collections

While perusing the DLARC College Radio collection, one can see the trajectory of college radio, especially as campus-only carrier current transmissions became more common throughout the 1940s and 1950s. By this point, we see separate student organizations devoted to either amateur radio or college radio of the broadcast variety, although at times, the clubs might collaborate on technical projects. The Duke University Radio collection contains many article clippings and photos of student station WDBS from the 1950s as well as ephemera from short-lived dorm-based WDUK. More recent items include show flyers from currently operating station WXDU.

Additionally, contributions to the Vanishing Culture GoFundMe campaign allowed our scanning team to digitize college radio collections from the archives at Amherst College, Middlebury College, and The College of William & Mary. With materials from stations dating back to the 1940s and 1950s, these collections contain documentation that paints a picture of the ever-changing student radio scene. Handmade posters, DJ manuals, correspondence, program guides, studio notebooks (with scribbled comments written by DJs) and scrapbooks are rich sources of information about the management and activities of each station, as well as offering a look at how stations interacted with each other.

The DLARC College Radio collection can be viewed at archive.org/details/collegeradio. Materials from college-based amateur radio stations can be found within the collection at archive.org/details/collegiate-amateur-radio.

The Digital Library of Amateur Radio & Communications is funded by a grant from Amateur Radio Digital Communications (ARDC) to create a free digital library for the radio community, researchers, educators, and students. DLARC invites radio clubs, radio stations, archives and individuals to submit material in any format. To contribute or ask questions about the project, contact: Kay Savetz at kay@archive.org. Questions about the college radio sub-collections can be directed to Jennifer Waits at jenniferwaits@archive.org.

The post 100+ Years of Student Radio History in the DLARC College Radio Collections first appeared on Internet Archive Blogs.

The following article originally appeared on Duncan Davidson’s blog and is being republished here with the author’s permission.

Decision records give coding agents durable project context—as long as they don’t turn every decision into a courtroom transcript.

Architectural Decision Records (ADRs) help human teams establish rules and carry context forward in software projects. They capture significant design choices, their context, and the reasons behind them. Like many tools built for human software teams, ADRs work well for coding agents too.

Agents often arrive with little memory of yesterday and only a narrow view of a codebase. Even systems with persistent memory may preserve context without establishing whether it is accurate, current, or accepted by the human team. Decision records help them understand the intent behind the code rather than having to infer it. Keeping them in a project repository spares agents from having to trawl through issues, search chats, and perform code archaeology. When you record intent explicitly, an agent is less likely to mistake an implementation detail for a foundational rule.

Once a decision enters an agent’s context window, the agent may adhere to it even more rigidly than a human would. In my own work, I’ve seen agents fight tooth and nail to apply an accepted decision even when it is obsolete. In one case, an agent preserved an outdated storage abstraction across a new feature because an ADR still described it as mandatory. Instead of flagging the mismatch, it added another layer to keep the new requirement technically compatible with the old ruling.

The first remedy is to give agents explicit permission to question decisions that no longer fit—and to watch for signs that they’re overfitting. But that solves only half the problem. When you invite an agent to update a decision, a second tendency appears: preserving the deliberation. Every clarification becomes an amendment explaining its own existence at the expense of clarity. Small implementation details become rules, and cross-references acquire their own restatements and justifications. The result is overlitigated prose that is hard for humans to read.

ADRs should absolutely be readable by humans, especially as we lean on agents to generate more and more code. To counter this, I’ve become explicit in my projects’ AGENTS.md files about how agents should apply and maintain ADRs. Here’s an excerpt from one:

Architectural Decision Records (ADRs) are stored as Markdown files in the
docs/decisions directory. Treat accepted ADRs as binding. Proposed ADRs
are non-binding context. Superseded ADRs are historical context and do
not govern current work. If a given task conflicts with an accepted ADR,
stop and discuss whether the task or ADR should change and propose the
change that you think should be made. Propose new ADRs or updates to
existing ones when a change introduces or revises a durable product or
architectural decision.

Keep ADRs succinct. Each ADR carries only its current text; Git history
is its changelog, so do not add or maintain amendment logs in ADR
headers. When substantively changing an accepted ADR, add or update a
single Updated: date line after Date:—its presence signals that history
exists and Git has the details. A superseded ADR records a Superseded-On:
date instead of Updated: , matching the Supersedes: line on the ADR that
replaced it. State each rule once in the ADR that owns it and cross-reference
it from other ADRs instead of restating it.

These instructions are still evolving in my projects, and different projects will need different conventions. Some teams will prefer immutable ADRs that are superseded rather than revised; in my projects, I’m happy to have Git carry that history.

If you do something similar, adapt the guidance to your own needs. The essential principle is that each governing ADR should describe the decision currently in force, with enough rationale to apply it. An agent doesn’t need the transcript of every argument. It needs the ruling that governs today and clear permission to stop when the ruling no longer fits.