AI coding tools boost developer output but shift risks to review, governance, and software quality

I’ve never been good at stopping what I’m doing. AI has made this problem even worse. Near the end of a recent workday, I was looking forward to closing my laptop and enjoying a relaxing dinner with my family. I had a few minutes free around 4:30, so I decided to check on a dormant project: a pile of prototypes and old data I’d been putting off for months. I opened up the files and threw them into Claude Code to see what was cooking. Seven hours later, I was hunched over my keyboard with bloodshot eyes. And I was really hungry. What happened? It turned out that the dusty pile was a gold mine. I spent hours poking and prodding it with Claude Code, trying to turn it into something useful. But somewhere along the way, I wandered off the track. I somehow ended up building my own compiler to convert the data tables into a different format. This was not the point of the project. All I wanted was a practical application. But instead I found myself at the bottom of a very deep rabbit hole.  It’s just one example of the danger posed by generative AI. It has altered our perceptions of what we can do, how quickly we can do it, and whether we should delegate it. As a CEO, this can be lethal to your workflow. I know there are many other executives who feel the same way. I’ve figured out a couple of ways to keep from drowning. I hope they can be useful to other leaders. Fast vs. slow thinking First, it’s important to understand what’s happening to us. Daniel Kahneman’s fast and slow thinking framework is helpful here. The fast thinking system is reactive and confident. It’s useful when you’re doing things you’ve already done many times and have gotten helpful feedback. You don’t need to look behind you anymore to be sure you’re doing it right. Fast thinking is great for times when you simply need to execute. But the problem is that if you aren’t actually as good at something as you think you are, it can lead to oversights and mistakes. And maybe more important, it crowds out your ability to think more slowly. Slow thinking is harder. But it’s necessary. You dial in to what you’re doing and shut out the rest of the world. CEOs need to be doing more slow thinking if they’re going to solve their toughest problems. Beware the rabbit hole CEOs tend to be energetic, impatient. We just want to get stuff done. As you might expect, that tips us toward defaulting to fast thinking. AI has only amplified this tendency. With vibe coding at our fingertips at any moment, we can easily be nudged into “just one more try.” The LLMs always make us feel like we’re right on the edge of nailing our objective. Agents are not designed to give us honest feedback. They want to push us forward and keep burning tokens. It makes us feel confident that whatever we’re building is going to be great, and it further entrenches us in fast thinking mode. When using AI, my shift into fast thinking is so automatic that I usually don’t notice it happening. That means I need automatic systems in place to fight fire with fire, so to speak. It’s fun to see an AI agent end an exchange with “Done.” But there is a well known difference between what an agent means by “Done” and really being done. So now, before I start working with an agent, I write down what done means to me. Every time. One or two sentences, or sometimes a whole page. That creates a natural boundary. It stops me from acting like a marathon is a sprint. It changes working with agents from a series of dopamine hits to progress toward some goal. And I never miss dinner anymore. Sometimes our natural drive kicks in and we slip past the boundary. And that’s okay. But when you realize it’s happening, you have to take action before you get pulled back into a AI rabbit hole. For me, that means stopping and figuring out who on my team to hand the project off to. You should be hiring people who have the expertise and intelligence to take over your abstracts with only minimal instructions. Otherwise you’ll convince yourself that you and only you can finish what you started. Once you’ve delegated, your role is to act more like a searchlight than a spotlight. Check in periodically from the outside, but don’t get too absorbed. Your main value is in asking questions from a distance that help clarify and guide. An AI nanny That dormant project I mentioned earlier didn’t end with the compiler. Claude suggested I could build a diagnostic tool to tell me how long I could trust my data. When I ran my data through the tool and it found no errors, I called it a win. But thinking it over later, I realized: Just because the tool didn’t flag a problem, was that proof nothing was wrong with the data? What if there was something wrong that the tool’s algorithm couldn’t detect? As a leader, you have to realize that you don’t know everything. And even if you did, you don’t have the time to look everything over.  Because of this, you need to apply healthy skepticism to whatever your agent is telling you. Your agent doesn’t have a human brain; it’s built to fit curves to data. You can’t independently trust its judgment. The best way to overcome this problem is to design validators that check and test whatever you’re using AI to generate. These checkers need to be independent of your agent. AI will gladly write a test it knows it can pass and tell you, “We did it!” And if your agent can touch the checker, it might try to modify it. Our team built several different validators, testing different approaches to make sure our validators were using principles based on real physics instead of just showing us answers we wanted to see. Now, with these validators in place, we can let our AI agents roam freely because we know they can’t pass any tests by accident. Building these tests took longer than building the search. That’s what told me we were on the right track. Look for the unknown unknowns But even well-designed validators can’t anticipate everything. As CEO, your job is to look for the unknown unknowns, because no one else is looking at the big picture as comprehensively as you are. Some AI failures don’t just waste time; they can do real, lasting damage. I once delegated some multi-agent work to one of our senior engineers, who brought on an intern to help. The intern was exploring whether Claude could handle code reviews. At some point an email came through asking for permission to connect Claude directly to our production GitHub repository. I caught it. If I hadn’t and permission had been granted, whatever that process did could have exposed our entire source code to the world. The instinct to treat an AI agent like a trustworthy junior colleague is understandable, but it’s wrong. A human (usually) understands their limitations, and even if they don’t, they have to face consequences for their actions. This creates a natural limitation on their risky behavior. The job of every leader is to apply as much creativity to “What could go wrong?” as we normally do to “What could go right?” In software, we often use the term blast radius. For everything we do, I try to get my team to think in terms of potential harm right at the outset. It’s the mindset a medical device company has to take, but all companies can benefit from it. In these premortems, we imagine something went horribly wrong, and then ask: Why? I pose a lot of open-ended questions, and then try to stay out of the room as much as possible. The power imbalance of a founder present can make honest discussions difficult. You can pretend that everyone on your team feels safe telling you something will explode, but most of the time they’re more concerned about not pissing you off.  I give my managers the autonomy they need to get to the truth. And I reinforce our company’s credo: To succeed here, you need to challenge everything you don’t understand or think is wrong. They have to know that we want them to find trouble before anyone gets hurt. I’ve found that most scientists thrive when they don’t feel like they’re living in a Dilbert comic. Sometimes I do need to be in the room. When I am, I keep my CSO hat on and let everyone know that. This isn’t so hard when the discussion is science, and ground truth takes precedence over power imbalances. Deputize smart people For many executives, the above advice will cut down their AI overload. But for more complicated businesses, AI is simply producing too much output for them to keep up with. In these cases, you need to start thinking about instituting a layer of decision-makers who sit between you and the AI skunkworks teams. These deputies should have your trust, a track record of sound judgment, and strong organizational skills. Their job is to filter prototypes, surface potential gaps in verification, and explain candidate projects to you simply. They should have the authority to shoot things down without your approval. Their goal is to cut down your decision-making surface area, so you’re weighing in only on what’s real and tested. Don’t let AI replace your thinking I’m convinced that AI will replace us only if we let it. As executives, our judgment and our experience got us where we are. I’d wager that these qualities are even more important today than they were five years ago. There are seemingly unlimited opportunities in front of us. Our ability to focus our resources on the most promising ones will determine who survives in the AI epoch.

AI coding tools have solved one problem remarkably well: They can produce code extremely quickly. That sounds obviously good. And most of the time, it is. But software development has never really been constrained by how fast we can type. The expensive part comes later. Understanding the code. Reviewing it. Debugging it. Changing it six months later when the person—or model—that wrote it has forgotten why it exists. Test automation is where this becomes especially interesting. Generating the Test Is the Cheap Part You can ask an AI coding assistant: Write Playwright tests for our signup, login, checkout, password reset, dashboard, invoices, settings, and admin pages. And a few minutes later you might have hundreds or thousands of lines of test code. It feels like incredible leverage. Until the suite starts failing. That’s the argument behind looking at the hidden cost of AI-generated test code. Generation cost has collapsed. Maintenance cost hasn’t. In some cases, AI actually increases it because you now have more code than your team would have written manually. AI Pull Requests Need Different Review There’s another subtle problem. Humans tend to judge large AI-generated pull requests differently. When someone on your team writes 80 lines, you probably read them. When an AI assistant generates 1,800 lines? You skim. You look at the filenames. You check whether CI is green. Merge. That’s dangerous for normal application code and potentially worse for test code because a bad test can happily pass for months. There are good ideas in this guide to testing AI coding assistant pull requests, but the bigger principle is simple: AI-generated tests need validation just like AI-generated product code. “Generated successfully” does not mean “tests the right thing.” Agents Add Another Failure Mode Now we’re moving from AI that writes test code to AI that actually decides what actions to take. That introduces a new question: What if the model chooses the wrong tool? An agent might have access to: browser interaction API calls database queries file operations search internal tools The action itself may work perfectly. It’s just the wrong action. Testing tool-selection failures in AI agents therefore becomes part of testing the product. And dynamic web applications make this harder. Partial renders, changing state, asynchronous updates, and stale context can cause an agent to confidently interact with yesterday’s version of the page. That combination of tool selection, state drift, and partial renders is probably going to become a much bigger QA category over the next few years. Self-Healing Can Heal the Wrong Thing AI test repair is another feature that sounds almost universally good. Selector changed? Fix it automatically. But imagine the application used to have: Submit Order And now has: Submit Quote The test can no longer find its element. An AI repair system finds the new button and updates the test automatically. Technically, it repaired the selector. Semantically, it may have changed what the test means. That’s why I like the idea of evaluating AI-generated test repairs before trusting automatic fixes. Self-healing should reduce maintenance. It shouldn’t quietly rewrite your specification. Measure Trust, Not Just Pass Rate Traditional test dashboards love pass rates. 97.4% passed. Great. But with AI-generated or AI-repaired testing, I think teams need another category of metrics: How trustworthy was the conclusion? That includes things like: Was the failure reproducible? Was a selector repaired? Did the test behavior change after repair? Was the failure caused by infrastructure? Did AI classify the failure correctly? How often do humans override AI conclusions? That’s why these ideas around measuring AI test failures in CI matter. The next generation of QA dashboards probably won’t just say PASS or FAIL. They’ll tell you why the system believes the result. AI Should Reduce Abstraction, Not Increase It This is where I think test automation is heading in an interesting direction. The worst outcome would be: AI generates enormous automation frameworks that humans barely understand, then another AI maintains those frameworks because humans can no longer understand them. That’s technically impressive. It’s also a strange place to end up. The better outcome is AI generating tests into representations humans can still inspect, understand, and modify. Use AI to remove work. Don’t use it to create a larger black box. Because the real productivity metric isn’t: How much test code did the AI generate? It’s: How much less testing infrastructure does your team have to think about?

As software engineers and tech builders, we are watching a massive transformation unfold. Between relentless hype, corporate layoffs, and billions poured into AI infrastructure, many are asking hard questions: Where is the tech industry actually heading? Are we investing billions in tech that just displaces jobs without creating macroeconomic value? Here is a deep breakdown addressing the core doubts around AI's economic reality, production system architecture, and long-term job security for developers. Q1: Is the current AI boom just hype and layoffs without real economic value? The Reality: It is a mix of a short-term hype cycle and long-term productivity gains. Real Economic Value: Corporate data shows tangible value generated through automated customer support, advanced fraud detection, and accelerated developer velocity. Hype & Market Correction: Many companies invested blindly due to FOMO (Fear of Missing Out) without clear monetization models. Coupled with post-COVID over-hiring and high interest rates, the industry is undergoing a necessary market correction rather than an existential collapse. Q2: If AI takes everyone’s job, who will buy the products? The Macroeconomic Paradox (Prisoner's Dilemma) The global economic engine relies on a straightforward flow: JOBS — → Salaries — → Purchasing Power — → Corporate Revenue (Government Taxes, Multinational companies products, subscriptions etc) If widespread automation destroys job markets, disposable income vanishes—meaning consumers cannot buy groceries, vehicles, or SaaS subscriptions. Companies aren't doing this to intentionally collapse consumer markets; they are caught in a classic Prisoner's Dilemma: Company A cuts operational costs by 80% using aggressive automation, allowing them to undercut competitors. Company B must replicate this to survive today, even if reducing workforce purchasing power hurts macroeconomic demand tomorrow. The Long-Term Equilibrium: Markets eventually adjust. If automation leads to systemic structural unemployment, policy mechanisms like AI/Robot Taxes and Universal Basic Income (UBI) will likely emerge to sustain consumer purchasing power and economic balance. Q3: How do consumer AI platforms (ChatGPT, Claude, Gemini) actually work under the hood? AI models are merely the probabilistic "brain"—they require a full-stack, distributed web architecture to operate at scale: Architectural Layer Core Technologies Primary Function Frontend React, Next.js, WebSockets, SSE UI, Markdown rendering, real-time token streaming, artifact sandboxing. Backend API Go, Node.js, Python (FastAPI), Redis Authentication, rate limiting, billing, chat history persistence, RAG pipelines. Inference Engine vLLM, TensorRT-LLM, Triton Model weight management in GPU VRAM and real-time response token generation. GPU Compute Infrastructure NVIDIA H100/B200 Clusters Massively parallel hardware execution and low-latency network interconnects. Key Takeaway: AI is shifting software engineering from manual boilerplate syntax to System Architecture, Complex Problem Solving, and Orchestrating AI Agents. Because AI is probabilistic (it hallucinates), critical distributed systems, security boundaries, and infrastructure design will always require human engineers. Q4: How do developers survive and thrive in this era? Here are 4 strategic shifts every engineer should make to stay indispensable: 1. Shift from "Code Writer" to "System Architect" AI handles boilerplate syntax, CRUD operations, and basic endpoints effortlessly. Your focus must shift higher up the stack: Focus Areas: Distributed System Design, Microservices Communication (gRPC, WebSockets), Event-Driven Architecture (RabbitMQ, Redis), and Database Architecture (Indexing, Partitioning, Query Optimization). 2. Master "AI Orchestration" Instead of building every feature from scratch, modern senior developers integrate LLMs into backend systems to automate complex workflows: Retrieval-Augmented Generation (RAG): Connect vector databases (Pinecone, PGVector, Qdrant) with enterprise data. Agentic Workflows: Build autonomous multi-step execution scripts using frameworks like LangChain, CrewAI, or custom Python/TypeScript runtimes. API Integration: Seamlessly connect self-hosted (vLLM/Ollama) or managed (OpenAI/Anthropic) endpoints into scalable backend services. 3. Deepen Domain & Problem-Solving Expertise AI knows syntax, but it lacks real-world business context and domain-specific edge cases: Core Value: Analyze complex business constraints first, then translate them into precise architecture blueprints and system prompts for AI tools to execute. 4. Build & Showcase Full-Stack AI Products A static resume is no longer enough; recruiters and engineering leads want proof of execution: Portfolio Action Item: Build an end-to-end production application combining a standard full-stack setup (React/Next.js + Node/Python + PostgreSQL) with integrated AI capabilities (real-time streaming, vector search, or asynchronous background agents using Redis/RabbitMQ). Proof of Work: Publish clean code on GitHub, document the architecture with system design diagrams, and share a video walk-through on LinkedIn and X. 💡 The New Engineering Reality: "AI will not replace software engineers. Software engineers who master system architecture and AI orchestration will replace those who don't." What are your thoughts on where software engineering is heading in the next 3 to 5 years? Let's discuss in the comments below!

Apparently AI was supposed to make developers work less. That was the idea, anyway. Write code faster. Automate the boring parts. Finish the same feature in half the time. Close the laptop at 2 p.m. and go become the kind of person who owns hiking shoes for reasons other than taking out the trash. That is not what happened. A lot of developers are working more with AI, not less. Not because AI is useless. The problem is almost the opposite. AI is useful enough that it makes more work feel worth doing. There is a name for this kind of thing: the rebound effect. The Rebound Effect The rebound effect is what happens when something becomes cheaper or easier, and people respond by doing more of it instead of simply enjoying the savings. You make cars more fuel efficient, and people drive more. You make lighting cheaper, and people light more buildings, more streets, and more screens. You make code cheaper to produce, and, well, look around. The washing machine is the easy example. It did make laundry easier. No question. But it did not simply delete laundry from household life. Standards changed. Clothes got washed more often. People owned more clothes. Clean clothes every day became normal instead of fancy. Historian Ruth Schwartz Cowan wrote about this in More Work for Mother. Labor-saving technology often saves labor on the individual task, then quietly raises the standard for how much of that task everyone is expected to do. AI looks a lot like that, except the laundry is software and the hamper is Jira. Why Developers Are Working More The real difference with AI is that it lowers the activation energy of programming. Before AI, a lot of ideas died in the parking lot. You would think, "I could build that," and then immediately remember the setup, the docs, the boilerplate, the weird library behavior, the test data, the CSS problem hiding under the couch, and the two hours you were about to lose to some TypeScript error that looks like it was generated by a cursed obelisk. So you would do the healthy thing and ignore the idea. Now you can ask an AI to scaffold the project, explain the library, write the first pass, generate the test cases, fix the annoying bug, and summarize the docs you did not want to read. The idea that used to feel like a weekend suddenly feels like something you can try before dinner. That sounds great, and it is great. But it changes the math. Instead of eight hours of work becoming four hours of work and four hours of leisure, it becomes eight hours of work with twice as many things attempted. Or ten hours, because now you are on a roll. This is where the rebound effect shows up. AI lowers the cost of doing software work, so more software work clears the bar. The side project becomes reasonable. The refactor becomes reasonable. The docs become reasonable. The "quick" prototype becomes reasonable. The little polish pass becomes reasonable. The feature nobody asked for but you can suddenly imagine shipping by Friday becomes, unfortunately, reasonable. More Things Become Worth Doing This is the key shift: AI does not just make existing tasks faster. It changes which tasks feel worth starting. A task that used to be obviously too much work now sits right on the line. Maybe it is not worth two days. But is it worth forty minutes with an AI assistant? Maybe. And once enough tasks move into that category, your day fills back up. The TODO list does not shrink. It mutates. You close one ticket and notice three adjacent improvements. You fix one bug and ask the AI to search for similar bugs. You write one endpoint and decide the client library should probably be updated too. You generate tests, then notice the tests could be better, then notice the code could be easier to test. This is not laziness. It is not hustle culture either, at least not always. A lot of developers genuinely like building things. AI removes enough friction that the part of your brain that says "eh, tomorrow" gets quieter. Economists have a related extreme called Jevons paradox. Make something more efficient, and total use can go up instead of down. Steam engines got better at using coal, and coal use increased. Programming tools get better at producing software, and we produce more software. Companies Will Not Invent the Four-Day Week for You To be fair, this is not only a personal problem. There is a company version too, and it is not subtle. If one developer with AI can produce what three developers previously produced, companies are unlikely to say, "Great news. Everyone can work Tuesday and Wednesday and spend the rest of the week making soup." They are more likely to say, "Great news. Imagine how much software we can ship now." Then competitors adopt the same tools. Expectations adjust upward. Yesterday's impressive output becomes tomorrow's baseline. The washing machine did not eliminate laundry. It helped make daily clean clothes feel ordinary. AI may do something similar to software. Leisure Is a Choice, Not an Automatic Dividend None of this means AI is bad. I am not interested in pretending that writing boilerplate by hand was some kind of character-building exercise. Getting unstuck faster is good. Exploring more ideas is good. Spending less time fixing infuriating bugs is very good. The issue is what happens after the savings show up. Technology can create surplus time, but surplus time does not automatically turn into leisure. Usually it gets spent. Sometimes by your employer. Sometimes by the market. Sometimes by your own ambition at 11:30 p.m. when you really should know better. So if you feel busier with AI than without it, you are not imagining things. AI made you faster, and then your backlog immediately noticed. The real trick is not learning how to use AI to do more work. Most of us figured that out pretty quickly. The trick is deciding when not to.

Introduction If you're a Software Engineer, the last few years have probably felt chaotic. The industry is changing aggressively, and it's easy to feel tired, overwhelmed, or anxious sometimes. I have too. But at the same time has been very exiting to see how things change. This article won't talk about which model is best or which tool makes you a "better engineer." There are already hundreds of articles about that. Instead, I want to share honest thoughts about AI from a human perspective, the good and the bad, and how I think things will evolve. New models drop every week, social media floods us with lots of information and hype, and staying up-to-date feels impossible. The good news: once you accept that you can't keep up with everything, it gets easier. Focus on what actually matters and ignore the noise. Keep in mind that the industry moves fast and some things here may already be outdated by the time you read this. AI is breaking the silos around programming A few years ago, programming was a huge barrier for most people. Sure, tools like Wix and WordPress made websites easier for lots of people, but building more complex applications still required coding skills. Then ChatGPT launched in November 2022, almost four years ago, and everything changed. How many products never saw the light because they were too expensive to build? How many small businesses couldn't afford the internal tools they needed? Now, thanks to LLMs, more people can create those applications even without deep programming knowledge. Not every problem can be solved this way of course, but a surprising number can. And LLMs will only get better. I personally have small scripts that I use daily that were created entirely with AI, scripts whose code I have never seen. They will only be used by me, so I don't really care about the code. This applies to non-programmers too: problems that used to require buying an app or paying a subscription can now be solved in a few hours with AI. Custom tools are cheaper than ever. Non-technical teams can also automate the tasks they've been putting off. You can create a prototype, and get feedback from others. It won't be production-ready sometimes, but it might be good enough to validate an idea. Solid programming fundamentals can help you get more out of AI when building applications, but you don't need them to start. Experiment, build, iterate. Your next product or company might begin with a vibe-coded idea. AI as a teacher Studying with AI in 2026 is absolutely great, more interactive and fun than it was in the past. I wish I had these tools during college. At least for me, there is no way back. Currently, my study workflow consist of studying documentation, reading articles and forums to understand concepts in depth, then asking AI for examples to complement my learning. Sometimes I reverse the order, starting with AI generating some code and then cross-checking with other sources. When practicing a language topic, I still prefer writing some code myself, but focused on the topic. You might wonder: why write code manually in 2026 if AI writes all the code? Because how can you develop judgment about AI-generated code if you don't understand it? And I don't mean the syntax itself, actually that's the least important, but the security, scalability, maintainability, and performance of generated code. Or at least that's what I think works best for me. If you're just starting in this field, I believe it's still very important to learn to code by hand, the same way mathematicians learn math by hand even though there are calculators and computers that can do calculations faster than a human. It's just part of the learning process. Once you know what conditionals and loops are, you don't need to remember the exact syntax, you just know when to use them. As engineers, one of the worst things that you can do is to blindly trust AI and not be able to judge if it's right or not. Mastering a language and its ecosystem takes years. Knowing the right libraries and tools for a given use case is backed by years of failures and lessons learned, and that makes the difference when designing systems. The fundamentals of Software Engineering haven't gone anywhere: concurrency, protocols, networks, algorithms, design patterns, performance, scalability, security, and testing. You still need to know how to correctly apply these concepts and tools. Fundamentals are more important than ever Imagine a library where all the shelves are behind locked doors, and all the keys sit at the entrance, but you don't know which key opens which door. Even with the right key, you still need to navigate the labeled shelves to find the right book. Knowing what to prompt is the key that opens the door to the right section of the model. If you don't know the vocabulary or the topic, that knowledge is simply hidden from you. For complex problems, vague questions won't be enough. You need domain knowledge to get the right answer. Repetitive tasks and specific needs can often be solved with a simple script or integration. But how would people even know that's possible without the vocabulary? That knowledge is there inside the model, accessible to everyone if they know what to ask. The same applies to mathematics, physics, chemistry, marketing, finance, or any other field. Only if you know the field can you access that information. Less manual writing, more responsibility Generating more code doesn't mean generating good quality code. AI is not responsible if something goes wrong, you are. Depending on the software you work on, errors can cost money or impact lives. Ask anyone in healthcare. Critique the generated code like you would review a PR from another human. You don't necessarily need to understand every line, just like we don't read the assembly code a compiler generates. But you need enough understanding to judge what's good and bad. When working on a feature, put extra effort in understanding the solution. Your future self will thank you. More important than the code itself: understand the product, customer needs, the actual problem you're solving. Everything else is just implementation detail. Strong requirements and acceptance criteria are crucial for getting good code from AI. It can easily forget the company policies or best practices you follow in your organization, so it's up to you to ensure the solution is correct. Lastly, don't rely on LLMs for everything. Use deterministic tools for static analysis and code quality checks. Then add review steps, whether by humans or agents, through skills and scripts. Now we can focus on what matters more: building proper test suites, discussing architectural decisions with depth, and tackling problems previously out of reach. There is no excuse. Refactors that were unmanageable and features that were too expensive are now achievable. It Will Take Years for Universities to Adapt Traditionally, it takes years for universities to adapt their study plans to market needs. For example, during my degree, professors discouraged the usage of Node.js. When I started working, I found it was one of the most in-demand technologies (and it still is, with TypeScript). Courses barely covered React and Angular. If I hadn't spent my limited free time as a student learning backend and frontend frameworks on my own, getting a job would have been much harder. Now companies expect new hires to be familiar with AI tools, as you can see in recent job openings. As a student, how do you manage your limited free time to learn the most in-demand technologies on your own, and also add a ton of new AI tools and concepts on top? A new engineer might feel overwhelmed about skills, rules, agents, models, tokens, context windows, spec-driven development, RAGs, MCPs, just to mention a few. Remember that AI is a tool, just like IDEs and compilers are. You can always learn Claude Code or OpenCode on the way, but four years of solid engineering fundamentals will pay off in the long run. Don't skip that part. If you're just starting college, AI tools will likely be more mature and stable when you graduate, so the adaptation will be smoother for new generations of engineers. Hopefully there won't be as much AI hype by then. When a technology becomes boring, it's usually a good sign that it's mature and stable. Disruption of software business models Programs are now easier to replicate, making it harder to monetize solutions that can be copied quickly and with minimal investment. Companies whose business model relied on being hard to replicate from scratch are at risk. Others find their product value unclear in this new market. Not all will adapt unfortunately, and some people will lose their jobs during restructuring processes. In January 2026, Tailwind's founder announced a 40% drop in documentation traffic and 80% drop in revenue, leading to 75% layoffs. Their model was driven by documentation traffic and one-time "lifetime access" payments, with no recurring revenue to sustain them when income dropped. AI became the middleman for information, damaging their business model. Another example is Jetbrains. They make great IDEs, but this year I've been using IntelliJ and GoLand less and less in favor of lightweight editors like VS Code, Zed, and Neovim. For me, it's hard to justify the Ultimate license cost. More people seem to be switching to lightweight editors too. At the same time, new AI companies are emerging and growing fast with fewer employees than traditional companies but making even more money, e.g. Cursor, and AI providers like OpenAI and Anthropic. Open source and the AI market war Open source is another threat for many companies, and not everyone sees it. I expect greater adoption of open-source alternatives in the coming years. Linux desktop usage is at an all-time high, and more people are trying open source software as a replacement for paid applications. I think this is good for people, given the abusive subscription culture we've seen in recent years. Additionally, not all companies have the same muscle to invest in AI. A 100-employee company can't match a 10,000-employee company. This could hurt small and medium-sized businesses. Adopting AI means integrating it into the core of the organization, which isn't cheap. Even a $200 subscription per employee adds up to a considerable amount at scale. API usage isn't cheap either. How can they spend thousands or millions of dollars on AI without raising prices for their products and services or restructuring? The AI market will eventually stabilize, like smartphones did. Every release felt revolutionary a few years ago; now most people don't care. Every technology matures this way. AI companies aren't just trying to replace humans, they're trying to capture market share from each other. If a competitor launches better and cheaper models, people will switch, and sometime cause dominant players to panic. These companies need paying customers just to keep the hardware running. And let's not forget that China has very cheap and capable models these days. Because of that, you should not stick with a single AI provider. Explore different options. You might find open-weight models that fit your needs. We don't know if they'll exist in five years. Conclusion Coding has never been the goal of software engineering, but the means. We are engineers, we solve problems. Code is just a way to solve them. If AI writes your code, it means now have more time to spend on better designs, architectural decisions, and proper testing. There is no excuse anymore. It's okay to feel anxious sometimes. But learning new things is also part of the fun. Try not to pay too much attention to AI gurus on social media. Choose high quality sources of information and limit your exposure to garbage content related to AI. Some companies will adapt faster than others. Some won't make it. If you're starting your degree, investigate your market needs and focus on that. Check LinkedIn for what companies are requiring. Don't try to stay up to date with every trend. Choose one tool and become very good with it. Even if you don't write or read code in the coming years, you still need to know what you're doing. Don't skip learning the fundamentals. You are responsible for the code you deliver. Keep your brain sharp and be able to search on your own. Read articles, books and official documentation. That skill will be useful when AI struggles with complex problems. This field has always rewarded those who stay curious. AI is just another chapter in a long history of tools that has changed how we work. It's not the first time we need to reinvent ourselves and won't be the last. Learn the fundamentals, build things that matter, and don't forget to enjoy the ride.

Background Artificial Intelligence has rapidly transformed the way software is built. Modern coding agents can scan entire repositories, refactor thousands of lines of code, and even coordinate multiple specialized agents in parallel. With larger context windows, they can "remember" architecture, documentation, and business logic across vast projects something that once required weeks of human effort. Introduction We're living in a moment where AI can churn out code faster than any human ever could. But speed isn't the same as wisdom. Great engineering has never been about typing lines of code; it's about asking the hard questions, anticipating risks, and knowing when not to build. Yet most AI tools today resemble eager junior developers: they recognize patterns, generate code, and quickly move on; but they rarely pause to question the ‘why’ behind their work. What they lack is the judgment, empathy, and tribal knowledge that seasoned engineers bring to every decision. If we want AI to be more than a code factory, we need to teach it to think like best engineers; cautious, curious, and deeply human in its approach to problem-solving. Memorization vs. Generation in AI Think of AI like a student who has read millions of books: Memorization is when the student repeats a passage word‑for‑word because they’ve seen it so many times. Generation is when the student uses what they’ve learned patterns of language, logic, and style to write something new that sounds right, even if they’ve never seen that exact sentence before. The coding agents which leverage Large Language Models (LLMs) mostly generate by predicting the next word based on context. But sometimes, especially with common phrases or famous quotes, they slip into memorization and reproduce text exactly. Understanding vs Memorizing Modern AI tools (like GitHub Copilot or ChatGPT) can read your entire project in seconds. That’s like giving someone a library card to every document in your company. But ask yourself: If you read every medical textbook, does that make you an experienced surgeon? No! Because information is not the same as experience. The AI knows what your code looks like. But it doesn't know why a messy piece of code was written that way to stop a server crash three years ago. Engineering Judgment Many people think a programmer's job is just typing code into a computer all day. In reality, experienced engineers spend most of their time asking questions before they type anything: Why are we building this? What happens if this breaks? Is there a simpler way to solve this without writing new code? Writing code is easy. Knowing what not to write is the hard part. The Rules AI Doesn't Know Every team has unspoken rules learned from past mistakes. We call this tribal knowledge: Don't touch the billing system at the end of the month! Leave that weird bug alone our biggest customer actually relies on it! We tried that 'clean' idea two years ago and it crashed the website. Right now, AI doesn't know these stories. If you ask AI to "clean up" old code, it might accidentally delete a safety check that was put there for a very good reason. What a "Smart AI Partner" Would Look Like Imagine if AI didn't just follow orders blindly but acted like a helpful senior coworker who watches your back. Here are few examples. Deleting Code Basic AI: "Done! I deleted that code for you." Smart AI Partner: "Wait! I checked the history and that code was added after a bug where customers were charged twice. Are you sure you want to delete it?" Cleaning Up Old Code Basic AI: "I rewrote 500 lines of code to make it look modern and neat!" Smart AI Partner: "Wait! This code hasn't broken in 2 years, and we have a big product launch next week. Should we leave it alone for now, so we don't risk breaking anything?" There Is No "Perfect" Code In school, there is usually one right answer. In software engineering, everything is a trade-off: Sometimes simple and repetitive code is better than fancy, complicated code. Sometimes a team writes quick and messy code on purpose to launch a product on time. An AI that only knows textbook rules will try to make everything "perfect." A true engineering AI understands real-world trade-offs. Conclusion AI's future in software development won't be defined by how quickly it can generate code, but by how wisely it can help us decide what code should be written and when it shouldn't. True engineering is about judgment, trade-offs, and empathy for the people who rely on the systems. To make AI a genuine partner, you must teach it to pause, ask "why" and respect the messy realities of deadlines, risks, and tribal knowledge that shape real-world engineering. Progress lies not in replacing human judgment but in amplifying it. Key Takeaways for Developers: Encourage AI tools to act like senior engineers questioning assumptions, flagging risks, and suggesting restraint when needed. Recognize that "perfect" code is a myth; engineering is about making the best trade-offs for the situation. Use AI to enhance decision-making, not just accelerate typing. Content Credits - This blog-post contents were formatted with ChatGPT to make it more professional and produce a polished content for the targeted audience.