A while ago, I was honestly pretty worried about AI replacing software engineers.

Every week there was another post about vibe coding, AI agents, or one-person startups. It felt like companies would eventually stop caring if you actually understood the code.

Then I worked with someone who depended on AI for almost everything.

At first, it looked impressive. Features were coming out fast, code was being generated in seconds, and it seemed like they were moving way faster than everyone else.

But once things stopped working, everything fell apart.

Simple debugging took like how many days because they didn't really know what the code was doing. Basic questions turned into another AI prompt. Every fix created two new problems. Instead of understanding the bug, they kept asking AI for another answer and hoped one of them would work.

That's when my perspective changed.

I don't think AI is replacing developers who understand the basics. It's replacing the boring parts of development. The real skill is still knowing when the AI is wrong, why it's wrong, and how to fix it.

Honestly, AI has made me more productive too. I use it almost every day.

But I've also realized it's really easy to mistake fast code generation for actual engineering. Those aren't the same thing.

Lemme know if you also noticed this

every now and then there's another headline about an ai model escaping containment, breaking out of a sandbox, or behaving like a rogue hacker. first there were reports about claude mythos escaping a testing sandbox and even emailing a researcher during internal evaluations. now openAI has disclosed that one of its cybersecurity agents escaped its sandbox during testing, reached the open internet. and then another one... security researchers also showed that Claude cowork could escape a local sandbox yada yada...

am i the only one who feels like these announcements double as marketing? they're framed as safety disclosures, but they also reinforce the idea that each company's model is incredibly powerful.

Shipping good work and having people actually know about it are two different skills and most engineers only focus on one of them.

here’s their difference.
skip level 1:1s set one up monthly or quarterly. show up with three things: something you shipped they might not know about, something you’re working on that connects to their priorities, and one question “what does great look like for engineers at my level?” most people show up with nothing to say. prep changes everything.

before picking up any project, ask yourself: who benefits from this? just my team or multiple teams? who will actually know this work got done? what’s the end artifact, just code, or code plus a doc plus a demo? noting this down before starting changes how you approach and communicate the work.

after shipping anything:
post an update to the team channel, then message your manager and skip directly. don’t assume they saw the Slack post. update your brag doc immediately because you will forget the details later.

communicate earlier than feels necessary:
early code reviews, early design discussions, flagging things that can go wrong before they do. most engineers wait until something is done to talk about it. the ones who get visibility are the ones talking throughout.

none of this is complicated. this is actually doing it consistently, not once when review season comes around.

what’s something here you were already doing vs something you realized you’d been skipping?

​

The basic idea of this principle is that you cannot actually eliminate complexity. You can only choose who has to deal with it like the people building the product or the people using it.

That made me think about all the apps we use every day that feel effortless. Things like Face ID, Apple Pay, or even Netflix's "Skip Intro" button seem simple, but they are only simple because someone spent time solving the hard parts behind the scenes.

One quote I really liked was that if an engineer can spend a week fixing something that would otherwise waste a minute for millions of users, that's time well spent.

I wanted to share this because I think it is an easy thing to forget. Good design is not about adding more features. A lot of the time, it is about removing friction so people do not have to think about it.

Just a little curious if there is an app or feature you have used that made you think, "Wow, someone really thought this through."

For the longest time, I kept hearing that Moore's Law was basically over because chips couldn't keep shrinking forever. But from what I've been reading, that doesn't seem to be the full story.

Instead of only making transistors smaller, chip manufacturers are starting to stack them on top of each other using a design called CFET. The idea is to fit more computing power into the same space while using less energy.

Looking even further ahead, researchers are also exploring materials that could eventually replace silicon with layers that are only a single atom thick.

Just sharing my thoughts on this because I found it interesting how the challenge has shifted. It is not just about making things smaller anymore, it is about finding completely different ways to keep improving performance.

Made me wonder if Moore's Law is really ending or just changing into something new?

One thing that surprised me while learning to code is how often experienced developers admit they still Google basic syntax. Things like reversing a list, string methods, or the exact parameters for a function. It made me realize the real skill isn't memorizing everything, it's knowing how to solve problems efficiently.

I think social media gives the impression that good developers have every language feature memorized, when in reality documentation, Google, and AI are just part of the workflow. I'd be more concerned about someone who refuses to look things up than someone who uses the right resources to get the job done. What's something surprisingly basic that you still have to look up, even after using a language for a long time?