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.