A normie software engineer in the age of code generation

I must confess that I was mostly skeptical of LLM-powered coding tools in the beginning of 2025. A year later, I’m a happy user of Cursor, Claude Code, and similar tools offering agentic code generation and execution capabilities. I don’t do much experimentation—no vibe coding, no several agents running in parallel, no dozen different MCP servers, no carefully curated set of skills, no Ralph Wiggum. I just open my editor, start a coding agent in the terminal, do a bit of back-and-forth to plan, have it executed, review the changes, and iterate.

I am a normie software engineer working on normie enterprise software written in normie languages (web UI in TS/React and backend service in Java), so LLMs work rather well for my normie workflow. That said, I can’t take it seriously whenever I hear the declaration that software engineering is about to be fully automated and we’re all cooked in 6 to 12 months… because I’m sure to hear the same prediction 6 to 12 months later. These estimates are worse than the story points on JIRA tickets I’ve written. I get that companies need to defend their valuation and raise more money, but let’s be honest. The frontier models are only just getting good enough at churning out working code, let alone software engineering.

The ability to generate code quickly is mostly a win, but translating requirements into code is only a part of my job. The reality is that, as a software engineer, I remain accountable for any code I merge into the codebase regardless of how the code was written. Even when “AI” produces 100% of the code, I am still the author because the agent acts on my behalf, under my guidance, and the decision (even if automated) to ship it to production is ultimately mine.

Of course, this is hardly an original thought. As the classic quote (reportedly from an IBM training in 1979) goes:

A COMPUTER CAN NEVER BE HELD ACCOUNTABLE

THEREFORE A COMPUTER MUST NEVER MAKE A MANAGEMENT DECISION

Replace “management” with “engineering.” True back then, still true in 2026.

This brings us to the real risk of fast, automated code generation at scale: it’s easier than ever to lose touch with the code I’m held accountable for when coding agents will happily pump out thousands of lines of code in minutes. How can I, a mere human, avoid drowning in the tsunami of LLM-generated code while staying productive?

Fortunately, scaling code is not entirely a new problem, and our industry has long worked to tackle this efficiently. Even before the rise of LLM code generation, no individual could fully understand every line of code for any sufficiently large codebase. The Linux kernel didn’t need LLM to reach 40 million lines of code—no single engineer can possibly understand it all, yet our world runs on Linux. What matters isn’t engineers knowing the codebase line by line, but that the software behaves as expected, and the engineers who maintain it can review and understand the code and its history when necessary.

Indeed, we have many great tools and techniques for this: automated tests to ensure code does what it’s supposed to do, version control systems to track changes in the codebase with clear attribution, branching strategies to facilitate parallel work, code review to maintain quality while enabling collaboration, statically typed languages to improve compile-time guarantees, powerful IDE features to navigate the complex codebase with ease… And that’s just at the level of code. For systems in production, we have a mature infrastructure and tooling ecosystem that supports scalable, observable, and fault-tolerant deployments, and continues to power today’s software industry. The same tools and practices allow us to leverage LLM code generation without losing control.

The accelerated pace of generating code and the escalating consequences of failing to uphold professional standards only highlight what I bring to the table as a software engineer: being accountable for working software products. As long as LLM code generation doesn’t distract me from meeting standards, I remain a happy user. My real concern isn’t AI replacing my job but the AI bubble crowding out investment in real engineering—both technology and human talent—but that’s a story for another day.