TL;DR
LLMs can generate code 12x faster than humans can type, and they’re getting better every month. But here’s the twist: the best engineers aren’t worried about AI replacing them. They know that code was never the bottleneck. Architecture was. Standards were. Maintainability was. In the age of AI, your value isn’t in typing faster or memorizing syntax. It’s in knowing the patterns, defining the boundaries, and structuring systems so that whether a human or an AI writes the code, it doesn’t turn into an unmaintainable mess six months later.
The Question Nobody Wants to Ask
There’s a weird divide happening in software engineering right now.
You’ve got one group of engineers looking at AI-generated code and calling it complete slop. Unusable. Garbage that’ll haunt your codebase for years. Then you’ve got another group absolutely blown away by what these models can do, shipping features at breakneck speed and wondering why everyone else is still typing out boilerplate by hand.
So which is it? Is AI the revolution we’ve been waiting for, or is it just really fast at producing tech debt?
The answer, like most things in engineering, is: it depends. And what it depends on matters a lot more than you think.
The Speed Gap Is Real (And It’s Only Getting Bigger)
Let’s talk numbers for a second.
A human can blur-type around 100 words per minute if they’re really going for it. An LLM? It generates roughly 50 tokens per second. That’s about 20-25 words per second. Do the math. That’s 1200 words per minute. Twelve times faster than you on your best day.
And the code? It’s not just gibberish. It’s reasonably well-structured. It follows conventions. It handles edge cases you might have forgotten about at 2 a.m. when you were three coffees deep into a bug fix.
But here’s the kicker: it’s getting better. Every single month, a new model drops and suddenly it’s the smartest model in the world. Remember when ChatGPT 4.0 came out? Then Claude Sonnet 3.5 appeared and blew everyone’s mind, achieving 92.0% on the HumanEval benchmark compared to GPT-4o’s 90.2% [1]. Then 3.7 tightened things up even more. Sonnet 4 was a leap. Opus 4 became an absolute beast for coding tasks. And now Claude Sonnet 4.5 is here, currently holding the crown as the best coding model available, while OpenAI’s o1-mini scores an impressive 96.2% on HumanEval [2]. Soon Gemini 3.0 will launch, and who knows, maybe it’ll take the top spot.
And remember this: right now, today, this is the worst these models will ever be. This is the baseline. From here, it only gets better.
Yet people are still dismissing it. „It’s AI-slop.“ „The code is terrible.“ „I’d never ship that.“
Meanwhile, other engineers are shipping production code written almost entirely by AI, and their users can’t tell the difference.
How is this even possible?
Why Some Engineers See Gold and Others See Garbage
The divide isn’t about skill level. It’s about domain.
If you’re working in a niche area with sparse documentation, limited open-source examples, and highly specialized knowledge, LLMs struggle. Think embedded systems. Game engine internals. Proprietary hardware drivers. Cutting-edge research implementations. There just isn’t enough training data for the model to lean on. It’ll give you something, but it’ll be wrong in subtle, dangerous ways. And experienced engineers in those domains can spot it immediately. To them, AI-generated code is a liability, not an asset.
But if you’re working in web development? Web 2.0, Web 3.0, REST APIs, CRUD apps, React frontends, Node backends? There’s an ocean of training data. Millions of repositories on GitHub. Decades of Stack Overflow answers. Endless blog posts and tutorials. The patterns are well-trodden. The solutions are documented.
We used to steal our code from Stack Overflow and GitHub anyway. Now the LLM does it for us, faster and more coherently.
So if you’re in that world, and you’re still writing every line of boilerplate by hand, you’re playing the game on hard mode for no reason.
The Dirty Secret: Code Was Never the Bottleneck
Here’s what nobody talks about: code has never been the hard part.
Seriously. Go look at any failed project. Any codebase that collapsed under its own weight. Any team that spent six months refactoring instead of shipping features. The problem was never „we didn’t type fast enough.“
The problem was always architecture. It was boundaries. It was unclear responsibilities. It was coupling. It was tech debt that compounded because nobody had a plan. A 2018 Stripe study found that developers spend almost one third of their time dealing with technical debt, with an estimated $3 trillion impact on global GDP [3].
Now we have LLMs that can generate code faster than we can even read it. And if you think that makes the architecture problem go away, you’re in for a rude awakening. It makes it worse.
Because now you can create a mess at 12x speed.
You can generate thousands of lines of tightly-coupled spaghetti code in an afternoon. You can build an entire feature that works today but will take three engineers two weeks to modify six months from now. You can ship fast and regret it faster.
This is exactly what happens when companies try to scale by hiring a bunch of junior developers and throwing them at a codebase with no structure. A few senior engineers who actually know the patterns have to come in and create guardrails. They define the architecture. They set the standards. They establish the boundaries so that everyone can work in parallel without stepping on each other’s toes. As Uber documented in their engineering blog when transitioning to service-oriented architecture, „Adding new features, fixing bugs, and resolving technical debt all in a single repo became extremely difficult. Tribal knowledge was required before attempting to make a single change“ [4].
LLMs are those junior developers. Incredibly productive. Surprisingly capable. And absolutely terrible at long-term planning.
What Actually Matters: Architecture and Boundaries
If you want to scale your output with AI, you need to know your patterns. Not just „I’ve heard of microservices.“ I mean really know them. Know when to use them. Know when not to.
Do you understand vertical versus horizontal slicing? Can you articulate the difference between a transaction script and a domain model? Do you know when event sourcing makes sense and when it’s overkill? Can you argue for a modular monolith over microservices, or vice versa, depending on the constraints? Shopify chose to evolve into a modular monolith with over 2.8 million lines of Ruby code, realizing that „all the things they liked about their monolith were a result of the code living in and being deployed to one place, while all the issues they were experiencing were a direct result of a lack of boundaries between distinct functionality“ [5].
Because here’s the thing: LLMs don’t have opinions on this stuff. They’ll do whatever you tell them. If you ask for a microservice, they’ll generate one. If you ask for an active record pattern, they’ll give you that too. But they won’t tell you if it’s the right choice. They won’t warn you that you’re about to make your life miserable in three months.
That’s your job now.
You need to define the target picture. You need to decide how the system will scale to hundreds of thousands of lines of code and dozens of features without turning into an unmaintainable nightmare. You need to set the boundaries and define the contracts between them.
And you need to do this before you unleash the code generator.
Because once the code exists, it’s exponentially harder to fix. You can refactor a bad function. You can rewrite a bad module. But rearchitecting an entire system? That’s a multi-month project that nobody wants to fund. As Martin Fowler notes in his canonical guide on microservices, „many, indeed most, situations would do better with a monolith“ and „if you don’t have certain baseline competencies, you shouldn’t consider using the microservice style“ [6].
Test-driven development isn’t just a nice-to-have anymore. It’s a survival strategy. When you define your tests first, you’re defining contracts. You’re establishing what each piece of the system is supposed to do. You’re creating boundaries that make it safe to change one part without breaking another. TDD follows the Red-Green-Refactor cycle: write a failing test, write just enough code to make it pass, then refactor both test and production code [7]. This process not only ensures correctness but also helps evolve the design and architecture of the system.
And those boundaries? They make it possible to load just the relevant context into an LLM and let it implement feature after feature without needing to understand the entire codebase.
The LLM Has the Same Problem as Your Junior Dev
You know what the hardest part of onboarding a junior engineer is? Context.
They don’t know where things are. They don’t know why decisions were made. They get lost in sprawling codebases with hundreds of files and thousands of functions. They make changes that seem reasonable in isolation but break something three layers away.
LLMs have the exact same problem. Worse, actually.
An LLM has a fixed context window. There’s only so much code you can feed it before it hits the limit. It can’t „remember“ the whole codebase the way a senior engineer gradually builds a mental model over months. It sees what you show it, and that’s it. While context windows have grown from 4,000 tokens when ChatGPT launched to 128,000 tokens today (roughly a 250-page book), models suffer from the „lost in the middle“ problem where they perform best when relevant information is at the beginning or end of the input, with degraded performance when critical details are buried in long contexts [8][9].
If your code is well-structured with clear boundaries, you can show it just the relevant module. You can load the interface definitions, the tests, and the implementation file. That’s enough. It can do good work. This is where architectural patterns like hexagonal architecture (also known as Ports and Adapters) shine, separating core application logic from external dependencies through well-defined interfaces [10].
But if your code is a tangled mess where everything depends on everything else? You’re cooked. You can’t give it enough context to make safe changes. It’ll write something that compiles but breaks production in ways you won’t notice until 3 a.m. when the pager goes off.
This is why the experienced engineers who call AI-generated code „slop“ aren’t entirely wrong. They’re working in codebases where the AI can’t succeed because the codebase itself is the problem. The AI is just making it more obvious.
Your New Job Description (Whether You Like It or Not)
We’re not just feature factories anymore. The era of „someone hands me a Jira ticket and I implement it“ is fading fast.
Your value now comes from foresight. From knowing the patterns. From understanding what happens when you scale. From being able to look at a proposed solution and say „this will work today but hurt us in six months“ or „this looks complicated now but will pay off when we add the next ten features.“
You need to know the standards. You need to know the architecture patterns. You need to be able to design systems that are maintainable not just by you, but by AI, by junior developers, by anyone who comes after you. As Google’s code review guidelines emphasize, „reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect“ [11]. The focus should be on continuous improvement, not perfection.
Because the world is evolving fast. The models are getting better. The tools are getting more powerful. And if you can’t keep up with the speed, you’ll get left behind.
But if you know the basics, if you can define the structure, if you can set the standards, you’re not getting replaced. You’re getting amplified. You’re going from writing code to designing systems. From being a developer to being an architect in the truest sense.
The AI can write the code. Your job is to make sure it’s the right code, in the right place, for the right reasons.
The Bottom Line
Code is cheap now. It’s getting cheaper every month. Soon it’ll be almost free.
But architecture? Standards? The ability to look at a system and know how it needs to be structured to survive the next two years of feature requests? That’s not getting cheaper. That’s getting more valuable.
The engineers who thrive in the age of AI won’t be the ones who can type the fastest or memorize the most syntax. They’ll be the ones who know the patterns. Who understand the trade-offs. Who can set up the guardrails so that whether a human or a machine writes the code, it fits into a coherent, maintainable system.
So learn the basics. Really learn them. Not just the names, but the why. Not just the patterns, but when to use them.
Because the tools are evolving faster than ever. And the only way to keep up is to know what actually matters.
And spoiler: it was never the code.
References
[1] Vellum AI (2024). „Claude 3.5 Sonnet vs GPT-4o: Comparison Analysis.“ Vellum AI Blog. Retrieved from https://www.vellum.ai/blog/claude-3-5-sonnet-vs-gpt4o
[2] MarkTechPost (2025). „The Ultimate 2025 Guide to Coding LLM Benchmarks and Performance Metrics.“ Retrieved from https://www.marktechpost.com/2025/07/31/the-ultimate-2025-guide-to-coding-llm-benchmarks-and-performance-metrics/
[3] Stack Overflow Blog (2023). „If you want to address tech debt, quantify it first.“ Retrieved from https://stackoverflow.blog/2023/08/24/if-you-want-to-address-tech-debt-quantify-it-first/
[4] Uber Engineering Blog. „Service-Oriented Architecture: Scaling the Uber Engineering Codebase As We Grow.“ Retrieved from https://www.uber.com/blog/service-oriented-architecture/
[5] Shopify Engineering (2020). „Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity.“ Retrieved from https://shopify.engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity
Additional reference: Shopify Engineering. „Under Deconstruction: The State of Shopify’s Monolith.“ Retrieved from https://shopify.engineering/shopify-monolith
[6] Fowler, M., & Lewis, J. (2014). „Microservices: A definition of this new architectural term.“ martinfowler.com. Retrieved from https://martinfowler.com/articles/microservices.html
[7] Wikipedia Contributors. „Test-driven development.“ Wikipedia, The Free Encyclopedia. Retrieved from https://en.wikipedia.org/wiki/Test-driven_development
Additional resources on TDD:
- CircleCI (2024). „Test-driven development (TDD) explained.“ Retrieved from https://circleci.com/blog/test-driven-development-tdd/
- InfoQ. „Test-Driven Development: Really, It’s a Design Technique.“ Retrieved from https://www.infoq.com/articles/test-driven-design-java/
[8] IBM Research (2024). „Why larger LLM context windows are all the rage.“ Retrieved from https://research.ibm.com/blog/larger-context-window
[9] Kolena (2024). „LLM Context Windows: Why They Matter and 5 Solutions for Context Limits.“ Retrieved from https://www.kolena.com/guides/llm-context-windows-why-they-matter-and-5-solutions-for-context-limits/
Additional reference on „lost in the middle“: Medium. „Understanding LLM Context Windows: Tokens, Attention, and Challenges.“ Retrieved from https://medium.com/@tahirbalarabe2/understanding-llm-context-windows-tokens-attention-and-challenges-c98e140f174d
[10] AWS Prescriptive Guidance. „Hexagonal architecture pattern.“ Retrieved from https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/hexagonal-architecture.html
Additional references on hexagonal architecture and DDD:
- Vaadin (2023). „Domain-Driven Design (DDD) and Hexagonal Architecture in Java.“ Retrieved from https://vaadin.com/blog/ddd-part-3-domain-driven-design-and-the-hexagonal-architecture
- Baeldung. „Hexagonal Architecture, DDD, and Spring.“ Retrieved from https://www.baeldung.com/hexagonal-architecture-ddd-spring
[11] Google Engineering Practices. „The Standard of Code Review.“ Retrieved from https://google.github.io/eng-practices/review/reviewer/standard.html
Additional Google references:
- Google Engineering Practices. „Introduction to Code Review.“ Retrieved from https://google.github.io/eng-practices/review/
- Abseil (2020). „Code Review – Software Engineering at Google.“ Retrieved from https://abseil.io/resources/swe-book/html/ch09.html
Additional Reading
Corporate Engineering Blogs:
- Netflix Engineering Blog. „Ready for changes with Hexagonal Architecture.“ Retrieved from https://netflixtechblog.com/ready-for-changes-with-hexagonal-architecture-b315ec967749
- F5/NGINX (2016). „Adopting Microservices at Netflix: Lessons for Architectural Design.“ Retrieved from https://www.f5.com/company/blog/nginx/microservices-at-netflix-architectural-best-practices
- Stripe Engineering Blog. Various articles on API design, migrations, and technical debt management. Retrieved from https://stripe.com/blog/engineering
- InfoQ (2019). „Paying Technical Debt at Scale – Migrations @Stripe.“ Retrieved from https://www.infoq.com/presentations/stripe-technical-debt/
- The Pragmatic Engineer. „Inside Stripe’s Engineering Culture“ (Part 1 & 2). Retrieved from https://newsletter.pragmaticengineer.com/p/stripe
LLM Benchmarks:
- Aider. „Aider LLM Leaderboards.“ Retrieved from https://aider.chat/docs/leaderboards/
- Hugging Face Blog. „BigCodeBench: The Next Generation of HumanEval.“ Retrieved from https://huggingface.co/blog/leaderboard-bigcodebench
- EvidentlyAI (2024). „10 LLM coding benchmarks.“ Retrieved from https://www.evidentlyai.com/blog/llm-coding-benchmarks
Software Architecture Resources:
- Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional.
- Martin, R. C. (2017). Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Prentice Hall.
- Newman, S. (2021). Building Microservices: Designing Fine-Grained Systems (2nd ed.). O’Reilly Media.