Blog on Dustin Burke

Being unusually responsible as a professional software engineer

Sat, 04 Jul 2026 00:00:00 +0000

I’m realizing that as a professional software engineer (someone who has accepted pay to create software), the bar has been raised for how we conduct ourselves, especially when working in the open in front of other builders. If we’re creating software that will be seen by other software engineers - whether open source or internal to your company - we need to spend a little extra effort and tokens to do the right thing.

Why?

Practicing what you preach and modeling good behaviors was always important when mentoring junior engineers. However, now the field has widened to enable a larger number of people to build software who are not professional software engineers.

There was an implicit assumption among engineers that your code would likely only be seen and judged by other software engineers. Those engineers would hopefully have developed - with practice and coaching - the “sniff test” for code that should not be trusted or used with caution because it’s clearly not production ready. No automated tests? No CI/CD pipeline? No documentation for users or developers to contribute? Lack of recent contributions. Unpinned or outdated software dependencies. Unclear or messy code organization. There are a lot of “tells” that you can quickly scan a codebase for, without even needing to go deep on the implementation details.

However, now your code will be seen by a lot more people who haven’t trained their nose to sniff out bad code. Or maybe it will be used by a coding agent, or worse - used as training data for LLMs. In both cases, this will reinforce bad behaviors rather than good practices for new software that is generated by humans and agents.

As a profession, we’ve eschewed formal certification or licensing to become a software engineer, instead relying on guidance from “grown up” senior engineers in the room to ensure the right things are done and the business is kept safe. That used to be release managers, QA and tech leads who approved what got merged into the main branch and released to customers as the “gatekeepers”.

Now, the shift has been for more senior engineers to encode their wisdom into the “agent harness” that will steer not only human engineers but also coding agents. This is even more critical now that code can be generated so quickly which puts a lot more downstream strain on your senior engineers to review all that code and uphold the standards. And teams are shifting to agent-assisted reviews or human-over-the-loop (rather than human-in-the-loop) workflows where a human engineer may not even see that code before it gets into production and used by customers.

But spend some time looking at the public Github profiles for the hyper-productive software engineers who drum up hype for AI engineering practices that are making human engineers “cooked”. (I won’t shame any individuals, but IYKYK who I’m likely referring to…) You’ll notice a disturbing trend that although they are churning out hundreds of contributions per day across dozens of concurrent agent sessions in agent loops, the quality and maturity of these repositories are seriously lacking in good software engineering practices around supply chain management and security. They may pin dependency versions (which is good) but they’re not using Dependabot to keep these dependencies updated automatically? No Trivy or Grype scanner for CVE security vulnerabilities? No static analysis (SAST) tool like Semgrep to identify insecure coding practices (and there are a LOT of them so its very hard to remember all of them or realize you’re even suspectible to them…). Or gitleaks to prevent accidental inclusion of secrets in the codebase. Dockerfiles that aren’t multi-stage builds and based on hardened container images from Docker or Chainguard to minimize the surface area for vulnerabilities.

Can a coding agent do the right things? Maybe, but it takes a human to give it the appropriate steering. And we built these deterministic tools for a reason and they do the task very well, so even coding agents should be using them.

We should be shifting all the guardrails and “scorecards” for ensuring production quality software to be pre-commit hooks run on every git commit - whether by a human or agent - rather than relying on post-hoc discovery. This is the “shift left” mentality from DevSecOps, but its even more relevant these days with AI-native engineering that has accelerated the inner loop of code generation.

I’m working on an open source tool generates a scorecard for any Github repository - github-repo-scorecard. It integrates existing scorecards from the open source community. It’s available as a browser extension so you can see the scorecard directly in Github when navigating to a repository. You can also use the scorecard tool from the command line or integrate it with your coding agent using MCP.

What I’m saying is we need to practice what we preach. And that means applying the same standards to all the code we write, not only the blesssed repos for the core product. Even the one-off side projects.

I recommend:

reviewing all your personal repos, identifying and fixing all the gaps (or at least the “smells” I mentioned above)
at least putting a disclaimer in the README to explain whether the code is alpha, beta or production quality so that others don’t make incorrect assumptions just because the repo looks polished.
creating a reusable Agent Skill that can make fixing up your repos easy work.
updating any repo bootstrap templates you use so all the best practices work out-of-the-box, deterministically, every time.
normalizing not only git “badges” but also a “production readiness scorecard” directly in the README for the repo so builders can immediately understand the risks and gaps

Inspired by the mantra to “be the change you seek”, I’ll be spending some time getting my own repos into shape. You should do the same.

Maybe we need to embrace the hippocratic oauth of software engineering or the ACM’s Code of Ethics and make it required reading for all builders. Or at least for professional software engineers, as a starting point.

KPI = metric + target

Sat, 30 May 2026 00:00:00 +0000

Metrics are not KPIs!

Key Performance Indicators (KPIs):

Key - these are the most important things to pay attention to
Performance - based on some outcome you want to happen
Indicators - for meaningful insights about the raw numbers and how to interpret and act on them

Contrast that with a metric. Metrics are just a number. A measurement. Data, not information. They don’t have any meaning beyond that. You have to interpret metrics to derive some meaning from them.

Just because you measure something doesn’t make it a KPI.

KPI = metric + target

A KPI does involve some metric. But it also needs some target to indicate the value (or range) which is “good”.

Think 📈 + 🎯. Plot the metric as a line on a graph and the target could be a horizontal line. Maybe the metric is revenue ($) and the target is some specific $ARR that your business is aiming to grow quarterly sales.

A metric moves up and down over time. A KPI moves into or out of the target range over time.

A KPI could have multiple metrics that are used to determine the desirable target range. You might shoot at a target but fall just below the bullseye. The x-axis metric was on target, but not the y-axis metric.

Some metrics are useful for diagnostic purposes. They allow you to break down the components and drivers which influence the KPI.

Why did the arrow fall short of the bullseye?

Arrow speed was too low? ➡ pull the bow back more strongly next time
Wind speed was stronger than anticipated? ➡ aim higher next time

Metrics need to be interpreted. You need to understand the dynamics for how all the factors interact and influence each other.

It surprises me how often people confuse this and misuse the word KPI. Maybe they come up with a list of KPIs for things that are actually just metrics and not directly related to the outcome they want. And often I’ve found, it’s not even clear what they want to achieve, or why.

If you find this interesting, you should read the book Measure What Matters. I highly recommend it. It introduces the idea of Objectives and Key Results (OKRs) which were all the rage in business for the last decade or so. I’ve seen more unsuccessful uses of OKRs over the years than successful examples. If you keep in mind the core insight I explained above, you’ll be more likely to hit the mark.

Writing as a human, and the AI pledge

Sat, 30 May 2026 00:00:00 +0000

You’ll notice there are no emdashes or excessive use of emojis here. That’s because it’s written by a human at about 20 tokens per MINUTE rather than an AI at hundreds of tokens per second.

I think it’s great there are movements like Verified Human and Not By AI to “pledge” and visually indicate that content has been written by a human instead of AI.

However, there’s more we need to do. It should be more than the (raises right hand) “honor system”. We should have these be verifiable in an automated and cryptographically sound way. There’s nothing stopping bad actors or AI from including these badges in their own work, so it doesn’t truly help identify authentic human creative work. Without this, we will lose the ability to discern what is true and authentic.

The idea of AI Watermarking is promising, but there are practical limitations. There is a challenge to get the growing number of AI model providers to comply. And that compliance needs to have repurcussions to hold them accountable. And that would need to be bound by international law so its not confined to individual nation states. Even if we solved the compliance challenge with human institutions across the world, it’s trivial for a bad actor to work around it and use an open source AI model to remove watermarks.

This sounds like a wicked problem without a clear solution, or even a framework for how to solve it. But I think it’s important we come up with a framework for how to solve it. Socio-technical problems at the intersection of humans and technology are the hardest ones to solve.

Even if we can’t cover 100% of all content with a watermark that certifies whether human or AI generated, making progress on having some critically important spaces in which the content in that platform can carry those guarantees would be a meaningful step forward.

Think places where the authenticity of the content has high consequences if we don’t get it right. Evidence presented in court that has legal consequences that impact people. Information used to make life or death decisions, such as medical imagery. Information used to make critical decisions for the successful functioning of human institutions, such as government voting records. Maybe the content shown on the television or in a social media feed, which might not have immediate consequences but has a compounding effect of manipulating and influencing large groups of people to act a certain way or form a certain opinion.

A necessary part of the solution would be end-to-end custody from production to consumption of the content, with a chain of trust that extends across all intermediaries from how that content gets transmitted from the originator who created it to the person that receives it. So it can’t be manipulated and distorted. Much like end-to-end encryption chat and video provided by WhatsApp and Signal to protect the privacy of your information as it flows through many computer networks across the world. I think these platforms are actually best positioned to solve this. But the hardest part is the producer side where the content is originally authored.

Upgrading my website, with Claude's help

Fri, 29 May 2026 00:00:00 +0000

My website was stuck in the early 2000s. GoDaddy, Dreamhost, SFTP, and an .htaccess file! I kid you not…

It’s great to see old school webhosting companies survive all these years. But there are nicer tools available nowadays.

Time for a fresh start. Cleaner layout. A space for me to write and share ideas.

I started as a freelance web developer in high school. I loved creating sites directly in HTML, CSS and javascript. And PHP when I needed. No frameworks. Just a text editor, some SFTP client, and a server somewhere hosting my files. I remember when it was so easy. The hardest part was setting up the DNS. Mostly you wrote content and added a little bit of markup to style it nicely. Then over the course of time things became much, much more complex, as inevitably happens. Isn’t there some law of physics that entropy always increases?

I couldn’t be bothered to spend time working on improving my website. Most of my time and energy went to raising a family and working as a professional software developer in a fast moving industry (that continues to accelerate). Just like the cobbler’s kids with poor shoes…

But now with Claude and some AI model trained on the entirety of human written knowledge and code at my fingerpoints, I figured its time to upgrade. And I didn’t have to spend a lot of mental cycles on it.

I had Claude do all the heavy lifting to help me decide on the right framework for blogging. That would have taken me the better part of the weekend to read a bunch of articles online, read the docs for a handful of the tools and frameworks, etc. But we got it sorted in like 20 minutes.

Together we settled on the following tech stack:

Sublime Text editor to write directly in Markdown without any distractions (or AI agents)
Hugo
Git and Github for hosting
Netlify hosting

I kept DNS at GoDaddy, but pointed the nameservers at Netlify.

Netlify is integrated with Github and automatically triggers on push to master branch. It deploys my changes live in ~10 seconds. It’s amazingly fast and simple.

I used to say at work “I remember the good old days of just SFTPing some files to a server” in the midst of some complex code deployment issues. But I have to say this workflow is an even better experience.

I can run hugo server locally with a super fast live reload experience. I can preview the Markdown directly in the editor or see the site live in my browser.

Honestly, the hardest part was not getting tempted by Wordpress, Medium, Substack, Ghost and all the many other blogging options available.

Keep it simple, silly (KISS 😘).

Booting up

Mon, 25 May 2026 00:00:00 +0000

I’ll be using this space to write about human-centered AI, technology trends shaping the world and our place within it, and the craft of software engineering while humans are still fluent in programming languages before the machines take that away from us.

I’ve long envied people who have maintained a blog for many years. Some people have been blogging for 20+ years and are still active! I’ve had many false starts over the years and it never took off. I have a pretty extensive collection of ideas and partially formed thoughts in my journal which I have been diligent about contributing to for about 20 years now. I plan to start shifting more of my work into the public space to shape ideas and future directions. And if nothing else, maybe my words will have some infinitesimal influence on a few of those billion model weights in some future AI model.