What engineers actually think about AI-generated code
My dissertation research in plain language: the question, how I'm approaching it, and what I can say so far about how engineers judge code they didn't write.
Coming soonSenior Software Engineer · Platform & Backend Systems
I build Go and Python systems across platform automation, backend services, developer tooling, and production infrastructure. My work focuses on making systems faster, safer to change, and easier for other engineers to operate.
Three pieces of work that changed how a system behaved, rather than three descriptions of what a team owned.
The service reconciles a Nautobot source of truth against the live network estate. At 20 minutes a run, it was slow enough that nobody ran it on demand — which meant drift was discovered late, by hand, and usually by the person it had already inconvenienced. The goal was not a faster report. It was making reconciliation cheap enough to run whenever someone wanted an answer.
A Python and LangChain pipeline read SQL data, expanded acronyms, and populated missing metadata fields through LLM services — improving completeness and consistency on a data set that had resisted manual cleanup. A separate prototype became a deployed internal tool that searches the bank's software inventory to tell teams whether a capability they are about to request already exists.
Escalation point for enterprise Azure App Services environments across 25 deployed applications: stack-trace and performance debugging with WinDBG and PerfView, and Python and KQL automation that standardised pre-event environment checks and cut manual review time by 15%.
I'm a doctoral candidate studying how software engineers perceive AI-generated code — and I've twice taken an AI-built prototype and rebuilt it into something a team could actually run. These are notes from both halves of that.
What was actually slow in a source-of-truth reconciliation service, why the correctness bug and the performance bug were the same bug, and how I verified it.
Read the case study →My dissertation research in plain language: the question, how I'm approaching it, and what I can say so far about how engineers judge code they didn't write.
Coming soonA prototype that demos is not a system that runs. What survived the rewrite, what had to go, and which parts of the original were worth keeping.
Coming soonPlatform work at Ticketmaster, plus two things I build and maintain on my own.
Custom Nautobot applications that extend a production source-of-truth platform with new data models, views, and jobs, carrying team-specific network automation workflows that the stock platform doesn't cover.
Production, at workA modular static-site generator: Markdown and front-matter processing, HTML templating, RSS generation, and filesystem automation — with tests that exercise failure paths and GitHub Actions CI enforcing format, vet, and a clean build.
github.com/beedawn/surgepress ↗A Dockerized full-stack application that collects academic literature, scores it for relevance in natural language, and lets you explore the results from a dashboard.
github.com/beedawn/scrapescholar ↗Eight years of technical work; the last two titled software engineer.
Go and Python platform automation on a Nautobot source of truth: configuration generation, three new pipeline subsystems, custom Nautobot apps in Python and Django, and a migration of network observability from SolarWinds to Grafana over SNMP and Telegraf. I review the team's Go and Python, and trained the wider network group on the platform.
Python and LangChain pipelines that processed SQL data and enriched metadata through LLM services, Python automation for CIDR-range validation and firewall checks, Selenium regression suites for API endpoints, and production support for an application on Red Hat OpenShift including disaster-recovery testing.
Escalation point for enterprise Azure App Services incidents. Stack-trace and performance debugging with WinDBG and PerfView, plus Python and KQL automation that standardised pre-event environment checks. Contract via Insight Global.
Built and deployed a backend service for encrypted personal-data processing, containerised on Kubernetes in GCP with Oracle behind Java Spring and Hibernate. Automated vulnerability remediation across 200+ servers with Ansible, PowerShell, and Python.
Where the automation habit started: a React billing tool for technicians, Python and PowerShell provisioning across a 450-user environment, and log-and-SQL diagnosis on mission-critical emergency-response systems under strict SLA commitments.
What I reach for, and what I'd want to be hired to build.
Backend services and the tooling around them
Building the platform other engineers deploy onto
Part-time and self-funded, alongside full-time engineering work.