Explaining codebases, documentation, technical concepts, unfamiliar libraries/languages, legacy systems, and planning changes

Everyone is talking about AI-generated code.

But after using Claude Code, I realized the real shift isn’t code generation—it’s how we interact with software development itself.

Instead of writing every line manually, we’re moving toward a model where engineers define goals, constraints, and architecture, while AI handles much of the implementation.

A few observations:

-AI is excellent at accelerating repetitive coding tasks.

-It can navigate large codebases faster than most developers.

-It helps reduce context-switching by keeping architectural discussions, debugging, and implementation in one place.

But it still struggles with ambiguous requirements.It doesn’t replace system design, domain knowledge, or engineering judgment.

The engineers who will thrive in the AI era won’t be the ones who can write code the fastest.

They’ll be the ones who can:
• Break down complex problems
• Design scalable systems
• Write clear specifications
• Validate AI-generated solutions
• Ask better questions

Claude Code isn’t replacing software engineers.

It’s changing what software engineering looks like.

The future may not be “AI vs Engineers.”

It may be “Engineers who effectively use AI vs Engineers who don’t.”

What’s been your experience with Claude Code or AI coding assistants so far?

#AI #ClaudeCode #SoftwareEngineering #GenAI #LLM #DeveloperProductivity #SystemDesign

A practical look at Anthropic’s agentic coding tool — what it actually does, how it changed my workflow, and whether it’s worth your time.

I'll be honest — I've always been a bit cynical about the glorified learning posts on LinkedIn. But here we are.

6 weeks ago I had never written a single line of code. I always wanted to learn - but never took the time! I had a rough concept of vibe coding - but no idea what to build. Until I found my "have to fix it" problem.

Territory planning reviews were taking hours of pivot tables, multiple dashboards, and customer PowerPoints - and still leaving gaps in the story. That felt like something worth breaking.

So I did. With GitHub Copilot powered by Claude as my co-pilot, I vibe coded my way through React, TypeScript, and data joins I didn't fully understand until they fell apart. Then I rebuilt them. Then broke them again. Then GitHub Copilot fixed them!

The result? A self-contained territory planning web app for our Security business - multi geo versions, one file, no install. Uniformed approach across our entire team.

What I took from it:
→ You don't need to understand everything to build something useful
→ Breaking things is faster than reading about them
→ AI doesn't write your solution — it helps you think through the problem

If you're sitting on a problem you think needs a developer to solve, it might be worth trying it yourself first.

Worst case you learn something. Absolute best case you ship something.
Middle ground - you have a great demo and someone far more qualified takes it from there. (we still need developers!!)

I've been a software engineer for basically my whole life, at least ever since I first taught myself to write HTML code when I was 12 years old, and in the modern era when Artificial Intelligence and Large Language Models are commonplace, I of course have adapted with the times, as I had done before whenever a new paradigm shift in the engineering landscape had come about.

In this modern era of A.I. vibe coded apps that get built and deployed while full of bugs and security holes, which then get trivially hacked in short order and the company's data all leaked online, I thought I'd write a little about how I, a career software engineer since 2008, approach the use of A.I. in my projects.

If you happen to be a junior developer just getting started in this space and relying heavily on A.I. to do most of your job, maybe reading about my approach to A.I. could be helpful to inspire you on a different way of doing it, and help you grow as a self-sufficient developer who uses A.I. only as a tool to automate the tedious parts but without it being a crutch that you rely on too heavily that you couldn't survive without it.

AI isn’t replacing software engineers - but it *is* changing who gets hired.

In this video, I break down what’s actually happening in the dev market right now - based on real experience, real data, and what I’m seeing inside teams.

I use AI every day to write code. It’s made me faster, more productive, and honestly… more valuable. But there’s a tradeoff most people aren’t talking about - and it’s quietly reshaping the job market, especially for junior developers.

We’ll cover:

* What AI is actually doing to mid-level and senior engineers
* Why junior roles are disappearing (and what the data says)
* The biggest mistake most junior devs are making right now
* What you need to do differently to actually get hired
* The 4 career paths that are still growing in 2025

This isn’t hype or fear - it’s a realistic look at where things are going, and how to adapt.

---

📌 If you're:

* Trying to break into tech
* Already working as a developer
* Or just curious about the future of AI and jobs

This will give you a clear picture of what’s changing - and what to do about it.

---

🎥 **Watch next:**
Python Isn’t Enough to Get Hired in 2026 — Here’s What Actually Works
👉 https://www.youtube.com/watch?v=aBymUMEu0PM&feature=youtu.be

---

💬 Let me know in the comments:
Which of the 4 paths are you focusing on?

---

⏱️ Timestamps
0:00 - AI made me more valuable… but we hired fewer engineers
0:45 - Python → C++ in 2 weeks (real example)
2:50 - How AI is making developers more efficient
5:00 - The Shift in the Junior Dev Market (and how to prepare!)
5:40 - The real hiring formula
7:20 - Stop being a generic developer
8:05 - The 4 buckets that are hiring
10:00 - The future of software jobs

---

👍 If this helped, consider subscribing - I post breakdowns of the dev industry as it actually is right now, not as it used to be.

I was skeptical at first.

Not about AI in general — but about whether it would actually fit into my workflow. I work mostly with legacy PHP and jQuery. The kind of codebase that was written before half the frameworks people talk about today even existed. Some Vue.js here and there in newer parts, but a lot of the core is raw PHP, procedural logic, and jQuery doing things you probably don't want to know about.

It's not glamorous. But it's real work, and it has its own kind of complexity.

When I started using Claude more seriously, I wasn't expecting much. Turns out I was wrong.

I had a draft post sitting in my local repo for a while, where I was about to scream about how AI is overestimated. Well, that post aged pretty badly. I never published it, and looking back at the notes I’m glad I didn’t. So what I’m going to write today will only be about my current workflow and how I actually use AI in my daily work — no hype, no predictions, just what I’ve found useful.

About 15 months ago I left a comfortable senior engineering role at a fintech company to go independent and build software products with AI coding assistants as my primary collaborators. I'm 38, have a mortgage, and my wife was pregnant with our second kid at the time. Not exactly the ideal moment for a career experiment.

I want to share what that experience has actually been like, because there's a lot of hype and doom out there, and not enough honest accounts from people who've spent serious time in the trenches with these tools.

Background

I've been writing software professionally for about 16 years. Mostly backend -- Java, Python, some C++ earlier on. I'm not a 10x developer. I'm a pretty average senior engineer who got tired of sprint planning meetings and wanted to build things on my own terms.

I committed to using AI coding assistants for everything. I rotate between a few different ones depending on the task -- they all have different strengths and keep leapfrogging each other every few months.

What 1,800 hours looks like

I tracked my time carefully because I'm billing myself against savings. Roughly 1,800 hours of active AI-assisted development this year. About 6-7 hours a day, six days a week.

I shipped three products: a multilingual document processing pipeline, a monitoring tool for small SaaS companies, and a real-time audio processing app still in beta.

Two of those required significant Rust and Go code. I had never written production Rust before this year. The AI assistants didn't just help me write unfamiliar languages -- they helped me understand the idioms, memory models, ecosystem tooling. Zero to shipping production Rust in about three months. That would have been 12-18 months solo.

I also went deep on vector embeddings, fine-tuning smaller language models, building custom data pipelines. A year ago I couldn't have explained cosine similarity. Now I have opinions about chunking strategies.

The part nobody talks about

Here's where I push back on the pure optimism narrative.

AI assistants are confident. Relentlessly, dangerously confident. They generate code that looks perfect, passes review, and has a subtle bug that surfaces three weeks later at 2am. I've lost entire days to AI-introduced issues I trusted too quickly.

I fell into what I call "velocity addiction." Moving so fast you skip careful review. You trust the output because it's been right fifteen times. Then time sixteen bites you hard.

One painful incident: an AI-generated database migration looked correct, passed tests, then corrupted two days of user data in staging. The logic error was subtle -- null handling that was technically valid but semantically wrong for my schema. Caught it before production, but it shook me.

These tools also make you feel more competent than you are. I wrote Rust that compiled and ran, but a friend with five years of Rust experience pointed out I was fighting the borrow checker in ways that would break at scale. AI helped me get it working but didn't teach me to think in Rust. There's a difference.

What I believe now

AI coding assistants are genuinely transformative for experienced developers. The key word is experienced. You need enough background to evaluate output, to smell when something's wrong even if it compiles.

The best mental model: you're directing a very talented but very junior team that never sleeps. They produce enormous amounts of work and know trivia about every framework. But they have no judgment. They don't understand your users or your architectural decisions. They will confidently lead you off a cliff if you let them.

The "AI will replace developers" framing is wrong, but not for comforting reasons. It's not that AI can't code -- it clearly can. It's that the hard part of software engineering was never the coding. It's figuring out what to build and why. AI is exceptional at mechanical parts and bad at strategic parts. For now.

The honest numbers

Am I more productive? Yes. Roughly 3-4x in raw output. But my error rate is higher too. I ship faster and fix more bugs. The net is positive, but it's not the clean 10x story that makes good tweets.

Am I making money? Barely. AI made building dramatically easier but didn't help with finding customers at all.

Would I do it again? Without hesitation. This year taught me more than the previous five combined.

Still figuring it out

Some days I feel like I'm living in the future. Other days I'm mass-reverting AI-generated commits at midnight questioning my life choices.

My advice if you're leaning into this: do it, but don't trust it. Build review habits before you build velocity. Keep an honest log of time spent fixing AI-introduced issues -- that number is higher than you think.

Curious to hear from others who've spent serious time with these tools. Where do you draw the line between AI-assisted and AI-dependent?

Three years ago, building a new software project felt like preparing for a mountain climb. You packed tools, planned every step, searched Stack Overflow for rope, and hoped the weather held.

In 2026, it feels more like stepping into a high-speed train.

Same destination. Different speed.

I’ve spent more than four years deep in Python development, building automation systems, data tools, internal products, and experimental AI workflows. I’ve written code the slow way, the painful way, and the “why did I do this manually?” way.

And if I’m honest, AI coding tools changed one thing more than anything else:

They didn’t replace coding. They removed friction.

How I actually use AI in software development today, why context matters more than hype, and why this gets much harder in SAP.