This content originally appeared on DEV Community and was authored by Giorgi Kobaidze
Table of Contents
- No Hero Fights Without a Suit
-
It's Always Been This Way, History Repeats Itself
- 1980s: The Command-Line Cowboys
- 1990s: The IDE Boom
- 2000s: Framework Fever
- 2010s: Stack Overflow and NPM Nation
-
Every Hero Needs a Sidekick - a Human Being
- But Finding a Good One Is Hard
- Driving Each Other to Success - Explained with NASCAR
- The Experience That Finally Converted Me
-
But Not Everyone Has a Project Partner — That's Where AI Can Step In and Fill the Gap (Well, Kinda)
- Let's See How Iron Man Does It
- AI Can Absolutely Be Your Sidekick
- Where AI Falls Short
- Summary
No Hero Fights Without a Suit
It was a Friday evening. I was sitting at my desk, exhausted from the week, scrolling through X (formerly Twitter), something I rarely do. But I was too tired to engage in anything more intellectually demanding than mindless social media scrolling (yeah, you can tell I was pretty messed up). Then I came across a post from a verified account that said something like, "Real developers don't use AI!" You know the type, those deliberately controversial posts designed to grab your attention and engage in the comments. It was so aggressive and polarizing that it actually caught my eye, even though my attention tank was completely empty.
Even me, who's cautious about overusing AI tools, think it's completely wrong to discourage someone from using them just because "real developers don't use AI."
What else? Real superheroes don't use armor, right? The truth is, AI isn't replacing developers, it's upgrading them. It's the new suit, not the new hero.
It's Always Been This Way, History Repeats Itself
Every generation of developers has had its own "shortcut" - helper tools that made their lives as easy as possible for that time. Let's look at a few examples from each generation, starting with the 1980s:
🕹 1980s: The Command-Line Cowboys
Back then, you were the debugger, IDE, and stack overflow all in one. Developers started using text editors like Emacs and Vim, and when makefiles came around, it was basically witchcraft. Automated builds? Unheard of.
Then came C compilers that actually optimized your code instead of making you do the math yourself. That was their "AI moment."
💾 1990s: The IDE Boom
Enter Visual Basic, Delphi, and Borland C++ Builder, drag-and-drop GUIs were born.
But soon, everyone realized they could make entire Windows apps without touching the Windows API.
The shortcut? Integrated Development Environments that made coding feel like assembling LEGO.
By the way, I still can't believe I actually wrote code in Borland C++. I'm a 90s kid (a.k.a. a 30-year-old man now), but for some reason, my very first line of code was written in Borland C++, back in 2006. Looking back, it was so raw and unsophisticated, but at the time, it felt like pure magic. It was the single coolest thing I'd ever done in my life, and nothing even came close.
It was one of the most popular editors of its time. Now I work with tools like VS Code and JetBrains IDEs, they're not even in the same galaxy when it comes to features and capabilities.
Let me explain what I mean by telling a quick story (completely made up):
A Trip to the '50s
1955 – Bell Labs Basement, New Jersey, USA (11:45 PM)
The air smells like warm dust. Fans hum, relays click and a printer roars in the corner. Though you're so used to those sounds, you don't even recognize them anymore.
You're at your desk, cluttered with punch cards, coffee stains, dust, and a growing pile of frustration and the only one in the room who regrets ever trying - well, actually you're also the only one in the room anyways, it's almost midnight. It's not your 2nd, 3rd, or 5th day it's the 8th day (weekend included) you've had to work this late, wrestling with a problem no one else can help you solve. Even coffee has stopped doing the trick.
"Alright, FORTRAN test number thirty-two"
You mutter, sliding a fresh deck into the card reader.
"This has gotta do the trick."
The machine starts clanking relentlessly, swallowing the cards one by one, just like you swallowed the last bite of that pizza 10 hours ago... yeah, you're actually starving, but all you need to do right now is to make that thing work and go home. You're staring at the blinker, hoping to work this time.
Minutes later...
You snatch the output as soon as it stops, scanning for the holy grail: ‘NORMAL TERMINATION.’
Instead, you see:
COMPILER DIAGNOSTIC: ILLEGAL CHARACTER IN COLUMN 7.
"Column 7? Again?"
You flip through this printout, finger tracing down the line numbers.
"Statement 60... hmm... that's the loop for summation. I checked that last night."
You go back to the keypunch machine, feed a blank card and re-type the line 60 with surgical precision. Only to result in the same diagnostic.
"What? I swear to god, this thing is broken or something. Alright, I'm done, I'll continue tomorrow. I'm going home!"
As you start unlocking your Ford Mainline on an empty street, someone approaches, carrying a large bag.
Stranger: "Hey, my name's John. I'm actually from the future. I know you don't believe me… how could you, right?"
You: "Well, buddy, I'm just trying to get home, okay? I don't need any problems right now, I've got plenty already. Have a good night!"
Stranger: "No, seriously. Let me show you." [He opens the bag and places something on the hood of your Mainline.]
You: "Whoa… what's that bright thing? A typewriter? And put it away, don't scratch my car, I just bought it!"
Stranger: "Relax. It's plastic and light. It's called a laptop."
You: "What the hell is a "lab top"?"
Stranger: "It's from the 2000s. Don't worry, it's a computer, well, not the kind you know. Much more advanced."
You: "How's that tiny plastic brick more advanced than my..."
Stranger: "OK, here, I've got your problem written and compiled in this editor called Borland C++." [He continues to show the whole thing.]
You lean against the car, completely blown away, unable to believe what you just witnessed.
"So you're telling me... you don't even need punch cards, card readers, or keypunch machines? And it can process logic in milliseconds? And that "Boar Land C Plus Plus" actually tells you what you've done wrong? Man, the future looks awesome... I wish I'd been born then!".
"Well, it's better, sure... but careful what you wish for, my friend. We've got the same scale of bugs and errors too. Some old-timers even wish times had never changed..."
Now, you could tell a similar story set at any point in the history of software engineering, it would feel just as remarkable.
🌐 2000s: Framework Fever
This was when developers said, "Why write everything yourself when there's a framework for that?"
We got .NET, Java EE, Rails, PHP frameworks, and Spring - a generation that replaced manual wiring with configuration magic.
It was also the era of Dreamweaver, where "web developers" could build a website without writing a single line of HTML. (And yes, they still called themselves developers.)
📚 2010s: Stack Overflow and NPM Nation
Have We Become Assemblers Instead of Creators?
Developers learned a powerful new spell: Ctrl+C, Ctrl+V.
Stack Overflow became the universal brain, NPM and NuGet turned "reinventing the wheel" into "installing it with one command," and GitHub made collaboration instant.
You didn't need to know how everything worked, just what to search for. Engineering became more about assembling ready-made components than creating them first and then putting them together.
A Short Story from My Early Days (True Story This Time)
I remember back in my bachelor's days, when I started looking for my first software engineering job. One of my friends who was already working told me, "Man, there are code snippets all over the internet, I barely have to write anything myself. I just copy and paste what I need, and it works." I remember feeling so frustrated when I heard that. Was that what software engineering had become? Copying and pasting snippets from the internet? So I'm gonna be a copy-paster, and that's it? I really hoped he was just overly exaggerating things.
Fortunately, I was right for the most part. When I started working, I actually had to write quite a lot of code manually, and boy, did I enjoy that process. I still remember one particular feature (one of the first ones I had to implement), it involved generating documents with specific formatting, styles, colors, content, images, signature fields - everything, all based on user input. That was quite a task. I'd been working on it the entire week, and by Friday, I still hadn't finished.
But I was so deep in the flow state that I didn't want to break it. I literally came to the office on Saturday and Sunday, sat there all alone from 9 AM till 11 PM (yes, over 12 hours straight - each day), and finally wrapped it up. I can't even begin to describe how rewarding it felt, going back home that Sunday midnight, exhausted, but proud.
That was the moment I realized that finishing projects is hard, and often not fun. But, good lord, when you finally do, it's incredibly rewarding.
What I'm trying to tell you, especially if you're a rookie software engineer or someone aspiring to become one, is this: don't listen to people who try to sound smart by saying "AI does all the work now." That's simply not true. Whether this job stays interesting for you depends entirely on how you approach it.
If you strongly believe and expect you'll just sit at a desk, type a few prompts, and have AI magically do everything for you without needing to think deeply or understand what's happening then, honestly, this job might not be for you.
Well... unless this article changes your mind. I sure hope it does.
Every Hero Needs a Sidekick - a Human Being
But Finding a Good One Is Hard
I know some of you have probably rolled your eyes, thinking you can do it all alone, right? I thought the same way about 7-8 years ago. To be honest, I still do a lot of grinding and learning on my own (I'm an introvert). But a few years back, I realized that working with someone else can actually make you a better software engineer. Seeing the industry from another person's perspective can be incredibly valuable and it might even save your career.
Of course, this person (or people) should be at least as motivated to learn as you are, or at the very least, be open to becoming just as motivated and maybe even more so with your help.
I've worked with plenty of software engineers, but I can only name a handful who were at that level - the kind where I could think, "Alright, they're special. I can learn so much from them!" You know how it goes: you work with them for a few months or years, and then either one of you changes jobs, or life changes, and the connection fades.
It's hard to find people willing to collaborate on projects outside of work hours on something you care about just as much as they do. And don't let friendship fool you: just because someone's your friend doesn't mean they'll make a good project partner. Those are two very different things. But if you're lucky enough to find someone who's both a friend and an exceptional collaborator... well, congratulations. You just hit the jackpot.
Driving Each Other to Success - Explained with NASCAR
You're probably wondering what NASCAR has to do with this article. Well, we just talked about how important other people are for moving your career forward. I like to explain teamwork using a NASCAR analogy. First, let's define a few important terms:
Aerodynamics - aerodynamics is all about how air flows around a car to reduce drag and increase speed.
Draft - in NASCAR, drafting is when a car follows closely behind another to reduce air resistance and gain speed.
Bumping - bumping is when one car nudges another to help it move ahead, often strategically.
If you've ever watched a NASCAR race, you might notice one thing that happens all the time - one thing that makes NASCAR so much more exciting than other racing categories: the leader almost never dominates the race, not even for a short stretch, let alone the entire event. That's because the leader has no car in front of them (well, unless they're lapping another car, which doesn't really count, since they'll eventually pass it). Without a car ahead, they don't get the benefit of drafting, which makes them slower than the cars in the pack behind.
As a result, the race winner is often decided on the last lap and it could be someone who was running 5th, or even further back, just one lap before the finish.
And all of this happens because of how aerodynamics work.
If a car is running alone, with no one in front or around it, it's going to be slower.
Two cars can run faster togetger than one, here's how (time for a brief physics/aerodynamics lesson):
The car in front cuts through the air, creating a draft for the car behind. The rear car gains much more speed than the front one, catches up, and gives it a gentle bump, helping the front car go even faster. Then the front car slices even more air, and the rear car bumps again, their speed increases drastically.
By working together like this, they can go much faster than they ever could alone. Sometimes they even swap positions and roles, taking turns benefiting from drafting and pushing each other forward.
This is a brilliant analogy of how you can work with someone and make yourself 10 times (or even more) better than you were before. That can work extremely effectively. Don't be a car that cuts air and doesn't get any push, you deserve to be pushed to success and you also deserve to understand how good it feels when your effort makes someone else successful.
The Experience That Finally Converted Me
Up until a few weeks ago, I was one of those people who were a little skeptical about AI. Sure, I had been slowly changing my mind, leaning more in its favor, but it wasn't until a recent experience that it really clicked for me. That moment made me realize I should've started using AI tools extensively in my workflow, ignoring them doesn't make you a better developer, it only holds you back. Simple as that.
So, I was helping someone with a website, not even a friend, we're not even in the same time zone, nor country... not even the same continent. We discussed the requirements, features, and all the usual stuff. Then I started the planning process, just like I always do, thinking about where to begin. After about an hour (maybe even less), while I was still sketching ideas on paper with a pen, she came back with an initial website design. The core layout was already done and it even had some pretty fancy features. The conversation went something like this (I hope I'm remembering the conversation accurately, I don't want to misquote)
Me: "Wow, that's gorgeous. How did you manage it so fast? Have you been working on it like for a week or smth?"
Her: "I know, right? It's beautiful! I just generated it using copilot."
Me: "I have no words... And that image right there, the one you're using as a component, where did you get that?"
Her: "Oh that's also generated by copilot."
Me: "What? Is it THAT good in generating images? I mean even the text is flawlessly generated."
Her: "I have an idea to make that dynamic."
Me: "OK, I'll look into that. It's going to be a lot of CSS and JS hustle."
Her: "Hmmm... it's actually easy peasy... (proceeds to explain why)."
I've always considered myself an extremely doer type of person. But that moment made me realize there are levels to that game. I saw there was room for me to improve as a doer.
In NASCAR terms, I was giving this person a draft (helping with the project). Then she came through with even more speed - being a doer in her own right - and pushed me forward. Now, I'm an even stronger doer than I was before, which lets me help her even more.
Gosh, how I love explaining everything in racing terms.
I'm not really a markup person, and I know she doesn't have extensive experience in HTML and CSS either. I mean, we both have some experience, but we're no magicians who can whip up impossible stuff on CodePen.
Yet, using AI, we actually managed to create something incredibly cool, something that even a master markupper would struggle to get right in a reasonable time period. Me? I'd probably take about 3 months or something.
It was at that moment I realized that talking to people and working together can still bring a lot of value. Just the thought that I might never have to write HTML and CSS manually again brought me so much joy, I can’t even describe it. I've spent hours, even days, wrestling with silly CSS rules: dragging components around, counting pixels to make things responsive, tweaking margins and padding... oh god, don't even get me started on effects, colors, and all the rest of it. I never found joy in that. I love puzzles, logic, and problem-solving - not dragging components around.
I can't get that lost time back, but I'm genuinely happy those days are gone. And you know that meme about back-end developers creating markup? That meme is outdated, retired, and officially DONE. It's not happening anymore.
So finally, I can say just like I mentioned in one of my articles: I'm all in on AI! (But still... stay away from vibe coding, please!)
But Not Everyone Has a Project Partner - That's Where AI Can Step In and Fill the Gap (Well, Kinda)
Let's See How Iron Man Does It
OK, let's talk about Iron Man. Sure, he has some people around him, but really, he's still a pretty lonely guy, right? He spends most of his time working on his projects.
Why does that sound so relatable?
Anyway, even though he's mostly alone, he has an AI friend - J.A.R.V.I.S.
J.A.R.V.I.S. is the one Tony Stark spends the most time talking to. And it's not just talking, he uses J.A.R.V.I.S. extensively, for practically every task.
Commands:
"J.A.R.V.I.S., subject at my 12 o'clock is not a target, disengage!"
"J.A.R.V.I.S., do me a favor and blow Mark 42."
Dialogues:
Tony Stark: "J.A.R.V.I.S., where's my flight power?!"
J.A.R.V.I.S.: "Working on it, sir. This is a prototype."Tony Stark: "Ever been to Tennessee, J.A.R.V.I.S.?"
J.A.R.V.I.S.: "Creating a flight plan for Tennessee."
Jarvis to Tony:
"As always, sir, a great pleasure watching you work."
Sounds familiar, right? Have you ever used Copilot, Claude Code, or something similar?
The interaction vibe (I hesitate to even use the word "vibe" anymore after vibe coding ruined it for me) is pretty much the same.
So here's my question: if even Tony Stark - genius inventor, engineer, scientist, businessman, and THE SUPERHERO AVENGER - relies on AI to work efficiently, why would you deny it? Maybe that's the way we are supposed to build software? Maybe we've been grinding to reach this level? Think about this.
For the record, I'm well-aware he's a fictional character, but the analogy still stands.
Tony Stark doesn't have to do everything by himself, that would be counter-productive and take forever. He doesn't even build his own suit anymore, the robot does it. His role is deciding which features to add, and there's nothing wrong with that.
At the same time, he's perfectly capable of doing the manual work. Remember the first Iron Man movie, when he was held captive? He built the very first Iron Man suit - "Mark 1" - crude, clunky, but still brilliant. It wasn't nowhere near as advanced as the later versions, of course.
Here's the comparison between the "Mark 1" - built with skills and pieces of junk, without AI and the "Mark 85" - built with all the right tools and AI.
Why was the difference that significant? Because back then, he had his skills and limited tools. Later, he used the same skills and every tool available: robots, AI, simulations and that's what made him unstoppable. He didn't say, "Real engineers don't use AI."
You have to delegate boring and repetitive work to AI, but when the time comes, you should be able to get involved manually.
Then you might ask: if I delegate all that work to AI, how can I improve my skills?
Good question, I'll try to explain from my own experience: if you mindfully code with AI, you're going to learn even more than from the tutorial hell. I'll expand on this topic in one of the upcoming parts of this series.
AI Can Absolutely Be Your Sidekick
AI can definitely be your project partner. Have you ever tried pair programming? It's the same concept - just without the human factor. Sometimes, that's even better. When you code with another person, you're relying on their knowledge or approach, which can occasionally be biased or incorrect. That's especially risky if you're not experienced enough to catch mistakes and correct them.
With AI, this problem rarely occurs. Of course, it's still not perfect, but it's only going to get better.
Take Claude Code as an example. One thing I absolutely love about it is that when you install it on your local machine, the very first thing it shows you is something like this:
AND, once again, I ABSOLUTELY LOVE THAT! Kudos to Anthropic for this. They don't just promote themselves or claim their product is perfect - they make it clear that you need to lead the process, you need to be the main pilot in your Boeing 777. Claude should be your second pilot, and it's always your responsibility to check and verify the quality and correctness of the code (or anything else) it generates.
That small but crucial element makes me think they're legit. It's a solid reason to use their product, which, to be honest, is absolutely fantastic. At first glance, it might seem like anti-promotion, but to me, it's actually a pretty strong selling point.
AI for Experienced Software Engineers
AI tools are extremely powerful weapons in the hands of an experienced software engineer. It's like giving a baseball bat to an MMA champion, dangerous, right? An experienced programmer is more likely to use AI wisely and mindfully: they verify the code and truly understand what the AI is generating. But some experienced developers get too comfortable. They don't ask AI questions to understand lesser-known concepts, which is a mistake.
You should always take AI's suggestions with a grain of salt.
No matter how experienced you are, there will always be concepts you don't fully grasp. Use the vast amount of resources AI provides to your advantage. Make AI justify all the decisions it makes. Don't trust it blindly and don't trust yourself blindly either.
AI for Junior Software Engineers
Even if you're a rookie, you can still use AI tools to your advantage. But you need to be mindful, don't fall into the trap of leaning too heavily on AI and skipping the learning process.
Don't use AI just to generate code for you, no matter how urgent the task is. Everyone at your company should understand that you're a beginner and need time to build knowledge and get familiar with the basics. Use AI as your mentor: sit down, chat with it, and ask even the simplest questions. Let me show you an example:
Prompt:
> Can you explain the different types of browser caching and how each level works?
Response:
Browser caching operates at several distinct levels, each with different characteristics:
1. Memory Cache (L1)
- Fastest but most volatile
- Stored in RAM during the current browser session
- Cleared when tab/browser closes
- Typical for: Images, fonts, scripts actively used on the current page
- Size limit: ~10-50MB depending on available memory
2. Disk Cache (L2)
- Persistent across browser sessions
- Stored on disk in the browser's cache directory
- Survives browser restarts but can be cleared by user or browser policies
- Typical for: Any cacheable HTTP resources
- Size limit: Usually 50MB-1GB (browser dependent)
3. Service Worker Cache (Application Cache)
- Most persistent and developer-controlled
- Programmatically managed via JavaScript
- Survives cache clearing in many cases (user must explicitly clear "site data")
- Typical for: PWA assets, offline-first applications
- Size limit: Varies by browser (Chrome ~6% of free disk space)
4. HTTP Cache (Browser Cache)
Controlled by HTTP headers:
- Cache-Control: max-age, no-cache, no-store, public, private
- ETag: Validates if resource changed (conditional request)
- Last-Modified: Timestamp-based validation
- Expires: Legacy expiration date
Cache Priority Order
When a resource is requested:
1. Check Memory Cache → instant return if found
2. Check Service Worker → programmable response
3. Check Disk Cache → fast return if valid
4. Network request → fetch from server, then cache based on headers
See? Now you can ask even more detailed questions at any level. For the most part, you can even replace boring and time-consuming video tutorials with AI. You can build projects and learn with AI tools.
That said, there are still amazing video tutorials you don't want to miss, especially ones about career development, managing your engineering path, and improving your skills properly. Sure, you can get answers to these questions from AI as well, but they'll usually be general. In real life, things often work in very peculiar and specific ways, so some guidance from experienced humans is still invaluable.
Video tutorials are still valuable at some level, as they show you a process of project creation from start to finish, which is a critical skill for a developer. I'd say it's more mental than technical. Always be a finisher when it comes to projects.
Where AI Falls Short
I'd say the biggest limitation of AI, at least for now, is that it doesn't have emotions. It can't form genuine friendships with you, and that can make a real difference.
When you have an emotional connection with someone, the work you do together can turn into a shared mission - your number one goal. You know that someone who truly cares about the project relies on you, and you can't let them down. You share the struggles, the breakthroughs, and the joy of celebrating small victories together. This kind of moments engrave the experience and knowledge in your brain 10 times better.
AI can't give you that feeling. It doesn't care about the outcome, its only purpose is to assist you, not to emotionally support you.
Let me show you an example:
Prompt:
> Hey Claude, you're awesome!!!
Answer:
Thanks! Is there anything you'd like help with on the project, or any other technical questions I can answer?
If your friend responded to your enthusiasm like that, you'd probably think something's wrong, it just sounds so dry and lifeless, right? A real human would say something like: "Hey! Where did that come from? Thanks!" or "Oh my god, thank you! You're amazing too!" - something with actual emotion behind it.
And honestly, even if AI replied that way, it still wouldn't feel the same as hearing it from a real person.
So, if what you're looking for is emotional connection, AI might not be the best companion or partner but it can still be an incredible ally when it comes to solving problems.
Summary
Don't hurt your potential by being hostile toward AI. Use it mindfully, and it will benefit you - it'll make your life and work so much better.
You can use AI as your peer programmer, your rubber duck (on steroids), your teacher, or even your mentor.
I've seen people call AI many things: some call it danger, others call it awesome, I call it J.A.R.V.I.S.
Shall we code, J.A.R.V.I.S.?
This content originally appeared on DEV Community and was authored by Giorgi Kobaidze
Giorgi Kobaidze | Sciencx (2025-10-13T16:22:14+00:00) Will Developers Survive AI Takeover? Part 2: Don’t Be Ashamed to Use AI, Even Iron Man Did. Retrieved from https://www.scien.cx/2025/10/13/will-developers-survive-ai-takeover-part-2-dont-be-ashamed-to-use-ai-even-iron-man-did/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.