[didibus]

> If the thinking bit is your favorite part, AI allows you to spend nearly all of your time there if you wish, from concept through troubleshooting

I think this depends. I prefer the thinking bit, but it's quite difficult to think without the act of coding.

It's how white boarding or writing can help you think. Being in the code helps me think, allows me to experiment, uncover new learnings, and evolve my thinking in the process.

Though maybe we're talking about thinking of different things? Are you thinking in the sense of what a PM thinks about ? User features, user behavior, user edge cases, user metrics? Or do you mean thinking about what a developer thinks about, code clarity, code performance, code security, code modularization and ability to evolve, code testability, innovative algorithms, innovative data-structure, etc. ?

[nativeit]

I’m struggling to understand how they are asserting one follows from the other. I’m not a SWE, but do a lot of adjacent types of work (infrastructure automation and scripting, but also electronics engineering, and I’m also a musician), and the “thinking” part where I get to deploy logic and reasoning to solve novel challenges is certainly a common feature among these activities I certainly enjoy, and I feel it’s a core component of what I’m doing.

But the result of that thinking would hardly ever align neatly with whatever an LLM is doing. The only time it wouldn’t be working against me would be drafting boilerplate and scaffolding project repos, which I could already automate with more prosaic (and infinitely more efficient) solutions.

Even if it gets most of what I had in mind correct, the context switching between “creative thinking” and “corrective thinking” would be ruinous to my workflow.

I think the best case scenario in this industry will be workers getting empowered to use the tools that they feel work best for their approach, but the current mindset that AI is going to replace entire positions, and that individual devs should be 10x-ing their productivity is both short-sighted and counterproductive in my opinion.

[skydhash]

I like to think of the essential/accidental complexity split. The true way to solve essential complexity in a business settings is to talk with stakeholders.

Tools, libraries and platforms are accidental complexities. If you have already learned how to use them, you can avoid the pitfalls and go straight to the solution, which is why the common advice is to use boring technologies, as the solutions are widely documented and there are a lot of case studies.

If it's something new, then you can learn as you go by starting small and refactor as you're gaining more confidence. Copy-pasta or code generation is usually bad in that case. You don't know enough to judge the long-term costs.

Code is tech debt. When people talk about software engineering, it's to make sure that this debt doesn't outweigh the benefits of using the software.