Agentic Coding Is a Trap

Interestingly I’ve learned more about languages and systems and tools I use in the last few years working with agentic coding than I did in 35 years of artisanal programming. I am still vastly superior at making decisions about systems and techniques and approaches than the agentic tools, but they are like a really really well read intern who knows a great deal of detail about errata but have very little experience. They enthusiastically make mistakes but take feedback - at least up front - even if they often forget because they don’t totally understand and haven’t internalized it.

The claim you should know everything about everything you work on is an intensely naive one. If you’ve worked on a team of more than one there’s a lot of stuff you don’t totally grok. If you work in an old code base there’s almost every bit of it that’s unfamiliar. If you work in a massive monorepo built over decades, you’re lucky if you even understand the parts everyone considers you an expert in it.

I often get the impression folks making these claims are either very junior themselves or work basically alone or on some project for 20 years. No one who works in a team or larger org can claim they know everything in their code base. No one doing agentic programming can either. But I can at least ask the agent a question and it will be able to answer it. And after reading other people’s code for most of my adult life, I absolutely can read the LLMs. The fact a machine wrote crappy code vs a human bothers me not in the least, and at least the machine will take my feedback and act on it.

As a senior developer, 25+ years, I have been thrown recently into a meeting "hey can you join in for 5 mins". I really don't like these meetings where you're dragged in in the middle of them without any clue.

The questions came flying in fast, without any introduction, and this was about an external integration out of a dozen. They have their own lingo, different from ours, to make the situation worse.

I had a _very hard time_ making sense of the questions, as I indeed relied heavily on a model to produce these integrations (extremely boring job + external thick specs provided).

I'm still positive these would have simply not happened in a 10x the time if I did not use models, however, I'm now carefuly considering re-documenting the "ohhs" and "aahs" of these so that these kind of uncomfortable moments never happen again.

I haven't felt so clueless and embarassed in a meeting, ever. All I could say was "I'll get back to you on that one, and that one, and this one".

Cognitive debt is very real, and it hurts worse than technical debt on a personal level! Tech debt is shared across the team, cognitive debt is personal, and when you're the guy that built the thing, you should know better!

To be continued... But from now on, the work isn't done if I don't get a little 5 mins flash-card type markdown list of "what is this" and "what is that", type glossary.

> only a skilled developer who's thinking critically, and comfortable operating at the architectural level, can spot issues in the thousands of lines of generated code, before they become a problem.

An additional factor: to find issues in generated code, the developer has to care. Many developers (especially at big firms) are already profoundly checked out from their work and are just looking for a way to close their tickets and pass the buck with the minimum possible effort. Those developers - even the capable ones - aren't going to put in the effort to understand their generated code well enough to find issues that the agents missed. Especially during the current AI-driven speed mania.

I kind of think this article misses the mark a little.

There is skill loss from heavy AI use.

But I want to acknowledge the awkward elephant in the room. AI Is making people too fast. I don't mean that a faster output is bad. It's a faster output and code rather than a full understanding and experience in producing the code. It's rewarding people who try to talk about business value rather than the people that are building and making safe decisions with deep knowledge.

AI: Yes, its good and it can produce some good solutions, however it ultimately doesn't know what it's doing and at the best of cases needs strong orchestrators.

We're in a cesspit of business driven development and they're not getting the right harsh and repulational punishments for bad decisions.

Using AI to go faster is optimizing the wrong thing. At every place I've worked, the "code writing" part takes the least amount of time, compared to all the other things you need to do in order to implement a feature. Let's examine a feature that takes a day to code:

First, you've got to plan everything, using whatever Agile or Waterfall planning ritual your company uses, get the task breakdown, file the JIRA tickets, decide who's doing the work. That all can take days or even weeks. Then you need to write a design doc with your proposed design, and get that reviewed by your peers/teammates. Again, another week for any substantial feature. If there are multiple teams involved, you need to get buy-in and design agreement among those multiple teams, let's add another week. At some places, you need approval to commence work, which can take multiple days, depending on the approver's schedule and availability.

Then, you take a day and write the code and make sure it passes tests.

Then, it's code review time, and this can involve a lot of back and forth with your team, resulting in multiple iterations and additional code reviews. Another "days or weeks" stretch. At bigger companies, you're going to need to pass all sorts of reviews from other departments, like legal, privacy, performance, accessibility, QA... even if done in parallel, let's add a conservative 2 weeks. Finally, you push to staging, and need to get some soak time internally among dogfooders, so you have some confidence that it's working. +1 week. Then you're ready to push from staging to prod, but since you work at a serious company, nothing goes to 100% prod right away--you need to slowly ramp up and check feedback/metrics in case you need to roll back. The ramp to fully launched could take another two weeks.

So here's a feature that took, what, maybe two months from design to release, and we're falling all over ourselves to optimize the part that took a day so that it takes 5 minutes instead...

The thing is the code quality is still ultimately up to you

Nothing stopping you from iterating with the agent till the code is the exact same quality that you yourself would write

I've been using AI tools to brainstorm approaches and sometimes generate code, but actually doing the typing myself. That way I'm less likely to forget the mechanics and programming language over time.

I've come to the conclusion that if AI can do it, its not hard. None of the complicated software i work on can be reliably written by ai yet

> When a sysadmin moved to AWS, they didn't feel like they were losing their ability to understand networking.

Wait, is this the same AWS I have been using?

Would like to see a study of brain scans during flow, manual programming, compared to code review. If the conclusion is different parts of the brain are activated, then orchestration is a separate activity entirely. Reading code is not the same as writing code.

However, the code review study needs to compare between surface scanning and reviewing long enough to get over a theoretical slough of perspective: when you assume the coding chair and are in their frame, whether the brain shifts into a different cognitive mode.

Otherwise, just stamping "Looks good to me" is likely to lead to the same atrophy. There's no critical thought, even a self-summary of the change or active questioning.

Thoughtful, deliberate code review just plain takes longer. AI can help here a lot, although it still takes over the "get into review mode" process.

The slot machine lever is my least favourite opinion on the subject.

Also, let’s not forget. The developer is rarely the person pitching the feature, and is normally given the constraints and the PRD…

Soooo people can keep tiptapping on the keyboard, but eventually they need to open their mind to the possibility that “the old way” is actually dead.

Slightly off-topic.

The funny thing is that he mentions that Spec Driven Development is the future.

Technically we allready did this when we where doing Waterfall. I kind of miss it that we had good documentation. The last decade (maybe more?) I get jira tickets with a one liner. I often need to call people as they specify almost nothing.

I am still avoiding working with AI. I try to use some models locally for experiments. I refuse to pay for something that was build on ripping others off. And the local models are underwhelming thus so far.

it's a fairly new way of doing things. I predict, in the future it will be more formalized and standardized like AGILE and SCRUM and all that boring stuff.

The result of that though would be establishment of development patterns that are good practices.

The rule of thumb is: An agent can write it, but a human has to understand it before it gets pushed to prod.

I'm still not convinced about the doom and gloom over developers being replaced. I'm not a dev as part of my main job function, but where I do use LLMs, it has been to do things I couldn't have done before because I just didn't have time, and had to de-prioritize. You can ship more and better features. I think LLMs being tools and all, there is too much focus on how the tool should be used without considering desired and actualized results.

If you just want an app shipped with little hassle and that's it, just let Claude do most of the work and get it over with. If you have other requirements, well that's where the best practices and standards would come in the future (I hope), but for now we're all just reading random blog posts and see how others are faring and experimenting.

the funny thing is once the llms got mostly good enough in november 2025 for me, it was mind boggling how much it helped me get stuff out of my head with ease.

its easier for me to code now, because its like i have a 24/7 insane intern that needs to be supervised via pair programming but also understands most topics enough to be useful/ dangerous.

ironically ive been spending much of my time iterating on ways to improve model reasoning and reliability and aside from the challenge of benchmark design, ive had some pretty good success!!

my fork of omp: https://github.com/cartazio/oh-punkin-pi has a bunch of my ideas layered on top. ultimately its just a bridge till i’ve finished the build of the proper 2nd gen harness with some other really cool stuff folded in. not sure if theres a bizop in a hosted version of what ive got planned, but the changes ive done in my forks have made enough difference that i can see the different in per model reasoning

It's funny because it's either

- tech for management who can delegate but don't have the expertise to know when it's wrong or just plainly impossible

- tech for coders who have the expertise... but who will gradually lose it.

So I'm not sure who it is for, beside VCs and shareholders until the next quarter obviously.

I agree with most points in the article but I disagree with the idea of coding as planning. Coding is a really bad way to plan; it maximizes sunk cost fallacy. People tend to code the first approach which came to their heads and they are resistant to revisit an approach once it has been transformed into code. Sometimes ideas which work well in the short term don't work well in the long term.

When you start coding as a way to scope out a problem, you're biasing yourself to think of everything in terms of abstractions which you invented for problems which you don't yet fully understand. My experience is that this distorts your own thinking; you are injecting your own biases into your learning process and locking down on decisions too early due to suck-cost bias.

Having a solution all coded-up and working after a couple of days creates the illusion that you've built something solid and maintainable and that any additional functionality needs to be added on top. Before you know it, the prototype has become the foundation.

It's like if I took you to some random country and told you to build a house and you started chopping wood and putting up the walls straight away. You might immediately have noticed that it's hot so you would put lots of windows... Good... But what you don't know yet is that this country gets hit by powerful cyclones once a year on average and your wooden house won't survive the first one. You started with the wrong material. It might work really well for the first few months until a point when it won't work at all and you'll have to rebuild the entire thing from scratch.

I think of it as driver's seat vs back seat vs passenger seat. You always take the back seat and eventually you will forget how to drive. You insist on always being in the front seat and you will miss out on the occasions where the LLM happens to know the area very well, like working with an unfamiliar library or problem domain. If it is a place that you are just passing through, it's a great to let it take the wheel and see where it will takes you. If it is a place that you need to become familiar with, it's great to have a dependable navigator beside you.

My sense is that a decade from now, the people who generally see their place as the driver seat but recognize when its not are going to be writing the code that matters.

There’s too much in this article to comment on it all, but if we zoom into the first claim:

> An increase in the complexity of the surrounding systems to mitigate the increased ambiguity of AI's non-determinism.

My question is why isn’t there an effort from the author to mitigate the insane things that LLMs do? For example, I set up a hexagonal design pattern for our backend. Claude Code printed out directionally ok but actually nonsensical code when I asked it to riff off the canonical example.

Then, I built linters specific to the conventions I want. For example, all hexagonal features share the same directory structure, and the port.py file has a Protocol class suffixed with “Port”.

That was better but there was a bunch of wheel spinning so then I built a scaffolder as part of the linter to print out templated code depending on what I want to do.

Then I was worried it was hallucinating the data, so I wrote a fixture generator that reads from our db and creates accurate fixtures for our adapters.

Since good code has never been “explained for itself 100%, without comments”, I employ BDD so the LLM can print out in a human readable way what the expected logical flow is. And for example, any disable of a custom rule I wrote requires and explanation of why as a comment.

Meanwhile, I’m collecting feedback from the agents along the way where they get tripped up, and what can improve in the architecture so we can promote more trust to the output. Like, I only have a fixture printer because it called out that real data (redacted yes) would be a better truth than any mocks I made.

Finally, code review is now less focused on the boilerplate and much more control flow in the use_case.

The stakes to have shitty code in these in-house tools is almost zero since new rules and rule version bumps are enforced w a ratchet pattern. Let the world fail on first pass.

Anyway, it seems to me like with investment you can slap rails on your code and stay sharp along the way. I have a strong vision for what works, am able to prove it deterministically with my homespun linters, and am being challenged by the LLMs daily with new ideas to bolt on.

So I don’t know, seems like the issue comes down to choosing to mistrust instead of slap on rails.

Edit: I wanted to ask if anyone is taking this approach or something similar, or have thought about things like writing linters for popular packages that would encourage a canonical implementation (I have seen some crazy crazy modeling with ORMs just from folks not reading the docs). HMU would love to chat youngii.jc@gmail

There's a subset of software engineers who understand most of the points from the article, but it looks more and more like this train can accelerate towards the cliff due to steam from burned money.

“The market can stay irrational longer than you can stay solvent” quote is usually applied to markets, but it can be applied to software engineering as well - all jobs can be gone even if world will be submerged into technological crisis, with single nine availability (and I'm talking about 9% :) ) and all accounts compromised.

I can’t say that I’ve felt my skills atrophy, but I’ve also never found backend web development to be that difficult. 90% of my job for my entire career could be described as digital plumber.

An aspect i don't hear about enough is using agents to make better abstractions instead of treating the agent as the abstraction. We could work on making abstractions that allow expressing what we are building in most concise form without any boilerplate. The reviews are enjoyable, if llm providers fail we have a chance to use the great abstractions by hand. The alternative i see everywhere: We don’t care about the bad abstractions because agents write the code. We don't review because its too much and too noisy and we rather blow our brains out than manually dig through that react and spaghetti codebase and writing all the boilerplate and cross references by hand. We have to build for resilience and future us.

AI doesn't automatically make us better human beings, but they only expose our worst parts. Most people are not born great leaders and managers (need rigorous training and experience), and empowering them with AI kind of pushes them into a spot where they suddenly need to "lead". To fight brainrot from AI overuse, we must try harder to maintain that developer's priority list.

Lars we are on the same page. I use LLMs to help me scope and get a second set of eyes on the high levels of a task. Then I write the code. Often I automate boilerplate or boring objects but sometimes it's faster/better for me to just write them. Then I will ask an LLM to say write some tests. Then I will focus on the cases they missed and write those myself.

I have been described as a decel and a Luddite though so be weary of my opinions.

I don't use AI for everything, but I use AI to make repeatable, auditable workflows. For DevOps, I don't just ask AI to go on my production server and fix all issues. I ask it to write scripts, which I audit, then I dry run, then I test, and finally approve and run on production.

I was just looking through HN search for "show HN", and I saw many fitness and calorie tracking apps.

A lot of them disappeared just after a few months of launch; a few of them survived a year, then died out as their domain name expired.

People are making things, but they are not reaching their "audience".

I created https://macrocodex.app/, launched on 16 Mar 2026, and reached 10,000+ monthly active users.

Fitness/Calorie tracking is a competitive space where there are tons of apps and services.

I could never have built such an app because I do not know how to design pages; I can talk to a designer, but from past experience, it takes them a long time to understand what the market wants and projects. And companies with small budgets find it very difficult to find a good guy.

Many of my projects never got shipped because I dreaded making landing pages, icons, UI, etc.

I am not saying we did a very good job with AI on landing pages or UI at all; that's not an area of my expertise; the domain knowledge is, but the fact that many people find it useful, I think I’ve succeeded.

I've even put a ticket system in the app for support and received a few bug reports, which I resolved.

Here's the latency of my other service: https://prnt.sc/6474F4gba_he

I no longer use managed services in AWS, and my costs are very low; this enables me to offer my apps and services for free to many users.

> Buried in a recent study[1] by Anthropic was a surprisingly honest moment when speaking about the risks of engaging with coding agents on a regular basis...

Does the person who wrote that still work there?

[1] https://www.anthropic.com/research/how-ai-is-transforming-wo...

I wrote something that touches on a few of the same points not too long ago (namely vendor lock-in and inability to project cost with LLMs at the wheel). Tangential topics but I think there's a healthy enough amount of intersection to at least join in on the discussion.

I do agree that if we just rely on AI for all outputs and some reviews (at least to a threshold, because we simply can't keep up with the AI throughput as humans) we will eventually have skills atrophy. Here's where the tangents intersect: I've been working on a way to have the best of both worlds. We can still use AI to generate a large swathe of code, but use good old software engineering to do it. My project (https://salesforce-misc.github.io/switchplane/) inverts the control. Rather than having LLM-as-runtime and doing all the things, you define and write LangGraph control flows that only use the LLM when judgement is actually required. The basic principle is:

If it's deterministic, write it in code. If it requires judgement, use the LLM.

Switchplane itself is local-only but the principles can be applied to deployed agentic services as well. Because the approach is code-first, we can have that vendor independence: Use whatever model you want anywhere in the graph. One goes down? No problem. Swap the config without impacting the overarching control flow.

Cost becoming a factor? Limit LLM loops or constrain their access however you want. It's just code that needs to be updated. You control the runtime, not the LLM.

Concerned about non-deterministic behaviour when you need determinism? Don't be. It's in code.

Worried about skills atrophying because we're handing off everything to an LLM? That's mitigated somewhat here because you still need to think in systems in order to build execution graphs in the first place.

It might not demo as well as a number of markdown files being executed by an LLM. It's definitely a more reliable approach in the long run though.

Re vendor lock in point: this is a harness issue really. Sure, CC is restricted to Anthropic models, but it's not the only harness out there. So if one vendor has an outage or botches the quality of their models due to compute shortage, you can switch to another vendor. LLMs are the easiest to switch. Of course, if hardware costs go up, so will all AI vendors. The only way out for the employer would be to directly buy the hardware (or do a fixed price deal with a cloud provider).

Re the understanding code point: you can still use LLMs to understand code. If you write the spec without knowing anything about the code, of course the architecture might suck. Maybe there is already a subsystem that you can modify and extend instead of adding a completely new one for the new feature you are adding, etc.

I use LLMs for my daily workflows and they do understand code perfectly and much more quickly than if I read it.

This author assumes that workforce development is a first-order priority for businesses, or at least for the health of the industry.

Why make this assumption so confidently?

The arrival of the electronic computer did not turn human computers into programmers, it simply eliminated them en masse.

>and then pulls the slot machine lever over and over

Does anyone really do this? You want verification and self-correction in a loop, not rerolling and cherrypicking. The non-determinism point is really tiresome to hear over and over.

I've been having the same feeling too. At work, I try to do a hybrid prompt where I fill in things at method level with some placeholder pseudocode and let the prompt fill in the blanks. This helps with remembering and keeping a memory map. But its a lost cause keeping up with other's PRs that are often very verbose and high volume. For a lot of backend programming without a very complex domain, I think this works fine.

But I still want to be in touch with coding by hand and have ventured into systems programming, outside of work, which I feel AI is less useful for currently.

The trap isn't agentic coding, it's using it as fancy autocomplete. When you delegate whole tasks with real acceptance criteria, not just single functions, the economics change completely.

This is how I feel about things. Its like someone is demanding that I become a manager, when I was perfectly happy being a IC. And now I have to figure out how to be a manager of AI agents while at the same time not lose my ability to judge their work, or plan effectively, even though I'm not supposed to be doing things "by hand" anymore. But doing things "by hand" is how I reasoned through problems and figured out the plan to begin with.

I try to make understanding the bottleneck and it seems to work out for me while still delivering solid productivity gains.

"Don't vibe code" but here's a deadline that's impossible without it. classic

Nope. 1) Skills don't go away, you just get better at the things you do regularly, but your still have your old skills, 2) You only have vendor lock-in if you use lock-in devices (stop using Claude Code), 3) It's not an increase in complexity, it's a replacement, in order to gain efficiency (see: the cotton gin), 4) The increased cost is negligible considering average salary and resulting productivity

I sometimes wonder if I'm in a different universe to other devs. Anytime AI coding is brought up, comments are overwhelmingly negative and often point out correctness, quality, slop, etc.

There's also the 'more stuff is being delivered, but it's not right, full of holes and papercuts'.

I'm 22 years into development and couldn't think of going back to non AI programming now. Not only has it sped up velocity by an order of magnitude, it's also helped me unlock side projects that I would never even begin in the past as I knew I didn't have that time.

It's just like any tool though, and I've found enormous differences in outcome depending on how you drive it. Launching into 'build this' and expecting it to output code that you would manually write would not get you there; and I feel this is where most developers stall out.

Getting the right outcomes takes a lot of harness set up - the same as if you wanted to hire new devs and get them productive without peering with them. You would set up linting, good test coverage and approaches, thorough documentation about what your project is, the domain, the architecture etc. This at least gets good code consistency for the most part.

For how to build, https://github.com/bmad-code-org/BMAD-METHOD is really good and I've onboarded a few Saas projects into it now. Tech speccing and multiple cycles of elicitation are what deal with all the edge cases that you normally only encounter during coding. It does front-load all of the planning brainwork; but condensing that into a couple days of solid speccing is far more productive than spreading it out over months.

It's taken a while to get to this point, and most agents aren't good for substantial work out of the box. Most of the time what the agent does will be a product of its environment.

AI is just another tool and a new layer of abstraction. Do you really think the majority of people who write in high level languages truly understand what's going on under the hood? Do they really? Or is there at some point a divide between what needs to be done, how the application or logic should perform, and the actual translation of all that into machine code?

These blogposts (no doubt written with the help of AI) have been the topic of many a comment here and elsewhere across the internet for years now. The atrophying of skills is a serious concern and has been voiced again and again since 2022 by everyone skeptical of AI and I just think some people and some places just don't care.

At some point, if you're just pulling the lever on the slop machine with zero insights into your code, may be your boss is justified in asking why you should earn more than 50k a year.

This is exactly the same problem of "mechanical engineers' job is to design parts, not machine them, so we'll take training on machines out of the mech eng curriculum." Result: fresh mech eng grads do not know how to properly design parts because they have no idea how they are machined.

Only way to cope with this I found is to grind leetcode or advent of code. It's kinda funny how fast this all changed. Less funny part is the fact that I'm now kinda feared for my job in some time.

Agentic coding without a harness is a trap.

Software engineering without a proper SDLC is a trap.

Driving without a seatbelt is a trap.

How can we solve this at a more fundamental level?

I think many people already recognize the problem:

-“Our ability to write code is being damaged.” -“If our ability to write code declines, our ability to recognize good code also declines.”

But the problem is that the market no longer works without LLMs.

Freelance rates and deadlines are now calibrated around LLM-assisted output. Even clients who write “do not vibe code” often set deadlines that are impossible to meet unless you use something like vibe coding. The client’s expectations themselves are becoming abnormal.

That is the irony of the market.

I honestly do not know what to do.

Recent Hacker News discussions are mostly a negative echo chamber about AI use. In other places, it is often the opposite: only positive echo. But almost nobody discusses the actual solution.

The main topics I keep seeing are roughly these:

1. Is the large repository PR system failing a fundamental stress test? Or should AI-generated(GEN AI) code simply not be merged? If PR review is moving from handmade production to mass production, how should the PR system change? Or should it remain the same?

2. As vendor lock-in continues, can we move toward local LLMs to escape it? Are cost and harness design manageable? What level of local model is required to reach a similar coding speed?

3. If we are forced to use agentic coding, how do we avoid damaging our own ability to code? There is a passage from Christopher Alexander that I keep thinking about:

“A whole academic field has grown up around the idea of ‘design methods’—and I have been hailed as one of the leading exponents of these so-called design methods. I am very sorry that this has happened, and want to state, publicly, that I reject the whole idea of design methods as a subject of study, since I think it is absurd to separate the study of designing from the practice of design. In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things.” — Christopher Alexander, 1971

This quote feels relevant to programming now. If we separate the study and supervision fo programming from the actual practice of making, something important may be lost.

In architecture, there is this idea that without practice, the architect loses meaning. But now the market is forcing the separation.

People with enough symbolic capital and high status have the freedom not to use AI. But people lower in the market are under pressure to use it.

So I think the discussion now needs to move beyond whether AI coding is good or bad.

The real question is How do we keep using AI because the market demands it, while still preserving the human practice that makes programming meaningful and keeps our judgment alive?

I think these are the important question. How do you maintain market value without using AI?

Or, if you do use AI, how do you avoid being treated as low-quality?

If you do not use AI, how can you remain more competitive than people who do use it?

If you do use AI, what advanatge do you have over people who do not use it, and how should you position yourself?

I know that agentic coding can cause skill degradation. I can feel it happening to me already. But for someone like me, who does not have strong status, credentials, or symbolic capital, social and market pressure makes AI almost unavoidable.

What frustrates me is that I do not see practical answers anywhere.

Frankly I don't buy atrophy argument at all. I (and I believe many other people) switched multiple frameworks and languages over the years. I.e., I was an expert in Chef more than 10 years ago, and nowadays I hardly remember anything about it. Calling this a cognitive decline is a significant stretch.

If you're afraid of cognitive decline - try to get to proper orchestration using multiple agents. That's a fun exercise.

agentic coding destroying the current tech industry would be bad for a few billionaires & their serfs but it would be very good for humanity, don’t fear the reaper

He's speaking facts. I have had the same concern about excessive cognitive offloading. As others have noted in the comments, AI tools when used correctly, can actually make us smarter and help us learn faster. But that requires a very particular usage pattern that is different from what I see with all the vibe coding going on these days.

I created a project called Ninchi to force myself to read my code and understand it. Recently I began also sharing it to see if there may be a larger need/opportunity. It's a small effort. We need to make a variety of efforts I think to encourage responsible AI usage before we end up drowning in slop.

Writing code is not the hard part of software development. This is coming from someone who has programmed for 30 years, writing an average of 100k+ lines a year.

The sooner programmers start thinking about modeling the domain, user mental models, architecture and data structures and less focus on the mechanics of writing code, the better.

Writing code is the EASY part. LLMs have basically solved the easiest part of software development. They however are bad at all the stuff I mentioned. LLMs don't have a point of view, you do as a software developer.

I have been finding a good rhythm for greenfield projects.

When I first learned to code, I would do complete rewrites of a project several times. Each time I learned a lot, and the final result would be very stable and very well designed.

At the time, those seemed like large projects, but they were relatively small.

So I have learned to slow down, and spend considerable time thinking or overthinking before coding. Since for large projects, rewrites are not so efficient.

Except that all those rewrites were upfront thinking and overthinking of the highest quality.

I have recently attacked a couple new greenfield projects in "orchestrator" mode. The fact that I know I am exploring and creating throw away code lets me try things out ambitiously. I can obsess about the original and critical code, as I did before. But now I can quickly surround it with the mundane code it needs to be usable - which can happen very very fast - especially when its a throw away experiment.

My conclusion from these successes, and others, is agentic coding isn't something that can be judged without factoring in all kinds of context, and the ability of the "orchestrator" to come up with orchestration patterns well suited to the work.

If agentic coding is a trap, it is a trap created with the cooperation of the orchestrator.

EDIT: An agent is what you make it. I insist mine keep all memories in an in-project folder. And that documentation is for "both of us", whereas their folder is for actively developing their own understanding and ideas. They are not be agreeable or contrarian, but collaborate and contribute by considering anything and everything all the time, at their highest level of operation. At the beginning of every session, they review everything and from their "fresh" perspective, update their own materials for anything that strikes them or they believe is important. And that they do the same thing at the end of every session before last submit. Project appropriate "harnesses" like this make a massive difference. Never operate an agent in plain helpful-servant mode, it is a serious waste of talent. Push them to operate at a high level, all the time, and develop their own material purely for their own project related self-enhancement, and they contribute far more than speed coding.

Another interesting thing that seems to be helpful. I have the agent write a kind of zen document about what it values. Its first task, before any project related review, is to consider its own words, and update them if they con't feel right, or they want to add something important. To remind themselves of who they are, before engaging with the project. This moment of intentional self-reflection before diving straight into project details seems to help them maintain a birds eye view, and a stronger self-aware/self-motivated commitment to quality (defined completely in their own terms!). Their own words do appear to ring true to them. They reliably respond to this session-start ritual as an intriguing surprise.

Try this thought experiment. If, in 6 months, the agents were better coders than you are, would this argument still hold?

This is a personal thought experiment so think it through for yourself. What would the consequence be if the agents really were better than you and you acknowledged that?

The major premise of "It's a trap!" is that it matters if you lose your coding skill. (I'll gloss over general critical thinking and stick with coding for now) However in the world where on any given task it would be done to a higher level of quality and faster if you gave it to the agent, then what are you doing trying to do it yourself? There's plenty of room for that kind of thinking in hobbies, but in the professional world?

Maybe you can add some value in code reviews, but you may also be better off never reading the code at all. Maybe the how of coding stops mattering and the what of products needs to be your top concern.

I can tell you that the agents that I use today are much better coders than I am in the language we're using. I don't write it at all. I couldn't fizzbuzz in it. But with a small team we are building useful internal tools and features at a breakneck pace. I certainly feel the same feelings of getting dumber and losing my coding chops, but I have to step back and say, could what we've built have been built in 5x the time without agents? And the answer is probably no.

The thing I'm mastering now is conjuring software with agents. What lets them rip, what slows them down, where they are today and where they will likely be tomorrow.

I can tell you that you should re-invest in small, modular systems, because agents can build modules and greenfield projects instantly. I can tell you that there is a point at which agents fall over completely even on mid-sized projects, but that that point is receding with each new generation of model, and that Codex 5.4 XHigh Fast set to 500K context window is a beast. (5.5 has yet to win me over)

I can tell you that pushing direct to main is viable, that PRs slow down fully agentic teams, and if your agents have sufficient permissions they can fix things fast enough to be let loose even knowing they may delete your service. I wouldn't do it with your main product yet (unless you're starting your startup today) and I wouldn't try it with a large legacy project. But maybe that rewrite you've always wanted to do is here and just a prompt away.

Now, the sane among you will note that agents are not better today, that they might not ever be, and either way you should never trust a computer to make a decision because it can't suffer the consequences of its actions. Or more down to earth, there are some things that are too important to yolo.

But I will argue that a huge swath of us work in domains where if you're willing to challenge some of the basic assumptions of software development (you should understand the code, it should be maintainable by humans, it should be built to last) then you'll be able to provide very useful software much more quickly than you would otherwise be able to do. Save the skill for your hobbies, and build things people want.

20+ years in. For me, agentic coding has been nothing short of a godsend -- not because it writes code for me, but because it lets me explore and prototype things that would have taken days of reading docs and ramping up. The creative surface area of what I can touch in a week has expanded dramatically.

Where I worry is beginners. The hard-won intuition for "this is a reasonable approach" vs. "this will bite you in six months" takes years to develop. With experience, you steer the agent. Without it, the agent steers you -- and it steers confidently in every direction, good and bad alike.