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 you’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 was widened to enable a larger number of people to build software who have not been trained or practiced software engineering as a professional disciplined.

There was an implicit assumption that your code would likely only be seen and judged by other software engineers and that they would hopefully have developed the “sniff test” for code that should not be trusted or used with care because its 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 seen and trained by 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 a “grown up” senior engineer 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”.

Yes, the shift has been for your more senior engineers to encode their knowledge 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-above-the-loop workflows where a human engineer may not even see that code before it gets into your customer’s hands.

But spend some time looking at the public Github profiles for some of 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, these repositories are seriously lacking in good software engineering practices around supply chain management and security. They may pin dependencies (which is good) but they’re not using Dependabot automation to keep them updated? 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 that 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.

Can a coding agent do these things? Maybe if you prompted it to. But 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.

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.

I recommend:

  • reviewing all your personal repos, identifying and fixing all the gaps (or at least the “smells” I mentioned above)
  • 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.