the biggest opportunity i see for the government given recent advances in llms is the obvious one: paying off tech debt.
it seems that most federal applications start accumulating tech debt the moment their dependency chain is locked in for the first time. once `pom.xml` specifies a specific version of Spring, you're never going to see that version increment ever again, forever.
i've seen multiple programs now on aging codebases that... well, really just too old to be maintained anymore. applications whose core dependencies are at least a decade from having gone defunct (looking at you, Stripes). i've seen Apache Struts installations as old as my college days. i actually do spend time, not a lot, but more than none, debugging why newer versions of Tomcat won't play nice with these ancient frameworks. that, too, has been made easier by LLMs being quicker to pinpoint breaking changes across a range of version updates that were never incrementally applied way faster than i can.
the problem is that our security controls are updated, our applications break, and because we don't have the time or the budget to fix our applications; or our development teams just can't figure it out; instead we ask for exceptions. and they're typically granted, resulting in an enterprise software architecture that has varying levels of compliance, and exposes a patchwork of exceptions to potentially exploit.
plus it complicates upgrading later: if our custom Stripes has a bunch of custom patches to keep it operational, when it comes time to upgrade later, how do we merge the new library with our own patches? do we still need them? what if we only need some of them because, say, a particular bug was fixed?
thus it seems to me that the first step as an llm-powered federal software engineer isn't to let the llm take over and do everything as it's been on legacy codebases, but to iteratively pay off tech debt and get our apps closer to current.