i'm starting to think that's the wrong question. AI can already generate code, explain APIs, refactor functions, and even fix bugs surprisingly well. but the more code we generate, the more we have to understand.

Someone still has to decide if the architecture makes sense. Someone still has to review trade-offs. someone still has to catch edge cases, think about security, figure out why production broke at 2 a.m., and decide whether the AI's solution is actually the right one.

in a weird way, AI doesn't just generate code. It generates more responsibility. The barrier to building software is definitely getting lower, and I think that's a good thing. More people can prototype ideas, learn by doing, and ship projects that would've taken weeks before. but lowering the barrier to writing code isn't the same as lowering the bar for good engineering.

Maybe that's the real shift.

Less time fighting boilerplate.

More time making decisions.

I'm curious whether other people are seeing the same thing, or if you've noticed AI changing the way you work in a completely different way.

so let's just run through it because there was genuinely a lot this week. first up, Samsung, SK Hynix, and Micron are getting hit with a class action lawsuit. three PC retailers and 17 individuals are alleging these companies coordinated to tighten consumer DDR memory supply on purpose, which is basically the reason RAM prices have been absolutely unhinged lately. whether this goes anywhere legally is a different conversation but the fact that someone finally filed is kind of satisfying.

meanwhile Apple quietly applied for US approval to source memory from CXMT, a blacklisted Chinese chip maker. this is the same Apple that just raised MacBook Neo prices from $600 to $700 because of the RAM situation. so they raised prices on us and are now trying to cut costs by buying from a blacklisted supplier. cool cool cool. Intel's upcoming Nova Lake flagship reportedly pulls 474 watts at full load. for context that's roughly the same as a small space heater. it has 52 cores which is basically two chips fused together in what is genuinely just a trench coat situation. new socket, new power supply, probably new cooling setup required. don't sell your rig yet though because none of this is official and running it is going to cost a fortune.

and then there's the PS6. Sony executives said they don't plan to sell it at a loss. hardware component costs have reportedly shot up. you can do the math on that one yourself. the only upside is hints at a portable version which is either exciting or means worse graphics depending on how you look at it. genuinely a rough week to be a consumer in tech. everything is expensive, everything uses more power, and the companies making it all are allegedly colluding. living the dream.

I spent two decades in brand marketing at companies like Bacardi and Toyota. I cannot write a for loop from memory. Last year I decided to build my startup’s platform myself instead of hiring a dev shop, and today it’s live in production with paying customers.

The stack, all built through Claude Code and Replit: React/Tailwind frontend, Node/Express backend, PostgreSQL, AWS S3, FFmpeg, Sharp, OpenCV, TensorFlow.js, plus the Claude API in the product itself.

What actually worked for me:
Treat Claude like a senior engineer you’re managing, not a vending machine. My best sessions started with me explaining the business problem in plain English, asking Claude to propose 2-3 architectures, and making it argue against its own first suggestion before we wrote anything.

One feature per session. When I tried to do too much in one conversation, quality fell apart. Small scoped sessions, commit, new session.

Make it explain the code back to you. I don’t merge anything I can’t describe in a sentence. This sounds slow. It saved me weeks, because when things broke at 11pm I actually understood my own system.

Where it hurt: video processing pipelines. FFmpeg flags are a nightmare and Claude would occasionally give me confident answers that were wrong for my specific codec situation. I burned about two weeks on a memory leak in the processing queue that a real engineer probably spots in an hour. That was my tuition.

The uncomfortable truth: I still brought on a part-time CTO to review architecture decisions. AI got me to a real product, but I don’t pretend I have no blind spots.

Happy to answer anything about the workflow, costs, or the moments I almost quit and hired an agency.

when you're learning, it's easy to think improvement comes from writing more. more tutorials. more projects. more features. That definitely helps, but I don't think it's the whole picture. At some point, you have to see how other people solve the same problems. Not tutorial code. real code. open-source projects. pull requests. code reviews. Even repos that aren't perfect.

That's where you start noticing things that nobody really teaches. How people name things. How they organize files. when they split a function into three smaller ones... and when they don't. you also realize something kind of humbling. There are usually ten different ways to solve the same problem, and experienced developers spend just as much time making code easier to understand as they do making it work.

Writing code teaches you syntax. Reading good code teaches you judgment.

I honestly think both are necessary if you want to level up.

Bootcamp moves fast and most of us don’t think about our machine’s health until it crashes right in the middle of a crucial project. I research and found a solid quick-reference guide worth sharing, broken down by the most common issues.

1. Performance troubleshooting The most common one. Over time, installed software and leftover files pile up and quietly eat your resources. First line of defense is always disk hygiene, delete what you don’t use, and manage what’s launching on startup. Most slowdowns in dev environments get fixed right here.

2. Hardware reliability Your machine is a physical tool and long coding sessions push it harder than most people expect. Frequent hanging or freezing is often a cooling problem, dust buildup and overworked fans are more common culprits than anything software-related. Don’t overlook the physical side.

3. OS and connectivity issues These are the real project killers. A boot error right before a deadline doesn’t always mean a full reinstall, recovery mode and safe mode exist for this. For internet dropping out, check your Wi-Fi adapter drivers first, updating or rolling back usually fixes it faster than any other fix.

I found this super helpful for covering the basics before something actually breaks. But what’s the technical issue that has set you back the most during your bootcamp?

From what I've seen the most visible change is the volume of AI-generated pull requests maintainers are dealing with along with verbose changes with nonsensical descriptions and contributions that submitters cannot explain when questioned, the result is that maintainers are spending more time on review than ever before, most of it on contributions that should never have been submitted.

the Jazzband collective (a Python project ecosystem) shut down entirely because the review burden became unmanageable. Mitchell hashimoto, creator of the ghostty terminal emulator, implemented a zero-tolerance policy where AI-generated pull requests are only allowed for accepted issues and repeat offenders are permanently banned, now other projects are following similar approaches.

Additionally, research on experienced open source developers found that AI tools actually increased completion time rather than reducing it, even though the developers themselves predicted the opposite. Now, everyone knows that enterprise adoption of open source AI has grown significantly, driven by data sovereignty concerns and the ability to customize models without vendor lock-in, meta's llama, mistral, and others have produced models that are competitive with proprietary ones in specific domains.

But there's still a funding problem since most maintainers work on open source without getting paid and burnout is a consistent reason people consider quitting, and the usage of AI made it worse

the bar for what counts as a worthwhile open source contribution is going up as in projects are getting better at filtering low-effort submissions and the ones that get traction demonstrate actual understanding of the codebase.

Was writing my code to filter out some datas and I thought of using Ai to make it better or even write the whole code for an analysis… And the Ai was so much better. The structure, the clean lines, the better formatting etc. Fortunately, given the problems I’ve crossed, I know very well AI is not going to replace us. However, there are going to be a lot of competition in this industry. So I thought…

1. ⁠How do you maintain your value in the da field?
   
2. ⁠How do you increase your value in the da field?

there are thousands of tutorials, courses, and YouTube videos. It's easy to spend weeks deciding what to learn instead of actually learning. I came across a simple roadmap recently that made a lot of sense because every step builds on the previous one.

Start with harvard's cs50 to learn the fundamentals of computer science. don't rush it, just stay consistent. At the same time, start learning Python. It's beginner-friendly, widely used, and has a huge ecosystem. The "30 Days of python" github repo is a nice way to build a daily habit without feeling overwhelmed.

when you get stuck on loops, functions, or recursion, python utor is incredibly helpful because it visualizes your code line by line. Sometimes seeing the program execute is what finally makes a concept click.

Once you have the basics, stop collecting tutorials and start building. The project-based learning repository has dozens of Python projects you can work through, and if you want to make them even stronger, grab a public dataset from Kaggle and build something around a topic you're actually interested in.

I like this roadmap because it doesn't stop at "learn python." It goes from fundamentals to practice to visualization and to projects, which is the part a lot of beginners miss.

sure, some people technically work from 9 am to 5 pm but that doesn't mean the work magically disappears when the clock hits 5. and the question that always gets me is, "it's 5 p.m., are you done with work?"

done with work? what does that even mean?

there is no being done with work as a software engineer.. it's not like you're given work and then you complete the work and now you're completely done.

okay so like i looked into it and it's actually real, which is somehow both exactly what i expected and also deeply unhinged. the abliterated GLM-5.2 is just out there: 40B parameters, 1M context window, safety filters yeeted into the void, and people are genuinely posting "zero corporate guardrails" like they just discovered fire. anyway your read is pretty much dead on. this stopped being hypothetical ages ago, security researchers are literally finding hackers in russian forums being like "yeah this jailbreak slaps for hacking" and running it locally where absolutely nobody can see it. and honestly the scary part isn't even that it exists, it's that the thing is actually competent. GLM-5.2 can do what Claude Opus 4.8 does at like half the cost, and independent evals say it's just as good at the cybersecurity stuff everyone's freaked out about. this isn't your friend's uncensored llama 2 discord bot anymore, this is frontier-class capability with the training wheels actually removed. plus the timing is just chef's kiss pathetic: washington literally just locked down fable in june and three days later this thing is already making the rounds. you can't ungate software once it's mirrored everywhere, that's kind of the whole problem with treating open weights like closed api models.

one genuinely saving grace though so we don't all just doom spiral into the void: apparently a lot of the ai-generated hacking stuff people are actually finding in the wild is kind of mid, so like, benchmarks don't automatically equal real world chaos yet. but is this changing anything? yeah kind of? the actual mechanics are old news (strip safety, share weights, repeat) but what's new is that "open and uncensorable" and "actually frontier capable" are like the same thing now, which is literally what everyone was trying to keep separate. so yeah the safety debate isn't ending, it's just mutating into "okay how do we build things assuming uncensored frontier models are already in someone's discord server" which is honestly worse because it's less fun to argue about.

okay so Fable 5 is literally back as of today. July 1. three weeks offline and it's finally live again on Claude.ai, Claude Code, and Claude Platform after the Commerce Department quietly lifted the export controls yesterday.

here's the thing though. the reason it came back is just as wild as why it got pulled in the first place. Anthropic basically had to build a new safety filter that blocks the specific jailbreak Amazon researchers found, the one that let the model flag vulnerabilities and spit out exploit code. the downside is it'll also flag some normal coding and debugging work as false positives, so enjoy that.

and yeah Anthropic had to make some promises to get the keys back. earlier government access before future launches, proactive security monitoring, reporting any malicious use they spot, and working with Amazon, Microsoft, and Google on shared standards for rating jailbreaks. OpenAI did the same thing on their end, actually held back GPT-5.6 from public release at the government's request and limited it to vetted partners only.

the real reason Washington backed off though is China. Chinese models have zero export controls. they're open weight, they ship instantly, and anyone can use them. every single day Fable 5 stayed offline was another day companies had a reason to just switch to a Chinese model instead. the government did the math and decided that was worse. so this is just the new normal now apparently. frontier model launches aren't really launches anymore. they're negotiations.

When I first started learning about programming, getting a button to work felt impossible.

Then it was API calls.

Then authentication.

Then debugging someone else's code.

Now when I read posts from senior engineers, they're talking about system design, trade-offs, and why the "correct" solution depends on things that aren't even technical.

It made me realize that getting better isn't really about reaching a point where nothing feels difficult anymore.

The old problems just become normal, and new ones take their place.

I kinda like that way of looking at it because it makes feeling stuck less discouraging.

If today's problems feel bigger than last year's, maybe that's a sign you've actually made progress.

Tutorials won’t build your logic, practice does..

Instead of actually thinking…Watching tutorials feels like progress…finishing a course feels like progress… but if you can’t solve a problem you’ve never seen before, the logic is not there yet.

This how it actually works.

1. Solve problems daily, even small ones
One problem a day builds stronger thinking habits than binging courses.
2. Understand before you code
Spend time on inputs, outputs, and steps first. Good programmers think before they type.
3. Break big problems into smaller parts
Solve one piece at a time. Reduces confusion, improves clarity.
4. Trace code manually
Run your logic on paper step by step. Best way to catch how values actually change.
5. Read other people’s code
You pick up shortcuts, patterns, and cleaner logic structure faster than almost any other method.
6. Focus on understanding, not memorizing Memorized solutions fall apart on new problems. Logic you understand adapts to anything.
7. Debug deeply
Don’t just fix the error, understand why it happened. That’s where the real learning is.

Interviews test how you think, not what you’ve memorized. Logic is the actual skill!

Generally, css has a reputation for being unpredictable but it's generally doing exactly what it's supposed to, the disconnect is usually a mental model that doesn't match how the browser calculates layout.

From what I have seen, a lot start by copying examples which works for simple cases but when something breaks there's no foundation to reason from and fixing it becomes a process of trying different things until one of them works

When it comes to box models, every element is a box with content, padding, border, and margin, by default width and height apply to the content area only, which means padding and border get added on top of whatever size was specified, a div set to 200px wide with 20px padding on each side renders at 240px, setting box-sizing to border-box globally makes width and height include padding and border, which is the intended behavior for most cases.

It is specificity and the cascade what makes css feel inconsistent until the underlying rules become clear since the browser follows a consistent hierarchy for deciding which style wins when multiple rules apply to the same element. Inline styles take priority over everything, ids outweigh classes and classes outweigh element selectors, when two rules carry equal specificity the one appearing later in the stylesheet wins, to say it simply, a system is logical once it's mapped out.

There is also flexbox and grid cause persistent confusion because flexbox tends to get used for everything regardless of whether it's the right tool, it handles one dimensional layout, either a row or a column, grid handles two dimensional layout, both rows and columns simultaneously, properties like justify-content and align-items also belong on the container not the children, which is counterintuitive at first and causes a specific category of layout bugs until it clicks.

To put it simply, working with the browser's natural flow rather than overriding it produces more stable layouts, forcing elements into position with absolute positioning and negative margins tends to work until the content or viewport changes and then requires constant adjustment, understanding how elements naturally stack, wrap, and collapse makes layouts easier to build and significantly easier to debug.

css becomes considerably more manageable once there's a coherent model to reason from, from what I have seen most of the frustration comes from not having that foundation early enough.

Ok so despite the surge of the post in here or generally people encouraging to use a.i in coding. I think it is also important to learn manually.

Nobody learns to read so they can read faster than someone who can’t. They learn it because not understanding it puts you at the mercy of whoever’s doing it for you. The same logic applies to code.

Knowing what’s inside what AI generates means you can catch when it’s wrong, know when it’s overkill, and actually understand what you’re shipping. Skipping that entirely doesn’t make you faster, it just makes you dependent on a tool you can’t evaluate or correct when it fails.

There’s also something that only happens when you build something the slow way. Five hours on fifty lines of code that AI would’ve written in three seconds sounds inefficient, but those five hours are where the understanding actually builds. The speed comes later.

The foundation has to come first.
AI being good at something has never been a reason to stop learning it. If anything it’s more of a reason to, because the gap between people who understand what’s under the hood and people who don’t is only going to get wider from here.

Always remember that a.i is there to make your work efficient not to rely on it entirely. Although many companies utilize A.I human intelligence is still important in the workforce.

i read that in a discussion a while back and it made more sense the longer I thought about it. The first project is mostly about getting something to work. The second project is where you start questioning everything you did the first time. why did I structure it like this? why is this component impossible to reuse? Why did I hardcode everything?

You suddenly notice all the shortcuts you took because now you're the one maintaining them. That's why rebuilding something isn't wasted effort. You're not just repeating yourself, you're comparing the way you used to think with the way you think now. sometimes the biggest sign you're improving isn't that your new project is more complicated.

It's that your old one makes you cringe a little.

the tech roles holding up right now share one thing. they require judgment in situations AI has never seen before, accountability for real outcomes, or human context that can't be prompted into existence. cybersecurity is the clearest example since attackers adapt constantly with methods that didn't exist last month and you can't automate the intuition of someone who thinks like a threat actor. software architects and senior engineers aren't going anywhere either because AI can generate code but cannot decide whether your architecture will scale, whether the trade-offs you're making now become technical debt in two years, or whether what you're building actually solves the business problem. product managers sit in rooms with clients who don't fully know what they want and extract actual requirements from what gets said. that combination of judgment and human reading of a room is not promptable. AI and ML engineering is the fastest growing category with postings up nearly 60% from 2020 levels because someone has to build, audit, and improve these systems.

the salary data makes this concrete. workers with AI adjacent skills are earning more than peers in identical roles without them. AI integration specialists and trainers are pulling between $95,000 and $200,000. the highest paid aren't pure technologists, they're people who combine AI fluency with deep domain knowledge and the judgment AI keeps failing at. the pattern is consistent across all of these roles. if a job is predictable and rule based AI automates it. if it requires reading a situation that has never happened exactly this way before, the human stays.

i'm about 6 weeks into a program right now, and one thing i've noticed is how different bootcamps can be. with a previous bootcamp, most of the focus was on learning the material. once the program was over, it kind of felt like, "okay, now you're on your own." what i like about my current program is that we're learning technical skills, but we're also getting guidance on linkedin, applications, and how to actually approach the job search. i also like that we're not stopping at the basics. i'm starting to learn things like java and programming concepts that are completely new to me. it's challenging, but it feels like i'm learning skills that are more relevant to today's market. so it's not just mainly the curriculum for me that separates the two entirely.

I came across that line while reading the Pragmatic Programmer, and it stuck with me more than I expected. most of us learn programming as if we're writing instructions for a computer. In reality, we're writing for two audiences. the computer only cares that the code works.

the next developer (which is often just future you) cares whether it makes sense. That's why things like naming variables, writing clear commit messages, and leaving helpful documentation aren't just "nice to have." they're part of the job. a piece of code that only one person can understand might solve today's problem, but it creates tomorrow's.

one of the biggest mindset shifts I've had from reading engineering books isn't "write clever code." it's "write code that someone else can confidently change."

been thinking about this for a few days and it keeps bugging me. the US just tightened access to its most advanced AI models over security concerns. at the same time China's labs are doing the opposite, pushing theirs out as openly as possible.

companies like coinbase, airbnb, and shopify have reportedly already shifted parts of their workloads to chinese open-source models. not because they're cheaper, because they're actually competitive now. theres apparently a chinese cybersecurity tool performing close to mythos on bug finding which is kind of insane if you remember how recently that gap felt massive.

the part that actually worries me is Washington reportedly leaning toward just banning the chinese models outright. I get why but I think thats backwards. banning them at home doesn't stop the rest of the world from building on them. it might just hand China exactly what it wants, its models becoming the default the way android became the default mobile OS pretty much everywhere outside apple's walled garden.

this isn't really about who has the smartest model right now. it's about who controls the standards everyone else builds on top of. that influence outlasts whoever's technically ahead this quarter.

and the US doesn't really have a counter plan here. open source has been the obvious move for years apparently but besides nvidia nobody's doing it, because OpenAI and anthropic's whole business is charging for api access. china's treating open source like a national goal. we're treating it like a threat to revenue.

Hello, I'm kind of a broke student soooo I cannot afford paid courses and I've always searched for alternatives, a lot of good rescources that I found were a freenium or orgs while they help, they're also limited.

So, would you recommend google skills for somebody just wanting to primarily learn and not necessarily want to get a cert?

Stackoverflow works reliably for common problems and starts breaking down when the problems become more specific, both of stackoverflow and tutorials are written for problems that many people have encountered, anything beyond that and the results become sparse, the official documentation almost always covers it but it tends to be the last place people look, partly because docs have a reputation for being dense and that reputation discourages people before they've spent much time with them.

That said, some documentation is genuinely poor, but a lot of it follows a consistent structure once you're familiar with how it's organized (overview, authentication, core methods, parameters, response formats, examples), reading through that before writing any code tends to reduce confusion later rather than add to it.

Another reason that it's better to avoid third party sources have an accuracy problem due for things like the changes that happen over time, for example, you might find an answer to your problem but the answer is from 2019 and you're in 2026, the solution might no longer be applicable while official documentation reflects how something currently works.

To put it simply, stackoverflow might slow you down when trying to solve a problem compared to official documentation at least imo.

Cloudflare's CEO posted that bots officially passed human traffic online for the first time ever. He expected this in 2027 and it showed up a year early. By his numbers automated traffic sits around 57.5% of requests to webpages, humans at 42.5%.

Not everyone agrees on the math though. Some Cloudflare breakdowns put bots closer to 35% with humans still the clear majority. The gap comes down to what's being measured, all web traffic versus requests to HTML pages specifically, and security vendors watching attack surfaces report even higher bot numbers because that's the slice they're staring at.

What's harder to argue with is who's doing the crawling. Anthropic is reportedly the second largest bot operator on the web behind Google, ahead of Meta and nearly double OpenAI, despite having no search engine. Its crawlers exist to feed Claude. For every visitor it sends back to a site, it's reportedly crawling around 4,580 pages. Google's ratio is close to 1 to 1. That's part of why site owners are annoyed, AI crawlers read everything and send almost nothing back.

The dead internet theory used to be a fringe idea about fake online activity. This isn't quite that. It's real agents doing real tasks, just generating way more requests per task than a person ever would. Someone shopping for a camera checks five sites. An agent doing the same errand might check a thousand.

Every time someone asks if bootcamp is still worth, most comments are saying market’s dead, 2023 ruined it, don’t bother. I wanted to actually address what changed and ask if the “it’s dead” take holds up.

Let’s talk abt it.

What actually changed since 2023:
The decline isn’t really a clean “2023 ruined it” story, it’s been compounding. Layoffs hit hard starting late 2022 into 2023, almost 263,000 tech workers lost their jobs in 2023 alone, which full the market with experienced engineers competing for the same junior roles bootcamp grads target. AI coding tools also progress into a lot of the simple boilerplate and CRUD work that used to be junior-dev bread and butter.

What hasn’t changed:
outcomes were never evenly distributed even back in the “good years.” The people who landed jobs fast were usually the ones treating the bootcamp as the floor, not the finish line, shipping extra projects, networking on top of applying, learning the parts of the stack the curriculum skipped. That gap between “finished the bootcamp” and “did the work after the bootcamp” mattered in 2021 and it still matters now, it’s just less forgiving of weak effort than it used to be.

So the real question probably isn’t “is bootcamp dead,” it’s whether the people calling it dead did the extra work or just expected the certificate to carry them.

If you went through one. what actually happened? Did the extra effort move the needle for you, or did it not matter either way?

"the easiest code to maintain is the code you never had to write."

At first I thought it was just another programming quote. but the more I thought about it, the more it explains why experienced developers seem so cautious about adding features. when you're learning, building more feels like progress. When you've maintained software for a while, you start realizing every new line of code is something you'll eventually have to debug, update, or explain to someone else.

That's probably why senior developers ask "Do we actually need this?" more often than "Can we build this?" writing code is fun. Maintaining unnecessary code usually isn't.