r/ChatGPTCoding • u/Impossible-Weird-776 • 4d ago
Discussion How do you tell when coding agents are amplifying your engineering skill vs hiding gaps in it?
TL;DR at the bottom.
I’m 15, mostly self taught, and I’ve been programming for around 2 years. I learned manually first and for a long time intentionally avoided using AI to write code because I wanted to know how programming actually worked before I had something else doing a huge part of it for me. I wrote thousands of lines myself, lived in documentation, debugged stupid mistakes, stared at errors for way too long, broke things, fixed them, somehow broke them again, and generally suffered in the traditional way lol. I’m glad I did that first, and I still keep a lot of my learning manual now, especially C++, systems and hardware.
For serious projects though, I use coding agents heavily. They’ve made me dramatically faster, which is great, but they also created a problem I don’t really know how to measure: how do I know whether AI is amplifying the engineer underneath the output instead of just making the output grow faster than I do? I’m not talking about blindly accepting generated code. I try not to hand an agent work I can’t meaningfully reason about. If there’s an important part of what I’m building that I don’t understand, I’d rather go learn it than treat whatever comes back as magic.
My workflow usually starts with me figuring out what should actually be built and how it should behave. I think through the structure, important boundaries, failure cases and what would count as real evidence that it works. Agents then do a lot of the implementation, which means a huge part of my time shifts into review. I inspect the changes, compare them to what was actually requested, run the software and its tests, look for things the agent touched for no reason, and reject approaches that technically work but are solving the problem badly. A normal conversation with an agent can go from “this works but its the wrong abstraction” to “that test is green but it proves nothing” to “you just broke the security boundary” and eventually “WHAT ARE YOU DOING”.
Review also isn’t something I suddenly decided I was good at because AI started writing code. Before agents became this important to my workflow, I had already spent months reviewing technical work with people much more experienced than me. We’ve had an honestly stupid amount of discussion about software decisions, debugging, Linux, security and things that went wrong in projects. Plenty of those conversations turned into hours of arguing where I actually had to explain why I thought something was wrong, and sometimes I was the one reviewing the implementation or pushing the direction of the project. I obviously don’t think their years of experience magically became mine, but that gave me a ridiculous amount of repetition asking the questions I now ask when reviewing agent work: does this really solve the requirement? What happens when it fails? Did we make this more complicated for no reason? Does the test actually prove anything? Are we fixing the real problem or hiding it? Is someone going to hate us for this six months from now?
Programming also stopped being purely something I studied pretty early. I started doing paid automation work, then the problems became big enough that I ended up building custom software around them. I’ve made low five figures total from software related work so far, and I’m starting to get the less glamorous side of it too: maintaining something after people actually depend on it. One system has employees using it, giving feedback, changing what they need and somehow discovering the ONE case I never thought about. Apparently “it works on my machine” was not the final stage of software engineering. Who knew.
I build a lot outside paid work too. I’ve made a small x86-64 kernel where I went into low level hardware and networking, but that’s only one example. I’ve also built Linux tools, backend and infrastructure systems, security related tooling, automation systems and software meant to make real workflows safer or easier. A lot of what I enjoy building has an actual use behind it rather than existing purely so I can put another repository on GitHub. I’m obviously not claiming I have deep expertise in every area I’ve touched after only 2 years, but I’ve put a stupid amount of time into this and I don’t really want to pretend otherwise just to sound humble.
If coding agents disappeared tomorrow, I wouldn’t suddenly become unable to program. I can still take a problem apart, design something, read the docs, write the implementation myself and sit in a debugger until I figure out what went wrong. I still deliberately do that now. I would just become WAY slower. That’s where this gets interesting to me, because being able to recognize why an implementation is bad isn’t exactly the same experience as fighting through it yourself. Spotting a bad abstraction isn’t the same as designing a bad one, living with it for months and finally understanding why you hate it. Reviewing a debugging fix isn’t quite the same as having no clue where the bug is and spending three hours hunting it down yourself.
Agents can erase a lot of that painful repetition simply by being ridiculously fast. But deliberately refusing to use them just so I can type more code also feels backwards. If I have a tool that multiplies how much I can do and I’m capable of supervising its work, of course I want to use it. I don’t think the answer is “stop using AI until you’ve suffered for another five years”. The question is whether the parts of engineering I’m practicing heavily can race ahead while some of the intuition that normally comes from implementing and failing yourself develops much more slowly without me noticing.
Right now I basically keep two tracks. When I actually need to ship something, I use agents aggressively. When the point is learning, I intentionally make myself do much more of the work. C++, systems and hardware especially stay much more manual. I still read docs, implement things myself and debug problems before immediately handing them to an agent. I also liked a suggestion I got recently: always keep at least one project where I personally own the important implementation decisions and need to be able to defend why I made them. That sounds like a pretty good control group.
So I’m curious how people here who seriously use coding agents think about this. What would you test completely without an agent to make sure the ability underneath your AI workflow is still growing? What experiences do you think you simply have to go through yourself? And for people who have been doing agent driven development for a while, have you noticed anything getting weaker, or anything becoming noticeably stronger?
The question I care about most is this: what separates someone whose engineering ability is genuinely being amplified by coding agents from someone whose output just makes them appear more capable than they really are?
I’m not interested in another “AI good” vs “AI bad” argument. I want to use these tools aggressively. I just don’t want the speed to hide weaknesses I would have been forced to notice without them.
TL;DR: I’m 15 and have been programming for around 2 years. I learned manually first, wrote thousands of lines myself and still deliberately keep part of my learning manual. Before coding agents became a huge part of my workflow I had already spent months reviewing technical work with more experienced people. I’ve also done paid client work, made low five figures from software related work, built useful software across several areas, worked on low level projects like an x86-64 kernel, and started maintaining systems that real people use.
Now I use coding agents heavily when I’m trying to ship. They do a lot of implementation while I spend much more of my time deciding how the system should work, reviewing what gets produced and proving that it actually behaves correctly. I can still build and debug without agents. I’d just be dramatically slower.
What I’m trying to figure out is whether that workflow can make some parts of my engineering ability develop very quickly while the intuition gained from personally implementing, failing and debugging grows more slowly underneath it. I want concrete ways to expose that gap before it becomes a problem, and to tell the difference between AI genuinely amplifying someone and AI simply making them look better than they are.
AI disclosure: the experiences and opinions are mine. I used AI to help organize and trim the writing.
3
u/ShortingBull 4d ago edited 4d ago
Overthinking.
As a software engineer of >30years my best project manager was not software literate - they were skilled at taking a message from the customer and passing it to the developers (there was a lot of developer plumbing there still) and aiding the process without inflicting their bias. They could manage the process, the customer and the developers.
This is who I am today when I use AI - I still use my eng skills to build a team that can solve problems and produce solutions. But I am the manager and I try to be a good one.
1
u/Impossible-Weird-776 4d ago
The manager analogy makes sense. My concern is whether I could become very good at managing the “team” while quietly getting worse at being one of the engineers on it. Do you think that distinction still matters as the tools improve?
1
u/ShortingBull 4d ago
IMO the process is more important than who the participants are.
I am not the lead engineer now - the AI can do better.
The only place I feel I add value now is giving direction and driving the process. The bits in the middle are just not the meat it used to be. It's a disposable medium that has low value - which is the exact opposite of 2 years ago.
1
u/CrimsonBolt33 4d ago
This is the best way to look at it in my mind. It is not the same as coding....its a new process and new skill set.
Knowing how to code and all that is important and helpful with AI, but being an architect and designer is more important with AI vs when you are coding manually.
3
u/Significant-Bee5101 4d ago
In the future just write shit yourself no ones gunna read all this and take it seriously
0
u/lu16151m0nc1n1 3d ago
the OP said to be 15 yo, I guess you're 13
2
-4
u/Impossible-Weird-776 4d ago
Then you’re probably not the audience for it lol
3
u/Significant-Bee5101 4d ago
Who is the audience for it Mr. 15-year-old engineer
-1
u/Impossible-Weird-776 4d ago
People who actually use coding agents seriously. You’ve made it pretty clear that isn’t you.
1
u/Significant-Bee5101 4d ago
Ah okay. I guess I'll go tell everyone at my job as a government contracted security researcher specializing in LLM security that I don't use "coding agents" seriously.
I sure hope they don't fire me!
-2
u/Impossible-Weird-776 4d ago
Fair, I misread that part. Still doesn’t really address what I was asking though.
1
u/roger_ducky 4d ago
Your main question can be answered as:
Who made the engineering decisions for the design?
Essentially, if the person did, and can explain the high level design and tradeoffs accurately, (not saying line by line, but module by module, as well as overall design) then AI is mostly just doing the implementation.
I do expect someone who understands it to at least explain why a specific data structure or pattern was used, even if they can’t give the textbook name for it.
People who only vaguely know what’s going on in the program didn’t stay in control of the design. That, I’d consider ceding too much control to the agents.
1
u/WiseHalmon Professional Nerd 4d ago
Provide your GitHub for a reply.
1
u/WiseHalmon Professional Nerd 4d ago
And describe a project you enjoyed that touched the real world
1
1
u/3dprintinted 4d ago
Code works and does what it needs to do. Codebase is just enough to complete specific tasks. When adding features to existing code it does not try to rewrite the whole thing and respects logic already written.
1
u/DevWorkflowBuilder 4d ago
the manager framing misses one thing: a manager can still read the diff. i keep a rule that i have to be able to write the failing test before the agent fixes anything, and i track how often i can. when that number drops under about 80 percent for a week it means i am rubber stamping, not reviewing. cheap signal, and it is on me rather than on the model.
1
u/geekichu 4d ago
youre doing great. it's like riding a bike. if you to suddenly do without a.i. you might be a bit rusty .. but quickly get back to speed and more. memory isnt lost.. not really.. you'll be like 'oh.. yeah... i remember now..'
this isnt limited to A.I. at my age and with all the tech Ive been exposed to, I can say I have forgotten more than I know. but it's actually not true. if i have to get into something similar to what I did before... it comes back. really does.
1
u/Flatliner2020 4d ago
For the amplifying-vs-hiding: write the handoff for the next session from memory, before looking at the code - what the module does and the failure case you were worried about. If that page comes out thinner than the code, the code got ahead of you.
3
u/kaaiian 4d ago
Meh. The tools are only getting better. If you don’t notice a gap now, it likely won’t be a problem in the future.
I’d focus more on figuring out how to leverage what you bring that AI can’t.
For example, “taste”. It can make a good UI using best practices, but it can’t know how it feels to use it as a human.
More and more, your job should be figuring out how to minimize time-to-feedback and how to best translate the intangibles into AI code iterations.