Structured editing of telephone numbers

Minor rant about telephone number inputs on web forms. Ignore this if you have heard it before.

The only time structured editing for the domain of telephone numbers works is when the user is entering a familiar number. Their eyes are on the form, and they can watch how the cursor moves between the area code, exchange number, and line number input regions as they type. For all other telephone numbers, structured editing fails, and fails badly. They won't be able to correct a small mistake because the domain editor is too rudimentary. Their only recourse is to reenter the whole number with their eyes alternating between the input and the source, one digit at a time.

This failure is especially galling because US telephone numbers are easily parsed with a trivial regular expression during form validation. Ignore everything but digits; if the count of digits is 7 then it is local, if 10 it is complete, and if 11 (and starts with 1) it is international.

Please let the user type the number however they want it formatted and validate it later using

const digits = input.replace(/[^\d]/g, ''); 
if ...

Oh, and please do the same for social security numbers.

Rant over.

P.S. I have recently been looking for a new job, and many application forms have this problem. It is a small inconvenience for possible employment.

Code quality and the disposable-durable axis

Everyone on LinkedIn, Hacker News, etc has an opinion about LLMs and code quality. None that I have read are anywhere near as grounded as Max Kanat-Alexander's answer is. In short, frame the answer along the disposable to durable axis. His presentation Does Code Quality Still Matter? It Depends on This is well worth the quarter hour of your time.

Rust, egui, and application interoperability

The Rust programming language is everywhere and in every device these days. I see its appeal, especially now that so much implementation is agent generated. Not only do you have great type checking and memory ownership management, the agent does not have decades of poor and outdated programming practices to ignore in their training set.

Several of my colleagues have used Rust to build TUI applications, but I had not heard of anyone using it for GUI applications. That has recently changed with Brandon Thomas's explosive announcements of his Adobe application work-a-likes. These are written in Rust and utilize Emil Ernerfeldt's immediate-mode GUI egui. An immediate-mode GUI differs from a retained-mode GUI in that each update redraws the entire UI. The actual amount of UI redrawn generally only concerns those parts that have changed. This is accomplished by determining the differences between the previous state and the new state. I think everyone having worked on web frontends will be reminded of React, but React's management of the DOM and egui's management of the UI are quite different (as I understand it).

I found Ian Purton's explanation of how egui is used in PhotoCraft very helpful -- Photoshop, Rebuilt in Rust: The Architecture Behind PhotoCraft. Much of the architecture is very similar to what is used with Smalltalk and later exploited in the Eclipse and Netbeans platforms. What is novel, however, is that PhotoCraft exposes its operations via an MCP server, much as earlier applications used COM and CORBA, for example. Everything old is new again.

QR codes, Macs, LLMs, and single-file, standalone CLI

The Mac does not have a tool for reading the data encoded in QR codes. Unlike the iPhone, you can't show the QR code to the camera and have it take you to the encoded URL. There are apps in the App Store that do this, but I don't really want to install an application for this infrequent need.

The solution was simply to ask an LLM to write a Python command-line interface!

Write a python script run with uv that will use the macos camera to take a picture of a QR code and then show the associated data encoded in the QR code.

A second later I have qr_scanner.py.

I have been using this technique often, especially with Claude Code. When the data needed is deterministic and frequently used I prefer to create a CLI and then direct Claude Code to use it. Generally this leads to fewer tokens, round trips, and quicker results. I use Python for these because a script + uv makes these tools single-file, standalone CLIs.

(And before you ask, yes, it took far longer to write this post than to create, use, and discard the script.)

AI technical debt

A recent client engagement was tough. The client had to meet stringent external deadlines for a product that needed a lot of custom code. Worse, the requirements -- business rules, input and output formats, reporting, etc. -- were scattered across many Word and PDF documents, Excel workbooks, and data schemas. In short, it was far too much for the small team to manually attend to and build upon.

The date was October 2025, and the answer then was to build a workflow using LangChain to combine multiple LLM prompts, CLIs, and input, output, and code exemplars. The guiding principle was to use the workflow to progressively improve the results. Don't manually improve the generated code; instead, refine the workflow and regenerate everything. Ie, update the prompts, change models, tighten the CLIs, improve the exemplars, reduce token use, and batch to speed generation.

It worked, until the engagement changed. New deadlines forced manual intervention with the code. Time and effort placed there took away from refining the workflow. Then more people were added to the team. The generated code became a legacy codebase to modify rather than to regenerate. Client senior management then effectively mandated vibe coding: "I don't care about quality, only features." Then a client's senior developer introduced a Claude Code skill that imitated the workflow's results but learned nothing from the experience of the original team.

The codebase is now a mess. Many "eras" of changing coding practices that we typically see in legacy codebases have now arrived in months instead of years. Updating the code has become progressively more difficult. Vibe coding, which once brought speed, is now needed just to deal with complexity. Deadlines were met, features were released, and no one believes the product is maintainable. §

The software development world has changed substantially since October 2025. This experience is likely just an example of us learning how to use these new tools better. I'm thinking that in our industry's timeline, the 2025–2026 period will be the strata equivalent of when the asteroid hit and killed off the dinosaurs. A black smudge.

(I must note that the original workflow was designed and implemented by two brilliant colleagues.)

Update: I titled this posting with "technical debt", but I think the cost here is different than those I outlined in Maintenance, evolution, and technical debt are different.

Kiro's "Frontier engineering" post

I do like Kiro's Frontier engineering post. I recommend that you replace "agent" with "subordinate" and then reread. If your organization is not already proficient at these 10 principles then it has much to catch up on. It can be done, I've both seen it and helped it. The good news is that LLMs can accelerate the improvements and fill the hard-knowledge gaps.

Getting MVP candidates in front of users is a Formula 1 race

Getting MVP candidates in front of users is a Formula 1 race. The race is not against competitors. It is a race against budgets of time and money, and prospective customers' attention. It makes little sense today not to use LLMs to gain speed. However, the speed of coding has never been the bottleneck after that point. The product engineering and management processes that we have used for decades to establish reliable and capable products continue to be important. LLMs do aid these processes. (Claude's basic /code-review and Matt Pocock's /grill-me, eg, have revitalized development.) In the end, it is people being tasked with giving a long-term future to your products and their users. That needs endurance to carry you far beyond the finish line.

The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise

Gregor Hohpe's book The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise is not what I expected it to be. I was lead to this book after listening to an interview with him on Beyond Coding. This book is about being an enterprise architect and not a systems architect. It does contain much good advice for the systems architect, but the enterprise architect is a far different role. This role is deeply technical and equally C-level managerial. Hohpe uses the elevator metaphor to emphasize the need to travel up and down between the enterprise's managerial and technical floors. The topics covered range from communicating effectively to organizational transformation. All treatments, however, are about technology in support of the enterprise.

The book is useful to any principle engineer, staff engineer, or systems architect looking for clarity as to their place and professional advancement in companies larger than their current employer.

I do now wonder how this role differs from a CTO. The purity of the CTO roles does seem to depend on the size of the enterprise. This LinkedIn discussion is useful.

Maddy Zhang's "Everything I learned at Microsoft in 9 Minutes"

I was not expecting Maddy Zhang's "Everything I learned at Microsoft in 9 Minutes" to have practical value. Especially with the sad faced, "Be Dumb..." thumbnail. I was wrong. It is awesome. She outlines 7 points that separate being a useful software developer and being a skilled software engineer. Watch the video.

1. "Learn-it-all" beats "Know it all".
2. Design for someone you will never meet.
3. Backwards compatibility is important.
4. Focus on security.
5. Ship, then learn from users.
6. Design constructive criticism.
7. Who survives the AI area.

Update: Her video Agentic AI System Design was HARD until I Learned these 6 Concepts is also very good.

DeepSeek's harness and prefix caches

I've been learning about DeepSeek's harness. At the core of a harness is preparing a prompt for the next round of model interaction. An efficient prompt will take advantage of the inferencing engine's prefix cache. That is, when the characters at the start of a prompt, ie the prefix, matches an existing record in the prefix  cache the inferencing engine can use the cached results to continue processing the remaining portion of the prompt.

DeepSeek's harness has a sophisticated layer managing the prompt. It is composed of an append only log and an undo mechanism. Anything added to the log is accompanied by a means of reversing the addition. The reversal does not change the log; instead it appends to the log instructions about ignoring the addition. When the harness builds the prompt it effectively recreates the previous prompt with new entries appended. The prompt (almost always) has an identical prefix. You rarely pay for the same inferencing twice.

The same log implementation is used to manage its tools (aka plugins) also. This implementation is work done a few years ago and is open source. As is the harness.

Specification "documents"

I have a minor role working on a complex system that has many requirements. Some are monumental. Some are microscopic. They all need to be tracked and, at some point, traced to the implementation. Unfortunately, the specification has no unique, immutable identifiers for the requirements. Without these there is little chance every requirement will be tracked and less of a chance they can be traced.

The specification is a Word document. A Word document is easy to create and update, to distribute, and to read (either online or in print). Word has useful features for conveying specifications -- section numbering, line number, version tracking, etc -- but not for tracking.

This got me thinking about tools like Starkits and Marimo (w/ uv) and using these to convey the specification's requirements and to track them. Ideally these specification "documents" can be as easily created, distributed, and read as Word documents are. They can be run locally by an individual or run on a server and used by the whole team. No need for a third party SaaS. No need for company IT involvement.

I am not naive here. When at Raytheon my team had an engineer working full-time managing requirements in DOORS. What I am thinking about is something between DOORS and the unstructured, backlog of Jira tickets.

I don't have much more to say about this right now. This note is here to remind me of this idea during some future.

Related are my postings Guidelines for presenting a document for discussion and Adding a Table of TODOs to a Google Document.

What has happened to online programming courses?

We all know that Stack Overflow usage has tanked, but what has happened to online programming courses? I assume there was a dip, but is it rising again now that junior programmers are seeing their career hitting a wall?

How AI Impacts Skill Formation

I finally got around to reading the paper How AI Impacts Skill Formation last night. The data is from a very small group of participants, but this is common for these kinds of studies. The summary is that the struggle to understand is necessary even for short term recall. The interaction patterns listed on pages 12-14 are useful, especially so for mentoring and self-learning.

I liked this exoskeleton analogy

For data science tasks, Wiles et al. described the impact of AI on non-technical consultants as an “exoskeleton”, the enhanced technical abilities enabled by AI did not persist when workers no longer had access to AI.

Also fascinating is that in the pilot study some 25% of participants surreptitiously used AI even thou they were told not too. Cheating really is endemic.

Visualization at the edge between intuitive and training

I've had a long term interest in visualization -- mostly implementing other people's designs. I don't believe that all visual tools need to be intuitive; many will need training to use effectively. I think this one is on the edge between intuitive and training needed.

This Widget Forces You to Think - YouTube

Preparing "Approval Tests" for refactoring Python

Emily Bache's short example of preparing "Approval Tests" for refactoring Python code is very good. Not only for the approach, but also for how advanced IDEs like PyCharm greatly support developers common editing and refactoring needs.

Reaction: Arjan Codes wrote tests the HARD way - My way is BETTER - YouTube

Don't look up

If you live in RI your home's electric meter was recently replaced to enable remote access. I have wondered how secure is that remote access? While this presentation does not address the electric meter, it does address how much of our satellite infrastructure is unsecured and accessible with cheap hardware. The presentation is about the available downlink data, but note the presenter's off-hand comment that if you fly a drone between the uplink site and the satellite you could likely gather the uplink data.

39C3 - Don’t look up: There are sensitive internal links in the clear on GEO satellites - YouTube

Update: A friend said it is easy to access the electric meter data for his home ... and his neighbors. Why is infrastructure security still so bad even in 2026!

Liberalism doesn’t necessarily maintain itself

At dinner last night a friend's comment about "being right and being ignored" reminded me (somehow) of this conversation between Cass Sunstein and Tyler Cowen

In particular,

COWEN: Now, your new book On Liberalism is primarily a defense of the liberal concept, but if someone asks you, what’s the most likely scenario for liberalism being self-undermining, what’s your worry?

SUNSTEIN: Low probability. The likelihood is that we’ll be undermined by anti-liberal and illiberal forces, not self-undermining. I think it’s fair to say or to worry that liberalism doesn’t create the conditions for its own self-perpetuation, so it’s not as if it’s self-undermining, but it doesn’t necessarily maintain itself [emphasis added]. The reason is that a society that is flourishing needs a lot of stuff in it, including norms of cooperation, norms of charity, norms of mutual support. Liberalism, in my view, doesn’t undermine those things, but other forces can undermine them, and it’s not clear liberalism has the resources to respond.

Given the times we are in, I do very much worry about our not having the resources to respond.

I enjoy the "Conversations with Tyler" podcast. The participants mostly assume you know what they know and, since I don't, this results in me very often pausing the audio and searching for a primer on what was just said.

Multi-Terra Helio Cell Vehicle

My children would have loved this Multi-Terra Helio Cell Vehicle 407 cockpit control. I especially like the addition of the fans!

Streamlit and a trivial cities explorer

I spent a little time this morning learning the basics of Streamlit. Earlier this month I had found a US cities dataset¹ and decided to use Streamlit to explore city populations. 

This dashboard shows each state's population along with a state selector to dynamically show a state's city's population along with a map showing its location and relative population size. 

While it took me much of the morning to figure out how to use the Streamlit and Pandas SDKs, along with a side-quest on how to debug a Streamlit application in Visual Studio Code, the final application is hearteningly trivial at barely a dozen lines of Python.

1. Unfortunately, the dataset of not very good based on what I know about RI and NH cities and towns.

Jenson's stuck desktop and Foster's recalibration of the futurism

I suspect many of you have seen by now Scott Jenson's presentation "Are we stuck with the same Desktop UX forever?" But, if you have not then it is worth your time. I went on to read the book he mentions Nick Foster's Could Should Might Don't: How We Think About the Future. Jenson's presentation suggests that Foster's book is a "how to", but it is more a useful survey of, and a call for the recalibration of, the futurism field.