Reflections on software engineering in the age of AI

Post by dang » Sun, Jun 28, 2026, 7:09 PM UTC

raincole wrote: post #24

lilerjee wrote: post #13

This is not an Age of AI. Why do so many not-real-programmers think this is an age of AI? It's just a hype. 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.

> I am developing my own app 2+ years manually, and not use "AI" at all. How does this mean this isn't an age of AI? Because you're The Representative of Programmers? > so many not-real-programmers Oh sorry I missed this part. It seems that you really are!

Post by danans » Sun, Jun 28, 2026, 7:11 PM UTC

slopinthebag wrote: post #14

danans wrote: post #7

> Someone asks you to add a feature to an existing program 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 co…

This is not true. First of all, not all software is written in the context of a FAANG company with “feature requests”. Secondly, writing software is similar to the process of design , this comment reads like “the vast majority of handbag design is mapping problem between features and leather”, ignoring that both the design and implementation can be rewarding to work on. Eg. I’m working on a program for myself and the…

Post by michaelchisari » Sun, Jun 28, 2026, 7:18 PM UTC

whoke wrote: post #20

"you haven’t done any of the hard thinking you would normally do in writing the code yourself" 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. Th…

  1. Don't use it to write code. It's a terrible
     programmer. But it's an intelligent rubber duck
     and a solid analysis tool.

  2. Write the code yourself. It'll go faster than
     figuring it out as you go along. It's just typing
     if you have a plan.

  3. Use an LLM to sanity check what you wrote.
     It can find potential design issues or future
     problems or breaks from convention. Decide based on
     your experience how much you want to address these
     issues before moving on.

Post by dnadler » Sun, Jun 28, 2026, 7:26 PM UTC

michaelchisari wrote: post #35

whoke wrote: post #20

"you haven’t done any of the hard thinking you would normally do in writing the code yourself" 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. Th…

| type errors, scope issues, import resolution, dependencies. I write code myself and use the LLM to find mistakes then fix them manually. I recommend inverting the conventional wisdom on LLMs: 1. Don't use it to write code. It's a terrible programmer. But it's an intelligent rubber duck and a solid analysis tool. 2. Write the code yourself. It'll go faster than figuring it out as you go along. It's just typing if yo…

Post by [deleted] » Sun, Jun 28, 2026, 7:29 PM UTC

dnadler wrote: post #37

michaelchisari wrote: post #35

Earlier quoted context omitted.

| type errors, scope issues, import resolution, dependencies. I write code myself and use the LLM to find mistakes then fix them manually. I recommend inverting the conventional wisdom on LLMs: 1. Don't use it to write code. It's a terrible programmer. But it's an intelligent rubber duck and a solid analysis tool. 2. Write the code yourself. It'll go faster than figuring it out as you go along. It's just typing if yo…

> Don't use it to write code. It's a terrible programmer. I see this sentiment often, and I’m honestly not sure where this comes from, as it’s really not been my experience. I feel like this must come from people feeling threatened and just moving the goals posts, or not knowing how to use the tools effectively.