One aspect AI is weak in is controlling complexity. If you tell it to implement something it will go ahead and implement it, without considering how much complexity it adds to the system or weighing alternatives. An experienced engineer on the other hand may decide the feature is too minor relative to the complexity it adds, and may decide to not do the feature. Or he may make some clever compromises to get most of the functionality while keeping the codebase simple. AI is weak in this judgement, it doesn't spontaneously exercise architectural restraint. As a result the code may progressively become too complex even for AI manage, and it becomes whack-a-mole where you can't make a change without breaking something.
Yeah but on the other hand, if you asked an LLM to implement a spec and it was like “I skipped this part because I didn’t like the complexity tradeoff” most people would be like “wtf why doesn’t Claude just listen to me”
I use openspec in addition with the /grill-me skill and it really helps clearing the path before starting to code. I think the goal of engineering, when using AI, is to maximize your value upfront instead of every five minutes.
I feel this mostly is a side effect from lack of domain knowledge. Most of the time this has happened to me, it's because I myself did not cleanly know how a problem should be solved to begin with. If you have a clear picture of what you want, approximately what syntax goes where and why, thats really when LLMs shine in my experience.
If you tell it to implement something it will go ahead and implement it, without considering how much complexity it adds to the system or weighing alternatives.
Recently I asked Claude (Fable) to use multiple threads to speed up a computation that could take several seconds to run while the user was waiting. Instead, it found a way to start the computation earlier in the background while the user was doing other things, so that it would be finished by the time the user was ready.
I found it follows conventions and documentation well. So if you have a well designed core, it can easily add independent features without increasing overall complexity. Maybe it doesn't work in some very tangled domains like games, but some basic crud and saas stuff is pretty much a solved problem now with agents. They will trivially add features that humans would have pushed to a backlog forever as not worth the effort.
I have actually found decent success recently (especially with Fable) giving it an "added line budget". This does more than anything else to keep it on task. The trick is knowing an approximate line count beforehand, but sometimes the LLM will push back on what it should cut. But usually it just doesn't add all those "nice to have" redundancies and multipage comments and unit tests that check if a certain phrase is still in the error message.
Keeping a simple log of "accepted/rejected" avenues is basically all that's needed, maybe with a root style guide in the project. I've got several multi-day sessions in 5.6 Sol running without going off the rails in terms of complexity. After a while in this loop it actually starts to remind/berate itself to keep things straight-forward.
Just ask it to do it. You can ask it to do a line reduction cleanup pass before each commit. I don’t know why they default to adding complexity because they are capable of doing it better just by asking.
With previous engineering trends like blockchains and microservices, you could choose not to jump on the bandwagon. However the coding agents trend is different and is changing the very fabric (sry for Claudeism) of software engineering, for better or worse. I do know we will never go back to mainly programming through code again, that’s for sure.
Knowledge work has changed...But it doesn't solve company internal governance nor politics.
When it takes anywhere between 2 weeks and 3months to do anything ( including approvals for non prod access) in most organizations...Code has never been the problem.
I'm starting to think there is no AI bandwagon per-se - instead the bandwagon most people associate with AI-assisted development is more a bandwagon of sloppy code and low standards - which irresponsible use of AI enables but isn't a prerequisite for (outsourcing sweatshops have been practicing it long before the dawn of LLMs).
I think it's not an option. The benefits are just too large for me.
>I do know we will never go back to mainly programming through code again, that’s for sure.
I think, in some niches, i.e. where there's something not well represented in the training set, it still makes sense to write code by hand. But I am not sure that it will continue.
There are still companies who refuse to believe this and still put Senior+ devs through hell during an interview process with junior level algorithm memorization.
In all aspects there will be dinosaurs and deniers and there will be embracers.
I think you misread. I never said not to learn it. In fact, for your entry level I would recommend testing for it. At senior+ it should be more about software architecture, design patterns, and distributed systems.
I don’t particularly mind algorithmic interview questions (they’re at least self-contained, somewhat objective, and something you can prepare for), but most software engineering has always been done by people with no knowledge of algorithms or compsci fundamentals. What’s being lost is coding fluency, not compsci knowledge.
Better example, leetcode interviews became so popular because people were memorizing FizzBuzz and they needed an alternative (but said interviewers didn't fully understand the purpose of FizzBuzz and though "harder means better, right?").
leetcode interviews be ame a thing, because many believed solving leetcode style puzzles makes you superior. Not because someone would memorize fizzbuzz.
This thinking was popularized by coding competions which existed before leetcode and inspired leetcode. Schools themselves produced people who believed these puzzles are what makes you superior developer - one of us, special and choosen.
Coding with AI has now introduced feature dopamine. At times this results in the system being prone to more failures because AI may have missed edge cases.
Also i am experiencing a decline in job satisfaction and i'm more prone to procrastination because I know the agents will do the work 10x faster than me. I am personally worried about this shift and I fear becoming less knowledgeable over time or not feeling the need to keeping up with new tech stack as agents do the work.
About "implementing by words bit": I don't believe English is a great language to program.
It's not type-safe, not object oriented, not functional. Has poor tools to highlight syntax or navigate through "wordbase", doesn't fail fast. It has no tests and has too large room for machine or other humans to interpret it.
Very often it's easier for me to express my thoughts in Java, which is ironically known to be a "wordy" language. But it's nowhere close to wordiness of English.
And you immediately give up your IP for someone else to use. The 4th option, if you have something in your mind worth building, is to just build the thing, without an LLM.
Sure if you use remote AI services, but any companies working on niche markets where they want to protect their IP, or they simply work with sensitive stuff, will rely on local AI instead.
There’s no company that has “no sensitive stuff”, from HR to financials to customer data to board presentations to engineering IP and they all, without exception , entrust their data to cloud services for at least a decade now. Even governments do that, although they sometimes use special regions.
You have to be able to write the software yourself in order to judge the results and get good software out. Otherwise the system claims the goals are met, the tests pass, and the human driving the system puts up a new PR. If they don’t know any better it must seem like the AI system is better than them and knows what it’s doing.
All the loops and agents don’t protect you from generating garbage.
Which sucks because then how are you supposed to improve your skills when you’re just getting the answers all day… answers you can’t verify?
People are more confident than they ought to be. Always have been. But AI throws gas on that fire.
And yes, there is also another sane and rewarding option: write everything just by youserlf without any assistance. Let's not forget about that one, shall we?
My personal experience is the larger the task you ask it to do, the less attention it pays to the details - for a very large task it seems more prone to missing test coverage, writing duplicate code, not refactoring where it should etc. So I try to split into smaller tasks where possible (also makes it easier to review).
What I like to do is to go back and forth on the spec, break it into very detailed tasks and milestones, and then set a /goal to complete the milestone and verify. Each task is verified with 'fresh eyes' or a clear context.
That said, I'd really like to see data to compare which approach works the best.
I'm not so sure. I think it's fair to say that only people who can output good art / code are qualified to evaluate the output of ai.
It's like how product people / C levels have absolutely no understanding of what makes for good code or a good engineering shop (aside from perceived costs.)
I was thinking more in line “people whose jobs are threatened by technology are biased when evaluating that technology”. Note that I don’t make quality judgement about quality of LLM output.
> You can’t just give a 3000-word, 4-page detailed dense spec and expect it to follow everything, and the larger the codebase, the less it can pack everything in, nor are the vast documents you can feed it worthwhile.
This point seems lost on a lot of principals. I’ve had very little success with these grandiose designs and change requests from RFCs/specs. The context windows just can’t keep it all together and very quickly the approach unravels.
I posit that the further ICs were from writing code at this point in their career, the more they suffer from AI psychosis. It’s the same ivory tower they were already on, just a different order they’re giving.
I have agents that have been running nonstop for several days working through tasks. At some point I have to go to sleep, and wake up to more progress.
Even with preplanning and post hoc analysis thrown in, I am seeing way more than 2x return on my investment. Where are your numbers coming from?
I wonder how that progress is being measured. Lines of code or counts of PRs? Sure... but I thought the matter of measuring productivity by lines of code was already well-understood as being misguided.
I'm having trouble reconciling all that supposed productivity with the real world where software isn't getting better, delivered faster, or becoming cheaper - unlike virtually all breakthroughs in industrialization (printing press, weaving loom, etc) which led to a quick increase in at least one of such factors.
I'm not denying that AI helps with and excels at parts of the software development lifecycle, but from my experience those parts overall contribute to a small increase in output or merely shift the work elsewhere (where it may just not be part of whatever measurement is being used).
I measure adherence to preestablished acceptance criteria, the same as I've done before while either coding myself or managing other engineers.
It sucks, but you don't usually have the time to pour over code when you manage multiple engineers either, so you have to learn how to do thorough but targeted reviews, minimize distraction, maximize efficiency, etc. A lot of these skills transfer over to managing agents.
We've only had truly decent agents capable of running long-horizon tasks for less than a year, I think it's worth calibrating around that: it's too soon to expect the entire industry to visibly shift.
That said, every senior engineer I know has gone all-in on agentic development, and juniors I mentor are getting a lot done as well.
With juniors it's important to make them understand that these models can't be blindly trusted and the output needs to constantly be critically evaluated.
But engineers who know exactly what they are doing have really been able to make some awesome things this year. I'm also working on a few really cool things, more than before, more ambitious as well, without sacrificing quality or craftsmanship.
I can also seem where some trends are headed. The breadth of software available to both harm and help you is going to explode, and computing is going to look a lot different soon. I'm already building targeted health apps for myself, bespoke personal apps and tooling, development tools, I'm working on games, libraries, various kinds of research, you name it. It feels like an intellectual Renaissance, and within a decade I expect things to look a lot different even if models stopped improving today.
You do have to work differently with these models. Your code evolves in a different way, and testing habits have to adapt. Clients are going to accept less stable but more ambitious demos. Prototyping and research have suddenly become very cheap. We're going to see the effects of the spread through STEM and the arts.
I was talking more about end-to-end feature/product development process from the perspective of the business, and not merely the "writing code" part. Things like figuring out what to build, what code to write (which remains - just that now you are writing a prompt instead of writing the code directly), design, customer support, regulatory compliance/etc.
From this perspective I believe that even if AI does actually automate away software development, we will find out that on average it was never actually the bottleneck nor a significant cost of the product lifecycle. Thus I'm not in a hurry to go all-in on AI just because I don't see old-school human-powered SW dev at being the bottleneck, at least not on the products/projects I work on (large software products with established customer bases).
In a lot of cases I find that the what to build is the biggest bottleneck - and in fact the relative slowness and occasional pushback (because they have skin in the game - see below) of conventional human-powered SW dev forces the stakeholder to think really well about what they want and gives them time to refine that idea. If I were to give them a hypothetical "SW dev in a minute" magic wand it would result in a lot of ill-defined & incoherent features being thrown at the wall which will quickly overwhelm support, destroy their reputation with customers (or worse, regulators) and become a perpetual maintenance burden slowing down any further development to a standstill (whether human or agentic). So I don't do that for my own sanity, even though that magic wand already exists and it's called Claude Code.
This is not to say I find AI completely useless - I see plenty of opportunities for AI to help out with non-product-related tasks - housekeeping that doesn't introduce/change any functionality and would normally rot in the backlog forever are good candidates, assuming I have good end-to-end tests and a full isolated environment where the agent can drive the whole product to QA its own work as to not create additional review burden (otherwise, I would have to review and QA it myself which is often as much effort as just doing the work myself).
> you don't usually have the time to pour over code when you manage multiple engineers either
One thing that I get with humans but not agents is skin in the game and self-preservation. A human writing code will write in such a way as to minimize future work to himself next time there's an outage, support ticket or likely change request and 2) will retain memory of what he wrote so that he will be able to address that support ticket or outage much quicker than a human having to effectively reverse-engineer the code to figure it out. From that perspective, agentic development didn't save time, it merely shifted it from the development phase to when the first support ticket or problem arises (the former can be scheduled and budgeted in, the latter is worse as it arises at unexpected times, derailing whatever else is happening).
(this obviously only works in environments where engineers are encouraged to own things end-to-end. I know some places treat their human engineers as a dumb one-shot ticket->code translator and discourage thinking or taking responsibility beyond that. These are the same places that wonder why they're not able to make any progress because they're stuck endlessly fire-fighting the crap such a degenerate process produces)
> With juniors [...] output needs to constantly be critically evaluated
This raises a scary catch-22. How are the juniors meant to evaluate the output without the expertise they'd only gain by being "in the trenches" for 10+ years? LLMs only help to a point - as they can be convinced of anything depending on prompting or persuasion (I've had Claude adamantly claim things that were wrong which I only picked up on because of actual experience. Similarly, I can easily steer it off the correct path with just a couple suggestions).
The problem of upskilling engineers is not new - billions have been thrown at the problem in the form of bootcamps/etc and yet there's still no good replacement for actual experience doing things and getting burnt in the process. I'm worried that deference to AI will mean a sea of perpetual juniors (but with senior responsibility and blast radius) and the jobs market for actually skilled & experienced talent drying up even more.
> bespoke personal apps and tooling, development tools, I'm working on games, libraries, various kinds of research, you name it.
Absolutely, same here. But building goodies for yourself is different from building them for paying customers. The latter brings a certain expectation of stability and support. In fact this is why even pre-LLM, there is a huge gap between being able to program and being able to launch a product, and why many programmers' pet projects never made it to the latter.
> Clients are going to accept less stable but more ambitious demos.
Demos? Sure. But generally speaking they're paying you for the actual implementation and subsequent support and maintenance of it. Salespeople being able to bang out a demo with a few prompts without engineering involvement could also mean more cases of them selling an impossible feature (that human-powered engineering could've warned them about).
It really depends on how you use it. I’ve switched up how I interact with LLMs repeatedly over the years, as the technology has developed.
Now, it’s at the point where it’s like running a development team of very eager amnesiacs. I’ve found the trick is exhaustive documentation by a lead agent, and then having a fresh agent work as a coordinator across as many subtasks as the project sensibly allows. This way the individual components stay on spec, as does the ultimate integration. It’s only really this year that this workflow has started to actually function, and it still needs human supervision - but less and less over time.
I give it two years, tops, and everyone everywhere is building bespoke software because it’s trivially easy.
One aspect AI is weak in is controlling complexity. If you tell it to implement something it will go ahead and implement it, without considering how much complexity it adds to the system or weighing alternatives. An experienced engineer on the other hand may decide the feature is too minor relative to the complexity it adds, and may decide to not do the feature. Or he may make some clever compromises to get most of the functionality while keeping the codebase simple. AI is weak in this judgement, it doesn't spontaneously exercise architectural restraint. As a result the code may progressively become too complex even for AI manage, and it becomes whack-a-mole where you can't make a change without breaking something.
Yeah but on the other hand, if you asked an LLM to implement a spec and it was like “I skipped this part because I didn’t like the complexity tradeoff” most people would be like “wtf why doesn’t Claude just listen to me”
Right, and that's why humans are still needed in the loop.
I use openspec in addition with the /grill-me skill and it really helps clearing the path before starting to code. I think the goal of engineering, when using AI, is to maximize your value upfront instead of every five minutes.
I feel this mostly is a side effect from lack of domain knowledge. Most of the time this has happened to me, it's because I myself did not cleanly know how a problem should be solved to begin with. If you have a clear picture of what you want, approximately what syntax goes where and why, thats really when LLMs shine in my experience.
[dead]
If you tell it to implement something it will go ahead and implement it, without considering how much complexity it adds to the system or weighing alternatives.
Recently I asked Claude (Fable) to use multiple threads to speed up a computation that could take several seconds to run while the user was waiting. Instead, it found a way to start the computation earlier in the background while the user was doing other things, so that it would be finished by the time the user was ready.
Yes, at the tactical level, AI is able to find better alternatives.
I found it follows conventions and documentation well. So if you have a well designed core, it can easily add independent features without increasing overall complexity. Maybe it doesn't work in some very tangled domains like games, but some basic crud and saas stuff is pretty much a solved problem now with agents. They will trivially add features that humans would have pushed to a backlog forever as not worth the effort.
Yes, for simple "leaf level" features where there are no big architectural trade-offs to make, AI works well.
> They will trivially add features that humans would have pushed to a backlog forever as not worth the effort.
More features is always good, right? Let's build dropbox+gmail+netlify+spotify+youtube+hackernews+... \s
Have you found any solutions to this? It would be a big unlock to give it this kind of judgement
I have actually found decent success recently (especially with Fable) giving it an "added line budget". This does more than anything else to keep it on task. The trick is knowing an approximate line count beforehand, but sometimes the LLM will push back on what it should cut. But usually it just doesn't add all those "nice to have" redundancies and multipage comments and unit tests that check if a certain phrase is still in the error message.
Keeping a simple log of "accepted/rejected" avenues is basically all that's needed, maybe with a root style guide in the project. I've got several multi-day sessions in 5.6 Sol running without going off the rails in terms of complexity. After a while in this loop it actually starts to remind/berate itself to keep things straight-forward.
I haven’t used it yet but https://github.com/dietrichgebert/ponytail is somewhat popular.
Just ask it to do it. You can ask it to do a line reduction cleanup pass before each commit. I don’t know why they default to adding complexity because they are capable of doing it better just by asking.
[dead]
With previous engineering trends like blockchains and microservices, you could choose not to jump on the bandwagon. However the coding agents trend is different and is changing the very fabric (sry for Claudeism) of software engineering, for better or worse. I do know we will never go back to mainly programming through code again, that’s for sure.
Fortunately, I haven't jumped the bandwagon yet, so I don't even have to think about going back :)
People who are trying to sell you AI and people who are now dependent on it are desperate for you to believe in its inevitability.
i used to think i love coding. putting some music on and getting into the zone churing code was the best feeling.
stragnely i dont miss that feeling and kind of dread going back to it
I'd say I "miss" it as in its a great kind of feeling, but it's hard to get when you now know there's a way better way of getting things done
Knowledge work has changed...But it doesn't solve company internal governance nor politics. When it takes anywhere between 2 weeks and 3months to do anything ( including approvals for non prod access) in most organizations...Code has never been the problem.
I'm starting to think there is no AI bandwagon per-se - instead the bandwagon most people associate with AI-assisted development is more a bandwagon of sloppy code and low standards - which irresponsible use of AI enables but isn't a prerequisite for (outsourcing sweatshops have been practicing it long before the dawn of LLMs).
>you could choose not to jump on the bandwagon
I think it's not an option. The benefits are just too large for me.
>I do know we will never go back to mainly programming through code again, that’s for sure.
I think, in some niches, i.e. where there's something not well represented in the training set, it still makes sense to write code by hand. But I am not sure that it will continue.
poor reading comprehension, re-read and try again
> I do know we will never go back to mainly programming through code again, that’s for sure.
Say who?
There are still companies who refuse to believe this and still put Senior+ devs through hell during an interview process with junior level algorithm memorization.
In all aspects there will be dinosaurs and deniers and there will be embracers.
How can you assess the output of coding agents if you don't know about algorithms and other fundamentals of software engineering?
I think you misread. I never said not to learn it. In fact, for your entry level I would recommend testing for it. At senior+ it should be more about software architecture, design patterns, and distributed systems.
User acceptance testing.
I don’t particularly mind algorithmic interview questions (they’re at least self-contained, somewhat objective, and something you can prepare for), but most software engineering has always been done by people with no knowledge of algorithms or compsci fundamentals. What’s being lost is coding fluency, not compsci knowledge.
There is no such thing as "junior level algorithm".
And one does not memorize algorithms.
bubblesort has entered the chat
Better example, leetcode interviews became so popular because people were memorizing FizzBuzz and they needed an alternative (but said interviewers didn't fully understand the purpose of FizzBuzz and though "harder means better, right?").
leetcode interviews be ame a thing, because many believed solving leetcode style puzzles makes you superior. Not because someone would memorize fizzbuzz.
This thinking was popularized by coding competions which existed before leetcode and inspired leetcode. Schools themselves produced people who believed these puzzles are what makes you superior developer - one of us, special and choosen.
Coding with AI has now introduced feature dopamine. At times this results in the system being prone to more failures because AI may have missed edge cases. Also i am experiencing a decline in job satisfaction and i'm more prone to procrastination because I know the agents will do the work 10x faster than me. I am personally worried about this shift and I fear becoming less knowledgeable over time or not feeling the need to keeping up with new tech stack as agents do the work.
About "implementing by words bit": I don't believe English is a great language to program.
It's not type-safe, not object oriented, not functional. Has poor tools to highlight syntax or navigate through "wordbase", doesn't fail fast. It has no tests and has too large room for machine or other humans to interpret it.
Very often it's easier for me to express my thoughts in Java, which is ironically known to be a "wordy" language. But it's nowhere close to wordiness of English.
[dead]
And you immediately give up your IP for someone else to use. The 4th option, if you have something in your mind worth building, is to just build the thing, without an LLM.
Sure if you use remote AI services, but any companies working on niche markets where they want to protect their IP, or they simply work with sensitive stuff, will rely on local AI instead.
There’s no company that has “no sensitive stuff”, from HR to financials to customer data to board presentations to engineering IP and they all, without exception , entrust their data to cloud services for at least a decade now. Even governments do that, although they sometimes use special regions.
So I don’t think AI will be much different.
What IP? Everything can be duplicated within a 1week to a month...
??
almost every inference operator either has ZDR or an opt out from training
unless you think they're just lying and training on business users data
You have to be able to write the software yourself in order to judge the results and get good software out. Otherwise the system claims the goals are met, the tests pass, and the human driving the system puts up a new PR. If they don’t know any better it must seem like the AI system is better than them and knows what it’s doing.
All the loops and agents don’t protect you from generating garbage.
Which sucks because then how are you supposed to improve your skills when you’re just getting the answers all day… answers you can’t verify?
People are more confident than they ought to be. Always have been. But AI throws gas on that fire.
And yes, there is also another sane and rewarding option: write everything just by youserlf without any assistance. Let's not forget about that one, shall we?
sane as in your boss will let you do that?
Are you being forced to use AI? I'm not.
But if the person that is above me forces me to use the latest craze tool to do *my* job then that is no longer a place for me to stay.
My personal experience is the larger the task you ask it to do, the less attention it pays to the details - for a very large task it seems more prone to missing test coverage, writing duplicate code, not refactoring where it should etc. So I try to split into smaller tasks where possible (also makes it easier to review).
What I like to do is to go back and forth on the spec, break it into very detailed tasks and milestones, and then set a /goal to complete the milestone and verify. Each task is verified with 'fresh eyes' or a clear context.
That said, I'd really like to see data to compare which approach works the best.
I'm not really sure what point this article is trying to make
Software developers still need to think. Models can't do everything. That's it.
I don’t think there is anything important in there.
True postmodernism has finally been reached by AI!
It's kind of like folks wielding gen ai and calling themselves artists.
Questionable output, generally shunned by artisans.
But possibly good enough for some.
Artists are biased when evaluating AI art (same with programmers evaluating AI code).
I'm not so sure. I think it's fair to say that only people who can output good art / code are qualified to evaluate the output of ai.
It's like how product people / C levels have absolutely no understanding of what makes for good code or a good engineering shop (aside from perceived costs.)
"Experts are biased when evaluating non-expert output" is what I would expect and think is probably the correct thing to be
I was thinking more in line “people whose jobs are threatened by technology are biased when evaluating that technology”. Note that I don’t make quality judgement about quality of LLM output.
> You can’t just give a 3000-word, 4-page detailed dense spec and expect it to follow everything, and the larger the codebase, the less it can pack everything in, nor are the vast documents you can feed it worthwhile.
This point seems lost on a lot of principals. I’ve had very little success with these grandiose designs and change requests from RFCs/specs. The context windows just can’t keep it all together and very quickly the approach unravels.
I posit that the further ICs were from writing code at this point in their career, the more they suffer from AI psychosis. It’s the same ivory tower they were already on, just a different order they’re giving.
AI coding is not that efficient. 2x increase at best, depending on the usage. Doesn't seem like a lot is gonna change tbh.
I have agents that have been running nonstop for several days working through tasks. At some point I have to go to sleep, and wake up to more progress.
Even with preplanning and post hoc analysis thrown in, I am seeing way more than 2x return on my investment. Where are your numbers coming from?
> wake up to more progress
I wonder how that progress is being measured. Lines of code or counts of PRs? Sure... but I thought the matter of measuring productivity by lines of code was already well-understood as being misguided.
I'm having trouble reconciling all that supposed productivity with the real world where software isn't getting better, delivered faster, or becoming cheaper - unlike virtually all breakthroughs in industrialization (printing press, weaving loom, etc) which led to a quick increase in at least one of such factors.
I'm not denying that AI helps with and excels at parts of the software development lifecycle, but from my experience those parts overall contribute to a small increase in output or merely shift the work elsewhere (where it may just not be part of whatever measurement is being used).
I measure adherence to preestablished acceptance criteria, the same as I've done before while either coding myself or managing other engineers.
It sucks, but you don't usually have the time to pour over code when you manage multiple engineers either, so you have to learn how to do thorough but targeted reviews, minimize distraction, maximize efficiency, etc. A lot of these skills transfer over to managing agents.
We've only had truly decent agents capable of running long-horizon tasks for less than a year, I think it's worth calibrating around that: it's too soon to expect the entire industry to visibly shift.
That said, every senior engineer I know has gone all-in on agentic development, and juniors I mentor are getting a lot done as well.
With juniors it's important to make them understand that these models can't be blindly trusted and the output needs to constantly be critically evaluated.
But engineers who know exactly what they are doing have really been able to make some awesome things this year. I'm also working on a few really cool things, more than before, more ambitious as well, without sacrificing quality or craftsmanship.
I can also seem where some trends are headed. The breadth of software available to both harm and help you is going to explode, and computing is going to look a lot different soon. I'm already building targeted health apps for myself, bespoke personal apps and tooling, development tools, I'm working on games, libraries, various kinds of research, you name it. It feels like an intellectual Renaissance, and within a decade I expect things to look a lot different even if models stopped improving today.
You do have to work differently with these models. Your code evolves in a different way, and testing habits have to adapt. Clients are going to accept less stable but more ambitious demos. Prototyping and research have suddenly become very cheap. We're going to see the effects of the spread through STEM and the arts.
> adherence to preestablished acceptance criteria
I was talking more about end-to-end feature/product development process from the perspective of the business, and not merely the "writing code" part. Things like figuring out what to build, what code to write (which remains - just that now you are writing a prompt instead of writing the code directly), design, customer support, regulatory compliance/etc.
From this perspective I believe that even if AI does actually automate away software development, we will find out that on average it was never actually the bottleneck nor a significant cost of the product lifecycle. Thus I'm not in a hurry to go all-in on AI just because I don't see old-school human-powered SW dev at being the bottleneck, at least not on the products/projects I work on (large software products with established customer bases).
In a lot of cases I find that the what to build is the biggest bottleneck - and in fact the relative slowness and occasional pushback (because they have skin in the game - see below) of conventional human-powered SW dev forces the stakeholder to think really well about what they want and gives them time to refine that idea. If I were to give them a hypothetical "SW dev in a minute" magic wand it would result in a lot of ill-defined & incoherent features being thrown at the wall which will quickly overwhelm support, destroy their reputation with customers (or worse, regulators) and become a perpetual maintenance burden slowing down any further development to a standstill (whether human or agentic). So I don't do that for my own sanity, even though that magic wand already exists and it's called Claude Code.
This is not to say I find AI completely useless - I see plenty of opportunities for AI to help out with non-product-related tasks - housekeeping that doesn't introduce/change any functionality and would normally rot in the backlog forever are good candidates, assuming I have good end-to-end tests and a full isolated environment where the agent can drive the whole product to QA its own work as to not create additional review burden (otherwise, I would have to review and QA it myself which is often as much effort as just doing the work myself).
> you don't usually have the time to pour over code when you manage multiple engineers either
One thing that I get with humans but not agents is skin in the game and self-preservation. A human writing code will write in such a way as to minimize future work to himself next time there's an outage, support ticket or likely change request and 2) will retain memory of what he wrote so that he will be able to address that support ticket or outage much quicker than a human having to effectively reverse-engineer the code to figure it out. From that perspective, agentic development didn't save time, it merely shifted it from the development phase to when the first support ticket or problem arises (the former can be scheduled and budgeted in, the latter is worse as it arises at unexpected times, derailing whatever else is happening).
(this obviously only works in environments where engineers are encouraged to own things end-to-end. I know some places treat their human engineers as a dumb one-shot ticket->code translator and discourage thinking or taking responsibility beyond that. These are the same places that wonder why they're not able to make any progress because they're stuck endlessly fire-fighting the crap such a degenerate process produces)
> With juniors [...] output needs to constantly be critically evaluated
This raises a scary catch-22. How are the juniors meant to evaluate the output without the expertise they'd only gain by being "in the trenches" for 10+ years? LLMs only help to a point - as they can be convinced of anything depending on prompting or persuasion (I've had Claude adamantly claim things that were wrong which I only picked up on because of actual experience. Similarly, I can easily steer it off the correct path with just a couple suggestions).
The problem of upskilling engineers is not new - billions have been thrown at the problem in the form of bootcamps/etc and yet there's still no good replacement for actual experience doing things and getting burnt in the process. I'm worried that deference to AI will mean a sea of perpetual juniors (but with senior responsibility and blast radius) and the jobs market for actually skilled & experienced talent drying up even more.
> bespoke personal apps and tooling, development tools, I'm working on games, libraries, various kinds of research, you name it.
Absolutely, same here. But building goodies for yourself is different from building them for paying customers. The latter brings a certain expectation of stability and support. In fact this is why even pre-LLM, there is a huge gap between being able to program and being able to launch a product, and why many programmers' pet projects never made it to the latter.
> Clients are going to accept less stable but more ambitious demos.
Demos? Sure. But generally speaking they're paying you for the actual implementation and subsequent support and maintenance of it. Salespeople being able to bang out a demo with a few prompts without engineering involvement could also mean more cases of them selling an impossible feature (that human-powered engineering could've warned them about).
The entire post reads like a tautology.
It really depends on how you use it. I’ve switched up how I interact with LLMs repeatedly over the years, as the technology has developed.
Now, it’s at the point where it’s like running a development team of very eager amnesiacs. I’ve found the trick is exhaustive documentation by a lead agent, and then having a fresh agent work as a coordinator across as many subtasks as the project sensibly allows. This way the individual components stay on spec, as does the ultimate integration. It’s only really this year that this workflow has started to actually function, and it still needs human supervision - but less and less over time.
I give it two years, tops, and everyone everywhere is building bespoke software because it’s trivially easy.
tl;dr - you still have to think when developing software
C in author's name stands for chu**