Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Senior Developer Skills in the AI Age

manuel.kiessling.net

Post reply on HN
Print view View original

291–300 of 323 posts

Re: Senior Developer Skills in the AI Age

#291

Post by ManuelKiessling »

necovek wrote: post #288
ManuelKiessling wrote: post #267

Earlier quoted context omitted.

Because I wanted exactly this experience: can I get to the desired result — functionality-wise, if not code-wise! — even if I choose the stack that makes sense in terms of technology, not the one that I happen to be proficient in? And if I cannot bring language-proficiency to the table — which of my capabilities as a seasoned software&systems guy can I put to use? In the brown-field projects where my team and I have…

Ok, I guess you shouldn't complain that you really got exactly what you wanted. However, your writing style implied that the result was somehow better because you were otherwise an experienced engineer. Even your clarification in the post sits right below your statement how your experience made this very smooth, with no explanation that you were going to be happy with bad code as long as it works.

I guess we are slowly but steadily approaching splitting-hairs-territory, so not sure if this is still worth it…

However. I‘m not quite sure where I complained. Certainly not in the post.

And yes, I’m very convinced that the result turned out a lot better than it would have turned out if an unexperienced „vibe coder“ had tried to achieve the same end result.

Actually pretty sure without my extensive and structured requirements and the guard rails, the AI coding session would have ended in a hot mess in the best case, and a non-functioning result in the worst case.

I‘m 100% convinced that these two statements are true and relevant to the topic:

That a) someone lacking my level of experience and expertise is simply not capable of producing a document like https://github.com/dx-tooling/platform-problem-monitoring-co...

And that b) using said document as the basis for the agent-powered AI coding session had a significant impact on the process as well as the end result of the session.

Re: Senior Developer Skills in the AI Age

#292

Post by Workaccount2 »

cztomsik wrote: post #203
Aurornis wrote: post #36

Earlier quoted context omitted.

> I feel like one could delete almost all comments from that project without losing any information I far from a heavy LLM coder but I’ve noticed a massive excess of unnecessary comments in most output. I’m always deleting the obvious ones. But then I started noticing that the comments seem to help the LLM navigate additional code changes. It’s like a big trail of breadcrumbs for the LLM to parse. I wouldn’t be surpr…

More tokens -> more compute involved. Attention-based models work by attending every token with each other, so more tokens means not only having more time to "think" but also being able to think "better". That is also at least part of the reason why o1/o3/R1 can sometimes solve what other LLMs could not. Anyway, I don't think any of the current LLMs are really good for coding. What it's good at is copy-pasting (with…

I have tried getting gemini 2.5 to output "token efficient" code, i.e. no comments, keep variables to 1 or 2 letters, try to keep code as condensed as possible.

It didn't work out that great. I think that all the context in the verbose coding it does actually helps it to write better code. Shedding context to free up tokens isn't so straightforward.

Re: Senior Developer Skills in the AI Age

#293

Post by tracker1 »

necovek wrote: post #9

The premise might possibly be true, but as an actually seasoned Python developer, I've taken a look at one file: https://github.com/dx-tooling/platform-problem-monitoring-co... All of it smells of a (lousy) junior software engineer: from configuring root logger at the top, module level (which relies on module import caching not to be reapplied), over not using a stdlib config file parser and building one themselves,…

I can say it isn't any better for JS/Node/Deno/Bun projects that I've seen or tried. About the only case it's been helpful (GitHub CoPilot) is in creating boilerplate .sql files for schema creation, and in that it became kind of auto-complete on overdrive. It still made basic missteps though.

Re: Senior Developer Skills in the AI Age

#294

Post by Workaccount2 »

Aurornis wrote: post #62
only-one1701 wrote: post #5

Increasingly I’m realizing that in most cases there is a SIGNIFICANT difference between how useful AI is on greenfield projects vs how useful it is on brownfield projects. For the former: pretty good! For the brownfield, it’s often worse than useless.

It’s also interesting to see how quickly the greenfield progress rate slows down as the projects grow. I skimmed the vibecoding subreddits for a while. It was common to see frustrations about how coding tools (Cursor, Copilot, etc) were great last month but terrible now. The pattern repeats every month, though. When you look closer it’s usually people who were thrilled when their projects were small but are now frust…

The real issue is context size. You kinda need to know what you are doing in order to construct the project in pieces, and know what to tell the LLM when you spin up a new instance with fresh context to work on a single subsection. It's unwieldy and inefficient, and the model inevitably gets confused when it can effectively look at the whole code base.

Gemini 2.5 is much better in this regard, it can make decent output up to around 100k tokens compared to claude 3.7 starting to choke around 32k. Long term it remains to see if this will remain an issue. If models can get to 5M context and perform like current model with 5k context, it would be a total game changer.

Re: Senior Developer Skills in the AI Age

#295

Post by skydhash »

atemerev wrote: post #289
skydhash wrote: post #247

Earlier quoted context omitted.

> It is 5x if you are already a senior SE knowing your programming language really well, constantly suggesting good architecture yourself ("seed files" is a brilliant idea), and not accepting any slop / asking to rewrite things if something is not up to your standards (of course, every piece of code should be reviewed). If you know the programming language really well, that usually means you know what libraries are u…

"Given this code, extract all entities and create the database schema from these", "write documentation for these methods", "write test examples", "write README.md explaining how to use scripts in this directory", "refactor everything in this directory just like this example", etc etc Everything boring can be automated and it takes five seconds compared to half an hour.

It can only be automated if the only thing you care about is having the code/text, and not making sure they are correct.

> Given this code, extract all entities and create the database schema from these

Sometimes, the best representation for storing and loading data is not the best for manipulating it and vice-versa. Directly mapping code entities to database relations (assuming it's SQL) is a sure way to land yourself in trouble later.

> write documentation for these methods

The intent of documentation is to explain how to use something and the multiple why's behind an implementation. What is there can be done using a symbol explorer. Repeating what is obvious from the name of the function is not helpful. And hallucinating something that is not there is harmful.

> write test examples

Again the type of tests matters more than the amount. So unless you're sure that the test is correct and the test suite really ensure that the code is viable, it's all for naught.

...

Your use cases assume that the output is correct. And as the hallucination risk from LLM models is non-zero, such assumption is harmful.

Re: Senior Developer Skills in the AI Age

#296

Post by lowsong »

> … I believe our community should embrace it sooner rather than later — but like all tools and practices, with the right perspective and a measured approach.

There is no such thing as a measured approach. You can either use LLM agents to abdicate your intellectual honesty and produce slop, or you can refuse their use.

Re: Senior Developer Skills in the AI Age

#297

Post by mistrial9 »

dheera wrote: post #158
mjr00 wrote: post #33

Earlier quoted context omitted.

> If the code works, passes all relevant tests, is reasonably maintainable, and can be fitted into the system correctly with a well defined interface, does it really matter? You're not wrong here, but there's a big difference in programming one-off tooling or prototype MVPs and programming things that need to be maintained for years and years. We did this song and dance pretty recently with dynamic typing. Developers…

> You're not wrong here, but there's a big difference in programming one-off tooling or prototype MVPs and programming things that need to be maintained for years and years. Humans also worry about their jobs, especially in PIP-happy companies; they are very well known for writing intentionally over-complicated code that only they understand so that they are irreplaceable

hmm I have seen conda env with far too many packages and maybe a lot of current version bumping, and the dev says "who cares" and it naturally gets a bit more.. Intentionally complicated is more like an accusation of wrongdoing.

Re: Senior Developer Skills in the AI Age

#298

Post by mistrial9 »

SkyBelow wrote: post #235
XorNot wrote: post #193

Earlier quoted context omitted.

I'm not convinced this actually happens. Seems more like somthing people assume happens because they don't like whatever codebase is at the new job.

The challenge is that sufficiently bad code could be intentional or it could be from a lack of skill. For example, I've seen a C# application where every function takes in and outputs an array of objects, supposedly built that way so the internal code can be modified without ever having to worry about the contract breaking. It was just as bad as you are imagining, probably worse. Was that incompetence or building thi…

but that is literally how the browser window DOM works, no? It depends on how diligent the maintenance is IMHO

Re: Senior Developer Skills in the AI Age

#299

Post by mistrial9 »

nsonha wrote: post #129
dilyevsky wrote: post #80

Earlier quoted context omitted.

The point is because it generally produces crap code you have to one shot or else iteration becomes hard. Similar to how a junior would try to refactor their mess and just make a bigger mess

I find it hard to believe that when the AI generates crap code, there is absolutely nothing you can do (change the prompt, modify context, add examples) to make it do what you want. It has not been my experience either. I only use AI to make small modules and refactor instead of one-shoting. Also I find "AI makes crap code so we should give it a bigger task" illogical.

it seems that there are really, really large differences between models; how well they do, what they respond to.. even among the "best" .. the field does seem to be moving faster

Re: Senior Developer Skills in the AI Age

#300

Post by thwarted »

cess11 wrote: post #160
necovek wrote: post #9

The premise might possibly be true, but as an actually seasoned Python developer, I've taken a look at one file: https://github.com/dx-tooling/platform-problem-monitoring-co... All of it smells of a (lousy) junior software engineer: from configuring root logger at the top, module level (which relies on module import caching not to be reapplied), over not using a stdlib config file parser and building one themselves,…

wrap_long_lines shares those characteristics: https://github.com/dx-tooling/platform-problem-monitoring-co... Where things are placed in the project seems rather ad hoc too. Put everything in the same place kind of architecture. A better strategy might be to separate out the I and the O of IO. Maybe someone wants SMS or group chat notifications later on, instead of shifting the numbers in filenames step11_ onwards on…

> instead of shifting the numbers in filenames step11_ onwards

There are idioms used when programming in BASIC on how to number the lines so you don't end up renumbering them all the time to make an internal change. It's interesting that such idioms are potentially applicable here also.

Post reply on HN