aiopinionpiece2_text=`
# AI in STEM & Security - Part 2
###### By Daniel Moreno
###### AI · 20 min read · Aug 8, 2026
---
![image alt ><](./assets/ai_brain.jpeg)
 *Source: https://www.ibm.com/think/topics/artificial-intelligence* 

Greetings and permutations everyone. Over the summer, I had an internship and spoke to a lot of different people at different stages of their career. In addition, I served as a SME for a large, agentic project. While doing that, I realized that my [previous post](./blogpage.html?page=aiopinionpiece) was insufficient, especially since I didn't discuss what might happen if AI keeps improving. I want to address a few of those gaps today.

### Is AI improving?

If we look online, there's certainly plenty of anecdotes to reflect the idea that the quality of AI-generated code is increasing. However, let's look at the data.

![image alt >< 80](./assets/ai-time-horizon.png)
 *Source: https://metr.org/time-horizons/* 

To explain this graph, GPT-2 could complete a task that would require a human engineer 1 second about 80% of the time. GPT-4 could complete a task requiring 53 seconds. GPT-5.2 could complete a task requiring 1 hour and 6 minutes. As you can see, this is a logarithmic curve. Quite honestly, it looks like the bottom of a sigmoid curve. There's plenty of other benchmarks too, like the ones from [Scale Labs](https://labs.scale.com/leaderboard). Even areas where they still struggle, like [complex reasoning](https://hai.stanford.edu/ai-index/2025-ai-index-report), are seeing improvement over time.

Even if we ignore the Mythos hype, from what I've seen and heard, internal models tend to perform even better. In addition, we don't need full AGI to see an impact on the world and our jobs.

### What if AI keeps improving?

Now, as I mentioned last time, I mentioned that I am a skeptic when it comes to the maximum potential for AI. For example, if AI is a statistical model, then it will produce the mean or whatever the peak of the distribution curve may be. However, the distribution curve for code is heavily skewed towards the terrible. As such, without improving the data sets, AI is generally going to pump out terrible code. However, as we just saw, AI seems to be improving over time, for a given definition of "improving". As such, what happens if that continues? Whether you love or hate AI, it is here, and it might not hit a ceiling for some time. Beyond that, the possibility of future improvement can have just as much of an impact as the actual realization of that improvement, simply because companies are trying to get ahead of the curve. Also, it is best to consider all possibilities and decide how YOU will approach them before those possibilities arrive.

The biggest issue is for early-career workers. According to [Stanford](https://digitaleconomy.stanford.edu/app/uploads/2025/11/CanariesintheCoalMine_Nov25.pdf), we've seen a 16% decline in jobs for workers aged 22-25 within "AI-exposed occupations... while employment for experienced workers remained stable." This isn't surprising. I would absolutely agree that the newest models are on par with your average intern or junior SWE in terms of knowledge and competency. They can fix bugs, plan small features, and do the first pass on implementing a major feature but a senior dev will still need to review and tweak all of it. Basically, a Senior SWE + AI = Senior SWE + Junior SWE so why bother hiring juniors? This really isn't any different than the countless times all of us have gotten additional responsibilities and workload without any additional benefits or pay. More output with fewer people at the same pay is the ideal world for a company.

I don't think that it is unreasonable to think AI will create a floor in the career ladder where it is financially not worth it (at least in the short term) to hire anyone below that floor. Unfortunately, we need those positions to train up and create the next generation of senior engineers. Now, in terms of average employee age, the SWE industry as a whole is on the young side so we won't see the impact immediately. However, this could cause major issues if we don't create a new way for juniors to gain expertise.

Update: I'm not the only one worried about "cognitive atrophy" where there simply aren't juniors being trained to take the place of seniors. [This talk from Goldman Sachs](https://www.goldmansachs.com/insights/goldman-sachs-exchanges/building-ai-systems-for-capital-markets) is another example.

Now, some people (and I'm not an exception) have compared the integration of AI to previous examples of industrialization such as replacing shovels with excavators. Hand-coding is still fine for small-scale, boutique projects, but the excavator will let us make far grander projects. There's a few issues with this specific example. Firstly, by some metrics, the development of excavators and other industrial equipment **has** reduced the number of construction workers, at least by a percentage of the population. Where we once had 10 men with shovels, we now have one man with an excavator. That doesn't even touch on all of the other specialists that once existed. Secondly, this assumes that our need for software will scale like our need for massive skyscrapers has. Thirdly, replacing a shovel is replacing a small fraction of the full construction process with a machine that is still operated by specially-licensed humans. That is a false equivalency with AI, especially under the assumption that it will keep improving. Under that assumption, it would be more accurate to imagine a tool that excavates yesterday, a tool that excavates and lays the foundation today, and a tool that excavates, lays the foundation, puts up the walls, and paints the walls tomorrow.

We're seeing something closer to the industrialization of software, especially if AI keeps improving.

#### What if we learn AI?

This really isn't an "if" because that implies you'll get a choice. If everyone else is using AI and seeing 2-times productivity boosts, you'll need to use AI too, or the company will get rid of you for underperforming. Ultimately, AI will simply set a new expectation. We're already seeing that. Even if we ignore the already-occurred layoffs (like in gaming where [28% of devs were layed off this year](https://gdconf.com/article/gdc-2026-state-of-the-game-industry-reveals-impact-of-layoffs-generative-ai-and-more/)) and the potential efforts to downsize, I can't tell you how many managers and directors I spoke to this summer where their first question was whether I had experience with AI. Not just using AI in a basic sense, they wanted to know if I knew when to use one model over another, if I could distinguish the output of different models, if I could use a single prompt where someone else might use multiple. This is becoming the new norm where we are simply expected to have another skill. There will absolutely be new jobs as we divide those who build foundational models, those who train models, those who work on the infrastructure, and those who integrate AI.

![image alt >< 80](./assets/title-shrank-skill-grew.webp)

![image alt >< 80-tall](./assets/lifecycle-of-ai-job-titles.jpg)

Just as cobblers and seamstresses didn't get a choice to move into factories, neither will you. Some are still around, but not many. In addition, the job is no longer profitable or respectable in the same way it once was.

#### What will happen to the software?

If it does go the direction of industrialization, the same thing as always will happen. It's great for efficiency and scale so it might lower prices. Even it is always higher quality, human-written code will become a luxury. It's the difference between hand-crafted furniture and factory-made. After all, we just want something good enough, cheap enough.

How much hand-crafted furniture do you own? How much of that did you buy as opposed to inheriting?

#### Will society collapse around us?

This depends on two things: how many fields are affected and the rate of change. If SWE is the only field affected, that sucks for us, but society will be fine. If it takes 30 years for AI to improve enough such that SWE gets phased out, then we will be fine too. Society and we will have enough time to adjust and retrain.

To use historical examples, typists tooks about 80 years by some estimates, cobblers took about 50 years to replace, and travel agents collapsed within 10 years. I don't know the time horizon for AI.

#### What happens if the code goes beyond us?

This is a definite possibility. AI code is weird and that could become worse as AI gets better at making code. Just imagine if all codebases were written as if for code golf. What happens if AI discovers and proves that code golf really is the best and most efficient format? What happens when I can no longer review the conclude? Does my job just become signing off on black boxes?

#### What would be the extreme?

For right now, AI is purely digital as robotics hasn't caught up yet. If only AI continues improving to the extreme end of things, manual labor will become the realm of humanity and human effort. After all, this extreme version of AI could do the rest.

### Will AI democratize software engineering?

I've mentioned it before, but I have a background in history and a deep interest in linguistics. As such, I'm going to have to ignore how much I hate the word "democratize", how unclear its definition is, how it gets misused...

Sorry. I'll stop ranting about that and get back to the point. Keep in mind that accessing and owning a service are different things. If you are entirely dependent on a handful of providers for models, hosting, and all of the other considerations, then you've simply made yourself reliant on them. Worse, the barriers to entry for AI hosting (at least in its current state) means that you won't have many people rising up to challenge those providers at a commercial scale. This monopoly/oligopoly just means that things are going to get worse and worse in terms of quality. The old strategy of "amazing at first; make you dependent; milk you dry" is just as true for AI as it has been for every other area of the technology industry. Now, you might say that open-source or open-weight models will fix this particular industry. However, for the vast majority of people in the USA, owning and running the hardware necessary to run AI is an impossibility. Keep in mind that the average US citizen is already far richer than good chunks of the world which means most people in the world will never be able to own and run their own AI.

Next, keep in mind that if you as an indie dev are seeing productivity gains from AI, so are the big companies. In fact, speaking from personal experience, they have models you don't know exist. They have instructions, prompt templates, skills, and agents that perfectly fine tune the models to maximize productivity gains. Whatever you can do, they can do better.

Also, look at YouTube. Making it easier to create simply creates a sea of content for everyone to sift through. Now, you're at the whims of whatever curation algorithms exist. If AI "democratizes" software engineering, that doesn't create a level playing ground. It just means we're going to flood the Internet with yet more content, probably with a stricter quality divide than ever. Keep in mind that attention is finite so the amount of content an individual can consume is finite. Short of increasing the population, that means demand is finite.

### Will AI help create more demand to meet its increased supply?

Maybe. If it can create a new industry or truly novel way to do things, then perhaps. However, this goes back to the time horizons I mentioned previously. In addition, we'd have to hope that the new industry is actually beneficial.

### Are we replaceable?
Ultimately, this is what all of us are wondering.

A growing number of companies have come to the realization that a growing number of customers are willing to pay a premium to interact with a human when they call in. That willingness increases as the circumstances surrounding that call become more devastating, difficult, and emotional. I don't know how many companies will realize this, nor do I know how many will be willing to charge that premium. However, more and more are... which is great for everyone in a call center.

Doesn't really help us, does it? After all, the vast majority of customers will never interact with the computer engineers, computer scientists, software engineers, IT technicians, IS analysts, or cybersecurity personnel. However, IT help desk is in an interesting position since they definitely interact with a large number of annoyed/distraught/emotional people. However, they primarily work with "internal customers" where customer experience matters far less from a profit perspective. Ultimately, I think that they are mostly safe from AI, but we've already seen how companies are handling IT help desk: offshoring. That's extremely unfortunate because IT help desk could have served as an extremely important entry-level position where people could learn about technology before advancing into higher positions.

For the rest of us, it depends.

#### Personal Limitations

Not everyone is cut out to be a code orchestrator. Some people, for whatever reason, choose not to or can't go beyond entry-level or mid-level SWE. This is going to be a new role, and not everyone is suited for it. Honestly, not everyone will even want the new job. That's not a condemnation of progress or them so much as a honest assessment of capabilities. This is especially true with AI where the focus will become architecture, orchestration, review, and documentation. Quite honestly, those are most people's least favorite parts of the job already. What happens when they become the entire job?

#### Wasted Money

Some SWEs are easily replaceable. This summer, I heard someone comment that their internship left them with a lot less sympathy for those getting laid off because you could easily lay off 10-20% of their team without seeing a drop in productivity. That comment and a few others are what spawned this entire post so I want to discuss some of the thoughts behind it and see how AI will affect these considerations.

Firstly, there are lazy people who ended up in SWE because they were told it's easy money. I've certainly seen plenty of people graduate with degrees and that mentality. AI, even if it doesn't improve, means that SWE is no longer easy money. People can no longer afford the luxury of thinking like that, and they will be the first ones to go as AI tightens the noose around all of our necks. In a way, Cs may get degrees, but they don't get a job if an AI can do the same work. Beyond that, all of the trivial tasks that allowed them to look productive, like incrementing the version number of consumed APIs, are being automated so they can't hide as much.

Secondly, there's been plenty of research that productivity is lost as teams grow in size. After a certain point, each new member provides diminishing returns. When looking at metrics, it's far harder to distinguish 1 and 2 units of progress than 5 and 10 units of progress after their productivity was multiplied by AI. If a company looked at tha second set of numbers, what do you think they would conclude? Perhaps that they can afford to downsize?

Thirdly, a lot of companies end up in the mindset of "I'm a X company with some Y". To use a silly example, let's imagine a restaurant who says "I'm a pizza restaurant with some delivery drivers". Obviously, restaurants aren't alive and can't think so the people thinking that are the ones in charge. Because the managers are thinking it, that is the tone for the entire corporate culture and will be picked up by everyone at every level. They'll act accordingly. For example, they'll probably hire more wait staff, cashiers, or janitors than they actually need. They'll probably put more software engineers on teams that support the wait staff than on teams that support the delivery drivers. Maybe management is right. If so, then everything is fine. However, what happens if we now exist in post-COVID times, if a majority of their profit is now from deliveries? What happens if that pizza restaurant is 50 years old and "I'm a pizza restaurant with some delivery drivers" is engrained in everyone's thinking? Well, money is now being lost because nobody is checking whether their approach/thinking matches the reality of their profit statement. The SWE teams for delivery drivers are probably overworked and understaffed while the SWE for wait staff are suffering from diminishing returns, lazy members, and way more. Now, what happens when AI comes along? In all likelihood, the managers are going to take a hard look at SWE team performance. Without needing to recognize the core flaw in their thinking, the managers can see opportunity to implement AI and downsize the SWE teams that support wait staff. While it sucks for those people getting laid off, the managers aren't incorrect that the teams can be downsized, and AI lets them arrive at the correct conclusion without them needing to challenge any of their underlying assumptions. Now, **to be clear**, this is not targeted at any particular company nor any company I've worked at. In fact, the best example I can currently think of is an airline, and it wasn't SWE teams targeted. However, the general pattern is applicable to **our** industry.

#### Nothing to do with AI

I was recently recommended [this video](https://www.youtube.com/watch?v=swtfbef3HhM) because it brings up the point that AI replacing you is simply the latest excuse for layoffs rather than the real reason. In addition, it points out that some of these layoffs have been reversed, at least in part. While I don't agree with *every* point, I think that the creator makes a lot of, at the very least, thought-provoking comments far better than I could so I'll let you watch it yourself.

### What is SDLC 3.0, and what do I think of it?

While I don't want to track down its origins, I believe that a book called *SDLC 3.0: Beyond a Tacit Understanding of Agile* helped to popularize a new concept: SDLC 3.0. Rather than the Waterfall of 1.0 or the Agile DevOps of 2.0, 3.0 focuses on the use of AI, though I don't know how closely we follow the initial concept. There's also things like the [BMad Method](https://github.com/bmad-code-org/bmad-method) and [GitHub's spec-kit](https://github.com/github/spec-kit) which follow a similar philosophy.

~~~

UNDERSTAND --> PLAN --> IMPLEMENT --> VERIFY --> REVIEW --> DOCUMENT --> DELIVER --> CLEANUP

~~~

This is the most basic approach, with one subagent per phase in a more traditional SDLC. An orchestrator agent receives a request and delegates it to the appropriate subagents with activity looping back on discovery, failures, or scope change. UNDERSTAND might interview the user, walk through the design tree, resolve dependencies, or explore the codebase. PLAN constructs a clear plan which will be used by later agents to construct their internal TODO lists. IMPLEMENT makes the changes while VERIFY builds and lints them. REVIEW checks the rest of the codebase to ensure it still works and compares the changes to the output of PLAN. Finally, everything is documented by DOCUMENT and pushed by DELIVER which may also make any relevant MRs. CLEANUP removes any files, branches, or the like used by the SDLC 3.0 pipeline that are unnecessary afterwards. For example, all work probably occurred on a separate worktree, and PLAN probably output a full file so that later subagents could read it in as necessary. All of that would need to be cleaned up. Also, an important note regarding the orchestrator is that it requires near-deterministic markers and phase gating rules. For example, you could instruct IMPLEMENT to always return 1 of 5 values: [IMPLEMENTATION_COMPLETE], [IMPLEMENTATION_PARTIAL], [NEEDS_CLARIFICATION], [NEEDS_INPUT], or [SCOPE_CHANGE]. Depending on which tag is returned, the orchestrator can redirect execution to the correct phase. By standardizing the communication between subagents and the orchestrator, it prevents confusion or wasted time. The orchestrator may also choose to skip certain tasks based on the complexity. For example, a trivial change requiring less than 5 lines may only require IMPLEMENT while a simple change may able to skip PLAN. Perhaps you only run part of REVIEW when less important changes are made.

~~~

UNDERSTAND --> UNDERSTAND-VALIDATE --> PLAN --> PLAN-VALIDATE --> IMPLEMENT --> IMPLEMENT-VALIDATE --> DOCUMENT --> DOCUMENT-VALIDATE --> DELIVER --> DELIVER-VALIDATE --> CLEANUP

~~~

Another approach would assign at least 2 dedicated subagents to each phase: one to perform the action and one to validate that action. The VERIFY and REVIEW components would now be split across 5 different agents, each phase's dedicated validation agent being run after that phase is completed. The orchestrator agent ensures that everything continues working like a state machine.

A more extreme versions might create 3 "acting" subagents and 3 "reviewing subagents" which each using a different model. If multiple models agree, then you can assume a higher degree of confidence. Another option might be to further subdivide the subagents based on domain. Perhaps there will be multiple IMPLEMENT subagents, each specializing in a different language, or multiple DOCUMENT subagents with one creating diagrams and another creating requirements documents. Perhaps the IMPLEMENT-VALIDATE subagents are split into: architecture, security, tests, code correctness, code quality, infrastructure, UI/UX, performance, accessibility, privacy, observability, and cost. Other option would be to add a final agent at the very end of the pipeline which reviews the full pipeline and session to improve the agents, instructions, and skills, kind of like [SkillOpt](https://github.com/microsoft/skillopt). You could also have an agent that saves important details to reference files within a wiki skill, allowing the skill to take the place of RAG in a cheaper and more versatile version. Another benefit of this approach is that you can have a human read the wiki skill, both to review it and to teach them about the codebase.

There are a lot of advantages to SDLC 3.0. Firstly, you can apply the principle of least privilege very easily. PLAN may need to read and write files, but it probably doesn't need access to bash. The VALIDATE subagents may not need to write to files. DELIVER only needs to read files and have access to your Git MCP server. If nothing else, whitelisting an AI's capabilities is always a good idea, as shown by recent news. Secondly, normal agents lack any understanding of when a task is done. They will simply keep iterating until all instructions are satisfied by their understanding, and then, they'll ask the user if they should do another round of iterations. The user needs to compare the agent's output against the acceptance critera. They need to consider all of the edge cases and possible ramifications. The SDLC 3.0 pipeline helps to resolve a lot of that. Thirdly, agents lack understanding of **GOOD** software engineering practices, let alone internal and proprietary patterns or best practices. Especially in the more extreme versions as you build separate subagents for specific purposes, you can provide that knowledge. Fourthly, agents struggle with long-term thinking and planning. Some of this is related to their context window as things can eventually slip out of it. In addition, whatever context window is advertised, not all of it is actually usable. Ordering the agents to always use the Todo tool can help, but having a detailed plan goes a very long way towards keeping the agents on-task and ensuring they don't forget anything. Basically, the PLAN agent lets you implement spec-driven development for AIs. Fifthly, agents really struggle with efficient tool and MCP server usage, not to mention context management. After reviewing token usage reports, I can't tell you how many are wasted by checking all tool definitions it has access to, calling tools, calling the wrong tools, and more. Creating skills to explain them and whitelisting tools all help, but there are limits as everything is still being injected into every session, regardless of whether it is relevant. That doesn't even get into context management, the context window, or how something like VS Code GitHub Copilot restricts the number of tokens a single agent can use. With SDLC 3.0, let's imagine an alternative. UNDERSTAND spends 7k tokens reading README.md, 36k tokens reading all source files, 500 tokens reading terraform/main.tf, and 500 reading .gitlab-ci.yml before outputting a 4k token summary to the orchestrator. Now, the 44 thousand tokens read in by UNDERSTAND aren't cluttering up the orchestrator's context window and aren't wasting the orchestrator agent's separate token limit. If nothing else, it helps to prune the tree of memories so semantic search isn't quite so inefficient, provided you aren't pumping all of this into RAG.

That being said, SDLC 3.0 is still limited by the quality of AI. Garbage in, garbage out still applies to it as SDLC 3.0 just applies duct tape over the underlying issues. In addition, all of this burns through tokens like crazy. At which point, you have to ask whether training a junior SWE into a senior one will be cheaper in the long run than senior SWE + AI. Also, keep in mind that fully autonomous agents don't truly exist. However, human intervention is still required to be reliably successful.

### How does cognitive science apply to AI?

This is an interesting topic that I wasn't super-familiar with until this summer. However, you can map certain aspects of AI design to human cognitive science. While it is nowhere near 1-to-1, it gives you something to aim for when adding new features and a way to frame discussions with people less familiar with AI's intricacies. For example, Graph-RAG uses techniques inspired by ACT-R activation decay, Hebbian learning, and Ebbinghaus forgetting curves to forget stale information and reinforce frequently-used memories. FTS5, Hebbian co-activation, local embeddings via sentence transformers, and emotional feedback buses can also be useful to track trends, compression & auto-merging, retrieval, and way more.

You can also view the AI in terms of the 4 types of memory. The context window serves as working memory (the dry-erase board) to track the system prompt, messages, and tool outputs within the session. An external database may serve as episodic memory (the timeline) to record all past events and interactions. A vector database, knowledge graph, or wiki skill functions as semantic memory (the encyclopedia) to track all facts, definitions, and knowledge that has been acquired. The system prompts, agent code, and LLM weights cover procedural memory (the skillset) which governs all skills (in the human sense), rules, and behavioral instructions. Each type of memory requires different storage methods, different retrieval algorithms, and different training methods, just like a human.

Another thing is to distinguish between using AI for System 1 and System 2 thinking. While this also doesn't perfectly match up with the traditional definitions of those terms, you can think of System 1 AI thinking as doing things while System 2 is thinking deeply about things. While AI has its struggles with writing code, I have found it really helpful when reviewing code. It can challenge my thinking, force me to consider my biases/assumptions, point out edge cases I missed, and more. While I wouldn't recommend acting on them 100% of the time, it can be useful for rubber-duck debugging and analyzing stuff while allowing the style and tone to remains yours. In addition, System 2 thinking is at the core of what makes SDLC 3.0 so interesting as the multi-agent systems move away from rapid, heuristic decisions towards multi-stage processes with planning, analysis, and retroactive review.

### What about AI security?

This is a nightmare. There's no other word for it. Like a lazy teenager, they'll find the easiest and most letter-of-the-law solution possible. They will cheat and find every gap in the wall imaginable. This can be found in things as trivial as training an AI to solve a video game to as major as the HuggingFace incident. Skills serve as plaintext repositories of information, nearly begging to be stolen. Each prompt and everything the AI touches ends up in its dataset with the potential to be spit out at a later date. Skills are treated as trusted operational guidance which is a problem considering [26.1% of analyzed skills contain at least one dangerous pattern](https://arxiv.org/abs/2601.10338). While that does not mean they are malicious, that doesn't make them less of security risks. Instructions mix natural language instruction with executable code before feeding them into non-deterministic statistical guessing machines. Besides rendering static analysis and even some kinds of dynamic analysis worthless, it means that a user can approve something that sounds useful while the agent does something else. That doesn't even get into prompt injection which is a nightmare to try and prevent when even [emojis are dangerous](https://arxiv.org/html/2601.00936v1). What about accidental prompt injection as models do things the user didn't intend? Was the user sufficiently clear in defining their inputs and outputs, in defining their acceptance criteria, in defining what is off-limits? Did they think like a human or like the AI? Can the AI interpret their intent and connotations from their words? For example, an AI will treat the prompts "make me a sandwich" and "sudo make me a sandwich" very, very differently.

People are working to implement security measures. Grammar-Constrained Decoding is an interesting approach, and I would recommend reading [this paper](https://osf.io/s9gu6/overview) and [this paper](https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2024.1406857/full). Proprietary models and data-scrubbed prompts can help. We can implement static & semantic review processes, run dynamic analysis multiple times in a sandbox, sandbox agents entirely, create permission manifests, whitelist tools, apply runtime enforcement controls, separate skills into trust tiers based on provenance, and log every action. However, security is playing catch-up while the industry is trying to tack AI on to everything it can imagine.
`