It's true, I spend less time solving problems that arise naturally from the process of implementation. But implementation errors have a poor signal-to-noise ratio. For every error that exposes a real design problem there are 10 others that involve routine fixes: type errors, scope issues, import resolution, dependencies. There's a common argument I see being thrown around, which is "how will junior engineers develop into senior engineers if they don't get reps in with implementation?" But to me it feels like "programmer" and "architect" are becoming more and more orthogonal as the models improve in capability. If my goal is to be an architect, getting more reps in as an architect is in my best interest, and letting the agents do the dirty work frees up space for me to spend the mental effort where it counts. And anecdotally, the scope of projects I've started taking on has scaled roughly linearly relative to how much work I'm able to delegate, while the mental engagement has stayed constant.

While I empathize with the tone, even before AI the creativity was largely at the feature definition step, not in the implementation.

Outside of the very few computer scientists working on novel algorithms, the vast majority of software development is a mapping problem between the feature request and the mundane technical details, something repeatedly (and correctly) mentioned here in the context of FAANG algorithm fixated interviews. This has now largely been automated by LLMs

What is left is just creativity part - defining the use cases and features to develop in the first place. But the corollary is that software engineers that start after the requirements have already been defined are obsolete, which is a sobering thought for any of us in that vocation.

I don't know why the author chooses to distinguish writing prose and writing code here. [Software is made of decisions](https://siderea.dreamwidth.org/1219758.html) and at least I usually like to flesh out those decisions through the act of writing code, which forces a level of precision that makes it hard (though not impossible) to handwave away important decisions.

The rest of the paragraph is a list of similar complaints.

All of these can be codified - the new work is the (fascinating!) challenge of working out how and codifying them, then giving the codified checker logic to the agent to run at will - thus taking yourself out of all of those loops.

They don’t even need to be deterministic checks - a shell script that wraps a `claude -p` - and maybe fetches some online resources to stuff into the context - can do your agent’s legal check for it.

As a result, you’re only being effective if you can engineer (not hack, not vibe) an agent that can produce work your company can use with as little cleanup as possible - and with less cleanup over time.

You get job by codifying what you know - what most don’t account for is that there’ll never be a limit to what there is to know, and codifying expertise will be challenging for a long time to come.

There are many reasons to curate what goes into the software - for example, if it must be maintainable, if it must conform to standards that cannot be fully codified into the software (eg. regulatory requirements), or if you just really darn well like writing code!

But it takes a mountain of code to make an outwardly simple thing so why not use a work-amplifying tool to produce that code and get to working software more cheaply.

On the other hand writing is the act of creating the exact product that will be consumed. Every detail matters and there’s no leverage to trying to write faster.

So it’s a false equivalence. Hopefully I’ve elucidated the subtlety.

Not sure if that’s fine though since I get to the point of a project being interesting a lot faster instead of wiring tools together.

Zooming out, the debate largely boils down to the downsides of severed junior pipelines and lost tacit knowledge on one hand, versus the upside of being able to build everything you envisioned on the other.

Honestly, I suspect that programming in the future will become something like the art of bonsai, a form of sculptural cultivation. Just as you dig furrows for water to flow through, and once the water emerges it follows those furrows, Gen AI will pour out an immense volume of code, and we will shape that code into form. It is like when you build with IoC based frameworks. If you do not adopt hexagonal architecture, the code inevitably converges toward the patterns the community recommends anyway. Ultimately, it is less about individual code fragments and more about hoping those fragments do not go wrong, contained by guardrails that ensure they do not exceed certain thresholds. If that is the case, programmers might end up focusing on questions like, "How much loss is acceptable?"

Many programmers say, "You need to know the entire codebase." But as someone who has delivered over 30 projects with codebases of 60,000 lines or more, I know that once my own code alone surpasses 40,000 lines, it becomes nearly impossible to hold it all in memory. So I document it in broad categories. And the next day, I have to retrace where I left off and refresh my memory, which takes a long time. This is one area where Gen AI genuinely excels.

Personally, what I have noticed when looking at other people's code is that those who work at a low level often struggle with high level integration, and vice versa. When cognitive resources become concentrated, specialization deepens in one area while others are neglected. And how one manages those cognitive resources ultimately diverges depending on the domain and the specific problem at hand. Just as the mindset required for architectural design differs from the mindset required for diving deep into implementation.

My workflow, broadly speaking, has not changed. My main job has always been to grasp a legacy codebase, open up the black box, connect debug logs one by one, find safe footholds, and add features. The only difference now is that the black box called "legacy codebase" has simply become "Gen AI code." It is not like I could ever claim my own code was bug free to begin with. Ultimately, what mattered was which bugs to contain and how far to wrap them. Open source programmers, however, are different. Their code blocks serve as their cognitive solutions and their reputation, so their approach differs from delivery oriented code. That is because code quality itself contributes to their prestige. For me, it is the brands and the number of companies I have delivered to that build my reputation. That distinction seems to divide programmers at a fundamental level.

In that sense, I think future programming work will split into roughly three categories. The first is the exceptionally talented group that creates the datasets Gen AI will consume. In other words, the renowned open source groups we already admire. In AI labeling terms, they will be the ones producing the gold standard answer sheets. I believe they will survive and remain admired, just as they are now, though their numbers will shrink even further.

The second group will be those who make Gen AI code flow through industries and organizations. When Gen AI pours out code like water, they will be the ones managing the channels to prevent it from flooding. Most people will migrate into this role.

The third group is QA, and I think they will survive. They will execute Gen AI code and relay to the channel managers when the watercourses are going wrong.

In truth, things are already moving in this direction. It is like how no one thinks about how OOP inheritance maps to vtables anymore. People just treat objects as abstract concepts and move on.

Personally, I think the overall flow in Gen AI coding will shift toward implementing system state in the form of state transition diagrams, a return to the primitive form of Parnas's theory of information hiding. Parnas's theory states that "modules should hide design decisions that are likely to change." Humans interpreted this as something like private variables in OOP, but then leaked internal implementations to the outside anyway. When business policies end up scattered across controllers and services, information hiding has effectively failed. The decisions most likely to change are not hidden in one place. They are dispersed throughout the system. But in the Gen AI era, ironically, information hiding might actually become easier to achieve. You just define the state transition from "payment pending" to "payment completed," and that is it. Ultimately, we might end up circling back to earlier approaches, do you not think?

Anyway, I am not asking for someone else's answer. I need to find my own way. Because my way and someone else's way are different, just as my programming and someone else's programming are different.

Programming is ultimately the work of constructing a mental model, and that mental model is inherently personal.

I just hope I can survive into the next era.

I also disagree that AI results are lower quality. Codex Pro results I get are marvelous but they sometimes miss things that humans understand naturally - all of the edges - coherence of visuals, passage of time, etc.

The manager's job is to manage multiple programmers to let them write code. A good manager should focus on management rather than write code himself.

But keep doing for many years will make manager out of touch from modern coding so he is starting to mismanage people or issue technically wrong order.

Every single LLM will make up stuff, go down rabbit holes I didn't even ask it to visit and infuriate me all day long by doing ALMOST what I asked it to do, but just not quite. Take "yes" to one question as an approval to some other question. Come up with a plan but one you review the plan and accept it it hits some minor issue and then throws away the plan and do whatever it wants. Or when I reject some line of code or don't approve a command it wants to run 9/10 times it just tries to re-add or re-run it as if my rejection was meaningless. And no amount of rules and markdown files ever seems to change its behaviour for long, if at all. It's like working with a sociopath who just doesn't remember anything that happened 5 minutes ago. It's the classic case of "my computer doesn't do what I want, only what I tell it".

And all of that would be fine if it didn't pretend to be a human, if all the UX didn't create the illusion that you interact with some intelligent being, because as long as I remember that this is a cli tool it's all good, I manage my expectations, but the experience sooner or later makes you annoyed and frustrated - and if this was a person they would either stop or you wouldn't never work with them again.

I built a "simple" storage application recently, uploading large files from a phone is not trivial, you can't just command Claude to do it without giving it good context.

1. Client asks you to add a feature(s)

2. Spend two weeks unpaid walking the client through scoping down to the most minimal viable set of features that tests the business hypothesis and roadmap

2. I wrote up a reasonably exhaustive bullet list and sent it to a CGPT to write a draft formal definition of features describing what it should (and should not) do, how users can access it and what the suite of tests that we will need through TDD

3. Chat for 30 minutes with CGPT researching which data structures, algorithms, code libraries and external services might serve best to implement this feature.

4. Generate mockups and data schema alongside CGPT, to build the new feature, the tests to make sure it works as expected, and the documentation telling users how to use it and telling other engineers what they’ll need to know to maintain and debug it.

5. Generate minimum code to test the full data workflow.

6. Send repo and or working application binary to Claude and Gemini to critique

7. Adjust as needed. Deploy for client review and acceptance in sandbox. Promote to production

8. GOTO3 and loop

I can do in a week what would have taken a month a decade ago

I currently work on a very large (multi-million lines) C++ code base and use Claude Code for the following:

1. I run Claude Code in the background finding bugs, while busy implementing new features.

It has so far found and fixed 100+ minor issues and a few major could-crash-the-server-in-production issues that I was really happy to get fixed before a customer found it.

2. I use Claude Code to do massive refactorings that would be really tedious to do by hand.

I love the fact that it updates not just the code but also comments and documentation.

3. I use Claude Code to implement features that I frankly am too bored to implement by hand.

Excellent! Less boredom at work!

4. I use Claude Code to generate tools to analyse the code and/or generate code.

This is a massive quality improvement. It allows me to make the code more maintainable and simpler while adding more features.

However I always always always check and verify every change before committing to git. Because the LLM it will occasionally add features or bugs I don't want.

The end result is really positive. Lots of productivity improvements, less tedious can't-be-bothered work, lots of bug fixes that otherwise would have triggered production issues etc. etc. while 100% maintaining my understanding of the code and all changes.

Love it.

I am developing my own app 2+ years manually, and not use "AI" at all.

Using AI usually can cause many problems, which the author pointed at.

Programming should be enjoyable, not an annoyed or unhappy thing.