What is Changing?
I stand continually amused and concerned at the gap between real-industry adoption of AI and the discourse online. If you survey the Internet, and ask It how the software industry is adopting AI, you will receive the entire range of answers: one corner will say "trepidatiously"; the next will tell you "carelessly"; some people believe everyone is on the adoption curve, and yet some will claim that no serious engineers touch the stuff.
Well, let me give you an accurate testimony in mid-2026:
- I do not personally know a single engineer who does not use some kind of AI tooling in the workplace.
- Almost all Enterprise shops are using Copilot, with CC/Codex usage limited or prohibited.
- Serious work with AI is done almost strictly in the process-level harnesses of Claude Code or Codex. If you are writing by hand or copy and pasting code, I have some bad news to deliver from 2025.
- Serious engineering with AI involves a lot of architecture, documentation, and a high-level understanding of traditional software practices and the SDLC. To date, there is still no accounting for taste. The gap between juniors and seniors is widening for this reason.
- Almost all serious folks embracing this movement are consuming an entire $200-price-point subscription (or multiple) every month, which is a massive subsidy compared to the rates we pay over API / enterprise billing. Generally, folks are capping their weekly limit every week. The $200 subscription point goes from looking expensive to seeming cheap pretty quickly. To most of us, it feels somewhat magical very suddenly.
If these takes, to you, are not self-evident or uncontroversial, you might not be a software professional, or you are in one of its niche extremities. There are few problems today that are tractable to a human senior, but intractable to a senior using CC/Codex under supervision or well-structured guidance.
Almost Nothing is Changing, in Theory
Yeah, not that much at least. Tone and conversation are changing faster than anything else, which is not abnormal for a hype-driven industry. The projects that I see being worked on with AI are the same projects that preceded it. The dev-teams that are adopting it are, generally, the same ones who were there prior. There are changes being made around hiring and firing, but these are pretty speculative and also hype-based (I do think some traditional junior engineers struggle right now, but you would be wrong if you thought juniors walking in with AI-nativity aren't sought after).
Dev practices are exceedingly the same, though you could argue that a change in pace so substantive constitutes a change in substance all-together. If you want to know more about my position, read on to my second post in which I defend another hot take: that the successful AI-native dev cycles are just the proven human dev cycles, and the effective process with AI is essentially just the same process every senior engineer is acquainted with already. Walking into 2026 as a senior engineer, you need very little new education to become extremely proficient with a harness and some tokens.
So Where Are We Then?
Despite stating that almost nothing is changing, it's also a time when we seem to be on the brink of massive change, so I'm not sure how to reconcile those things. This is not a piece of prophetic text, I am not telling anyone where the industry is going, and I am not capable of divining what capacities the model-providers will attain (anyone who can, including the providers, stands to make absurd amounts of money, so I think I'm in good company here).
Do You Have Advice?
Yep, sit down and ask yourself: "how would I do this here engineering task if I had an absurd amount of time to guarantee results? What would the project look like if I could do things correctly from the beginning and not optimize around throughput?" What are the parts of the system? How do they interact? What technology should you be using and why? What are the expected issues and which parts of the system make them non-mission-failures?
Write it down. (Call it a spec, it's basically just some architecture documents.)
See if you can understand how you would execute on it yourself. Consider the steps you would take. Where would you start? How would you organize the work? If you had to go through piece by piece, how would you build the system? How would you verify it? What rules would keep you on track and how would you stay productive? What levels of abstraction and proof-of-concept will you tolerate? Etc.
Write it down. (Call it CLAUDE.md, it's just how you work.)
Think like you would if you had, I dunno, ten little software Minions. They can't step on each other's toes. Figure out what they can do at the same time, and what needs to be done before other things can be begun. Organize a set of tasks that resemble your work stream, parallelized if necessary, and document how they should take on units of work.
Write it down. (Call it a Plan, it's basically just some JIRA Epics. Nasty, I know.)
Ok, go pick your harness. Turn it on. Watch it. Tell it to carry out the units of work you have arranged. You'll probably find it makes a lot of mistakes with your process. Figure out what it is doing wrong.
Write it down. (Call it a Skill, or a rule, or an MCP for your third-party integration. It's just some prompts reducing complexity for the agent as it navigates a context it can't contain or take on tasks with domain-knowledge.)
Ok, now go back to the beginning and figure out how you can automate these processes at large (i.e., agentic code review in CI, useful perpetual tasks that yield background timesaves, and so on).
Notice each time that you're doing the same thing. Once you are in this rhythm, you will find yourself repeating the same tasks, over and over.
Run it all in a loop that keeps track of its own state. (Call it whatever you'd like, as you won't be picky at this point as you see a sort of fool-proof means of materializing functional systems from your thoughts, so long as they are well-organized.)
Sounds like a lot of hard work? Yeah, actually, but, er, you don't really have to write any code. Just rigorously verify it.
The Bottleneck is Time Management (still)
Something wrong? My advice is not working? Go back to Advice, Step 1, because if you can't understand how to do it yourself, you're betting on some oracular knowledge from the LLM. Let me drop a super arcane hint: no one doing serious engineering work is asking their harness to do something that they couldn't do themselves, or anything they couldn't understand if they had the time. Try it. You'll get lost in the sauce pretty quick. It's doable but it does not scale to projects with feature velocity. This is why junior engineers on CC are not replacing seniors -- it isn't a matter of taste, it's a matter of knowing what you are trying to accomplish and understanding how to check that it works.
Basically, we are at a place where the time-management of your own thoughts, and the time-management of verification, have eclipsed all other inputs to software (not token cost). I would argue that this is not new, and this was actually always the case-- if you really think about the causes of SDLC failure in the past, they essentially boil down to the same things. Anyone who has ever tried to scale architecture to meet evolving client needs, or tried to scale the quality of a QA organization, or has tried to write tests for a system that was created without them-- these were problems of organization, process, and time-allocation.
If you feel differently, hit me up, I guess, and if you live in the Minneapolis or San Francisco area I'll buy you a beer and talk it out. But in terms of the online discourse, I'm not really interested in the debate, because the above is essentially a sort of "lived experience" one finds hard to disbelieve.
Proof
So if you don't believe me that this is the way that software is being made, take a look at my github repo. It's what I used to generate this entire website (no, not this post, I'm still writing my English by hand) in a single pass of Claude Code, an alltogether unremarkable feat in 2026. You can look at the core loop and the entrypoint/initial prompt.
I wrote this post, executed the prompt in README.md and went for a walk. Claude Code built and deployed what you're looking at. I didn't check how long it took; less than an hour.