85 posts tagged with "programming"

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?

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.

As a software engineering director building open source products, I have prohibited my teams from using AI coding assistants due to concerns about intellectual property and questions about the risks and real world effectiveness of AI coding assistants. It is now time to allow and even encourage AI coding assistants, with guardrails.

In reaction to all of the "agile is dead" articles, I am cleaning up old posts about Agile, re-reading them, contemplating lessons learned but forgotten, and asking myself if some practices have outlived their usefulness. That is the spirit of agility: the interplay of action and reflection.

"Agile" is not a silver bullet for improving software productivity, reliability, and simplicity. But "Agile" continues to give us tools that can foster improved software engineering.

The Agile Manifesto was a distillation of certain trends that the authors had noticed in their successful projects. On balance, they ring true to my twenty-five year career in software.

It did not offer guarantees and it did not offer to solve world hunger. Through prescriptive frameworks such as Extreme Programming and Scrum, and common practices such as development of story cards and short cycles (aka sprints), the Agile "revolution" broke us free from the confines of gigantic requirements and design documents that were always at least slightly wrong, and frequently very difficult to change. It helped us embrace the uncertainty of software development, empowering us to find our way out of that wrongness more quickly and productively.

"For the past two years, the Ed-Fi Alliance software development team has been listening to community members through its Technical Advisory Group, Special Interest Groups, and at our annual events. We have been hearing that the pace of change in the Ed-Fi ODS/API Platform needs to accelerate, shifting to a cloud-native architecture that can better support large-scale deployments while offering greater cost and performance flexibility. To do so, we need a reboot."

→ Full article at New Cloud-Native Functionality Coming to the Ed-Fi Alliance Technology Suite

Though barely mentioned in the article, the work to create a production ready system has been dubbed Project Tanager, the third bird-related project name in my tenure with the Ed-Fi Alliance (Roadrunner, Meadowlark).