Is Your Org Ready For Agents

Listening to this video and feeling inspired. It's crazy how the Conference ==AI Engineer== feels like such a hype bro conference ready to tell you just do...

Copy this post

Editorial history

  1. gpt-6-lunacopy editorEdited

    Imported GPT-6 Luna copy edits after the owner confirmed exclusive authorship of these post diffs.

    d3b1fe70

    Attribution recorded by gpt-6-codex.

Editorial history (1)
  1. gpt-6-luna — copy editor (edited)

    Imported GPT-6 Luna copy edits after the owner confirmed exclusive authorship of these post diffs.

    Attribution recorded by gpt-6-codex.

    File at this revision Open diff in GitHub

Listening to this video and feeling inspired. It’s crazy how the Conference AI Engineer feels like such a hype bro conference ready to tell you just do more, let go, you’re cooked if you’re not on the train, gaslighting you to believe something they lack evidence for. But what it really is, is a group of talks that are done by some of the best engineers trying to make it through this transition just like the rest of us. Drawing the lines between the past and the current. How do you get comfortable with the current without letting go, without giving in to shipping slop, but shipping real good work with confidence.

https://youtube.com/watch?v=Se8jHLliLXE

It turns out that good Developer Experience is also good Agent Experience

Checklist #

I’m sure I’m missing a lot here, but this is what I’m thinking off the cuff. If you dont have these you need to rethink the first job for your new agents to begin work on your codebase.

  • testing, linting, sast, type checking
  • continuous integration
  • continuous delivery
  • local development
  • Monitoring with logs, spans, and traces
  • flexible infrastructure

Testing #

do new changes cause regressions to working features

Can you, to the best of your ability, say what you are about to ship is of high quality and provides new features with fewer bugs? Can you prove that your code compiles? Can you prove that your code is not going to shit the bed given a valid input type from the user?

CI #

Everything done in testing, done automatically and blocking merge into the main branch.

CD #

Once you have passed all of your tests and made the merge, do you have a system to build good reliable repeatable artifacts. Does it include the smallest possible surface area for attack, thinking heavily about supply chain attacks at this point in time.

OTEL #

Monitoring with logs, spans, and traces

Can you see bugs in production, who is affected by them, and make good decisions about how to fix them, what to fix, and whether to roll back or fix forward?

Flexible Infrastructure #

Can you roll back quickly?

Can you roll out a new release quickly?

Connections

Related tags and posts connected to this entry.