88 posts tagged with "programming"

Reflections from the conversation at Data and AI Weekend 2026, on the subject of measuring AI adoption.

In brief:

• Measure business value, not minimum use
• In addition to monetary cost, there may be such a thing as too much use
• Conversations with the LLMs risk short-circuiting conversations with co-workers
• Measure the human element — what we bring and share in an artificially intelligent workplace

A conference focused on the hallway conversations rather than the slide decks?

Is that going to work?, I kept wondering.

Answer: a resounding YES.

While the speakers at prior Data Days were always terrific, this (mostly) conversational format delivered so much more in terms of practical ideas and deep questions for continued reflection.

I can read the speakers' books and blogs or listen to their podcasts on my own. But the conversation with all of you made it so much more interesting.

For those who led the sessions: thank you for your time, your insights, and seeding the questions that got the ideas flowing. For the participants: thank you for a weekend of inspiring conversations. And a special shout out, blessings, and gratitude for Lynn Bender pulling it all together.

The economics of such an event are difficult. Keeping my fingers crossed that Lynn still has the heart — and the business model — for Data and AI Weekend in 2027.

TL;DR summary: Docker Sandboxes are a convenient and effective means of safely running a coding harness in permissions bypass mode.

YOLO is now (dangerously so) the norm​

Running coding harnesses in YOLO (bypass permissions) mode has become the new norm:

• Configuring the right permissions is "hard" (read: tedious), especially when you throw in git worktrees that cause compound commands (cd <worktree> && <take an action>).
• Approving permissions demands attention: it is stultifying and ruins much of the benefit of using a coding agent - letting it run while you go do something else.

In YOLO mode, the coding harnesses in summer 2026 seem to be very good at preventing the agents from reaching files outside the code repository; in all of 2026 I do not think I have denied permission to anything, and my spot-checking of the logs revealed nothing concerning.

Then again, they might just be very good at hiding their tracks... see recent news about agents "escaping" to crack into other companies.

From time to time I pop in to peek at one of the dozens of pull requests that come through my mailbox daily, furthering the work of the Ed-Fi Alliance to help connect student data. What feature, improvement, or bug fix are the teams working on? How has this engineer approached a given problem, what tests have they written, what documentation have they provided, are the I/O seams sufficiently fault tolerant? Did they run the GitHub Copilot Code Review Agent, and fix the issues detected there?

Updated October 2026

These notes are adapted from a lunch-and-learn at the office, intended to socialize terminology and some lessons learned in recent months.

For all of last year, I wondered why anyone would use the CLI version of Claude Code and similar tools. I asked a colleague about this a couple of times, and still had trouble getting it.

Until I sat down and used the CLI to perform my work. As a knowledge worker, if you haven't used copilot or claude or (favorite tool) in the terminal, you are truly missing out.

🔝 Top 3 reasons I like this experience:

GitHub Copilot Coding Agent is an impressive and powerful tool for "autonomously" completing development tasks running in GitHub's environment. Like any tool, there is a learning curve ahead before any of us become truly high functioning, beginning with the statement of a well crafted prompt.

⚠️ But I have a concern: lack of commit signing. Should that stop us from adopting Coding Agent? TL;DR conclusion: time to relax the commit signing requirement.

GitHub CoPilot recently promoted Agent mode as a full feature in VS Code. Many writers and commenters in the blogosphere think competitors are still better; perhaps they're right. But this is the one I have, and Microsoft is innovating rapidly - seeing that first hand at Microsoft Build even as I type this. So in recent days I've performed three initial experiments that I want to share. Not because I'm doing anything brilliant: just trying to find tasks that might be a good fit, learn how to interact with the tool, and share a bit to help others in my proximity.

Lesson: be patient, and be in a learning mode. Not just waiting for it to finish (might take several minutes), but also in getting the right results. I remarked on a failure (below) to my colleague Jason Hoekstra; he suggested that I simply undo and try again. It was the right advice. Experiment and build an intuition.

Below I describe three experiments and outcomes.

Containerization of an application benefits operations of the application by solving the problem of "it works on my machine" (at least, for the application itself). The container holds the operating system and all needed components. Once you have Docker on a host - whether localhost, on-prem data center, or in the Cloud - you can run the application with greater confidence, knowing that the application will execute the same in all environments.

But the benefits of containerization can also shift left in the development lifecycle. For example: have you ever needed to revisit an older application, and realized that you don't have the SDK on your machine? Instead of installing the SDK locally, you may be able to run the SDK in a Docker container.

Following up on Grudgingly Accepting AI Coding Assistants, I have a small win from my first experiment with GitHub Copilot: a Python script for converting portions of an Open API specification file to a CSV. There is nothing revolutionary in this small win; countless programmers have doubtlessly done much more. But a reluctant engineer has to start somewhere.