will software engineers education be like doctor education? Where we go to school for 6-8 years with multiple steps of tests and certifications to passed before we can touch production code
Coding assistants are solving the wrong problem
141–150 of 151 posts
Re: Coding assistants are solving the wrong problem
#142Cope harder. AI-assisted programming is a huge productivity boost.
Re: Coding assistants are solving the wrong problem
#143> There’s a name for misalignment between business intent and codebase implementation: technical debt. I wish we'd stop redefining this term. Technical debt is a shortcut agreed upon with the business to get something out now and fix later, and the fix will cost more than the original. It is entirely in line with business intent.
Software is not a liability, it's an asset. If you make it for less then it has a shorter shelf-life. Tech debt is a nonsense term to begin with.
I'm going disagree with you. My assets don't wake me up at 3am when they stop working....the best software is no software.
My line of reasoning with an example:
I own a car, and the car itself isn't the value I get from the vehicle. The value is being able to go distant places easily. If I could snap my fingers and travel instantly I wouldn't own a car.
So, software is the value delivery vehicle, but generally not the actual valuable thing (remember that the vast majority of software are CRUD apps that are a step above excel that mainly handle bookkeeping).
Re: Coding assistants are solving the wrong problem
#144It is entirely possible for someone to be 2x faster at coding with AI without increasing their throughput. I believe Claude Code has made me at least 2x as productive. But I can easily see why a 2x increase in individual development speed may not translate to any increase overall at the level of the whole organization. Because at most organizations the bottleneck is not code, it’s everything else from politics to external blockers to bike shedding and people’s egos. So a developer who is 2x faster at their work may just end up having more free time on their hands. The greatest increases in productivity and throughput are where there are no external blockers, like random side projects, which is exactly where people report the greatest productivity with AI.
Re: Coding assistants are solving the wrong problem
#145Earlier quoted context omitted.
Software is not a liability, it's an asset. If you make it for less then it has a shorter shelf-life. Tech debt is a nonsense term to begin with.
I'm going disagree with you. My assets don't wake me up at 3am when they stop working....the best software is no software. My line of reasoning with an example: I own a car, and the car itself isn't the value I get from the vehicle. The value is being able to go distant places easily. If I could snap my fingers and travel instantly I wouldn't own a car. So, software is the value delivery vehicle, but generally not th…
I'm speaking from the perspective of business and accounting.
Re: Coding assistants are solving the wrong problem
#146Earlier quoted context omitted.
I use Claude Code a lot but one thing that really made me concerned was when I asked it about some ideas I have had which I am very familiar with. It's response was to constantly steer me away from what I wanted to do towards something else which was fine but a mediocre way to do things. It made me question how many times I've let it go off and do stuff without checking it thoroughly.
I've had quite a bit of the "tell it to do something in a certain way", it does that at first, then a few messages of corrections and pointers, it forgets that constraint.
Create an AGENTS.md that says something like, "when I tell you to do something in a certain way, make a note of this here".
The only catch is that you need to periodically review it because it'll accumulate things that are not important, or that were important but aren't anymore.
Re: Coding assistants are solving the wrong problem
#147> most tech debt isn’t actually created in the code, it’s created in product meetings. Deadlines. Scope cuts.
> When asked what would help most, two themes dominated
> Reducing ambiguity upstream so engineers aren’t blocked...
I do wonder how much LLMs would help here, this seems to me at least, to be a uniquely human problem. Humans (Managers, leads, owners, what have you) are the ones who interpret requirements, decide deadlines, features and scope cuts and are the ones liable for it.
What could an LLM do to reduce ambiguity upstream? If it was trained with information on requirements, this same information could be documented somewhere for engineers to refer to. If it were to hallucinate or "guess" an answer without talking to a person for clarification, and which might turn out to not be correct, who would be responsible for it? imo, the bureaucracy and waiting for clarification mid-implementation is a necessary evil. Clever engineers, through experience, might try implement things in an open way that can be easily changed for future changes they predict might happen.
As for the second point,
> A clearer picture of affected services and edge cases
> three categories stood out: state machine gaps (unhandled states caused by user interaction sequences), data flow gaps, and downstream service impacts.
I'd agree. Perhaps when a system is complex enough, and a developer is laser focused on a single component of it, it is easy to miss gaps when other parts of the system are used in conjunction with it. I remember a while ago, it used to be a popular take that LLMs were a useful tool for generating unit tests, because of their usual repetitive nature and because LLMs were usually good at finding edge cases to test, some of which a developer might have missed.
---
I will say, it is refreshing to see a take on coding assistants being used on other aspects instead of just writing code, which as the article pointed out, came with its own set of problems (increase Inefficiencies in other parts of the development lifecycle, potential AI-introduced security vulnerabilities, etc.)
Re: Coding assistants are solving the wrong problem
#148Earlier quoted context omitted.
Yes but in my experience this sometimes works great, other times you paint yourself in a corner and the sun total is that you still have to learn the thing, just the initial ram is less steep. For example I build my self a nice pipeline for converting jpegs on disk to h264 on disk via zero-copy nvjpeg to nvenc, with python bindings but have been pulling out my hair over bframe ordering and weird delays in playback et…
Yeah, knowing what words to use is half the battle. Quickly throw away a prompt like "Hey, `make build` takes five minutes, could you make it fast enough to run under 1 minute" and the agent will do some work and say "Done, now the build takes 25 seconds as we're skipping the step of building the images, use `make build INCLUDE_IMAGES=true` when you want to build with images". It's not wrong, given the prompt, but ta…
"Make all the tests pass"
"Ok, I've deleted all the failing tests"
Re: Coding assistants are solving the wrong problem
#149Earlier quoted context omitted.
The article they are referring to is 404, but based on the URL was published bit more than year ago. That's quite long time in a field that is evolving so rapidly and which even the pioneers are still figuring out.
Its not from a year ago, just 6 months ago: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o...
> developers can use any tools they choose (primarily Cursor Pro with Claude 3.5/3.7 Sonnet—frontier models at the time of the study
Sonnet 3.5 came out in mid 2024
Re: Coding assistants are solving the wrong problem
#150I have long said that the fundamental job of a programmer is to translate sloppy requirements into bulletproof logic.
And AI has no concept of this.