I Think We're Measuring Software Engineers Wrong.

A developer argues that the software industry is measuring engineers with outdated metrics like lines of code or number of commits, while AI tools have made code generation cheap. The real value now lies in understanding business domains, reducing complexity, and making architectural decisions that prevent future problems. The developer advocates shifting focus from output to impact, such as modeling institutional knowledge and designing maintainable systems.

A few years ago, one question appeared in almost every engineering interview. "How many programming languages do you know?" Then it became: "How many years of experience do you have?" Today it's slowly becoming: "Which AI coding tool do you use?" Cursor. Claude Code. GitHub Copilot. Codex. Windsurf. Lovable. Bolt. The tools have changed. But I think we're still measuring engineers using the wrong metrics. For decades, software engineering rewarded output. More commits. More pull requests. More features. More lines of code. It made sense. Writing software was expensive. Every line represented time. Effort. Knowledge. Today... AI can generate hundreds of lines before you finish your coffee. Suddenly, writing code is no longer the bottleneck. So why are we still acting like it is? This isn't a bad thing. It's progress. Boilerplate. CRUD endpoints. Configuration files. Documentation. Tests. Much of this can now be generated in seconds. The cost of producing code has dropped dramatically. Whenever something becomes cheaper... Something else becomes more valuable. Not syntax. Understanding. Good engineers don't just write software. They answer questions like: How should this system evolve over the next three years? Which service should own this data? What happens when the database is unavailable? How do we avoid duplicating business rules? How do we keep different teams from stepping on each other? None of these questions disappear because AI exists. In many ways, they become even more important. One thing I've noticed while building enterprise software is that AI understands programming surprisingly well. It understands Python. Go. TypeScript. React. FastAPI. SQL. What it doesn't understand is your business . Ask it to generate an authentication service. You'll probably get a good result. Ask it to explain why Customer A can partially pay Invoice B under Contract C while Customer D cannot. Now the conversation changes completely. That's no longer a programming problem. That's institutional knowledge. Every business has rules that never appear in tutorials. Healthcare. Manufacturing. Banking. Insurance. Retail. Logistics. Government. Eventually you discover sentences like: "This customer follows the legacy billing process." Or: "That contract uses a completely different approval workflow." Or: "Invoices created before 2022 are handled differently." None of this exists inside a language model. Someone has to model it. Someone has to protect it. Someone has to maintain it. That's engineering. The engineers I admire rarely impress me because they code faster. They impress me because they reduce complexity. They ask better questions. They see failure modes before they happen. They simplify architectures. They create systems that other engineers enjoy working on. Ironically... Many of them probably write fewer lines of code than junior developers. But every line carries much more value. Some people worry AI will replace software engineers. I think something different is happening. AI is raising the minimum expectation. If everyone can generate CRUD applications... CRUD applications stop being impressive. The differentiator becomes everything around the code. Architecture. Communication. Domain modeling. Reliability. Observability. Business understanding. These aren't disappearing. They're becoming the job. I still use AI every day. Probably more than ever. But I ask different questions now. Instead of: "Write this API." I ask: "What architecture would make this easy to maintain?" Instead of: "Generate a database schema." I ask: "What's the domain model behind this business?" Instead of measuring how quickly I can generate code... I measure how many future problems I can avoid. That single shift has probably saved me more time than any coding assistant ever has. Sometimes we describe senior engineers as people who know more technologies. I'm no longer convinced that's true. Maybe seniority is simply the ability to recognize patterns. To understand trade-offs. To make good decisions with incomplete information. AI can help us write implementations. Experience still helps us choose the right implementation. Those are very different skills. Software engineering isn't disappearing. It's evolving. As AI continues to automate implementation, the profession moves closer to what it has always been underneath: Designing reliable systems that solve meaningful problems. The tools will continue to improve. Models will become faster. Frameworks will come and go. But one thing will remain surprisingly constant. Technology changes. Engineering judgment compounds. And I suspect that's what will separate great engineers from everyone else over the next decade. Over the past several months, I've been documenting how these ideas apply in real enterprise software. Instead of focusing on AI demos, I built a complete Enterprise AI Transaction Intelligence System that covers the entire engineering lifecycle: The complete implementation—including three technical handbooks, production-ready Python source code, synthetic datasets, and architecture documentation—is available here: 📘 Enterprise AI Automation Blueprint 👉 https://uigerhana.gumroad.com/l/enterprise-ai-automation-blueprint https://uigerhana.gumroad.com/l/enterprise-ai-automation-blueprint I'm also publishing a long-form Dev.to series on Enterprise AI Engineering, Software Architecture, and Production AI Systems. If you're interested in building systems that last—not just demos—I hope you'll follow along. Happy building. 🚀