The student becomes the master.
AI:"look at me, i'm the captain now."
Artificial intelligence is rapidly reshaping the way software gets built, tested, and maintained — but not in the simplistic, headline-grabbing sense of "AI replacing developers." Over the past few years, I've seen firsthand how AI is starting to change working practices. It's not a sweeping transformation, nor is it …
AI can never be anything more that a tool. But AI can be a tool that enables the user to become someone (or something) else's tool. To be fair "being a cog in the wheel" is not always a bad thing - being a member of a team following a leader or an overarching abstract ideal, can be very satisfying and productive, as one part of one's life, in a symbiotic relationship with one's own human originality. In the worst case however, it kills originality of action and thought - Dark Ages stuff. AI has the power to let us lead us into the new Dark Ages, if we let it.
Despite the label, it’s not Intelligence..
it’s not intelligent, is doesn’t reason, it pattern matches, it runs inference cycles, it does some pretty suspect maths/statistics. It is not sentient.
It also ‘learns’ by consuming - it seems everything without sorting out the garbage Humans and Animals with demonstrable ‘Intelligence’ get taught, they get stuck (often getting it horribly wrong and adapting), and improve their reasoning/critical thinking abilities. They improve using increasingly advanced subject specialised knowledge/textbooks and do trial and error research and use their ‘honed knowledge’ and become an expert. They are also immersed in the very same world they are trying to problem solve.
That’s not how AI works. Throwing computing muscle at it. It has no satisfaction and pride at doing a good job, and no stake in the game- the self-interest of keeping a job by doing it well.
Hardly surprising it’s a bit shit.
In the worst case however, it kills originality of action and thought - Dark Ages stuff. AI has the power to let us lead us into the new Dark Ages, if we let it.
Maybe reading one of those articles by an irate historian about why the dark ages were actually quite a good time will make you feel better.
Agreed - especially not LLM technology, which isn't actually "intelligent" so that it understands your request as anything but a statistical theory against a massive dataset. Never mind technology that can understand an application in it's entirety like a programmer has to while debugging a major system. LLMs are fine for toy projects of a few files, but try to take them up against a code base of hundreds of thousands or millions of lines and they fail miserably at "understanding" what needs to change using mere statistics.
We need actual machine intelligence with model-of-the-world storage, information about the history of a conversation and project over time, less tendency to modify code that isn't related to a problem, and the ability to correlate the model of the world with templates of how to map it to system concepts. LLM statistics will never achieve that, and Altman and company are the biggest scam artists and bullshit spewers on the planet since Drumpf was born...
I might not necessarily agree with the recommendation of trying to solve things yourself first. I can do that for most tasks I come across; the bigger problem is whether my solution is good (fast, maintainable, extendable, etc.) enough to be used. A bit of online research beforehand can increase the chances of that greatly.
Unfortunately, the same cannot be said for AI tools, especially those that suggest one single solution, providing little context for its advantages and disadvantages.
The tools will default to a single solution, but if you can fix that in the prompt by telling it to give three alternate solutions with context, and to let you pick which one it should proceed with. Prompt engineering is going to become a big deal in the future and if I wasn't about to retire it's an area I would be getting into.
We have seen plenty of things which some have proclaimed will "become a big deal in the future", and which indeed have become a big deal. Some of them have turned out to be much less successful than those who proclaimed as the future would have has us believe at the beginning. Whilst the current trend of LLM based (supposed) AI will no doubt become a big thing, it remains to be seen whether the results will be acceptable or whether it will generate even bigger problems. At the present, it seems to me to be heading directly for the latter (bypassing 'GO' in the process and failing to collect the £200 (billion) reward as it does so).
As they say - every new solution breeds new problems.
‘Good enough’, ‘minimum viable product’.
The slop of Agile. Deliver some shit that half works and try to improve it.
The Snakeoil of ‘delivering value early’ ….. is a long tail of cost, performance problems, shit Database and data models and inability to scale (up or out).
Lol. If that's what you think Agile does or how it works, then you've been doing it very wrong.
Performance, scaling, and cost are day one objectives regardless of methodology. But lets face it, you know they're the first thing cut in a waterfall delivery because you well understand why there won't be time to deliver everything anyway. At least with Agile what goes missing isn't the performance, scalability, security, or run cost, its that umpteenth feature nobody will ever use that the design committee simply wouldn't give up.
Agile works, if you do it right. If you do it wrong, well, the problems not the methodology, is it?
>> If you do it wrong, well, the problems not the methodology, is it?
To mangle Mr Ian Anderson MBE (no less)...
" just remember, if you don't mind --- it's not the gunmethodolgy that kills screws up the project, but the man behind."
I guess that's why SSDAM is(was? does anyone use it these days?) so hard to get right in the real world - there can only be a handful of people who actually understand how to implement it and many hundreds who claim that they do!
Every waterfall delivery is a series of agile steps with the final one ( a fully working, bug free product *) being a little waterfall.
we all know that the current "agile" software is never finished so it is little different to a failed waterfall project
* stop laughing at the back there.
If that's what you actually believe then you don't understand either Agile or Waterfall I'm afraid. Once software stopped shipping on CD the opportunities changed forever.
Agile gets you working software from the beginning to end. Waterfall might or might not and you won't know until the end.
Agile ensures you only build what you're actually going to use. Waterfall might or might not build something you might or might not need or have needed 3 years ago and you won't know until the end.
The only real purpose behind waterfall now is embedded systems where redeployment is difficult or expensive and can't be trivially automated.
I suspect you have no experience of real world “waterfall”, I suspect like many you have taken the academic or purist view as gospel; where you can only progress to the next phase in a system development when all components of a system have completed a phase. Reality, is a (large) system is broken down into components within a common framework, each component then proceeded down its own “waterfall”. I was permitted to progress to the next stage once I had got a deliverable signed off, so yes I had to produce the relevant design documents, however, sign off was only to say sufficient had been defined to permit meaningful activity in the next phase, the expectation was the documents would be refined and only frozen after customer sign off. Ie. Not too dissimilar to DSDM, Agile etc.
Remember a key driver behind Agile were the SI’s as it enable risk to be transferred back on to the customer.
Obviously, with mass market products like Windows Office, there is no one customer, so someone within the development team have to make a judgement call over what can be released to market. The shipping of physical media, and the costs and time involved, meant release authorisers were more conservative. Today, as we are witnessing, speed of release is more important than completeness of useable functionality, leading to broken systems…
Lol. Hilariously wrong.
I've enough real world experience of waterfall to know exactly why not only doesn't it work but why it can't work.
You've totally misunderstood Agile by the looks of your post. It's absolutely not about risk transference.
Speed of release and quality of what is released are unrelated, at least in the way you seem to think.
All of the most reliable systems I've built or interacted with were produced using agile. It delivers far higher quality than waterfall can produce, due the nature of waterfall mandating corner cutting to meet often arbitrary deadlines.
> You've totally misunderstood Agile by the looks of your post. It's absolutely not about risk transference.
I spend 20 years working for SI’s selling “Agile”…
Classic aka textbook waterfall misses the feedback; good systems are the result of both top-down and bottom-up thinking.
>” Speed of release and quality of what is released are unrelated, at least in the way you seem to think.”
They are related because some eg. Microsoft, have taken the mantra “ Release early, release often” to mean release half-baked ‘“products” to market, because that’s “Agile”. I don’t miss understand, just that people have misunderstood Agile; at the end of the development process you need a product that actually works and reasonable complete. So I agree only an idiot would take whatever comes out of 3 cycles of Agile and release it to market, however, I expect the same idiot to behave similarly with respect to waterfall…
>” due the nature of waterfall mandating corner cutting to meet often arbitrary deadlines.”
Agree Arbitrary deadlines are a big issue, Agile also suffers from them, hence why many think you only need three cycles of “Agile” to get an 80% product, fit for release to production…
6 weeks of coding is never going to deliver a working abstraction of complexity.
Correlation of value is endemic in how modern professionals work, from software engineering through to marketing etc.
Rapid iteration enables it, waterfall does not. The reason if evolution of the market, regulator, and business while the system is being produced.
Waterfalls requirement to have fully completed detailed specs before commencing coding nukes any ability to deliver that.
No respectable techie still behaves as though it's the 90s, let alone the 70s, which birthed waterfall due to the cost of iteration through compilation and distribution. If waterfall didn't already exist there is no possibility anyone would invent it as a way of working now. It doesn't solve today's problems at all.
>” If waterfall didn't already exist there is no possibility anyone would invent it as a way of working now.”
I would disagree…
Learning about software engineering, the logical sequence of activities contained in the waterfall model greatly facilitates learning and tool development.
[Aside: similar arguments apply to the ISO OSI Reference Model.]
The issue and challenge is taking this learning forward into the real-world and applying it. Even back in 1981, it was recognised SSADM and strict adherence to “The Waterfall” was problematic and ill suited to many IT projects - which were exploring new areas of computerisation, hence the rise of alternatives which have been grouped together under the “Agile” label. However, I suggest many, inexperienced PM’s and developers would take the textbook Waterfall and try to apply it….
Says it all. The road whither is traditionally paved with good intentions (and human weakness.)
A decent technical library next to one's desk is often a far better resource than the whole internet combined. Actually getting up an taking a book from the shelf to lookup some detail of a data structure or algorithm etc allows the mind's focus to broaden and become receptive to peripheral information in the text which might lead to a much better solution.
Although in practice most software that doesn't need to scale to millions is often better forgoing complex data structures and involved algorithm for simplicity. Its usually easier to replace a simple implementation after benchmarking with a more efficient but more complex implementation than the other way round.
My observations in the last two decades would suggest proportionately far fewer graduates from the exact sciences (eg maths & physics) enter software careers than previously. The vast majority seem to be IT graduates followed by Comp. Sci. (not quite the same thing) graduates. The narrowness of the former IT courses, especially the typical total lack of any mathematics, does limit the creativity and insight required for problem solving tasks.
Speaking as an fairly average coder I'm as sane as the next person. The PFY will attest to that*
Although considering our 3 main coders , theres not that much sane about us, ranging from OCD to an seemingly inbuilt hatred of the entire world of designers/fellow/previous coders (and the manglement for good measure)
But they are very good at what they do. which is fairly typical for our profession... and I've always wondered why.
*I caught her once, standing in a corner, holding a torch and she said she was a lampstand.
[...] I can state with authority that being good at maths has absolutely no relationship to being a good coder.
...Except, of course, when said "coder" is faced with an OBOE, or needs to apply DeMorgans Law, or some such.
Besides, why would anyone aspire to be a coder, anyway? Sets the bar rather low, I wot.
... or needs to deal with coordinate systems in 3D space, and the coder wants to use Euler angles because they're easy to understand but lead to guimbal lock. Instead of using quaternions, whose physical representation is nonexistent but with easy algorithms if you know what they do.
... unless you are doing complex real-time audio synthesis. On the small project I work with, the real nitty-gritty is above my 'pay grade', but fortunately there are a couple of other devs who know what they are doing, so I leave that to them and concentrate on the more mundane UI stuff.
"... being good at maths has absolutely no relationship to being a good coder"
Depends what you mean by "being good at maths". Most math teachers (and consequently their students, graduates and the public at large) believe being good at maths means being able to manipulate symbols and calculate swiftly. In reality, the mathematical mode of thought is grounded in ability to model the world and its processes logically and reasonably accurately -- the essence of good programming (as opposed to mere "coding"). See W.W. Sawyer, Mathematician's Delight (many reprints since 1945) and Junaid Mubeen, Mathematical Intelligence, Profile Books 2022 [ISBN 978 1 78816 683 6].
Maths is, basically, formalised abstraction.
And abstraction is crucial to good systems design (which leads, one would hope, to good code)
Me, I never really got my head around mathematical notation systems which are key to understanding and handling its abstractions. So I've always been frightened of it. That, and learning how to integrate, which in my day was about pattern recognition so you could spot the right technique to use. Numerical methods have rendered that skill from the 1960s totally redundant.
Now, where's my slide rule and log tables?
"... lack of any mathematics, does limit the creativity and insight required for problem solving tasks."
I think this is a bit of a generalisation and it does depend of what exactly (pun on your 'exact sciences') lack means.
I have worked with many people from backgrounds both WITH and WITHOUT extensive mathematical knowledge and the corrolation is not so stark.
Maths is a set of tools that is useful BUT not the end-all of skills to have as a 'Software Engineer'.
You need to have a problem solving mind and you do build up a set of 'conceptual solutions' for problems over time & experience.
It is much easier to be able to lookup techiniques that you may need to 'solve' your problems BUT I do not like the idea of a black box ['AI'] giving you solutions that you are supposed to accept as 'right'.
You must be able to solve a 'problem' in a number of alternative ways to enable you to understand the plus/minus points of the possible ways to go.
Some people have an almost intuitive way of honing in on the 'right' area for the solution NOT just 'I always do this' or 'This is all I know' !!!
This naturally grows with time & experience and you should be always expanding your knowledge as techniques appear or new ideas are considered.
Mindset, attention to detail, accuracy and self-confidence & self-doubt are useful.
You have to aware that you can be wrong and misunderstand and be prepared to rollback a few steps to reconsider your answers.
You are not perfect and can make mistakes ... there is nothing worse than working with someone who always says 'I know what I am doing ... don't question me !!!'.
Finally, there is still some aspect of 'Art' in writing good code as well as technical skills !!!
:)
35 years in development on the back of a history degree. I can count on the fingers of one hand the number of times I've needed maths for anything. Those seven times was plugging values into algorithms other, smarter people wrote. Basic A-level (high school) maths suffices. If you're writing algorithms, you have to already ask yourself if the solution you are implementing is too complex. Never mind premature optimisation, reinventing the wheel is to be avoided.
"The Art of Computer Programming" by Donald Knuth (1968 plus additions) was my bible.
I did once give AI a simple programming problem that should have taken about 8 lines of code. It made a fundamental error. No, a twos-complement addition is NOT the same as a boolean OR, jeez.
“ A decent technical library next to one's desk is often a far better resource than the whole internet combined. Actually getting up an taking a book from the shelf to lookup some detail of a data structure or algorithm etc allows the mind's focus to broaden and become receptive to peripheral information in the text which might lead to a much better solution.”
… and better still the authors of the book - the owners of it’s IP - have been rewarded for their skill and effort by it’s purchases and not bot scraping for free.
"probably not something you could safely Google these days."
More probably something that you couldn't have safely googled 20 years ago - nowadays, with their current levels of filtration in place, I think you would have a struggle to get google to return any results at all of the 'dodgy' nature you are alluding to ;)
Very useful in any managed language too (C#, Java etc), because you really don't want to run out of memory on a high throughput application by forever creating and destroying objects and waiting on garbage collection time.
Annoyingly, despite 30 years in the field, multiple degrees, several bookshelves of books, and t'internet, I had to reinvent the concept for myself as I had no memory of encountering it. Fixing Tom's code for him, I proudly showed Dick the solution I'd just invented only for him to say "nice ring buffer". At which point I realised my "genius" was almost as flawed as my memory, and dreams of fame and fortune travelling worldwide to conferences dissipated like a fart in a hurricane.
I don’t think he was saying that he’d been coding for 50 years, just that he has recently passed 50 years old.
Although I had to go back and check - the phrasing can easily be read either way round (as I also did at first and thought “Hang on a mo…?”)
statements are "As an experienced software engineer (I've recently crossed the half century in years)" and "Back in the '90s when I started as a software engineer".
Hence my point about bad at English. Maybe he has been working for 50 years or is 50 years old (still not sure***) but you would have to squint very hard when parsing the above not to infer programming for 50 years.
It would have been much simpler to state "As an experienced software engineer with 35 years experience..."... the persons actual age is irrelevant to the discussion.
Bluck
**** logically he cant be 50 years old else he would have been to Uni and worked as a chemist all before 15 years of age
You are reading a CORRECTED text...you are late to the party.
The original text stated "As an experienced software engineer (I've recently crossed the half century in years)" and "Back in the '90s when I started as a software engineer".
This has now been amended to "As an experienced software engineer (I recently crossed the half century in years, and have been in the field for over 25 of them)" for which I commend the author making.
Now the math (and related text description) make sense: started Uni at 18, got degree by 21, worked for 1 year as a chemist, worked for 25+ years as a software engineer equals 50 years of age.
Maybe I appear to be an arsehole but no matter the validity of what the author may be stating, this grated with me.
Now my world is back on an even keel I can take the dog for a walk.
Bluck
The IT World was a very different place from today.
PC's didn't exist. The Internet didn't exist.
I wrote my first program in Sept 1972. SOFOR Fortran on punched cards for an ICL 1901A.
Still writing code today (between writing Crime Fiction) mostly in Delphi (or rather Lazarus) for my Model Train Control System parts of which date from 1975 with OCP71's as axle counters.
It now has a full year timetable in the scheduling database (MySQL). My grandkids love it which is IMHO great praise from a them considering the number of hours that they sit playing FPS games.
The original text stated "As an experienced software engineer (I've recently crossed the half century in years)" and "Back in the '90s when I started as a software engineer".
I'm not sure what the problem was. If you started your first job after completing a 3 or 4 year university course and graduated in the mid 90s, then that sentence is perfectly true.
As someone of a similar age, I would even allow leeway a up to couple of years to be considered recent. We're not 8 years old now and none of us are counting the months to our next birthday.
If I were the author or editor I wouldn't have even bothered changing it.
So I learnt FORTRAN at school for a couple of years (the school had a tie in with a local Uni to use their computing facilities..all punch card based) and left school at 17 in November 1977
I considered going to Uni full time but a few weeks before the end of term 1977 I looked at jobs and low and behold their was a job for a "Statistical Cadet" in a small Stats Research company.
I went to the interview and they offered me a job on the spot as a programmer, they would pay for my Uni fees (BSC in Stats) as I studied part time and also give my salary a bump based on the credits I got.
So left school last week of Nov 77, started my new job the next week.
It was a small company run by a older retired former Government Statistician (mid 50's) and a younger mathematician (mid 30's) and they both hated programming so were desperate to get someone that knew FORTRAN.
So my career timeline (compared to others) doesn't make sense.
I am 65, have a degree and have been programming for ~48 years...so there would appear to be a 4 or 5 years anomaly in my math which on occasion has been questioned.... simply because in 99% of cases if you have degree you enter the work force at ~22 and not 17 as was my case.
Bluck
>” so there would appear to be a 4 or 5 years anomaly in my math which on occasion has been questioned...”
So a prospective employer actually read your CV with interest!
I had a slightly different problem: the job I did directly after uni. (‘83) was not a new graduate job (nor was the pay) prospective employers had real difficulty getting their heads around working and being at uni at the same time. It was probably the prime reason why I went into start-ups, who recruited on reputation and word-of-mouth.
Interestingly, subsequent segments of my career (and studies) also involved parallelisms.
The closest analogy i have for this in real life was the debate about allowing maths students to use calculators in exams in the 80’s. I was fortunate enough to have brilliant teachers, and their line was “how will you know if the calculator result is correct?”. It wasn’t that the calculator was in error, but more likely that the operator messed up the inputs - a missed decimal point, a div vs a multiply etc.
I think a modern developer needs to be able to look at an ainswer and recognise when it is not correct and complete. That can only come from learning and/or experience.Scepticism is an underrated quality these days.
Linters, hammers, pliers, AI. They're tools, not ends in themselves. Like any tool, AI can be used productively and abused horribly. If you don't understand platforms, optimization, code, and languages then no amount of AI is going to make you the least bit more productive. On the other hand, if you do, then a good AI assistant can help you with some of the more mundane coding tasks (do you really need to remember that specific syntax for a routine you last used 5 years ago?). I've been coding for over 40 years and have seen languages, tools, and paradigms come and go, They all had their good points and capabilities to do real harm. In the final analysis, it all depends on the evolved monkeys who are controlling and using the technology.
Except AI seems to be like one of those cheap screw drivers they used to sell at petrol stations. They looked like proper tools until you tried using them, the handle would come loose, the stem would bend the head would flatten.
Ask any proper professional they are obsessed with the quality of their tools, and, none of the AI tools seem up to scratch.
100% Spot on !!!
Calling 'AI' a tool is to ignore its weaknesses and to jump ahead of it 'proven' value.
Something is called a 'tool' usually because its facility has been proven by wide suitability for the job and positive experience of use.
A Lump Hammer is a useful 'tool' but would not be used to hammer in tacks when repairing an upholstered chair, a Tack Hammer being more appropriate to the job at hand.
The leap to calling 'AI' a tool is more marketing than proven value ... it still comes with a 'check the answers' warning !!!
This is like a tailor having a pair of well weighted & balanced shears, for cutting cloth, that randomly may become partially blunt !!!
The 'tool' may look good and appear to be just what you need BUT when you use them it may make you job harder or even ruin the job entirely !!!
A tool must make my work easier and work EVERY time without having doubts whether the 'end product' is flawed due to 'Hallucinatory issues'.
:)
"If you don't understand platforms, optimization, code, and languages then no amount of AI is going to make you the least bit more productive."
Unfortunately, it appears to me that the biggest proportion of the people who are most enthusiastic about using the current fake 'AI' for programming, are the ones who don't adequately understand those things; they see it as a shortcut alternative to actually learning how to do the job.
Those who do know and understand probably simply get on and do it.
"When it really comes into its own is when you have no clue what you are doing and need that help to get started. This can save days."
This seems to be the MO for many coders under a certain age nowadays. But if you have no clue where you're going, how will you know when you get there? And how will you know you landed in the right place?
Now get off my lawn!
A while ago I lost multiple days to LLMs producing confident assertions that a particular tool does X, with it producing multiple different ways to make the tool do X.
None of them worked, but due to the complexity of the system it took about an hour to find out each time.
I eventually found real documentation - written by a human - explicitly stating that it didn't do X at all, but it did do Y to achieve a similar goal.
In the last two days I've had an LLM produce a claim that doing Z when using a Python tool was a "critical" error, and output a change that would have completely broken it.
It did this despite the public documentation explicitly requiring the developer to do Z, a requirement that was unchanged since the tool's inception.
When I pointed this out, the LLM produced an apologetic response - but it always does, regardless of correctness.
A major problem is that LLMs are equally confident when asserting that 1+1=2 and that the noon sky is bright pink.
It will gladly drive you off a cliff, then apologise on the way down.
Me to! Jusr as you say, the 'flirst draft' of this code worked, i asked for some tweaks, it's like 'well i really should use this tool instead' then wrote up code using a differnt tool that (per the docs) apparently would never work (the new tool it switched to physically won't do what i want.)
> When I pointed this out, the LLM produced an apologetic response - but it always does, regardless of correctness
That's the problem with LLM's, they have incorporated the Genuine People Personality (GPP) from the Sirius Cybernetics Corporation, hence why they are always happy , cheerful but nearly always wrong
That's one of the first library functions I wrote two decades ago. (Ok, after the registry read/write functions.) :)
I discovered that if a file with the extension already exists, you can ask "what application is associated with *this* *file*?" with SYS "FindExecutable" filename to executable. But if you can't do that, yes you have to step through HKCU\extension -> HKCU\shell\open\command -> Check for %n parameters -> ExpandPaths.
I'm a novice. Not young but just wanted to create an application. I had done bits of scripting in my various roles but never a relatively large app with UI. I started off using AI a lot. I soon found it has severe limitations. It has no human intuition and it cannot seem to take any sort of macro view of what you are doing. It cannot realise that some function should be generalised for use in multiple, similar situations. Sometimes it provides overly complex and abstracted code it appears to have recalled from somewhere. And ... it provides solutions that simply don't work and correcting them requires an extensive prompt that takes as much time as doing it yourself. Sometimes, it simply cannot get to a solution going round in circles being corrected but never getting there.
So ... I use it less and less. But as a super search engine it is fantastic. It is excellent at answering simple language questions, checking syntax and simple logic. It also excels at digging up approaches to questions such as; "what ways can I do ....". As I'm working alone as a retiree it's like having a colleague you bounce things off. I'd prefer a human though they look wider than the exact question and don't keep saying; "you're right, good catch" or "I'm sorry I should not make up API calls".
I think LLMs are more useful for novices like me but fade for experienced programmers using a language they have years of time on.
In simple terms, LLMs are pattern matching word processors.
Why would anyone expect them to have 'intuition', a view (macro or otherwise), or any 'realisation' about anything?
I am also at a loss to understand why there should be any surprise that it should come up with a piece of code "it appears to have recalled from somewhere" - this is what LLMs do. It is how they are programmed. Recalling information from the data they have been 'trained' on is how they work!
"Why would anyone expect them to have 'intuition', a view (macro or otherwise), or any 'realisation' about anything?"
I was neutral on that. As I don't understand how we do it, other than learning from experience, I wondered if an LLM would learn the same way. They do but only in a very low order way. So they learn or rather were trained to work with what you might call first order and zero order (none) abstraction. But higher order patterns such as all the obvious to us human objectives they are unable to grasp. They can fake that but because the higher level abstraction pattern matching is not there, they can't really do it.
code recalled from somewhere
I probably didn't explain this well. What I mean is they often even lack the ability to fully map that code into the new scenario, because of the earlier point they do not understand the full environment so may offer up something that might even do the job but is unnecessarily complex.
But if you fully understand how humans work you should get a Nobel prize. I have a deep suspicion we are 95% pattern matching too, just that we see deeper into the pattern, well most of us. But there does seem to be a little extra in humans. But maybe there isn't, maybe I just want to believe that. I have seen many people behave like NPCs. You can call it faith, they are somehow programmed with belief in something and just repeat, repeat and if presented with evidence or logic that the belief is incorrect can become very angry and aggressive.
While I'd agree that extensive knowledge of maths is an optional extra when designing/writing software, I would point out that schools generally don't teach much (if any) of the maths developed in the last 200 years, with the exception of some statistics. So the odd maths expert (is there any other kind ?) may come in handy occasionally.
IIRC, much if not all of matrix math, or it's use in the mainstream of STEM efforts, is within the last century or so.
I would look for people holding math degrees from programs where the emphasis is on proofs, not applying known results. Yeah, a pure math emphasis. Doing proofs means you have to ask: Am I right? Have I covered all the cases? What are the edge cases? Are there counter-examples? Can I generalize this? Is it useful elsewhere? Can I split out a complicated part into its own theorem/lemma? How can I make this easier to understand by someone else (or even myself)? Do I really need to do it this way, or is there another better approach? Have I really understood the problem? ... All habits of thought you want in a developer.
I think most software engineers will agree at worst, LLMs that assist with code are frequently a good replacement for sites like stack overflow.
They are also frequently a good replacement for the official docs for libraries/frameworks/man pages etc.
Just that aspect makes AI code assistance relatively useful.
Does it make it so useful that the current insanity of throwing trillions of dollars at AI is a worthwhile exercise?
Nope.
There's a great deal of shilling going down from AI hype bros, that's for sure.
The likes of Eric Schmidt, who is quoted as saying, in April this year:
"We believe that in the next year, the vast majority of programmers will be replaced by AI."
Whilst he is no longer at Google, he's a big player in AI investments.
No surprises that he'd be making sweeping statements like this.
You've got 5 months for that to happen, Eric.
I think it's safe to say that Eric was talking out of his ass.
Then you have the tech bros warning about the impending danger of AGI - all of this keeps AI in the headlines.
LLMs are useful, disruptive and powerful - but they are nowhere near the level of hype that's been thrown at them.
I've found use cases for copilot, I guess I use it about 20% of the time for specific tasks.
The latest is upgrading old code - bumping deps and fixing issues, with just a little bit of hand holding, it's surprisingly good.
With the right prompts, it's really good at advanced filtering and sorting of data - it's semantic abilities really shine.
It's fantastic at generating fixtures - again, the semantic abilities are often uncanny valley accurate.
It's good at prototype code. For example, libs and frameworks and concepts you don't know much about - you can quickly get LLMs in agent mode to spin you up working examples.
This requires an experienced developer mindset and good prompting skills. The code generated should never be used in production, but it's good enough to get ideas from and to learn from too.
All of these examples are surely giving tech learning sites a hard time, as well as tech discussion sites such as stack overflow.
There was a time when I'd be on Stack Overflow frequently, both helping and being helped.
Now it's very infrequent - once a month, if that.
My colleagues have the same experience. LLMs are stack overflow on steroids, without the snarky comments (depending on which model you pick, of course)
However, stackoverflow seems to be handling all of this really well, so who knows what the impact will be over the longer term - the longer term being just a matter of a few years in the tech world.
The biggest problem I see is that people throw all of AI into one big basket along with the LLMs which have the mist recognition.
But other forms of AI (for example DeepMind's protein folding work which won a Nobel Prize) are in fact much more significant in value and use cases.
I will make a bold prediction that within 5 years AI diagnostic tools in healthcare (particularly radiological analysis) will outperform their human equivalents.
There are already stories of rare diseases being diagnosed by AI and early ling cancer being spotted by AI.
This is the sort of AI application that really deserves the hype.
Regarding that time frame for Eric Schmidt, I recently heard an interview with Cory Doctorow. He pointed out that the billions pouring into AI data centers have five year amortizations, but the processors have useful lives of around 1.5 years, less at the loads they're being pushed to handle.
That's just crazy in terms of waste.
It's a rising concern that the rush to "AI everything" and build a stupendous amount of data centres to support it, is going to cause huge amounts of equality issues globally.
These data centres will not only be hungry in terms of power, but also very thirsty for cooling.
I'm guessing we're going to see billions poured into massive data centres globally, which will eat up the resources that people need.
That community waiting for a power and water upgrade? - they'll get a downgrade if a big data centre is built nearby.
The only jobs generated will be the short term construction jobs - after that? a paltry few jobs for locals. Security, cleaning etc.
The only people benefitting from this insanity are the tiny amount of tech oligarchs - the rest of us will see net losses.
" the associated application can be overwritten by "user preference," such as "Open with" overrides in Windows Explorer. [..] The AI gave no hint at these wrinkles"
"The AI pointed out the "ScriptErrorsSuppressed" property of the control, which resolved my problems. This is the simple type of contained question at which AI shines."
Since the "AI" literally hasn't a clue what it's talking about but merely depends on statistics about what token should follow what, all this means that in the first case the question has not been asked enough times in those terms to generate a sufficiently significant probabilistic chain, and in the second case this requirement has been fulfilled. The bot knows nothing about the matter of these (or any other) questions -- it literally hasn't a clue conceptually about what you're asking. It doesn't deal in concepts -- it's the embodiment of the "Chinese Room", the capacity of which was to fool the observer, not render valuable guidance.
It's a massive indictment of declining human mental capacities that we have to keep re-iterating this basic truth -- and as we're cattle prodded into using such "AI" more and more there's a serious danger of us becoming dumber than the machines.
I asked an AI last night to generate a Python script that draws some boxes with PIL (Pillow) for an e-ink display I'm playing around with. It managed it and saved me faffing around writing the same code by hand. HOWEVER, I only trust AI for this sort of noddy programming - as a glorified wizard for making simple code samples or throwaway stuff. When tasks are complex, or require security / safety I wouldn't trust it as far as I could throw it.
I look for examples where AI has contributed to solving problems. Many of these have been from AI finding relevant insights from sources outside the user’s field or language.
I also asked AI a question in a subject I know well. At first, AI proposed an old, incorrect “solution” that has been too widely used. A few months later it found the correct solution. My father was an applied mathematician and told me he enjoyed learning the fundamentals in many different subject areas. Many fields start with a big idea followed by a lot of hard work putting the idea into practice. He led a group of mathematicians in a large laboratory and hired people with diverse backgrounds, unlike most academic departments that focus on a few subject areas. AI has the potential to help break out of such silos and suggest novel approaches to problems because it uses wider range of documents than can be found in libraries and conventional web searches.
For me personally AI has been an absolute godsend in getting up to speed quickly on unfamiliar or rusty topics.
I've never got on with books - a character defect on my part (huge impatience) and cannot remember the last I even bought one, the internet made it less likely; AI is the final nail in the coffin.
In five years time, the very term "senior developer" will mean much less as a code producer and more as an architectural decision-maker and AI supervisor.
In short they will be compelled to spend much more of their time THINKING and that's a good thing. Developers/architects will act as the brains; AI will be their eyes, ears, hands and feet.
It won't replace roles - all this talk of mass layoffs is just pure hubris and balderdash - it will elevate them.
Any useful software developer already spends the vast majority of their time "thinking" and "making architectural decisions", and the occasional use of their "eyes, ears, hands, and feet" consists either of using perceptual skills when observing a practical activity, or communicating in an intelligent dialogue with other people (an intelligent dialogue being one which involves both sides thinking).
And AI clearly doesn't remove the need to type, or have any visible eyes, ears, hands, or feet of its own.
From the perspective of how it is used and to what degree it replaces skilled labour, AI is just a new search engine for the existing library of text-based information stored on computers.
If AI were just a glorified search engine, developers wouldn’t be using it to generate production-ready code, refactor legacy systems, or validate logic in real time. That’s a little more than “typing” and “dialogue,” don’t you think?
The reality whether you like it or not is that grunt work is being automated. The ratio of thinking to typing is shifting whether we like it or not. Pretending nothing changes is like saying IDEs didn’t change development because we still type.
Senior roles will lean harder into architecture and oversight because the mechanical bits are increasingly handled by AI. That’s not hubris—it’s progress and progress that is absolutely in the right direction in my opinion. The sooner we stop romanticizing manual keystrokes, the better.
Developer's are using it to produce 'production-ready' code? Not using co-pilot they're not. I'm not really familiar with the commercial AI coding products, but I have a hard time believing they can generate production ready code either. It's likely to happen, just not yet.
Not really sure the point that this article is trying to make, but it doesn't bear much relation to the headline. So one person that is a light AI user doesn't get that much benefit from it? Quick, sell your shares in AI everyone! Or not...
I've been a software engineer (plus other labels) for a good number of years now. This year I worked on an AI project and have done a LOT of learning about AI. Before I get into that, I will say this:
- About 70% of people in my personal experience that claim to be developers aren't competent. At best, a lot of them are bad coders, but there's a lot more to software development than just coding (and if you are going to be just a coder, at least be good at it).
- The software engineering industry is full of cowboys and people that don't know what they are doing. Things don't actually seem to be getting better, sadly. Instead, non-technical people go on a 3 day Scrum course, get a BS certificate and think they know the first thing about running a software development project (they don't, and in all likelihood, neither did the person teaching them on the course).
- Be very afraid of anyone that prefixes any statement about software development with, "I used to be a developer". As a good software engineer, you can often earn around a similar wage (if not more) than a CTO, so the primary reason to no longer be a developer is either you burnt out or weren't very good at it.
Onto AI: if you'd told me a year to a year an half ago that you could get an AI agent to do half or even more of the coding for you, I would have thought that you were quite stupid and incompetent. Today, I not only believe this is possible, but am actually doing so myself.
So what are some people doing wrong and why are some people able to get good results, often using the same models, such as Sonnet 4.5? The answer is 'context', which is the data that you send into your LLM. Copilit isn't very good at this. The best indexing that it does of your codebase is when you have your source code checked into a Github or Azure DevOps. The problem with that is that once you start making modifications, then that index is out of date and it has to fall back to looking at modified files. And not everyone has their code in ADO or Github.
So which tools do have really good context engineering? The two I've found are Augment Code and Warp.dev. Sadly, though both put up their prices recently by 3x or more based on previous tiers, so I'm going to continue with Warp.dev, but also see how I get on wih BYOK (Bring Your Own Key) with it. Both Augment and Warp create really good hybrid indexes of your codebase so that it knows how files and modules relate to one another, the same way that a long time developer working on it would. You can use these systems to add features to an existing codebase and write meaningful unit tests which following existing test (patterns and frameworks).
Copilot is OK for simple stuff, a few pages closely related. But asking it to work and understand the full codebase is most likely beyond what it can do.
Other things you could try at Claude Code with an MCP tool that indexes your codebase and store the vectorised embeddings (which may not be a term with which you are familiar, but it's basically a high dimensional datastore of something which captures the meaning of a thing based on their attributes, which are stored as vectors. Other items close by in that dimensional space are judged as similar. Such as Toast and Bread).
But context is king and you need to clearly ask for what you want, but also provide enough of the existing codebase as the correct context. Augment and Warp do this Automatically. Another thing they do is build the solution, add in tests and keep going round in iterations whilst they fix their own mistakes, which is great.
Compare this to some tools such as Cursor (on the trial, I could only use GPT models) and the results were horrible. Windsurf has gotten far, far worse and was the only AI agent system to corrupt my files multiple times (so perhaps requiring that the Windsurf devs do 80 hour weeks wasn't a great idea after all. Who could have knew, right?!).
At the end of the day, all AI is going to do for incompetent people is to continue them to be incompetent, whilst being a huge help those that take the time to understand how it really works and how it can benefit them.
Output from AI absolutely does need to be reviewed. I've had several situations where the proposed solution was hiding that something wasn't possible (such as a specific local embeddings model wouldn't run in LlamaSharp, though the code pretended it did). If you don't understand, nor review the code that's produced, they you're going to end up in real trouble. But if you're a good developer, then take the time to try out different tools, learn how they work and they will save you many, many hours doing dog work or trying to understand how some spaghetti code works in an old solution.
I'm actually quite positive about AI and it's ability to help people at all levels in software development. I just would be very careful about juniors using it for anything other than to help explain bits of code to them. I would advise them to not use AI to generate code in their early years or at least take days off from doing that. Learning to get unstuck is a crucial skill and it can primarily only be learned by getting stuck.
AI can speed up learning of subjects. I still pay for many training resources, PluralSight, loads of Udemy courses, have had CLoud Academy subscriptions in the past and I really am liking my recent Mannings subscription service where you can even have books read to you. Would probably avoid LinkedIn Learning as I've seen the odd course on there that I feel was full of crap or just plain wrong. But then you can get AI to explain a thing that was glossed over in a training video or book or just answer your specific questions about something. It really is an incredible technology and I fully expect more and more of us to be running local models over the next ten years.
I would highly recommend that any developer spends a good amount of their time developing AI skills and understanding how the technology works at a deep level. Having a strong core foundation about a topic is the only upon which true expert knowledge can be built. Look on Udemy for courses by Ed Donner, they are really good and go into the details of AI.
Yes, AI can generate bad code. It can generate code that works, but wouldn't scale well past one user. But if you're a competent software engineer, you'll quickly spot these problems and be able to get the agent to put them right. So a full circle round of that may take ten minutes, including telling the agent that the first version was wrong and what it should do instead. Ten minutes is far quicker than anyone could have written the code correctly in the first place, so you really can make big gains in coding. And then you can get 100% test coverage for the new code that's just been written, written using the same style and libraries as your existing tests. But again, software engineering isn't just coding, so AI doesn't replace the software engineer. It just means that a 1 person team really can create, test and deploy a full application all by themselves. Many fewer people required on each team.
So to anyone that's not seeing a benefit from AI, then either:
- You are using the wrong tools. Or the right tools badly.
- You are using an obscure programming language.
- You are using brand new frameworks and libraries (which tends to be the case with AI libraries at the moment - agents really struggle writing C# for Semantic Kernel because that library is changing so quickly and things that are still in the readme of the codebase have been removed from the actual code!)
Good luck everyone and be happy: AI can do most of the grunt work, whilst leaving you to do the real thinking. Okay, so perhaps that's not great news for everyone, but it should be.
Whilst there is much to comment upon, I will restrict myself.
>” But context is king and you need to clearly ask for what you want…”
This is down to natural language skills and to have done the specification and design work - namely the stuff keyboard junkies say isn’t necessary.
>” So to anyone that's not seeing a benefit from AI”
I suggest a good first step is to improve your language skills and learn about software specification and design - ie. The stuff you should be doing before jumping into coding.
Perhaps this might be a benefit of AI; getting people to write specifications which are maintained…
People still use Delphi. That's kinda wild.
Also on the primary topic; "it depends" - MMV because how people use it varies. You CAN make it work for you, but you have to know how to do so: it isn't going to just work out the box, it's hard to know if it ever will work out the box.
Think about how a human developer approaches a fresh codebase, let's say you start a new job at a new company, maintaining a 10-year-old system. It might take you 3 months, 6 months, to fully get up to speed. The docs are probably a mess. The test suite is probably broken. It might not have been engineered right in the first place. It might be a system that, IDK, talks to other systems that are hard to model.
If you start a ticket that requires you to get deep into the guts of it in week two you're going to have all sorts of issues, you're probably going to do it wrong - you're relying on your team to catch those errors (they probably won't).
Now consider it from the POV of an AI when you're asking it to work on that same system - you're asking it to do that same thing, but in a matter of seconds. To do what you're asking it to do, with no opportunity to have that 6 months of learning, no support structures, no properly working test suite, no accurate documentation. They'll rip through it, do what they can, but it's probably going to be broken. If there's one legitimate complaint here - and it's probably the root cause - it's that they attempt to "please" the user, that is to say they'll try to please the user by completing the task, even if they don't really know how to. Every time you ask an AI to do something, it starts with its own knowledge and knows nothing about your project.
There are ways to sort all of these issues out, and LLMs are very good at helping you do it. It is an investment of time and work - but a worthy one. You can ask the AI to write its own AGENTS file, its own github PR review instructions, to rewrite the main documentation, all in the repo (you do store the code docs in the repo, not Confluence or something, right?), to properly document how it works, to validate it's own test suite, to build test versions of the systems it talks to. You _must_ check through these yourself, at least initially. Then you can move on to getting the AI to do things for you - and you have it test what it did before even considering telling you that it is finished. When you've done and had AI help you do the groundwork (and you can tell it, by the way, to ask if it doesn't properly understand things) - your 6 months of initial "getting to know the system", but for AI - it will work like a dream.
It'll also help you do things that are above you, if you're remotely intelligent - I have personal projects that I simply don't have the 6 or 7 PhDs I'd really need to write them, where AI has done basically all the work, in a testable and tested way, where the science is sound, which would cost hundreds of grand to have somebody else write. Occasionally at the day job I can ask the AI to do more complex stuff like that, and it will.
It also saves my finger and wrist joints if nothing else, even if it did take the same amount of time in the end - but it doesn't. But AI can do the work of multiple copies of me at the same time anyway, even if that was the case. I sometimes send the AI off cooking personal projects in the background whilst working on day job stuff even, fire and forget..
I have tested several AIs writing code in various languages from C/C++ to C# to COBOL, and Assembler and in every case it could only get very simple tasks correct. Often code won't even compile without several attempts. For anything more complex than "hello world" all AI tools required several attempts to get it correct. In Visual Studio 2026 the AI doesn't know when certain requests aren't possible without low level internals or driver access. Many times asking if to code something technically not possible it kept trying when told the code didn't work.
By themselves, they dont save time. I was struggling re-explaining context, repeating myself with yelling messages "No Fallbacks!". LLMs love to please! And working on different repos (Java, Python, JS, Go), I was working on different components of the applications that connect well but...sit in different repos!
Since that time, I ended up creating Recallium (Recall-ium). It solves the very same problem of re-explaining context, or deal with vanishing context windows. I am not at least 4x-5x more productive.
I research in Claude Desktop - store all teh research as context, --> open Cursor, bring back the context from there, and continue coding.
I even have Global Rules that all AI Assistants get: never implement fall backs :)
While there are plenty of memory systems for AI, I found nothing catered to developers! Try it out: https://recallium.ai
What everyone seems to be forgetting is that this technology is advancing far quicker than we can easily comprehend.
The first PCs were so limited, they were useless for most of the tasks for which we now rely on them. The first speech to text programmes were barely usable, but many now rely on them daily.
The first online translators could only handle the simplest sentences and would fail miserably with anything more nuanced. While still not perfect, they're now incredibly useful.
AI is the same. In general terms the above article is not entirely wrong, but this is only when looking at it at this snapshot in time.
The level of sophistication of AI tools has advanced enormously in just the past year and it shows no sign of stopping.
Even if its utility is currently standing at 30%, it was probably only 5% a year ago and at this rate it could easily be 60% or higher by next year.
Ignore it at your peril.
I don't know how old the OP is, but they seem like they're in my ballpark. I agree with them 100%. With the current state of AI, I use it mostly as a 'look-up' tool, the way I used to use textbooks and/or the ilk of StackOverflow. I catch it in a boo-boo more times than I like, but often enough it gives me some more complete answers than I was looking for - including some error checking that I hadn't considered yet. I guess I'm still in the category 1 - 2 range.