This post is an inner monologue about something I’ve been thinking a lot about lately—the thin line between engineering and hacking, and how AI is blurring that line faster than ever. When I say “engineering,” I’m talking about building scalable, reliable systems with thoughtful design. “Hacking,” on the other hand, is about quick, scrappy solutions that just work, even if they’re held together with duct tape and a prayer. But with AI advancing at an insane pace, I can’t help but feel like the distinction between the two is fading. It’s weird, it’s exciting, and honestly, it makes me wonder—are we all just becoming better hackers?
Parallel Code Universes: Industry vs. Academia
After nearly three years “engineering” B2B solutions in the industry, transitioning back into academia felt like stepping into a parallel universe. The priorities that once dominated my day—-scalable systems, reliable code, design patterns, adherence to best practices and tooling—suddenly seemed to vanish. In stark contrast, academia seemed to embrace a more flexible approach, where code quality and scalability often took a backseat to simply making things work. The absence of industry-standard tools wasn’t just striking; it highlighted a fundamental shift in mindset that took some getting used to. It was all about getting things to work.
The Code Multiverse: Engineering vs. Hacking
Stepping into the parallel code-universe of academia felt unsettling at first. My time in the industry had shaped me into an engineer—one who instinctively thought in terms of edge cases, optimal designs, and scalable architectures. Most decisions reloved around: Should this be a factory? No, maybe a singleton. But what if it needs to be extended later? Perhaps the builder pattern is better. Will this scale? It works now, but what happens as complexity grows? I was so immersed in these technical deliberations that I often lost sight of the bigger picture. Looking back, I was obsessing over how to do rather than what to do.
Returning to academia rekindled the art of hacking—of building without overthinking, of exploring without prematurely optimizing. I started experimenting more, rapidly prototyping ideas without fixating on the “right” way to do it. The focus shifted from crafting the perfect solution to simply getting things done, learning through iteration rather than over-engineering from the outset. This shift unlocked new ideas, ones I might have missed had I remained bound by industry’s rigid frameworks.
The contrast between industry and academia gave me a really good opportunity to see both sides of the spectrum. Hackers push boundaries, imagine possibilities, and move fast without worrying about perfection. Engineers refine those ideas, making them robust and scalable. Neither is superior; both are essential …… At least, that’s what I used to believe: Now, I’m starting to wonder!
AI: Uniting the Parallel Universes of Hacking and Engineering
The screenshot you see above is me asking GitHub Copilot to set up a backend server. With just a simple prompt, it generated the whole file structure and the file contents for me. (for those nitpickers, yes, the modules are missing __init__ files, which is a blunder), but if we take a step back from our “engineering” mindset, we can see the magic this just did. With just a plain natural language command, Copilot was able to set up the entire codebase for me. This alone saved me at least 30 minutes to an hour of my time—time I would’ve spent thinking about file structures and writing boilerplate code. Isn’t this simply amazing?
With AI code assistants getting ridiculously good, programming is starting to feel more like natural language. The obscure syntaxes, the high-level abstractions—they’re beginning to make less sense. AI has absorbed nearly every best software engineering practice (don’t worry, no GitHub copyrights were harmed). It’s not far-fetched to assume that AI will soon write high-quality code, reducing the need for as many engineers. What once took an entire team can now be built by just a few people using AI tools.
So, what’s left for us humans? Traditional software development is no longer the gold rush it once was. If AI is handling most of the heavy lifting, what happens to those who were just translating user requirements into code? Some believe there will eventually be no such thing as “software engineers”—that AI will handle all the coding. However, coding, at least for now, is a peculiar language; you have to be incredibly specific to make computers do exactly what you want. David J. Milan’s video on computational thinking is a really good explanation of how coding is an intricate, precise process where the smallest details matter. This level of precision is something only those with a deep understanding of code can fully grasp. So yes, we will still need humans to write code—perhaps in a form that’s more natural and vastly more efficient.
That’s why I believe this shift in software development doesn’t mean human programmers will become obsolete—it means we’ll evolve. Instead of meticulously crafting every function and obsessing over syntax, we’ll be the ones throwing ideas at the wall, hacking together rough solutions, and letting AI refine and optimize them. The role of the engineer will move closer to that of an inventor, an experimenter, a painter—a hacker in the truest sense. Not someone merely following best practices, but someone testing the boundaries of what’s possible.
AI may perfect the code, but humans will provide the messy, chaotic, and creative sparks that drive innovation. We’ll spend less time wrestling with boilerplate and more time pushing the limits of what technology can do. In the end, the future of programming might not be about writing perfect code—it might be about having the boldness to think and build something imperfect and letting AI take it the rest of the way.