TLDR: LLMs are a tsunami transforming software development from analysis to testing. Ride that wave or die in it.

I have been in IT since 1969. I have seen this before. I’ve heard the scoffing, the sneers, the rolling eyes when something new comes along that threatens to upend the way we build software. It happened when compilers for COBOL, Fortran, and later C began replacing the laborious hand-coding of assembler. Some developers—myself included, in my younger days—would say, “This is for the lazy and the incompetent. Real programmers write everything by hand.” We sneered as a tsunami rolled in (high-level languages delivered at least a 3x developer productivity increase over assembler), and many drowned in it. The rest adapted and survived. There was a time when databases were dismissed in similar terms: “Why trust a slow, clunky system to manage data when I can craft perfect ISAM files by hand?” And yet the surge of database technology reshaped entire industries, sweeping aside those who refused to adapt. (See: Computer: A History of the Information Machine (Ceruzzi, 3rd ed.) for historical context on the evolution of programming practices.)

Now, we face another tsunami: Large Language Models, or LLMs, that will trigger a fundamental shift in how we analyze, design, and implement software. LLMs can generate code, explain APIs, suggest architectures, and identify security flaws—tasks that once took battle-scarred developers hours or days. Are they perfect? Of course not. Just like the early compilers weren’t perfect. Just like the first relational databases (relational theory notwithstanding—see Codd, 1970), it took time to mature.

Perfection isn’t required for a tsunami to destroy a city; only unstoppable force.

This new tsunami is about more than coding. It’s about transforming the entire software development lifecycle—from the earliest glimmers of requirements and design through the final lines of code. LLMs can help translate vague business requests into coherent user stories, refine them into rigorous specifications, and guide you through complex design patterns. When writing code, they can generate boilerplate faster than you can type, and when reviewing code, they can spot subtle issues you’d miss even after six hours on a caffeine drip.

Perhaps you think your decade of training and expertise will protect you. You’ve survived waves before. But the hard truth is that each successive wave is more powerful, redefining not just your coding tasks but your entire conceptual framework for what it means to develop software. LLMs' productivity gains and competitive pressures are already luring managers, CTOs, and investors. They see the new wave as a way to build high-quality software 3x faster and 10x cheaper without having to deal with diva developers. It doesn’t matter if you dislike it—history doesn’t care. The old ways didn’t stop the shift from assembler to high-level languages, nor the rise of GUIs, nor the transition from mainframes to cloud computing. (For the mainframe-to-cloud shift and its social and economic impacts, see Marinescu, Cloud Computing: Theory and Practice, 3nd ed..)

We’ve been here before. The arrogance. The denial. The sense of superiority. The belief that “real developers” don’t need these newfangled tools.

Arrogance never stopped a tsunami. It only ensured you’d be found face-down after it passed.

This is a call to arms—my plea to you. Acknowledge that LLMs are not a passing fad. Recognize that their imperfections don’t negate their brute-force utility. Lean in, learn how to use them to augment your capabilities, harness them for analysis, design, testing, code generation, and refactoring. Prepare yourself to adapt or prepare to be swept away, fighting for scraps on the sidelines of a changed profession.

I’ve seen it before. I’m telling you now: There’s a tsunami coming, you can hear a faint roar, and the water is already receding from the shoreline. You can ride the wave, or you can drown in it. Your choice.

Addendum

My goal for this essay was to light a fire under complacent software developers. I used drama as a strategy. The essay was a collaboration between me, LibreOfice, Grammarly, and ChatGPT o1. I was the boss; they were the workers. One of the best things about being old (I'm 76) is you "get comfortable in your own skin" and don't need external validation. I don't want or need recognition. Feel free to file the serial numbers off and repost it anywhere you want under any name you want.

I know he's supposed to be an expert in AI and deep learning, but every time I try to give one of his interviews on YouTube a chance, I find myself frustrated at how shallow his questions are, how he trips over his own ideas, and how his questions are frequently so nebulous and vague, his guests struggle to come up with a meaningful answer. It seems like he does a quick Google search and asks vague questions about a few relevant topics without actually planning his interviews.

It sucks to me because he gets such knowledgeable, innovative people on his channel, and just whiffs it every damn time. He compares everything to Python (which, fine, Python is okay, but he doesn't even seem to be an expert in it) and his understanding of his guests' work is so shaky.

I get the impression he got into CS just to become a famous podcaster or something. Maybe he's just nervous because he's talking to titans of the field, but honestly, it's hard to watch.

Does anyone else feel this way or am I just a pissy pedant?

okay so i’ve been reading about software architecture and i keep seeing this whole “monolith vs microservices” debate.

like back in the day (early 2000s-ish?) everything was monolithic right? big chunky apps, all code living under one roof like a giant tech house.

but now it’s all microservices this, microservices that. like every service wants to live alone, do its own thing, have its own database

so my question is… what was the actual reason for this shift? was monolith THAT bad? what pain were devs feeling that made them go “nah we need to break this up ASAP”?

i get the that there is scalability, teams working in parallel, blah blah, but i just wanna understand the why behind the change.

someone explain like i’m 5 (but like, 5 with decent coding experience lol). thanks!

https://x.com/unclebobmartin/status/1820484490395005175

I'm kinda hyped, even though I'm not a huge fan of the advice or the refactorings.

https://news.mit.edu/2026/margaret-hamilton-computing-pioneer-dies-1007

Mad respect to these brilliant people who paved the way for many of us.

I've been reading up on unit testing, and I was reminded of the existence of TDD. I could never for the life of me take it seriously. But apparently it has a swarm of supporters who I struggle to believe actually adhere to it as much as they say they do. I'm not even sure if people follow it properly, because in TDD you're supposed to write your test, then code to pass the test, ONE TEST A TIME.

But even if i write all my tests before implementation, imo TDD is at best, just as good as implementing before testing.

Tests will inevitably depend on implementation. The first thing you learn about unit testing is edge cases. That's not a "behavior" or "interface", that's an implementation detail.

Unless the problem you're solving is so simple that you can see ahead of time how the code will look like, you'll inevitably refactor your code as you write it. This means renaming, changing arguments, method & class deletion/creation. That means rewriting your tests as well. That's wasted time.

I think there's value in testing, but doing it backwards makes no sense to me.

i’m trying to level up not just my coding skills, but the way i think about problems, like a real software engineer would. i’m looking for book recs that can help me build that mindset. stuff around problem-solving, system design, how to approach real-world challenges etc.

Team member adds me to a PR.

I leave some comments.

"I'll address that in another a PR".

Another PR never gets raised.

Team member adds me to another PR.

I leave some more comments about refactoring code we've touched.

"Can we please not fixate on minor details like that, let's move forward, please approve".

Etc etc

At first I planned to just stop reviewing his code but I don't like that solution because it burdens my other team members. I also planned to bring it up with my manager but I'm worried it might negatively affect the general atmosphere of the team - so I don't want to resort to that just yet.

Is there anything else I can do to help my team member be more receptive to code reviews and not just want to get code merged asap?

EDIT: some people were asking for an example about one of my comments. An example is a 50 line code block that is copy and pasted and I'm asking him to put it in a documented function and reuse it in both places.

Hello, I'm currently working on a project as part of my computer science program's capstone or project. I'm interested in understanding how experienced engineers typically use comments within their code. That would be helpful for senior developers or project managers when reviewing, critiquing, or understanding the code.

I know my code is terrible would like to know some tips for improvements

I'm a senior dev with 15+ years of experience. However this is my first time really being the tech lead on a team since most of my work has been done solo or as just a non-lead member of a team. So I'm looking for opinions on whether I'm overreacting to something that one of my teammates keeps doing.

I have a relatively newly hired mid-level dev on my team who regularly creates PRs into the develop branch with code that doesn't even compile. His excuse is that these are WIPs and he's just trying to get feedback from the team on it.

My opinion is that the intention of a PR is to submit code that is, as much as can be determined, production ready. A PR is no place to submit WIP.

I'm curious as to what the consensus is? Is submitting WIP as a PR an abuse of the PR system? Or do people think it's okay to use the PR in order to get team feedback? To be fair, I can see how the PR does package up the diffs all nice and tidy in one place, so it's a tempting tool for that. But I'm wondering if there's a better way to go about this.

Genuinely curious to hear how people fall on this.

Edit: Thank you all for all of the quick feedback. It seems like a lot of people are okay with a PR having WIP as long as it's marked as a draft. I didn't realize this is a thing, and our source control (Bitbucket) does have this feature. So I will work with my guy to start marking his PRs as drafts if he wants to get feedback before submitting as a full-on PR. I think this is a great compromise.

Thanks all for the responses!

I’m a staff-level software engineer and I absolutely LOVE reading textbooks.

It’s partially because they improve my intuition for problem solving, but mostly because it’s so so satisfying to understand how some of these things work.

My current top 4 “most satisfying” topics/reads:

1. Virtualization, Concurrency and Persistence (Operating Systems, 3 Easy Pieces)

2. Databases & Distributed Systems (Designing Data-Intensive Applications)

3. How the Internet Works (Computer Systems, 6th edition)

4. How Computers Work (The Elements of Computing Systems)

Question for you:

Which CS topic (book, lecture, paper—anything) was the most satisfying to learn, and did it actually level-up your day-to-day engineering?

Drop your pick—and why—below. I’ll compile highlights so everyone gets a fresh reading list.

Thanks!

35 years ago today I started my first job as a software engineer at McDonnell-Douglas in St. Louis.

White shirt with a tie, dress pants, pocket protector. Paper resumes sent to employers by mail. $26K to start. Cellphones didn't exist. Presentation were given using overhead projectors. PCs were still using MS-DOS. Windows was a novelty program on PCs. The public internet did not yet exist. Our work computers were shared VAXs which we accessed with amber VT-220 terminals. Security posters on the wall telling us "Don't feed the Bear". And we wrote Tomahawk cruise missile flight software in Ada, never thinking that it would ever actually be used. And laser targeting systems for the missiles. The factories in the next buildings had production lines for four different fighter aircraft. Reagan's Star Wars projects were being actively pursued - there was a R&D particle beam weapon experiment being developed in the next room to be carried on the space shuttle.

So this just happened...

Took my wife to an appointment and waited for her in the car. One client I developed a webapp for sent me a message saying that he's getting an error when trying to create a new invoice. Didn't have my laptop with me, but thought I could save some time for when I got home and read the logs to see if there's anything there.

I logged into Azure Portal and found the error. Then I logged into Github and found the line causing the error. It was a quick fix so I edited the file directly in Github and commited the change. My workflow automatically builded and deployed the webapp in the testing environment. Did a quick test and everything was good, ran the workflow to deploy the version in production and told my client to check if it was fixed. It was.

Then I realized I've diagnosed the problem, fixed the bug, tested and deployed the app, all from my phone, in about 15 minutes. If life was a game, I think I'd have unlocked an achievement.

What a nice time to be alive.

I have a hypothesis that many of the processes we run in engineering teams are mostly organizational theater.

Daily standups, story points, sprint planning, retrospectives, team metrics — the whole agile ceremony package.

A few years ago I accidentally tested this.

I became a tech lead of a brand new team and we started from scratch. Instead of introducing all the usual processes, we tried something very simple.

I set goals for the team every 3 months and we just worked towards achieving them.

No story points.
No sprint planning.
No retros.
No velocity tracking.

We talked when it was necessary, adjusted the plan when reality changed, and focused on the actual outcome.

What surprised me is that after a year we never felt the need to add those processes.

The team was motivated, everyone understood the goal, and work moved forward without the usual structure.

Since then I've been wondering if many engineering processes exist not because teams need them, but because organizations feel uncomfortable without them.

Another thing that changed recently is AI.

Now I sometimes pick up a task that was estimated as "5 story points", finish it in two hours with AI tools, and the estimation suddenly becomes meaningless.

It makes me question whether our process assumptions still make sense in 2026.

I'm not saying agile practices are useless — they probably help in some environments.

But I'm increasingly skeptical about how much of it is actually necessary.

Curious about other people's experience.

Have you ever worked in a team with minimal process? Did it work or completely fall apart?