For instance, the ones that look at it from an economics perspective, security perspective, long term maintainability perspective and so on. For each of these there are pros and cons.
The more experience I get the harder the job seems tbh
I'm a 23+ year dev; among the highest level ICs in my org.
It's still craft, its just that the craft is different. I don't write *.ts, *.cs files anymore; I write *.md files that other devs are using, that we're using as guardrails, that ensures that we minimize the slop while increasing speed and basically lift every developers level up by several notches.
I went from building one kind of framework/platform level artifact to another type of framework/platform level artifact.
If one's perspective is that it's just a shift in what "craft" means, then it's still craft. I'm still building systems; just a different kind of system.
But there is a price to pay: the code that you generate is not the code that you understand and when things go pear shaped you will find that that deterministic element that made compilers so successful is missing from code generated from specs dumped into an AI. If you one-shot it you will find that the next time you do this your code may come out quite different if it isn't a model that you maintain. It may contain new bugs or revive old ones. It may eliminate chunks of the code and you'll never know and so on.
There is a reason that generated code always had a bit of a smell to it and AI generated code is no different. How much time do you spend on verifying that it actually does what's written on the tin?
Do you write your own tests? Do you let the AI write the tests and the code? Are you familiar with the degree to which AIs can be manipulated to do stuff that you thought they weren't supposed to? (A friend of mine just proved this to his boss by bribing an AI with a 'nice batch of pure random data' to put a piece of unreviewed code into production by giving itself the privileges required to do so...)
Quality and consistency are going up, not down. Partially because the agents follow the guidance much more closely than humans do and there is far less variance. Shortcuts that a human would make ("I'll just write a one-off here"), the agent does not...so long as our rules guide it properly ("Let me find existing patterns in the codebase.").
Part of it is the investment in docs we've made. Part of it is that we were already meticulous about commenting code. It turns out that when the agents stumble on this code randomly, it can read the comments (we can tell because it also updates them in PRs when it makes changes).
We are also delivering the bulk of our team level capabilities via remote MCP over HTTP so we have centralized telemetry via OTEL on tool activation, docs being read by the agents, phantom docs the agent tries to find (we then go and fill in those docs).
There are some studies about maintaining attention over longer periods of time when there is no action required. It will be difficult to keep that up forever so beware of review fatigue and bake in some measures to ensure that attention does not diminish over time.
Over enough time, this gap closes and the need for reviews goes down. This is what I've noticed as we've continued to improve the docs: PRs have stabilized. Mid-level devs that just months ago were producing highly variant levels of quality are now coalescing on a much higher, much more consistent level of output.
There were a lot of pieces that went into this. We created a local code review skill that encodes the exact heuristics the senior reviewers would use and we ask the agent to run this in AGENTS.md. We have an MCP server over HTTP that we use to deliver the docs so we can monitor centralized telemetry.
The objective is that at some point, there will be enough docs and improved models that the need for human reviews decreases while quality of code reaches a steady state that is more consistent than any human team of varying skill level could produce.
One thing we've done is to decouple the docs from the codebase to make it easier to update the docs and immediately distribute updates orthogonal to the lifecycle of a PR.
(I'll have a post at some point that goes into some of what we are doing and the methodology.)
Ouch. Managing human coders has been described as herding cats (with some justice). Getting humans to follow standards is... challenging. And exhausting.
Getting AIs to do so... if you get the rules right, and if the tool doesn't ignore the rules, then you should be good. And if you're not, you still have human reviews. And the AI doesn't get offended if you reject the PR because it didn't follow the rules.
This is actually one of the best arguments for AIs that I have seen.
In some cases, it was "instant"; dev's MCP server connected to our docs was down -> terrible PR. We fix the MCP connection and redo the PR -> instantly follows the guides we have in place for best practices.
Okay that's pretty hilarious. Everyone has a vice!
Maybe that's another way of saying: I was trained as a designer, and now the distinction between design (read: architecture, service-design, product, ux, cx) and programming is blurring.
All I'm seeing around me is people dropping best practices in a FOMO driven push for speed: let's stop reviews, let's drive 5 agents in parallel, let's not even look at the code!
This is going to blow up.
Only after we pick up the remains we'll find a more sustainable approach for AI usage. I suspect that version will still require crafters.
If we end up in a place where the craft truly is dead, then congratulations, your value probably just dropped to zero. Everyone who's been around startup culture knows the running jokes about those 'I have a great idea, I just need someone to code it' guys. Now you're one, and you'll find how much ideas are worth.
Nah, we are way past wringing our hands over agentic engineering. Every startup and all fast moving companies are onboard. They don't hand code anymore. There will not be some code quality crisis that will stop everyone in their tracks. I'm trying to cope with this too, but I don't think the best path is praying for failure. Embrace it, move on.
Provide some examples then? Everyone who is all in on agentic code are pretty vocal about it. Who is declaring the opposite stance? Anyone?
You can’t just pretend it’s startups doing all the agentic engineering. They’re just the ones pushing the boundaries on best practices the most aggressively.
This is a good call out, but I'm talking to a lot of friends at other companies. So my perspective is informed by both news and personal anecdote.
Both big tech and startups are now full of people working at 10x, features are written as fast as PMs can think them, monoliths self heal with agents buzzing over them.
10x means 10 times the outcomes in a given amount of time, so did you see the last iOS version pack a decade worth of features in a single release?
Do you remember when meta moved their backend to rust in a month?
What about Microsoft software not having a single bug in a year?
Yeah, me neither.
The thing about AI is that you don't have to use it for everything. Like any other tool you can use it as much as you'd like. Even though I like the craft, I find myself really enjoying the use of AI to do things like boilerplate code and simple tests. I hate crafting verbose grunt work, so I have AI do that. This in turn leaves me more time to do the interesting work.
I also enjoy using AI to audit, look for bugs, brainstorm, and iterate on ideas. When an idea is solid and fleshed out I'll craft the hard and interesting parts and AI-generate the boring parts.
Yes, sometimes I can also ask AI to evaluate things at the system level and it often has surprisingly good insights, but that is usually a collaboration where our powers combined comes up with a better solution. I enjoy that process, too.
I do sympathize with the people "in mourning". I feel like this is really about how your identify is tied up in what you do. I have generally identified as a command line wizard. The xkcd of the guy flying in with "perl" very much speaks to me. But AI absolutely crushes at this. It's not that useful a skill anymore. Now I identify more as a local AI expert instead :D
Twelve years ago I would have the bright idea of why not make a little, just a tiny little (what I would call now) preprocessor for Java which does the same thing in less characters and is clearer. Everyone would love it. Of course no one loved it. Well, I never implemented it. Because I got some sense: you can’t just make tiny little preprocessors, a little code generation here and there, just code-generate this and tweak after the fact. Right? It’s not principled.
You can cook up a dichotomy. Good for you. I think the approach is just space age technology meets Stone Age mindset. It’s Flintstone Engineering. It’s barely even serious.
I am not offended that you took my craft. I am offended that you smear paint on the wall with three hundred parallel walls and painters and pick the best one. Or whatever Rube Setup is the thing that will take over the world as of thirty minutes ago.
Make something rock solid like formal verification with LLM assist (or LLM with formal verification assist?). Something that a “human” can understand (at this point maybe only the CEO is left). Something that is understandable, deterministic.
I might be out of a job. But I will not be offended. And I will respect it.
Hell no. I, a craftsman, was going out of my way to use things like Haskell. I was very aware of the divide the entire time. The present is a relief.
Engineers be loving the craft.
It's a dance, but AI is unfortunately looking at us like we're dancing, and meanwhile it's built a factory.
Personally, I have noticed that I still produce substantially more and better code than the people at my company spending all day writing prompts, so I'm not too worried yet, but it seems plausible at some point that a machine that stole every piece of software ever written will be able to reliably turn a few hundred watt-hours of of electricity into a hallucination-free PR.
simonw•47m ago
> Before AI, both camps were doing the same thing every day. Writing code by hand. Using the same editors, the same languages, the same pull request workflows. The craft-lovers and the make-it-go people sat next to each other, shipped the same products, looked indistinguishable. The motivation behind the work was invisible because the process was identical.
Helps explain why some people are delighted to have AI write code for them while others are unhappy that the part they enjoyed so much has been greatly reduced.
Similar note from Kellan (a clear member of the make-it-go group) in https://laughingmeme.org/2026/02/09/code-has-always-been-the... :
> That feeling of loss though can be hard to understand emotionally for people my age who entered tech because we were addicted to feeling of agency it gave us. The web was objectively awful as a technology, and genuinely amazing, and nobody got into it because programming in Perl was somehow aesthetically delightful.
rudedogg•28m ago
We all have different thresholds for what is acceptable, and our roles as engineers typically reflect that preference. I can grind on a single piece of code for hours, iterating over and over until I like the way it works, the parameter names, etc.
Other people do not see the value in that whatsoever, and something that works is good enough. We both are valuable in different ways.
Also, theres the pace of advancement of the models. Many people formed their opinions last year, and the landscape has changed a lot. There’s also some effort requires in honing your skill using them. The “default” output is average quality, but with some coaxing higher quality output is easily attained.
I’m happy people are skeptical though, there are a lot of things that do require deep thought, connecting ideas in new ways, etc., and LLMs aren’t good at that in my experience.
qsort•21m ago
If I reflect for a moment about why I personally got into tech, I can find at least a few different reasons:
- because I like solving problems. It's sad that the specific types of problems I used to do are gone, but it's exciting that there are new ones.
- because I like using my skills to help other people. It's sad that one specific way I could do that is now less effective, but it's exciting that I can use my knowledge in new ways.
- because I like doing something where I can personally make a difference. Again, it cuts both ways.
I'm sure most people would cite similar examples.
magicalist•16m ago
(I'll admit, though, that this also smells to me a bit too much like introvert/extrovert, or INTP/INTJ/etc so maybe I'm being reflexively rejective)
adriand•10m ago
The two emotions I personally feel are fear and excitement. Fear that the machines will soon replace me. Excitement about the things I can build now and the opportunities I’m racing towards. I can’t say it’s the most enjoyable experience. The combo is hellish on sleep. But the excitement balances things out a bit.
Maybe I’d feel a sense of sadness if I didn’t feel such urgency to try and ride this tsunami instead of being totally swept away by it.
sublinear•7m ago
The "make-it-go" people couldn't make anything go back then either. They build ridiculous unmaintainable code with or without AI. Since they are cowboys that don't know what they're doing, they play the blame game and kiss a ton of ass.
The "craft-lovers" got in the way just as much with their endless yak shaving. They now embrace AI because they were just using "craft" as an excuse for why they didn't know what they were doing. They might be slightly more productive now only because they can argue with themselves instead of the rest of the team.
The more experienced and pragmatic people have always been forced to pick up the slack. If they have a say, they will keep scope narrow for the other two groups so they don't cause much damage. Their use of AI is largely limited to google searches like it always was.
hungryhobbit•5m ago
Emacs vs. vi. Command-line editor vs. IDE. IntelliJ vs. VS Code. I could do like twenty more of these: dev teams have always split on technology choices.
But, all of those were rational separations. Emacs and vi, IntelliJ and VS Code ... they're all viable options, so they boil down to subjective preference. By definition, anything subjective will vary between different humans.
What makes AI different to me is the fear. Nobody decided not to use emacs because they were afraid it was going to take their job ... but a huge portion of the anti-AI crowd is motivated by irrational fear, related to that concern.
ehnto•2m ago
I love the exciting ideation phase, I love putting together the puzzle that makes the product work, and I also take pride in the craft.