Building Software My Way: The Philosophy of an AI Systems Engineer

02 Sep, 2025

When it comes to software, I’ve always approached it differently than most. Not because I want to be contrarian, but because I wanted control, speed, and efficiency. Over the years, I’ve built a personal ecosystem of software that serves my needs first — and it’s taught me more about development, infrastructure, and creative problem-solving than any framework or methodology I’ve studied in isolation.

I like to think of myself as an AI Systems Engineer — not just a backend engineer, or a software developer, or even strictly a machine learning engineer. My world combines all of these perspectives: building systems that are reliable, scalable, and fully under my control. In practice, this means I can go from writing a new feature to deploying it at scale without depending on external systems. It’s self-sufficient software, for a self-sufficient engineer.

The Core Philosophy: Streamlined Autonomy

The first thing I learned in software development is that friction kills creativity. The more time you spend wrangling dependencies, orchestrating infrastructure, or debugging CI/CD pipelines, the less time you have to actually solve problems. My philosophy is simple:

• Automate what doesn’t require thought. CI/CD pipelines, dependency management, containerization — I don’t enjoy these tasks, but I automate them so that I don’t have to think about them.
• Focus on the function. The real work is in writing application logic, designing algorithms, or building systems that actually do what I want them to do.
• Minimize external dependency. I’m not building software for the world; I’m building it for myself. That doesn’t mean others can’t use it, but the primary goal is personal efficiency.

This philosophy informs every choice I make. Tools exist to serve me, not the other way around.

How I Build Software

The stack I use is deliberate: FastAPI for the backend, Go for the frontend, Docker containers for reproducibility. Beyond that, everything else is optional or context-specific:

• Containers first. Every project lives in a Docker container. It solves 90% of dependency hell before it even starts.
• Version pinning when necessary. If dependencies misbehave or roll out breaking changes, I revert to stable versions. I refuse to chase every new release unless it materially improves functionality.
• CI/CD pipelines for speed. Linting, testing, and building are automated. I don’t want to worry about deployments; I want to focus on code.

I have deliberately avoided frameworks or platforms that demand excessive mental bandwidth for trivial benefits. If I can automate a workflow, I automate it. If I can containerize a service, I containerize it. Otherwise, I don’t overcomplicate things.

Observability, Monitoring, and Security

I do pay attention to reliability. For inference applications or data pipelines, observability matters. I usually implement:

• Prometheus + Grafana for monitoring
• Telemetry + logging
• Automated security scans via Dependabot

Critical vulnerabilities are addressed immediately. Medium or low-risk issues are handled ad hoc. My philosophy here is about risk prioritization: I protect what needs protecting, but I don’t waste bandwidth chasing every minor warning.

Collaboration: Hands-Off by Design

I’ve found that collaboration is best handled with clear boundaries:

• Documentation first. Every project has a doc.md and a contributing.md. If someone wants to dive in, the roadmap and reasoning are all there.
• Pull requests and issues are standard. If you contribute, I’ll review and merge if it fits. If not, it’s your choice.
• I’m not building for others. I’m building for myself. Anything outside that is a side effect, not a requirement.

This hands-off model allows me to remain highly productive while still being open-source friendly. If someone wants to follow the ladder, they can. Otherwise, it doesn’t change my workflow.

Stability vs. Extensibility

When I say “stable,” I mean the foundation is unshakable. Everything else is modular:

• I can add features, swap modules, or refactor without destabilizing the core.
• Feature completeness is the benchmark. If a system does what I need, reliably, that’s enough. Everything else is a side effect.
• My systems are designed to be flexible but not frivolous. I experiment deliberately, within the constraints of what I know is productive.

This balance allows me to remain creative while maintaining reliability.

AI Systems Engineering: A Meta Role

What sets my approach apart is the perspective I bring: AI Systems Engineering. I combine backend engineering, ML engineering, HPC thinking, and system architecture. I’m not just writing code; I’m building infrastructure that supports experimentation at scale.

This role requires:

• Understanding dependencies and managing them efficiently
• Orchestrating software so that infrastructure is invisible
• Automating pipelines while maintaining flexibility
• Keeping mental bandwidth free for creative problem-solving

It’s a hybrid mindset that bridges engineering and research, allowing me to focus on the problems that actually matter.

The Goal: Creative Headroom

Everything I do is about maximizing my headspace for problem-solving:

• Automate, containerize, and streamline everything else
• Remove friction from repetitive tasks
• Preserve mental bandwidth for application logic, system design, and experimentation

If I spent my time worrying about every detail of deployment or infrastructure, I’d produce nothing. By designing systems that handle the minutiae, I get back to the core of why I do software: to create, explore, and solve problems efficiently.

Closing Thoughts

I build software for myself. I build infrastructure to support exploration. I build systems to remove friction so that I can focus on the work that actually matters. Collaboration, observability, and security are there to support that goal, not to dictate it.

This philosophy might not scale to a 10,000-person team, but it does scale for the problems I care about: high-speed experimentation, robust inference, and modular infrastructure. By thinking like an AI Systems Engineer, I’ve created a workflow that gives me freedom, flexibility, and focus — and that’s what makes building software worthwhile.

If you’re curious, all my projects are open-source, documented, and available for experimentation. Dive in if you dare, but remember: the ladder is there if you want it; otherwise, the focus is on creating, not supervising.